The Limits of SysML v1 and how SysML v2 addresses them (2)

April 2023, Markus Schacher

SysML v2 Differences

Development of SysML v2 has been initiated in 2017 and currently it is expected to be released in 2023 or 2024. In March 2023, the SysML v2 Submission Team (SST) published the pre-release 2023-02 consisting of about 2’400 (!) pages. This is probably the largest specification that the OMG ever developed. Based on this pre-release I see the following substantial differences between v1 and v2 of SysML (where possible, references such as „LV-2“ to the limitations identified in part 1 are given):

General features

• DG-1 Metamodel
  Directly MOF-based metamodel called KerML instead of being based on UML
• DG-2 Textual Specification
  Textual language (similar to UML’s HUTN) as an alternative/complement to the graphical language to define a model
• DG-3 API
  Standardized API for services and tool extensions
• DG-4 Viewpoints
  Configurable/filterable „viewpoints“ (e.g. diagram types or compartment types) for specific stakeholder needs and „views“ (e.g. diagrams or compartments) as their rendering (instantiation)
• DG-5 Import
  SBVR-like adoption package-import, including filters and aliasing
• DG-6 Units
  Simplified, but more powerful and more robust handling of units for values (e.g. enum literals may now have units)
• DG-7 Metadata
  Language extension via orthogonal „metadata“ concept, libraries and specialization of elements in libraries having attached metadata replaces stereotypes and profiling of SysML v1 and UML
• DG-8 Libraries
  Several comprehensive libraries supplied as part of SysML v2 for specialized modelling disciplines such as systems modelling, meta-modelling, verification (test) modelling, risk modelling, cause/effect modelling, geometrical modelling, analysis techniques, quantities and ISO units

Core Modeling

• DC-1 Definitions
  Strict separation between definition and usage of model elements (parts, actions, attributes, ports, interfaces  items, states, etc.)
• DC-1 Definitions
  Strict separation between definition and usage of model elements (parts, actions, attributes, ports, interfaces  items, states, etc.)
• DC-2 Usages
  A usage is a kind of specialization (expressed as „:|>“) with inherited features including inherited decompositions
• DC-3 Usage Decomposition
  Usages may be hierarchically decomposed (in SysML v2) in the same way as definitions (e.g. blocks in v1)
• DC-4 Occurrences
  An occurrence is a definition or usage of an item in time and space
• DC-5 Variation Points (addresses LV-2)
  Supports variation points (applicable to definitions and usages) and variants similar to OVM/ISO 26550
• DC-6 Variation Constraints (addresses LV-2 and LV-3)
  Choices of variants may constrain other choices of variants using boolean constraint expressions
• DC-7 Variation Selection (addresses LV-2)
  Specializations may use/select elements of chosen compatible variants
• DC-8 References
  Weak/shared aggregations in v1 are now called „references“ in v2
• DC-9 Dependencies
  Dependencies may have multiple sources and multiple destinations (although a little clumsy notation)
• DC-10 Allocation
  New decomposable „allocation“ dependency between many types of elements (e.g. between actions to parts (performs), requirement to design element, logical to physical elements, SW to HW, budget to parts, etc.)
• DC-11 Causation
  New decomposable „causation“ dependency between states
• DC-12 Expressions (addresses LF-1)
  Supports mathematical expressions with syntax very similar to (KnowGravity’s) xUML expressions, but also supports vectors and tensors
• DC-13 Constraints (addresses LF-1)
  Supports boolean constraints as inheritable assertions stated in a simple boolean expression language, but without quantifiers and logical variables
• DC-14 Constraints Reuse
  Reusable constraints stem from a library of constraint definitions that may be instantiated as constraints with bindings as weak unification
• DC-15 Annotations
  New annotations for comments, textual representation, metadata (e. g. to add security or safety information), etc. with structured contents and formalized relationship to annotated elements
• DC-16 Enums
  Enums are now called „enum def“ and literals „enum“

Requirements modelling changes

• DR-1 Requirements
  Requirements are now constraint definitions with attributes and subjects (aka targets) that support types (definitions) and usages
• DR-2 Structured Requirements (partially addresses LN-3)
  Supports composite requirements and in-place <satisfy> requirements usages (e.g. in parts) with parameters bound to requirement definitions
• DR-3 Allocations
  Allocation of requirements (responsibility) separated from satisfaction of requirements (implementation)
• DR-4 Derived Requirements
  <derive> dependencies propagate satisfaction to the derived requirements
• DR-5 Use Cases (partially addresses LN-4)
  Use cases are now supported as definitions and usages and are now represented by the unified symbol (sharp and rounded rectangle instead of oval)
• DR-6 Extensions
  <extends> dependency between use cases is no longer supported
