Systems Engineering Model Lifecycle Management (MLM) Workgroup

The Systems Engineering Model Lifecycle Management (MLM) project originated as a spinoff of the INCOSE MLM Working Group which originated in 2012 to indentify the scope and challenges of model management. Our focus here is to identify the capabilities (as services), and infrastructure needed to support a key aspect of MBSE Systems Modeling Environment (SME) namely, managaing the various model baselines.

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.

• The next-generation modeling language must be capable of management in a heterogeneous and distributed modeling environment. The ability to manage change to the model, where multiple users are collaborating on a single model, is challenging enough. This basic capability requires extensive branch and merge capability that includes effective means for evaluating and integrating changes from multiple users, while maintaining a history of all changes. These challenges increase when multiple models and tools are all part of the collaboration. The ability to integrate with Product Lifecycle Management (PLM) environments, which enable versioning, configuration, and variant management, is a fundamental SME requirement.

• Scaleability (number of elements, uses, model size)
• Transaction Time (user transactions, bulk transactions)

SysML meta data/concepts currently not available in the language:

• Time of revision
• System identification (which system is being modeled)
• Model version identification
• Previous model version identification
• Dependency information to other MCI’s and modeling artifacts
• Author information
• Tool/Environment version information
• External sources
• Rationale and assumptions
• Variances and feature lists

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:
   1. - Models of different kinds including geometric, analysis, and logical models (refer to model taxonomy in SEBoK Part 2 ‘Representing Systems with Models’}
   2. - Artifacts that result from the execution of models such as simulation and analysis results.
   3. - Needed inputs to stimulate the models .
   4. - Artifacts that are generated as views of the models including documents and reports.
   5. - The tools and environments used to create, review, update and delete the models and related artifacts.
   6. - 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).
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 :
   1. - Direct or indirect model interface dependency
   2. - Direct or indirect model association
   3. - 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:
   1. - Create and identify a dependency
   2. - Delete a dependency
   3. - 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 .
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:
    1. - Multiple users reviewing the same or different MCI’s at the same or different time
    2. - Multiple users updating the same or different MCI’s at the same or different time
    3. - Updating a model that contains updated MCI’s, newly created MCI’s, or deleted MCI’s
    4. - Identifying and tracking the change log in such collaboration
    5. - 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:
    1. - Time of revision
    2. - System identification (which system is being modeled)
    3. - Model version identification
    4. - Previous model version identification
    5. - Dependency information to other MCI’s and modeling artifacts
    6. - Author information
    7. - Tool/Environment version information
    8. - External sources
    9. - 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.
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:
    1. - The MLMS should allow a user to look search for Model Element
    2. - 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.
    3. - The MLMS should allow a user tag Model Elements and to use these tags in searching and browsing (private and public tags).

…and growing

The SME will be capable of managing system models as part of a heterogeneous and distributed modeling environment.

• Standardized metadata for capturing change, variant, and configuration information
• Integrate with PLM environment
• Manage SysML and its dependencies as a graph
• Unique id for all model elements
• Model configuration item (CI)is the level the model is versioned
• Model diff hierarchical from CI to element level
• Model branch and merge capabilities
• Capture incremental changes efficiently
• Ensure automated transformation between SysML v1 and SysML v2 and later versions
• Broad support for model transformation

• UC 1 Provide Actionable Data - 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.
• UC 2 Provide Evidence/Provenance - 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.
• UC 3 Notify Users of Change - 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.
• UC 4 Collaborating on Model - 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.
• UC 5 Protect PI - 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.
• UC 6 Compare Models - 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.
• UC 7 Support User Roles - 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.

and more…

• "Model Lifecycle Management for MBSE", Submitted version
• SysML v2 Model Management OV-1 - draft Dec 12, 2016

• JPL TBD

Below are a list of services key to MLM. However, most services listed in the spreadsheet are useful for supporting MLM such as visualization and workflow. Context specific services are listed in the Derived Requirements section above.

• Services to Manage Changes to the Model
  • Request model update
  • Create branch
  • Define data privileges (across models)
  • Control access
  • Update branch
  • Log change
  • Re-baseline branch
  • Merge branch to trunk
  • Define version
  • Compare/Diff Model
  • Compare/Diff Model Element
  • Compare/Diff Diagram
• Services to manage metadata
  • Create metadata
  • Update metadata
  • Delete metadata
  • Define metadata query
  • Update metadata query
  • Delete metadata query
  • Execute metadata query
• Services to define/execute notifications (specialized workflows)
  • Task change notification
  • Model change notification
  • Execute change notification

• Present MLM requirements in the context of change management scenarios
• Illustration of how concepts supports the Hybrid SuV scenario

Last updated December 25, 2016