Model Lifecycle Management for MBSE

Authors: Amit Fisher, Sanford Friedenthal, Mark Sampson, Lonnie VanZandt, John R. Palmer, Mike Nolan, Michael Loeffler, Manas Bajaj , Krista Hovey, Laura Hart, John Nallon

Abstract

Model Based Systems Engineering (MBSE) is an evolving practice in the early stages of adoption similar to the mechanical, electrical and software domains 20 to 30 years ago. Today there is increasing recognition of the potential MBSE brings to system life cycle processes with the increasing complexity of systems and the demands of the global marketplace. In order for the practice to realize this potential, system modeling  and MBSE must be part of the larger model based engineering effort, and integrate with other engineering discipline models and modeling activities across the life cycle of a system. This is placing increasing demands on the need for Model Lifecycle Management (MLM) as an essential part of an MBSE infrastructure. This paper establishes the motivation for model life cycle management, as well as laying the foundation for addressing the model management challenges that lay ahead. The paper describes some of the key concepts, requirements, current practices, and future directions of MLM. 

1. Motivation - Model Lifecycle Management as an Enabler of Model-Based Systems Engineering (MBSE)

Smarter and more complex products enter our lives every day. The modern society in the 21th century is more dependent than ever on such systems that serve our basic needs for health, communication, transportation, financial management, education, entertainment and much, much more. These smarter products today are not independent. They usually consist of collections of other constituent systems, and often dependent on the behavior of external systems. Products are more and more autonomous, capable of optimizing their  operation and perform goal-seeking behaviors. Moreover, we witness the growing importance of smarter, cyber-physical systems that combine software, hardware, mechanical and electrical components. Ever increasing demands on system performance is driving tighter integration of the engineering disciplines to provide this performance. This convergence of engineering disciplines, as well as growing business challenges such as shorter time to market, strict safety requirements, higher product quality and stricter regulatory compliance increase the need for new and holistic system approaches and methodologies that support system design. These factors have led to the the engineering domain innovators to modeling, abstraction and multi-disciplinary analysis techniques during the design, and the increasing importance of model-based methodologies for product development.

Model Based System Engineering (MBSE ) formalizes the application of systems engineering through the development and use of a unified, and consistent models of a product that persists throughout the system life cycle. It is often contrasted with a Document Based Systems Engineering (DBSE), which is characterized by system design information captured and controlled through a variety of separate and distinct document artifacts that must be aligned and reconciled via manual processes. While models might be used in a DBSE approach, they are mostly standalone and not linked or connected via formal point-to-point relationships. Within organizations, system engineering teams have traditionally relied on documents—hard copies or electronic files—to coordinate system information between stakeholders (users, designers, testers, and suppliers). In the MBSE approach, a unified system model includes information about the specification,design, analysis, and verification of the system and its elements including their requirements, structure, behavior, and performance, and physical characteristics. MBSE helps to ensure a more complete, consistent and traceable system design, while at the same time enabling communication, and reuse of the system information.

Central to MBSE is the notion of a ‘model’. While we provide a formal definition for this term (see section 2.1) we can think about a ‘model’ as a representation of something using a modeling language that is well understood by the model creator and the model consumer. MBSE aims for cohesion and integration of models that support stakeholder information through the entire system lifecycle, and includes the model creation, modification, refinement, analysis, release, management and  archival. Each model may represent different facets of the system, such as the system architecture, geometric design, and various analytical perspectives such as performance or reliability. The different types of models represent important facets of the system being developed which should collectively represent the best understanding of the system at a given point in time. Systems engineering focuses on ensuring that all these different facets of a system are addressed to meet the stakeholder needs.

Model Lifecycle Management (MLM) involves the synchronization of the modeling information over time to ensure a consistent representation of the system being modeled. The MLM challenges are multi dimensional. MLM must account for different types of models being developed by different users that are often geographically distributed, and using different tools. The models are being updated by different users at different times. The tool revision may also change over time. In addition, other information that results from the model, such as analysis results and model queries must be synchronized with the models that produced them. In addition to maintaining consistency of all this information at a snapshot in time, the revision history (including what changed and why) must also be retained in order to fully understand and validate the design information. Finally, model management must account for models of product families and system variants, where substantial commonality combines with unique features to satisfy different customers and different requirements.

