From hardware to software: HAL as a central element for black box modeling

Software has long been the dominant component of complex systems. In practice, however, many architects find it difficult to effectively break down the system into subsystems that can be treated like a "black box" due to the high proportion of software. However, this is necessary in order to master the complexity of modern systems. An effective solution is the use of hardware abstraction layers (HAL). I deal with this:

• The dilemma of the system boundaryIn a system with hardware and software, it is difficult to find a clear demarcation.
• Case study: Smart Trash CanA practical example shows how MBSE can help to structure an intelligent waste separation system.
• Interface modelingThe direct approach of mapping physical signals and sensor connections in SysML leads to complex models that are difficult to understand.
• Hardware Abstraction Layer (HAL)A logical API hides physical details, enabling clean "black box" modeling.
• Define APIs correctlyA sophisticated API facilitates integration, testing and variant management.
• Advantages of the HAL architectureClear system boundaries, easy interchangeability of components, improved testability and agility in development

MBSE workshop on March 12, 2025In my training course on SysML & MBSE at Embedded World in Nuremberg, you will learn how to use SysML in practice. Register now to Class 5.3 and 15% save with code EWC25CLD.

The dilemma

In a system that consists of both hardware as well as software it is often difficult to draw a clear line. A classic example is the control unit: where does it actually belong? Many subsystems use the same control unit. In a model at system level, the question arises as to how we can represent this dependency in a meaningful way.

With MBSE, we have to decide explicitly which interfaces we model. A widespread but often problematic solution is the direct modeling of input and output pins. In SysML, this can quickly lead to a confusing number of signals and connections that make the model difficult to understand and maintain. Not only that: the "black box" is broken open as a result.

Before I present the solution, I would like to introduce the case study that I will use to explain the procedure.

Case study

Wouldn't it be nice to have a waste garbage can that separates the waste correctly itself? This system is ideal for training courses, because:

• It's easy to understand.
• It has little ComplexityNevertheless, all the problems can be presented well.
• It can be built quickly and cheaply for practical workshops.
• As a rule, it is "unfamiliar" to training participants, which means that long discussions with domain experts can be avoided.

The already exists, of course:

In the following, we will use a system similar to that of Bin-e, which consists of 6 subsystems:

For introductions to SysML, I recommend working informally at the beginning (without SysML) so as not to leave the participants hanging.

TrashIntake subsystem

Before we model formally with SysML, I would first like to show how the TrashIntake should look informally. As we can see in the following picture, the TrashIntake should have a motorized door. We can use two sensors to determine whether the door is open or closed.

Naive interface modeling

The system boundary can already be seen in the image above. We could now derive the interfaces directly from this. That would be in this case:

• Opening for throwing in the waste
• Throw onto the tray of the TrashSorter
• Contacts to the two sensors
• Electrical connection of the motor

Although this approach is not wrong, it does mean that an enormous added value of the MBSE is lost. This is because we have physical interfaces modeled. However, this approach lacks the control logic of the TrashIntake. And if the control logic is missing, then we don't have a "black box".

When we model subsystems, we work at the logical level. It is a common mistake to adopt the interfaces of the physical components one-to-one!

For this reason, for all MBSE methods we have Logical interfaces. The challenge here is to decide which interfaces (and subsystem elements) are necessary to incorporate the control logic.

The control system plays a special role here: For example, we could connect our Smart Trash Can to a Raspberry Pi (Raspi) operate. Of course, the TrashIntake would not have its own microcontroller. Instead, a Raspi would take over all software functions for all subsystems. But how can we model this and enable black box modeling at the same time?

Modeling a black box subsystem with a hardware abstraction layer (HAL)

At this point, it makes sense to go through the identified interfaces and question whether or not they need to be visible outside the black box. If not, then we need an abstraction. As a rule, the logical interface then takes the form of an API. Let's take a look at the four interfaces from this point of view:

• Opening for throwing in the waste - Keep: This interface exists at user level.
• Throw onto the tray of the TrashSorter - Keep: This interface connects TrashIntake and TrashSorter and is therefore required for integration.
• Contacts to the two sensors: Abstraction: The control logic, which is part of the black box, uses the sensors, but nothing outside our subsystem.
• Electrical connection of the motor: Abstraction: We do need a power supply for the motor, but the control of the motor is part of the black box.

