Event-basierte Softwarearchitektur in der embedded Systementwicklung

In diesem Artikel wird die Event-basierte-Software-Architektur genauer vorgestellt. Dieser Architektur-Stil ist einer von vielen verschiedenen Stilen, die seit den Anfängen der Softwarearchitektur in den 1960er Jahren entwickelt wurden, neben beispielsweise

• Objektorientiert
• Schichtenorientiert (Layered)
• Client-Server
• Master-Slave
• Pipe-filter
• Peer-to-peer
• Model-view-controller

 

Der Event-basierte Architekturstil ist besonders im Bereich der Embedded Entwicklung sehr stark vertreten. Ob dies auf die folgenden speziellen Anforderungen und Einschränkungen von Embedded Systemen zurückzuführen ist?

• Begrenzte Ressourcen
• Echtzeitfähigkeit
• Sicherheit
• Zuverlässigkeit
• Wartbarkeit

 

Auf diese Fragestellung werden wir in diesem Artikel eingehen. Wenn sie mehr zum Thema Embedded Systeme erfahren möchten klicken sie bitte hier.

1. Warum es wichtig ist den richtigen Architektur-Stil zu wählen?

Viele wichtige Entscheidungen zu einem Embedded Projekt werden bereits bei der Auswahl der idealen Software-Architektur getroffen. Sie prägen das Projekt über die gesamte Laufzeit und entscheiden oft über Erfolg oder Misserfolg. Natürlich lässt sich jede Anwendung mit den meisten der derzeit gängigen Architekturstilen umsetzen. Die Qualitätsanforderungen können bei einigen Architekturstilen oft nicht zufriedenstellend bedient werden. Das heisst, die Qualität der entstehenden Software wird also massgeblich durch die Wahl der Architektur bzw. des idealen Architekturstils beeinflusst.

 

Sehr gut kann dies mit folgendem Beispiel veranschaulicht werden.

Wenn eine Anwendung auf externe Ereignisse reagieren können soll, dann kann das mit jedem Architekturstil gemacht werden. Wenn die Anforderung aber lautet, dass die Anwendung zeitnah und zeitkritisch auf Ereignisse reagieren muss. dann ist vermutlich eine Layer-Architektur, basierend auf dem Layering Architekturstil die falsche Wahl. Denn bei einer Layer-Architektur können die Ereignisse zwar auf einem Hardware-nahen Layer entgegengenommen werden – aber die Reaktion auf das Ereignis geschieht dann üblicherweise auf einem der höheren (Applikations-) Layer. Dieses Durchreichen durch verschiede Layer ist zeitintensiv. Die Event-basierte-Architektur ist für zeitkritische Anwendungen sicherlich die bessere Wahl.

 

2. Event-basierte Software Architektur

Eine Event-basierte oder Event-gesteuerte Architektur reagiert auf Ereignisse (Events) im Softwaresystem und unterscheidet sich dadurch von den gewöhnlichen Architekturen, welche auf Anfragen (Requests) reagieren. Ein Ereignis (Event) ist jedes signifikante Ereignis oder jede Änderung des Zustands der Systemhardware oder -Software. Die Quelle eines Ereignisses kann internen oder extern sein. Ereignisse können von einem Benutzer (z. B. Mausklick oder Tastendruck), von einer externen Quelle (z. B. Sensorausgang) oder vom System (z. B. Laden eines Programms) erzeugt werden. Sie werden der Software durch Hardware Interrupts gemeldet. Weiter kann die Software auch selbst Events generieren. Zum Beispiel zum Signalisieren eines wichtigen Zeitereignisses (durch einen Timer).

Eine Event-basierte Software besteht aus dem «Event-Producer» und dem «Event-Consumer». Der Event-Producer erzeugt ein Ereignis und registriert dieses im System. Er kennt weder die Reaktion auf dieses Event noch den Event-Consumer. Der Event-Consumer verarbeitet ein oder mehrere Events und führt eine Reaktion aus. Die Schnittstelle zwischen Event-Producer und Event-Consumer kann beispielsweise durch eine Implementation des Publish/Subscribe Pattern (Quelle) realisiert werden. Dieses zentrale Stück Software kann beispielsweise Event-Channel heissen. Der Event-Channel kennt die Ereignisse im System und ermöglicht den Event-Consumer sich auf bestimmte Events zu registrieren. Ein Event wird also durch einen Event-Producer erkannt und anschliessend dem Event-Channel gemeldet. Der Event-Channel informiert alle Event-Consumer über Ereignisse zu denen der jeweilige Consumer registriert ist.

Der Ansatz von einem Event-basierten System kann mit diversen Programmiersprachen umgesetzt werden und ist grösstenteils von der Technologie unabhängig.

2.1 Welche Qualitätsmerkmale können durch den Einsatz Des Event-basierten Architekturstils gewährleistet werden?

Wie bereits weiter oben beschrieben ist der gewählte Architekturstil massgeblich für die Qualität der Software verantwortlich. Nach ISO 25010 sind die Software-Qualitätsmerkmale wie folgt definiert.

Die Event-basierte Architektur beeinflusst hauptsächlich die Merkmale Zuverlässigkeit, Sicherheit, Effizienz, Wartbarkeit und Übertragbarkeit. Die Benutzbarkeit eines Softwaresystems (auch als Gebrauchstauglichkeit / Usability bezeichnet) wird grösstenteils durch das User Interface Design bestimmt. Die spezifizierte Funktionalität kann mit verschiedenen Architektur-Stilen umgesetzt werden und muss unabhängig von der Architektur durch Verifikation und Validierung sichergestellt werden.

 

Zuverlässigkeit

• Vorteile
  Mit einer Event-basierten Architektur verwendet man einen erprobten Architektur-Stil mit einer hohen Fehlertoleranz der sich bereits in vielen Softwareprojekten erfolgreich bewährt hat.  Verantwortlichkeiten sind durch «seperation of concerns» klar definiert. Deshalb sind Event-basierte Architekturen auch im High-Level Bereich (Cloud Architekturen, Entreprise Computing) sehr verbreitet und oftmals als Microservice Architekturen bekannt. Der grosse Vorteil sind die getrennt entwickelbaren Teile der Software. Durch diese Trennung wird es möglich, dass ein System lauffähig bleibt, auch wenn ein Service fehlerhaft ist, was zum Beispiel im Bereich der grossen Server-Applikationen vorteilhaft ist.

 

• Nachteile
  Durch die Komplexität, die aus der asynchronen Verarbeitung von Events entsteht, können Software-Fehler wie DeadLocks entstehen. Um diese zu vermeiden, ist es wichtig, dass der Code, der für das Event Handling zuständig ist, sehr gut getestet wird und die Synchronisation nicht im funktionellen Teil der Firmware gelöst werden muss. Dies ist durch das Verwenden eines bereits in vielen Projekten bewähren Schedulers, wie der DATAFLOW Runtime möglich.

 

Effizienz

• Vorteile
  Durch den Event-basierten Ansatz arbeitet das System nur beim Auftreten von Ereignissen. Es gibt also keine unnötige Energieverschwendung was das Gesamte System sehr Energieeffizienz macht. Das Auftreten eines Ereignisses startet sofort die Verarbeitung und ermöglicht daher Antworten in Echtzeit.Die Echtzeitfähigkeiten von Softwaresystemen mit Event-basierten Architekturen macht sie für die Entwicklung von Embedded Systemen sehr attraktiv.

 

• Nachteile
  Das Erzeugen, Verteilen und Behandeln von Events im System benötigt zusätzliche Ressourcen (Rechenzeit, Speicher), die bei einer monolithischen Architektur für die Funktionalität der Software genutzt werden können. Allerdings sind wir der Meinung, dass die Vorteile einer solchen Architektur die geringfügigen Performance Einbussen eines optimierten Scheduler wie der DATAFLOW Runtime mehr als aufwiegen.

 

Übertragbarkeit

• Vorteile
  Eine Event-basierte Architektur ist in sich sehr lose gekoppelt, da der Event-Consumer den Event-Producer nicht kennen muss. Durch die lose Kopplung können die einzelnen Teile der Software unabhängig voneinander implementiert werden und sie ermöglicht ein sauberes Testen der schmalen Schnittstellen. Die Software ist dank der losen Kopplung und der einfachen Schnittstelle auch problemlos erweiterbar. Durch die Entkopplung von Hardware Spezifischem Code (Producer) und der Verarbeitungslogik (Consumer) ist es auch möglich, die Software mit geringem Aufwand auf eine andere Zielplattform zu portieren.

 

• Nachteile
  Die Wartung der Software kann unter Umständen komplex werden, da die Abhängigkeiten im verteilten System nicht offensichtlich sind. Das erhöht das Risiko einer unerwünschten Veränderung der Funktionalität. Durch die Verwendung von Model basierter Entwicklung und Code Generierung kann sichergestellt werden, dass die Architektur immer verständlich bleibt und das Risiko für die Software-Wartung beherrschbar wird. Ein solcher Ansatz ist z.B. mit dem DATAFLOW Designer und Code Generator problemlos möglich. Der Event-basierte Ansatz benötigt auch eine Infrastruktur für das Event Handling. Diese muss bereitgestellt werden, wenn die erstellte Firmware oder Teile daraus auch auf einem anderen Zielsystem wiederverwendet werden sollen. Durch die Verwendung eines bewährten Event-Frameworks, wie der DATAFLOW Runtime, kann dies aber mit minimalem Aufwand realisiert werden.

 

2.2 Weshalb eignet sich der Event-basierte Ansatz nun besonders gut für Embedded Systeme?

Die Event-basierte Architektur adressiert also vor allem Merkmale wie

• Effizienz,
• Sicherheit,
• Zuverlässigkeit,
• Wartbarkeit und
• Übertragbarkeit.

 

Embedded Systeme haben sehr oft spezielle Anforderungen und Einschränkungen. Diese haben wir auch bereits in der Einleitung angeschnitten.

• Begrenzte Ressourcen
• Echtzeitfähigkeit
• Sicherheit
• Zuverlässigkeit
• Wartungsfähigkeit

 

Die hohe Korrelation zwischen den besonderen Merkmalen der Event-basierten Architektur und den Anforderungen von Embedded Systemen untermauert also die zu Beginn aufgestellte These. Der Event-basierte Architekturstil ist also besonders oft im Bereich der Embedded Entwicklung vertreten, weil er sich vor allem bei den speziellen Anforderungen von Embedded Systemen insbesondere der Effizienz bei ereignisbasierten Systemen auszeichnen kann.

 

Wo hat der Event-basierte Architekturstil seine Grenzen?

Der Event-basierte Architekturstil kann vor allem bei grossen und komplexen Systemen an seine Grenzen stossen. In solchen Fällen können komplizierte Eventstrukturen entstehen, welche nicht offensichtliche bzw. zyklische Abhängigkeiten aufwerfen. Ausserdem können von solchen Systemen hohe Mengen an Events generiert werden, dessen Abarbeitung sichergestellt werden muss – ohne in ein «Denial of Service» zu laufen.

Abhilfe zur Vereinfachung bei komplexen Systemen könnte beispielsweise die Kombination aus mehreren Architekturstilen liefern. So könnte beispielsweise ein Komponenten-orientierter Architekturstil zusammen mit einem Event-basiertem Architekturstil eingesetzt werden. Dadurch wird eine bessere Strukturierung der Software erzielt, ohne dabei auf die Vorteile der Event-basierten Architektur zu verzichten zu müssen. Die Kommunikation zwischen den Komponenten läuft also weiterhin über Events.

 

3. Event-basierte Architektur mit DATAFLOW

Bei IMT setzten wir seit über 20 Jahren erfolgreich auf eine Event-basierte Architektur bei der Umsetzung von Firmware für Embedded Systeme. Das in dieser Zeit entstandene Know-how haben wir in Form der DATAFLOW Runtime und des DATAFLOW Designers auch für unsere Kunden verfügbar gemacht.

