Verteilte Embedded Systems mit leichtgewichtigen Microservices realisieren

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

GSP Sprachtechnologie GmbH

Das Microservice-Prinzip „Für jede Aufgabe ein eigener Prozess" hat auch für Embedded-Systeme viele Vorteile. Eine Microservice-Architektur lässt sich nicht nur leicht mit einfachen Mittel realisieren, sondern wird im Vergleich zu monolithischen Architekturen auch die Software-Qualität verbessern.

Der Beitrag zeigt, wie in einer Microservice-Architektur mit einfachen Mitteln automatische Tests realisierbar sind, ohne dass hierfür der Applikationscode geändert oder instrumentiert werden müsste. Wir betrachten beispielhaft die digitale ELektroAkustische Anlage („ELA-System“) der Firma GSP.

ELA ist ein Beschallungssystem für den Einsatz in Eisenbahnen und anderen öffentlichen Nahverkehrsmitteln. Es hat folgende Grundfunktionen: automatische Ansagen, manuelle Durchsagen, Fahrgasthilferufe und akustische Verbindung zu einer stationären Zentrale. Das ELA-System in einem Zug kann bis zu 150 Geräte verschiedener Typen umfassen. Dies sind Leistungsverstärker, Sprechstellen für Fahrer, Sprechstellen für Zugbegleiter und Sprechstellen für Fahrgäste. Alle Geräte sind über ein Ethernet-Netz untereinander und gegebenenfalls mit weiteren Systemen verbunden (Bild 1 zeigt schematisch einen möglichen Ausschnitt aus einem ELA-System).

Aufgaben der Software

Die Embedded Software in den Geräten muss unter anderem folgende Funktionen übernehmen:

• Umwandlung analog Audio zu digitalen Netzwerk-Streams und zurück,

• Signalverarbeitung (Lautstärkeregler, Equalizer, Echo-Unterdrückung, …),

• Steuerung der Geräte-Hardware (Inputs, Anzeigen, Relais, …),

• Erkennung der Zugkonfiguration,

• zugweite Steuerung des Systems (Prioritäten, parallele Streams, …),

• dynamische Umkonfiguration (Kuppeln von Zügen, Ausfallsicherheit),

• Parametrierung,

• Selbsttest der Anlage,

• Überwachung der Software.

Architektur nach dem Microservice-Prinzip

Die Gerätesoftware wurde so in Prozesse aufgeteilt, dass jeder Prozess genau eine Aufgabe hat. Die Aufteilung auf einzelne Prozesse entspricht einer Microservice-Struktur. Die Prozesse kommunizieren über Nachrichten miteinander. Die Übertragung der Nachrichten erfolgt über shared Memory mittels einer Bibliothek ("IPC" = Inter Process Communication), gegen die jeder Prozess gelinkt ist.

Bild 2 zeigt die wesentlichen Komponenten der Software-Architektur eines Gerätes des ELA-Systems. Diese Architektur ist in jedem Gerät gleich, unabhängig vom speziellen Gerätetyp.

Die Microservice-Struktur hat folgende Vorteile: Die Prozesse können separat entwickelt werden. Jeder Prozess bleibt überschaubar. Fehlersuche und Weiterentwicklung werden einfacher. Die Einarbeitungszeit neuer Mitarbeiter wird kürzer. Für neue Features müssen im Allgemeinen nur 1-2 Prozesse geändert werden. Die meisten Prozesse bleiben unverändert und sind nach wenigen Bugfix-Runden praktisch fehlerfrei.

Im Vergleich zu monolithischen Systemen wird die Software-Qualität zunehmen. Um den begrenzten Ressourcen der embedded Systeme Rechnung zu tragen, kommunizieren unsere Microservices – wie schon erwähnt - über shared Memory (statt über das Netzwerk). Außerdem sind die Nachrichten in einem sehr effizienten binären Format codiert.

Transparente Nachrichten-Umlenkung

In die IPC-Bibliothek haben wir einen Mechanismus zur bidirektionalen Transparenten Umlenkung von Nachrichten eingebaut.

