NextGenSysML Part 6 – Structure Requirements
This blog post presents the requirements for structure modeling with SysMLv2. 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 modeling of structures is one of the main pillars of system modeling. In SysML v1, the essential elements of structure modeling are the blocks and parts with appropriate relationships, and the block definition and internal block diagrams.
Of course, SysML v2 will also provide capabilities to model structures, and they will be similar to SysML v1. The central element will be a modular unit of structure that defines value properties, interface ends, constraints, and other structural as well as behavioral features. That model element can be used to model building blocks of a system architecture, items that flow through the system, data, concepts, and other structural elements.
The RFP calls this model element Definition Element which does not mean that this will be the same name of that element in the final SysML v2. In SysML v1, this model element is called a Block.
SysML v2 shall also provide a usage element that represents the usage of a definition element in a specific context. In SysML v1, this is, for example, a part property.
SysML v2 will have a special focus on the modeling of usages. It is the most intuitive modeling of structures for engineers. Except for the software engineers, most system modelers struggle with the concept of block definition and block usage (parts) in SysML v1. With SysML v2 you can – simply said – model ibd’s without bdd’s.
SysML v2 shall provide basic structure modeling capabilities like
- Hierarchical composition structures of definition elements (in SysML v1: blocks and part properties).
- References from one element to another element (in SysML v1: associations with aggregate kind none or shared (aggregation))
- Multiplicities for usage elements
- Generalization/Specialization
More exciting is the requirement for a capability to model structure with variability. In the blog post NextGenSysML #4, I already presented the SysML v2 cross-cutting requirements for variant modeling. The requirement “Structure with Variability” is specific to the modeling of structures. At each level of a decomposition structure, a variant from different possible variant choices can be selected. A non-mandatory requirement requests the additional capability to auto-generated a tree of elements based on a set of rules, i.e., you can generate a single variant from a configuration space.
SysML v2 will also provide better support for modeling deeply nested structures. For example, to specify values of part properties deeply nested in the system structure. That includes the capability to locally override, redefine or add features to the features defined by the type.
The Digital Twin is on everyone’s lips. SysML v2 shall include a capability to model the structure of an individual, for example, a digital twin (depending on your definition of a digital twin). In SysML v1 you can already model instances, but the expressiveness is very limited.
The next blog post covers the requirements about the capability of SysML v2 to model interfaces. 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
- NextGenSysML Part 4 – Cross-cutting Requirements
- NextGenSysML Part 5 – Properties, Values & Expressions Requirements
Planned future blogs posts:
- 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 – SysML API & Services: Architecture and Conformance Requirements
- NextGenSysML Part 15 – SysML API & Services: Service Requirements
2 Responses
Are there any improvements coming for multiplicity? In SysML V1 one of the most confusing things for a beginner is to show “airplane” as having “wing” with multiplicity “2” only to find that there is no way to address the “left” and “right” wing…(except for in a sequence diagram, an obscure UML feature that does not link to anything else and which not all tools support).
The SysML V1 solution of showing multiple composition relationships between “airplane” and “wing” in order to show roles for “left” and “right” wings is likewise confusing for beginners.
Finally, having the multiplicity hard-coded rather than referencing a parameter that can be defined at the top of the model is very limiting. Ideally, the multiplicity for “cooling fan” should be settable as the result of a parametric calculation based on expected power dissipation, etc…
My wish would be for the possibility to set multiplicity by a value that can be used elsewhere in the model (“number_of_wings = 2”) and optionally to provide a set of names (“wing_names = {‘left’, ‘right’}” or something similar…
Any movement in this arena?
Thanks!
Typically, you model a left and a right wing by part properties. One part property for each wing with multiplicity 1. If you have a detailed model, the type of both properties would be different because the wings are not the same, but similar. You can use generalization to model the common parts.
Most beginner struggle with the block definition diagram. The internal block diagram is much more the kind of modeling that engineers are used to: boxes representing parts connected with lines, and tiny boxes for interfaces.SysML v2 will focus on this kind of modeling which will make the life for engineers much easier.
Parameters for multiplicities are under discussion.