Context modeling with the SysML block

The block is one of the best known and most important elements of SysML. However, in practice, I often see confusion and errors in its use, especially on the whiteboard, particularly among beginners.

This article is intended to help beginners in particular not to get into the wrong habit and to use the SysML block themselves as quickly as possible. Modeling the system context is a good example of this. And that's what this article is about.

Experienced SysML experts will probably find this article boring. However, they can look for errors (guaranteed) and write their own tips on blocks in the comments.

Important distinction: Definition and use of the block

In SysML we encounter blocks in two different contexts, which can lead to confusion, especially for beginners. On the one hand, blocks can define the properties of an element that is of interest to us. They then appear in the block definition diagram (bdd). On the other hand, we can also record the use of the blocks. They then appear in the Internal Block Diagram (ibd).

Especially on the whiteboard: Do not mix block definition diagram (bdd) and internal block diagram (ibd)!

A context can be modeled with either bdds or ibds, both have their justification. If we are modeling in the tool, then we need both (at least with SysML 1.x.). With SysML v2 the definition can be omitted).

Simple example: Charging a cell phone

This example comes from the video embedded below. We want to model the context for charging a smartphone. To do this, the following four parts, which are all part of the system context, interact:

If we remember the Last week's article on modeling the system context the first thing we notice is that there is no "system of interest" that forms the center of our star-shaped context diagram. This is not unusual and is particularly common in System of Systems. In such cases, it is usual to introduce the system context as a separate element.

All blocks

With the four elements listed above, we therefore have five elements, each of which we model as a SysML block. The relationship is trivial in this case: the four elements are all parts of the context. We can record this visually in a block definition diagram (bdd) using a composition relationship:

Whether the "effort" for a bdd on the whiteboard is worthwhile should be questioned. When modeling in the tool (SysML 1.x), we have to create the blocks, but creating the diagram is optional.

In practice, there are many other use cases for bdds besides context modeling.

Use of the blocks

Not all properties of the blocks are visible in the diagram. However, these can optionally be displayed in compartments. As we want to deal with the connection of the four blocks here, we can display the ports in the bdd:

In addition to ports, blocks can have many other properties, such as values, constraints, operators and much more. The parts are also part of the block and can be displayed in a compartment.

However, even if we were to display the ports in Figure 2, we would still have no information about the use of the ports. We would only have a SysML representation of Figure 1, for which we need an Internal Block Diagram (ibd).

Modeling use in the glass box

The frame of an Internal Block Diagram (ibd) always corresponds to a SysML block. In this case, let's look at the inside of the context, which looks like this:

Intuitively, the image is quite easy to understand, as it shows how the iPhone is connected to the charger via the cable, which is plugged into the wall socket. But what is going on here in detail?

We can already see visually that the symbols in Figures 2 and 3 are different: In Figure 2 we have block definitions, in Figure 3 we have instances of blocks. In the object-oriented world this is comparable to classes and objects (objects are instances of classes).

This can be confusing, especially for beginners: We often have exactly one instance of a block, as in this example. But that doesn't have to be the case.

Understanding the identifiers of the block instances

As the boxes are instantiated blocks in ibd, they also have identifiers that consist of two parts, for example "box : Charger Box". Here, "box" is the name of the instance and "Charger Box" is the corresponding block definition.

If we are only dealing with one instance of a block, we can also omit the identifier. Then we can still recognize from the colon that it is a block instance. For example, ": ChargerBox".

Wiring blocks

With the ibd, the focus is on understanding how the parts are used. In Figure 3, we can see from the relations how the four parts are connected to each other and how the energy flows from the Wall Outlet via the Charger Box and Charger Cable to the iPhone.

This already shows why modeling represents added value:

• We recognize ports that have been defined but not used (ports without connection)
• We recognize that connected ports must be compatible

We do not need a diagram to realize this added value. Modern tools can automatically perform this check using the model. However, modeling an ibd on a whiteboard can also contribute a great deal to communication, even if we can "only" check the diagram visually.

Ports often have to be complementary (plug vs. socket). The concept of "conjugated ports" was abolished with SysML 1.6. Tim Weilkiens explains why in Conjugation Considered Harmful!

Nesting

Based on the designations in Figure 3, we can guess that there is much more to the diagram than meets the eye. Let's take a closer look at the connection between the Charger Box and the wall outlet. Using the tilde (~), we can see that "Standard Wall Plug" represents the socket on one side and the plug on the other. We can also see "GND" and "Power". If we are modeling with a tool, we can go one level deeper here:

Here again, we have the advantage that tools enable us to validate the consistency of the system. Of course, we can only validate what has been modeled. In this example, if we model the voltage but not the current, the system can warn us if the wrong voltage is connected, but not if the power (current flow) is too high.

Conclusion

We now come across the SysML block so often that we should at least know the basics. When reading, it is important that we understand that we encounter blocks in two different contexts, as a definition and in use. Both have their right to exist.

When we start sketching connections on the whiteboard, it is particularly important to internalize this difference. Nothing is more confusing than mixing ibd and bdd. On the whiteboard, ibd is often more helpful.

Video

I have taken several images from this short video, which shows very nicely how block definition and use interact:

Photo by Thomas Kolnowski on Unsplash