SysML v2 - a first look

The SysML v2 Submission Team (SST) recently announced the fifth public release of its work towards the OMG SysML v2 specification. This is the first public release since the SST presented the initial submission of its proposed SysML v2 specifications to OMG. The complete public release of the specification and prototype tooling can be found at http://openmbee.org/sysml-v2-release/2020-09. 

If you have been keeping track of the SysML v2 developments, you probably already know this. A good introduction to the currently planned features of the specification can be found here. This week I decided to give it a try. If, like me, you are a practitioner of MBSE and SysML and are interested in getting a sense of what is coming up with SysML v2 and how you might try it, read on…

Setting up the tooling

The current public release has 

• an installer for Jupyter notebook with SysML kernel, and
• an installer for Eclipse plugins for the KerML and SysML editors

I tried the Eclipse plugins, as it also allows graphical visualisation within the same setup. (You can visualize the models built in Jupyter by using the Tom Sawyer Visualization tool prototype. But there aren’t any prototype graphical editors yet.) 

Installation of the prototype tooling is slightly tricky due to the various dependencies. Make sure that you follow all the instructions in the readme file in the correct sequence. I installed the “Eclipse Modeling Tools” IDE. Before installing the plugins, I also installed Graphviz and PlantUML, as these are required for the visualisation. Once this setup is properly done, the KerML and SysML plugins can be installed smoothly.

Building a simple model

As a first attempt, I started making a simple model of a car. I started by creating a new project, checking the “sysml.library” project on the Project References page. I also converted the project to an Xtext project, as required to set up indexing infrastructure for resolving references.

Decomposition & specialization (and Blocks & Parts)

Let us say, we want to simply define a car as specialization of a vehicle, and that it has parts, such as wheels, transmission, steering, etc. Using SysML v1.6, we would usually start with a block definition diagram, defining different blocks for “car”, “vehicle”, “wheel”, etc. and then drawing the relationships between them. 

Although SysML v1.6 makes clear distinctions between “definitions”, as in “Blocks”, and “usages”, as in “Part properties”, this is often confusing to new users. The part names get relegated to connector ends and the ownership/containment of the definitions is not clear.

There isn’t a graphical editor prototype for SysML v2 yet. Using the textual notation, we first declare the “definitions” that would be needed to describe the concept of the Car. To make the verbiage simpler, “usages” are called <part>s in SysML v2, and “definitions”/“Blocks'' are called <partDefinition>s. The definitions have to be declared as below.

With these definitions, the Car can then be defined as below. As you can see, the distinction between the <part> and <partDefinition> stereotypes is more evident. As seen in the diagram, we can declare multiplicity, and a <part> can in turn contain more <part>s to form a hierarchy as is done for the Transmission part/usage pTrans. (I guess, ideally one would probably define the <partDefinition> of Transmission to have an Engine, which can be redefined in the Transmission part/usage if needed.)

Of course, we can put these descriptions together in one file. The resulting visualization explicitly shows the specialization and stereotype relationships. (NOTE: The graphical visualization may differ slightly between the visualization prototypes as the standards are still being defined.)

Generally, new concepts would be created using a combination of old concepts (by grouping, specialisation, redefinition, etc.) and perhaps a few additional new concepts. The old concepts might come from earlier projects, or from libraries of common components. Therefore, this explicit separation of <part> and <partDefinition> would hopefully make it easier to model.

Defining behavior

In SysML v2, “activities” and “call behavior actions” are called <actionDefinition>s and <action>s respectively. Control flow is specified using the “succession - then” keyword combination, and object flows using the “flow - to” combination. You can define actions, input and output ports for actions and flows between the ports as shown below. I faced some issues with the visualisation prototype (the visualisation would be lost if I complete the definition - but you can see the form in the diagram below). 

Further descriptors, e.g. for decisions, branching and merging, etc., are also available similar to the current version of SysML.

I did try creating links, called <connection>s, and <requirement>s and <requirementDefinitions>. But since the visualisation didn’t seem to work completely for that, I was not sure about the correctness of those declarations. I guess, I will reserve that for later.

In summary

The formal release of the SysML v2 specification is still about a year away, and robust commercial implementations will probably not be available for another 3 to 4 years. However, SysML v2 has the promise of making architecture models seem more like models that can be viewed flexibly, rather than a bunch of diagrams. Also, with standardised API and semantic basis, it should give a boost to interoperability and automation. 

The current public release lacks a graphical editor prototype, and hence is perhaps not the most convenient for practitioners to start playing with yet. For practitioners, being aware of the proposed changes, and perhaps tuning their current (SysML v1.x) modeling and model management practices, can ensure that they will be well placed to make the transition from SysML v1.x to v2 smoothly, without painful rework or loss of information.