1. SysML 2.0 – Visualization Capability
Working Group Progress
for
OMG System Modeling & Assessment Working Group
Chris Schreiber (LMCO), Josh Feingold (TSP), Marc Sarrel (JPL), Elyse Fosse (JPL)
11/21/2018

2. 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
11/21/2018

3. 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
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
11/21/2018

4. Limitations of SysML 1.4 - Visualization
Separation of Model Construction from Visualization
Diagram construction left to modeler
Model elements can be removed, but added elements cannot be automatically added to diagrams
Some tool capabilities to auto-create, but not necessarily rule-based
Specification of SysML Diagrammatic Views
Appearance of SysML diagrams is fixed with no facility for user-defined rules
Modelers sometimes make modeling choices to accommodate immediate needs, resulting in more work later or deferring robust modeling
View Construction and Layout
Layout of diagram elements manual requiring manual maintenance
Facility for “semantic zoom”
In-Work, Changed Data and Model Compare
The current spec is silent on visualizing changes and differences between model baselines
11/21/2018

5. SME Services - Visualization
Relevant SME Services
Render/Produce Model Views
Define Model Views
Present Results
Specify Viewpoints
Extend/Customize Model Language
Model Queries to Support Visualization
Manage Changes to Model
Summarized Inputs/Outputs
User-Defined Input
Domain-Specific Symbology
Controller Data
Template Input
Source/Target Model Input Data
Domain-Specific View Output
Rendered View Output
Rendered Controller View Output
Rendered Compared Model Data View Output (Model/Diagram/Element)
11/21/2018

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
11/21/2018

7. MVC as View and Viewpoint
11/21/2018

8. Requirements Decomposition
11/21/2018

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
11/21/2018

10. Requirements – Object Template Definition
Object Template Definition must be able to store a configurable representation of the UI for a node, edge, port, drawing, or label.
Reference frame
Relative coordinates
Absolute coordinates
Hierarchy of UI elements
UI elements
Define graphical object-to-graphical element attribute linkage
11/21/2018

11. Requirements – OTD – UI Elements
Geometric
Shape
Image
Text
Splitter
Transformation
Group
Logical
If-else
Switch
11/21/2018

12. Requirements – OTD – UI Elements
Action
On click
On double-click
On drag
On mouse-wheel
Elements attributes
Color
Name
Tooltip
Gradient
Hyperlink
Etc.
11/21/2018

13. Requirements – Object Template Definition
Define graphical-object-to-graphical-element attribute linkage so that attributes of objects such as Nodes and Edges can be accessed by the elements that compose their UIs.
Attribute values
Basic operators
If-else
String manipulation
Basic math
Extensible operator language
11/21/2018

14. Requirements – Rich Diagram Persistence
Store and refer to a set of Object Template Definitions
Nodes
Edges
Ports
Labels
Graphs
Intergraph describes connections between individual graphs
Position
Units relatable to some physical dimension
Sizes
11/21/2018

15. Requirements – Rich Diagram Persistence
Nesting (sub-graphs)
Expand/collapse state of owner nodes of sub-diagrams
Relational
Edge connects to node x (and port y) not simply have the end of the edge at the location of node x.
Ports owned by nodes
Nodes owned by graphs
Graphs root of owned by nodes
Edges owned by graphs (ordinary or intergraph)
Labels owed by ports, nodes or edges
11/21/2018

16. 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.
11/21/2018

17. Requirements – Model-to-View Mapping
Data to graph objects
Refer to Object Template Set
Data to rendering style
Choose particular Object Templates to apply
Control attributes referenced by Object Templates
Data to layout properties
Spacing
Style
Other preferences
Data to layout constraints
Swim lanes
Groups
Edge routing
Sequencing
Separation
Position
11/21/2018

18. BACKUP
11/21/2018

19. 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]
11/21/2018

20. Visualization Services - Detail
SME/SysML 2 Service
Customize Language
Customize Service
Interoperate
Construct Model
Visualize Model
Analyze Model
Manage Model
Support Workflow
Support Collaboration
Service Description
Input
Output
Extend and customize modeling language
Present language concept x
Create symbol
User-defined input for domain symbology
Domain-specific symbology available for viewpoint definition
Update symbol
Delete symbol
Assign symbol to concept
Update user interface
- Customized language data - Custom language meta data
- Incorporated custom language elements (symbol, note, etc.) - Incorporated custom language meta data (mouse-over, queriable, etc.)
Define model views
Filter data
Filterable selection data
Rendered Filtered View
Define template
- Existing template information - User input to template - Template meta data (i.e. version, etc.)
Saved, controlled template available for selection
Present results
Present default views
- Selected controller data (including filtered info) - Default view information
Rendered View
Present customized views
Controller Data
Present query results
Present analysis/execution results
Present validation results
Specify viewpoints (includes both query definition and presentation definition)
Define Viewpoint
- User Input - Controller input needs
Rendered Controller View
Update Viewpoint
Delete Viewpoint
Define Thin View Artifact
Define Rich View Artifact
Rendered Controller View as a persitent Rich View Artifact
Read Rich View Artifact
Define, update, delete, and execute model queries to support visualization and analysis
Define query
Update query
Delete query
Execute query
Rendered Controller View, and Rendered View
Manage changes to model
Compare/Diff Model X
- Source Model and Target Model Data - Compare/Diff Controller Data
Rendered Compared Model View
Compare/Diff Model Element
- Source Model Element and Target Model Element Data - Compare/Diff Controller Data
Rendered Compared Element View
Compare/Diff Diagram
- Source Diagram and Target Diagram Data - Compare/Diff Controller Data
Rendered Compared Diagram View
Comments
Schreiber: Constructing the model is no different than any other visualization and so does not get special handling
Schreiber: Visualization should apply facility for different methods (plots, charts, heat maps) that relate to the specific SysML diagram types
Schreiber: The visualization framework should extend beyond diagrammatic representaions
Schreiber: For Define Viewpoint service, thin and thick views. For thin, need only the ability to define the artifact.
Schreiber: For Define Thin View Artifact service. Similar to a PDF export that is a transient operation and doesn't require management of the view
Sarrel: For Re-baseline Branch service, the Git version control system has a powerful concept called re-baselining that could be applied to model version control to work in a branch, and keep up with the latest changes in the trunk in a clean way.
Sarrel: For Diff services, use cases should include both ephemeral and persistent views
11/21/2018

21. 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
11/21/2018

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

23. MVC - OpenMBEE Example
11/21/2018

24. 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.
11/21/2018

25. 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)
11/21/2018

26. 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
11/21/2018

27. 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.)
11/21/2018

28. 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
11/21/2018

29. 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
11/21/2018

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

31. SE Use Cases - Abstract SE Process/Practice
Process Output – Visualization Type
11/21/2018

32. 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

33. 11/21/2018

34. 11/21/2018

35. 11/21/2018