Embedded System
Bei sogenannten Embedded Systems handelt es sich um eingebettete (Computer)systeme, die - weitestgehend unsichtbar - ihren Dienst in einer Vielzahl von Anwendungsbereichen versehen, wie z.B. in Flugzeugen, Autos, Kühlschränken, Fernsehern, DVD-Playern oder allgemein Geräten der Unterhaltungselektronik."Embedded Systems" vereinigen durch ihre oftmals sehr hardware-nahe (und vergleichsweise) einfache Konstruktion daher die große Flexibilität von Software mit der Leistungsfähigkeit der Hardware.
Die Software-Entwicklung für diese Systeme ist daher nicht vergleichbar mit der für z.B. Desktop- oder PC-Systeme: oftmals werden Betriebssysteme eingesetzt, die zwar nicht über Speicherschutz verfügen, dafür jedoch Echtzeitanforderungen genügen.
Bevorzugte Programmiersprachen sind daher z.B. Assembler oder C. Übliche Embedded-Betriebssysteme sind z.B. VxWorks, zunehmend auch spezielle Linux-Derivate, aber auch für Java gibt es Ansätze wie etwa OSGi.
;Beispiel 2 : Im weitesten Sinne ist jedoch auch die Elektronik in einem Videorekorder ein eingebettetes System, obwohl der Videorekorder selbst auch wieder ein datenverarbeitendes System ist. Man setzt deshalb für die Definition des eingebetteten Systems voraus, dass
Beispiele
;Beispiel 1 : Die Elektronik in einem Kaffeevollautomaten ist ein eingebettetes System. Mit ihr wird beispielsweise die Kaffeemenge und -stärke reguliert. Die Kaffemaschine an sich ist kein datenverarbeitendes System.
;Beispiel 3 : Ein Mobiltelefon.
Embedded-Systeme basieren zumeist auf derselben Hardware wie Computer, jedoch mit zwei wesentlichen Unterschieden: Kosten und Stromverbrauch. Die Fertigung in großen Stückzahlen, zumeist im Millionen-Bereich, ist ein weiterer wichtiger Punkt zur Kostenreduzierung.
Hinzu kommt, dass die einzelnen Komponenten wie Prozessor und RAM auf Weiterentwicklungen von älteren Komponenten basieren, was die Langlebigkeit steigert, Stromverbrauch und -kosten jedoch senkt.
Die hierbei verwendeten älteren Komponenten sind jedoch noch nicht die einzige Erklärung, warum diese Systeme langsam sind, denn die gesamte Architektur des ursprünglichen Systems wurde vereinfacht, um weitere Kosten zu senken.
Ein Beispiel hierfür wären die Peripheriegeräte, die durch ein synchrones serielles Interface kontrolliert werden, welche bis zu hundert mal langsamer sind als vergleichbare Konzepte aus der Desktop-PC-Welt.
Die Programme auf einem Embedded System laufen meist im Echtzeitmodus mit stark reduzierten Ressourcen verglichen zu aktueller Computerhardware, zumeist ohne Festplatte, Betriebssystem, Tastatur oder gar Bildschirm. Ein kleiner Flash-ROM oder Flash-RAM-Chip ersetzen mechanische Komponenten wie eine Festplatte. Wenn überhaupt, dann gibt es nur ein kleines Tastenfeld und die Ausgabe wird oft höchstens durch ein LCD realisiert.
Die Software auf einem solchen Gerät wird oft Firmware genannt und wird auf das Flash-RAM gespielt. Im Falle eines Flash-RAMs besteht die Möglichkeit eines Updates, ohne den Chip wechseln zu müssen. Wenn man allerdings nur ein Flash-ROM hat, muss zumeist der gesamte Chip ausgewechsels werden und da dieser meist fest auf der Platine ist, die gesamte Schaltung.
Embedded Systems werden mittels vielen verschiedenen CPU-Architekturen realisiert. Dies stellt einen, wenn auch nicht den größten Unterschied, zum Desktop-Computer dar, da dieser zumeist nur durch zwei wesentliche Architekturen realisiert wird, momentan (2004) x86 und PowerPC (letzterer in Computern der Firma Apple).
Die Software, also Compiler, Assembler und Debugger, welche zur weiteren Programmentwicklung verwendet werden, kommen zumeist von verschiedensten Orten oder Herstellern:
Embedded Systeme verfügen, im konventionellen Sinne, oftmals über kein Betriebssystem. Zumeist arbeitet man mit real-time-Systemen wie unten näher beschrieben.
Es gibt aber auch sehr komplexe Betriebssysteme wie z.B. Linux, welche dann mit einigen Modifikationen im System integriert werden können.
Debugging wird normalerweise mit einem "in-circuit-Emulator" realisiert, also einem Programm, welches die komplette Hardware auf Softwarebasis simuliert. Da man meist langsame Hardware im Embedded System verwendet und die heutigen Computer viel leistungsstärker sind, kann man damit genau so arbeiten, als würde man direkt mit der Hardware des Embedded Systems arbeiten. Die Vorteile sind jedoch wesentlich. So kann man die Software, welche später auf dem embedded System laufen soll, optimal und komfortable mit dem Simulator entwickeln, ohne komplizierte und zeitaufwändige Eingriffe an der Hardware. Im konventionellen Fall müsste man jedes Update wieder auf den Chip des embedded Systems spielen, dieses dann starten und testen. Wenn man selbiges mittels Simulator macht, kann man auch die simulierte Hardware zur Laufzeit ändern und auf das ev. Fehlverhalten testen.
Alternativ, wenn man keinen Hardwareemulator zur Verfügung hat, wird oft mit Debuggern gearbeitet, welche interne Interrupts des Microcontrollers verwenden. Stichwort Microcode.
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 erforscht und entwickelt.
Entwickler sollten auf alle Fälle die Möglichkeit des Debuggings, welche höhere Programmiersprachen mit sich bringen, nutzen. Diese verfügen über die Möglichkeit, in Programmen Breakpoints (engl. Haltepunkte) zu setzen und dann kann das Programm im Single-Stepping- (Einzelschritt-) Modus durchlaufen werden. Man sollte auch einfache Programme verwenden, welche Sequenzen von Echtzeitereignissen mitloggen können, um Fehler effizienter zu finden.
PC- oder Mainframeprogrammierer, welche zum ersten Mal mit einer solchen Programmiertechnik in Kontakt gelangen, scheinen zuerst oftmals etwas verwirrt über die Implementierungsziele und die dazu verwendeten Methoden.
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 dem LEM, also dem Mondlandemodul, verwendet.
Zu Begin des Apollo-Projekts wurde genau dieses System als eines der riskantesten Komponenten des Projektes angesehen.
Die ersten Embedded-Systeme 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 (engl. Integrated Circuits) wurden nach einiger Zeit, dank der Massenproduktion, für jedermann erschwinglich.
Die entscheidende Eigenschaft des Minuteman-Computers war, dass man den Weg-Finde-Algorithmus später programmieren konnte, woduch 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.
Die Elektronik ist meist ein Mikroprocessor oder ein Microcontroller.
Einige größere, aber veraltete Systeme verwenden Allzweck-Mainfraims oder Minicomputers.
Alle Embedded-Systeme 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 nachdem alles erfolgreich getestet wurde, wird der Programmcode gestartet, den der Entwickler vorgibt.
Die meisten 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.
Viele dieser Geräte verfügen über eine per Software steuerbare Kontrollleuchte. Dies ist hilfreich, da diese leuchtet, falls das System in einen Fehlzustand gelangt ist.
Es finden verschiedene Softwarekonzepte Anwendung:
In dieser Implementierung durchläuft die Software einfach eine endlose Schleife (eng. LOOP) und diese ruft dann Unterprogramme (engl. Subroutine) auf. Die Unterprogramme wiederum sind dann die Software des Programmierers oder Systemaufrufe zur Hardware. Diese Interrupts (engl. Unterbrechungen) setzen Flags oder interne Zähler, welche dann wiederum vom System gelesen werden können.
Ein einfaches API dient zum Aktivieren oder Deaktivieren von Interrupts. Wenn dies richtig gemacht wird, können verschachtelte Aufrufe in verschachtelten Unterprogrammen realisiert werden. Diese können dann vorhergegangene Interrupt-Zustände in den äußersten Instanzen zurücksetzen. Dies ist eines der einfachsten Konzepte, um einen Exokernel zu erzeugen.
Normalerweise wird dazu ein Unterprogramm aus der Hauptschleife verwendet, um die Liste der "Software Timers" zu verwalten, welche besagen, wie lange ein Prozess schon gelaufen ist. Dazu wird ein periodischer Echtzeit-Systemaufruf (engl. Real Time Interrupt) verwendet. Wenn also einer dieser Timer abgelaufen ist, wird ein zugehöriges Unterprogramm aufgerufen, welches dann ein "Flag" setzt. Dies ermöglicht dann dem nächsten Unterprogramm, ausgeführt zu werden.
Die Benutzeroberflächen von Embedded-Systemen variieren stark. Man kann von einem rudimentären 2x20 Zeichen-LCD-Display ausgehen wie auch einer Ausgabe am Computerbildschirm darunter verstehen. Da man aber meist leistungsschwache Hardware verwendet oder diese für wichtige Aufgaben verwenden möchte, bedient man sich hier anderer Konzepte.
Entwickler von solchen Interfaces empfehlen, möglichst früh in der Entwicklungsphase die Nutzungsqualität der Benutzerschnittstelle zu testen. Am besten man nimmt den nächstbesten freien Mitarbeiter (noch besser eine Mitarbeiterin) und setzt ihn vor den PC, auf dem das Programm mit der gewünschten Oberfläche läuft. Wenn nun Fragen auftreten, sollte man sich über die Oberfläche Gedanken machen und am besten etwas ändern bzw. verbessern.
Die Entwicklung der Oberfläche sollte am besten nur von einer Person geleitet oder erstellt werden. Im idealen Fall ist dies sogar jemand, der das Programm später benutzen will. Das Programm muss leicht bedienbar sein, es nutzt wenig, wenn es viel kann, aber der Entwickler selbst der einzige ist, der es nutzen kann.
Siehe auch: ARM-Architektur, MIPS-Architektur
Charakterisierung
Plattformen
Werkzeuge, die Software
Betriebssystem
Debuggen, die Fehlersuche
Geschichte
Design von embedded Systemen
Start-up
Nach einem Reset des Systems blinkt die Kontrollleuchte kurz auf, um ihre Arbeitsfähigkeit zu garantieren, dann bleibt sie so lange aus, bis ein Fehler auftritt. In der Erweiterung dieser Eigenschaft kann die Schaltung auch bestimmte Blinksequenzen senden, welche dann mittels einer Tabelle in der die Fehlercodes stehen bestimmten Fehlern zugeordnet werden können. Verschiedene Typen von embedded Software-Architekturen
control loop
Nonpreemptive multitasking
Preemptive timers
Preemptive tasks
Office-style operating systems
Benutzeroberfläche
Der Vorteil liegt auf der Hand, die Konfiguration wird auf dem Embedded System selbst gemacht, das Interface wird auf ein anderes Gerät ausgelagert wie z.B. dem PC. Dies spart Ressourcen und macht die Konfiguration einfacher. Ein anderer Vorteil ist, dass die Konfiguration von solchen Geräten total betriebssystemunabhängig gemacht werden kann, da man nun nur noch einen Browser zur Verfügung haben muss, wie er auf praktisch jedem System zur Verfügung steht.