1. System Modeling Assessment & Roadmap Joint OMG/INCOSE Working Group
Systems Engineering Model Construction
Focus Area
Snapshot
December 8, 2015
Collaborate
Analyze
Integrate
System
Model
Manage
Transform
Construct
OMGSysML Model Construction Wiki
Exchange
Visualize
9/18/2018

2. Outline Background and Context Limitations of SysML v1.4
Focus: External reviewers
Limitations of SysML v1.4
Focus: Model Construction related features
Effectiveness measures as a basis for evaluating concepts
Focus : Model Construction measures: Productivity (Time, Cost), Quality, Ease of Use, Learning Curve Complexity
Services needed to support concept
Focus: Model Construction services
Illustrate how concept supports the Hybrid SUV scenario
Focus: Model Construction
9/18/2018

3. System Modeling Assessment & Roadmap Joint OMG/INCOSE Working Group
Background and Context
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
9/18/2018

4. MBSE Capability: Construct Model
Background and Context
MBSE Capability: Construct Model
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 and other discipline engineers contribute to the development and update of the system model throughout the lifecycle to support system specification, design, analysis, and verification activities
Hybrid SUV Change Scenario
MoE
Ability to efficiently and intuitively construct models
High Level Intent/Driving Requirement:  
The next-generation modeling language and tools must enable much more intuitive and efficient model construction.
It often requires several clicks to capture a core concept in a model.
More streamlined and efficient user interfaces could reduce the time and effort to build and maintain a model.
The ability to repeat common modeling patterns with reduced user input (e.g., table-based entry) is another capability to increase modeling productivity and understanding.
9/18/2018

5. MBE To-Be State Background and Context
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

6. Systems Modeling Environment Conceptual Architecture - Construct Model
Background and Context
Systems Modeling Environment Conceptual Architecture - Construct Model
Initial Scope

7. MBSE Capability: Construct Model
Background and Context
MBSE Capability: Construct Model
More Detailed Requirements:
Model Changes (includes a change to a model element or change to a reference to an external model element or other data item, or possibly to a change in metadata)
Create new elements or references
Update existing elements or references
Delete existing elements or references
Create Variants of elements or element configurations
Type of Data Input
Manual entry
Graphical
Text/structure text
Tabular/forms based
Automated ingest from the following
Another model of same type
Another model of different type
Structured data source (e.g., file, database)
Unstructured document
Linked data via reference
Simple link (e.g., hyper link)
Semantic relationship (e.g. OSLC)
9/18/2018

8. MBSE Capability: Construct Model
Background and Context
MBSE Capability: Construct Model
More Detailed Requirements (cont):
Construction Operations
Control  access (validate user has data access privileges)
Automated ingest
Select and validate data source
Transform input to match schema
Maintain links/log to external data source
Manual entry
Apply pattern
Apply validation rules and assess
Resolve validation errors
Log changes to model
Capture metadata regarding update (who changed, when, rationale, input source...)
Report differences
Non Functional Requirements
Performance
Security
Extensibility
New technology
New requirements
9/18/2018

9. MBSE Capability: Construct Model
Background and Context
MBSE Capability: Construct Model
Stakeholders
Customers
Managers
System Engineers
Design
(IV&V)
Specialty / Whole Life
Other Disciplines
Software
Hardware
Mechanical
Electrical
Algorithms
Mission / Business Analysts
Sources
Customer Specifications
Management Cost/Schedule and EVMS
System Level
CONOPS – Operational Scenarios
Specifications: SRD, SSS, ICS, etc.
Software
SRS, CSCI models/specs, UCs
Hardware
HWCI models/specs
Algorithms
Models/specs
9/18/2018

10. Background and Context
System Engineering Model Construction Role of the Concept Model, for example
A model is a simplified representation of a system at some particular point in time or space intended to promote understanding of the real system.
As an abstraction of a system, it offers insight about one or more of the system's aspects, such as its function, structure, properties, performance, behavior, or cost.
Source:
Table
VIEW DB
Text
VIEW
System
Requirements
System
Test Cases
Controller/Transform
Table
System
Model
Text
VIEW
System
Interfaces
Controller/
Transform
MODEL
Update 2003
Model with
Latest
Graphic
Table
Text
Model
System
Design
VIEW
Controller/Transform
CONCEPT MODEL
Parse & Transform Using
Concept / Meta model “grammar”
9/18/2018

11. MBSE Capability: Construct Model
Background and Context
MBSE Capability: Construct Model
Interactive Model Construction
Standard tool HMI with
Model Browser
Model Diagram
Model Tool Palette
Model Library Access
Stereo type extensions
Data types, and units
Patterns (e.g. Frequently used combinations of model elements)
“Batch” Model Construction
Tabular data import
Requirements (ID, Description, attributes….) mapped to Requirement Stereotype
Interfaces (ID, Description, Type, Attributes) mapped to Interface Stereotype
Use Cases (ID, Description, Pre-Condition, Post-Condition, scenario steps,…)
Structured document import
Unstructured text
Structured / Unstructured Graphics and Figures/Images
& Hybrid
9/18/2018

