Von Hardware zu Software: HAL als zentrales Element für die Black-Box-Modellierung

Software ist längst der dominierende Bestandteil von komplexen Systemen. In der Praxis fällt es vielen Architekten aber schwer, durch den hohen Bestandteil an Software, das System effektiv in Subsysteme herunterzubrechen, die wie eine „Black Box“ behandelt werden können. Das ist jedoch notwendig, um die Komplexität von modernen Systemen zu beherrschen. Ein effektiver Lösungsweg ist der Einsatz von Hardware-Abstraktions-Layers (HAL). Dabei behandle ich:

• Das Dilemma der Systemgrenze: In einem System mit Hardware und Software ist es schwierig, eine klare Abgrenzung zu finden.
• Fallbeispiel: Smart Trash Can: Ein praxisnahes Beispiel zeigt, wie MBSE helfen kann, ein intelligentes Mülltrennungssystem zu strukturieren.
• Schnittstellenmodellierung: Der direkte Ansatz, physikalische Signale und Sensorverbindungen in SysML abzubilden, führt zu komplexen und schwer verständlichen Modellen.
• Hardware-Abstraktions-Layer (HAL): Durch eine logische API werden physikalische Details verborgen, wodurch eine saubere „Black-Box“-Modellierung ermöglicht wird.
• APIs richtg definieren: Eine durchdachte API erleichtert die Integration, das Testen und das Variantenmanagement.
• Vorteile der HAL-Architektur: Klare Systemgrenzen, einfache Austauschbarkeit von Komponenten, verbesserte Testbarkeit und Agilität in der Entwicklung

MBSE-Workshop am 12. März 2025: In meiner Schulung zu SysML & MBSE auf der Embedded World in Nürnberg lernst Du, SysML praktisch einzusetzen. Jetzt anmelden zur Class 5.3 und 15% sparen mit Code EWC25CLD.

Das Dilemma

In einem System, das sowohl aus Hardware als auch aus Software besteht, ist es oft schwierig, eine klare Grenze zu ziehen. Ein klassisches Beispiel ist das Steuergerät: Wo gehört es eigentlich hin? Viele Subsysteme nutzen dasselbe Steuergerät. In einem Modell auf Systemebene stellt sich die Frage, wie wir diese Abhängigkeit sinnvoll darstellen.

Beim MBSE müssen wir explizit entscheiden, welche Schnittstellen wir modellieren. Eine weit verbreitete, aber oft problematische Lösung ist die direkte Modellierung von Input- und Output-Pins. In SysML kann das schnell zu einer unübersichtlichen Menge an Signalen und Verbindungen führen, die das Modell schwer verständlich und wartbar machen. Nicht nur das: Die „Black Box“ wird dadurch aufgebrochen.

Bevor ich die Lösung vorstelle, möchte ich das Fallbeispiel vorstellen, anhand dessen ich das Vorgehen erklären werde.

Fallbeispiel

Wäre es nicht schön, einen Mülleimer zu haben, der den Abfall selber korrekt trennt? Dieses System eignet sich hervorragend für Schulungen, denn:

• Es ist leicht zu verstehen.
• Es hat wenig Komplexität, dennoch lassen sich alle Problematiken gut darstellen.
• Es lässt sich für praktische Workshops schnell und günstig bauen.
• In der Regel ist es „fachfremd“ für Schulungsteilnehmer, wodurch sich lange Diskussion mit Domänenexperten vermeiden lassen.

Das gibt es natürlich schon:

Im Folgenden werden wir uns an einem System orientieren, das dem von Bin-e gleicht und aus 6 Subsystemen besteht:

Für Einführungen zu SysML empfehle ich, anfangs informell (ohne SysML) zu arbeiten, um die Teilnehmenden nicht abzuhängen.

• TrashIntake — Dieses Subsystem enthält die Tür, die sich automatisch öffnet und schließt.
• TrashSorter — Dieses Subsystem klassifiziert und transportiert den Abfall, nachdem dieser in das System gewandert ist.
• TrashContainer — Dieses Subsystem beherbergt die Behälter für die verschiedenen Müllarten
• PowerSupply — Die Energieversorgung, die sich für einzelne Komponenten unterscheiden kann
• UserInterface — Die Schnittstelle für den Nutzer, die eine Komponente (Display) aber auch eine Software (Smartphone-App) sein könnte
• Control — Das Subsystem für die Steuerung

Subsystem TrashIntake

Bevor wir formal mit SysML modellieren, möchte ich zunächst zeigen, wie der TrashIntake informell aussehen soll. Wie wir im folgenden Bild sehen, soll der TrashIntake eine motorisierte Tür haben. Mit zwei Sensoren können wir feststellen, ob die Tür offen oder geschlossen ist.

Naive Schnittstellenmodellierung

Im obigen Bild ist ja bereits die Systemgrenze zu sehen. Nun könnten wir daraus direkt die Schnittstellen ableiten. Das wären in diesem Fall:

• Öffnung zum Einwurf des Mülls
• Durchwurf auf das Tablett (Tray) des TrashSorters
• Kontakte zu den zwei Sensoren
• Elektrische Verbindung des Motors

Dieses Vorgehen ist zwar nicht falsch, aber damit verpufft ein enormer Mehrwert des MBSE. Denn damit haben wir die physikalischen Schnittstellen modelliert. Doch bei diesem Vorgehen fehlt die Steuerlogik des TrashIntake. Und wenn die Steuerlogik fehlt, dann haben wir keine „Black Box“.

Wenn wir Subsysteme modellieren, arbeiten wir auf der logischen Ebene. Es ist ein häufiger Fehler, dort eins zu eins die Schnittstellen der physischen Komponenten zu übernehmen!

Daher haben wir bei allen MBSE-Methoden logische Schnittstellen. Hier ist nun die Herausforderung zu entscheiden, welche Schnittstellen (und Subsystemelemente) notwendig sind, um die Steuerlogik mit aufzunehmen.

Eine besondere Rolle nimmt hier die Steuerung ein: Wir könnten unseren Smart Trash Can zum Beispiel mit einem Raspberry Pi (Raspi) betreiben. Natürlich hätte der TrashIntake nicht einen eigenen Mikrocontroller. Stattdessen würde ein Raspi alle Softwarefunktionen für alle Subsysteme übernehmen. Aber wie können wir das modellieren und gleichzeitig eine Black-Box-Modellierung ermöglichen?

Mit einem Hardware-Abstraktions-Layer (HAL) ein Black-Box-Subsystem modellieren

An dieser Stelle ist es sinnvoll, die identifizierten Schnittstellen durchzugehen und zu hinterfragen, ob diese außerhalb der Black Box sichtbar sein müssen oder nicht. Wenn nicht, dann brauchen wir eine Abstraktion. In der Regel nimmt die logische Schnittstelle dann die Form einer API an. Schauen wir uns die vier Schnittstellen von eben unter diesem Gesichtspunkt an:

• Öffnung zum Einwurf des Mülls — Behalten: Diese Schnittstelle existiert auf Nutzerebene.
• Durchwurf auf das Tablett (Tray) des TrashSorters — Behalten: Diese Schnittstelle verbindet TrashIntake und TrashSorter und ist daher für die Integration erforderlich.
• Kontakte zu den zwei Sensoren: Abstrahieren: Die Steuerlogik, die Teil der Black Box ist, nutzt die Sensoren, aber nichts außerhalb unseres Subsystems.
• Elektrische Verbindung des Motors: Abstrahieren: Wir benötigen zwar eine Energieversorgung für den Motor, aber die Ansteuerung des Motors ist Teil der Black Box.

API für das Subsystem

Durch diese Denkweise und einen „Software First“- oder „Software-Defined“-Ansatz bekommt die API einen enorm wichtigen Stellenwert. Die Qualität der API hat Auswirkungen auf:

• Das Black-Box-Verhalten des Subsystems
• Der Testbarkeit des Subsystems
• Dem Aufwand, dieses Subsystem zu mocken, wenn andere Subsysteme es fürs Testen benötigen
• Den Aufwand, Varianten des Subsytems zu erstellen
• Die Flexibilität, das Subsystem unabhängig vom Rest des Systems weiterzuentwickeln.

In diesem Fall wollen brauchen wir eine API, mit der wir die Tür öffnen, schließen, sowie den Zustand der Tür abfragen können.

export type DoorState = "OPEN" | "CLOSED" | "MOVING" | "UNKNOWN";
export interface DoorControl {
  /**
   * Öffnet die Tür. Falls die Tür nicht innerhalb des definierten 
   * Zeitlimits öffnet, wird eine Exception geworfen.
   * @throws Error wenn die Tür nicht erfolgreich geöffnet wurde.
   */
  openDoor(): Promise<void>;
  /**
   * Schließt die Tür. Falls die Tür nicht innerhalb des definierten 
   * Zeitlimits schließt, wird eine Exception geworfen.
   * @throws Error wenn die Tür nicht erfolgreich geschlossen wurde.
   */
  closeDoor(): Promise<void>;
  /**
   * Gibt den aktuellen Zustand der Tür zurück.
   * @returns Der aktuelle Türstatus als DoorState.
   */
  getDoorState(): DoorState;
}

Modellierung des logischen Subsystems in SysML mit HAL

Basierend auf dem eben gesagten, könnte dieses Subsystem folgendermaßen in SysML modelliert werden:

IntakeDoorHAL ist der Hardware Abstraction Layer (HAL), der nun die logische, in Software abgebildete Funktion auf die Hardware in der Form von Steuer- und Sensorsignalen überträgt. Dabei übernimmt der IntakeDoorHAL die Aufgabe, von der Software-Welt (API-Aufrufe) in die Hardware-Welt zu übersetzen. Damit ist es nicht notwendig, Sensor- oder Motorleitungen außerhalb des Subsystems sichtbar zu machen.

