1. INCOSE Model LifeCycle Management (MLM) Challenge Group
Update - 23 Sept 2015
Laura E. Hart
Lockheed Martin

2. System Modeling Environment Basic Functionality in Support of MBSE

3. System Modeling Environment (SME)
Used by system modelers to perform MBSE in the broader context of Model-Based Engineering (MBE)
Provide basic capabilities that include:
model construction
model visualization
model analysis
model management
model exchange and integration
support for MBSE collaboration and workflow
Scope
SysML modeling language and tools
Reuse libraries (e.g., models, practices, ..)
Integrations with other engineering models and tools

4. Effectiveness Measures
Improve systems engineering productivity, quality, and management of complexity and risk
Expressive: Ability to express the system concepts
Precise: Representation is unambiguous and concise
Presentation/communication: Ability to effectively communicate with diverse stakeholders
Model construction: Ability to efficiently and intuitively construct models
Interoperable: Ability to exchange and transform data with other models and structured data
Manageable: Ability to efficiently manage change to models
Usable: Ability for stakeholders to efficiently and intuitively create, maintain, and use the model
Adaptable/Customizable: Ability to extend models to support domain specific concepts and terminology
Secondary
Primary

5. Driving Requirements
Driving requirements for the next-generation system modeling language and tools have been identified as highlighted below.
Express the core systems engineering concepts.
Include precise semantics that avoid ambiguity and enable a concise representation of the concepts.
impact assessment of a requirement or design change
integrate with equation solvers, execution environments, & capture quantitative data.
Provide flexible and rich visualization and reporting capabilities to support a broad range of model users.
Enable much more intuitive and efficient model construction.
Integrate across discipline-specific engineering tools, including hardware and software design, analysis and simulation, and verification.

6. Driving Requirements (cont.)
Provide a standard application program interface (API) to provide dynamic access to the model.
Capable of being managed in a heterogeneous and distributed modeling environment.
Enable efficient and intuitive use by a broad range of users with diverse skills.
Must be highly adaptable and customizable to multiple application domains.
Support the migration of existing models with minimum information loss.
Enable evolution of the above capabilities that take advantage of on-going advances in technologies, concepts, methods, and theories.

7. System Model - Definition
A System Model contains the information about the system at any given stage during its lifecycle. It includes the system architecture model and model-based connections between the system architecture model to the various domain-specific models, such as CAD and CAE models that describe various aspects of the system and its sub-systems [2, 3]. The connections between the system architecture model (or model elements) and domain-specific models (or model elements) may have different behaviors [4], such as (1) reference connections for basic traceability, (2) data map connections for exchange for parameter values, (3) function wrap connections for wrapping executable code in system model elements, and (4) model transform connections for generating and synchronizing model structures bi-directionally. Also, the scope of the system model may vary. Sometimes, the system model is viewed as an abstract specification model of the system and its elements and other times, it may include the detailed element design information.
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:

8. MLM Concept Simulation, analysis & resulting data
High level representation
ofproduct structure & behavior
This is an illustration of a typical MLM concept. The “SOI” or Whole System Model is represented by several different types of models including architecture, analysis, and geometric models of the system. The architecture model typically includes a high level representation of the product structure and behavior. The CAD models cover mechanical and geometric aspects of the system, and the analysis models include simulation and other engineering analysis models and the resulting data from their execution or computation. . As the figure shows, models evolve over time through different revisions, refer to each other to define dependency/traceability constraints/objectives. Moreover, the specific tool revision/version that was used to author the models is changing and must be linked to its associated model artifacts.
a) Changed name from 'System of Interest' to 'Whole System Model'
b) The Whole System Model points to the CAD Model, Analysis Model, and the Architecture Model to clearly encompass a broad spectrum of models.
c) Added change request to drive the model revision
d) Added people (Bob and Mary) to indicate that the team members and that the participants change over the lifecycle as well.
e) Added change request to initiate model revision
f) Added a model View to indicated the views must be managed as well
Mechanical & geometric aspect

9. Model Lifecycle Management (MLM) - Definition
Model Lifecycle Management (MLM) is a governance process synchronizing the create, read, update, and delete (CRUD) operations on heterogeneous models within the supporting modeling tools and model repositories, throughout the system development lifecycle. This is accomplished through the management of Model Configuration Items, including versions, variations, configurations and baselines of models, simulations, analysis results, and the tools that are used by multiple geographically dispersed users. In addition, MLM includes the management of all the metadata associated with the models, tools, and analysis results including who made the change, what changes were made, when and why, as well as information regarding the application of the model.

