SysML v2: A four-page overview for practitioners
SysML v2 can be intimidating: it is specified in several documents, each of which is well over 500 pages long. Fortunately, there is now a lot of help available. In this article, I would like to provide this by discussing the four aspects of SysML that are necessary for practical work. these are: (1) The metamodel; (2) Basics of modeling; (3) Capturing structures correctly; (4) Capturing behavior correctly.
This content is also available in compact form as 4-page PDF that you can download here without registration. You can also order a free multifunctional scarf with SysML v2 print under the same link (Christmas promotion).
Graphical modeling
In the following, I will focus on graphical modeling, as it leads to the textual notation already has a lot of good material there. I also use a screenshot of the 4-page cheat sheet, which downloaded here as PDF can be used.
Metamodel
SysML v2 is based on KerML, the Kernel Modeling Language. Actually, it should not be necessary for practitioners to understand KerML, or to know it at all. But in practice, it helps to know a few things:
KerML defines the precise meaning of the language, which makes SysML v2 a cleanly defined, formal language with clear semantics. In KerML (and thus also in SysML v2) everything is a typed element, there are no „special cases“ as in SysML v1. Elements have types, properties and relationships that work in a uniform way. SysML v2 uses many KerML concepts directly, especially relationships such as specializes, subsets or redefines.
A second key aspect is the clear separation between Definition of and Usage. KerML does not explicitly enforce this pattern, but it makes it cleanly possible. Definitions describe reusable types, usages their concrete application in the model context. This principle runs through structure, behavior and requirements and is one of the main reasons why SysML v2 is significantly more robust for reuse, variant creation and scaling than SysML v1.
Definition and usage
First of all, every modeler should understand what definition and usage are and how they are used. One Definition of describes a reusable type, i.e. the general concept of an element. A Usage is the concrete use of this type in the model context. Types are defined, instances or context-specific characteristics are used. This applies to structures, behavior, requirements and even relationships themselves. In SysML v2, this pattern is omnipresent and deliberately made explicit. Definitions are optional, but omitting them is not recommended.
The image shown summarizes the most important relationships: specialize describes an inheritance relationship between definitions: A SubDef is a specialization of a more general definition and inherits its properties. usage links a usage to its definition and answers the question: „What type is this specific element?“ Two further relationships are added at usage level: subset means that a usage represents a restricted subset of another usage, such as ports, attributes or roles. redefine goes one step further and deliberately replaces an inherited characteristic with a new, more precise meaning.
Taken together, these four relationships explain how SysML v2 models consistency, reuse and controlled specialization in a clean and comprehensible way.
Basics of modeling
There are countless methodologiesSYSMOD, Harmony, MagicGrid, Arcadia and many others. They all have their raison d'être, and some also use other modeling languages, but they also have a lot in common. This short introduction is about these similarities.
Regardless of the specific methodology, MBSE approaches can be traced back to a few common principles. At their core, they all work with the same technical quadrants: Requirements, Behavior and Structure. In SysML v2, these are clearly covered by language elements (see below).
In addition, all MBSE methodologies separate the problem and solution layers. SysML v2 explicitly supports this separation without enforcing it. In the problem layer, needs, goals and desired behavior are described, typically with abstract requirements, use cases and Black box-behavior. In the solution layer, these elements are refined and realized, for example through concrete parts, internal structures, detailed actions and allocations.
The connection between the layers is created via relationships such as refine, satisfy and allocate. This means that SysML v2 does not provide a method specification, but a consistent linguistic foundation on which practically all established MBSE methodologies can be mapped.
Structure
A scalable structure starts with a clean project organization. In SysML v2, models are organized via Namespaces and Packages The model tree is structured in a way that clearly defines the ownership structure. The model tree also describes ownership.
Libraries enable reuse. There are both standard libraries and the option to create your own. A standardized Naming conventions is important. CamelCase is common, with upper case for definitions and lower case for usages.
The central components of structural modeling are Occurrences and Parts. An Occurrence describes a specific occurrence of an element in space and time and thus forms the basis of many SysML v2 concepts. Parts are specialized items that can also perform behavior. They represent the structural components of a system, which we can nest hierarchically.
Ports and Interfaces finally define the system boundaries and couplings. Ports describe explicit interaction points of a part and define which types of flows or messages are allowed. Interfaces specialize connections between ports and ensure that interactions are compatible. They thus support clean black-box and glass-box modeling.
Behavior
behavior builds directly on the structure described above. Occurrences provide the temporal context in which behavior takes place, Parts are the carriers of this behavior. One Action is always linked to an occurrence and is executed by a part, either directly or via the perform relationship. The explicit coupling prevents abstract „function clouds“ without reference to the system architecture.
Actions are the most important language element for describing behavior and allow complex processes to be modeled. Communication is realized via Messages realized over Interfaces and Ports between Parts can be exchanged. Behavioral modeling is enormously powerful, but unfortunately it is often a challenge to get the structures right. I would like to see much more support from the tools here.
Cases describe behavior from a higher-level, scenario-based perspective. A case has at least one subject, optional actors, input parameters and a result. The best-known special case is the Use Case, which describes typical usage scenarios in connection with requirements. In addition, there are Analysis Case and Validation Case, that specifically address technical issues. Definition and usage make it possible to define reusable cases and instantiate them in specific system contexts. Cases thus bridge the gap between requirements, behavior and verification.
Requirements
In SysML v2 Requirements also Occurrences, which makes them fully-fledged model elements. A requirement is therefore no longer a static block of text, but can have attributes, parameters and relationships that are processed in the model. This is precisely where the bridge to parameterization is created: requirements can contain values, reference constraints or specify calculations and limit values themselves, which are later compared with design parameters. This means that requirements can not only be formulated, but also quantitatively checked, compared and automatically evaluated.
Conclusion
SysML v2 has enormous potential, but also has a steep learning curve. It is not enough to know the model elements. We also need to use the language methodically and correctly.
If this article is useful to you, then I recommend that you also read the 4-page cheat sheet and keep it printed out on your desk. And if you have a different focus, take a look at the other SysML v2 resources to.
