Interface modeling with SysML v2 (in SysIDE)

Interface modeling is an important topic in Model Based Systems Engineering (MBSE), as it decouples components from one another. This enables complexity to be mastered. Languages such as SysML are ideal for specifying interfaces precisely.
In this article, I take a closer look at the constructs for interface modeling in SysML v2, because there are a lot of them! The topic is independent of the tool. However, I ran through the following examples with SysIDE because I wanted to take another look at this tool anyway.
Note: I am organizing a webinar on interfaces with SysML on 25.09., 16:00, together with SodiusWillert. Register now
Interfaces decouple subsystems
Interfaces make it possible to break down systems into clearly defined components/subsystems that can be developed, tested and even exchanged independently of each other. This principle of decoupling reduces the coordination effort between teams and allows asynchronous development processes. Stable interfaces can drastically reduce integration problems.
Good MBSE practices "black box" thinking, a concept in which components are described by their inputs, outputs and behavior without having to know their inner workings. This is precisely one of the strengths of SysML (regardless of the version). Anyone working with complex systems cannot avoid clean interface modeling.
SysIDE: SysML v2 modeling in VS Code
I have already worked with several SysML v2-tools. SysIDE had been on my list of interesting tools for some time: SysIDE is both Open Source as well as commercially, a combination that has transformed software development.
Equally unusual is the "text first" approach of SysIDE: it is not a stand-alone tool, but an extension of VS Code or compatible IDEs. I have been using Cursor AIinto which SysIDE can be easily installed.
Discuss SysIDE Online
- In the SysIDE Forum
- In the SysIDE channel on the Discord Systems Engineering Professionals Server
The community edition of SysIDE does not allow visualization. I currently have an active trial, which is why I am including SysIDE-generated diagrams from SysIDE below. The diagrams are rendered with TomSawyer, which is included with the SysIDE Modeler.
Interface modeling with SysML v2
If you are not familiar with SysML v2, you should take a look at the SysML v2 FAQ by Tim Weilkiens, Stephan Roth & Uwe Kaufmann that answers the most important questions.
First of all, our inventory: SysML v2 distinguishes between use and definition for almost all elements, whereby the definition is often optional.
For interface modeling, we need to consider two aspects:
- What do we connect?
- How do we connect it?
We can connect almost anything: Parts, Portsbut also actions and much more, whereby not every element type is relevant for interface modeling in every constellation Similarly, not all connection options are relevant in the context of interface modeling, but specifically Connections and Interfaces (a specialization of Connection).
Furthermore, elements such as Attributes and Items comes into play when it comes to what happens at the interfaces.
Note: Please feel free to give feedback on the following descriptions, which certainly have room for improvement in one place or another.
Parts and connections
Parts are the elementary "building blocks" in SysML v2. Parts can be connected directly to each other with Connections. But first things first: When modeling interfaces, we would not normally connect parts, but ports (next section).
package SETrends {
part A;
part B;
connection connect (A, B);
// connect (A, B); # Alternative 1
// connect A to B; # Alternative 2
}
- SysIDE always displays the connection in the right direction, i.e. with an arrowhead. This is not the case with the reference implementation. The SysML v2 specification allows both (see discussion in the forum)
- Similarly, the visual representation cannot show more than two connections, i.e. connect (A, B, C). This is a problem with the rendering engine of Tom Sawyer and should be possible in the future.
Ports
A port in SysML v2 corresponds to a proxy port in SysML v1.x. A port is a part of a part. Ports can also be created with Connectionsbut also with Interfaces (more on the differences in a moment):
package SETrends {
part A {
port pa;
}
part B {
port pb;
}
interface connect (A.pa, B.pb);
// connection connect (A.pa, B.pb); # Possible but not useful
}
If one part contains another, we can use bind make the port visible to the outside world. As these are really the same port, they are references, hence the equal sign:
part BlackBox {
port p;
part A {
port p;
}
bind p = A.p;
}
Connections and interfaces
An interface is initially a specialization of a connection for ports: Every interface is therefore also a connection. Linking ports with connections is valid SysML v2, but we should avoid it.
Connections are themselves elements and can be logical or physical, e.g. a logical connection between pump and tank or a physical connection through a piping system.
Connections can contain additional attributes that do not belong directly to the connected elements, e.g. flow rate through a line.
Interfaces are used for reusability: For example, the connection of a power supply should remain the same for different devices and sockets.
Port features, port definitions and conjugated ports
In practice, we would work with Port definitions work to enable reuse.
Ports also generally have features that go beyond in, out or inout get a direction. We already know all this from SysML v1 and it allows us to check the consistency of our model. However, features can also be additional attributes,
As soon as we work with port definitions, we can also use these conjugate (~) to invert the definition of the port and reverse all directions.
Port features: Core of the interface description
This article is about interface description, and this manifests itself in the ports and everything that is connected to them. These are the port features just mentioned, i.e. flows or attributes. All of these features do not have to be typed from a technical point of view, but without them it makes little sense in practice. After all, we want precision that allows us to perform automatic consistency checks.
Finally, here is another example that shows how we can model a socket connection using port defs and interface defs as well as the use of typing. What can be clearly seen here is that the diagram is only a very incomplete view of the model. Nevertheless, it is useful for maintaining an overview. The textual form is much better suited for the interface description.
private import SI::V;
private import SI::A;
private import ISQElectromagnetism::electricPower;
package SETrends {
port def HouseholdOutlet {
out power : electricPower;
attribute voltage = 230 [V];
attribute maxCurrent = 16 [A];
}
port def HouseholdDevice {
in power : electricPower;
attribute voltage = 230 [V];
attribute maxCurrent;
}
interface def ApplicanceConnection {
end port outlet : HouseholdOutlet;
end port device : HouseholdDevice;
}
part HouseholdGrid {
port outlet : HouseholdOutlet;
}
part Toaster {
port power : HouseholdDevice {
:>> maxCurrent = 2 [A];
}
}
interface : ApplicanceConnection connect
outlet ::> HouseholdGrid.outlet to
device ::> Toaster.power;
}
What is still missing
As is often the case with SysML, this is just the tip of the iceberg. And what is shown here is not yet sufficient for a complete modeling of interfaces:
- The modeling of Behavior I have left out the topic of the "new", because although this is an important topic, it is also very extensive.
- The Documentation I have left out here (although the symbol names themselves are already part of the documentation. But SysML v2 has several mechanisms for documentation. Besides doc-comments, we can also take metadata or linked elements such as requirements into account here.
- We can use the features presented in many different permutations, for example via the Nesting from Ports, Inheritance and other features.
Conclusion
SysIDE has so far been by far the most pleasant working environment for SysML v2 text notation, which is also due to the integration with VS Code. This also showed how pleasant it is to record SysML v2 interfaces in text form. However, there is still room for improvement when displaying diagrams, especially as this is a commercial feature.
Interface modeling is an important aspect of mastering complexity. SysML v2 and SysIDE clearly show a step in the right direction.






