INCOSE Model Life Cycle Management MLM Challenge Group

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

System Modeling Environment Basic Functionality in Support of MBSE 22

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: 1. model construction 2. model visualization 3. model analysis 4. model management 5. model exchange and integration 6. support for MBSE collaboration and workflow • Scope – Sys. ML modeling language and tools – Reuse libraries (e. g. , models, practices, . . ) – Integrations with other engineering models and tools 33

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

Driving Requirements • Driving requirements for the next-generation system modeling language and tools have been identified as highlighted below. 1. Express the core systems engineering concepts. 2. 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. 3. Provide flexible and rich visualization and reporting capabilities to support a broad range of model users. 4. Enable much more intuitive and efficient model construction. 5. Integrate across discipline-specific engineering tools, including hardware and software design, analysis and simulation, and verification. 55

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

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 domainspecific 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 bidirectionally. 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. 7

MLM Concept Simulation, analysis & resulting data High level representation ofproduct structure & behavior Mechanical & geometric aspect 8

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

Why is MLM Hard? • Environment: – 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, 1000 s 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. 10

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

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

MLM Roadmap and Approach • Participate with PLM/MBSE effort in Man. TIS – 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 – Sys. ML Constructs • Evaluate System Architecture Model (SAM) as Configuration Specification across “System Model” 13

Related Initiatives and Collaborations System Engineering Environment WG OMG Sys. ML 2. 0 RFP INCOSE Model Lifecycle Challenge INCOSE SME WP model construction Updated SE-Bok model visualization model analysis model management model exchange and integration support for MBSE collaboration and workflow ts Requiremen Proc esses Challenges aches o r p p A Solutions Recommenda Best OMG Man. TIS PLM/MBSE Pract ices 14

USE CASES Source: UCs where initially pulled from the INCOSE White Paper 15

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. 9/17/2021 16 16

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. 9/17/2021 17 17

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. 9/17/2021 18 18

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. 9/17/2021 19 19

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. 9/17/2021 20 20

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. 9/17/2021 21 21

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. 9/17/2021 22 22

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

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 SEBo. K 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). 24

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

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

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

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

BACKUP 29

Additional Requirements to be vetted • Support fine-grained ownership of (responsibility for) model elements by domain-of-expertise and/or multidisciplinary 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 metamodel – 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 30

API Services A B C 31