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

System Modeling Environment Basic Functionality in Support of MBSE

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

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

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.

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.

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: http://sebokwiki.org/wiki/Representing_Systems_with_Models

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

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.

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.

Organizing Construct (a good place to start) Model Lifecycle Management for MBSE http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:model_lifecycle_management_for_mbse_v4.pdf Sets Scope Defines terminolgy Identifies realated practices SCM, ALM, PLM, PDM, CM, ECM, DM Identifies Use Cases Defines requirements

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)

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”

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

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

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

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

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

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

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

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

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

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

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

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 .

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.

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

The MLM team meets every other Friday from 11-12 Eastern. Resources http://www.omgwiki.org/MBSE/lib/exe/fetch.php?media=mbse:model_lifecycle_management_for_mbse_v4.pdf MLM White Paper (concepts) http://www.omgwiki.org/MBSE/doku.php?id=mbse:modelmgt MLM Team Site http://www.incose.org/ChaptersGroups/WorkingGroups/mbse-initiative INCOSE Connect Site The MLM team meets every other Friday from 11-12 Eastern. Contact Lonnie VanZandt lonniev@gmail.com if you would like to participate.

Backup

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

API Services A B C