The SysML v1 to SysML v2 Migration
Many companies in different industries have implemented MBSE with SysML at great expense. And now comes SysML v2. What does this mean for those companies? Does everything have to be rebuilt?
SysML is indeed an important standard in systems engineering, but it is also just a language. The MBSE methodologies are largely language-independent. For example, you can do a system context description well with SysML, but you can also describe it with other modeling languages and even self-defined drawings, tables, or text, whereby the latter cases are not modeling scenarios anymore.
A model-based approach requires a harmonic triad of methodologies, modeling languages, and modeling tools. The impact of the change from v1 to v2 is, of course, mainly in the languages and the tools aspect of the harmonic triad.
Moving from SysML v1 to SysML v2 requires changing tools, updating tool- and language-specific guidances, and possibly updating parts of the methodology. This leads to costs, such as training project participants and scheduling lower productivity initially since everyone has to go through the learning curve first.
Part of the SysML v2 specification is also a definition of transformation rules for mapping SysML v1 elements to SysML v2 elements. The mapping is an important building block for migrating from SysML v1 to SysML v2.
The following figure shows three potential strategies for how existing SysML v1 models can be used or transferred in a SysML v2 MBSE environment.
A SysML v2 tool can access a SysML v1 model just as it accesses other engineering models. To do this, it must be technically capable of accessing the data. On the other hand, it must be able to “understand” the data.
In strategy 1, the SysML v2 tool receives the information from the SysML v1 model via a proprietary interface provided by the SysML v1 tool. It receives the data in a standardized format such as XMI or a proprietary format. In addition, the SysML v1 semantics of the data must be understood by the SysML v2 tool. One possibility is that the SysML v2 tool uses the v1-to-v2-transformation rules to convert the read SysML v1 model elements into SysML v2 elements. For example, when the data of a block model element is read, it becomes a part definition. Of course, there are also other possibilities, such as only linking model elements or selectively reading out individual pieces of information.
In strategy 2, a SysML v1 tool that can handle the v1 to v2 transformation can offer a v1 model externally as a SysML v2 model via the SysML v2 API. Since the transformation is not bidirectional, it can only offer the SysML v1 model elements externally as SysML v2 elements. However, the transformation cannot transform SysML v2-specific requests from the outside to SysML v1, such as “give me all part definitions,” unless the interface can apply its own transformation rules from v2 to v1 in addition to the official transformation. However, a complete mapping will not be possible because SysML v2 has more concepts than SysML v1.
Strategy 3 is a complete transformation of a SysML v1 model to v2.
Strategies 1 and 2 are particularly useful if the SysML v1 model is still active, i.e., if work on it is continuing. If the SysML v1 model is no longer to be worked on, but the information in the SysML v2 model is required and, if necessary, is to be developed further, strategy 3 is particularly suitable.
In most cases, the transformation from v1 to v2 will not be lossless. The transformation rules are based on SysML v1.7. Most SysML v1 models are based on an older version and, more importantly, are typically not 100% compliant with SysML. Thus, the transformation cannot provide a complete mapping. Tools can compensate for known inconsistencies, and models can be suitably adapted to improve the quality of the transformation.
Do you have ideas for more migration strategies or comments on the ones presented? Feel free to comment or write me and if enough material has been collected, publish a revised version of this post.
