Suchen

Grundlagen des Embedded Software Engineering

| Autor/ Redakteur: Prof. Dr. Christian Siemers* / Sebastian Gerstl

Was versteht man unter Embedded Software Engineering? Welche Herausforderungen adressiert es und welche Designmethoden bietet es als Lösungsansätze? Eine Einführung von Prof. Dr. Christian Siemers.

Firmen zum Thema

Software Engineering setzt sich aus vielen Teilbereichen zusammen. Wer die teils zusammenhängenden, teils unterschiedlichen Techniken und Designmethoden kennt, ist in der Lage, von Grund auf stabile, rundum solide Software zu entwickeln.
Software Engineering setzt sich aus vielen Teilbereichen zusammen. Wer die teils zusammenhängenden, teils unterschiedlichen Techniken und Designmethoden kennt, ist in der Lage, von Grund auf stabile, rundum solide Software zu entwickeln.
( Bild: gemeinfrei / Pixabay )

Das Wort Embedded Software Engineering setzt sich zusammen aus den Komponenten Embedded Systems (dt. eingebettete Systeme) und Software Engineering (dt. Softwaretechnik). Ein eingebettetes System (engl. Embedded System) ist ein binärwertiges digitales System (Computersystem), das in ein umgebendes technisches System eingebettet ist und mit diesem in Wechselwirkung steht. Dabei hat das Computersystem die Aufgabe, das System, in das es eingebettet ist, zu steuern, zu regeln oder zu überwachen.

Die Softwaretechnik (engl. Software Engineering) beschäftigt sich mit der Herstellung von Software, also der Entwicklung und dem Betrieb von Programmen und der Organisation und Modellierung der zugehörigen Datenstrukturen. (Lit.: Balzert, S.36).

Das Besondere der eingebetteten Systeme ist ihre Eigenschaft als „universeller Systemintegrator“. Die technischen Systeme werden durch interagierende Komponenten geformt. Die hohe Zahl der Komponenten, die wachsende Komplexität der einzelnen Komponenten und des Gesamtsystems und nicht zuletzt die Anforderungen ständig verbesserter Systeme machen es notwendig, die Einzelkomponenten sowie die Interaktionen mit immer mehr Funktionen auszustatten. Rechnersysteme sind die einzig verfügbare Technik, um komplexe Interaktionen zwischen einzelnen physikalischen Systemen zu implementieren und zu kontrollieren.

Herausforderungen des Embedded Software Engineering

Bei der Entwicklung von Software für eingebettete Systeme stehen Entwickler besonderen Randbedingungen gegenüber, die es für eine korrekte Funktion zu beherrschen gilt. Hierzu zählen die Kopplung zu physikalischen Prozessen, die damit einhergehenden Anforderungen an Zuverlässigkeit und die zunehmende Anzahl von verteilten Systemen mit hoher Dynamik.

Kopplung an physikalische Prozesse: Die physikalischen Prozesse, mit denen die eingebetteten Systeme gekoppelt sind und deren Wechselwirkungen durch die Software behandelt werden sollen, zwingen dem System ein gegebenes Zeitverhalten auf. Da sich die Zeitabläufe z.B. bei gesteuerten Motoren nicht ändern lassen, muss folglich das eingebettete System in Echtzeit arbeiten, also in seinem zeitlichen Verhalten dem umgebenden technischen System angepasst sein. Hierbei unterscheidet man hartes und weiches Echtzeitverhalten. Die Differenzierung erfolgt ausschließlich durch die Konsequenzen, die ein zeitliches Fehlverhalten hervorrufen kann: gefährdet ein solches Fehlverhalten Mensch und/oder Material, so darf es nicht vorkommen, und das System muss unter allen Umständen die zeitlichen Bedingungen erfüllen. Dies wird als hartes Echtzeitsystem bezeichnet.