Figure 1: A Representative Model Management Concept

Figure 1 is an illustration of a typical MLM concept. The ‘system of interest’ 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.

The paper is organized as follows: Section 2 provides a scope and comprehensive definitions for the main vocabulary used in this paper and in the Model Management community. Section 3 provides a list of requirements and use cases for effective Model Lifecycle Management, while section 4 highlights some of the current practices for Model Lifecycle Management and compares it with  adjacent artifact management approaches such as Source Code Management (SCM) and Product Lifecycle Management (PLM). Finally, section 5 provides a suggested starting roadmap for the MBSE Model Management community.

2. Definition and Scope of Model Management

2.1 Definitions and Scope

The glossary of the INCOSE Systems Engineering Body of Knowledge (SEBoK) is the main source for systems engineering terms used throughout this document. The source for terms relating to artifacts and annotations is the Dublin Core Metadata Initiative (DCMI) ontology.

 

Let us start with the most basic concept, a Model:

A model is an abstraction of something meaningful and relevant to the model stakeholder. In the context of Model Based Systems Engineering, a model that represents a system and its environment is of particular importance to the system engineer who must analyze, specify, design, and verify systems, as well as share information with other stakeholders [SEBoK].

A variety of system models are used to represent different types of systems and different facets of systems such as its geometry, functions, and performance. Any specific model is described in a modeling language that has clear and well-defined representation rules, or abstract syntax and semantics.. All models used throughout a systems life cycle to represent the system may be considered within the scope of MLM.  For example, a free text requirement document will not be in scope, while a SysML model defining a system safety requirement is.

The scope of MLM includes formal models with well defined syntax and semantics such as simulation and analysis models, architecture models such as simulation and analysis models, architecture models such as SysML and AADL, and CAD/CAE models, The scope of MLM excludes informal documents where the syntax and semantics are not well defined via a modeling language, such as text documents, visio drawings, powerpoint slides, and other less formal descriptions of a system, unless the information is derived directly from a more formal model, such as the result of a model query or model execution. This scope may change over time, but it was felt by the authors that this is a reasonable starting point.

A specific and important model in the context of MBSE is the System Model:

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, CAE, Analysis etc. that describe various aspects of the system and its sub-systems. 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 wide variety of engineering methods, computer models, and software tools and databases are used throughout the lifecycle of a complex system, such as a satellite or an automobile. During the early phases of system development, system engineers develop requirements, concept sketches, block diagrams, flow charts, back-of-the-envelope calculations such as mass and cost roll-ups and performance parameter estimates, and architectural trade-off models. As the system definition matures, the focus shifts to developing high-fidelity design (structural and functional), analyses, and optimization models of various subsystems and components. This includes, but is not limited to, 3D geometric models of parts and assemblies (CAD), finite element analysis and computational fluid dynamics model to compute physics-based behavior, discrete event simulation models, and complex control algorithms. Although these models are developed by different teams, software tools, methodologies/workflows, and at different stages in the system lifecycle, they all represent different aspects of the same system.

[refer to IBM def ]

It is not the goal of this paper to come up with a common way to describe all models.However, in order to provide common definitions for MLM, a  generic model structure” is proposed as shown in Figure 2, using the UML notation.

A Model consists of one or more Model Elements. A Model Element may consist of other Model Elements, in which it becomes a Model Element Container . Model elements can relate to each other. These allowable relationships are specified by the modeling language abstract syntax.

Fig 2 - UML meta-model for generic model structure representation


