What’s new in SysML 1.6?
This blog post introduces the changes to SysML version 1.6 that are relevant for modelers. I skip those changes that only affect the specification document like fixed typos or rewordings. You may also be interested in the blog post series about the changes to SysML version 1.5.
SysML 1.6 was finally published on December 5th, 2019. You can find the specification document on the OMG website www.omg.org/spec/SysML. There you can also find the list of all SysML specifications published so far. The OMG specification documents are available for free.
The SysML 1.6 was authored by the SysML 1.6 Revision Task Force (RTF). Members of the RTF are representatives of different companies that are members of the OMG. Among them are tool vendors like NoMagic, respectively Dassault, PTC or IBM, industrial users like NASA or Airbus, and other organizations like NIST or my company oose. Yves Bernard from Airbus, Robert Karban from Nasa JPL, and I chaired the SysML 1.6 RTF.
An RTF works through a list of issues that can be submitted by anyone who has found something suspicious in a standard. The form to report an issue can be accessed on the OMG website at issues.omg.org/issues/create-new-issue.
The RTF discusses each issue, and finally, the members of the RTF create resolution proposals and vote to accept (or reject) them.
End of last year, the SysML 1.7 RTF has started to work on the next revision 1.7 of SysML. Yves Bernard from Airbus and myself from oose chairs the RTF.
In parallel, the work on the next generation of SysML has also started: SysML v2. Check out the blog post series about the next generation of SysML.
Now, let’s have a look at the changes in SysML 1.6:
Some minor changes
Most of the changes were minor things. The following list presents some of them:
Compartment names shall comply with the following notation: Shown in italics, where permitted by the font in use, and
- All lower case
- Words separated by spaces
The following figure depicts an example of a compartment with the headlines following this notation convention:
The enumerations FlowDirection, FeatureDirection, and ControlValue, are renamed to FlowDirectionKind, FeatureDirectionKind, and ControlValueKind to satisfy the naming convention of enumeration types that the name should have the postfix “Kind”.
The BindingConnector now has an additional alternative notation. In combination with proxy ports, the binding connector appears very often in internal block diagrams, and the keyword «equal» clutters the diagram. With SysML 1.6, you can alternatively use the symbol =. The next figure illustrates the new alternative notation.
More formalism: OCL instead of Text
Part of the definition of a SysML model element is often a list of constraints, for example, the satisfy relationship has the constraint: “The supplier shall be an element stereotyped by «requirement» or one of «requirement» subtypes.” The constraints written in natural language are understandable but sometimes not sufficiently precise and verifiable by a modeling tool.
Wherever possible, SysML 1.6 now provides formally defined constraints statements written in OCL. In summary, 22 pages of OCL statements have improved the SysML specification. For example, the constraint of the satisfy relationship about the supplier mentioned above is now also specified in OCL by:
Please note that the constraint has also been fixed by replacing the element Requirement with AbstractRequirement that was introduced with SysML 1.5 (see blog post about the changes in SysML 1.5)
Block-typed Properties without Associations
A major change in SysML 1.6 is the removal of the constraint that properties typed by a block must be defined as an end of an association. In practice, you can now, for example, create part properties in an internal block diagram without modeling a composition association relationship.
In the model, you still have the blocks (types of the part properties). What’s missing are the association relationships. So, you cannot visualize the decomposition structure in a block definition diagram. The benefit of this diagram is very small, in contrast to the effort for creating the diagram. Most engineers are only interested in the internal block diagram views.
Another advantage is that you have fewer model elements to store and maintain in the model. Modeling an association creates 3 elements in the model: the association itself and one property at each association end. If you model the property without an association, you only create 1 element in the model.
If you like, you can still model the properties with an association relationship. SysML 1.6 only removed the constraint that it is mandatory.
By the way, SysML v2 will support the usage-oriented modeling approach. Simply said it means, modeling ibd’s without bdd’s.
Do you know property-specific types? No? No wonder, because SysML very badly specifies them. The tool support is correspondingly bad. The filed issue about property-specific types states:
- The definition of a property-specific type cannot be shown on a bdd.
- No runtime semantics is given.
- No examples of the property-specific type are given.
SysML 1.6 clarifies the property-specific type definition and makes some minor adaptions. The following figures depict an example of an application of the property-specific type.
The block definition diagram defines two simple blocks specialized from the very common abstract block Object. The Warehouse references a list of items that are stored in the Warehouse, and the Warehouse block is the namespace of the property-specific type Warehouse Item. The property-specific type is depicted by the applied stereotype <<pst>>.
Based on these blocks, we specify an instance specification of a machine and an empty warehouse.
Now we store the machine in the warehouse, i.e., we assign the instance specification ProductX to the set of stored items. This also gives the instance specification the property-specific type and the storedAt property defined with it.
When the instance specification ProductX is removed from the set of storedItems, the value storedAt is also automatically be removed.
SysML 1.6 fixes a serious problem with the modeling of conjugated ports.
The following figure shows a simple definition of a door with a proxy port that represents the lock typed by an interface block. In addition, the door specializes the interface block to guarantee that the block implements the specified interface features. Note that this is a technical usage of the generalization relationship to specify the interface realization. Conceptually, it does not make sense: the Door is not a kind of a Lock.
In the digital age, the opposite part is a robot that has the keycode for the door lock. In the first attempt, the definition is similar, but with a conjugated port, i.e., the key does not have direction “in”, but “out”.
By the way – do not even think about connecting both ports in the block definition diagram. It looks tempting but is completely wrong. You connect them in the internal block diagram (usage versus definition).
On the second view, you will realize that the definition of the Robot does not work. It inherits the flow property “in k:Keycode”, but it should be “out k:Keycode”. You need something like a “conjugated generalization” relationship. As a workaround, I’ve defined such an element in the SYSMOD profile.
Now, the issue is fixed in SysML 1.6, but not with a conjugated generalization relationship. A new special conjugated interface block called ~interfaceBlock does the job. The conjugated interface block references the original one. The notation is the same as for the conjugated port mechanism. From the diagram perspective, it looks the same. However, behind the scenes, not the conjugated port mechanism is used, but the special conjugated interface block.
It is intended that most of the modeling is automatically performed by the tool and should not bother the modeler.
These were all modeler relevant changes in SysML 1.6. If you would like to see all changes, check out the specification document with change bars. You can download it from the SysML specification page on the OMG website.