Erzeugt das Fehlverhalten lediglich eine Qualitätsminderung, so spricht man von einem weichen Echtzeitsystem. Andere Anpassungen an das physikalische System können z.B. die maximal erlaubte Verlustleistung, aufgrund der maximal verfügbaren elektrischen Leistung oder die Begrenzung der erzeugten Wärme, bzw. die mittlere Energieaufnahme betreffen. Im Fall von batteriebetriebenen Geräten bestimmt die mittlere Energieaufnahme die Einsatzdauer. Anpassungen an die elektrischen Werte können meist nur durch gemeinsames Hard- und Software Engineering (Co-Design) erreicht werden.

Zuverlässigkeitsanforderungen: Die Zuverlässigkeitsanforderungen, die in besonderem Maße an eingebettete Systeme gestellt werden, betreffen die Hard- und Softwarequalität. Softwarequalität ist die Gesamtheit der Merkmale und Merkmalswerte eines Softwareprodukts, die sich auf dessen Eignung beziehen, festgelegte oder vorausgesetzte Erfordernisse zu erfüllen. Als Merkmale gelten Funktionen, Zuverlässigkeit, Benutzbarkeit, Effizienz, Änderbarkeit und Übertragbarkeit.

Die Zuverlässigkeit (engl. reliability) ist als Wahrscheinlichkeit definiert, dass ein System seine definierte Funktion innerhalb eines vorgegebenen Zeitraums und unter den erwarteten Arbeitsbedingungen voll erfüllt, das heißt intakt ist und es zu keinem Systemausfall kommt. Bei den Fehlern bzw. fehlerhaften Handlungen, die die Zuverlässigkeit herabsetzen, müssen zwischen der fehlerhaften Handlung (engl. error), die zu einem späteren Fehler führt, der fehlerhaften Stelle im Gerät bzw. Programmcode, auch als innerer Fehler (engl. fault) bezeichnet, und dem tatsächlichen Fehlverhalten, auch Fehlerwirkung oder äußerer Fehler (engl. failure) bezeichnet, unterschieden werden.

Die Rate der äußeren Fehler wird in FIT (Failure in Time, Anzahl der auftretenden Fehler pro 109 Betriebsstunden) gemessen. Die durch Software verursachten Fehler übersteigen die Hardwarerate ohne besondere Maßnahmen um ca. 100 bis 1000 (Literatur: González et.al.). Hierin besteht eine wesentliche Aufgabe des Embedded Software Engineering: diese Rate auf geforderte Werte zu reduzieren.

Verteilte Systeme mit hoher Dynamik: Bei einer zunehmenden Anzahl von Systemen ist die Anzahl der (eigenständigen) elektronischen Komponenten sehr hoch, sie bewegt sich zwischen einigen 100 bis über 1000 Komponenten. Entwicklungen wie Smart Sensors (Sensoren mit eingebauter Vorverarbeitungz.B. durch Mikroprozessoren) oder MEMS (microelectromechanical system) zeigen, dass die Durchdringung eines physikalischen Prozesses mit elektronischen Komponenten zur Messung, Steuerung und Regelung sehr weit gehend sein kann und dass die Trennung nach physikalischer Prozess/Informationsverarbeitung nicht mehr aufrechterhalten werden kann.

Kombination aus Verteilung, Zuverlässigkeit und Dynamik

Die Probleme in der Softwareentwicklung solcher Systeme lassen sich durch zwei meist geforderte Eigenschaften darstellen: Zum einen soll eine solche verteilte Applikation robust, zuverlässig und in Echtzeit arbeitend sein, zum anderen arbeitet die verteilte Applikation hochgradig parallel, und das Gesamtsystem ist meist auch dynamisch, d.h. die Applikation muss sich den wandelnden Bedingungen anpassen.

Die Kombination aus Verteilung, Zuverlässigkeit und dynamischer Anpassung gilt als besondere Herausforderung.

