1. System Modeling Assessment & Roadmap Joint OMG/INCOSE Working Group
Objectives:
Assess effectiveness of system modeling with SysML in support of MBSE Adoption and Use
Develop a preliminary System Modeling Roadmap to improve effectiveness
Use the Roadmap to influence the SysML specification, tool vendor implementations, related standards efforts, and industry collaborations
Scope:
SysML modeling language and tools
Modeling languages and tools that support use of SysML (e.g. constraint language, transformations)
Reuse libraries (e.g., models, practices, ..)
Integrations with other engineering models and tools
Focus Areas:
Systems Engineering Use Cases
System Engineering Concept Model
SysML v2/MBSE Capabilities including Model Construction, Model Visualization, Model Analysis, Model Management, Model Interoperability,
Members:
IBM, EADS, LMC, NASA/JPL, Raytheon, John Deere and Various Consultants
1/18/2019

2. MBSE Capability: Visualize Model Data
Task objective
Elaborate concepts, requirements, and metrics for effective model visualization that support the next generation system modeling language (SysML v2)
Use Cases
Systems engineers, other discipline engineers, and systems engineering data consumers visualize system model data throughout the lifecycle to support system specification, design, analysis, and verification activities.
MoE
Ability to represent model data in a variety of forms
Ability to navigate between model views
Ability to navigate to model views from other disciplines (Engineering and other)
Ability to define ad hoc views of model data
Driving Requirement & Associated Requirements:  
(R3) The next-generation modeling language and tools must provide flexible and rich visualization and reporting capabilities to support a broad range of model users.
Also . . .
(R5) Support broader context of MBE
(R8) Efficient and intuitive to a broad range of users
(R11) Modular and extensible for future technology
1/18/2019

3. Model Visualization – Intent and Derivation
Driving Requirement
(R3) The next-generation modeling language and tools must provide flexible and rich visualization and reporting capabilities to support a broad range of model users.
High Level Intent and Derived “Requirements”
The next-generation modeling language and tools must enable visual representation of model data in a variety of forms. [R3]
Visualization must easily navigate to/from model data to other visualizations from other Engineering (and Program Disciplines) [R3,5,8]
Visualization must include non-diagrammatic views (tables, matrices, etc.) [R3,8]
Visualization must support both static and dynamic representations [R3,11]
Visualization must support SE Use Cases [R3,8]
Visualizations should be initially simple [R3,8]
Visualizations should provide easy access to associated data (meta data) [R3,5]
Visualization should provide some ability to manage appropriate data from the visualization back to the model [R3,11]
1/18/2019

4. Stakeholder Context for Visualization
Model Data
User
Contributor
System Modeler
Heavy Model User
Modeling Tool and Language
Traditional System Definition
Pattern and Ontology Development
Light Model User
Contextual Interaction and Modification
Attribute and Value Definition
Analysis
Data Consumer
Read-Only Use
Data Association and Connection
Ad-hoc and Alternative Viewing
1/18/2019

5. Systems Modeling Environment Conceptual Architecture
Need to refine definition of the conceptual architecture to account for additional stakeholders and uses

6. Requirements Decomposition
Following Model-View-Controller paradigm
Back End Data Structure - Model
Front End Visualization - View
Translation Layer - Controller
Meaningful, Repeatable View Construction
Model Data Definition
Navigation, Flexibility and Relevance
1/18/2019

7. MVC - OpenMBEE Example
1/18/2019

8. Requirements – Back End Data Structure
Elements – Entities and Relationships from the Domain Space
Wheels, engineers, telephones, marriages, shipping routes
Descriptors – Details of Elements, either stored as relational columns, attributes, or via triple-store relationships
URI, price, color, temperature, date of birth, duration
Support multiple types of views
Diagram, 3D, Geographic, Simulation
1/18/2019

9. Requirements – Front End Visualization
This spec to be constrained to Systems Diagrams.
High-level conceptual definitions
What does each type of drawing object represent?
Drawings, Nodes, Edges, Ports, Labels, Annotations, Nesting
External Links
Palette definition rules
How to create a set of drawing object representations to describe a system
Level of differentiation acceptable within a single visual object definition
Provide core, extensible palette definitions
Updated “classic” SysML style
Simplified “iconographic” style
1/18/2019

10. Requirements – Translation Layer
Explicit mapping between back end and front end
Comprehensible
A viewer should, without needing to explicitly view the source data, be able to determine the approximate meaning or significance of the diagram.
Reproducible
With access to only the Back End and Translation Layer, be able to create a functional duplicate of the front end visualization.
Unambiguous
With access to only the Front End and Translation Layer, be able to derive important aspects and critical structure of the back end data.
Facilitates a single interpretation of the data by multiple users.
1/18/2019

11. BACKUP
1/18/2019

