What's new in SysML 1.4 - Constraining decompositions

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Dieser Blogbeitrag wurde zuerst in meinem englischsprachigen MBSE-Blog veröffentlicht. Daher ist dieser Beitrag in englischer Sprache.

The fourth part of the blogpost series about the changes in SysML 1.4 presents the new concept to constrain a decomposition hierarchy.

The following figure shows a simple product tree of a drone subsystem (DS) for a forest fire detection system (FFDS). It is the sample system I've also used in some previous posts.

[caption id="attachment_866" align="aligncenter" width="300"] Product tree of a drone subsystem for a forest fire detection system (click to enlarge)[/caption]

The structure allows different configurations of drone subsystem instances due to the multiplicitiy of the camera and the heat sensor and generalization of the camera. For instance drones with 2 standard FFDS cameras and no heat sensor or 1 highend FFDS camera and 1 heat sensor and so on.

SysML 1.4 introduces a new model element to constrain decomposition hierarchies. It is called bound reference. It  is a marker to highlight properties that are connected to other properties with a binding connector to constrain them. The binding connector specifies that the values of the connected properties must be the same.

The following diagram shows the definition of the bound reference properties for the drone subsystem:

[caption id="attachment_865" align="aligncenter" width="300"] Product tree of a drone subsystem for a forest fire detection system with bound references (click to enlarge)[/caption]

The bound reference properties are connected with the appropriate properties in the decomposition hierarchy with a binding connector:

[caption id="attachment_864" align="aligncenter" width="300"] Binding of bound references (click to enlarge)[/caption]

The bound reference bindingPath is a derived property. The value specifies the path from the enclosing block to the connected property and could be derived from the binding connector relation.

The type of the bound reference must be compatible with the type of the connected property. Otherwise the values of properties could not be the same.

In our example the types are the same (Camera and Heat sensor). The multiplicity of the bound reference is more general than the multiplicity of the connected properties. Therefore it is not necessary to update the multiplicity each time when the multiplicity of the connected properties changes, for example due to a change of the requirements or a new architecture decision..

Now it is easy to define special drone subsystem configurations. For instance drones with 2 standard FFDS cameras and no heat sensor or drones with 1 highend FFDS camera and 1 heat sensor:

[caption id="attachment_867" align="aligncenter" width="584"] Variants of a drone subsysteme with bound references (click to enlarge)[/caption]

Of course the concept of the bound reference properties could be used for the modeling of variants (for example see my blogpost Variant Modeling with SysML).