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.
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:
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.
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 (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
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:
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:
→ Proprietary tool-to-tool approachFor 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).
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:
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.
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.
Visualizing cross-domain traceability in SECollab - The MBSE modeler sees the link in the MBSE tool context (and vice versa)
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.
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.
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.
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
The 3rd 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 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 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 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.
|
SodiusWillert SECollab supports cross lifecycle analysis by publishing lifecycle data into its graph database and applying queries to visualize various views of the lifecycle graph, such as coverage matrices and metric charts. It also allows us to visualize the impact of design elements by rendering a relationship graph that originates from the design element to the necessary depth. |
Requirements coverage analysis and traceability across SysML and IBM DOORS in SECollab
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.
Illustration of a digital review of a SysML diagram in SECollab
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.
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.
Here are several methods for implementing global configurations.
OSLC global configurations specification is the only open specification that addresses the digital thread configuration challenge in an open and robust manner.
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.