Broadcast date: December 22nd, 2021
You can join and watch this episode on Youtube, Spotify, iTunes, Amazon Music, or Google Podcasts.
Welcome to the 22nd door of our MBSE Podcast Advent Calendar. Today, we travel to the future and model our great MBSE Podcast Christmas Tree with the next-generation modeling language SysML v2.
The SysML v2 is currently under development. It will be officially available probably in 2023 or 2024. So, there is still some time. However, it is already interesting to take a look at it now in order to set the course in good time. 2-3 years is a very short time in relation to major changes in the process and tool landscape in MBSE.
The SysML Submission Team (SST for short) is currently working on the specification of SysML v2. What is great is, that they also provide a pilot implementation so that you can experiment with SysML v2. We use the pilot implementation based on Jupyter Lab to show you some more or less equivalent SysML v2 models of our Christmas tree.
To avoid having to set up a Jupyter Lab environment yourself, my company oose provides a ready-to-use implementation at sysmlv2lab.com. Here you will also find a general introduction to SysML v2, the current state of the specification, and many examples. You can also create your own models and play around with them. But beware: From time to time, the server will be restarted and all files will be lost. If you want to save your models, you have to download them manually.
We have already uploaded our Jupyter notebook for the MBSE Podcast Christmas Tree. SysML v2 offers a textual notation in addition to the graphical notation known from SysML v1. To create the models in the pilot implementation, one has to use the textual notation and can then generate the graphical notation automatically. Later there will probably be graphical editors for SysML v2 as well. So, let’s have a look.
package TMPCT_PhysicalArchitecture {
part theMBSEPodcastChristmasTree {
part tree {
part trunk;
part branch[1..*];
attribute height : ScalarValues::Integer;
}
part transportationNet;
part christmasTreeStar;
part christmasTreeStand;
part fairyLights;
part transportationPackage;
part ball[1..*] : ChristmasTreeBall;
part christmasBlanket;
part powerManagementModule;
part enjoymentControlUnit;
}
part def ChristmasTreeBall {
enum def BallColor {
enum red;
enum blue;
enum gold;
}
attribute color : BallColor;
}
}
Our TMPCT – model is a simplified version of our SysML v1 physical architecture of the Christmas tree. We have directly modeled the parts. They have no explicit type. Simplified, in SysML v1, it would mean to define part properties without blocks. What works in SysML v2, but not in SysML v1, is that the parts can also define structures themselves, as you can see here, for example, with the part “tree” which defines the trunk, the branches, and a value property for the height of the tree.
If no type is defined, however, a type from the system library of SysML v2 is implicitly set in the background. Also, a part always needs a context. If this is not given, for example, with our top-level part “theMBSEPodcastChristmasTree”, then the element “Anything” from the KerML base library is set as the context element. BTW: KerML is the metamodel of SysMLv2.
For one part, we set the type. The part “ball” is of type “ChristmasTreeBall”, which is defined at the end. It contains the definition of an enumeration, which is then used to specify the attribute “color”.
So far, all we have is a list of things. The diagram is, therefore, also just a simple tree structure, which of course, fits perfectly with our Christmas tree project.
The graphical notation of SysML v2 is very similar to SysML v1. One difference in the diagram is the relationship between the part “ball” and the part definition “ChristmasTreeBall”. The relationship is a “defined by” relationship.
package TMPCT_PhysicalArchitecture {
part theMBSEPodcastChristmasTree {
part tree {
part trunk;
part branch[1..*];
attribute height : ScalarValues::Integer;
connect trunk to branch;
}
part transportationNet;
connect transportationNet to tree;
part christmasTreeStar;
connect christmasTreeStar to tree;
part christmasTreeStand;
connect christmasTreeStand to tree.trunk;
part fairyLights;
connect fairyLights to tree.branch;
part transportationPackage;
connect transportationPackage to christmasTreeStar;
connect transportationPackage to tree;
connect transportationPackage to fairyLights;
connect transportationPackage to powerManagementModule;
connect transportationPackage to christmasTreeStand;
connect transportationPackage to christmasBlanket;
part ball[1..*] : ChristmasTreeBall;
connect ball to tree.branch;
part christmasBlanket;
connect christmasBlanket to christmasTreeStand;
part powerManagementModule;
connect powerManagementModule to enjoymentControlUnit;
connect powerManagementModule to fairyLights;
part enjoymentControlUnit;
connect enjoymentControlUnit to fairyLights;
}
part def ChristmasTreeBall {
enum def BallColor {
enum red;
enum blue;
enum gold;
}
attribute color : BallColor;
}
}
Now we add some connections to our model. For this, we use simple connection relationships.
If we visualize the model, we can see the structure of our Christmas tree. However, since the visualization is generated automatically, we cannot adjust the layout.
So much for the 22nd door of our MBSE Podcast Advent Calendar. We wish you a great 22nd of December.
Podcast: Play in new window | Download