embedded systems

Ein eingebettetes System („embedded system“) zeichnet sich dadurch aus, dass ein Mini-Computer mit zugehöriger Software in einem technischen Gesamtsystem eingebettet ist. Der Mini-Computer überwacht dabei einlangende Signale (z. B. Sensordaten) und reagiert auf diese. Diese Reaktion kann das Weitermelden eines erkannten Zustands sein oder auch die Ansteuerung einer anderen Komponente des technischen Systems.

Beispielsweise kann die Regelung einer Heizungsanlage über ein derartiges eingebettetes System erfolgen. Auch in zahlreichen anderen Bereichen des Haushalts sind eingebettete Systeme heutzutage anzutreffen (Waschmaschine, Kühlschrank, Mikrowelle, Kaffeemaschine, Fernseher, DVD-Player, Alarmanlagen, etc.). Zusätzlich enthalten größere technische Systeme wie Autos, Flugzeuge, Eisenbahnen, Kraftwerke, etc. eine sehr große Anzahl eingebetteter Systeme, welche in ihrem Zusammenwirken die Funktionalität des Systems ausmachen.

Es gibt eingebettete Systeme, die nur eine eng umrissene Aufgabe erfüllen. Es hat sich als kosteneffizient herausgestellt, die gewünschte Funktionalität über eine Kombination aus Hardware und Software zu erreichen. Die große Flexibilität der Software ermöglicht eine optimale Ausnutzung der Leistungsfähigkeit der Hardware.

Egal wie Ihre Idee aussieht, wir von DLS können Ihnen bei der Umsetzung helfen. Regelmäßig braucht ein Projekt mit einem „embedded system“ mehrere Schritte von der Idee bis zum fertigen Produkt. Folgende Schritte kommen bei der Realisierung eines neuen „embedded systems“ wiederkehrend vor:

Kann die gewünschte Funktionalität im angedachten Kostenrahmen umgesetzt werden? Um eine gewisse Sicherheit in der Beantwortung dieser Frage zu gewinnen, ist es oftmals zielführend, die technische und wirtschaftliche Realisierbarkeit der Produktidee durch eine Vorstudie abzusichern. Sie wollen keineswegs mitten im Projekt auf unliebsame „Überraschungen“ stoßen, welche die Umsetzung des Projektes nicht mehr sinnvoll erscheinen lassen, weil die aufgelaufenen Projektkosten ausufern oder weil plötzlich die technische Machbarkeit an Grenzen stößt.

Auf welchen Microcontoller wollen Sie bauen? Was sind Ihre Auswahlkriterien? Kosten oder langfristige Verfügbarkeit?

Eingebettete Systeme können auf standardisierter Hardware, welche in großen Stückzahlen erhältlich ist, aufsetzen (z. B. Embedded-PCs). Häufig sind einschränkende Randbedingungen (minimale Kosten, geringer Platz-, Energie- und Speicherverbrauch, etc.) vorhanden, welche für eine produktspezifische Entwicklung (eigenes Hardware-Design) sprechen. Hier ist wie so oft die Frage zu stellen, ob auf bereits seit Jahren auf dem Markt verfügbare und erprobte Komponenten (mit bekannten Stärken und Schwächen) oder erst vor kurzem eingeführte Komponenten (oftmals in einzelnen Merkmalen leistungsfähiger) gesetzt wird.

Bei vielen Anwendungen kann die Verwendung einer bereits erprobten Prozessorarchitektur dazu beitragen, Kosten zu senken. Die Wiederverwendung von Programmcode und Toolchains sowie die Möglichkeit der Nutzung bereits bekannter Referenz-Designs sind hierbei nicht zu unterschätzende Faktoren, welche gemeinsam mit den reinen Materialkosten zu betrachten sind.

Von eingebetteten Systemen wird oftmals eine besondere Reaktionszeit erwartet. Innerhalb einer garantierten Zeitspanne von wenigen Millisekunden müssen Daten verarbeitet werden und Ausgaben vorgenommen werden. Zusätzlich wird eine besondere Robustheit und Langlebigkeit von eingebetteten Systemen erwartet. Aus diesem Grund wird beim Hardwaredesign auf bewegliche Teile (wie z. B. aktive Lüfter) verzichtet, um das Wartungsintervall des eingebetteten Systems erhöhen zu können. Wenn eingebettete Systeme im Verbund mit anderen eingebetteten Systemen eingesetzt werden, so führt dies oftmals dazu, dass es keine direkte Benutzerschnittstelle (weder Tasten, noch Displays oder Lautsprecher) oder nur eine sehr eingeschränkte Benutzerschnittstelle (z. B. nur einige LEDs für Statusinformationen) gibt.

