Eingebettetes System

Ein eingebettetes System (auch englisch embedded system) ist ein elektronischer Rechner oder auch Computer, der in einen technischen Kontext eingebunden (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 – den Dienst in einer Vielzahl von Anwendungsbereichen und Geräten, beispielsweise in Geräten der Medizintechnik, Waschmaschinen, Flugzeugen, Kraftfahrzeugen, Kühlschränken, Fernsehern, DVD-Playern, Set-Top-Boxen, Routern, Mobiltelefonen oder allgemein in Geräten der Unterhaltungselektronik. Im Fall von komplexen Gesamtsystemen handelt es sich dabei meist um eine Vernetzung einer Vielzahl von ansonsten autonomen, eingebetteten Systemen (z. B. 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 vereinigt eine solche 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 (z. B. LIN-Bus, CAN-Bus, ZigBee für drahtlose Kommunikation oder IP über Ethernet).

Eingebettetes System auf einer Einsteckkarte mit Prozessor, Speicher, Stromversorgung, und externen Schnittstellen

Charakterisierung

Eingebettete Systeme können in Einzelfällen auf ähnlicher Hardware wie Arbeitsplatzcomputer basieren (sogenannte 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 der MCS-51-, Microchip-8Bit-PIC- oder Z80-Serie trotz ihres Alters und bekannter Schwächen immer noch eine sehr beliebte Basis für eingebettete Systeme. Die Wiederverwendung von Programmcode und Toolchains sowie die Scheu vor vollständigen Redesigns „ohne Not“ sind hierbei ebenfalls nicht zu unterschätzende Randfaktoren neben den reinen Materialkosten.

In einem eingebetteten System muss die Software 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, manchmal auch die gesamte Schaltung.

Firmwarekomponenten

Im Wesentlichen besteht die Firmware aus drei Komponenten.

Bootloader: Sorgt für das Laden des Betriebssystems und der Applikationssoftware. Weiter bietet dieser die Möglichkeit Betriebssystem und Applikationssoftware im Flash-Speicher zu aktualisieren. Dies kann entweder über eine serielle Schnittstelle (RS232) und/oder über Ethernet und IP erfolgen. Bekannte Bootloader für eingebettete Systeme sind RedBoot oder U-Boot.
Betriebssystem: Dieser Softwareteil sorgt u. a. für das Multitasking, Speicher und Dateiverwaltung (z. B. JFFS2) sowie für IP-Dienste wie z. B. TFTP, HTTP, SNMP und Telnet
Applikationssoftware: Dieser Teil enthält die anwendungsspezifische Software. Diese wird auch als Anwendungssoftware bezeichnet.

Bei kleinen eingebetteten Systemen können die drei Softwareteile zusammengefasst sein.

Plattformen

Eingebettete Systeme werden mittels vieler verschiedener CPU-Architekturen (8051, ARM, AVR, TI MSP430, MIPS, PowerPC, 68k/Coldfire, Intel x86, 68HC12, C167, Renesas M16C, H8S und diverser anderer 8/16/32-Bit-CPUs) realisiert.

Eine Untergruppe der Architekturen sind die Prozessorfamilien, wie zum Beispiel 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 sind Geschwindigkeit und vor allem Ausstattung mit Speicher und Peripheriebausteinen.

Eine besonders 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. In realen Anwendungen werden heutzutage oft beide Ansätze in einem FPGA als SoC 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 wie Alteras Nios II, Xilinx’ MicroBlaze, der Mico32 von Lattice oder auch IP-Cores eines Mikrocontrollers wie PIC oder 8051.

Betriebssystem

Embedded-PC Simatic Microbox PC 427B von Siemens auf dem das Betriebssystem Windows XP Embedded installiert ist.

Bei „kleinen“ Systemen kommt häufig kein Betriebssystem zum Einsatz.

Wenn ein Betriebssystem eingesetzt wird, arbeitet man in eingebetteten Systemen meistens mit sehr spezialisierten Betriebssystemen (QNX, VxWorks, Nucleus, OSEK, OS-9, RTEMS, ECOS usw.). Auch spezielle eingebettete Versionen von Standardbetriebssystemen wie Linux (siehe Embedded Linux), NetBSD oder Windows (3.x, CE, XP Embedded, Automotive oder Windows Embedded POSReady 2009/POSReady 7) finden inzwischen Anklang. Oftmals verwendet man Konfigurationen mit harten/weichen Echtzeitanforderungen, wie unten näher beschrieben. Hierfür müssen spezielle Echtzeitbetriebssysteme oder Betriebssysteme mit entsprechend angepassten Kernen verwendet werden.

Siehe auch in der Liste Betriebssysteme für eingebettete Systeme.

Entwicklungsumgebung, Programmierung, Werkzeuge

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

Halbleiterhersteller, die am Absatz ihrer Prozessoren und Controller interessiert sind, und
Softwarefirmen, die sich auf solche Programme spezialisiert haben.

Die Software für Embedded Systeme, die sogenannte Firmware, wird in der Regel über einen Crosscompiler erzeugt. Dieser Compiler läuft auf einer anderen Architektur (in der Regel auf einer PC-Architektur) als die des Zielsystems. 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.

Manche Hersteller bieten auch System Design Kits an, die eine Prototypenplatine mit dem entsprechenden Prozessor zusammen mit einem Satz Software Development Kit und Dokumentation zu Hard- und Software enthalten.

In zunehmendem 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.

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 bzw. 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 werden auch eher exotische Sprachen wie Ada in eingebetteten Systemen 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 sogenannte modellbasierte Entwicklung mit MATLAB/Simulink oder ASCET Anwendung. Aus den Modellen wird automatisch C-Code generiert, der wiederum für den entsprechenden Zielprozessor compiliert wird.

Das Testen 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 einen Hardware-Emulator.

Softwareentwicklung

Die Softwareentwicklung für eingebettete Systeme unterscheidet sich grundsätzlich von der für beispielsweise Desktop- oder PC-Systeme. Im Gegensatz zu dieser muss sich der Softwareentwickler für eingebettete Systeme meist selbst mit den Möglichkeiten der Ein-/Ausgabe beschäftigen. Die Funktionen dafür sind sehr hardwareabhängig und in der Regel für jedes System neu zu entwickeln. Siehe dazu auch Embedded Software Engineering.

Debugging, Fehlersuche

Debugging umfasst sowohl Fehlerbeseitigung in der Software als auch des integrierten Systems. Für Software-Testing kann ein In-Circuit-Emulator (ICE) verwendet werden, eine Kombination aus Programm und Hardware, die es erlaubt, die Software im System, das heißt, auf der Zielhardware, zu testen. Dazu muss der eigentliche Controller gegen die ICE-Hardware (ein sogenannter Bondout-Chip) ausgetauscht werden. Das erlaubt es, die Software komfortabel, ohne weitere Eingriffe in 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 schon einen „Schmalspur“-ICE on Board, so dass der Hardware-ICE nicht mehr unbedingt benötigt wird. Dafür sind die Einwirkungsmöglichkeiten 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 beispielsweise ein 68k-Derivat einen bis zu 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 den Faktor 1000 geringer.

Diese ist auch bei den meisten modernen ARM-Architekturen, z. B. Controller mit Cortex-M3 Core, als spezieller Debugging-Core vorhanden: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0337e/DDI0337E_cortex_m3_r1p1_trm.pdf (Chapter 10…13) Das ist ein Teil des Microcontrollers, der für den normalen Programmablauf nicht nötig ist 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 kann der Prozessor an beliebigen Stellen im Programm angehalten und die Werte der Register oder des Speichers 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, wenn man keinen ICE zur Verfügung hat, wird oft mit Simulatoren gearbeitet, welche die interne Struktur und die Peripherie des Mikrocontrollers in Software nachbilden. Hier müssen aber beim Debugging die „externen“ Signale (Tasten, Display usw.) „von Hand“ nachgebildet werden, wobei in der Regel Interrupts benutzt werden müssten, die im Simulator normalerweise nicht realisierbar sind.

Inzwischen gibt es auch bei eingebetteten Systemen Entwicklungen auf Java-Basis. Gründe sind unter anderem 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 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 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 davon in Massenproduktion hergestellt. Die Anwendung war ein Wege-Such-System, das der Rakete nach einmaliger Programmierung ein unabhängiges Manövrieren 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 zugunsten des Gewichtes verzichten konnte.

Entwurf eingebetteter Systeme

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

Folgende Aspekte spielen bei Entwurfsentscheidungen 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 ausreichend RAM und andere Peripherie-Funktionen vorgesehen sind.
Hardwareanforderungen: Je nach Einsatzumgebung des Systems können unterschiedlichste Rahmenbedingungen entstehen. Wenn es um eine Freiluftanlage oder sonstige raue Umweltbedingungen wie Hitze und Staub geht, muss man auf Robustheit der Hardware achten, also vor allem hermetische Kapselung. Wenn es dabei um aufwändigere Systeme geht, sind sogenannte Industrie-PCs oft eine Lösung. Wenn es um ständige mechanische Erschütterungen geht, müssen Steckverbindungen möglichst eingespart oder besonders robust ausgeführt werden. Bauteile mit beweglichen Komponenten wie Festplattenlaufwerke oder Lüfter versucht man dabei möglichst auch zu vermeiden.
Stromverbrauch: In vielen Fällen werden eingebettete Systeme mit Batterien betrieben. Diese werden, wie z. B. bei Wasserzählern, nur im Eichintervall (5 Jahre + Laufzeitreserve) getauscht. Die hohen Laufzeiten werden durch spezielle Chiptechnologien (z. B. CMOS) und Maßnahmen in der Software, wie z. B. Schlafmodus, erreicht.
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.
Betriebssicherheit: Viele eingebettete Systeme laufen im Gegensatz zu PCs im Dauerbetrieb. Fehler und Störungen, wie z. B. bei Probleme mit der elektromagnetische Verträglichkeit (EMV), erfordern spezielle Maßnahmen im eingebetteten System um einen zuverlässigen Wiederanlauf zu gewährleisten. Daher sind Mikrocontroller mit einem Watchdog ausgerüstet. Dieser bewirkt bei Unregelmäßigkeiten im Ablauf einen kontrollierten Wiederanlauf und stellt damit die Verfügbarkeit des eingebetteten Systems, ohne Eingriff des Benutzers, sicher.
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 beispielsweise 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 System Design Kit.

Systemstart

Alle eingebetteten Systeme haben einen Start-up Code, der 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 tritt jedoch durch möglicherweise veränderte Bits im RAM manchmal undefiniertes Systemverhalten auf, das eine Schaltung zur Spannungsüberwachung (Supply Voltage Supervisor, SVS oder auch Brownout Detection genannt) vermeidet. Der SVS löst einen „richtigen“ Reset aus, so dass 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 dazu, dass das Einschalten länger dauert als bei analogen Geräten, beispielsweise bei Autoradios.

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, Window-basierten Benutzerinterface eines Fahrkartenautomaten mit Touchscreen:

Regelschleife

Regelschleifen werden für Regelungssysteme eingesetzt, die zyklisch Berechnungen aufgrund von Eingangssignalen vornehmen und Ausgangssignale senden (siehe Regelungstechnik). Wird auch als Zeit-gesteuertes Design bezeichnet (siehe Embedded Software Engineering).

Reaktive Systeme

Reaktive Systeme verarbeiten aperiodisch auftretende Ereignisse, wie beispielsweise einen Tastendruck und veranlassen entsprechende Aktionen. Wird auch als Ereignis-gesteuertes Design bezeichnet (siehe Embedded Software Engineering).

Benutzeroberfläche

Eingebettete Systeme besitzen häufig keinen eigenen Anschluss für ein Display oder Eingabegeräte. Jedoch kann eine mittelbare Benutzerkommunikation über Datenschnittstellen vorgesehen werden. So haben etwa netzwerkfähige Drucker und andere Geräte ein Webinterface oder eine serielle Schnittstelle, über die man per Browser oder Terminalemulation alle wichtigen Konfigurationseinstellungen vornehmen kann.

Probleme beim Einsatz eingebetteter Systeme

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 Verkabelungsaufwand. 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 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- und auch der Kostenminimierung und daher das Prinzip „nur so viel wie nötig“.

Siehe auch

Architekturen

Begriffe und Konzepte

Literatur

Jürgen Teich, Christian Haubelt: Digitale Hardware/Software-Systeme – Synthese und Optimierung. Springer, Berlin/Heidelberg 2007, ISBN 978-3-540-46822-6.
Joachim Wietzke: Embedded Technologies: Vom Treiber bis zur Grafik-Anbindung. Springer, Berlin/Heidelberg 2012, ISBN 978-3-642-23995-3
Jörg Wiegelmann: Softwareentwicklung in C für Mikroprozessoren und Mikrocontroller: C-Programmierung für Embedded-Systeme VDE Verlag 2011, ISBN 978-3800732616

Weblinks

Commons: Eingebettete Systeme – Sammlung von Bildern, Videos und Audiodateien

Literatur zum Thema Eingebettetes System im Katalog der Deutschen Nationalbibliothek

Dieser Artikel basiert ursprünglich auf dem Artikel Eingebettetes System aus der freien Enzyklopädie Wikipedia und steht unter der Doppellizenz GNU-Lizenz für freie Dokumentation und Creative Commons CC-BY-SA 3.0 Unported. In der Wikipedia ist eine Liste der ursprünglichen Wikipedia-Autoren verfügbar.