• DR-7 Analysis (partially addresses LN-1)
  New „analysis case“ supported as a special kind of action with use case like properties to evaluate a result about a subject of the analysis
• DR-8 Trade-off
  New „trade off analysis“ supported as a specialization of an analysis case to choose a preferred solution
• DR-9 Verification (partially addresses LN-5)
  New „verification case“ as a type of analysis case supported to verify whether a subject satisfies a set of requirements

Structure modeling changes

• DS-1 Blocks (partially addresses LS-1)
  The generic term „block“ has been replaced by more specific, but still somewhat generic terms such as part, port, item, interface, etc.
• DS-2 Refinements (LR-1)
  Components and items may be redefined (:>>) as refinements across specialization hierarchies of their using elements
• DS-3 Features (addresses LN-3)
  Parts may now exhibit attributes, ports, actions and states as features
• DS-4 Attributes
  Value properties in v1 are now called attributes in v2
• DS-5 Derived Attributes (LF-1)
  Attributes may include a (potentially refined) derivation expression
• DS-6 Derived Multiplicities (LR-1, LR-2)
  Multiplicities may now be derived by being specified using expressions and through subsetting (:>) multiplicities may be subject to refinements including separation into distinct individual parts, ports and items
• DS-7 Items (LR-1)
  Flows across ports and connectors are now represented by item definitions or usages that may be subjects of actions
• DS-8 No Proxy Ports (LR-1)
  Parts of different composites may now directly be connected via ports without the need of proxy ports
• DS-9 Binding Connectors (LR-1)
  Binding connectors may now equate two ports on different hierarchy levels
• DS-10 Interface Definitions (LR-1)
  Interface definitions are now a kind of connector types connecting two types (definitions) of (conjugated) ports, specifying the exchanged items (definitions) that flow through the interface and may be decomposed into more specific interfaces (definitions)

Behaviour modelling changes

• DB-1 Actions (LF-2)
  Activities in v1 are now called action definitions in v2 and are more declarative than imperative as in SysML v1
• DB-2 Refined Actions (LF-2)
  Actions (definitions) may be specialized and refined (including inheritance) as well as decomposed
• DB-3 Action Composition (LF-2)
  Actions may be structurally (via allocations) as well as temporally (via successions of steps) composed to behaviours that will ultimately become performance features of components and systems
• DB-4 Performances
  Allocations are now called „perform“ (simple use) and „perform action“ (with instantiation and binding) dependencies from parts
• DB-5 Successions (LF-2)
  Flows between actions are now called  successions that imply temporal ordering that may be continuous or  discrete (one after the other)
• DB-6 States
  The metamodel of concurrent states has been simplified and states may include constraints and parts may exhibit states
• DB-7 Individuals (LS-2)
  Individuals (instances) with lifetime, timeslices (intervals) for temporal decomposition, snapshots and attribute values are now supported
• DB-8 Functions
  Reusable functions stem from a library of calculation definitions that may be instantiated as calculations with bindings as weak unification

How SysML v2 addresses the limits of SysML v1

Based on information from its pre-releases, I see the following limitations identified in the first part of my article addressed by SysML v2. The following limitations of SysML v1 are fully resolved by SysML v2:

• LN-3 (features): SysML v2 offers a variety of model elements that could act as features. Parts may declare a range from attributes (properties), perform actions (capabilities), exhibited ports and states to parts as their components. Furthermore, constraints may be used to express complex interdependencies among those features.
• LR-1 (block): By means of decomposable and refinable composition associations including refinable multiplicities components may now be formally refined into their parts. Furthermore, port refinement as well as direct port reuse across decomposition hierarchies greatly simplify modelling complex compound systems with complex interfaces. For example, a car that is a composition of 4 wheels and 2 axles (besides other parts) may be refined by connecting two of its wheels to its front axle and the other two to its back axle.
• LR-2 (associations): Decomposability of associations, particularly along their multiplicity not only simplifies complex components into their individual parts, but also decomposition of connections. For example, a single connection representing power cord between a plug and a device may be decomposed into three individually named wires.
• LF-1 (expressions): A comprehensive expression and function language (including extensive libraries) is specified in SysML’s underlying core language KerML. KerML standardizes all relevant basic as well as compound types such as various vectors or collections. It defines an abstract as well as a concrete syntax for expressions. Expressions may be used to specify constraint, derivations, performances, filters and more. The concrete syntax is still a little slanted towards OCL or common programming languages, which may make it a little difficult to read nor non-technical people. It provides no convenient form for specifying quantifiers or complex rulesets and offers no support for reflection.
• LF-3 (control): SysML v2 offers guard conditions on successions between actions as well as special types of actions called „control nodes“ that control the sequencing of actions (alternative or parallel successions as well as repeating successions).

