The time is right for a new version of SysML. The OMG (Object Management Group) released SysML Version 1.0 more than ten years ago. The aim was to create a simple, yet powerful modelling language for a wide range of applications in systems engineering. Since then we’ve learned a lot about SysML through its use in the industry. That includes both its strengths and weaknesses. In addition to this, model-based systems engineering (MBSE) is becoming more and more popular, gaining in importance for many product development companies. These factors are leading to an increasing number of requirements for SysML.
In December 2017 the OMG published the Request for Proposal for Systems Modeling Language Version 2 – short, RFP for SysML v2. The document is a long list of requirements for the new version of SysML. It’s now up to so-called submissions teams to respond to the RFP with a suggestion for a new modelling language. It’s thus going to take a few years before SysML v2 is officially adopted. Nevertheless, it makes sense to get familiar with the new concepts now and to prepare for changing methodology.
In June 2018 the OMG published the “SysML API & Services RFP”. This marks the beginning of development for a new, groundbreaking standard for collaborative engineering.
In my MBSE Blog at www.mbse4u.com you’ll find a series of blog posts that introduce the requirements contained in the RFP. I’ll outline the most important ones for you here:
SysML v1 is based on UML. This has many advantages, but also comes with disadvantages. Certain concepts relevant to systems engineering, such as groups and allocation, are poorly represented. UML’s data model is so complex that automated analyses, simulations or even simple queries are difficult to implement. For these reasons, SysML v2 will receive a new core independent from UML, called KerML, which is being specially developed to meet the requirements of a contemporary modelling language. This new meta model could also be used for a new edition of UML in the future.
In addition to this, there will be another version of SysML v2 that is still based on UML. This is meant to ease the transition from SysML v1 to SysML v2. This SysML v2 profile, however, won’t have the entire functionality of SysML v2, because its core will still be limited by UML.
SysML v2 will be much more precisely specified than SysML v1 and will offer executable models. This is also possible with the present version, but the run time environment has to “guess” some things due to the lack of precision.
SysML v2 will have new model elements that explicitly support a greater number of systems engineering concepts. Among these are: risk, variants, material properties, geometric properties, and cause-effect relationships.
SysML v2 follows the usage-focus modelling approach which aims at simple and intuitive modelling of structures. To put it simply: modelling of internal block diagrams without block definition diagrams. Internal block diagrams correspond to the typical language that software engineers use, whereas block definition diagrams are often difficult for non-engineers to understand.
Users are of course most interested in how SysML is going to look. The RFP doesn’t name any specifications. We can assume that SysML v2 will look similar to SysML v1. There’s no reason to change the current appearance of use cases as ellipses or blocks as rectangles.
There will be additional possibilities for visualization and presumably new types of diagram. For example, prototypes are now making use of the visualizations from graphical databases like neo4j. It may be possible to visualize the new geometric properties in (very) simple CAD representations. There will also be a purely textual representation so that one can program in SysML. The current candidate for the programming language is Alf, which would then be extended for this purpose.
I’ll conclude with another highlight. There will be a standardized API for accessing SysML models. This mans it’s possible to read and write to the model independently from the modelling tool. This will create many new possibilities and improve the interoperability between engineering tools. For example, various authoring tools for requirements engineers, system architects and simulation experts could be used at the same time and all of them would be able to work on the same model.