This blog post presents the cross-cutting requirements for SysML v2. It is part of a blog post series about the upcoming new SysML v2 and SysML API & Services standard. The blog posts present the requirements for the standard stated in the request for proposals (RFP) published by the OMG. See end of this post for a list of all posts of this series including a link to the first post of the series that provides an overall introduction.
The cross-cutting requirements for SysML v2 apply to all model elements. Many of them are quite natural. Nevertheless, they must be specified.
We talk a lot about models. The model itself is also a model element requested by the RFP. SysML v1 also has a model element Model. It is a container and namespace for all model elements.
Another important requested top-level element is the model library. It is also already part of SysML v1.
Both – model and model library – are a container for other model elements. SysML v2 shall also provide a general container element, i.e., a model element that contains other distinguishable model elements. In SysML v1 this is a Package.
On the first view, a group is similar to a container. However, elements of a group are members, but not contained, and the group is not a namespace. SysML v2 shall provide a group element and a relationship between a group and the members of the group. SysML v1 also has such an element called ElementGroup. Due to the underlying UML, the capabilities of the SysML v1 ElementGroup are a little bit limited.
Several requirements for SysML v2 are about basic capabilities of a model element like…
- …a unique universal identifier. Beside others, that enables the assignment of URI’s and the access via an API.
- …a name and aliases. It is quite apparent that most model elements need to be named. Some elements do not need a name, or it is optional like some relationships. Not available in SysML v1 is the capability to define aliases (except using the element import relationship).
- …a description field. In SysML v1, typically, a modeling tool provides a description field for a model element. However, it is not part of the language. Now, it is requested for SysML v2.
- …an annotation. It is a text string that, for example, a navigation link to another internal or external entity, or just a note. In addition to a navigation link included in an annotation, SysML v2 shall also provide a separate navigation relationship between a model element and another internal or external element like a hyperlink. Most SysML v1 modeling tools already provide hyperlinks, but it is not part of the standard yet.
A non-mandatory requirement for SysML v2 asks for a root model element that contains features that apply to all other model elements. In SysML v1 respectively UML the metamodel has such a root element simply called “Element”.
Problems & Risks
Systems engineering is a lot about problem-solving and risk management. SysML v2 shall provide model elements for problems and risks with appropriate attributes.
Another set of requirements asks for several relationships between model elements:
- A general directed relationship between model elements without any further semantic. Extensions of SysML can use it as a basis to define their specific relationships. SysML v1 respectively the underlying UML does not provide a semantic-free directed relationship. The most general one is the dependency relationship with the dependency semantic. That is, for example, the reason for the confusion about the direction of the allocate relationship that is based on the dependency relationship.
- Deriving a relationship from other relationships should be possible — for example, a connector between two parts derived from a connector between nested parts. In SysML v1, those connectors cost significant modeling effort, and there is no standard way to describe the derived relationship.
- A dependency relationship between model elements.
- A cause-effect relationship between model elements; SysML v1 does not have such a relationship.
- An explanation relationship between elements representing a rationale and the elements explained by the rationale.
- A refine relationship specifying that model elements refine model elements.
- A conform relationship to model that elements conform to other elements.
- An allocate relationship like in SysML v1.
- A copy relationship to enable reuse of catalog items. SysML v1 already provides a copy relationship between requirements.
A hot topic in MBSE is the modeling of variants. Although it is already possible to that with SysML v1 (e.g., VAMOS), it is not explicitly provided by the language, and the lack of a standard is a stumbling block for necessary tool support.
SysML v2 shall provide capabilities to represent variants. The requirements for variant modeling are aligned with ISO/IEC 26550:2015. The following variant concepts are requested for SysML v2:
- Variation point to mark features that can vary.
- Variants that correspond to variation points.
- Variability expressions to construct valid variant configurations, for example, exclusive-or or requires constraints.
- Variant binding to link a variant and the model elements that vary.
Views and Viewpoints
Views and Viewpoints are a crucial concept in system architecting. It is part of SysML v1, but unfortunately rarely used in practice for various reasons.
SysML v2 shall have the capability to define a view. A particular view can be, for example, a diagram or a generated document. SysML v2 shall also have the capability to define a viewpoint that specifies the requirements of a view based on a set of stakeholders and their concerns.
The view and viewpoint concepts are aligned with ISO 42010.
SysML v2 shall provide the capability to apply metadata to model elements:
- a version,
- a timestamp,
- data protection controls, for example, specifying a security classification.
The next blog post covers the requirements about properties, values, and expressions capabilities of SysML v2. Stay tuned!
Previous blog posts of this series:
- NextGenSysML Part 0 – Next Generation Modeling: SysML v2 and SysML API & Services – Introduction
- NextGenSysML Part 1 – Overview SysML v2 and SysML API & Services RFP’s
- NextGenSysML Part 2 – The General OMG Requirements
- NextGenSysML Part 3 – Language Architecture and Formalism Requirements
Planned future blogs posts:
- NextGenSysML Part 5 – Properties, Values & Expressions Requirements
- NextGenSysML Part 6 – Structure Requirements
- NextGenSysML Part 7 – Interface Requirements
- NextGenSysML Part 8 – Behavior Requirements
- NextGenSysML Part 9 – Requirements Requirements
- NextGenSysML Part 10 – Verification Requirements
- NextGenSysML Part 11 – Analysis Requirements
- NextGenSysML Part 12 – Example model and Conformance Requirements
- NextGenSysML Part 13 – SysML API & Services Overview
- NextGenSysML Part 14 – API & Services: Architecture Requirements
- NextGenSysML Part 15 – API & Services: Conformance Requirements
- NextGenSysML Part 16 – API & Services: Service Requirements