Fühlen Sie sich beim Fliegen wohl?

Embedded Systems – die andere Welt

Peter Hruschka

© Shutterstock/Annette Shaff

Wenn Sie wieder einmal böse sind, dass Ihre Textverarbeitung crasht, denken Sie einmal daran, dass das harmlos ist im Vergleich zu einem Ausfall des Avionic-Systems von Flugzeugen, dem Airbag Ihres Autos, einem Herzschrittmacher oder dem Regelsystem zur Produktionsüberwachung bei der Herstellung hochgiftiger Chemikalien.

In Ihrem Alltag kommen Sie mit vielen technischen Systemen in Kontakt: mit Mobiltelefonen, Autos, Flugzeugen, Navisystemen, medizinischen Apparaturen, Hörgeräten, intelligenten Backherden, Umweltmesssystemen u. v. a. mehr. Wenn Sie in dieser Welt leben und technische Produkte erstellen, die anderen das Leben erleichtern sollen, dann ist dieser Artikel für Sie. Embedded heißt, dass „Computerei“ nicht der Hauptzweck des Systems ist, sondern es eingebettet in eine Umgebung arbeiten muss. Dabei geben Ereignisse in der Umgebung vor, wann etwas gemacht werden muss. Das System muss reagieren. Und Real-Time bedeutet (manchmal extrem) schnell. Was ist so anders bei der Entwicklung von Real Time Embedded (RTE) Systems im Vergleich zu kommerzieller Software für Banken, Behörden, Versicherungen, Webshops …?

Zuverlässig und sicher

Die beiden Begriffe im Namen „Embbeded“ und „Real-Time“ fordern Reaktivität und Schnelligkeit. Das sind nur zwei Besonderheiten dieser Art von Systemen. Die Einbettung fordert bei diesen Systemen, auf eine Vielzahl von Sensorsignalen oder Signalen von anderen Teilsystemen zu reagieren. Wenn Ereignisse aus der Systemumgebung nicht schnell genug aufgenommen werden können oder wenn die Reaktion des Systems nicht rechtzeitig erfolgt, dann sind u. U. Menschenleben gefährdet. Von derartigen Systemen wird oft hochgradige Zuverlässigkeit und Verfügbarkeit verlangt, aber auch der Nachweis an Sicherheit. Doch dazu später mehr.

Software ist wichtig, aber …

Ich habe zwar auch Informatik studiert, aber manchmal nehmen wir uns als Softwareentwickler zu wichtig. Richtig ist, dass die Softwareanteile in Embedded Systems ständig wachsen. Aber Embedded Systems sind durch ein enges Zusammenspiel von Hardware, Software und evtl. vielen anderen Techniken gekennzeichnet, wie Mechanik, Elektrik, Hydraulik … Unsere Kunden sind an dem Gesamtsystem interessiert, nicht nur an dem Softwareanteil: Wenn Ihr Handy versagt, ist es Ihnen doch egal, ob die Software oder die Hardware kaputt ist.

Das Kunststück als Entwickler besteht darin, in dem ganzen gelieferten System zu denken (Abb. 1) und nicht zu voreilig Abgrenzungen zwischen Hardware und Softwareanteilen vorzunehmen. Fangen Sie an, Funktionalität und Verhalten des Gesamtsystems zu spezifizieren und zu designen, bevor Sie für Teile dieser Funktionalität die geeignete Technologie (Hardware, Software, Mechanik …) auswählen.

Abb. 1: Welches davon ist Ihr System?

Abb. 1: Welches davon ist Ihr System?

Wir trennen Problemstellung von Lösung

Im Entwicklungsprozess für Embedded Real Time Systems wollen wir neben dem Denken in Gesamtsystemen und dem Denken in den Softwareanteilen des Systems auch noch eine zweite Dimension unterscheiden (Abb. 2, linker und rechter Halbkreis): das Denken in der Problemstellungen (d. h. den Anforderungen) und das Denken im Lösungsraum (Architektur und Realisierung). Somit ergeben sich die dargestellten vier Haupttätigkeiten bei der Entwicklung. Beachten Sie, dass das Bild keinerlei Reihenfolge suggeriert; alle Pfeile weisen in beide Richtungen: Sie können in jedem Quadranten beginnen.

Im Gegensatz zu kommerziellen Systemen, wo man Anforderungen und Lösung leichter trennen kann, kommt bei Embedded Systems die Lösung im Projektverlauf oft früher ins Spiel, weil manchmal erst durch die Lösungstechnologie entschieden werden kann, ob das Problem überhaupt und effektiv lösbar ist. Entwickeln Sie also parallel Modelle in allen vier Bereichen und iterieren Sie häufig, um die Konsistenz der Modelle aufrechtzuerhalten. In [1] finden Sie eine ausführliche Diskussion dieses facettenreichen Prozesses, in [2] die Ausweitung des Prozesses, um auch andere Technologien außer Software einzubeziehen (Mechanikanalyse – Mechanikdesign, Elektronikanalyse – Elektronikdesign …).

Abb. 2: Problemstellung und Lösung jeweils auf System- und Softwareebene

