Eingebettetes System

Embedded Systems ist der englische Fachbegriff für eingebettete (Computer-)Systeme, die – weitestgehend unsichtbar – ihren Dienst in einer Vielzahl von Anwendungsbereichen und Geräten versehen, wie z. B. in Flugzeugen, Autos, Kühlschränken, Fernsehern, DVD-Playern oder allgemein Geräten der Unterhaltungselektronik.

Embedded Systems vereinigen daher durch ihre oftmals sehr hardwarenahe Konstruktion die große Flexibilität von Software mit der Leistungsfähigkeit der Hardware.

Die Software-Entwicklung für diese Systeme unterscheidet sich grundsätzlich von der von z. B. Desktop- oder PC-Systemen: Oftmals werden Betriebssysteme eingesetzt, die zwar nicht über Speicherschutz verfügen (der eher selten auch in der Hardware realisiert ist), dafür jedoch Echtzeitanforderungen genügen. Bei „kleinen“ Systemen kommt häufig auch überhaupt kein Betriebssystem zum Einsatz. Im Gegensatz zu Software-Entwicklern für PC-Systemen muss sich der Software-Entwickler für Embedded Systems meist selbst mit den Möglichkeiten der Ein-/Ausgabe beschäftigen. Funktionen dafür sind sehr hardwareabhängig und in der Regel für jedes System neu zu entwickeln.

Übliche Embedded-Betriebssysteme sind z. B. VxWorks, OSEK, zunehmend auch spezielle Linux-Derivate, NetBSD, aber auch für Java gibt es Ansätze wie etwa OSGi. Bevorzugte Programmiersprache ist im Allgemeinen C oder C++. Assembler wird dann eingesetzt, wenn zeitkritische Funktionen vor allem in Interrupts programmiert werden. Im Zusammenhang mit Betriebssystemen ist Assembler eher eine Randerscheinung; in Systemen ohne Betriebssystem und vor allem bei massiven Speicherrestriktionen kommt Assembler eher zur Anwendung.

Beispiele

Beispiel 1: Die Elektronik in einem Kaffeevollautomaten ist ein eingebettetes System. Mit ihr wird beispielsweise die Kaffeemenge und -stärke reguliert. Die Kaffeemaschine an sich ist kein datenverarbeitendes System.

Beispiel 2

Im weitesten Sinne ist jedoch auch die Elektronik in einem Videorekorder ein eingebettetes System, obwohl man den Videorekorder selbst auch wieder als ein datenverarbeitendes System bezeichnen könnte. Man setzt deshalb für die Definition des eingebetteten Systems voraus, dass

die genaue Aufgabe des Systems vor der Entwicklung feststeht
Hardware und Software eine funktionale Einheit bilden.

Beispiel 3: Ein Mobiltelefon.

Charakterisierung

Embedded Systems basieren häufig auf derselben Hardware wie Arbeitsplatzcomputer, sie unterliegen jedoch meist stark einschränkenden Randbedingungen: Minimale Kosten und damit geringer Platz-, Energie-, Speicherverbrauch. Die Fertigung in großen Stückzahlen, oft im Millionen-Bereich, ist ein weiterer wichtiger Punkt zur Kostenreduzierung. Hinzu kommt, dass die einzelnen Komponenten wie Prozessor und RAM auf Weiterentwicklungen älterer Komponenten basieren, was die Langlebigkeit steigert, Stromverbrauch und -kosten jedoch nicht unbedingt senkt. „Moderne“ Entwicklungen werden demzufolge häufig auf Plattformen basieren, die mit der PC-Welt nichts mehr zu tun haben, aber im Bezug auf die Peripheriemodule hochintegriert sind und durch moderne Stromspartechniken entschieden weniger Energie verbrauchen.

Für viele Anwendungen können auch ältere Komponenten eingesetzt werden, wenn zudem die Vereinfachung der Architektur des ursprünglichen Systems dazu beiträgt, weitere Kosten zu senken. So ist die Architektur 8051 von 1980 trotz ihrer bekannten Schwächen immer noch eine sehr beliebte Basis für Embedded Systems.