For example, all SysML Model Elements [#REF] are part of a SysML Model, while some SysML Model Elements ( such as Package and Blocks) can also be a Model Element Container.A SysML Package is a Model Element Container that contains Blocks that are also Model Elements. Blocks can be related to other Blocks through associations, generalizations, etc. A Simulink Model is constructed of Simulink blocks ( basic Model Element) that can also contain additional Simulink blocks ( and serve as Model Element Container) . While this simplified model structure may not represent all possible model structures, it. aid in understanding the problem and specifying the MLM requirements described in Section 3.

During the model lifecycle, the models and model elements are being created, read, updated and deleted over time. A Model as well as any Model Element can be part of a Model Configuration Item:

A Model Configuration Item is a logical part of the model that is maintained in a controlled fashion, i.e. have a trackable revision history.. A Model Configuration Item can be defined in different granularities, from a an individual fine grained Model Element, a set of model elements, to the entire Model.  An increment update to an entire Model MCI is often called a Model baseline.

Model Configuration Items are managed to maintain the integrity of the models. The granularity of the MCI as well as the organization of the MCI’s are an important decision for MLM .The organization is often influenced by the organization of the teams creating the model.  Good organization of the model can  minimize resource conflicts and the need for complicated merging of changes.

The following configuration management terms also apply to model lifecycle management:

Version – A version is a state associated with the lifetime of a Model Configuration Item at a given point in time. Versions can be managed by logical time index (most common use) or by other unique identifier that can distinctly differentiate between two versions.

Variant model – A variant model represents a model of a variant of the system being modeled. As opposed to Version that represent a change in state, a variant is usually used to reflect a change of a Model Configuration Item for a given context. Variants reflect a change in a parameter of Model Configuration Item , such as an automobile with an automatic or manual transmission or a SmartPhone for North America or Europe.

Configuration - A configuration is a set of Model Configuration Items with their associated Versions and Variants. Within a specific Configuration, every Model Configuration Item has a single and unique Version/Variant.

Baseline- a Baseline is an immutable Configuration. A Baseline uniquely defines an “unchanged over time” set of Model Configuration Items with its associated versions and variants. Model Baselines are often used to freeze Model Configuration Items at critical points in the model development life cycle.

The following terms relate to the capabilities used to create, edit, and store Models, also known as Model CRUD functionality :

Modeling tool is a software application that is used to produce a model, and is part of a systems development environment that allow user to create, update, read and delete a model using its model language and by enforcing the model abstract syntax and semantics.

Model Repository is the logical location and/or physical storage space of the Model and its Model Elements. It is considered to be common that different disciplines using different modeling languages and modeling tools store them in different Model Repositories.(ie. file-base vs database)

Metadata is the information about the model, and may include information about who created or modified the model or model element, what was changed, when and why it was changed, as well as information about how the model is used in particular contexts.

Building on these terms, we can provide a  comprehensive definition of Model Lifecycle Management:

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.

A Model Lifecyle Management System (MLMS) is a set of elements that implement a model lifecycle management process, and may include people, hardware, software, data, and procedures. 

2.2 – MLM and Related Configuration Management Approaches

Through its governance process, Model Lifecycle Management Systems need to address multiple aspects of controls and functionality. MLM solutions can gain and adopt current practices from adjacent management domains that have proven to be both robust and extremely valuable in its specific domains. This section provides a brief overview of these domains and practices as a basis for comparison with MLM systems. Section 3 extends these characterization and provides further analysis of MLM solutions’ requirements and use cases.

2.3.1 – Source Code Management ( SCM)

In Application Lifecycle Management ( ALM), Source Code Management (SCM) systems provide version and revision control of program source code and other text files. SCM systems are realized by tools that track the development of a source file to prevent it from being altered by more than one person at a time. It is commonly used for projects where multiple source files are used or where multiple people are working with the same source files. The most common pattern of use of SCM system is “Branch and Merge”. When it is necessary to develop two versions of the software concurrently (for instance, where one version is used for testing, and the other version is where new features are worked on), a “branch” is created and allows users to work on independent “source code streams”. When the first change is made after a branch, a new revision is created. Each revision is associated with a timestamp and/or revision number and the person making the change. Revisions can be compared, restored, and merged - a process that combines two or more source files from different branches back into a single source file.

In comparison to MLM, SCM systems are dealing with files as their sole configuration items, while MLM systems can and should support different Model Configuration Item granularities and their relationships. SCM is a well established practice, and users of models in MBSE projects will expect similar functionality from their MLM system, especially when it comes to the Branch and Merge functions. The main challenge will be to support such functionality beyond “ difference and compare” utilities on the text file level and to generalize this functionality to any Model Configuration Item ( such as Model, Model Element Container or Model element).

2.3.2 – Product Lifecycle Management (PLM)/ Product Data Management (PDM)

As computer-aided everything became pervasive, the problems of keeping up with the many models in product development lead to product data management systems (PDM) to manage Mechanical CAD, Manufacturing, Analysis, and other models. Typically these are associated with a structure of Bill of Materials (BOM) which includes version and release management. As products have begun to cross domain/design boundaries the PDM systems have morphed into Product Lifecycle Management (PLM) systems to include all possible information about the product’s lifecycle (not just a design/CAD model) from initial needs, requirements, down through purchasing, suppliers, manufacturing, and even warranty and inservice information—providing as it’s goal the single source for all product information. PLM’s perspective on model management is merely extending it’s philosophy to include all types of models associated with the product—cost, reliability, behaviors, and more can all be associated with the BOM structure—bringing all models under control with the rest of the product information does synchronize models at a more granular level than is being addressed by MLM.

2.3.3 – Enterprise Content Management (ECM)

Enterprise Content Management (ECM) refers to the business management processes and tools required to manage all unstructured operational information created in the daily operation of any business. Business data such as electronic or paper operations documents and business forms, email messages or text messages have lifecycles and must be managed throughout those lifecycles in support of a business’s operational needs. While ECM tool sets may include a Product Lifecycle Management system, management of models and their associative data are governed by configuration and data management processes created uniquely for the product in development.

Most of ECM considers the “document artifact” as the main configurable item. The “document artifact” is considered as a single resource that contains unstructured data that is not further analyzed by the ECM system. While basic revision control in MLM could be similar to ECM systems, MLM systems need to support a larger range of configuration item granularity.

2.3.4 – Data Management

Data management is a process focused on ensuring the integrity of data generated for each operational area of a business and is a major part of the basic capabilities of Database Management Systems ( DBMS). Data management teams work concurrently with other management teams at the enterprise and project levels to define appropriate control processes for identified data sets.

MLM systems should be able to leverage current Data Management practices. Data from each phase of model generation may be developed in independent databases or a single consolidated database operated as a collaborative workspace for remotely located teams of authors in independent enterprises. Models and supporting data should be identified with the level of control required according to the Configuration and Data Management plans governing the project. Data managers will continually oversee data security, assign access controls as defined by the identified project lifecycle controls, and ensure data integrity throughout the projected retention period of the completed data sets.

3. Model Lifecycle Management Requirements and Use Cases

As was discussed in section 2, the scope of MLM can encompass a broad range of models and artifacts. This section is intended to provide the foundation for the requirement for a MLM system. It is expected that specific implementation of an MLM system may address those requirements that are relevant to their scope.

3.1 MLM Functional Requirements [move to appendix, add summary here ]

  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 (MCI).
  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. Inputs required to stimulate the models .
  4. Artifacts that are generated 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.
  1. The MLMS shall not modify the model content (excluding its metadata).
  2. 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:
  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
  1. The MLMS shall provide services to identify different versions of an MCI and related artifacts, and maintain a history of the versions.
  2. The MLMS shall provide services to identify different variations of an MCI and related artifacts.
  3. The MLMS shall maintain a lineage of MCI variations (e.g., their source and dependencies).
  4. 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).
  5. 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
  1. 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.
  1. 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
  1. 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.
  2. The MLMS shall provide services to assess the impact of changes in tool versions on an MCI, collection of MCI’s, or models.
  3. 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.
  4. 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
  5. Once models are configured and executed, the MLMS shall support the identification, analysis and storage of the analysis results within the MLMS boundaries.
  6. The MLMS systems should provide analysis result visualization and summary information.
  7. Search and Navigation:
  1. The MLMS should allow a user to search for Model Elements
  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).