The following limitations of SysML v1 are at least partially resolved by SysML v2:

• LN-1 (goals): There is no explicit support for goals, but Analysis Case support utilizes objectives as a notion. Via metadata requirements nay be „misused“ as objectives for example for analysis cases or verification cases.
• LN-2 (negative requirements): Although SysML v2 currently doesn’t include the notion of negative requirements or safety goals, any model element (such as requirements, parts, functions, etc.) could be adorned by metadata classifying it as „safety relevant“. Using a viewpoint and related view definitions, the subset of all safety-relevant model elements could be filtered and combined serving as the subject of a further safety analysis carried out e.g. by means of the dedicated complementary OMG language RAAML [4] (Risk Analysis and Assessment Modeling Language).
• LN-4 (usages): The execution of a use case may be specified using a sequence of actions, that may also involve multiple actors. Use cases may be specialized as well as included by other use cases, but UML’s <extends> semantics (including extension points) seems to be lost.
• LS-2 (interdisciplinary): Interfaces and items are now sufficiently general to express transfer of any type of refinable exchange of physical or virtual as well as continuous or discrete things (including parts) between two parts across their ports. Item flows may be subject to constraints such as Kirchhoff’s law constraining electrical current exchanged between two appliances or to dependencies described by cause/effect models. Properties of physical items may also include shape, geometry as well as coordinate frame information supported by SysML’s Geometry Domain Library. However, it is still hard to imagine, how complex schematics of an electrical or mechanical device shall be rendered using SysML v2.
• LV-1 (specialization): Specializations of definitions and usages come in three flavours called „subclassification“, „subsetting“ and „redefinition“ in SysML v2. Subclassifications imply inheritance of all kinds of features from one or more general definitions. Subsettings between usages restrict the number of members of the set represented by a subsetted usage. Finally, redefinitions redefine inherited features by means of more specialized definitions. Specialization currently focuses on structural inheritance of features in SysML v2. Behaviour inheritance such as state machine inheritance and polymorphic behaviour is not addressed by this pre-release of the SysML v2 specification although the corresponding section in the specification is still incomplete.
• LV-2 (options): SysML v2 supports a comprehensive and integrated approach to express variability and optional features „as built“ , including constraints. However, there seems to be little support for variability and optionality „as used“ , i.e. dynamic system configurability that changes over time. Furthermore, variations and variants (of components with features) are tightly coupled to their owning components. A separate (orthogonal) view focusing on features such as a feature tree with constraints as in Orthogonal Variability Modeling (OVM) [3] currently seems not to be supported by SysML v2.
• LF-2 (actions): SysML v2 doesn’t standardize a textual action language, but supports opaque actions which may be expressed in a referenced action language such as Alf. Furthermore, it offers so called „interactions“ that are used to express transfers and flows between components. SysML v2 defines a few atomic actions for assignment as well as sending and accepting items. However, the current release of the specification defines no actions to express dynamic changes of the system structure (see LD-1, LD-2 and LD-3 below) nor actions for exception handling and debugging (in simulations).

Unfortunately, the following limitations of SysML v1 are currently not at all addressed by SysML v2:

• LS-1 (data specification): The current pre-release of the SysML v2 specification offers simple datatypes, but almost no support to specify complex data structures such as records, tables, lists, maps, trees and more. Today’s systems are often data-intensive which means that these aspects need to be described using some other language.
• LD-1 (association instantiation): The declarative semantics required for model execution are not yet defined in the current specification. For example, there is no support in SysML v2 to express dynamics of the system structure such as establishing, breaking and changing associations or connections between components, items or chunks of data.
• LD-2 (part instantiation): The declarative semantics required for model execution are not yet defined in the current specification. For example, there is no support in SysML v2 to express dynamics of growing or shrinking systems where instances of components, items or chunks of data are dynamically created or destroyed. There is also no support for dynamic (re-)classification of instances.
• LD-3 (function instantiation): SysML v2 doesn’t provide a way to formalize a dynamically changing number of instances of similar, but concurrently executed processes (i.e. multiple action occurrences of the same action usage/definition). Particularly (partial) synchronization mechanisms and interferences among such concurrent processes could become very difficult to specify and/or analyse.
• LV-3 (parameters): On the one hand, SysML v2 doesn’t provide a built-in formalism to separate configurable properties of parts from „natural“ properties (however, this could be achieved by means of some metadata). On the other hand, due to its lack of support to represent complex data structures, it seems to be very hard to specify complex sets of configuration data often adhering some substantial interdependencies and constraints.
• LR-3 (interactions): Modeling (and simulating) complex interactions of multiple agents with and within the System of Interest (e.g. swarms) using SysML v2 is still hard to conceive. Although a bit clumsy, this could be achieved using executable UML by modelling a dynamic group of instances of active classes whose behaviour is specified by a composition of highly declarative state machines. Due to the lack of support for dynamic system structures in SysML v2 (see LD-1,LD-2 and LD-3), such a task could become even harder.