Programme eines Embedded System müssen oft Echtzeitanforderungen genügen. In der Regel existieren verglichen mit Desktop-PC-Hardware nur stark reduzierte Ressourcen, zumeist ohne Festplatte, Betriebssystem, Tastatur oder Bildschirm. Ein ROM- oder Flash-Chip ersetzt meist mechanische Speicherkomponenten wie eine Festplatte: bewegliche Teile bedeuten Verschleiß, der hier unerwünscht ist. Wenn überhaupt, dann gibt es meist nur ein Tastenfeld und die Ausgabe wird – soweit vorgesehen – durch ein LCD realisiert.

Die Software auf einem solchen Gerät wird Firmware genannt. Sie befindet sich gewöhnlich auf einem ROM, immer häufiger jedoch auf Flash-Speicher. Im Falle eines Flash-Speichers besteht die Möglichkeit eines Firmware-Updates, ohne dass der Chip ausgewechselt werden muss. Ist nur ein ROM vorhanden, muss zumeist der gesamte Chip ausgewechselt werden, je nach Verbau die gesamte Schaltung.

Plattformen

Embedded Systems werden mittels vieler verschiedenen CPU-Architekturen (MIPS, ARM, Intel x86, PowerPC, 68k/Coldfire, 68HC12, C167, diverse 8/16 Bit-CPUs, ...) realisiert.

Betriebssystem

Wenn ein Betriebssytem eingesetzt wird, arbeitet man in Embedded Systems meist mit sehr spezialisierten Betriebssystemen (VxWorks, Nucleus, OSEK, OS-9 usw.). Oftmals verwendet man Konfigurationen mit harten/weichen Echtzeitanforderungen, wie unten näher beschrieben.

Allerdings finden auch spezielle Embedded-Versionen von Standard-Betriebssysteme wie Linux (Embedded Linux), NetBSD oder Windows (CE, EmbeddedXP) inzwischen großen Anklang.

Entwicklungsumgebung, Werkzeuge

Die Software zur weiteren Programmentwicklung, also Compiler, Assembler und Debugger (wobei beim Debugging regelmäßig auch Hardware eingesetzt werden muss), werden meist von verschiedensten Herstellern angeboten:

Softwarefirmen, welche sich auf solche Geräte bzw. Programme spezialisiert haben.
Die Programme werden in der Regel über einen Crosscompiler erzeugt. Dieser Compiler wird auf einer ganz anderen Architektur (in der Regel einem PC) laufen als das Zielsystem.
Teilweise können Compiler anderer, schon unterstützter Architekturen, welche direkt mit der verwendeten Architektur verwandt sind, verwendet werden.

Debugging, Fehlersuche

Debugging umfasst sowohl Fehlersuche in der Software als auch des integrierten Systems. Für Software-Debugging kann ein sog. „In-Circuit Emulator“ (ICE) verwendet werden, einer Kombination aus Programm und Hardware, welche es erlaubt, die Software „im System“, das heißt, auf der Zielhardware, zu testen. Dazu muss aber der eigentliche Controller gegen die ICE-Hardware (ein sog. „Bondout-Chip“) ausgetauscht werden. Dies erlaubt es, die Software komfortabel, ohne weitere aufwändige Eingriffe an der Zielhardware, zu entwickeln. Da mit dem ICE Zugriffe auf die Peripherie der CPU möglich sind, lassen sich so Software- von Hardwarefehlern unterscheiden und trennen. Früher wurde dazu ein Logikanalysator benötigt, der als Zusatzoption die Ziel-CPU emulieren konnte.