Neben der algorithmischen Korrektheit einer Applikation müssen bei eingebetteten Applikationen meist eine oder mehrere weitere Bedingungen eingehalten werden. Abgesehen von den grundlegenden Prinzipien des Software Engineering, die auch im eingebetteten Bereich zur Anwendung kommen, können zusätzliche Methoden zum Einsatz kommen, um diese Bedingungen zu erfüllen.

Referenzmodell eines nicht verteilten eingebetteten Systems: Charakteristisch ist die starke Außenbindung mithilfe von Aktoren und Sensoren.
Referenzmodell eines nicht verteilten eingebetteten Systems: Charakteristisch ist die starke Außenbindung mithilfe von Aktoren und Sensoren.
( Bild: Christian Siemers )

Referenzmodell für Embedded: Das nebenstehende Bild zeigt das allgemeine Referenzmodell eines nichtverteilten eingebetteten Systems. Charakteristisch ist die starke Außenbindung mithilfe von Aktoren und Sensoren; diese stellen die wesentliche Kopplung an die technische Umgebung dar, in der das System eingebettet ist. Die Benutzerschnittstelle kann entfallen, in diesem Fall handelt es sich um ein tief eingebettetes System (engl. Deeply Embedded System). Die Referenzarchitektur zeigt, dass eingebettete Applikationen eine starke Eingabe/Ausgabe-(Input/Output-, I/O-)Bindung besitzen. Dementsprechend sind Hard- und Software stark I/O-dominant ausgeführt.

Designmethoden zur Erfüllung zeitlicher Vorgaben: Die Echtzeitfähigkeit einer Software-Applikation ist die häufigste Bedingung, die erfüllt werden muss. Die Echtzeitfähigkeit bezieht sich dabei auf das gezeigte Referenzmodell, d.h., das System muss im Allgemeinen auf Ereignisse von außen rechtzeitig reagieren. Rechtzeitig heißt, dass es eine maximale Zeit nach Eintreten des Ereignisses gibt, bei der die Reaktion eingetreten sein muss, ggf. auch eine minimale Zeit nach dem Ereignis, vor der die Reaktion nicht eintreten darf. Letzteres ist z.B. notwendig, wenn in einer ggf. verteilten Applikation mehrere Reaktionen gleichzeitig eintreten müssen.

Um die Kopplung zwischen Umgebungsereignissen und dem eingebetteten System herzustellen, bieten sich zwei Methoden an: zeitgesteuertes Design und ereignisgesteuertes Design. Das zeitgesteuerte Design (engl. Time-triggered Design) geht davon aus, dass es in der Software einen meist periodisch aufgerufenen Teil gibt, in dem festgestellt wird, ob Ereignisse vorliegen. Die Implementierung kann z.B. durch einen periodisch per Timer ausgelösten Interrupt Request (IRQ) mit zugehöriger Interrupt Service Routine (ISR) erfolgen.

Dieser zyklisch ablaufende Teil stellt also fest, ob Ereignisse vorliegen und startet die entsprechende Reaktionsroutine. Die Zykluszeit richtet sich nach der geforderten maximalen Reaktionszeit für dieses Ereignis sowie andere Zeiten im System. Diese Designmethodik ergibt ein statisches Design, bei dem alle Aktivitäten zur Übersetzungszeit (engl. Compile Time) bekannt sein müssen. Die Echtzeitfähigkeit dieses Designs lässt sich beweisen, wenn alle maximalen Bearbeitungszeiten (engl. Worst-Case Execution Time, WCET) und alle maximalen unterbrechungsfreien Zeiten (engl. Worst-Case Interrupt Disable Time, WCIDT) bekannt sind.

