Binding of bound references

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.

Product tree of a drone subsystem for a forest fire detection system

Product tree of a drone subsystem for a forest fire detection system (click to enlarge)

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:

Product tree of a drone subsystem for a forest fire detection system with bound references

Product tree of a drone subsystem for a forest fire detection system with bound references (click to enlarge)

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

Binding of bound references

Binding of bound references (click to enlarge)

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:

Variants of a drone subsysteme with bound references

Variants of a drone subsysteme with bound references (click to enlarge)

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).

6 Comments

  • Klaas Gadeyne

    Reply
    3. November 2014at17:19

    Hi Tim,

    Thx for sharing this!

    Are the semantics of the “constraining decomposition” mechanism (exactly) the same as
    1/ when one would add a top-level property cameraBR to the drone system block and add an OCL constraint to the drone system that states that self.cameraBR = self.drones.camera?
    2/ when one would add a top-level property cameraBR to the drone system block and bind its value to self.drones.camera using a parametric diagram?

    In that case, am I right when stating that:
    – The advantage of the new construct is that one doesn’t have to know OCL (or parametrics)
    – The disadvantages of the new construct are that (i) it’s less flexible than OCL/parametric diagrams (imagine the case where the top-level property represents the diameter of a subsystem and the deeply nested property represents the radius of the subsystem) and (ii) it’s yet another concept that modelers have to learn

    BR,

    Klaas

    • Axel Scheithauer

      Reply
      5. November 2014at00:46

      Hi Klaas,

      Yes, that’s correct: The binding connector is the same as in parametric diagrams, so the diagram is in fact a parametric diagram (=no advantage), and OCL would also do the job.
      OCL allows more flexibility, but gives no visual representation of the constraint. It could constrain anything, so it’s hard to see what it constrains in this case. And in many cases this flexibility is not needed.
      Additionally the stereotype «boundReference» makes it easy to distinguish between the real property and the one that is only used for constraining the decomposition. Also defining them in a generic system documents how this generic system could get specialized. And finally bound references may specify an end path multiplicity. This makes it possible to specify that in each of the 4 wheel assemblies of my specific car the wheels shall be mounted with 5 lug bolts while the generic wheel assembly could have from 4 to 7 lug bolts (a parametric diagram can limit the number of lug bolts, but 20 lug bolts could still be distributed randomly like 4/4/5/7).
      It may be another concept, that modelers need to learn, but I think it is worth the effort, since it presents a standard way to define such often needed constraints. It also makes it easier to reuse generic assemblies that are defined in a library, opening the path to really useful standard libraries.

      Best regards

      Axel

  • 9. September 2015at22:54
  • Mudit Mittal

    Reply
    27. May 2016at12:31

    HI,
    We could have redefined the required part directly, instead of having create the bound reference. Does it create an additional advantage over that method?
    One advantage I see though, is that you can refer to properties of a part of the subsystem. For example, Camera is a part of Drone, which otherwise is inaccessible via attributes of ‘Drone Subsystem’.

    • 31. May 2016at07:50

      An advantage of bound references is that you can control the constraints on the whole structure from the single block that owns the bound references.

Post a Comment