Interessant ist an dieser Stelle IMotorPower, die dem Subsystem als Energiequelle bereitgestellt wird. der HAL hat die Verantwortung, diese mit der richtigen Polarisierung zur richtigen Zeit an den Motor weiterzugeben.

Wo ist das Steuergerät?

Da es sich hier um eine logische Architektur handelt, fehlt die Allocation auf physikalische Komponenten. Bei den meisten Blöcken ist dies eine (mehr oder weniger) offensichtliche 1:1-Beziehung (Motor, Sensoren, Tür). Beim HAL hingegen steckt einiges mehr dahinter: Der HAL benötigt im fertigen System ein Steuergerät (Hardware und Software), das aber auch für andere Systeme verwendet wird. Das trifft auch auf das Betriebssystem des Steuergeräts zu und möglicherweise auf weitere Elemente.

Der eigentliche HAL ist eine Software, die zur Ausgewählten Architektur passen muss und die oben gezeigte API implementiert. Weiterhin muss der HAL auch konfiguriert werden (bspw. muss das Mapping der Sensoren und Motorsteuerung auf die Pins des RasPi konfiguriert werden). Diese Aspekte sind jedoch für die logische Sicht nicht von Belang.

Vorteil dieses Vorgehens

• Undurchdringliche Systemgrenzen: Der größte Vorteil von diesem Vorgehen ist, dass wir saubere Systemgrenzen und damit eine „Black Box“ haben, die eine starke Unabhängigkeit vom Rest des Systems hat.
• Leichtes Austauschen von Komponenten: Wenn eine Komponente noch nicht fertig entwickelt wurde, kann trotzdem ein Subsystem mit derselben Funktion bereitgestellt werden. Dies hat Joachim Pfeffer erfolgreich eingesetzt, um kontinuierliche ein lauffähiges System zu haben.
• Automatisiertes Testen: Die eigentliche Funktionalität steckt nun in der Software und kann vergleichsweise leicht automatisiert getestet werden:
  • Um die Software zu testen, kann die API direkt getestet werden, während die Steuersignale (Sensoren, Motor) gemockt werden
  • Für das gesamte Subsystem kann ein Testprotokoll erstellt werden, welches die API mit klar definierten Eingaben füttert. Den Subsystemtest vollständig zu automatisieren ist aufwändiger und erfordert in der Regel Testroboter.
• Verbessertes Variantenmanagement: Solange Varianten die Schnittstellen bedienen können, sollte ein Austausch ohne Probleme möglich sein. Das praktiziert bspw. SpaceX bei der Entwicklung der Raptor-Engines, von denen keine zwei identisch sind.

Wie geht die Entwicklung dann weiter?

Das hier vorgestellte vorgehen für das Modellieren von logischen Subsystemen mit sauberen Schnittstellen und HAL für die Verbindung von Hardware und Software ist enorm mächtig. Das liegt aber weniger an der Modellierung als an der Methodik.

SysML ist nicht notwendig, um die hier vorgestellte Modellierung von Subsystemen zu nutzen

Insbesondere hätte ich das innere des Blocks gar nicht modellieren müssen: Was zählt ist ein klares Verständnis der Schnittstellen der IntakeDoor. Das Team, das die IntakeDoor verbaut, braucht nicht zu wissen, wie viele Sensoren vorgesehen sind. Dem würde ich sogar provozierend hinzufügen: Das zu detaillierte Modellieren kann sogar schaden, da es die Kreativität des Teams einschränkt.

Konkret reichen die Schnittstellen allein nicht aus, um das Subsystem zu entwickeln. In diesem Artikel habe ich vieles ausgelassen, zum Beispiel die Anforderungen. Eine vervollständigte Spezifikation könnte nun an die Designabteilung weitergegeben werden, um das Subsystem zu konkretisieren.

Alternativ ist eine weitere Verfeinerung mit SysML denkbar, bei der die Funktion über Zustandsmaschinen und Aktivitätsdiagramme abgebildet werden könnte. Welches Vorgehen Sinn macht, hängt von der Komplexität des Systems und dem Wissensstand des Teams ab.

Fazit: HAL unersetzlich für vernünftige Black-Box-Modellierung

Wer moderne Systeme vernünftig mit MBSE abbilden möchte, kommt nicht herum, sich mit dem Thema HAL auseinanderzusetzen. Überall wird von Softwaredefinierten Systemen gesprochen, ganz viel im Bereich Automotive. Wenn dabei nicht vernünftig Funktionalität in Software über HALs abstrahiert wird, dann fliegt uns das System spätestens bei der Integration um die Ohren.

Photo by ThisisEngineering on Unsplash