Ereignisgesteuertes Design: Im ereignisgesteuerten Design (engl. Event-triggered Design) wird den Ereignissen selbst ein Interrupt Request zugewiesen. Dies bedeutet, dass die zugehörigen Serviceroutinen zumindest teilweise als Interrupt-Service-Routine ausgelegt sein müssen, und ein Interrupt Priority Management muss die Prioritäten bei gleichzeitigem Auftreten regeln. Das Gesamtsystem ist hierdurch scheinbar weniger belastet, weil die Ereignisbehandlung nur dann aufgerufen wird, wenn tatsächlich etwas vorliegt. Das System selbst kann jedoch im Vergleich zum zeitgesteuerten Design nicht schwächer ausgelegt werden, weil die Echtzeitfähigkeit garantiert werden muss. Die Systemauslegung eines (harten) Echtzeitsystems muss immer der maximalen Last folgen, nicht einer mittleren.

Negativ am ereignisgesteuerten Design ist außerdem, dass die maximal definierte Ereignisrate nicht automatisch eingehalten werden muss. Zusätzlich Hardwaremaßnahmen sind erforderlich, falls – etwa durch prellende Schalter oder Teilprozesse, die außerhalb der Spezifikation arbeiten – angenommene Ereignisraten überschritten werden können, um die Arbeitsfähigkeit der Applikation zu erhalten.

Designmethodik für verteilte Systeme mit Echtzeitfähigkeit

Der Autor: *Prof. Dr. Christian Siemers ist Fachmann für Echtzeitsysteme, Hardware/Software Co-Design, Hardwarenahe Software und Transcodierungen, Automatisierungstechnik sowie Sichere Systeme (Safety), insbesondere Fehlererkennung, -behebung und Fehlertoleranz. Er unterrichtet an der TU Clausthal sowie an der Hochschule Nordhausen.
Der Autor: *Prof. Dr. Christian Siemers ist Fachmann für Echtzeitsysteme, Hardware/Software Co-Design, Hardwarenahe Software und Transcodierungen, Automatisierungstechnik sowie Sichere Systeme (Safety), insbesondere Fehlererkennung, -behebung und Fehlertoleranz. Er unterrichtet an der TU Clausthal sowie an der Hochschule Nordhausen.
( Bild: Prof. Dr. Siemers )

Das zeitgesteuerte Design kann dahingehend verallgemeinert werden, dass ein synchrones Systemdesign gewählt wird. Dieses entspricht dem meist genutzten Modell der digitalen Hardware: Berechnungen werden durch ein (asynchrones) Schaltnetz durchgeführt und am Ende eines Zeittakts in Flipflops gespeichert. Übertragen auf das Softwaredesign heißt dies, dass algorithmische Berechnung und Kommunikation (vor oder nach der Berechnung) in einer angenommenen Zeitspanne durchgeführt werden und am Ende dieser Zeitspanne alle Ergebnisse als Eingang für den nächsten Zeitabschnitt gespeichert werden.

Die synchrone Designmethodik ergibt dann eine Systemarchitektur, die der eines komplexen, kooperierenden Automaten entspricht. Für echtzeitfähige verteilte Systeme muss die Kommunikationszeit selbst begrenzt sein, was durch spezielle Netzwerke (z.B. TTP/C, Time-Triggered Protocol Class C oder diverse Echtzeit-Ethernet-Standards) gewährleistet ist.

In der Entwicklung selbst muss die Annahme, dass die algorithmische Verarbeitung innerhalb einer vorgegebenen Maximalzeit erfolgt, nachgewiesen werden (WCET-Bestimmung). Synchrone Sprachen, die die Entwicklung unterstützen, sind Esterel, Lustre und Signal. Zur zeitlichen Definition des Systemverhaltens, insbesondere auch bei verteilten Systemen, bietet sich auch Time Definition Language (TDL) an.

Designmethoden zur Erfüllung energetischer Vorgaben