3.2 Indicative Use Cases

A set of representative use cases are provided here to complement the requirements in the previous subsection.

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

4. Current Practices

With the growing importance of Model Based System engineering, enterprises are looking for better ways to manage their heterogeneous modeling environments. The market is seeing growing demand for smarter MLMS, demands that results in the emergence of new technologies and approaches for Model Management. This section provides a brief overview of current and emerging directions in model management solutions, with emphasis on two important aspects of these technologies: Specifically, the model repository/storage mechanism and security model. Furthermore, this section also provides examples of product manufacturers approaches for their Model Management functions.

4.1 Model Repository Approaches

The following outlines different dimensions of storage and control as applied across industry, recognizing that any given project may have a mix of approaches, which may not be followed in an identical fashion across the multiple projects in work by a given enterprise. Moreover, it is important to notice that some of these approaches differentiate between physical and logical repositories as follows:

Physical Repository: A Physical Model Repository is a concrete location when the model artifact are being stored. It is a representation of the physical storage place where the digital representation of Model and Model Elements are maintained.

 

Logical Repository: A logical model repository is the virtual location where model can be accessed. It is the location in which model are maintained from a MLMS user perspective. Different physical repositories that are used to store Models and Models Elements can be mapped to single logical repository, and multiple logical repositories can be mapped to a single physical repository. The association between physical and logical repositories is also called mapping.