12. SME Requirement #3 - Visualization
3. The next-generation modeling language and tools must provide flexible and rich visualization and reporting capabilities to support a broad range of model users. SysML currently includes concepts for view and viewpoint. Tool vendors and end users have been able to apply this capability to query the model and provide flexible reporting capability. The next generation must extend this capability with advanced visualization techniques that include dynamic zoom, filtering, and traversal of model relationships, and visualizing the dynamic behavior of a system, such as provided by simulations. The modeling language must also support symbol libraries that extend well beyond the current SysML notations. It is also expected that the modeling environment will provide a simplified web interface to dynamically view the model from a diverse set of viewpoints.
1/18/2019

13. MBSE Capability: Visualize Model Data
Task objective
Elaborate concepts, requirements, and metrics for effective model construction that support the next generation system modeling language (SysML v2)
Use Cases
Systems engineers, other discipline engineers, and systems engineering data consumers visualize system model data throughout the lifecycle to support system specification, design, analysis, and verification activities.
MoE
Ability to represent model data in a variety of forms
Ability to navigate between model views
Ability to navigate to model views from other disciplines (Engineering and other)
Ability to define ad hoc views of model data
High Level Intent/Driving Requirement:  
The next-generation modeling language and tools must enable visual representation of model data in a variety of forms. (now in back end)
Visualization must easily navigate to/from model data to other visualizations from other Engineering (and Program Disciplines) (tool requirement, partially captured in front end)
Visualization must include non-diagrammatic views (tables, matrices, etc.) (need to determine if this is a tool issue or whether spec wants to be this broad)
Visualization must support both static and dynamic representations (likely a tool requirement)
Visualization must support SE Use Cases
Visualizations should be initially simple (made more explicit in translation layer)
Visualizations should provide easy access to associated data (meta data) (decomposed into per-layer requirements)
Visualization should provide some ability to manage appropriate data from the visualization back to the model (this is a tool requirement, but also addressed to some extent in translation layer - unambiguous)
1/18/2019

14. Stakeholder Visualization Drivers
Visualization Paradigm – Purpose for visualization by stakeholder type
Interaction Constraint – Extent to which stakeholder input should be constrained by language
Contribution - Ability to modify model data during interaction with visualization
Extension – Possible additional needs for visualization beyond pure system engineering process
1/18/2019

15. Informed by SE Use Cases Visualization Stakeholders
Modeling User – includes users with requirements for CRUD access including multiple manipulation modes (GUI, bulk-load, etc.)
Domain User – includes users with requirements for limited or access controlled CRUD access and unlimited view-only access (other SE’s, other Eng domains)
Casual User – includes all users with requirements for view-only access
Visualization Types Taxonomy
Applicable Standards
ISO10303
Special Discussion on the Requirement to Use SysML Syntax (Diagramming Conventions) in Visualizations
Special Discussion on the Use of SysML Extensions and Domain-Specific Views (i.e. iconography, Safety views, etc.)
1/18/2019

16. Categorizations of Data Visualization Types
2D-Planar
Examples –
Cartograms
Point Distributions
Contour Maps
3D-Volumetric
CAD
Surface and Volume Geometries
Point Cloud and Heat Map (MRI)
Temporal (not just Time!)
Timeline/Time Series/Alluvial
Flow, Sankey, Arc
Multi-Dimensional
Categorization – Pie Chart, Histogram, Bar Chart, Tree Map, Stacked Area
Relationship – Parallel Set, Spider
Hierarchical
General Tree, Dendrogram, Radial Tree, Hyperbolic Tree, Stack Map
Network
Node Link
Matrix
Radial Dependency
Hive Plot
1/18/2019

17. SE Data Uses – The “V” Stakeholder Needs
CONOPS
Mission Timelines/Events/Scenarios – Timeline, Hierarchical, Network, 2D and 3D Visualization
Mission Needs – Hierarchical, nDimensional
Requirements Development and Management
Requirements – Hierarchical, Network, 3D, Temporal
Architecture
Functional Architecture – Hierarchical, nD, Temporal, Network
Physical Architecture – Hierarchical, Temporal, 3D, nD, Network
Mission Critical Event/Item/Process – Timeline, Hierarchical, Temporal, Network, 2D, 3D, nD
Budgets and Allocation – Hierarchical, Temporal, Network
Implementation – covered mainly in Detail Design Discipline Tools
Integration –
Assembly Sequence – Timeline, Hierarchical, 2D, 3D, nD, Temporal
Verification –
Verification Plan – Timeline, Network, Hierarchical, Temporal
Validation
Validation Plan – Timeline, Network, Hierarchical, Temporal
1/18/2019

18. SE Data Uses - Other Operation/Sustainment -
Disposal – Timeline, Temporal, 3D
Analysis (System Level)
System Performance
Decision Analysis
Risk
Specialties
Reliability
System Safety
Etc.
1/18/2019

19. SE Use Cases - Abstract SE Process/Practice
Process Output – Visualization Type
1/18/2019

20. MBE To-Be State Source: NDIA MBE Final Report dated February 2011
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

21. 1/18/2019

22. 1/18/2019

23. 1/18/2019