MBSE & The Digital Thread: Optimization Of The Engineering Lifecycle

The adoption of Model-Based Systems Engineering (MBSE) is central to contemporary system engineering practice. Recognizing the inherent complexity of system engineering, which involves numerous practices and interfaces with other engineering disciplines, the integration and interoperability of MBSE activities with other lifecycle phases are paramount for realizing its full advantages. This article discusses the various aspects of MBSE interoperability, along with the technologies that support its implementation.

TABLE OF CONTENTS

MBSE and the Digital Thread

Key Integration Patterns

1. Cross-domain (tool) traceability links
2. Data exchange and synchronization
3. Cross-domain analysis and reporting
4. Cross-domain review

The Challenge Of Configuration Management

MBSE and the Digital Thread

Digital thread is a foundational infrastructure to enable a digital product lifecycle, and more specifically, an engineering lifecycle. The objective of the digital thread is to facilitate data connectivity and mobility across engineering repositories and tools in a systematic way, in addition to supporting cross-lifecycle views and analytics. Complex systems engineering includes a myriad of tools and disciplines that complement MBSE tools: requirements management, change and process management, product data tools (a.k.a PLM), testing tools, and disciplinary design tools such as electronic (E/E) and mechanical design, to name a few.  Since MBSE tools specify all aspects of the system, they need effective upstream and downstream interoperability with most of their companion engineering tools.  

For example:

Requirements tools

In the presence of MBSE tools, requirements tools are used to specify in a textual format stakeholder needs and requirements. MBSE tools typically refine the requirements into detailed functional and architectural specifications. Hence, establishing traceability across MBSE elements and requirements objects is essential to meet almost any engineering practice. A special consideration is the capability of MBSE tools to also represent requirement objects, as supported by SysML. That potentially forms a pattern of data mirroring, where the authoritative source of requirements is the requirement tool, but they need to be synchronized with the SysML model in the MBSE tool.

Maintaining the mirroring depends on process choices. If not, you can skip mirroring and use traceability links from the SysML tool to the requirements tool. This dichotomy faces almost every organization that deploys MBSE, where most tend to go with the mirroring approach.      

Disciplinary design tools

There is clearly a tight relationship between MBSE and discipline-specific design tools, such as electrical and electronics (E/E) design, mechanical design, and software architecture tools. MBSE models specify the architecture and behavior of system components, which are later realized by the disciplines. Therefore, it is essential that the digital thread supports consistency across the MBSE specification and the discipline implementation. This can be realized by traceability and data exchange patterns in a complementary way. For example, traceability links from MBSE elements to the E/E design help track the impact of change across. Data exchange may support automated synchronization of “upstream” MBSE design with “downstream” E/E design by applying proper transformations.

Change management tools

Change management (CM) tools such as Atlassian Jira play an important role in the automation of DevOps patterns and managing agile planning and tracking. As recently stated by the DoD DEMS director, “digital engineering is about adopting a CI/CD approach to the entire systems engineering process”^[1]. In fact, MBSE models are also artifacts that relate to planning and tracking items. The most useful pattern is to enable traceability across plan items and model elements, relating design tasks to MBSE design elements or tracking design issues with CM tickets.

^[1] Daniel Hettema - Digital Engineering, Modeling, and Simulation Director, OMG SysML V2 day, Reston, VA

 MBSE at the center of the engineering process

Key integration patterns

The challenge at hand now is how to realize the abovementioned digital thread patterns, between MBSE tools and the other ecosystem tools. Just to recap, we mentioned 4 key patterns that are essentially core patterns of any digital thread backbone:

1. Cross-domain (tool) traceability links
2. Data exchange and synchronization
3. Cross-domain analysis and reporting
4. Cross-domain review

In general, all those patterns involve the interoperability of MBSE and ecosystem tools. When approaching such a challenge, there are two common approaches to solving it:

For example, when exchanging requirements data between a requirements tool like IBM DOORS and a modeling tool like IBM Rhapsody or MagicDraw, a synchronization script can utilize the specific APIs of DOORS and MagicDraw to perform the synchronization.

The idea of having API dependencies has always been considered weaker and less scalable than modular open systems approaches. In case of requirements synchronization, there is a standard exchange format called ReqIF, which most requirement tools support. That allows the MBSE tools to import and export requirements to/from requirement tools in a standard way.

Another example relates to establishing traceability relationships – this can be done in a proprietary way by using the requirements tool API, or using an open link data standard like Open Services for Lifecycle Collaboration (OSLC).

1. Cross-domain (tool) Traceability Links

The traceability pattern requires setting links across lifecycle objects within domain tools. A prominent example is traceability from MBSE model objects to requirement objects.

There are two common approaches to do this:

A federated linked data approach