API for the subsystem

This way of thinking and a "software first" or "software defined" approach gives the API an enormously important role. The quality of the API has an impact on:

• The black box behavior of the subsystem
• The testability of the subsystem
• The effort to develop this subsystem mockif other subsystems need it for testing
• The effort to create variants of the subsystem
• The flexibility to further develop the subsystem independently of the rest of the system.

In this case, we need an API with which we can open and close the door and query the status of the door.

export type DoorState = "OPEN" | "CLOSED" | "MOVING" | "UNKNOWN";
export interface DoorControl {
  /**
   * Opens the door. If the door does not open within the defined
   * time limit, an exception is thrown.
   * @throws Error if the door was not opened successfully.
   */
  openDoor(): Promise;
  /**
   * Closes the door. If the door does not close within the defined
   * time limit, an exception is thrown.
   * @throws Error if the door was not closed successfully.
   */
  closeDoor(): Promise;
  /**
   * Returns the current state of the door.
   * @returns The current door status as DoorState.
   */
  getDoorState(): DoorState;
}

Modeling the logical subsystem in SysML with HAL

Based on the above, this subsystem could be modeled in SysML as follows:

IntakeDoorHAL is the Hardware Abstraction Layer (HAL), which now transfers the logical function mapped in software to the hardware in the form of control and sensor signals. The IntakeDoorHAL takes on the task of translating from the software world (API calls) to the hardware world. This means that it is not necessary to make sensor or motor cables visible outside the subsystem.

IMotorPower, which is provided to the subsystem as an energy source, is interesting at this point. The HAL is responsible for passing this on to the motor with the correct polarization at the right time.

Where is the control unit?

As this is a logical architecture the allocation to physical components is missing. For most blocks, this is a (more or less) obvious 1:1 relationship (motor, sensors, door). With the HAL, however, there is much more to it: The HAL requires a control unit (hardware and software) in the finished system, but this is also used for other systems. This also applies to the operating system of the control unit and possibly to other elements.

The actual HAL is a software that must match the selected architecture and implement the API shown above. Furthermore, the HAL must also be configured (e.g. the mapping of the sensors and motor control to the pins of the RasPi must be configured). However, these aspects are not relevant for the logical view.

Advantage of this approach

• Impenetrable system boundaries: The biggest advantage of this approach is that we have clean system boundaries and therefore a "black box" that is highly independent of the rest of the system.
• Easy replacement of componentsIf a component has not yet been fully developed, a subsystem with the same function can still be provided. This has Joachim Pfeffer successfully deployedto have a continuously running system.
• Automated testing: The actual functionality is now in the software and can be relatively easily tested automatically:
  • To test the software, the API can be tested directly while the control signals (sensors, motor) are mocked
  • A test protocol can be created for the entire subsystem, which feeds the API with clearly defined inputs. Fully automating the subsystem test is more complex and usually requires test robots.
• Improved variant management: As long as Variants can operate the interfaces, an exchange should be possible without any problems. This is practiced, for example, by SpaceX during the development of the Raptor enginesof which no two are identical.

How will the development continue?

The approach presented here for modeling logical subsystems with clean interfaces and HAL for connecting hardware and software is enormously powerful. However, this is less due to the modeling than to the methodology.

SysML is not necessary to use the modeling of subsystems presented here

In particular, I didn't have to model the inside of the block at all: What counts is a clear understanding of the IntakeDoor's interfaces. The team that installs the IntakeDoor does not need to know how many sensors are provided. I would even add provocatively: The overly detailed modeling can even do harmas it restricts the creativity of the team.

Specifically, the interfaces alone are not enough to develop the subsystem. I have left out a lot in this article, for example the requirements. A completed specification could now be passed on to the design department to concretize the subsystem.

Alternatively, a further refinement with SysML is conceivable, in which the function could be mapped using state machines and activity diagrams. Which approach makes sense depends on the complexity of the system and the team's level of knowledge.

Conclusion: HAL irreplaceable for sensible black box modeling

If you want to map modern systems properly with MBSE, there is no getting around the topic of HAL. Software-defined systems are being talked about everywhere, especially in the automotive sector. If functionality is not properly abstracted in software via HALs, then the system will blow up in our faces during integration at the latest.

Photo by ThisisEngineering on Unsplash