12. Working Group Wiki Page
Background and Context
Working Group Wiki Page
9/18/2018

13. Working Group Wiki Page
Background and Context
Working Group Wiki Page
9/18/2018

14. Working Group Wiki Page
Background and Context
Working Group Wiki Page
9/18/2018

15. MBSE Capability: Construct Model
Background and Context
MBSE Capability: Construct Model
Dependencies on other MBSE Assessment Capabilities
Concept Model
Understanding the core and extended concept model is a key pre-requisite to both interactive and batch model construction
Includes transformation from tabular, structured text and natural language descriptions to model based representations
SE Use Cases
Consistent with use cases dependent on model construction
Lifecycle aspects of model construction (e.g. concept, architecture, design, implementation, integration, verification, validation phases)
MBSE Usability
Viewpoint/Views for model construction
Pattern: Model-View-Controller
Tabular: e.g. MS Excel as the model view with macro adapters to the system model
Graphical: e.g. MS Visio as the model view with templates and adapters to the system model
3-D Visualization: e.g. STK with adapters linking to the system model
Pattern Libraries: e.g. domain specific system model patterns for all views driven from a common library
Automation Techniques
OSLC, etc.
9/18/2018

16. System Model Construction Current State & Vision
Background and Context
System Model Construction Current State & Vision
Current State
Manual Entry
Rich GUI interface
Semi-Automated
Bulk tabular data input via plug in scripts
Structured document parsing
Requirements Documents “shall” statements
Design Documents
Tool to tool transfer/exchange
Third party support tools
Bridges/Gateways
File based/OSLC based
Repository transfer/exchange
Emerging Vision
Full automation
Sketch interpretation
Concept development support
Structured text interpretation
Based on standardized document templates
Drawing interpretation
Structured graphics
MS Powerpoint graphics
MS Visio graphics
Repository Exchange
Schema based transformation
Tool Exchange
Model Interchange (UML based)
Model Interchange (non UML)
9/18/2018

17. December 2015 Discussion Material
Limitations of SysML v1.4
Focus: Model Construction related features
Effectiveness measures as a basis for evaluating concepts
Focus : Model Construction measures: Productivity (Time, Cost), Quality, Ease of Use, Learning Curve Complexity
Services needed to support concept
Focus: Model Construction services
Illustrate how concept supports the Hybrid SUV scenario
Focus: Model Construction
OMGSysML Model Construction Wiki
9/18/2018

18. Limitations of SysML v1.4 Model Construction
Language Limitations related to Model Construction
Time representation: Milestone, Time Period
Constructing:
Timelines,
Allocating System Elements to Time periods,
Begin/End dates/times for activities
Workflows
Spatial representation: (X,Y,Z), (Lat, Lon, Elevation), (Azimuth, Elevation, Range)
Environment spatial context
Physical Representation of system deployments
Views/Viewpoints
“fit for purpose” representations of the system architecture/design,
“non technical” viewpoints/views
Stochastic Processes
Random Variable representation
Simple distributions (Normal, Exponential, etc.)
9/18/2018

