2. Motivation

2.1 Model Management as an Enabler of Model-Based Systems Engineering

 

Smarter products and Systems of Systems (SoS) are arising 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 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. Moreover, it used to be common to assume that these products were mainly the outcome of “single engineering discipline”, e.g. a car was mainly a mechanical product with minimal amount of software while the electrical power distribution of an aircraft was mainly an electrical system. This separation to “engineering silos” is being overcome as we witness the growing importance of smarter, cyber-physical systems that combine software, hardware, mechanical and electrical components, where increasing demands on system performance is driving tighter integration of those formerly disparate systems, with concomitant increases in software control.[AMIT - GIVE EXAMPLE OF INCREASING IMPORTANCE OF SW] The convergence of engineering disciplines, as well as growing business challenges such as shorter time to market, strict safety requirement and highly regulated markets increase the need for new and holistic system approaches and methodologies that support product design. These factors have led to the increasing importance of using models, abstraction and multi-disciplinary analysis techniques during the design, and the increasing importance of model-based approaches for product development.

Model Based System Engineering (MBSE) formalizes the application of systems engineering through the development and use of a unifying, evolving, and self-consistent model of the system that persists throughout the system life cycle. It is often contrasted with a Document Based Systems Engineering (DBSE, Fig A), which is characterized by system design information being captured and controlled through a variety of separate and distinct document artifacts that must be aligned and reconciled via manual processes or ad-hoc scripts.

The use of models in systems engineering is not model-based systems engineering. In the DBSE approach, models used during system development are (a) standalone and not linked to each other, or (b) connected via informal and low-fidelity point-to-point linkages as shown in Figure A. Within organizations, systems engineering teams have traditionally relied on documents—hard copies or electronic files—to co-ordinate and flow domain models and documents between stakeholders (users, designers, testers, and suppliers). In the MBSE approach, the unifying system model (also known as the Total System Model -- see figure later) includes information about the specification and design of the system and its elements including their requirements, structure, behavior, and performance, physical, qualities and other characteristics. MBSE helps to ensure a more complete, consistent and traceable system design, while at the same time enabling communication, analysis, and reuse of the system specification and design information.

Figure A

Central to MBSE is the notion of a ‘model’. While we provide more formal definition for this term in section 2.2, we can think about a ‘model’ as a representation of something using a modeling language that is well understood by the model creator and 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, and archive. Each model may represent different facets of the system, such as a system architecture, a geometric design, and various analytical perspectives. The different 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.

 

Model management involves the synchronization of the modeling information over time to ensure a consistent representation of the system being modeled. The model management challenge is highlighted in the figure below. Model management 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, the simulation and analysis results must be synchronized with the analysis and design models. 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.

 

 

This paper is intended to define the objectives and scope of model management, its current practices and issues, how model management relates to more traditional configuration and data management practices, requirements and use cases for model management, emerging practices, and a roadmap for addressing the challenges of model management. The general term used in this paper is ‘Model Lifecycle Management’. We hope that this work can be the basis to further explore and enhance this field, creating the foundations needed for dealing with large scale MBSE deployments.

 

The paper is structured as follows:

2.2 Definition and Scope of Model Management

 

Being a community of Systems Engineers of the International Council of Systems Engineering (INCOSE), the authors of this document elect to regard the Glossary of the INCOSE Systems Engineering Body of Knowledge (SEBoK) as the 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. For terms of general discourse, the authors elect to regard the Free Dictionary online as the definitive source. Our intent is to only modify a term when it does not adequately convey what is needed for this purpose.

 

 

An immediate challenge in discussing Model Lifecycle Management is to define its scope: where does MLM start and where does it end?  This section formally defines the main concepts and terms used in this paper, as a critical step to establish a common understanding of the key concepts needed for model lifecycle management. These concepts aim to establish a taxonomy for the INCOSE MBSE MLM community, and will be used in Section 3 to explain the main MLM requirements. The concepts described in Section 3 are intended to be relatively high level, generic, and implementation independent. When needed, these concepts are further refined in section 4, which includes review of current specific MLM implementation approaches.

 

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 systems facets. Any specific model is described in a modeling language that has clear and well-defined representation rules, or abstract syntax. The model abstract syntax is a set of constructs (such as the model entity types and relationship between its entities) that define a model in the corresponding modeling language.

All artifacts within the product development supply chain and operations that adhere to this definition will be considered in the “modeling scope”, while we will exclude the ones that do not. For example, a free text requirement document will not be in scope, while a SysML model defining a system safety requirement is. From this definition it is clear that the scope of MLM includes formal models with well defined syntax and semantics. This may include system models in SysML and other modeling languages, CAD/CAE models, and simulation and analysis models and their analysis results.  It is not the goal of this paper to come up with a common way to describe all models’ syntax (e.g. a common meaningful meta-model for all modeling languages).

 

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

 