Folgende Grundfunktionen sind möglich:

• Alle Nachrichten von Prozess X an Prozess Y werden statt an Y an einen anderen Prozess T umgeleitet. T kann sich außerhalb des Systems von X und Y befinden.

• Alle Nachrichten von Prozess X an Prozess Y werden zusätzlich an einen anderen Prozess T kopiert. T kann sich außerhalb des Systems von X und Y befinden.

• Alle Nachrichten von Prozess X an Prozess Y werden blockiert (gelöscht).

• In den Kommunikationskanal von Prozess X zu Prozess Y werden Nachrichten von einen anderen Prozess T eingeschleust. Für Y scheinen die eingeschleusten Nachrichten von X zu kommen. T kann sich außerhalb des Systems von X und Y befinden.

In allen Fällen erfahren die Prozesse X und Y von der Umlenkung nichts, für sie ist die Umlenkung transparent.

Bild 3 verdeutlicht das Prinzip. X, Y und Z sind Prozesse im Embedded System („Gerät“), das durch den blauen Rahmen angedeutet wird. Die normalen Kommunikationswege zwischen den Prozessen sind als schwarze Pfeile dargestellt. Die roten Pfeile und Kreuze stellen die Nachrichten-Umlenkung dar:

1 Nachrichten von X nach Y, von Y nach X sowie von Z nach Y werden blockiert.
2 Nachrichten von Y nach X werden an den externen Prozess T umgeleitet.
3 Nachrichten von Y nach Z werden auch an den externen Prozess T gesendet (kopiert).
4 Der Prozess T schleust Nachrichten an Y in das System ein, die Y als Nachrichten von X bzw. Z interpretiert.

Dieses Setup ermöglicht es, den Prozess Y zu testen, indem die Prozesse X und Z durch den externen (Test-) Prozess T simuliert werden. Viele weitere Setups sind möglich, insbesondere auch solche, an denen mehrere Geräte beteiligt sind.

Automatisches Testen

Aufgrund des Microservice-Ansatzes muss jegliche Kommunikation innerhalb des Systems durch den Austausch von Nachrichten zwischen den Prozessen erfolgen. Durch die Transparente Nachrichten-Umlenkung werden automatische Tests auf einfache Weise möglich:

• Da jedes Input-Ereignis (zum Beispiel das Drücken auf einen Knopf an einer Sprechstelle) in einer Nachricht resultiert, kann durch Einschleusen der entsprechenden Nachricht das Ereignis simuliert werden (gleichzeitig werden durch echte Ereignisse ausgelöste Nachrichten blockiert).

• Auch das Output-Ereignis (zum Beispiel das Blinken einer Lampe am Führerstand) wird durch eine Nachricht ausgelöst. Durch den Vergleich dieser Nachricht mit der Erwartung kann getestet werden, ob die Aktion richtig ausgeführt wurde.

Eine externe Testmaschine kann Nachrichten in das System einschleusen und im System fließende Nachrichten beobachten. Damit ist sie in der Lage, beliebige Abläufe auszulösen und zu testen (Ausnahme: der eine Prozess pro Gerät, der direkt auf die Hardware zugreift (HAL) wird hiermit nicht getestet).

Es können komplexe Szenarien mit beliebig vielen beteiligten Geräten getestet werden. Jeder Test löst im System exakt dieselben Reaktionen aus wie der reale Betriebsfall, da dieselben Nachrichten verwendet werden. Der Test erfolgt mit der Original-Software und –Konfiguration auf der Original-Hardware. Auch das Timing entspricht weitgehend den realen Verhältnissen. Es wird also sehr realitätsnah getestet; die Aussagekraft der Testergebnisse ist hoch.

Ein einfaches Beispiel

Zur Verdeutlichung beschreiben wir einen einfachen Test. Dabei wird folgender Ablauf getestet:

1. Ein Fahrgast drückt die Ruf-Taste einer Fahrgastsprechstelle (FGS).
2. Daraufhin blinkt am Führerstandsinterface (MFI) beim Fahrer eine LED.