19. Effectiveness Measures Model Construction
Interactive Model Construction
Productivity Measures (Time on Task, # of interactions)
Support for new model construction: element, attributes, operations, relationships
Measure: # of interactions to complete a range of model construction tasks
Support for model “re-use”: patterns, libraries
Measure: # of interactions to complete pattern construction or library insertions
Quality Measures
Completeness: at end of task is the model complete e.g. all required fields have entries (where “required” is defined by the organizations work instructions)
Consistency: at end of task is the model left in a “consistent” state (where “consistent” is defined by the organizations best practice guidelines)
Ease of Use
Intuitive Interface: Need to define what “intuitive” implies from a model construction perspective, e.g. window layout, menus, pop-ups, browsers, drawing areas are easy to find and access (based on standard windowing environments)
Standard Human Factors principles employed
Learning Curve
Related to Ease of Use
Measures related to length of time it takes a range of user categories to become “proficient” in constructing a model with a range of complexities (static, dynamic, parametric, etc.)
9/18/2018

20. Effectiveness Measures Model Construction
Batch or “Bulk” Model Construction
Productivity Measures (Time on Task, # of interactions)
Support for importing external data and constructing an initial model that represents the external data (tabular, free text, etc)
Quality Measures
Completeness: at end of task is the model complete and are all external data element represented in the model
Consistency: at end of task is the model consistent with the “intent” of the external data description
Ease of Use
Intuitive Interface: Is it an easy to learn process to access the external data (tables, text documents, etc.), set up the import mappings and execute the transformation of the external data into the model representation?
Standard Human Factors principles employed, specifically for transformation of information from one representation to another
Learning Curve
Related to Ease of Use
Measures related to length of time it takes a range of user categories to become “proficient” in importing a model with a range of complexities (static, dynamic, parametric, etc.)
9/18/2018

21. Support Services Model Construction
9/18/2018

22. Support Services Model Construction
Login
Description: Provide user/process credentials, returns a pointer to the session.
Service Signature: SessionLink login (String userID, String password)
References:
Logout
Description: Terminate user/process session, returns null
Service Signature: null logout()
Create Model Element
Description: Create a model element from a list of parameters, returns a UID (Unique id) of the new model element or null (for invalid element) (AttrValList is a comma separated value list of all of the model elements property names, property types and associated values)
Service Signature: UID createModelElement( String stereoTypeName, String elementName, String elementDescription, AttrValList propertyList)
Create Model Variant
Description: Create a model variant of a model element, returns a UID (Unique id) of the new model variant or null (for invalid pattern)
Service Signature: UID createModelVariant( String modelTypeName, String modelUID)
9/18/2018

23. Support Services Model Construction
Create Model Pattern
Description: Create a model pattern from a list of model elements, returns a UID (Unique id) of the new model pattern or null (for invalid pattern) (AttrValList is a comma separated value list of all of the model elements property names, property types and associated values)
Service Signature: UID createModelPattern( String patternTypeName, String patternName, String patternDescription, modelElementList elementList)
References:
SelectModel Pattern
Description: Select a model pattern from a list of model patterns, returns a UID (Unique id) of the new model pattern or null (for invalid pattern) (AttrValList is a comma separated value list of all of the model pattern names)
Service Signature: UID selectModelPattern( String patternTypeName, String patternName, AttrValList propertyList)
9/18/2018

24. Support Services Model Construction
Delete Model Element
Description: Deletes the model element referenced by UID, returns true if deletion successful, or false if failed delete.
Service Signature: Boolean deteleModelElement( UID elementUID)
References:
Delete Model Pattern
Description: Deletes the model pattern referenced by UID, returns true if deletion successful, or false if failed delete.
Service Signature: Boolean deteleModelPattern( UID elementUID)
Modify Model Element
Description: Modifies the referenced model element, returns true if modification successful, or false if failed modification.
Service Signature: Boolean modifyModelElement( UID elementUID, String propertyName, String propertyValue)
Modify Model Pattern
Description: Modifies the referenced model pattern, returns true if modification successful, or false if failed modification.
Service Signature: Boolean modifyModelPattern( UID elementUID, String patternName, String patternValue)
9/18/2018

25. Support Services Model Construction
Create Model Elements from Table
Description: Creates a set of new model elements from a tabular listing of each model element, uses createModelElement service for each row an array of UIDs for each element created (null for invalid model elements) (table format is a CSV (comma separated value) formatted table
Service Signature: UID[] createModelFromTable (Table ModelElementsTable)
References:
Create Model Elements from Graphic
Description: Creates a set of model elements from a formatted graphic (e.g. MS Visio or PowerPoint) representation of the model elements, their properties and their annotated relationships whith each other.
Service Signature: UID[] createModelFromGraphic ( Graphic modelElementsGraphic)
Create Model Elements from Text
Description: Creates a set of model element from a textual description of the model elements (assumes a structured representation of the model element that can be parsed using natural language parsing rules to discover nouns, verbs, adjectives, adverbs, etc. that represent structural, behavioral, requirement and parametric descriptions of a systems model
Service Signature: UID[] createModelFromtext (String modelElementSpecification)
References: 2012 Drechsler, 2015 Tao Yue
Link Model Elements from Graph
Description: Creates a set of model elements from a directed graph representation of the system model, returns a list of created model element UID’s
Service Signature: UID[] createModelFromGraph(Graph modelElementGraph)
9/18/2018

26. Support Services Model Construction
Create Validation Rule
Description: Create a validation rule for a set of model elements, returns a UID (Unique id) of the new rule or null (for invalid pattern) (RuleValList is a comma separated value list of all of the rule property types and associated values)
Service Signature: UID createValidationRule( String ruleTypeName, String ruleName, RuleValList ruleValueList)
References:
DeleteValidation Rule
Service Signature: Boolean deleteValidationRule( String ruleUID)
UpdateValidation Rule
Description: Update a validation rule, returns a UID (Unique id) of the updated rule or null (for invalid pattern) (RuleValList is a comma separated value list of all of the rule property types and associated values)
Service Signature: UID updateValidationRule( String ruleUID, RuleValList ruleValueList)
Execute Validation Rule
Description: Execute a validation rule , returns a Boolean indicated 1 success, 0 failure of the exectuion)
Service Signature: Boolean executeValidationRule( String ruleUID )
9/18/2018

27. Hybrid SUV Scenario Model Construction
Vehicle design unable to satisfy a requirement
Model Construction:
Question: Role of the “model” at this point in the scenario? Query, analyze? Trouble Report Model?
Propose requirement change
Model Construction
New Requirement as variant to and existing requirement. Question: Change as “variant”?
New dependencies between new requirement and design model elements
New Constraints as variant to existing constraints
New value bindings for the constraint variants
Assess potential impact to system design
Question: Analysis capability….potential for new analysis comments/notes or analysis model elements
Propose update to specifications
Specification updates to the design model elements as variants linked to the requirement and constraint variants
Report update and creation
Implement change
Question: How to model “implementation” change (e.g. Model execution, generation from model)
Add new “build” model element (representing a model based build package)
Add new build scripts to the build model element
Verify system meets requirement
Add new test scenario, test case, test procedures, test results
Add test artifact links to design elements and requirement variant
9/18/2018