10. Why is MLM Hard? Environment: Data: Collaboration: Change Management
Large distributed teams including contractors require different data Access
Geographically distributed physically
Physical representation and granularity of data based on tools and configurations
Data:
Large data sets, 1000s of requirements, elements, interfaces
Differing maturity levels require different processing
classifications, owners, IP
Collaboration:
Sharing data based on access rights
Supporting reviews
Collecting metrics
Change Management
Depends on phase and maturity of data.  Informal during creation, formal and expensive after program baseline
Model Quality
How to validate completeness, maturing and quality.

11. Organizing Construct (a good place to start)
Model Lifecycle Management for MBSE
Sets Scope
Defines terminolgy
Identifies realated practices
SCM, ALM, PLM, PDM, CM, ECM, DM
Identifies Use Cases
Defines requirements

12. Adjacent Management Domains
Utilize patterns from adjacent control domains:
Source Code Management (SCM)/Application Lifecycle Management (ALM)
Product Lifecycle Management(PLM)/Product Data Management (PDM)
Configuration Management (CM)
Enterprise Content Management (ECM)
Data Management (DM)

13. MLM Roadmap and Approach
Participate with PLM/MBSE effort in ManTIS
Solicit vendor support ????
Identify Use Cases
Identify common patterns of adjacent practices
Identify information to be shared in a collaborative development between domains (inter-model vs intra-model)
(MB)SE
Electrical
Mechanical
Simulation
Software
Identify additional meta data to support MLM
Identify a set of services to support UCs
Standardize vocabulary in systems modeling languages
SysML Constructs
Evaluate System Architecture Model (SAM) as Configuration Specification across “System Model”

14. Related Initiatives and Collaborations
System Engineering Environment WG
model construction
model visualization
model analysis
model management
model exchange and integration
support for MBSE collaboration and workflow
OMG SysML 2.0 RFP
INCOSE Model Lifecycle Challenge
Updated SE-Bok
INCOSE SME WP
OMG ManTIS PLM/MBSE
Requirements
Processes
Challenges
Approaches
Solutions
Recommendations
Best Practices

15. Use Cases
Source: UCs where initially pulled from the INCOSE White Paper

16. UC 1 Provide Actionable Data
1. A stakeholder of a Model/Model Element who is not the editor of the entire set of information within the Model/Model Element needs curated information within the model in order to make decisions or present definitive information to other parties.
2/27/2019

17. UC 2 Provide Evidence/Provenance
2. During an exchange of information between parties engaged in argumentation, one party challenges the veracity of Model/Model Element information and the other party must obtain the provenance of the curated information in order to provide a warrant for the claims made by the information.
2/27/2019

18. UC 3 Notify Users of Change
3. A stakeholder responsible for contributing to or curating numerous models has too little spare time to poll each model in their scope of responsibility; this stakeholder needs to be notified when an area of interest within a particular model is subject to access or modification by selected individuals or communities of interest.
2/27/2019

19. UC 4 Collaborating on Model
4. Two or more stakeholders are collaborating on a common model yet are not present in the same actual meeting place. Lacking body language clues, the stakeholders need to receive indication of their peer activities within the shared model.
2/27/2019

20. UC 5 Protect PI
5. A community of stakeholders with differing permissions to view, modify, and relate information form a joint venture that exploits their respective capabilities to solve a complex problem. Meanwhile, the providers of information retain their information confidentiality rights.
2/27/2019

21. UC 6 Compare Models
6. An organization is requested to describe, present, or instantiate a system that was created some past time even perhaps with different knowledge tools and by individuals no longer associated with the organization. During such a representation, the organization is requested to demonstrate the differences between the current systems and the legacy systems.
2/27/2019

22. UC 7 Support User Roles
7. An enterprise-scale team which aggregates functional and domain teams from a variety of corporations works contemporaneously and serially on a common problem that requires access to different model elements in different lifecycle phases, different levels of abstraction, in different disciplines, and with different information access rights.
2/27/2019

23. requirements
Source: Requirements where initially pulled from the INCOSE White Paper