Below are the three current approaches for model management repositories:

  1. Multiple Local Repository Approach - This is the default and most common approach in organizations for model management. In this approach team members in a single team or teams within a group/organization use file systems on their individual computers or shared drives to store models that they develop. In many cases, the logical and physical repositories are the same, and are part of local storage area.

    Often, there is no formal version control where the history of models can be tracked except for identifying changes in the timestamp on the model files; where formal version control is applied, the execution may be a highly manual process and subject to incomplete adherence. Sharing of models within and across teams is achieved by file transfers via emails or shared drives. Notification of updates to constituent models may be ad hoc or non-existent. There is limited to no tracking of design models to analysis models or to corresponding analysis results.

    The multiple local repository approach may be combined with the other approaches for portions of the system models that have not been considered significant to the model management. For example, the design model may be fully controlled through a multiple version-controlled model repository, yet which may not encompass the analysis model (or more commonly the model analysis results).

  1. Single Version-controlled Model Repository Approach - In this approach, a team or organization selects a single repository with formal version control (ability to track model history) to manage all of the different types of models - Requirment, architecture, CAD, CAE, software, part libraries and more. THis implies a single physical model repository that might be mapped into multiple logicla repositories serving multiple team, projects or engineering domains.

    In most modern enterprises, this approach is not realistic due to the involvement of multi-disciplinary engineering artifact in the product development. Each repository type is often designed to manage specific categories of models - PLM system for CAD, CAE, and BOM; SCM systems for software code; Databases for large collections of instance data; ERP systems for supply chain information. D    ue to this complexity, consolidating all of this information into a single location is considered to be hard-to-impossible.

  1. Multiple Version-controlled Model Repository Approach - This approach provides a better mechanism for model management than the single version-controlled repository approach. It allows different engineering teams to select the best tools and repositories suited for the types of models they are managing, e.g. a PLM system for CAD,CAE,BOM; SCM system for software code; and databases for libraries. Each repository provides formal version control. Most organizations have multiple version-controlled repositories.

While the management of individual system model is easier with this approach, the challenge of model synchronization, notification and traceability is becoming harder. As models are being manages independently, technology that will allow linking, tracing, monitoring and reporting on multiple distributed model resources is required. Some of the new promising technical directions are being discussed in Section 5 as part of the Emerging MLMS Technologies chapter.

4.2 Governance and Security of Models

Many product development environments require strict security considerations to protect classified, proprietary and other corporate data. While MLMS will typically resides within the enterprise intranet that is protected with the appropriate Authorization/Authentication mechanism ( e.g. LDAP) , this is usually not sufficient for effective MLM governance. MLMS needs to manage security and access rights in different level of granularity, and therefore requires further mechanism beyond the enterprise intranet security model.