Such federated architecture is supported by the OSLC standard, which specifies an HTTP REST API to obtain selection dialogs, object representations based on URIs, modification, and creation of objects and links. OSLC also offers a draft specification for using a link discovery service. This service helps find incoming links. Additionally, there’s a draft link validity service. It tracks whether a link is still valid after changes to its endpoint objects. OSLC APIs come from two main sources. First, some domain tool providers, like IBM ELM or Siemens Polarion, support them directly. Second, third-party vendors, such as SodiusWillert, offer OSLC adapters for tools like Atlassian Jira.    

➡️ Find out more about SodiusWillert's OSLC and Linked Data solutions

A central link management service

A central service that indexes lifecycle objects from domain providers (tools), creates and stores links across them. Typically, such tools will also provide additional capabilities such as visualizing and analyzing the digital thread. Instances of such tools are Intercax Syndea and SodiusWillert SECollab. When links are stored in another tool, by default, they may not be visible in the tool that owns the object.

For example, if a link from an MBSE object to a requirement is stored in a link management tool, it needs to be discovered by the requirements tool. This can be implemented by applying a query on the companion tool or utilizing a central discovery service such as the one proposed for the OSLC standard.

➡️ Find out more about SodiusWillert's SECollab

Visualizing cross-domain traceability in SECollab - The MBSE modeler sees the link in the MBSE tool context (and vice versa)

2. Data Exchange, Synchronization, and Transformation

Data Exchange

As mentioned earlier, data exchange between MBSE and other lifecycle tools is necessary and supports several use cases. For example, it can mirror stakeholder requirements from a requirements tool to an MBSE SysML view. It can also help sync MBSE architecture with downstream E/E tools or BOMs in a PLM tool. It is important to note that such exchanges may typically require a transformation mapping that maps MBSE domain representations to those of the companion tool. This is key to ensure consistency across the MBSE model and either upstream requirement tools or downstream disciplinary tools. Such automation is essential to realize a “CI/CD” digital engineering approach.

Point-to-point connectors

There are also point-to-point proprietary approaches, using proprietary formats and synchronization scripts, which require ongoing maintenance and are expensive to scale. As an example, the SodiusWillert family of plug-ins Publisher enables exchange of UML/SysML data across the common MBSE SysML tools: IBM Rhapsody, Dassault MagicDraw, and SparxEA by maintaining special adapters and transformations for each tool utilizing their proprietary APIs. Publisher is useful to automate digital thread scenarios where, for example, the system's model is developed in one tool and the software architecture and code generation are implemented by another tool, to maintain synchronization of relevant system architecture data with software architecture data.

➡️ Learn more about our complete Publisher suite of plug-ins: 

• Cameo Model Importer for IBM Rhapsody
• IBM Rhapsody to Cameo Systems Modeler
• IBM Rational Software Architect to Cameo Systems Modeler
• UNICOM System Architect to Cameo Systems Modeler  
• SPARX Enterprise Architect to Cameo Systems Modeler

Open standards-based exchanges

An alternative approach is to rely on domain standards, such as ReqIF, to represent requirements data. For example, SodiusWillert ReqExchanger leverages ReqIF to import data from requirement tools to IBM Rhapsody. Unfortunately, there are no good implementations of the UML/XMI MBSE exchange standard, due to various issues we will not discuss here. In addition, MBSE tools at present do not have standard APIs. This means that for MBSE tools, there are always tool-specific adapters to import and export data.

➡️ Find out more about SodiusWillert ReqExchanger

As of writing this article, the new SysML v2 standard is about to be finally adopted by the OMG, introducing a standard RESTful (HTTP) API and data representation, either in JSON or RDF. This will considerably accelerate the integration of SysML V2 MBSE tools into the digital thread, as implementation of MBSE exchanges can use a single standard API. This means that disciplinary tools such as E/E design tools and PLM tools can use a common synchronization mechanism with any SysML v2 compliant tool.

Using a SysML v2 schema may facilitate a “hub and spoke” architecture where lifecycle data is represented with SysML v2 format, and lifecycle tools push and pull SysML v2 formatted data. Another approach to implement a central “hub and spoke” is to use standard RDF vocabularies such as the ones specified by the OSLC standard to represent lifecycle data in a common manner. SodiusWillert SECOllab uses RDF vocabularies to represent data from across the lifecycle. It is also worth mentioning that SysML V2 also supports RDF data representation as specified by the SysML v2 OSLC vocabulary

3. Cross-Domain Analysis and Reporting

The 3^rd important digital thread use case is analyzing data and relationships across all lifecycle providers. Some common examples are coverage and impact analysis, and visualizing lifecycle metrics.

Coverage Analysis

Coverage analysis is used to analyze how realizations across the engineering chain cover higher-level specifications. For example, how does MBSE functional analysis cover system requirements, or how does physical design in a disciplinary domain cover an MBSE logical design. Such coverage analysis helps to measure the completeness of the engineering process across lifecycle domains.

Impact Analysis

Impact analysis helps analyze the impact of a change to a specific design element, in terms of how it propagates and impacts other elements across the lifecycle. Such analysis supports implementing design changes to make sure all impacted designs remain consistent, and to assess the cost and risk of making such a change at a certain stage of development.

Lifecycle Reporting

