What are the benefits of SysML v2? Interview with Uwe Kaufmann
Anyone who deals with systems engineering and MBSE and SysML in Germany is Uwe Kaufmann (➜LinkedIn) have certainly already met. Uwe is actively involved in the Society for Systems Engineering (GfSE). In particular, he heads the PLM4MBSE working group and the "SysML Industrialization" project group.
Today's interview is about SysML v2, which has been several years in the making and represents a quantum leap compared to v1.
In addition to his voluntary activities at the GfSE Uwe Kaufmann consultants to create added value with modeling in the areas of software and product development.
SysML is making a version jump from 1 to 2. There are supposed to be many changes, what are the most important ones?
SysML v2 will meet the requirements of a general system modeling language. Until now, SysML was a profile of UML and therefore had the flavor of a software software modeling language. This has caused many problems and acceptance in the user community. A lot of time has now been time to analyze the SysML v1 and to work out the disadvantages and and obstacles to its applicability. The result was 3 years of work from 2014-17 resulted in a requirements document in the form of a Request For Proposal (RFP), which forms the basis for the specification of SysML v2 (see figure and further links).
In my opinion, the most important requirement for SysML v2 is the demand for interoperability, i.e. the exchange of models between different authoring systems and a standardized interface (API) to be able to make requests to authoring tools.
SysML v2 will have exact and unambiguous semantics.
The prerequisite for interoperability is the metamodel of SysML v2, which defines the semantics and the abstract and concrete syntax of the language. is defined. In contrast to SysML v1, SysML v2 will therefore have exact and unambiguous semantics. It cannot be emphasized emphasize strongly enough how important this requirement is. It is unfortunately underestimated by many users. But if exchange of data does not work, it is very often due to this lack of lack of accuracy and clarity. Problems with model exchange in SysML v1 are not because there is something wrong with the XMI standard, but because the tools interpret and implement the SysML standard differently. Apart from the missing diagram exchange, but that's another topic. topic.
There are other modeling languages - why is SysML better?
I wouldn't say better or worse here. Each of these languages has its advantages and disadvantages. Capella has already eliminated some of the deficits of SysML v1 that we will only now solve in SysML v2.
Capella has already eliminated some of the shortcomings of SysML v1
The difference is that SysML is a standardized language that is implemented by different providers. SysML 1.4.1 is already an ISO standard (ISO 19514:2017) and other standards (ISO and OMG-) standards, such as the Unified Architecture Framework (UAF, formerly UPDM - "Unified Profile for DoDAF and MODAF" aka ISO 19513:2019).
We need a standardized language language is needed, for example, for the long-term archiving of product knowledge and the documentation of product-defining data.
One important change is the introduction of an API. What is the motivation and how will it be used?
An API (Application Programming Interface) ensures openness and therefore interoperability. A lack of model exchange was and is one of the biggest problems in the use of SysML v1.
Lack of model exchange was and is one of the biggest problems in the use of SysML v1
When creating the requirements specification (RFP) for SysML v2, the users therefore gave great weight to this requirement, which resulted in a separate RFP for the "SysML v2 API and Services".
SysML v2 has the potential to act as a "single source of truth" in a product development process. The system architecture of a product can be mapped with the help of SysML v2 - starting with the requirements via the functional-logical architecture - and can thus be made available over the entire product life cycle. Feedback from all phases can be captured in the system model, which is why we have been discussing the integration of (SysML-supported) MBSE (Model-Based Systems Engineering) and PLM (Product Lifecycle Management) intensively for some time, for example in the GfSE working group PLM4MBSE and the GfSE project group "SysML Industrialization".
What does the separation of SysML and UML mean for the user? Since there is a transitional solution, will the independent SysML prevail at all?
In concrete terms, this means means that the user is freed from the inhibitions of software modeling. The separation of abstract and concrete concrete syntax in SysML v2 means, among other things, that the new system new system modeling language can be offered to the user via a completely different user interface than before.
In terms of the language architecture of SysML v2, however, the separation from UML also means that something is being turned on its head. A (new) UML could and should become a domain-specific language of SysML.
There will be an option for backwards compatibility with SysML v1
Before fears arise that that everything will be different and new with SysML v2, it should be it should be noted that there is also a requirement for backwards compatibility with SysML v1. This means that for SysML v2 there will also be a UML profile in parallel to its own metamodel. profile in parallel with its own metamodel. Support for the migration from SysML v1 to v2 is to a certain extent already provided in SysML v1.7, in that a non-normative annex for the precise semantics of SysML in the specification. the specification.
What will be the most important application of SysML v2? Which applications would not be possible with SysML 1.x?
The "killer app" in the product life cycle is complexity (to be seen here in terms of the number of subsystems and their connections and interdependencies). This complexity can only be mastered if we describe our "product systems" in a model-based way, i.e. in a form that can be interpreted and simulated by computers.
The "killer app" of SysML v2 is the mastery of complexity
Making the complexity of the life cycle also means that we make the models and their elements models and their elements over the life cycle in a versionable and configurable and subject to change management. This was only possible to a limited extent with SysML v1, but in v2 will be part of the standard language scope.
Where can our readers find further information?
As part of the GfSE project group "SysML Industrialization", which I lead, we are directly involved in the OMG team (SST - SysML v2 Submission Team) for the specification of SysML v2. Currently, the SST has published a first "Public Incremental Release", where you can find the language specification as well as first implementations. Comments and suggestions can be communicated directly via the project group or myself. The project group is happy to accept use cases for the "Validation & Verification" of SysML v2 for further influence, and I will be happy to answer any further questions.
Click here for the Google Drive with the current state of development
Also interesting is certainly the development of SysML v2, which is well documented in the OMG Wiki of the RFP Working Group. is well documented. And last but not least, the specifications of SysML v2 (RFP) provide a well-founded insight into what we can expect from the future system modeling language.
Further links:
- SysML v2 API and Services
RFP:
http://doc.omg.org/ad/2018-6-3 - Systems Modeling Language
(SysML) v2 RFP:
http://doc.omg.org/ad/2017-12-2 - 2019-09
OMG SST Public incremental release of SysML
v2:
http://openmbee.org/sysml-v2-release/2019-09 - Tim Weilkien's blog
NextGenSysML:
https://mbse4u.com/blog/ - SysML v2 RFP Working
Group:
http://www.omgwiki.org/OMGSysML/doku.php?id=sysml-roadmap:sysml_assessment_and_roadmap_working_group - GfSE PLM4MBSE AG -
Position paper on PLM and MBSE:
http://www.gfse.de/Dokumente_Mitglieder/ag_ergebnisse/PLM4MBSE/PLM4MBSE_Position_paper_V_1_1.pdf