When analyzing current MLMS, these are the current governance and security models observed:

  1. None, A Single User Owns All Rights and Content - For small projects of short duration this may be acceptable, but otherwise the single owner becomes a bottleneck to the update and management of the constituent models or model configuration items.

  1. OS Authentication, A Multi-User OS restricts Access but Content is Non-Attributable. For small and static teams this may be acceptable if procedural model governance mechanisms are established and followed, but otherwise the incomplete tracking of change invariably lead to the desire to question the rationale for a change, or some other query of the change author is needed that can not be accomplished. Absence of individually assigned access controls introduces challenges to the information assurance in the situation of changing team composition.

  1. LDAP, An External Server manages Users and Access but Content is Non-Attributable - this approach is only marginally better than the prior alternative, inasmuch as it provides a better mechanism to limit access to authorized users. However, the approach still requires procedural model governance mechanisms.

  1. Change-Managed Content, A CM system tracks who made commits but atomic modifications are Non-Attributable - this approach improves on the prior methods by virtue of greater granularity of records of change of the model configuration items, and is essential for large multidisciplinary teams that change over time periods that are considered short with respect to the product lifecycle.

  1. Authenticated, Role-Based-Access with Atomic-Level Attributability - Atomic-level access control, change control and attribution enable the most accurate and trackable Model management system that allow a complete security model in different level of model element granularities. This is considered to be the most advanced MLMS security model and very few current system support it in practice.

4.3 A Sampling of Approaches and Challenges in Various Industrial Settings

This section provides three current MLM examples from organizations that are applying MBSE techniques in their product development lifecycle.

4.3.1 Manufacturers of Large, Complex Consumer Product Lines with Significant Optional Variability and Software Driven Features (“Mass Customizable” Mechatronic Products)

In design and construction of complex product lines, system level models are becoming the “glue” that holds the software and hardware design artifacts together and provides the basis for the definition of the product line. Individual products are more quickly designed and constructed from patterns that are composed of model elements and connections with variation settings, allowing them to meet a range of requirements and provide many “levels” of capability to individual products built from that product line. Models are used to describe the product lines themselves, their possible variation dimensions, the requirements they can satisfy and the rules governing their instantiation. Because the number of possible individual buildable product configurations can be huge, analysis of the models is increasingly important for verification. Deriving the correct configuration of all the models to perform large scale simulation of a particular individual variant, at a particular effective point during the life of the entire product line, is difficult without strong model management capabilities. Manual model variant configuration and effectivity methods have hit practical limits; by the time the analyst can get the models configured to do the simulation the design has already changed.

Increasingly, for building the software and hardware parts of these products the models are transformed directly into the actual product components through autocode generation or model driven manufacturing systems. Since the models must comprehend many dimensions of variability, including option based variants, time-based, serialized or lot effectivities, model management systems must support these capabilities. In today’s practice, most Product Lifecycle Management (PLM) systems contain these capabilities, but their integrations to modeling tools are limited, mainly due to lack of standards and defined modeling language support for those concepts. In the rare cases where models are used to handle this complex variability they have been integrated into PLM systems with significant effort and custom code.

Application Lifecycle Management (ALM) systems are beginning to gain product line capabilities, but take a software centered view on the problem that does not always match the hardware or system design approach. The modeling of the mechanical Computer Aided Design (CAD) elements is supported in these variation dimensions better than the software or systems level models, owing to the history of PLM systems predecessors, the Product Data Management (PDM) systems that evolved to handle the CAD data in complex variable assemblies.

4.3.2 Manufacturers of Large, Complex Defense System of Systems and Mission Systems Integration

A major industry challenge we are facing today in integrating modeling tools is in the choice of investment. In order to make a good modeling investment decision, it’s important to accurately forecast future capability and future cost. As standards become more comprehensive and more widely accepted, industry members will be able to increase investment based on increased confidence of future usefulness. Standards supporting protection of intellectual property will help address the challenge of developing an agile environment with suppliers and other partners in a business environment where protection of intellectual property is important.

The second important aspect of MLM adoption is collaboration. Collaboration depends on some level of standardization and the more standardization, the more capability exists for collaboration. For example, internal standards on modeling practices, model schemas, model quality check rules, etc., are the first step to collaborate within an organization. As standards are adopted by a company, it’s customers and supply chain, it builds capability for further collaboration of the system data. Understanding that the standards are important we must constantly evaluate the value of adopting a new standard relative to the cost of working with incomplete standards. Vendors tend to promote the standards or parts of the standards that they adopt in order to capture a larger share of the market. They are not always ready for real world deployment. Model management depends on specifying the model types that will be managed, the scope of control, and the method of governance.

4.3.3 Manufacture of Large Aerospace, Defense and Security Systems

