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
- Centered
- 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:
AbstractRequirement.allInstances().base_NamedElement->includes(self.base_Abstraction.supplier)
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.
Property-specific Type
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.
Conjugated Ports
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.
6 Responses
Sadly, I don’t think that many of these changes clarify things. Or possibly the examples are misguided.
For example, as you state, a door is not a type of lock, but simply has a lock, which you could model as either an interface or a part, as you wish. Neither is a robot a type of lock, so the same logic follows. By using a bad example like this you are not clarifying the situation or the example.
I also disagree regarding the BDD. They are an essential aid to ensuring that types are not duplicated in models, especially large models where you may want to encourage reuse. By minimizing its use, it will allow people to model more quickly, but I think that models will be poorer as a result.
For small one-off projects this is fine, but normally these types of projects don’t use SysML extensively in my experience.
Regarding the bdd it is the other way round. For projects that manage large block definition models, part property definitions with associations are very cumbersome. The relevant information is the existence of the part properties. The existence of the associations and the properties at the other end of the association are not needed, but they are part of the model. That costs a lot of effort: layouting bdd’s, defining the associations correctly with all its properties (navigation, ownership, etc.), and so on.
Anyway, finally, it is a matter of taste. SysML now allows both approaches.
Regarding the door example: the basic problem is the overloading of the generalization. Here, it is also used to model interface realization. You could have a part property of type Lock in the door block, but on the one hand it forces the modeller to to detail the block, which otherwise might not be necessary, and second, you still have the problem on the side of the robot. The robot could own a part property of type Key, but to assure that it is conform to the type of the conjugated port, you need a relationship to the interface block.
Concerning conjugated ports:
Why do I need to specialize Door from Lock at all if there is already a proxy port typed by Lock?
Isn’t that sufficient?
Thanks
The Generalization between Door and Lock assures that Door implements the features of the interface block. The proxy port is a proxy for the Door, i.e., it is a behavior port.
Concerning Property Specific Types:
Why is the association storedItems pointing to Warehouse Items and not Object?
When you add the machine to the slot, the type of the machine instance spec is not related to the slot
type. Isn’t that a problem?
And why do I need <>? What does it add?
Thanks
Max,>”? That’s the stereotype notation of the property specific type. The type is only valid in the context of the property.
The association points to WarehouseItem, because only WarehouseItem things should be part of the list to have the storedAt information. It is a design decision.
The type of the machine instance specification includes WarehouseItem. So, it fits to the type of the storedItems property.
What do you mean by “And why do I need <>?”. Did you write “<
/Tim