Um energetische bzw. Verlustleistungs-bezogene Vorgaben zu erfüllen, existieren vergleichsweise wenig Software-basierte Methoden. Die Auswahl eines Mikrocontrollers anhand der energetischen Eigenschaften oder sogar der Wechsel auf anderen programmierbare Architekturen wie Field-Programmable Gate Arrays (FPGA) können wesentlich Energie sparender wirken als reine Softwarelösungen.

Innerhalb des Softwaredesigns können drei Methoden angewendet werden um den Energiebedarf bzw. die Verlustleistung zu senken:

  • Die tatsächliche Laufzeit des Programms pro betrachteter Zeiteinheit wird möglichst minimal gestaltet, und in den Zeiten, in denen der Prozessor idle ist, wird der Betriebszustand „schlafend“ o.ä. gewählt. Dieser Betriebszustand (der Hardware) ist dadurch gekennzeichnet, dass viele Teile des Prozessors abgeschaltet sind und dadurch der Energieumsatz stark minimiert wird. Wie weit gehend abgeschaltet werden kann und wie der Prozessor wieder aufgeweckt wird kann nur im Einzelfall entschieden werden und ist abhängig von dem Prozessortyp, der Planbarkeit der Applikation usw.
  • In einem anderen Ansatz wird versucht, das Programm so zu gestalten, dass bei Einhaltung aller Zeitschranken möglichst gleiche Idle-Zeiten (pro betrachteter Zeiteinheit) entstehen. Im zweiten Schritt kann dann die Taktfrequenz des Prozessors (und damit auch die Betriebsspannung) so angepasst werden, dass keine Idle-Zeiten mehr existieren. Dies liefert ein gleichförmig arbeitendes Design mit minimierter Verlustleistung. Die ideale Zeiteinheit, deren Ablauf optimiert wird, ist dabei die Superperiode (= kleinstes gemeinsames Vielfaches über alle verschiedenen periodischen Abläufe im System), die Anpassung der Taktfrequenz muss jedoch für jede einzelne Periode möglich sein.
  • Alternativ oder zusätzlich können auch spezialisierte Compiler verwendet werden, die energetisch besonders günstigen Code liefern. So ist der Bedarf an elektrischer Energie für verschiedene Instruktionen unterschiedlich, dies kann ausgenutzt werden.

Weiterführende Literatur

Helmut Balzert: Lehrbuch der Software-Technik. Bd.1. Software-Entwicklung. Spektrum Akademischer Verlag, Heidelberg 1996, 1998, 2001, ISBN 3-8274-0480-0.
Shankar Sastry, Janos Szipanovitis, Ruzena Bajcsy, Helen Gill: Modelling & Design of Embedded Software. Proceedings of the IEEE 91(1), 2003, ISSN 0018-9219.
Antonio González, Scott Mahlke, Shubu Mukherjee, Resit Sendag, Derek Chiou, Joshua J. Yi: Reliability: Fallacy or Reality? IEEE Micro 24(6), pp. 36-45.
Christian Siemers, Eine kleine Geschichte der Zeit. Elektronikpraxis 43 (23), S. 42-43 (2007)

Dieser Beitrag ist ursprünglich auf unserem Partnerportal Embedded Software Engineering erschienen.

* Prof. Dr. Christian Siemers ist Fachmann für Echtzeitsysteme, Hardware/Software Co-Design, Hardwarenahe Software und Transcodierungen, Automatisierungstechnik sowie Sichere Systeme (Safety), insbesondere Fehlererkennung, -behebung und Fehlertoleranz.

Dieser Beitrag ist urheberrechtlich geschützt. Sie wollen ihn für Ihre Zwecke verwenden? Infos finden Sie unter www.mycontentfactory.de (ID: 46081254)

Redaktion Industry of Things; NuernbergMesse/Frank Boxler; MathWorks; DFKI; Pexels; Pixabay; gemeinfrei; Mesago/Thomas Geiger; Christian Siemers; Prof. Dr. Siemers; fischertechnik; Axians; Medisana/Oliver Eltinger; Vogel Communications Group; Edag