Creating a Bridge Between Capella and System Composer or Simulink

This technical article demonstrates a one-directional approach to generate System Composer™ and Simulink^® models out of an Eclipse Capella™ system. With System Composer and Simulink, you will be able to simulate, implement, and test the detailed design of your system, which is crucial for state-of-the-art software development.

Systems Engineering

Systems engineering is a well-known approach to manage the complexity of large, interdisciplinary projects. It can include both hardware and software aspects, as well as other processes that are relevant to the overall system. In the V-Model, systems engineering is located at the top left and covers the system requirements and system-level design tasks (Figure 1).

System engineers often use model-based systems engineering tools—such as Eclipse Capella—to draw a big picture of the overall system. A good practice is to divide large systems into architectures and components—drawn as boxes that have ports—which are interconnected via interfaces. System Composer makes it easy to quickly draw the system by generating architecture views as well as other types of diagrams and postprocessing functionalities (Figure 2).

System engineers using Eclipse Capella usually follow the Arcadia method, which involves dividing the system engineering process into four layers:

• Operational: Defining stakeholder needs and environment
• System: Formalizing and consolidating system requirements
• Logical: Developing system logical architecture
• Physical: Developing system physical architecture

Within these layers, it is possible to work with classes, interfaces, modes, and a variety of different views and diagrams. Capella focuses on high-level architecture design but does not have built-in features to design, simulate, implement, and test the detailed functionality of components. One approach to include these features in systems designed with Capella is to establish a bridge between the model-based systems engineering tool and design tools like MATLAB^® and Simulink.

Use Cases

Building such a bridge can be useful if the goal is tool migration, where the system is already modeled in Capella but needs to be migrated to System Composer or Simulink. In this case, a model-to-model conversion is required only one time or very rarely.

The bridge can also be helpful in use cases that require continuous conversion. In this scenario, Capella is the master tool for systems engineering while System Composer or Simulink can be used for more detailed functional development. The model-to-model conversion happens on a regular basis and is usually integrated in a continuous integration/continuous deployment workflow. A postprocess task is required to distribute and update artifacts, such as Simulink or System Composer model files, Simulink data dictionaries, or log files.

General Workflow

As mentioned above, the Arcadia method uses different layers. It’s important to first identify the layers used to determine if there is a benefit to import information from that layer to, for example, a System Composer architecture or Simulink model. The main purpose of a Capella to Simulink or System Composer bridge is to leverage the design capabilities of these tools, as well as implement and test them. Hence, the logical architecture layer is a reasonable choice. A mapping table helps to specify what kind of import artifacts to expect—as well as typical mapping options—focusing on the logical architecture layer (Table 1).

Table 1. Capella-MathWorks mapping options in a logical architecture layer.

The source of this bridge is the Capella XML file, which is located in the Capella workspace. The XML file contains required information, such as:

• Architectures, components, and functions
• Function ports and interfaces
• Connections, requirements, and data types

The first step is to parse the XML file and to generate an internal model representation—based on an internally defined metamodel—which only contains data required for artifact generation (Figure 3). Depending on the Capella or Simulink/System Composer modeling guidelines, customization is necessary, for example:

• Applying variable naming adjustments
• Adjusting data type and interface settings
• Choosing model architecture types (model reference, subsystem reference, subsystem)

Artifacts are programmatically generated using MATLAB, Simulink, or System Composer application programming interfaces.

In the postprocessing task, the generated artifacts are distributed to existing projects or repositories. If you are following a continuous conversion process, establishing an update mechanism will be mandatory. Imagine there are interface changes in a Capella logical function and the existing artifact still uses the obsolete interface. In that case, a manual update of all changes would be very time-consuming and error prone. By leveraging predefined unique identifiers, you can automatically identify and adjust existing artifacts in case of any changes.

Import Examples

In this function example, Capella LogicalComponents map to Simulink model files (Figure 4). Simulink models are standalone components that can be referenced in other Simulink models or System Composer architectures. LogicalFunctions are converted to Simulink subsystem references. A subsystem reference behaves like a subsystem, but it is stored in a separate SLX file. This helps with team collaboration and reduces merge conflicts. The subsystem contains Simulink inports and outports with the appropriate data types as well as Ground and Terminator blocks to connect the ports.

The data types example demonstrates generation of Simulink data types such as Simulink bus objects from Capella ExchangeItems and classes (Figure 5). Class 2 has two elements with a unit8 and an enumeration type. Data types can be any allowed Simulink data type, such as floating point, Boolean, enumeration, signed and unsigned integer, or Simulink bus. Data type objects are stored in Simulink data dictionary files, which will be attached to the appropriate models. An individual data dictionary hierarchy is possible and can be customized.

Conclusion

A one-directional Capella import mechanism is possible by reading and postprocessing the existing Capella XML file. It requires detailed knowledge of Capella, as well as Simulink, System Composer, and MATLAB APIs. The generated artifacts depend on the modeling guidelines. MathWorks Consulting has worked with clients in the past to bridge Capella with Simulink and System Composer. While the exact code depends on the specific requirements of a project, MathWorks Consulting can help customize such a bridge, integrate specific work environments, as well as establish an update mechanism.