Panel on SysML v2 (Part 2): How can we achieve conformance?

This is the second part of the panel on SysML conformance. Last week the panelists were introduced (Part 1). We have also clarified what SysML conformance is all about and what the scope of conformance is. One thing is clear: the conformance of SysML v2 is at risk. That's why this time we're looking at the panelists' suggestions on how we can achieve conformance.

Here is the second part with Andreas Pollom, Daniel Siegl, Robert Karban and Vince Molnár.

How can we achieve SysML v2 compliance?

In principle, SysML v2 is on the right track in terms of conformance: after all, conformance was demanded from the outset via a requirement in the SysML v2 RFP. Interested parties can follow the activities of the SysML v2 RFP Working Group and also participate.

The panelists now examined the question of why SysML v2 conformance is nevertheless in danger. In doing so, they looked for inspiration from other standards, such as BPMN or ReqIF.

The panelists all agreed that a test suite would have tremendous value for SysML v2 compliance. The most important stakeholder for such a test suite would be the tool vendors. Ideally, manufacturers would have access to tests before they even start development. Established vendors are already working on tools, but for new companies this could be extremely valuable.

Users benefit most indirectly from a test suite, as this would ensure better interoperability. In this respect, here is another appeal to SysML users to exert pressure on the manufacturers.

Conformity of what?

But what should conformity actually refer to? The panelists had already commented on this last week. Small manufacturers in particular will be able to cover all aspects of SysML v2 and only a few users will use all the features of SysML v2. Therefore, we need different categories of conformance and possibly also levels.

For example, API and text notation would be separate categories. There could also be gradations, for example a test suite for a minimal implementation of the API.

Create usable results

There is already a test suite for the Pilot implementationwhich are Ed Seidewitz and this also represents a useful starting point for interested parties. Vince's group is already considering how these tests could be used systematically. His group also has ideas on how to generate tests.

The number of questions Vince receives about SysML v2 confirms the interest in the market. Vince also has many people around him who are ready to get started. There is a lack of core team members to coordinate these activities.

We have to create artifacts such as test suites before we can use them at all. Hence the call for cooperation. There is also enough material here for master's or doctoral theses.

Vince Molnár, 37:30

Seal of approval or certification

Robert pointed out that although we SysML certifications for users havebut not for the language itself! Vince explained that the OMG itself does not usually set up certification programs for tool manufacturers. However, this does not have to be done by the OMG. Daniel suggested INCOSE as an organization that could run such a program. The ReqIF standard was also mentioned as another example, for which an external organization (ProSTEP ivip) a Implementation guide had created.

Such activities are not always in the interests of tool manufacturers, who have at least resisted interoperability in the past, for example with regard to PLM interoperability.

Have fun with SysML v2 conformity

A new idea, at least for me, came from Daniel from the BPMN world: The BPMN Model Interchange Working Group (BPMN MIWG) has managed to build up an active community in which the tool manufacturers are also very active. The group's website includes a table with the test status of the various tools.

The group meets regularly online for Interoperability demos with a good atmosphere and a lot of commitment.

Transformation from SysML v1 to v2 only later

We must be very careful not to "pollute" our SysML v2 world with "dirty" data from the SysML v1 world

Daniel Siegl, 42:12

Robert pointed out that the transformation from SysML v1 to v2 could also have great potential for the topic of conformity. Both Vince and Daniel advised caution here: we can and should check the validity of transformed SysML v2. But on the one hand, there is a lack of realistic examples here, and on the other hand, we should never start with a transformation before we have the opportunity to really validate the result properly.

Enabler for open model library

Success in SysML conformance would have many positive effects and in particular contribute to the spread of SysML and MBSE. However, the group discussed one idea in more detail. Conformance would pave the way for libraries of model components, as we already know from software development.

Robert addressed the topic in the context of configuration management with branching and merging, as has been practiced in software repositories (git, Subversion, etc.) for decades. As Daniel's company LieberLieber a solution for model versioning has developed, he could contribute a lot here.

In particular, all panelists wanted an ecosystem of "stock" models that modelers could access, just as we are used to in software development.

Package managers with semantic versioning are widely used in software development (atp for Linux applications, npm for Javascript, gem for Ruby...) and would also be desirable in the world of modeling.

Daniel had heard the desire for such a library 15 years ago from Rockwell Collins and Vince suggested OMG as the perfect home for such an initiative. After all, 80 companies are already part of the OMG Systems Modeling Community, many of which would surely participate in such a project.

However, we will only be able to create such a model library if we can guarantee SysML conformity. Which brings us back to the topic.

What happens if we don't make it?

The biggest danger is that nothing will change compared to SysML v1. If we don't have conformity and therefore have the same problems with v2 that we had before, then we will have wasted a huge opportunity. The victims would be the users and the speed at which SysML and MBSE spread will not increase.

Another danger is that the high expectations of SysML v2 will not be met, resulting in a Valley of disappointments could lead to. If we are unlucky, the train will eventually leave the station.

Conclusion

At this point, I can only repeat what I wrote last week: We need people to get involved. Would you like to support SysML v2 activities? Here again is the list of things to do:

• Tool manufacturer: Conformity will save you time and money. Therefore, get involved with money, or better with personnel, for example in setting up a test suite.
• User: Hope for the best, but prepare for the worst! In particular: Standardize your modeling today, avoid customization and profiling as much as possible.
• User: Ask your tool manufacturers explicitly about conformity. Make it clear that the topic is very important to you.
• Users in large corporations: Conformity can even become a problem within the same organization. Corporations such as ESA, Mercedes, thyssenkrupp can benefit from compliance through internal interoperability alone. Therefore, there is a business case for such companies and we are happy to help you develop it.
• Students and teachers: There is a lot of potential here for interesting master's or doctoral theses.
• All readers: Even small amounts of money (for companies) help to finance the work on conformity. Is your company in a position to make a contribution? Active cooperation from competent people often helps even more than money.