A typical environment might include several modeling tools used to address different accepts of the System Model including, an UML or SysML tool, an analysis tool, a data management tool and other support tools such as a SCM tool, defect management tool, workflow tool and  requirement management tool.  For the creation of our System model we use a SysML modeling tool that stores the physical model as a set of files. The individual files represent a Configuration Item (CI). The granularity of the files is configurable through properties of the modeling tool. So the user can specify whether a CI’s “physical file” represents a package or a block or some other model element.  This particular modeling tool does not have an inherent version control mechanism built in but does provide an interface to various configuration management tools.  This is possible since the model repository is a set of files.  

Typically for system models we specify the CI granularity at the package level.  When developing software we can work at a lower level such as an object class. Now that we have specified the CI level, we need to determine the physical file system structure. We have the option to specify a hierarchical file system to store the physical model to reflect the package hierarchy of the logical model or a flat file system where CIs are stored in one directory regardless of the logical model’s package structure. This decision impacts the size of your namespace so it’s important. Now we organize these CIs in a way to minimize the need for concurrent checkouts which minimize the need for merging.  

Unlike software code merging where different software developers are making changes in different areas of a module, it is not obvious to the modeler how far reaching a model change can affect a CI. This makes model merging significantly more challenging. The creation of a relationship between two blocks can potentially change both blocks and their CI containers.  What appears to be a simple model change can create changes across an entire model.  Consider the creation of ports, a connector, an item flow  and their corresponding element containers.  We now specify the particular configuration management tool that we will be utilizing.  We have tried and are currently using several different SVN tools each with their own challenges.  There will be special configuration for each of these as well in order to integrate properly with our modeling tool.  We often exploit features of a tool in unconventional ways to accomplish our objectives. We have combined both creative modeling techniques with unconventional software configuration management usage in an attempt to support variant modeling and composable construction.

We may create separate packages and branches to support major modifications prior to review and acceptance.  Even for the day to day user checking out a part of the model for edit there is a certain level of understanding of the underlying physical representation of the model that is needed.  Of course we want to show full traceability to our requirements which reside in a separate requirement management tool which must stay synchronized with the content of our model. Once you start supporting variants and composable models you probably have corresponding variant and composable requirements as well that need to be coordinated. We too consider the system model as the “glue” providing consistency across the various aspects of the product definition and being able to reach across the entire lifecycle product line in support of analysis, trades, change impact, and reuse through variant and composable architectures.  There is lot of moving parts and we have not found silver bullet yet but with the advancements of standards and cooperation of industry and tool vendors, we are getting closer.

5. Model Lifecycle Management - Future Business, Technical and Research Directions

5.1 Emerging Business Challenges and Opportunities

There is a general recognition of the need for new integrations, collaborations and industry standards that will enable multiple vendors to work together towards a common goal. New roles, such as “Model Management Administrator” will emerge in these organizations. Roles that will be focusing on the lifecycle management aspect of models across the product design, development and supply chain will be implemented in toolsets. Topics like Model Intellectual Property management and abstractions will become increasingly important as companies start to collaborate using models and versus document based artifacts. MLM will require much deeper evaluation of model integrity, risk and governance.

5.2 Emerging Technologies Challenges and Opportunities

The increasing importance of MLMS will require new innovative technologies to support the shift from local, ad hoc practice into enterprise level one. The following list of promising approaches that are emerging from model management and related practices such as information management and configuration management.

Linked Lifecycle Data is a practice to apply principles of Linked Data to the artifact and data produced during a produce development lifecycle [REF].Being integral and critical part of that lifecycle, MLMS will be able to leverage these principals to allow better functionality and usability as users interact with their models.

The eXtensible Access Control Markup Language (XACML) is an access control policy language that describes access requests according to the rules defined in security policies. XACML is a standard that defines the XML schema for representing the authorization and entitlement policies of a system and this standard is maintained by the OASIS open standards organization.

5.3 Research Roadmap for the INCOSE MBSE Model Management Community

MLM is a broad and wide research topic that is critical to the adoption of MBSE as mainstream Systems Engineering practice. This paper provides an overview of the MLM current opportunities, challenges, requirement and existing practices. The main opportunities and challenges are ahead of us and need to be addressed by a coordinated community based effort. Specifically, we recommend pursuit of the following research/organization directions:

Summary

References

Acknowledgements