Another set of use cases is lifecycle reporting. For example, various safety-critical practices (e.g., DO178C) require detailed traceability reports to show how software requirements are traced to system requirements. Metric reports are important to measure compliance and progress. For example, what percentage of the system requirements have already been realized by a logical design.

Implementing lifecycle analysis and reporting

Implementing cross-domain reporting and analysis requires a mechanism to query data across the lifecycle. A common way to achieve this is to manage a lifecycle graph that represents the essential lifecycle objects and their relationships.

Since lifecycle data is federated across various MBSE and other companion tools, it needs to be indexed into the lifecycle graph to perform the analysis. Once the lifecycle data is indexed into the graph, the various use cases mentioned earlier are implemented by applying graph queries and visualizing the results. Such a graph may be implemented using various technologies, such as dedicated graph databases, RDF repositories, or even relational databases. The indexing of data may be performed by periodic data publishing from the MBSE and the companion tools, or by using change protocols such as OSLC TRS.

Requirements coverage analysis and traceability across SysML and IBM DOORS in SECollab

4. Cross-Domain Review And Approval

Modern engineering processes use a continuous CI/CD pattern that involves applying continuous requirements and design changes that need to be reviewed and approved. Each such change may involve engineering artifacts across multiple domains, such as requirements, system models, SW models, and other disciplinary models. Reviews are conducted by various stakeholders who need to easily view the changes and provide feedback.

• A central review and approval service would organize all the related review artifacts from the various domain tools, so they are easily accessible for inspection without the need to access each one of the authoring tools separately. Such a service would also rely on indexed data, which includes diagram images and graphical visualizations for the reviewers. For example, a requirement change would include the actual requirement module from DOORS and the related SysML diagrams that show the respective design changes. Such a review may further span to include test artifacts and SW architectural diagrams from a UML code generation tool.

• A review service would also orchestrate the review in terms of which reviewers need to review what artifacts and would collect their comments and annotations. The service would also track the review progress up to its conclusion by the reviewers. SodiusWillert SECollab implements such lifecycle review processes based on its lifecycle graph database.

Illustration of a digital review of a SysML diagram in SECollab

The Challenge Of Configuration Management

One of the challenges in such digital thread use cases is that lifecycle data is versioned by authoritative tools. Each domain tool, and specifically an MBSE tool, maintains various baselines and versions of the design data. Hence, each one of the digital thread scenarios is performed in a context that is not only a set of specific designs, but also what configurations or baseline of that design. For example, if we look at traceability links from a SysML design to a set of requirements, that traceability might look different if we choose a different baseline of the requirements and the design. The same holds when we look at data exchange scenarios, or analysis and review scenarios.

Therefore, digital thread use cases shall specify an overall configuration of their respective artifacts.

Global configurations

To manage a “digital thread configuration”, there needs to be a notion of a “global configuration” that specifies for each domain tool a configuration that participates in the overall global configuration in context. There might be multiple such global configurations. Once we engage in a digital thread scenario, a global configuration has to be specified.

A specification of “global configuration” is also specified by OSLC, which covers services to orchestrate digital threads. Tools like SECollab provide the capability to specify such a global configuration, and also tool suites like IBM ELM.

Implementing global configurations

• Central global configuration service: A set of global configurations (GCs) is stored in a GC server. Each GC refers to participating domain configurations (requirements, MBSE, Git, PLM, etc.).   Environments such as IBM ELM and others implement and use a GC service that is used by domain tools (Rhapsody, DOORS, Test Manager) for cross-tool interactions. SodiusWillert SECollab also supports GCs to manage all its published domain data for purposes of digital thread analysis, reporting, and review based on the OSLC configuration management specification.  
  
  
• A “project use” approach: Each tool and project specifies the configurations of each of its used projects. For example, a SysML V2 project would specify the configuration of each one of its related SysML V2 projects. The shortcoming of the “project use” method is that only applicable within a single environment, such as a set of SysML V2 projects, and it does not apply in heterogeneous environments. For example, a digital thread containing an MBSE, requirements, and source code git projects will not fit well with a “project use” approach.

OSLC global configurations specification is the only open specification that addresses the digital thread configuration challenge in an open and robust manner.

CONCLUSION

MBSE is foundational for digital engineering and needs to be integrated into a digital thread backbone. The digital thread architecture fosters traceability, data exchange, and overall analysis of the engineering process centered around the MBSE system specifications.

Some helpful standards support the modularity of the digital thread. These include SysML v2 API, model interchange, and OSLC. OSLC offers tool-independent APIs that help integrate engineering tools in a modular way. OSLC specifies modular APIs to establish cross-tool links, which may be supported natively or by OSLC adapters such as OSLC Connect. We also mentioned the need to have some centralized digital thread services, such as global configurations, reporting and analysis, as well as cross-lifecycle reviews.

Some digital thread tools, such as SECollab, bundle those services together as part of one server.

➡️ Did you find this article useful? Do you have any questions about any of the above solutions? Please, send us an email!