Die DATAFLOW Runtime ist ein Event-basierter Embedded Scheduler der ohne die Notwendigkeit eines zusätzlichen Betriebssystems (Bare Metall) auf Embedded Prozessoren (wie ARM Cortex-M) ausgeführt werden kann. Die Funktionalität der Firmware wird mit dem Active Object Design Pattern (Quelle) umgesetzt, wobei die Objekte in DATAFLOW als Active Parts bezeichnet werden.

Ein Active Part kann als Event Producer einen Event erzeugen. Die Active Parts sind über Channels verbunden, so dass der Consumer über den Event informiert wird, und entsprechend reagieren kann. Weiterhin ist es auch möglich über Software- oder Hardware Timer Events zu erzeugen. Auch Hardware-Interrupts werden in dieses Event System eingebunden. Dadurch kann der Software-Entwickler die vollständige Funktionalität der Firmware Event-basiert umsetzten und Testen.

Durch die Vergabe von Prioritäten in den Active Parts kann das zeitliche Verhalten genau definiert werden. Präemptives Multitasking (Quelle) wird vom Bare Metall Scheduler unterstützt. Bei der Verwendung eines RTOS Schedulers werden die Active Part Prioritäten nahtlos in die RTOS Prioritäten integriert. Auch Time Slice Scheduling ist möglich, wenn dies vom verwendeten RTOS unterstützt wird.

Mithilfe des DATAFLOW Designers lässt sich die Zerlegung der Firmware in Active Parts, die Definition der Events sowie das Definieren der Channels grafisch am PC erledigen. Ein Code Generator stellt sicher, dass die grafische Repräsentation immer mit der erstellten Software übereinstimmt und der Entwickler sich auf das Umsetzten der Funktionalität fokussieren kann.

Weitere Einzelheiten zu DATAFLOW können sie unserer Webseite entnehmen.

Die Event-basierte Architektur ist nicht mehr aus der Softwareentwicklung wegzudenken. Die aktuell sehr gefragten IoT Geräte, welche meist sehr energieeffizient und echtzeitfähig sein müssen, werden oft mit einer Event-basierten Architektur umgesetzt. Gerade weil sich der eventbasierte Ansatz sehr gut für Echtzeitanforderungen eignet und zudem auch die folgenden Qualitätsmerkmale ideal abdecken kann, ist der Event-basierte Architekturstil vor allem im Embedded Bereich sehr beliebt.

• Effizienz,
• Zuverlässigkeit,
• Wartbarkeit,
• Sicherheit und
• Übertragbarkeit.

 

Natürlich wird der Event-basierte Architekturstil auch bei der IMT sehr häufig und erfolgreich eingesetzt. Die IMT AG geht sogar einen Schritt weiter und hat ein Event-basiertes Echtzeitbetriebssystem «DATAFLOW Runtime» und ein Design Tool für Event-basierte Architekturen gepaart mit Komponenten-orientierten Architekturen entwickelt.

Mit dieser Tool-Suite können Systeme mittels Event-basierter Architektur modelliert und umgesetzt werden. Der Benutzer wird in der graphischen Oberfläche optimal unterstützt und entsprechende Massnahmen sorgen dafür, dass bestimmte Regeln von Event-basierten Architekturen eingehalten werden müssen. So wird der Benutzer gewarnt, wenn Ein- oder Ausgänge nicht verbunden wurden, Protokolle für Nachrichten nicht definiert wurden, ausgehende Ports mit mehreren Eingängen verbunden wurden und vieles mehr. Dank dieser Tools konnte nicht nur die Qualität der Anwendungssoftware zusätzlich gesteigert werden. Auch der Entwicklungsprozess wurde dank der automatischen Code-Generierung, der übersichtlichen System-Designs und der sehr guten Wartbarkeit weiter optimiert. Der hohe Entwicklungsaufwand, der in die DATAFLOW Software geflossen ist, macht sich bezahlt da neue Projekte dank DATAFLOW wesentlich effizienter und somit kostengünstiger umgesetzt werden können.

Haben Sie weitere Fragen oder möchten auch sie von den Vorteilen der DATAFLOW Software profitieren? Dann Kontaktieren Sie uns bezüglich eines Präsentationstermines oder testen sie unsere 30 Tage Demo Version.