Summary and a Way Forward

SysML v2 passed the vote for adoption by the OMG end of March 2023. Compared to SysML v1, SysML v2 is certainly a big step into the right direction. Modeling features are supported much more comprehensively, including variability modelling. Decompositions of components and associations/connections is much cleaner than in SysML v1 Formalization has been improved via KerML’s expression and function semantics.

The biggest limitations that still remain are related to representing system dynamics. Actions that change a system’s structure during its lifetime are not yet fully elaborated. This is particularly due to the fact that the declarative execution semantics are still „work in progress“ in the current version of the specification. Specifying complex data structures is also poorly supported by SysML v2, causing the important discipline of software engineering being not well supported and modelers have to revert to UML.

Looking from a bird’s eye perspective, there are at least six categories of systems that are best designed using different modelling languages or combinations of them:

1. Single-discipline systems, such as mechanical or electrical components or pure software systems, e.g. a mechanical piston, an electrical inverter or an inventory management system. Model-based design of this type of systems is best done by dedicated modelling approaches such as mCAD or eCAD systems or UML tools.
2. Simple multi-discipline systems that are developed by a single organization, but require multiple engineering disciplines to coordinate and integrate the overall design of the system. Examples of such systems are washing machines, medical devices, or simple robots. Model-based design of this type of systems is best done by dedicated modelling approaches as mentioned in the previous category, but complemented by a systems engineering language such as SysML v1 or v2 for requirements engineering, designing the overall architecture of the system as well as for integration purposes.
3. Complex multi-discipline systems that are singletons composed of components collaboratively developed by multiple organizations and require some commissioning as well as multiple engineering disciplines to coordinate and integrate the overall design of the system. Examples of such systems are commissioned weapon systems, nuclear power plants or space ships. Model-based design of this type of systems is best approached by dedicated modelling approaches as mentioned in the previous categories, but complemented by modern systems engineering languages such as SysML v2 or BIM [1] for designing the overall architecture of the system as well as for integration and simulation purposes. They may also need some approach to integrate different modelling culture and styles as described in [5].
4. Complex mass products that are built from components developed in-house as well as components developed by third parties and that are highly customizable to meet specific customer needs. Examples of such systems are computers, automobiles or aerospace systems. Model-based design of this type of systems is best approached by architectural modelling approaches such as SysML v2 with deep variability modelling support, complemented by PLM systems.
5. Systems of Systems (SoS) that are built of highly interconnected multiple subsystems and/or many instances of COTS components that are typically provided as black boxes by third party organizations. These multi-discipline systems usually require highly customized overall architectures as well as complex commissioning with many dependencies and constraints. Examples of such systems are home energy systems, smart buildings or manufacturing systems consisting of people and machines. Model-based design of this type of systems is best approached by systems engineering languages such as SysML v2, complemented by data and constraint modelling languages for data preparation as well as simulation standards such as FMI [2].
6. Organic Systems of Systems (oSoS) that are collections of multiple independent systems that are interconnected, but that also exhibit some degree of autonomy and flexibility. These systems are designed as federations of autonomous devices and/or living components, often represented by digital twins that work together in order to achieve a common goal. They are usually need to be highly resilient by having the ability to adapt to changing circumstances or requirements. Examples of such systems are smart grids, dynamic transportation networks (e.g. railway or air traffic networks), smart organizations or smart cities. Model-based design of this type of systems go beyond the capabilities of SysML and need to be approached by advanced agent modelling and simulation languages.

With respect to the system categories identified above, SysML v2 is well suited to address the needs of categories 2 and 4 (for systems of category 2, even SysML v1 would be sufficient). For category 1, even SysML v2 is not precise/dedicated enough. For systems of category 3 and 5, SysML v2 is very helpful, but for architectural purposes only. Additional, dedicated modelling languages are needed to design these kinds of systems. Finally, the most sophisticated category 6 of systems definitively goes beyond the capabilities of SysML (v1 and v2) and needs to be approached by advanced agent modelling and simulation languages.

References

• [1] BIM
• [2] FMI
• [3] OVM
• [4] RAAML
• [5] Swickline Chris, „Method for developing SoS Architectures Using SysML Model Federation“
• [6] SysML v1.7beta
• [7] SysML v2.0 2023-02
• [8] UML 2.5.1