Abb. 2: Problemstellung und Lösung jeweils auf System- und Softwareebene

Die UML ist immer noch Standard

Zur Durchführung der vier Aufgaben steht Ihnen UML zur Verfügung. Obwohl UML für Softwaresysteme entwickelt wurde, können alle Diagrammarten auch auf der Systemebene eingesetzt werden. Sie müssen nur den Scope groß genug wählen. Die Object Management Group hat als Erweiterung der UML die SysML (System Modeling Language) definiert, [3] gibt einen guten Überblick dazu. Da die beiden Standards jedoch zu 80 Prozent überlappen, ist die Verbreitung von SysML eher zögerlich. Es gibt zu viele (gute) Tools und Lehrbücher im UML-Bereich. Für Systeme, bei denen Simulation und Animation in der Entwicklung eine große Rolle spielen, sollten Sie auch an Modellierungssprachen wie MATLAB/Simulink denken.

Umgang mit Kernaspekten von Embedded Systems

Unabhängig von der Modellierungssprache und unabhängig von den Betrachtungsebenen müssen Sie die in Tabelle 1 gezeigten fünf Kernaspekte in den Griff bekommen. Je nach Art Ihres Embedded Systems sind diese mehr oder weniger stark ausgeprägt. Greifen wir uns im Folgenden einige der Punkte heraus.

Tabelle 1: Fünf Kernaspekte bei der Entwicklung von RTE-Systemen

Tabelle 1: Fünf Kernaspekte bei der Entwicklung von RTE-Systemen

Einbettung

„It’s Always the Goddamned Interfaces“ heißt eines der Pattern in [4]. Und die sollten Sie sowohl bei der Problemstellung wie auch bei der Lösung sehr ernst nehmen. Dazu bewährt sich das gute alte Kontextdiagramm in seinen beiden Ausprägungen „logisch“ und „physisch“ (Abb. 3). Das logische Kontextdiagramm zeigt alle Nachbarsysteme und benennt die Ein- und Ausgaben des Systems; das physische Äquivalent zeigt die Kanäle, d. h. die Leitungen und Medien, über die die logischen Ein- und Ausgaben fließen. Achten Sie bereits bei diesen relativ einfachen Modellen darauf, dass sie vollständig und akkurat sind.

Natürlich gehört zu den beiden Diagrammen eine Mapping-Tabelle, die zeigt, welche logischen Ein- und Ausgaben über welche Kanäle gesendet oder empfangen werden. Im Beispiel der Statusangaben an den Fahrer könnten diese über den Lautsprecher oder über das Display (oder auch über beide Kanäle) ausgegeben werden.

Abb. 3: Logischer und physischer Kontext eines Tempomaten

Abb. 3: Logischer und physischer Kontext eines Tempomaten

Zeitanforderungen

Für den Umgang mit Zeitanforderungen lohnt es sich, fachliche Prozessmodelle (für die Problemstellung) und Architekturmodelle (für die Lösung) zu haben. Dann kann man darin sehr leicht die Stellen identifizieren, für die bestimmte Zeitauflagen einzuhalten sind, bzw. einzelne Komponenten im Blackboxtext auch auf deren Einhaltung überprüfen. Zum Beispiel ein textueller Ablauf für das Verhalten eines Airbags:

  • Zum Zeitpunkt „Null“ berührt das Fahrzeug die Crashwand.
  • 25 ms später aktiviert der elektronische Sensor die Zündpille des Fahrermoduls.
  • Nach 30 ms ist die Abdeckung des Fahrermoduls aufgerissen und der Airbag wird aufgeblasen.
  • Nach ca. 55 ms ist der Fahrerairbag vollständig aufgeblasen und der Fahrer taucht ein.
  • Nach 85 ms ist der Fahrer maximal in den Airbag eingetaucht und bewegt sich wieder vom Lenkrad weg.
  • Nach ca. 150 ms ist das gesamte Unfallgeschehen abgeschlossen, die Insassen befinden sich in ihrer Ausgangsposition und beide Airbags sind weitgehend geleert.

Ihre Modelle sollten diese Schritte zeigen und um entsprechende Timing-Anforderungen erweitert werden. Probieren Sie als Hausaufgabe, den obigen Text als Prozessmodell (z. B. Aktivitätsdiagramm) oder als Komponentendiagramm zu zeichnen und hängen Sie die Timing-Anforderungen daran. Ohne Bezugspunkte zu Analyse- und Designmodellen sind die Aussagen oft zu schwammig und schwer zu verifizieren.

Parallele Prozesse

Sehr oft sind RTE-Systeme gekennzeichnet durch eine Vielzahl unabhängig laufender Prozesse. Je nach Ihrer Technologie sprechen Sie dann wahrscheinlich von Multi-Processing (Computer mit mehreren Kernen, die echt gleichzeitig arbeiten), Multitasking und Multi-Threading (Zeitmultiplexverfahren, die nach außen den Eindruck der Gleichzeitigkeit vermitteln). Eine gute methodische Einführung dazu finden Sie in [1] und [5], insbesondere, wie Sie festlegen, welche Teile des Systems nebenläufig zu anderen ausgeführt werden sollen, und wie mit „Tricks“ wie Task-Inversion oder Bündelung von Tasks aus unterschiedlichen Zuständen die Anzahl der parallelen Prozesse verringern können.

