When a team starts using model-based system engineering (MBSE), either for the first time or for a new project, typically one of the main challenges is to identify and establish where the data will be stored and which data repository will be considered as the so-called “single source of truth”.
Having determined how to start implementing MBSE in a project and/or how to select the right tool for your needs (as covered in our previous posts), you now need to go one step further and ensure that all team members can integrate their data into the new tools smoothly. The transition towards MBSE will transform your existing processes and your team will need to rethink the workflows and consider data exchanges with other existing tools.
In this post, we summarise some of the main scenarios and needs related to data exchange in the context of MBSE, and options to support them while ensuring that your team members can still use other tools when needed.
By Paloma Maestro Redondo, System Engineer and Project Manager
Why do engineers need to exchange data?
Engineers are used to using different tools for different purposes, like simulations and calculations. In addition, each domain of expertise will use their own tools. When designing a spacecraft, for example, a mechanical engineer will not use the same tool for CAD design as a thermal engineer uses to perform thermal analysis. These tools share certain information, like the overall geometry of the system, and might even be able to process similar file formats, but they deal with different data and generate very different outputs. Other engineers might also need to be aware of their design decisions and interpret the data coming from these team members.
One of the many examples in the context of space engineering is the exchanges between the power engineer, the thermal engineer and the mission analyst, and the joint decisions that are needed. Space mission design is performed using applications that analyse the system performance in a realistic operational environment, but the power and thermal engineers also need to size their subsystems according to the design of the orbit and the satellite’s planned attitude. At the early stages of the design, tools like CDP4-COMET allow engineers to record the main data that needs to be shared and used by multiple domains to size the system. However, as the design evolves, the complexity of the data exchanges will increase.
In some cases, for example when a project involves a consortium of companies, different teams may use different tools for the same purposes. Sometimes this is simply because there are different options available, but it may also be because teams need to develop their own in-house toolset(s) to accommodate specific needs and processes.
Setting up the context for MBSE data exchanges
Depending on the project phase and the level of detail at which MBSE is implemented, each domain may generate different types of data. Some engineers might be able to input their data directly in the MBSE tools, while others will need support (and automation) to transfer the data due to its size and complexity.
When using MBSE tools, it’s important to keep in mind that we should only model elements that bring value to the design and we should always avoid overcomplicating the models. This means that, depending on the context and the stage, your models should contain only those details that are necessary to achieve the study’s goals. This approach should also help you to identify what data needs to be exchanged.
As we have explained in previous posts, at the beginning of a project it’s important to take care to select the right MBSE tool, ensuring that the new toolset is compatible with the existing systems and environment. Depending on your initial assessment of possible tools and methodologies, you can decide whether your team will still use the same tools in the later phases of a project. Then, once this is settled, you can start defining the requirements for the data exchanges at each phase.
We recommend dedicating enough time to understand the needs of each team member and to develop a solution that can be integrated with the company’s existing processes. Depending on the context, you might need to design new software solutions for the data exchanges in your projects. Underestimating these challenges can result in teams working in isolation again and being unable to exchange data.
How to exchange data: individual adapters
Whether you want to exchange a complete model or just specific data between tools, you need to ensure first that the tools are compatible – that the target tool can store the data coming from the source tool. This becomes increasingly complex when we want to provide synchronisation between the tools, and even more challenging if we need to deal with more than two tools.
Let’s look first at the scenario that involves exchanging data or complete models between two tools. If an exchange mechanism is not yet in place, we will need to define the mapping between the concepts and the data models being used by each tool. With this information, software engineers can develop an adapter that will allow you to transfer data between the tools and that can integrate some automated mechanisms to facilitate future exchanges. The adapters are either standalone applications or plugins that allow users to navigate to the correct data and select the desired data exchange mechanism.
An example of these adapters is the Digital Engineering Hub Pathfinder project that Starion completed for the European Space Agency (ESA). As a proof of concept, we developed a series of adapters to support data exchanges between CDP4-COMET and other engineering tools. For some of these adapters, development and improvements have been maintained and are operational. The open source ones can be downloaded from Starion’s GitHub repository at https://github.com/STARIONGROUP. The adapters developed in this R&D project were: Capella, SysML (for Enterprise Architect and MagicDraw), Catia, EcosimPro, MATLAB and STEP TAS.
How to exchange data: MBSE Hub
If your project needs a single repository that contains all the MBSE data, you will need to define what will be your ‘single source of truth’. This can be fulfilled by a virtualised central hub repository to which multiple tools can be connected, and that engineers will use to upload their most up-to-date data and retrieve the latest data submitted by their colleagues or even by external stakeholders.
Developing such solution isn’t straightforward. It needs to deal with the complexity of synchronising large sets of data and, depending on the project setup, any security aspects. At Starion, we’ve taken part in another ESA activity to develop a proof of concept of such ‘virtualised central hub’ and evaluate it by performing data exchanges related to different domains of expertise. The MBSE Hub, developed as part of the Model Based Engineering Hub project, has been tested in the context of the operations, RAMS (reliability, availability, maintainability and safety) and thermal engineering domains, the latter being part of another activity called Digitalisation of Thermal Engineering Processes (DOTEP).
For this kind of solution, we need to provide semantic interoperability for all the exchanges and stakeholders. So in this case, we weren’t dealing just with a single mapping mechanism but with multiple ones between the data models of each tool and the one being used by the central repository. In the MBSE Hub, we developed an implementation of the Space System Ontology (OSMoSE – Space System Ontology), an ESA initiative with the goal of enabling semantic interoperability and providing a shared understanding across multiple stakeholders for the European space industry.
You can find out more about these projects in our MBSE brochure.
In summary
There are several alternative ways to facilitate the exchange of model data. We recommend that you choose a strategy based on your team’s needs and that you request support from your software engineering teams to help assess the complexity of your data exchanges.
If you are already using MBSE in your work, look for the gaps between the tools that your team members use and any new data exchanges required to facilitate the design process and improve communication.
If it’s your first time implementing MBSE, we recommend you take a close look at the needs of both your project(s) and team(s) and identify the data that will need to be exchanged across tools. Taking time now to assess the effort and workload that this requires will avoid unnecessary reworking or additional costs in the later phases.
At Starion, we specialise in helping organisations to navigate the complexities of MBSE adoption and provide solutions for the exchange of data across platforms and tools. Reach out for support in your daily activities or to get started!
Find out more
Follow Starion Group on LinkedIn to find out when new posts are published.
Find out more about MBSE at Starion.