Fig ?? describe the simple model structure that is used in this paper

 

[WE NEED TO ADD EXAMPLE OF 2 MODELS STRUCTURED and MAPPED TO THIS SIMPLE MODEL – SysML and MODELICA/Simulink ? ][S3]

This simplified model structure may not represent all possible model structures, but should aid in understanding the problem and specifying the MLM requirements described in section 3.

 

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 controlled fashion. MLM system will be required to keep a strict governance mechanism for any CRUD (Create, Read, Update, Delete) operation executed on the Model Configuration Item. 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,

 

MLM solution will need to keep the history of the Model Configuration Items values, as well as the various operations executed on these items. The Model Configuration Item granularity is a critical decision in MLM systems - it represents the set of Model Elements that will “behave together” over time. The Model Configuration Item granularity also affects access right policies and other locking mechanism in MLM systems that highly influence the performance of such solutions. Chapter ??? provide more details on performance considerations in MLM solutions.

During the model lifecycle, models and model elements are being created, read, updated and deleted over time. The MLM system tracks the Model Configuration Items within the managed models and enforces a governance mechanism to maintain the integrity of these items.

The following terms apply to model governance mechanisms:

 

Version – A version is a state associated with the life time of a Model Configuration Item. 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 a car with an automatic or manual transmission or a SmartPhone for North America or Europe. The relationship and lifecycle aspect of Version versus Variant are further described in section 2.2

 

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 fix 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:

 

Modeling tool is a software application that is used to produce a model, and is part of 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 store them in different Model Repositories.

 

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

Total System Model is the information about the complete system at any given stage during its lifecycle. The TSM includes the system architecture model and model-based connections between the system architecture model to the various domain-specific models, such as CAD, CAE, MATLAB/Simulink, and Mathematica, that describe various aspect of the system or its sub-systems. The TSM is a federation of models unified by the system architecture model. Since the TSM represents information about the complete system at a given point in time, all models participating in the TSM federation are versioned. Just as the individual models are refined in the TSM by different stakeholders, the overall TSM model evolves over time. During system delivery/acquisition, the TSM becomes the blueprint of the system that is used to maintain and service the system till it is decommissioned.

Now we can provide a comprehensive definition to Model Lifecycle Management:

Model Lifecycle Management (MLM) is a governance process for collaborative CRUD operations on heterogeneous models, including its supportive modeling tools and model repositories, throughout the system development lifecycle. MLM managed the lifecycle of the model through the control of its Model Configuration Items, including Versions, Variations, Configurations and Baselines of the model, simulation and analysis results, and tools that are used by multiple users that may be geographically distributed. In addition, model management must manage additional metadata about the models, tools, and analysis results including who made the change, what changes were made and why, as well as information regarding the use of the model.

 

2.3 – MLM and related configuration management approaches

2.3.1 – Source Code Management

Source Code Management (SCM) systems deal with version and revision control system 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 steams”. 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. SCM is a well established practice, and users of models in MBSE project will expect similar functionality from their MLM systems, especially when it comes to the Branch and Merge functions. The main challenge will be to support such functionality beyond “ diff and compare” 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/ Product Data Management

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 CAD, Manufacturing, Analysis, and other models.  Typically these were associated with a structure of Bill of Materials which include 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.

Putting models in PLM hung on a product structure does manage and configuration control models, but it does not provide the value of these many controlled models communicating with each other.  

2.3.3 – Enterprise Content Management/ Document Management System –

Enterprise Content Management 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 tool, management of models and their associative data are governed by Configuration and Data  Management processes created uniquely for the product in development.

2.3.4 – Data Management

Data Management is the discipline focused on ensuring the integrity of data generated for each operational area of a business enterprise, as well as the repositories for said data.  Data management teams work concurrently with other management teams at the enterprise and project levels to define appropriate control processes for identified data sets.

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.

 

 [S1]We need to call out the comparison with traditional configuration and data management practices.

 

Also, did we want include a specific section on current model management practice and the issues before we transition to the requirements.

 [AF2]I think we need to provide the “current model management practice” after we review the requirements so we can classify current approaches according to these requirements

 [S3]For SysML, we have an example if figures 5.3-5.5 in our book. We can probably make an even simpler example that stays away from any complexities of the language.

 

A Pakcage is a Model Elment  Container that contatins Blocks that are also model elements. Blocks  can realte to other Blocks through associations, beneralizations, etc.. That may be simple enough.