Interoperability Live – SysML v2 API in Action

The content of this blog post was presented with a live demo at the GfSE SysML v2 Extravaganza Workshop in October 2024. In the meantime, the technologies, SysML v2 and the modeling tools, will have developed further.
Summary
Model-Based Systems Engineering (MBSE) integrates various engineering disciplines to realize integrated systems with relevant information throughout the system’s lifecycle. The emergence of the SysML v2 API supports this integration by allowing various engineering tools to access a SysML v2 system model.
The blog post shall demonstrate this integration with mechanical engineering disciplines, lifecycle assessment, simulation, and their interaction with a system model repository.

Introduction
Given the complexity of most systems and the involvement of various subsystems, all stakeholders must share a common understanding of the overall system. Using models in systems engineering enables comprehensive support of intelligent tools, making complexity more manageable.
In the following sections, we describe a complete upstream process for easy presentation. While multiple iterations that are not directly demonstrated here might occur in practice, this gives a basic understanding of the overall possibilities.
The process is as follows:
- Creation of base architecture in SysML v2 and visualization of model content
- Extension of the base architecture with requirements, functional architecture and physical architecture, and visualization of model content
- Usage of the system model information for decisions in mechanical engineering
- Refinement of parameters in system model from mechanical engineering
- Usage of system model information for preparation of life cycle assessment (LCA)
- Application of simulation/analysis with information from the system model
The following components are part of this setup:
Component: SysML v2 Base architecture
Description: The base architecture has to be described. As this post relies on SysML v2 for the system modeling, a decent SysML v2 editor is required. With SysML v2 having both a graphical and textual notation, many editors can be used.
Solution used in the demo:
- A proprietary demo tool, together with the SysML v2 Pilot Implementation (JupyterLab) is used to push the models to a server repository.
- Intercax SysML v2 API Pilot Implementation, including a SysML v2 repository.
- Tom Sawyer SysML v2 Viewer for visualization
Component: Requirements, Functional Architecture, and Physical Architecture
Description: Many systems engineering artifacts would be supported by SysML v2 for different typical upstream processes used in the industry. The demo chooses use cases and functional architecture as defined by the FAS Method, SysML v2 requirements, and a simple physical architecture as sample artifacts. The strong inspiration for the FAS Method is based on the fact that prototype tools for their application in SysML v2 were available off-the-shelf when creating the demo. Any sufficiently elaborate SysML v2 editor could be used in this step.
Solution used in the demo:
- FAS plugin (by the Functional Architectures working group of GfSE, the German chapter of INCOSE) and some more proprietary demo tools based on the SysML v2 Pilot Implementation (JupyterLab) are used to update the models on the server repository.
- Intercax SysML v2 API Pilot Implementation, including a SysML v2 repository.
- Tom Sawyer SysML v2 Viewer for visualization
Component: Mechanical Engineering (MCAD) Tool
Description: The mechanical design is mostly done in parametric 3D editing tools.
Solution used in the demo:
- Opensource 3D modeling tool FreeCAD with a demo SysML v2 API interface developed by Fraunhofer IPK and an opensource plugin FCInfo for analysis of the design.
- A 3D model taken from Grabcad
Component: Simulation/Analysis Tool
Description: Simulation/Analysis at this level is used to support decision-making (i.e., trade studies), and they can be of different types: mass roll-up, overall availability, performance, thermal, etc.
Solution used in the demo:
- System Composer
- Matlab
- Simulink
Base Architecture
The base architecture has been defined in SysML v2 textual notation:
In theory, multiple tools would be appropriate to write the above model to the repository. In this case, it was written to the repository with a proprietary tool for the sake of the demo:

The basic architecture can then be visualized with Tom Sawyer’s SysML v2 Viewer. The model is located in the SysML v2 repository on the server sysml2.intercax.com. The viewer connects to the server and the project in order to visualize it. There is no export/import of data.
The screencast does not show much yet. The basic architecture is very simple and consists only of a part definition, “CommonDrone,” with two attributes, “powerConsumption” and “actualMass,” each of which subsets the corresponding quantity.
Requirements, Functional Architecture and Physical Architecture
The demo chooses use cases and functional architecture as defined by the FAS Method because prototype tools for its application in SysML v2 were available off the shelf when creating the demo.
During the demo, use case activities and functional groups are already modeled using the quick-and-easy graphical user interface of the mentioned prototype implementation:

After conversion to functional groups with the prototype tool’s built-in functionality, the use cases, functional groups, functional architecture, and their traceability are written to the SysML v2 repository using the SysML v2 API.
The remaining requirements and physical architecture are written with a proprietary tool that takes SysML v2 textual notation of requirements and architecture as its input to complete the picture. After writing the mentioned artifacts to the repository, the tool also establishes traceability between the functional architecture and the physical architecture:

The video below shows the workflow described above in action.
The model is still only located in one place on the server sysml2.intercax.com. Again, we connect the Tom Sawyer SysML v2 Viewer to the server and visualize the model. The following screencast shows a journey through the model and the artifacts that were previously created with the FAS tool, among others.
Mechanical Design
Based on the refined base architecture, the mechanical design of the drone is addressed. The information located at the intercax server is used to validate the conformance of the design with the requirements and to refine specific information in the system model. In this demo, the mechanical Design is done in FreeCAD Version 0.21.2 (here). It uses the FCInfo macro (here) and a panel developed by Fraunhofer IPK that accesses the SysML v2 API server.
The shown procedure is as follows:
- Request projects from SysML v2 API server and select project related to MCAD model
- Analyze relevant requirements from system model and validate with bounding box from FCInfo macro
- Validate material of “body” with maximum mass requirement
- Push mass of material body to system model
After the project has been selected the requirements are analyzed. The “height” requirement is compared against the dimensions measured for the boundingbox of the complete drone by the shown by the FreeCAD macro FCInfo. As shown in the below image the dimensions are not exceeding the requirement and the second requirement is considered.

For the second requirement the material of the drone body is selected in such a way that it has a low mass for a good mass budget. As shown in the video, the selection of aluminium as suggested in the system model is sufficient. Thus the material is not changed and the actual mass of the body is pushed back into the system model via the API. In that way further domains can build on the information.
Lifecycle Assessment
In order to evaluate the sustainability impact of a product a lifecycle assessment (LCA) can be conducted. In this demo developed by Fraunhofer IPK the programming interface of the tool openLCA (here) is used to prepare the calculation of the product carbon footprint. As the system model cannot deliver all information relevant for this calculation (e.g. parameters for transportation or machining of the product), the system model shall only be used for preparation of the analysis. This includes the creation of flows (products and materials that are relevant in the systems lifecycle) as well as processes for the creation of the products which can be later refined in the LCA tool.
In the video a developer view is shown as a command line output with the feedback from the API interaction and the actual application view that the LCA expert sees. The latter view shows that the LCA expert does not have to interact with the SysML model in any form as soon as the program is started. The program automatically creates the entities with the respective UUIDs and reference units from the system model and adds the tags “sysmlv2” and “external” to identify them as coming from the SysML v2 model. Based on this boilerplate the actual LCA can be done.
Analysis & Simulation
The analysis shown in this demo aims to perform a preliminary dimensioning of the battery of the drone; specifically concerning the battery weights, number of cells and battery capacity.
The constraints for the analysis are essentially two: the design range of the drone and the maximum weight of the drone: the first is chosen arbitrary and set to 12km, while the second one is a requirement which comes from the drone specification and already captured as constrain in the design model.
The analysis is performed using MathWorks System Composer™ and a graphical user interfaces that is used to access the SysML v2 Repository via the SysMLV2 API and launch the analysis.
Note. This app was created for this example using App Designer and is an example of a customization for a specific analysis.
The figure below shows the workflow for the analysis:
- Using the SysMLv2 API, locate the system model (by means of project name or project ID)
- Using the SysMLv2 API, get all the available commits for the given project (we will pick the last one in this case as it is the one with all the information we need)
- Using the SysMLv2 API, fetch the necessary information for the analysis. Specifically:
- architecture definition (in terms of parts and parts definition)
- parts attributes
- Requirements, aka constraints
- Instantiate the analysis and perform some tradeoffs by setting the values for power consumption for the engines and mass for arms and rotor parts. The tool will estimate the battery weights, cell number and power consumption and will also provide a warning if the constraints on max weight for the drone is violated

The video below shows the workflow described above in action.
Conclusion
After the many details in the various models, we zoom out once again.
It is worth noting that only one SysML v2 model is written and read by all other applications via API. Model data is not exported or imported; it is always synchronized. This is the advantage of linked data.
The SysML v2 API is also noteworthy. It is a standard. We could replace the SysML v2 repository in the showcase with a repository from any other manufacturer and it would still work in exactly the same way. If everyone adheres to the standards, we would only have to change the server’s address in the showcase.
SysML v2 is just a language, and the SysML v2 API is just an API, but they lay the foundation for the future of MBSE.
Further details can be found at Fraunhofer Publica (Link available soon).