Heutige Embedded CPUs haben in der Regel einen „Schmalspur“-ICE schon on Board, so daß der Hardware-ICE nicht mehr benötigt wird. Dafür sind die Einwirkungsmöglichkeiten von der Debugging-Software auf die Ziel-CPU bedeutend eingeschränkt. Eine komplette Überwachung der CPU ist nicht möglich, dafür sind die Kosten erheblich gemindert. Kostet ein voll ausgebautes ICE-System für z.B. ein 68k-Derivat bis in den 6-stelligen Eurobetrag, sind die Kosten für solch ein „Schmalspur“-System häufig im unteren 3-stelligen Eurobereich. Hier kommt in der Regel eine Schnittstelle vom Typ „JTAG“ zum Einsatz. (Speziell für die 68k-Derivate gibt es eine Schnittstelle, die sich „Background Debug Module“, BDM, nennt, die von Motorola schon lange vor den JTAG-Schnittstellen benutzt wurde. Auch hier sind die Kosten um fast drei Zehnerpotenzen geringer.)

Alternativ, wenn man keinen ICE zur Verfügung hat, wird oft mit Simulatoren gearbeitet, welche die interne Struktur und die Peripherie des Microcontrollers in Software nachbilden. Hier müssen aber beim Debugging die „externen“ Signale (Tasten, Display usw.) „per Hand“ nachgebildet werden, wobei in der Regel Interrupts benutzt werden müssten, die im Simulator normalerweise nicht realisierbar sind.

Inzwischen gibt es auch im Embedded-Bereich Entwicklungen auf Java-Basis. Gründe sind u. a. die Möglichkeit des einfacheren Plattformwechsels bzw. der Plattformunabhängigkeit und der Wegfall von Simulatoren (siehe OSGi und Embedded Java).

Der Microcode-Interrupt lässt den Debugger auf der Hardware arbeiten, auf welcher sonst nur die CPU arbeitet. Von dem Standpunkt der CPU aus können CPU-basierte Debugger dann benutzt werden, um die Elektronik des Computers zu testen und gegebenenfalls Fehler in dieser zu diagnostizieren. Diese Fähigkeit wurde an der PDP-11 (siehe Programmed Data Processor) erforscht und entwickelt.

Der Systemtest wird mittels der sogenannten Hardware-in-the-Loop-Technik durchgeführt, bei der das fertige System an eine Spezialhardware angeschlossen wird, die die Umgebung des Systems simuliert. Auf diese Weise kann das Verhalten des Systems mit Testfällen detailliert untersucht werden.

Geschichte

Das erste bemerkenswerte moderne Embedded System war der Apollo Guidance Computer, welcher von Charles Stark Draper zusammen mit dem MIT Instrumentation Laboratory entwickelt wurde. Jeder Flug auf den Mond hatte zwei dieser Systeme, welche zur Steuerung verwendet wurden, dabei. Das inertial guidance system wurde sowohl im Kommandomodul als auch in der Mondlandefähre (LEM, Lunar Excursion Module) verwendet.

Zu Beginn des Apollo-Projekts wurde genau dieses System als eines der riskantesten Komponenten des Projektes angesehen.

Die ersten Embedded Systems wurden allerdings schon vorher in der Minuteman-Rakete eingesetzt und als Folge dessen in Massenproduktion hergestellt. Die Anwendung war ein Wege-Such-System, welches der Rakete nach einmaliger Programmierung eine unabhängige Manövrierung ermöglichte. Die verwendeten integrierten Schaltungen wurden nach einiger Zeit, dank der Massenproduktion, für jedermann erschwinglich und damit nutzbar gemacht.

Die entscheidende Eigenschaft des Minuteman-Computers war, dass man den Weg-Finde-Algorithmus später programmieren konnte, wodurch man die Rakete wesentlich präziser einsetzen konnte. Ein weiterer Vorteil war die Selbsttestfunktion der Rakete zur Statusabfrage und, dass man auf größere Mengen von Kabeln zu Gunsten des Gewichtes verzichten konnte.

Design von Embedded Systems

Die Elektronik bildet meist ein Mikroprozessor mit entsprechender Peripherie oder ein Microcontroller. Einige größere, aber meist veraltete Systeme verwenden Allzweck-Mainframes oder Minicomputer.

Folgende Aspekte spielen bei Designentscheidungen von Embedded Systems eine Rolle:

Integration: Je mehr Funktionalität der verwendete Mikrocontroller bereits enthält, desto weniger Peripheriebausteine werden benötigt, um die Anbindung an die benötigten Systemschnittstellen (Ein-/Ausgabe) zu ermöglichen. Je weniger Bausteine eine Platine benötigt, desto geringer ist der Platzbedarf der Leiterbahnen und die Signallaufzeiten zwischen den Bausteinen. Diese Überlegungen führten dazu, dass auf heutigen Mikrocontrollern meist schon bereits ausreichend RAM und anderer Peripherie-Funktionen vorgesehen sind.

Echtzeitanforderungen: Hohe Verfügbarkeit und definierte Antwortzeiten sind häufig gestellte Anforderungen an ein Embedded System und damit auch an dessen Betriebssystem und Software. Beispielsweise muss die elektronisch gesteuerte Bremse oder der Airbag nahezu unverzögert im Millisekundenbereich reagieren, eine Überschreitung der definierten Latenzzeit ist nicht tolerierbar. Die einfache und geschlossene Bauweise sowie die Verwendung spezieller Echtzeitbetriebssysteme erlauben es schon in der Entwicklungsphase, die Reaktionszeiten des Gesamtsystems abzuschätzen.

Stückpreis: Der Stückpreis hängt wie viele Waren des Marktes von den Entwicklungs- und Herstellungskosten ab. Je höher die Stückzahl, desto geringer ist der Anteil der Entwicklungskosten je Stück. Bei großen Produktionsmengen wird daher von der Entwicklung viel Aufwand in die Optimierung des Ressourcenverbrauchs gesteckt, um z. B. durch Speichereinsparung die Materialkosten weiter drücken zu können. Bei geringen Stückzahlen fallen die Materialkosten dagegen weniger ins Gewicht. Hier lohnt es sich dann wieder mit teureren, aber dafür flexibleren Bausteinen (z .B. FPGAs) die Entwicklungszeit zu verringern.

Entwicklungsumgebung: siehe Entwicklungswerkzeuge

Systemstart

Alle Embedded Systems haben einen Start-up Code, welcher nach dem Einschalten durchlaufen wird. Normalerweise deaktiviert dieser die Interrupts, kalibriert die interne Elektronik, testet den Computer (RAM, CPU und Programmcode) und startet den Programmcode, nachdem alles erfolgreich getestet wurde.

Viele dieser Systeme sind innerhalb von 100 ms einsatzbereit. Selbst nach einem kleinen Stromausfall bzw. einer Spannungsschwankung laufen diese Geräte sofort weiter, da die interne Hardware dann den Selbsttest der Hardware und Software überspringt und direkt weiterarbeitet. Hierbei treten jedoch durch möglicherweise veränderte Bits im RAM manchmal undefinierte Systemverhalten auf, die eine Schaltung zur Spannungsüberwachung (Supply Voltage Supervisor, SVS) vermeidet. Der SVS löst einen „richtigen“ Reset aus, so daß das System komplett initialisiert wird und eben auch die Selbsttests durchläuft.

Verschiedene Typen von Embedded-Software-Architekturen

Es finden verschiedene Softwarekonzepte Anwendung:

Regelschleife

Regelschleifen werden für Regelungssysteme eingesetzt, die zyklisch Berechnungen aufgrund von Eingangssignalen vornehmen und Ausgangssignale senden. Siehe Regelungstechnik.

Reaktive Systeme

Reaktive Systeme verarbeiten aperiodisch auftretende Ereignisse, wie beispielsweise einen Tastendruck und veranlassen entsprechende Aktionen.

Benutzeroberfläche

Eingebettete Systeme besitzen häufig keine eigene Benutzeroberfläche. Jedoch kann eine mittelbare Benutzerkommunikation über Datenschnittstellen vorgesehen werden, indem etwa netzwerkfähige Drucker und ähnliche Geräte meist über ein Webinterface verfügen, über welches man per Browser alle wichtigen Konfigurationseinstellungen vornehmen kann. Viele Systeme haben zwischenzeitlich aber auch schon ein Display, über welches das System mit dem Benutzer kommunizieren kann.

Siehe auch