Die Software für eingebettete Systeme ist somit häufig maßgeschneidert. Es muss nicht unbedingt ein vollständiges Betriebssystem eingesetzt werden, welches mehrere verschiedene Anwendungen gleichzeitig ausführt. Es gibt allerdings stets folgende Kernfragen zu beantworten:

Wo ist die Software gespeichert (z. B. direkt in der eingesetzten Recheneinheit oder auf einem eigenen Speicherbaustein) und wie wird die Software gestartet (z. B. eigenes Startprogramm, welches ggf. auch Aktualisierungen der Software in bereits ausgelieferten Systemen ermöglicht)?

Wo werden Daten gespeichert (interner Speicher auf dem Mikrocontroller oder externer Speicher)?

Wie wird die Hardware angesteuert (eigenes Betriebssystem, vorhandene Software-Komponenten, neu zu schaffende Software-Komponenten)?

Wie wird die Anwendungslogik gestaltet (z. B. eng verzahnt mit der Hardware-Ansteuerung, um maximale Geschwindigkeit zu erzielen oder auf Basis einer Zwischenschicht, um auch eine andere Hardware nutzen zu können)?

Da die Software fest mit der Recheneinheit verbunden ist, wird sie auch mit dem Begriff „Firmware“ bezeichnet. Aus der Beantwortung der Kernfragen zur Architektur entstehen z. B. nachfolgende Firmwarekomponenten:

Bootloader: Eigene Software, welche das Betriebssystem lädt und startet. Dabei wird dem Betriebssystem auch die auszuführende Anwendungssoftware übergeben. Der Bootloader kann auch das Betriebssystem und oder die Anwendungssoftware aktualisieren, wenn eine dafür geeignete Hardwareschnittstelle verfügbar ist (serielle Schnittstelle wie z. B. RS232, USB, Ethernet). Ein bekannter Bootloader ist U-Boot. Einige Bootloader können sich auch selbst aktualisieren, andere Bootloader können nur von der Anwendungssoftware aktualisiert werden.

Betriebssystem: Das Betriebssystem sorgt für die Ausführung der Anwendungssoftware und bietet dieser zahlreiche Funktionen zur Nutzung der verfügbaren Hardware an. Es wird eine einheitliche Schnittstelle bereitgestellt, damit die Anwendungssoftware sich nicht mit den Details der Hardware befassen muss. Das Betriebssystem bietet u. a. die Möglichkeit, mehrere Anwendungsteile gleichzeitig auszuführen (Multithreading, Multitasking), geordnet auf den Speicher zuzugreifen (inkl. Dateiverwaltung) und ggf. über ein Netzwerk zu kommunizieren (z. B. Ermöglichung der Nutzung einzelner IP-Dienste wie FTP, HTTP, SMTP, Telnet, NTP).

Applikationssoftware: Dieser Teil der Software enthält die eigentliche Logik der Anwendung und wird auch als Anwendungssoftware bezeichnet.

Für die Software-Entwicklung von eingebetteten Systemen werden Werkzeuge zur Abfassung der Programmtexte (Quelltexteditoren), zur Übersetzung der Programmtexte in ausführbare Dateien (Compiler) sowie zur Fehlersuche bei der Ausführung auf der Zielhardware (Debugger) verwendet. Die Werkzeuge werden von Halbleiterherstellern, die Verbreitung ihrer Prozessoren und Controller fördern möchten, und spezialisierten Softwarefirmen angeboten. Diese Werkzeuge verfügen über unterschiedliche Eigenschaften, Stärken und Schwächen, welche bei der Auswahl für den angedachten Einsatzzweck berücksichtigt werden müssen. Als Programmiersprache wird zumeist C oder C++ verwendet, für die effiziente Entwicklung werden die Werkzeuge so ausgestaltet, dass sie auf Windows-PCs und/oder Linux-PCs genutzt werden können und nicht direkt auf der Zielhardware ausgeführt werden müssen (z. B. Cross-Compiler).

Wir haben bei DLS in den letzten 20 Jahren in den unterschiedlichsten Projekten mit verschiedenen Werkzeugen gearbeitet und können Sie aus der praktischen Erfahrung heraus bei der Auswahl beraten.

Für das Testen der Software wird oftmals eine Simulation der Zielhardware verwendet, welche es ermöglicht, die Software auf dem PC zu testen. Es gibt allerdings auch Werkzeuge, welche Software-Tests auf der Zielhardware ermöglichen.

In allen Fällen ist die Automatisierung der Testausführung anzustreben, damit die während der Entwicklung vorgenommenen Softwareänderungen sehr schnell auf „unerwünschte Nebenwirkungen“ geprüft werden können.