Eineingebettetes System (auchenglisch„embedded system“) ist einComputer, der in einen technischen Kontexteingebunden (eingebettet) ist. Dabei übernimmt der Rechner entweder Überwachungs-, Steuerungs- oder Regelfunktionen oder ist für eine Form der Daten- bzw. Signalverarbeitung zuständig, beispielsweise beim Ver- bzw. Entschlüsseln, Codieren bzw. Decodieren oder Filtern.
Eingebettete Systeme verrichten – weitestgehend unsichtbar für den Benutzer – ihren Dienst in einer Vielzahl von Anwendungsbereichen und Geräten, beispielsweise in Geräten derMedizintechnik,Waschmaschinen,Flugzeugen,Kraftfahrzeugen,Kühlschränken,Fernsehgeräten,DVD-Spielern,Set-Top-Boxen,Routern,Mobiltelefonen oder allgemein in Geräten derUnterhaltungselektronik. Im Fall von komplexen Gesamtsystemen handelt es sich dabei meist um eine Vernetzung einer Vielzahl von ansonsten autonomen eingebetteten Systemen (so im Fahrzeug oder Flugzeug).
Oft werden eingebettete Systeme speziell an eine Aufgabe angepasst. Aus Kostengründen wird eine optimierte gemischte Hardware-Software-Implementierung gewählt. Dabei vereint eine solche Konstruktion die große Flexibilität vonSoftware mit der Leistungsfähigkeit derHardware. Die Software dient dabei sowohl zur Steuerung des Systems selbst als auch zur Interaktion des Systems mit der Außenwelt über definierte Schnittstellen oder Protokolle (zum BeispielLIN-Bus,CAN-Bus,ZigBee für drahtlose Kommunikation oderIP überEthernet).
Eingebettete Systeme können in Einzelfällen auf ähnlicher Hardware wie Arbeitsplatzcomputer basieren (Embedded-PCs). Typischerweise unterliegen sie jedoch stark einschränkenden Randbedingungen: minimale Kosten, geringer Platz-, Energie- und Speicherverbrauch. Einzelne Komponenten wie Prozessor und Arbeitsspeicher basieren oft auf Weiterentwicklungen älterer Komponenten, was die langfristige Einsetzbarkeit und Ersatzteilbeschaffung erleichtert. „Moderne“ eingebettete Systeme basieren häufig auf Prozessorplattformen, die mit der PC-Welt wenig gemeinsam haben, aber in Bezug auf die Peripheriemodule hochintegriert sind und durch moderne Stromspartechniken deutlich weniger Energie verbrauchen.
Bei vielen Anwendungen kann die Verwendung einer älteren Prozessorarchitektur dazu beitragen, Kosten zu senken. So sind die Architekturen derMCS-51-,Microchip-8Bit-PIC- oderZ80-Serie trotz ihres Alters und bekannter Schwächen immer noch eine sehr beliebte Basis für eingebettete Systeme. Die Wiederverwendung von Programmcodes und Toolchains sowie die Scheu vor vollständigen Redesigns „ohne Not“ sind hierbei neben den reinen Materialkosten ebenfalls nicht zu unterschätzende Randfaktoren.
In einem eingebetteten System muss die Software oftEchtzeitanforderungen genügen. In der Regel existieren, verglichen mit PC-Hardware, nur stark reduzierte Ressourcen, zumeist ohne Festplatte, häufig ohne Betriebssystem, Tastatur oder Bildschirm. Ein ROM- oder Flash-Chip ersetzt mechanische Speicherkomponenten wie eine Festplatte, stromsparende Prozessoren kommen ohne Lüfter aus, denn bewegliche Teile bedeuten Verschleiß und Fehleranfälligkeit. Wenn überhaupt, dann gibt es meistens nur ein Tastenfeld, und die Ausgabe wird – soweit vorgesehen – durch einLCD realisiert.
Die Software auf einem solchen Gerät wirdFirmware genannt. Sie befindet sich gewöhnlich auf einemROM, immer häufiger jedoch aufFlash-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, manchmal auch die gesamte Schaltung.
Im Wesentlichen besteht die Firmware aus drei Komponenten.
Bei kleinen eingebetteten Systemen können die drei Softwareteile zusammengefasst sein.
Eingebettete Systeme werden mittels vieler verschiedenerCPU-Architekturen (8051,Arm,AVR,TI MSP430,MIPS,PowerPC,68000/Coldfire, Intelx86, 68HC12,C167, RenesasM16C,H8S und diverser anderer 8/16/32-Bit-CPUs) realisiert.
Eine Untergruppe der Architekturen sind die Prozessorfamilien (beispielsweise 8051, AVR, PIC16, ARM7, PowerPC 5xx, MIPS 4k, AMD AU1000, Intel Pentium M), bei denen verschiedene Varianten mit denselben Entwicklungswerkzeugen und Debugtools betrieben werden können. Unterschiede innerhalb einer Prozessorfamilie bestehen bei der Geschwindigkeit und vor allem der Ausstattung mit Speicher und Peripheriebausteinen.
Eine besonders flexible Plattform sind hochintegrierteFPGA-Bausteine, mit denen zum einen unterschiedliche CPU-Architekturen nachgebildet werden können (beispielsweise 68000 und PowerPC 405 auf einem Chip) und zum anderen auch gut parallele Rechenleistung ohne Prozessor – nur mittels dedizierter Logik – zur Verfügung gestellt werden kann. In realen Anwendungen werden oft beide Ansätze in einem FPGA alsSystem-on-a-Chip integriert. Zum Einsatz kommen hierbei als Prozessor sowohl fest verdrahtete Hardmakros wie die PowerPC-Kerne in verschiedenen Xilinx-Virtex-FPGAs als auch flexibel konfigurierbare Softcore-Prozessoren wieAlteras Nios II, XilinxMicroBlaze, derMico32 von Lattice oder auch IP-Cores eines Mikrocontrollers wie PIC oder 8051.
Bei „kleinen“ Systemen kommt häufig kein Betriebssystem zum Einsatz.
Wenn in eingebetteten Systemen ein Betriebssystem eingesetzt wird, handelt es sich meistens um darauf spezialisierte Betriebssysteme (Beispiele:QNX,VxWorks,Nucleus,OSEK,OS-9,RTEMS,ECos). Auch spezielle sogenannteeingebettete Versionen von Standardbetriebssystemen wieLinux (sieheEmbedded Linux),NetBSD oderMicrosoft Windows (3.x,CE,XP Embedded,Automotive oderWindows Embedded POSReady 2009/POSReady 7) kommen inzwischen zum Einsatz.
Oftmals haben Anwendungen weiche oder gar harteEchtzeitanforderungen, wie unten näher beschrieben ist. Hierfür müssen spezielle Echtzeitbetriebssysteme oder Betriebssysteme mit entsprechend angepassten Kernen verwendet werden.[1]
Die Software zur Programmentwicklung, alsoCompiler,Assembler undDebugger (wobei beim Debugging regelmäßig auch Hardware eingesetzt werden muss), wird in der Regel von verschiedenen Herstellern angeboten:
Die Software für Embedded Systeme, die Firmware, wird in der Regel über einenCross-Compiler erzeugt. Dieser Compiler läuft auf dem Entwicklungssystem (PC-Architektur), also normalerweise einer anderen Architektur als der des Zielsystems. Viele Cross-Compiler sind nicht auf einen bestimmten Prozessor begrenzt, sondern können Maschinencode für eine ganze Prozessorfamilie erzeugen, wie ARM7, PowerPC 8xx.
Manche Hersteller bieten auchSystem Design Kits an, die einePrototypenplatine mit dem entsprechenden Prozessor zusammen mit einem SatzSoftware Development Kit undDokumentation zu Hard- und Software enthalten.
In zunehmendem Maße erfolgt die Softwareentwicklung für eingebettete Systeme mit Hilfe modellbasierter Entwicklung, bei der graphische Modelle des Verhaltens spezifiziert werden, welche dann mittelsCodegenerierung in C-Code überführt werden.
BevorzugteProgrammiersprache ist im AllgemeinenC oderC++, aber auch fürJava gibt es Ansätze wieOSGi.Assemblersprache wird dann eingesetzt, wenn zeitkritische oder Gerätetreiber-Funktionen vor allem inInterrupts programmiert werden oder wenn das Betriebssystem selbst an eine neue Umgebung bzw. CPU angepasst werden muss. Oberhalb des Betriebssystems ist Assembler eher eine Randerscheinung, in Systemen ohne Betriebssystem und vor allem bei massiven Speicherrestriktionen kommt Assembler jedoch häufiger zur Anwendung. In sicherheitskritischen Anwendungen wie bei Flugsteuerungsrechnern werden in eingebetteten Systemen auch eher exotische Sprachen wieAda eingesetzt – man muss hier allerdings differenzieren zwischen den zeitkritischen und den sicherheitskritischen Anwendungsebenen, für die ggf. innerhalb des Systems unterschiedliche Anwendungen und Programmiersprachen verantwortlich sein können. Nicht nur in der Automobilindustrie findet häufig die sogenanntemodellbasierte Entwicklung mitMatlab/Simulink oderASCET Anwendung. Aus den Modellen wird automatisch C-Code generiert, der wiederum für den entsprechenden Zielprozessor kompiliert wird.
DasTesten von Software für eingebettete Systeme findet oft in frühen Entwicklungsphasen auf dem PC statt. Dafür muss häufig die Umgebung der Anwendung, mit der das eingebettete System kommuniziert,simuliert werden. Diese Simulation heißt dann MiL (Model in the Loop) oder SiL (Software in the Loop). Wenn die Software auf der Zielhardware implementiert ist, spricht man dagegen von HiL (Hardware in the Loop); der Zugriff auf die Testhardware vom PC aus erfolgt dabei in der Regel über einenHardware-Emulator.
DieSoftwareentwicklung für eingebettete Systeme unterscheidet sich grundsätzlich von der für Desktop- oder PC-Systeme, da hierbei der Fokus auf den Möglichkeiten derEin-/Ausgabe liegt. Die Funktionen dafür sind hardwareabhängig und für jedes System neu zu entwickeln.
Debugging umfasst Fehlerbeseitigung sowohl in der Software als auch im integrierten System. Für Software-Testing kann einIn-Circuit-Emulator (ICE) verwendet werden, eine Kombination aus Programm und Hardware, die es erlaubt, die Softwareim System, also auf der Zielhardware zu testen. Traditionellerweise muss dazu der eigentliche Controller gegen die ICE-Hardware (einBond-out-Prozessor) ausgetauscht werden. Das erlaubt es, die Software komfortabel und ohne weitere Eingriffe in der Zielhardware zu entwickeln. Da mit dem ICE Zugriffe auf die Peripherie der CPU möglich sind, lassen sich Software- von Hardwarefehlern unterscheiden und trennen. Früher wurde dazu einLogikanalysator benötigt, der als Zusatzoption die Ziel-CPU emulieren konnte.
Heutzutage haben eingebettete CPUs schon einen „Schmalspur“-ICE an Bord, so dass der Hardware-ICE nicht unbedingt benötigt wird. Demgegenüber sind die Einwirkungsmöglichkeiten der Debugging-Software auf die Ziel-CPU eingeschränkt. Eine komplette Überwachung der CPU ist nicht möglich, dafür sind jedoch die Kosten erheblich geringer. Kostet ein voll ausgebautes ICE-System für ein 68000-Derivat einen bis zu sechsstelligen Eurobetrag, liegen die Kosten für solch ein „Schmalspur“-System im unteren 3-stelligen Eurobereich. Meist kommt eine Schnittstelle vom TypJTAG zum Einsatz. Eine Alternative für Coldfire- und 68000-Derivate ist die SchnittstelleBackground Debug Module (BDM) von Motorola.
Auch bei modernen ARM-Architekturen, Controller mit Cortex-M3 Core, ist sie als spezieller Debugging-Core vorhanden.[2] Das ist ein Teil des Microcontrollers, der für den normalen Programmablauf nicht nötig und nur für das Debugging eingebaut ist. Dieser Debugging-Core kann mit einer Debugging-Software über einen JTAG- oder SWD-Adapter angesprochen werden. Damit lässt sich der Prozessor an beliebigen Stellen im Programm anhalten, und die Werte der Register oder des Speichers können angesehen oder verändert werden. Auch ein schrittweises Abarbeiten des Codes zur Fehlersuche ist möglich. Als Hardware ist hier ein JTAG- oder SWD-Adapter nötig, der oft unter 100 € zu bekommen ist. Die Debuggersoftware kann von voll funktionsfähiger Freeware (gdb + ddd,gdb + kgdb,Eclipse) bis zu professioneller Software im Tausend-Euro-Bereich reichen.
Alternativ wird oft mit Simulatoren gearbeitet, welche die interne Struktur und die Peripherie des Mikrocontrollers in Software nachbilden. Beim Debugging sind die „externen“ Signale (Tasten, Display) „von Hand“ nachzubilden, wobei Interrupts benutzt werden müssten, die im Simulator nicht realisierbar sind.
Es gibt auch bei eingebetteten Systemen Entwicklungen aufJava-Basis, begründet im einfacheren Plattformwechsel und der Plattformunabhängigkeit mit Wegfall von Simulatoren (sieheOSGi undEmbedded Java).
DerMicrocode-Interrupt lässt den Debugger auf der Hardware arbeiten statt nur auf der CPU. Vom Standpunkt der CPU aus können CPU-basierte Debugger dann benutzt werden, um die Elektronik des Computers zu testen und gegebenenfalls Fehler zu diagnostizieren. Diese Fähigkeit wurde an derPDP-11 (sieheProgrammed Data Processor) erforscht und entwickelt.
Der Systemtest wird mittels derHardware-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.
Zwischen dem eingebetteten System und derSystemumgebung, welche das eingebettete System aufnimmt, befinden sich in der Regel verschiedeneSchnittstellen. Diese Schnittstellen können je nach Anwendungszweck des eingebetteten Systems in der Praxis sehr unterschiedlich ausgeführt sein. Eine spezielle Schnittstelle ist dabei dieBenutzerschnittstelle (User Interface). Des Weiteren liegen zwischen System und Systemumgebung ein oder mehrereProgrammierschnittstellen.
Viele Anwendungen werden erst dadurch sinnvoll und nutzbar, dass die dafür erforderlicheSignalverarbeitung inEchtzeit erfolgt. Geräte, Systeme und Verfahren, die mit dem Attribut „Echtzeit“ versehen werden, sollten nach objektiven Maßstäben Kriterien wie „Rechtzeitigkeit“, „Vorhersagbarkeit“, „Sicherheit“ und „Zuverlässigkeit“ erfüllen.[3] Dies setzt eineEchtzeitplanung vonProzessen voraus. Überdies muss diemaximale Laufzeit zur Erfüllung einer Aufgabe aus der Systemumgebung bestimmbar, also einem deterministischen Prozessablauf zugehörig sein. DieReaktionszeit des Systems zur Erfüllung der Aufgabe muss dem Kriterium der „Rechtzeitigkeit“ genügen.
Zur Realisierung der Echtzeitverarbeitung finden unter Berücksichtigung der Benutzerschnittstelle(n) und der Programmierschnittstellen verschiedene Softwarekonzepte Anwendung.
Die nachfolgend aufgeführte sogenannte „Regelschleife“, die auf den Entwurf eines Reglers hinausläuft, ist allenfalls für äußerst einfacheregelnde Embedded-Systeme in der Industrie geeignet. Sie muss noch nicht mal mit Echtzeit unterlegt sein. Davon zu unterscheiden ist der sogenannte „reaktive Ansatz“, der auf den Entwurf eines sogenannten „reaktiven Systems“ hinausläuft, das sich in ständiger Interaktion mit der Umgebung befindet, wobei die Umgebung dominiert und das reaktive System sich dieser unterordnet.
Regelschleifen werden für Regelungssysteme eingesetzt, die zyklisch Berechnungen aufgrund von Eingangssignalen vornehmen undAusgangssignale senden (sieheRegelungstechnik). Dies wird auch als „zeitgesteuertes Design“ bezeichnet (sieheEmbedded Software Engineering).
Der reaktive Ansatz führt zum Entwurf eines Prozessablaufs, in welchem aperiodisch auftretende Ereignisse, wie etwa ein Tastendruck oder eine Folge von Tastendrücken, verarbeitet und daraus resultierende Aktionen veranlasst werden. Derartiges wird als „ereignisgesteuertes Design“ bezeichnet (sieheEmbedded Software Engineering).
Alle eingebetteten Systeme haben einenStart-up Code, der nach dem Einschalten durchlaufen wird. Normalerweise deaktiviert dieser dieInterrupts, kalibriert die interneElektronik, testet denComputer (RAM,ROM,CPU) und startet den eigentlichenProgrammcode, nachdem alles erfolgreich getestet wurde.
Viele dieser Systeme sind innerhalb von 100 ms einsatzbereit. Selbst nach einem kleinen Stromausfall oder einer Spannungsschwankung laufen diese Geräte sofort weiter, da die interne Hardware denSelbsttest der Hardware und Software überspringt. Es tritt jedoch durch möglicherweise veränderte Bits im RAM undefiniertes Systemverhalten auf, das eine Schaltung zur Spannungsüberwachung (Supply Voltage Supervisor, SVS oder auchBrownout Detection genannt) vermeidet. Der SVS löst einen „richtigen“Reset aus, so dass das System komplett initialisiert wird und auch die Selbsttests durchläuft.
Die Dauer des Systemstarts ist bei der Kfz-Elektronik an den Kontrollleuchten erkennbar, die nach Einschalten der Zündung aufleuchten und nach kurzer Zeit wieder erlöschen. Der Systemstart führt bei vielen Geräten dazu, dass das Einschalten länger dauert als bei analogen Geräten, beispielsweise beiAutoradios.
Eingebettete Systeme besitzen häufig keinen eigenen Anschluss für einDisplay oder Eingabegeräte. Jedoch kann eine mittelbare Benutzerkommunikation über Datenschnittstellen vorgesehen werden. So haben netzwerkfähige Drucker und andere Geräte ein Webinterface oder eine serielle Schnittstelle, über die per Browser oder Terminalemulation alle wichtigen Konfigurationseinstellungen erfolgen.
Die Elektronik bildet einMikroprozessor mit entsprechender Peripherie oder einMikrocontroller. Einige eher veraltete Systeme verwenden noch Allzweck-Mainframes oderMinirechner.
Folgende Aspekte spielen bei Entwurfsentscheidungen von eingebetteten Systemen eine Rolle:
Mit dem verstärkten Einsatz von eingebetteten Systemen in Automobilen macht sich ein weiteres Problem bemerkbar: Die Anzahl der Systeme ist so hoch, dass der verfügbare Platz in einem Auto nicht ausreicht und der Verkabelungsaufwand steigt. Deshalb werden mehrere Steuerfunktionen in einemSteuergerät vereint, ermöglicht durch leistungsfähige 32-Bit-Mikrocontroller. Speicherschutzmechanismen wieMPU oderMMU, die dafür sorgen, dass sich die einzelnen Funktionen nicht gegenseitig beeinflussen können, sind jedoch im Allgemeinen weiterhin eher unüblich. Auch sollte die Verbreitung von 8/16-Bit-Controllersystemen nicht unterschätzt werden. In diesem Marktsegment gilt die Maxime der Stromverbrauchs- sowie der Kostenminimierung und daher das Prinzip „nur so viel wie nötig“.
Der erste prominente Einsatz eines eingebetteten Systems war der desApollo-Guidance-Computers, der vonCharles Stark Draper zusammen mit demMIT Instrumentation Laboratory entwickelt wurde. Jeder Flug auf den Mond hatte zwei dieser Systeme dabei, die zur Steuerung verwendet wurden. DasInertial Guidance System wurde sowohl im Kommandomodul als auch in derMondlandefähre (LEM, Lunar Excursion Module) verwendet.
Zu Beginn des Apollo-Projekts wurde dieses System als eine der riskantesten Komponenten des Projektes angesehen.
Die ersten eingebetteten Systeme wurden aber schon vorher in derMinuteman-Rakete eingesetzt und in Serie produziert. Die Anwendung war ein Wege-Such-System, das der Rakete nach einmaliger Programmierung ein unabhängiges Manövrieren ermöglichte. Durch den Preisverfall öffneten sich die verwendetenintegrierten Schaltungen allmählich einem größeren Kreis von Anwendungen.
Die entscheidende Eigenschaft des Minuteman-Computers war, dass der Weg-Finde-Algorithmus später programmiert werden konnte, wodurch sich die Rakete wesentlich präziser einsetzen ließ. Ein weiterer Vorteil bestand in der Selbsttestfunktion der Rakete zur Statusabfrage sowie darin, dass man zugunsten des Gewichtes auf größere Mengen von Kabeln verzichten konnte.