Zur praktischen Umsetzung sind hier oft Standardbetriebssysteme nicht ausreichend schnell oder sicher. Sie müssen auf Real-Time-Betriebssysteme ausweichen, die Ihnen Verzögerungs- und Bearbeitungszeiten garantieren. Beispiele sind QNX, eCOS, OSEK usw. Diese bringen jeweils ihre Philosophie zur Bewältigung der Echtzeitanforderungen mit. Sie denken und arbeiten mit Time-sliced Architectures, mit Pre-emptive oder Cooperative Multitasking, Interrupts und Interrupt-Levels, unterschiedlichen Strategien im Umgang mit typischen Nebenläufigkeitsproblemen wie konkurrierender Zugriff auf gemeinsame Ressourcen, Fairness, Deadlock-Freiheit usw.

Zur Lösung mancher dieser Fragen sind daher neben fachlichen Domänenkenntnissen tiefgreifende Kenntnisse über die eingesetzten Basissysteme (Hardware und Software) Voraussetzung.

Funktionale Sicherheit

Bei einem sicherheitskritischen System ist es notwendig, normenkonforme Entwicklung nachzuweisen. Neben der generischen Norm IEC 61508 gibt es noch zahlreiche domänenspezifische Normen, wie z. B. ISO 26262, IEC 60601 oder DO 178B. Die Nichteinhaltung dieser Normen hat evtl. Konsequenzen bezüglich Haftung im Schadensfall und Strafverfolgung.

Durch die Normen wird ein Sicherheitslebenszyklus definiert, der unter anderem verlangt, dass eine Gefahren- und Risikoanalyse durchgeführt wird, dass Sicherheitsanforderungen definiert werden und auf System-, Software- oder Hardwareebene implementiert werden können. Zu den bekannten Methoden zählen FTA (Fault Tree Analysis), FMEA (Failure Mode and Effects Analysis), FMECA (= FMEA with Criticality Analysis) oder FMEDA (Failure Mode, Effects, and Diagnostic Analysis). Wiederum gilt: Saubere Modelle der Requirements und Architekturen erleichtern diese Sicherheitsaufgaben. Eine systematische Untersuchung von Systemzuständen und von Ereignissen und Randbedingungen, die die Übergängen auslösen (z. B. mittels Zustandsdiagrammen oder UML StateCharts) sind unabdingbar für das Aufspüren potenziell unerwünschter Systemzustände.

Java holt auf

Obwohl viele Embedded Systems immer noch in C, C++ oder Assembler entwickelt werden, gewinnt Java zunehmend an Bedeutung. Erstmals in 2014 wurde der Embedded-Java-Standard (Java-ME-8) gleichzeitig mit der Java Standard Edition verabschiedet und gewährleistet eine flexible und leistungsfähige Umgebung für zeitgemäße Anwendungen auf Embedded-Plattformen. Die beiden zugrunde liegenden Embedded JSRs bilden – vereinfacht gesprochen – ein direktes Subset von Java SE, sowohl bei den verwendeten Sprachfeatures als auch bei den APIs und virtuellen Maschinen.

Zertifizierbares Wissen

Das International Software Architecture Qualification Board (iSAQB) widmet diesen sicherheitskritischen Systemen ein eigenes Modul (EMBEDDED [6]) im Rahmen der Advanced-Level-Zertifizierung. Darin werden neben einer Einführung in die wichtigsten Aspekte solcher Systeme schwerpunktmäßig Methoden für Systeme vorgestellt, in denen „funktionale Sicherheit“ und deren Nachweis anhand von internationalen Normen eine Hauptrolle spielt.

Fazit

Sie können heute beruhigt Auto fahren und fliegen. Die Analyse- und Designtechniken, die solche Systeme performant, sicher und zuverlässig machen, sind in den letzten Jahrzehnten wohl verstanden und lehrbar geworden. Und sie sind durch internationale Standards abgesichert, deren Einhaltung für kritische Produkte nachgewiesen werden muss. Trotzdem hinkt die Praxis in manchen Unternehmen dem Stand der Technik noch hinterher. iSAQB leistet mit dem Advanced Module „Sicherheitskritische eingebettete Systeme“ seinen Beitrag zur Verbesserung der Situation.

Aufmacherbild: A kite toned with a retro vintage instagram filter effect von Shutterstock / Urheberrecht: Annette Shaff 

Verwandte Themen:

Geschrieben von
Peter Hruschka
Peter Hruschka
Informatikstudium an der TU Wien, Promotion über Echtzeit-Programmiersprachen. 18 Jahre im Rahmen eines großen deutschen Softwarehauses verantwortlich für Software-Engineering. Initiator, Programmierer und weltweiter Prediger und Vermarkter eines der ersten Modellierungstools. Seit 1994 selbstständig als Trainer und Berater mit den Schwerpunkten Software-/Systemarchitekturen und Requirements Engineering, bevorzugt im technischen Umfeld.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: