1. SysML 2.0 – Systems Engineering Process (SEP) Working Group
Workflow, Practices & Collaboration
Focus Area
Snapshot
March 15, 2016
11/16/2018

2. Outline Background and Context Limitations of SysML v1.4
Focus: Workflow, Practices & Collaboration = Systems Engineering Process
Limitations of SysML v1.4
Focus: Modeling Language with no Process recommendations
Effectiveness measures as a basis for evaluating concepts
Focus : Alignment with Industry Best Practices, Simplicity, Flexibility, Completeness, Collaboration
Services needed to support concept
Focus: Practices for; SE, MBSE, AML Integration, PLM Integration, Product Lines
Illustrate how concept supports the Hybrid SUV scenario
Focus: High Level Workflow and Practices
11/16/2018

3. MBSE Capability: Systems Engineering Process
Background and Context
MBSE Capability: Systems Engineering Process
Task objective
Elaborate concepts, requirements, and metrics for an effective systems engineering workflow, its practices and collaboration that support the next generation system modeling language (SysML v2)
Use Cases
The Workflow and Practices systems engineers and other discipline engineers follow to develop and update the system model throughout the lifecycle to support system specification, design, analysis, and verification activities. Plus their collaboration with other domains, such as Product Lifecycle Management (PLM)
MoE
Best-practices necessary for efficient and innovative model-based systems engineering
High Level Intent/Driving Requirement:  
The next-generation modeling language must be accompanied by a best practice process for model-based systems engineering
Rather than only standardizing a modeling language and logical systems modeling environment (SME) process advice (based on industry norms) must also be provided
More streamlined and efficient model-based systems engineering processes could reduce the time and effort to build and maintain models and systems
Reduced learning curve when embarking on model-based systems engineering
11/16/2018

4. MBSE Workflow, Practices & Collaboration
Background and Context
MBSE Workflow, Practices & Collaboration
Hardware Models Q
SET
CLR S R
System Models
Component Models ò G ( s ) U
Analysis Models
Operational Models
Component Models
System Models ò G ( s ) U
Analysis Models
Operational Models
Configuration Management
Program
Management
Test
Manufacturing
Hardware
Systems
Customer
Logistics
Software
System Models
Operational Models
The MBE to-be state leverages MBE across the acquisition life cycle to enhance affordability, shorten delivery time, and reduce risk. In the to-be state, the models become an integral part of the technical baseline, and evolve throughout the programs life cycle. The current state is characterized by gaps between domain silos and lifecycle development phase hand-offs that are often the source of errors until later in the development process when they are more expensive to fix.  The future state of MBE seeks to reduce these errors though seamless integration of model data across domains and across the lifecycle by aligning shared model properties and assumptions. Different engineering disciplines concurrently operate on different facets of the system and/or product design, such that the impact of a change in one model can be readily assessed in another model. Engineering and programmatic knowledge is shared through a common technical baseline. The models developed by each discipline evolve in maturity throughout the life cycle, and are not thrown away and redeveloped as the program transitions from one phase of development to another. This includes the up-front mission analysis models, the system requirements and architecture models, the detailed hardware and software design models, and the detailed simulation models used to assess and verify all aspects of the system as it evolves. Early validation of requirements including those for manufacturing and support, and efficient development of a fully integrated technical baseline result in significant improvement to the development process.
The collaborative foundation provides a means to share the information from the model registry across the extended enterprise of customers, teammates and suppliers. The foundation includes the modeling standards that enable information exchange, the model registry that enables ready access to the different models, and a trusted environment which enforces protection of intellectual property and secure access to sensitive and classified data. The collaborative environment also enables reuse from one program to another to enable sharing across a family of products and system of systems.
The MBE to-be state includes a workforce that is skilled in the use of the matured modeling methods and tools, an infrastructure that supports this capability, and policies that enable it.
MBE Enhances Affordability,
Shortens Delivery and Reduces Risk Across the Acquisition Life Cycle
Needs
Current Capabilities
Budget/Schedule

5. Systems Modeling Environment Conceptual Architecture - Practices
Background and Context
Systems Modeling Environment Conceptual Architecture - Practices
Initial Scope

6. Systems Engineering Process (SEP)
SysML v1.x
Limitations
Systems Engineering Process (SEP)
SysML v1.x provides no recommendations, norms or examples of MBSE implementation processes or workflows
Confusion about how to apply SysML v1.x as there are no standard techniques
Block abstraction means Systems and Components are not explicit
Activity abstraction means that Functions are not explicit
DSL Profiles & Stereotyping lead to widely different SysML implementations
No clear roles and responsibilities mapped to viewpoints and/or diagram types
System model silos with limited standards for integration with adjoining specialisms
Focus on language ignores tool environment concerns, such as collaboration
11/16/2018

7. MBSE Capability: SEP Simplified Ontology
Background and Context
MBSE Capability: SEP Simplified Ontology
SE Lifecycle
(methodology)
Outside SysML 2.0 Scope
SME Practice Repository
Practice
(Process Step or Task)
Technique
Role
SME
Workflow
(Use Case)
Service
User
11/16/2018

8. MBSE Capability 1: Systems Engineering Process
Background and Context
MBSE Capability 1: Systems Engineering Process
Detailed Requirements - Identification, definition and description of:
SE Lifecycle (when)
Outside the scope of SysML 2.0 but would include;
MBSE
Systems of Systems
System Product Line Engineering
Rigor Aspects
Agile Aspects
PR Practice (Process Steps) (what)
e.g. 1 Design Review
e.g. 2 Change in Requirement
SME Workflow (SME Specific Process Steps) (what)
e.g 1 View current design, identify improvements, propose changes, implement changes
e.g. 2 Elicit new/changed requirement, analyze the impact of the change, reject requirement, modify system design or compromise
11/16/2018

9. MBSE Capability 1: Systems Engineering Process
Background and Context
MBSE Capability 1: Systems Engineering Process
Detailed Requirements - Identification, definition and description of:
PR Techniques (how)
e.g. 1 Peer review, design review workshop, brainstorming, storyboarding
e.g. 2 Requirements change impact analysis, requirements coverage analysis
SME Service (how)
e.g. 1 Automated design review, system model simulation, functional animation
e.g. 2 Trace link navigation, missing trace link report
PR Roles with Skills (who)
e.g. 1 System Design Reviewer with skills & competencies in MBSE
e.g. 2 Requirements Engineer and Systems Engineer
SME User (who)
e.g. 1 The SME login for Bill Smith – who is a model-based systems engineer
e.g. 2 The SME login for Kirsty Walker – who is Requirements Engineer
11/16/2018

10. MBSE Capability 2: Systems Engineering Process
Background and Context
MBSE Capability 2: Systems Engineering Process
Detailed Requirements - Identification, definition and description of:
PR & SME Tools (where)
e.g. 1 Systems modeling tool (generic, then site specific)
e.g. 2 Requirements engineering tool and/or PLM tool (generic, then site specific)
PR & SME Deliverables/Products/Outputs
e.g. 1 Design review report, list of proposed improvements, improved model
e.g. 2 New requirements, updated model, change requests
PR Values or Benefits provided (why)
e.g. 1 High quality system design, problems found early when cheaper to fix
e.g. 2 System meets stakeholders needs, agile response to changing needs
MBSE Risks & Mitigation
e.g. 1 Incomplete system design – mitigated by Design Review
e.g. 2 Requirements not met – mitigated by Requirements change practice
Relationships between all of the above
e.g. Risks for a Practice, Roles involved in a Practice, Deliverable from a Practice
11/16/2018

11. Systems Engineering Process (SEP)
Effectiveness
Measures
Systems Engineering Process (SEP)
Clear and Understandable
Measure: broad review (for clarity) inside and outside usual OMG/INCOSE audience
Simple, Pragmatic and Relevant
Measure: # of pages of documentation
Modular and Applicable in Parts
Measure: Can parts of the SEP be used autonomously (e.g. PLM Workflow)
Generalist but Applicable to Specific Domains
Measure: Reviews to eliminate domain specific language but also trials in different domains
Scalable from Rigorous to Agile
Measures: Trials
Tool and Tool Vendor Agnostic
Measures: Review for independence
Aligned with Appropriate Industry Standards
Measures: OMG Standards (SysML 2.0), OASIS Standards (OSLC, etc.)
11/16/2018

12. Systems Engineering Process (SEP)
Support Services
Systems Engineering Process (SEP)
Workflow and Collaboration Practice Repository
To document and store the SEP
SEP Authoring
SEP Updating from OMG
SEP Extending/Tuning by SysML 2.0 User Organizations and Tool Vendors
SEP Distribution/Viewing
Assumptions
These need to be reviewed;
The SysML 2.0 SEP for Workflow and Collaboration and freely distributable and not licensed
The SysML 2.0 SEP does not include copyright content from other SE or MBSE processes
11/16/2018

13. Hybrid SUV Scenario - SEP
To Do
High level SEP proposal needs to exist before it can be tested with the HSUV scenario
11/16/2018