In Wirklichkeit wird nun noch mehr passieren, aber für unseren einfachen Test lassen wir es dabei bewenden.

In der Software der Geräte passiert in diesem Ablauf Folgendes:

1. In der FGS schickt der HAL-Prozess an den Control-Prozess zwei (Tasten-) Nachrichten: "Taste wurde gedrückt" ,"Taste wurde losgelassen". Nun folgen diverse Aktionen, die die Übertragung über das Netzwerk einschließen. Am Ende erfolgt:

2. Im MFI schickt der Control-Prozess an den HAL-Prozess die Nachricht: „LED soll blinken“.

Um den Ablauf in einem automatisch ausführbaren Test zu realisieren, macht das Testsystem (PC) Folgendes:

1. In der FGS wird die Kommunikation HAL-->Control gekappt. Stattdessen werden vom Testsystem die beiden oben genannten Tasten-Nachrichten eingeschleust. Der Control-Prozess erhält dieselben beiden Nachrichten, die er nach dem Drücken der Taste vom HAL-Prozess erhalten hätte.

2. Die Kommunikation Control-->HAL im MFI wird beobachtet. Wenn dort die Nachricht „LED soll blinken“ erscheint, dann ist der Test bestanden, ansonsten nicht.

Bild 4 zeigt schematisch die Kommunikationswege:

Simulation des Systems

Die Geräte können auch auf einfache Weise simuliert werden: Die Software wird für die Simulations-Plattform (zum Beispiel Linux-PC) kompiliert. Dabei muss nur der HAL-Prozess angepasst werden bzw. kann sogar entfallen, alle anderen Prozesse können unverändert in der Simulation verwendet werden.

Auf einem PC können viele simulierte Geräte laufen, indem sie in eigenen Verzeichnissen gestartet werden. Mit dem geschilderten Testverfahren lassen sich nun Systeme aus simulierten Geräten testen. Dafür wird das Testsystem auf demselben Rechner gestartet, auf dem auch die Simulationen laufen.

Es können dieselben Testfälle verwendet werden wie auf dem echten System. Bis auf Timing, Audioausgabe und die Betätigung der Hardware sind die Abläufe identisch zum realen System. So können komplexe Abläufe im System automatisch getestet werden. Das ermöglicht Software-Tests, die über die üblichen Unit- und Komponententests weit hinausgehen. Die Tests laufen automatisch, zum Beispiel immer nach dem Nightly Build.

Zusammenfassung

Embedded Systeme können mit einer Ressourcen-schonenden Microservice-Architektur entwickelt werden. Dadurch steigt die Qualität der Software. Außerdem ermöglicht diese Architektur den Einbau einer Transparenten Nachrichten-Umlenkung. Durch diese Nachrichtenumlenkung ist es möglich, automatisierte Tests zu implementieren, die nicht nur einzelne Geräte, sondern komplexe Systeme aus vielen Geräten testen. Die Geräte-Software wird dabei nicht verändert oder beeinflusst, die Tests sind daher sehr realitätsnah. Dieselben Tests können auch mit einer Systemsimulation laufen und dadurch die Software-Entwicklung absichern.

(Der Beitrag wurde mit freundlicher Genehmigung des Autors dem Embedded Software Engineering Kongress Tagungsband 2019 entnommen.)

„Teile und herrsche“: Wo Microservice-Architekturen sinnvoll sind

Microservices in Java

Microservices – Neue Geheimwaffe oder SOA-Remake?

Der Autor

* Dipl.-Physiker Frank Reglin ist seit vielen Jahren als Software-Entwickler, insbesondere im Embedded-Bereich, tätig. Seine Schwerpunkte sind die Entwicklung von System-Konzepten, die Programmierung von hardware- und betriebssystemnaher Software sowie die Definition und Realisierung problemorientierter Sprachen. Er hat die Architektur des vorgestellten ELA-Systems entworfen und die Software zur Interprozess- und Netzwerk-Kommunikation entwickelt.

90 Embedded-Software-Experten im Netz

(ID:46909211)