Eingebettetes System
aus Wikipedia, der freien Enzyklopädie
Der Begriff Eingebettetes System (engl. embedded system, franz. système embarqué) bezeichnet ein Rechnersystem, das – weitestgehend unsichtbar – den Dienst in einer Vielzahl von Anwendungsbereichen und Geräten versieht, wie z. B. in Waschmaschinen, Flugzeugen, Autos, Kühlschränken, Fernsehern, DVD-Playern, SetTopBoxen, Handys oder allgemein Geräten der Unterhaltungselektronik (Consumer Electronics). Im Fall von komplexen Gesamtsystemen handelt es sich dabei meist um eine Vernetzung einer Vielzahl von, ansonsten autonomen, eingebetteten Systemen (zum Beispiel im Fahrzeug oder Flugzeug).
Eingebettete Systeme vereinigen daher durch ihre oftmals sehr hardwarenahe Konstruktion die große Flexibilität von Software mit der Leistungsfähigkeit der Hardware. Die Software dient dabei sowohl zur Steuerung des Systems selbst, als auch ggf. zur Interaktion des Systems mit der Außenwelt über definierte Schnittstellen oder Protokolle (zum Beispiel LIN-Bus, CAN-Bus oder TCP/IP über Ethernet).
Die Softwareentwicklung 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 auch eher selten mit der Hardware möglich ist), dafür jedoch Echtzeitanforderungen genügen. Bei „kleinen“ Systemen kommt häufig auch überhaupt kein Betriebssystem zum Einsatz. Im Gegensatz zu Softwareentwicklern für PC-Systeme muss sich der Softwareentwickler für eingebettete Systeme meistens 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.
Mit dem verstärkten Einsatz von eingebetteten Systemen in Automobilen tritt derzeit ein weiteres Problem zu Tage. Die Anzahl der Systeme ist inzwischen so hoch, dass der verfügbare Platz in einem Auto für weitere Steuerungen nicht ausreicht. Zudem steigt der Verdrahtungsaufwand. Deshalb geht man in neuen Steuerungen dazu über, mehrere Steuerfunktionen in einem Steuergerät zu vereinen. Dies wird möglich durch neue, leistungsfähige 32-Bit-Mikrocontroller. Speicherschutzmechanismen wie MPU oder MMU, die dafür sorgen, dass sich die einzelnen Funktionen nicht gegenseitig beeinflussen können, sind jedoch im Allgemeinem weiterhin eher unüblich – auch sollte die Verbreitung von 8/16-Bit-Controllersystemem nicht unterschätzt werden. In diesem Marktsegment gilt die Maxime der Stromverbrauchs- und auch der Kostenminimierung und daher das Prinzip „nur soviel wie nötig“.
Übliche eingebettete Betriebssysteme sind z. B. VxWorks, OSEK, zunehmend auch spezielle Linux-Derivate oder NetBSD. Auch Microsoft bietet verschiedene Windows-Varianten für eingebettete Systeme an. Bevorzugte Programmiersprache ist im Allgemeinen C oder C++, aber auch für Java gibt es Ansätze wie etwa OSGi. Assemblersprache wird dann eingesetzt, wenn zeitkritische oder Gerätetreiber Funktionen vor allem in Interrupts programmiert werden, oder wenn das Betriebssystem selbst an eine neue Umgebung/CPU angepasst werden muss. Oberhalb des Betriebssystems ist Assembler eher eine Randerscheinung, in Systemen ohne Betriebssystem und vor allem bei massiven Speicherrestriktionen kommt jedoch Assembler häufiger zur Anwendung. In sicherheitskritischen Anwendungen wie zum Beispiel bei Flugsteuerungsrechnern kommen auch eher exotischere Sprachen wie Ada in eingebetteteten Systemen zum Einsatz – 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.
Inhaltsverzeichnis |
[Bearbeiten] Charakterisierung
Eingebettete Systeme können in Einzelfällen auf ähnlicher Hardware wie Arbeitsplatzcomputer basieren (sogenannte embedded-PC, ohne Lüfter), sie unterliegen typischerweise stark einschränkenden Randbedingungen: Minimale Kosten, geringer Platz-, Energie-, Speicherverbrauch. Die Fertigung von Millionenstückzahlen ist die Motivation zur ungehemmten Kostenreduktion, inklusive Outsourcing der Entwicklung/Fertigung in v. A. asiatischen Länder. Einzelne Komponenten wie Prozessor und RAM basieren oft auf Weiterentwicklungen älterer Komponenten, was die langfristige Einsetzbarkeit und Ersatzteilbeschaffung steigert. „Moderne“ Embedded Systeme basieren häufig auf Prozessor-Plattformen, die mit der PC-Welt wenig gemeinsam haben, aber im Bezug auf die Peripheriemodule hochintegriert sind und durch moderne Stromspartechniken entschieden weniger Energie verbrauchen.
Für viele Anwendungen kann die Verwendung einer älteren Prozessor-Architektur dazu beitragen, Kosten zu senken. So sind die Architekturen 8051 oder PIC von 1980 trotz ihrer bekannten Schwächen immer noch eine sehr beliebte Basis für Eingebettete Systeme. Die Wiederverwendung von existierendem Programmcode und Toolchains sowie die Scheu vor vollständigen Re-Designs „ohne Not“ sind hierbei ebenfalls nicht zu unterschätzende Randfaktoren – neben den reinen Materialkosten.
Programme eines Eingebetteten Systems müssen oft Echtzeitanforderungen 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 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.
[Bearbeiten] Plattformen
Eingebettete Systeme werden mittels vieler verschiedenen CPU-Architekturen ( ARM, MIPS, PowerPC, 68k/Coldfire, Intel x86, 68HC12, C167, diverse 8/16 Bit-CPUs, …) realisiert.
Eine Untergruppe der Architekturen sind die Prozessorfamilien, wie zum Beispiel ARM7, PowerPC 5xx, MIPS 4k, Intel 486, bei denen verschiedene Varianten mit den selben Entwicklungswerkzeugen und Debugtools betrieben werden können. Unterschiede innerhalb einer Prozessorfamilie sind Geschwindigkeit und vor allem Ausstattung mit Speicher und Peripheriebausteinen.
Eine flexible Plattform sind hochintegrierte FPGA Bausteine, die zum einen unterschiedliche CPU Architekturen nachbilden (68k und PowerPC 405 auf einem Chip, zum Beispiel), zum anderen auch gut parallele Rechenleistung ohne Prozessor - nur durch Logik - ausführen können.
[Bearbeiten] Betriebssystem
Wenn ein Betriebssystem eingesetzt wird, arbeitet man in Eingebetteten Systemen meistens 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 Eingebettete Versionen von Standardbetriebssystemen wie Linux (Embedded Linux), NetBSD oder Windows (CE, XP Embedded, Automotive oder Embedded for PoS) inzwischen großen Anklang.
[Bearbeiten] Entwicklungsumgebung, Werkzeuge
Die Software zur weiteren Programmentwicklung, also Compiler, Assembler und Debugger (wobei beim Debugging regelmäßig auch Hardware eingesetzt werden muss), werden meistens von verschiedensten Herstellern angeboten:
- Halbleiterherstellern, die am Absatz ihrer Prozessoren und Controller interessiert sind.
- Softwarefirmen, die sich auf solche Programme spezialisiert haben.
Die Software für embedded Systeme, sogenannte Firmware wird in der Regel über einen Crosscompiler erzeugt. Dieser Compiler läuft auf einer anderen Architektur (in der Regel ein PC) als das Zielsystem. Diese CrossCompiler sind normalerweise nicht auf einen bestimmten Prozessor begrenzt, sondern können Maschinencode für eine ganze Prozessorfamilie erzeugen, wie zum Beispiel ARM7, PowerPC 8xx.
In zunehmenden Maße wird die Software für eingebettete Systeme mit Hilfe modellbasierter Entwicklung vorgenommen, bei der graphische Modelle des Verhaltens spezifiziert werden, welche dann mittels Codegenerierung in C-Code überführt werden.
[Bearbeiten] Debugging, Fehlersuche
Debugging umfasst sowohl Fehlersuche in der Software als auch des integrierten Systems. Für Software-Debugging kann ein so genannter „In-Circuit-Emulator“ (ICE) verwendet werden, einer Kombination aus Programm und Hardware, die 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 so genannter „Bondout-Chip“) ausgetauscht werden. Dieses 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 Eingebettete CPUs haben in der Regel einen „Schmalspur“-ICE schon on Board, so dass 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 Coldfire- und 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 Bereich Eingebetteter Systeme 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 der 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 so genannten 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.
[Bearbeiten] Geschichte
Das erste bemerkenswerte moderne Eingebettete System war der Apollo Guidance Computer, das von Charles Stark Draper zusammen mit dem MIT Instrumentation Laboratory entwickelt wurde. Jeder Flug auf den Mond hatte zwei dieser Systeme dabei, die zur Steuerung verwendet wurden. 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 eine der riskantesten Komponenten des Projektes angesehen.
Die ersten Eingebetteten Systeme wurden allerdings schon vorher in der Minuteman-Rakete eingesetzt und als Folge dessen in Massenproduktion hergestellt. Die Anwendung war ein Wege-Such-System, das 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.
[Bearbeiten] Design eingebetteter Systeme
Die Elektronik bildet meistens ein Mikroprozessor mit entsprechender Peripherie oder ein Microcontroller. Einige größere, meistens veraltete, Systeme verwenden Allzweck-Mainframes oder Minicomputer.
Folgende Aspekte spielen bei Designentscheidungen von Eingebetteten Systemen 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 meistens schon bereits ausreichend RAM und anderer Peripherie-Funktionen vorgesehen sind.
- Echtzeitanforderungen
- Hohe Verfügbarkeit und definierte Antwortzeiten sind häufig gestellte Anforderungen an ein Eingebettetes 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 bei 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
[Bearbeiten] Systemstart
Alle Eingebetteten System haben einen Start-up Code, das nach dem Einschalten durchlaufen wird. Normalerweise deaktiviert dieser die Interrupts, kalibriert die interne Elektronik, testet den Computer (RAM, ROM, CPU) und startet den eigentlichen 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 oder auch Brownout Detection genannt) vermeidet. Der SVS löst einen „richtigen“ Reset aus, so daß das System komplett initialisiert wird und eben auch die Selbsttests durchläuft.
Die Dauer des Systemstarts ist beispielsweise 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 leider dazu, dass das Einschalten länger dauert als bei analogen Geräten, beispielsweise bei Autoradios.
[Bearbeiten] Verschiedene Architekturtypen
Es finden verschiedene Softwarekonzepte Anwendung. Insbesondere das erste Konzept ist jedoch allenfalls für sehr einfache Embedded-Systeme geeignet. Der reaktive Ansatz wiederum fasst eigentlich alles andere zusammen, bis zum hochkomplexen, Windows-basierten Benutzerinterface eines Fahrkartenautomaten mit Touchscreen:
[Bearbeiten] Regelschleife
Regelschleifen werden für Regelungssysteme eingesetzt, die zyklisch Berechnungen aufgrund von Eingangssignalen vornehmen und Ausgangssignale senden. Siehe Regelungstechnik.
[Bearbeiten] Reaktive Systeme
Reaktive Systeme verarbeiten aperiodisch auftretende Ereignisse, wie beispielsweise einen Tastendruck und veranlassen entsprechende Aktionen.
[Bearbeiten] 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 meistens über ein Webinterface verfügen, über das man per Browser alle wichtigen Konfigurationseinstellungen vornehmen kann. Dies ist für die Anwendungen nützlich, bei denen Systeme über kein eigenes Display bzw. Bedieninterface verfügen, über welches das System mit dem Benutzer kommunizieren kann.
[Bearbeiten] Siehe auch
- ARM-Architektur
- MIPS-Architektur
- 68000-Architektur
- Coldfire-Prozessor
- PowerPC-Architektur
- Intel 8051
- TI MSP430
- Atmel AVR
- PICmicro
- MOS Technologies 6502
- Sensornetz
- Eingebettetes Datenbanksystem
[Bearbeiten] Weblinks
- t2-project.org T2 SDE ist eine GPL Embedded System Entwicklungsumgebung
- embeddedexpert.com ist eine generelle Seite über Embedded System in deutscher Sprache