24. Requirements 1/4
1. The MLM System (MLMS) shall provide services for managing the creation, review, update, and deletion of individual constituent models and model elements, their interfaces, and related artifacts. 2. MLMS shall keep a strict governance mechanism for any CRUD (Create, Read, Update, Delete) operation executed on the Model Configuration Item. 3. The MLMS services shall include: i. Models of different kinds including geometric, analysis, and logical models (refer to model taxonomy in SEBoK Part 2 ‘Representing Systems with Models’} ii. Artifacts that result from the execution of models such as simulation and analysis results. iii. Needed inputs to stimulate the models . iv. Artifacts that are generated as views of the models including documents and reports. v. The tools and environments used to create, review, update and delete the models and related artifacts. vi. Metadata about the models, the related artifacts, the tools and environments, and the users of the models and related artifacts. 4. The MLMS shall not modify the model content (excluding its metadata).

25. Requirments 2/4
5. The MLMS shall provide services to identify Model Configuration Item (MCI) and related artifacts to be managed. MCI related artifacts are any other MCIs that have direct or indirect dependency with the original MCI. Dependency can be defined as : i. Direct or indirect model interface dependency ii. Direct or indirect model association iii. Explicit dependency defined between the MCI and any other data source 6. The MLMS shall provide services to identify different versions of a MCI and related artifacts, and maintain a history of the versions 7. The MLMS shall provide services to identify different variations of an MCI and related artifacts, and maintain a lineage of the variations (e.g., their source and dependencies) 8. The MLMS shall provide services to generate reports of the differences between versions and variants of MCI’s or collections of MCI’s (include comparison of MCI’s resulting from different tool versions) 9. The MLMS shall provide services to manage dependencies between versions and variants of MCI’s that may be the same or different model kind. The management shall include: i. Create and identify a dependency ii. Delete a dependency iii. Generate a query/report of the dependencies between an MCI and any other MCI’s 10. The MLMS shall provide a service to identify and alert on model inconsistencies, for example models synchronizations after an update to one of the Model Elements .

26. Requirements 3/4
11. The MLMS shall provide services to enable 2 or more users to collaborate on the creation, review, update, and deletion of the same and different MCI’s within one or more models. This includes: i. Multiple users reviewing the same or different MCI’s at the same or different time ii. Multiple users updating the same or different MCI’s at the same or different time iii. Updating a model that contains updated MCI’s, newly created MCI’s, or deleted MCI’s iv. Identifying and tracking the change log in such collaboration v. The MLMS shall provide services to maintain information about the modeling tool/environment that was used to create, review, update or delete the MCI. This should include the tool name and version, release date and any other relevant tool metadata. 12. The MLMS shall provide services to create, review, update, and delete metadata for each revision and variant that includes: i. Time of revision ii. System identification (which system is being modeled) iii. Model version identification iv. Previous model version identification v. Dependency information to other MCI’s and modeling artifacts vi. Author information vii. Tool/Environment version information viii. External sources ix. Rationale and assumptions 13. The MLMS shall provide different metrics such as the number, type and frequency of changes for NCI over time. This may result from query and analysis of the metadata or MCI content over its evolution. 14. The MLMS shall provide services to assess the impact of changes in tool versions on an MCI, collection of MCI’s, or models.

27. Requirments 4/4
15. The MLMS shall provide policy-based security and access controls to the MCI’s, models, and related artifacts. At minimum, the MLMS should enable authentication and authorization based security model in the MCI level. 16. The MLMS shall not significantly degrade the performance and availability of the modeling environment as it relates to creating, reviewing, updating and deleting MCI’s and Models 17. Once models are configured and executed, the MLMS shall support the identification, analysis and storage of the analysis results within the MLMS boundaries. The MLMS systems should provide analysis result visualization and summary information. 18. Search and Navigation: i. The MLMS should allow a user to look search for Model Element ii. The MLMS should allow a user to browse the models managed within the MLMS and to open a Model or Model Element when it was found. iii. The MLMS should allow a user tag Model Elements and to use these tags in searching and browsing (private and public tags).

28. The MLM team meets every other Friday from 11-12 Eastern.
Resources
MLM White Paper (concepts)
MLM Team Site
INCOSE Connect Site
The MLM team meets every other Friday from Eastern.
Contact Lonnie VanZandt if you would like to participate.

29. Backup

30. Additional Requirements to be vetted
Support fine-grained ownership of (responsibility for) model elements by domain-of-expertise and/or multi-disciplinary team-member (block, part, value properties)
Provides solid basis for role-based access rights management
Support fine-grained version/revision control
Enable full revision history
Could (should?) be an orthogonal concept to rest of meta-model
At object level? Need to validate potential scalability issues
Learn from success of git and github (ALM)
Provide access control to model
Support CRUD transactions
Support content PI, Classification, Role responsibilities and rights (right on data versus

31. API
Services A B C