6 ways to link models

The V-model is often used to show how the artifacts of system development relate to each other: On the left-hand side is the chain of increasingly concrete development artifacts, from requirements to implementation. On the right-hand side are the corresponding elements of verification and validation, which link the elements on the left-hand side accordingly.

It looks quite simple and doesn't sound that difficult. It is also easy to implement as long as the tool supports such elements and links, and there are now many such tools. The problem arises when elements have to be edited in another tool. Then the question of cross-tool working arises. What now?

The following section deals with how to tackle the problem of cross-tool traceability.

Traceability must be used

Many systems engineering tools are able to link elements together. In requirements management, for example, a DOORSCreate a "module" with user requirements in order to then link individual user requirements with system requirements that have been stored in another module. DOORS also offers the option of analyzing this link: Is there at least one system requirement for each user requirement? Which system requirements are affected if a user requirement changes?

Modeling and MBSE are also used in the area of implementation: There are CAD systems such as OnShapespecial tools for electrical circuits, and nowadays, of course, software source code everywhere. But I am not aware of any tool that can handle both requirements and implementation-related models. And then there is a break in the tool chain. And this is an example with only two models. If you think about all the processes in systems engineering, then we quickly have to deal with dozens of models.

The truth about model integration: there is no one-size-fits-all solution

To say it up front: There is no one-size-fits-all solution. There are various more or less complex approaches that can be used to get to grips with this issue. But none of the approaches is without weaknesses.

1. manual care

The transition from one tool to another can be done manually, even for larger developments. Incidentally, this was also how things were done in the early days of systems engineering - there was no other way back then. It is important to have a good process so that no errors creep in during manual synchronization. This reconciliation can also be partially automated, for example by exporting and importing data via primitive formats such as CSV.

Model integration via manual maintenance requires good processes

In the case of manual maintenance, it is advisable to think about which data really needs to be exchanged and to optimize it. Examples are

• IDs can be stored in comments in the source code
• A specification can be generated as a document from a system description
• Results from a test run can be entered manually.

2. individual integrations

Nowadays, modern tools usually offer interfaces for automated integration (Application Programming Interfaces, or APIs). When selecting a new tool, it is essential to ensure that an API is available! Older tools, such as the aforementioned DOORS, often struggle with this, while modern tools, such as Jamaare designed for integration.

An API requires active design. First of all, you should define the architecture: Should a central "master tool" be created in which all links converge? Many use a requirements management tool for this. They then create dummy elements for other artifacts, such as test runs. Alternatively, you can implement a point-to-point integration that only creates links when required.

File-based integrations are also possible. The CSV format still seems to be the workhorse in many areas, but teams also always use standard formats if they exist (e.g. ReqIF for requirements).

Bidirectional integration should be avoided - these are very error-prone

Also important: Is the integration unidirectional or bidirectional? If it is not absolutely necessary, unidirectional integrations are preferable. This means that data can only be edited at one end, while at the other end the data is read-only but cannot be changed.

3. service model

The service model is comparable to individual integration, with one difference: the tools serve each other "on demand" with regard to the data they need. This is usually realized with web services, i.e. websites for machines.

Data can be offered generically, which requires appropriate customization. But slowly OSLC for this purpose. Open Services for Lifecycle Collaboration is an open technology that uses standardized specifications for certain types of data. For example, there is a specification for requirements. A requirements tool can then offer requirements via OSLC, while another tool can query them via OSLC.

4. build it yourself

Nowadays, I would think twice about developing an integrated tool chain myself. However, there are now many companies (mostly corporations) that have strategically opted for this approach. Of course, you shouldn't start from scratch, but build on a solid platform. Eclipse has been trying to establish itself here for several years. Companies such as Airbus, Thales, Bosch and Ericsson are focusing in particular on the area of system modeling.

Eclipse makes sense insofar as many elements already exist, such as RMF for requirements management or Papyrus for UML/SysML modeling. Eclipse offers another technology, the Eclipse Modeling Framework (EMF), which drastically simplifies the integration of Eclipse-based tools.

5. external traceability

There are several tools on the market that are only responsible for traceability. These tools usually have adapters for different systems. They collect all links from the sources and bring them together in a central tool. There you can analyze and often edit the data. The tool takes into account the fact that some systems already offer internal traceability, such as DOORS. Such traces created in the tool are then also displayed. An old-timer of this type is Reqtify. A modern example of external traceability is Smart Facts.

6. all-in-one solution

There are providers who promise a complete solution. This should be able to cover almost all SE activities. Examples include Siemens (Teamcenter) and Esterel (Scade). However, caution is advised here.

Firstly: "Everything" is an elastic term. Sooner or later, you will still have to integrate. Secondly, the well-known problem of many multifunctional devices applies: a lot of things work, but often not particularly well. Thirdly, you become heavily dependent on the provider. With other approaches, this dependency is at least somewhat less. This is perhaps not critical in a fast-moving development. However, if you are building a long-lasting or safety-critical system, you should carefully consider whether you want to be so closely tied to a single provider.

Conclusion

There are many ways to integrate the artifacts of system development. Unfortunately, there is no clear recommendation: the tools of different industries are simply too diverse, the requirements too different.

My recommendation is not to lose sight of the big picture first, i.e. to pursue a clear architecture. Furthermore, good processes should be ensured before investing in an integration (of any kind). If it turns out that a manual process is often carried out, you have a good candidate for an initial integration.