Grundlagen der Entwicklung von Embedded Systemen

Ein Embedded System (Eingebettetes System) ist nach Wikipedia wie folgt definiert:

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.

Embedded Systeme können heute in den meisten Geräten in allen Branchen gefunden werden. Häufig führen diese Systeme kritische und sicherheitsrelevante Funktionen aus und müssen daher mit grosser Sorgefallt konzipiert und entwickelt werden.

Der Kontext eines Embedded Systems wird durch den Benutzer, Umsysteme und die physikalische Umgebung definiert wie in Abbildung 1 dargestellt.

Wenn im folgenden Artikel der Begriff System verwendet wird, ist damit immer ein Embedded System gemeint.

Aufbau von Embedded Systemen

Ein System besteht aus Hardware und Software die genau aufeinander abgestimmt sind, wie auf Abbildung 2 dargestellt.

Hardware

Die Hardware eines Systems kann je nach Einsatzzweck sehr unterschiedlich ausfallen. Sie besteht unter anderem aus:

• Mikroprozessoren
• Speicher (Flash, RAM, EEPROM, …)
• FPGAs (Field Programmable Gate Array)
• Sensoren
• Aktuatoren
• Stromversorgung
• Diskrete Logik (Logik Gatter etc.)
• Anschlüsse
• Kontrollelemente, Bildschirm, …
• Gehäuse

 

In einem Embedded Systemen beinhaltet einen oder mehrere Mikroprozessoren. Diese erlauben es das Verhalten des Systems mittels Software zu kontrollieren. Häufig sind auch Mikrokontroller (System on a Chip, SoC) in Embedded Systemen anzutreffen. Bei diesen sind der Mikroprozessor und andere Komponenten wie Speicher und Peripherien auf einem einzelnen Chip untergebracht. Im Weiteren wird der Begriff Mikroprozessor verwendet, dies schliesst aber auch Mikrokontroller mit ein.

 

Software

Die Software, die auf einem Mikroprozessor ausgeführt wird, nennt man Firmware. Im Unterschied zu einer klassischen Desktop Applikation muss eine Firmware mit deutlich weniger Ressourcen und Leistung auskommen.

Eine Firmware besteht aus den folgenden Komponenten:

• Bootloader
• Betriebssystem
• Applikation

Der Bootloader wird ausgeführt, wenn der Mikroprozessor startet. Er ist dafür zuständig, die Applikationssoftware und allenfalls das Betriebssystem zu laden und zu starten.

Das Betriebssystem stellt grundlegende Funktionen wie Multitasking, Speicherverwaltung sowie weitere Dienste zur Verfügung. Embedded Betriebssysteme werden häufig als Real Time Operating Systems (RTOS) bezeichnet, um auf ihre Echtzeitfähigkeit hinzuweisen. (Siehe dazu auch nächstes Kapitel).

Nicht jede Firmware verwendet ein Betriebssystem. Wenn dies nicht der Fall ist, spricht man von einer Bare Metal Firmware. Oft übernimmt dort eine ‘Runtime’ genannte Bibliothek die Grundlegende Funktion eines Mini Betriebssystems. Die Runtime wird meist direkt in die Applikation gelinkt und zusammen mit dieser auf das Gerät heruntergeladen.

Die Applikation wird vom Bootloader oder dem Betriebssystem gestartet und ist für die eigentliche Funktion des Embedded Systems zuständig. Sie greift häufig direkt auf Prozessor Schnittstellen zu, um mit der Hardware des Embedded Systems und dadurch indirekt mit Umsystemen und dem Benutzer zu kommunizieren.

 

Schnittstellen

Embedded Systeme kommunizieren mit anderen Systemen und/oder dem Benutzer über Schnittstellen. Es gibt auch viele Embedded Systeme ohne Benutzerschnittstelle, die ausschliesslich mit anderen Systemen kommunizieren.

i) System Schnittstellen
Zur Kommunikation mit anderen Systemen werden verschiedene Schnittstellen eingesetzt. Dies können standardisierte Schnittstellen wie UART (Universal Asynchronous Receiver Transmitter), I2C (Inter-Integrated Circuit), CAN (Controller Area Network) oder USB (Universal Serial Bus) sein. Aber auch proprietäre Schnittstellen sind immer wieder anzutreffen. Diese werden vor allem innerhalb eines Gerätes eingesetzt und bestehen aus Datenleitungen die Mikroprozessoren untereinander oder mit anderen Hardware Komponenten verbinden. Im Gegensatz zu standardisierten Schnittstellen sind diese oft schneller und günstiger in der Umsetzung.

ii) Benutzerschnittstellen (User Interface)
Sofern das Embedded System die Interaktion mit einem Benutzer unterstützt, verfügen es dafür ebenfalls über Schnittstellen. Diese werden auch mit dem Überbegriff User Interface (UI), Man Machine Interface (MMI) oder Human Machine Interface (HMI) bezeichnet.

Solche Schnittstellen können zum Beispiel Bildschirme, Keypads oder Touchscreens sein. Viele Geräte verfügen aber auch über LCDs, LEDs, Knöpfe, Schalter und. ähnliche Bedienelemente. Auch Audio Ein- und Ausgabe kann Teil einer solchen Schnittstelle sein, zum Beispiel für die Alarmierung.

 

Einschränkungen und Anforderungen

Im Vergleich zu PC-Applikationen unterliegen Embedded Systeme verschiedenen Einschränkungen und Anforderungen:

• Begrenzte Ressourcen
• Limitationen von Bibliotheken und Tools
• Echtzeitfähigkeit
• Sicherheit und Zuverlässigkeit
• Eingeschränkte Update-/Wartungsfähigkeit

 

Begrenzte Ressourcen

Eine Firmware muss sich im Gegensatz zu einer PC-Applikation mit deutlich weniger Ressourcen arrangieren. Ein typischer Mikroprozessor hat in der Regel eine Taktrate von wenigen bis einigen 100 MHz. Als Arbeitsspeicher stehen meist nur einige Kilobyte (KB) zur Verfügung und als persistenter Speicher einige Megabyte (MB). Das ist hauptsächlich damit begründet, dass die Herstellkosten von Embedded Systemen in der Regel möglichst niedrig gehalten werden müssen, weil hohe Stückzahlen produziert werden, und im mobilen Bereich auch Energieeffizienz ein sehr wichtiger Faktor ist. Im Gegensatz dazu hat eine leistungsfähigere PC-Hardware einen deutlich höheren Stromverbrauch, mehr Wärmeentwicklung und ist in der Herstellung teurer.

Durch eine saubere System- und Software Architektur ist es aber möglich, diesem Aspekt Rechnung zu tragen und nur genau so viel Ressourcen für eine Aufgabe zu verbrauchen wie notwendig. Wenn schon früh im Design Prozess klar ist, was wo im System am besten gelöst wird, werden unnötige ‘Verbraucher’ vermieden und so sowohl Herstell- als auch Entwicklungskosten reduziert.

 

Limitationen von Bibliotheken und Tools

Bei der Entwicklung einer Firmware stehen in der Entwicklungsumgebung oft keine umfangreichen Bibliotheken zur Verfügung. Daher kann es sein, dass benötigte Algorithmen von Hand implementiert werden müssen. Dies muss ebenfalls bei der Planung und Umsetzung berücksichtigt werden, da dies den Entwicklungsaufwand erhöhen kann.

Durch Code Generatoren und 3rd Party Bibliotheken kann dieser Aufwand reduziert werden.

 

Echtzeitfähigkeit

Ein weiterer, wichtiger Aspekt eines Embedded Systems ist die Echtzeitfähigkeit. Echtzeit bedeutet, dass eine bestimmte Operation in einem genau definierten Zeitfenster ausgeführt werden muss. Dies kann im Bereich von Sekunden aber auch von Mikrosekunden liegen.

Es ist wichtig, das klar definiert wird, welche zeitlichen Grenzen gelten:

• Wann muss die Operation abgeschlossen sein?
• Was ist die Toleranz?

 

Mit diesen Informationen kann das System Design auf die Anforderung ausgelegt werden. Beispielsweise verfügen leistungsfähigere Mikroprozessoren oft über Mechanismen wie Caching oder Branch Prediction, die die Leistung verbessern. Allerdings führt dies dazu, das nicht mehr im Vorhinein klar ist, wie lange die Ausführung einer Operation genau dauert. Liegen die Daten bereits im Cache, geht es schneller, müssen sie zuerst geladen werden, dauert es länger.

Das bedeutet, das bereits bei der Auswahl und Konfiguration eines Mikroprozessors darauf geachtet werden muss, dass dieser die zeitlichen Anforderungen einhalten kann. Muss dies später in der Software gelöst werden, kann der Entwicklungsaufwand massiv ansteigen.

 

Sicherheit und Zuverlässigkeit

Viele Embedded Systeme müssen sicherheitsrelevante (safety critical) Funktion ausführen oder sind entscheidend für die Funktion eines wichtigen Gerätes/Prozesses (mission critical). Daher ist die Sicherheit ein wichtiger Aspekt bei der Entwicklung eines solchen Systems.

Die Anforderungen an die Sicherheit müssen früh im Entwicklungsprozess berücksichtigt werden:

• Funktionssicherheit
• Verhalten im Fehlerfall
• Datensicherheit (Cybersecurity)

 

Eine Risikoanalyse (siehe weiter unten) hilft, diese Anforderungen früh zu erkennen. Auch geltende Normen und Richtlinien für die entsprechende Geräteklasse und Branche geben hierzu einen Rahmen vor.

Wird die Sicherheit von Anfang an ins Design miteinbezogen, kann durch die geschickte Aufteilung von Komponenten der Entwicklungsaufwand oft stark reduziert und die Sicherheit verbessert werden.

So kann es z.B. einfacher sein, wenn eine externe Hardware die Einhaltung eines Parameters (Spannung, Temperatur, etc..) überwacht und einen Fail Safe State auslöst, als dies nachträglich in der Software zu lösen.

Beim Design des Systems sollte von Anfang an klar definiert werden, wie das Verhalten im Fehlerfall sein sollte.

Beispiele sind:

• Reset des Prozessors und Neustart der Firmware
• Laden einer Backup Konfiguration
• Verweilen in einem Fail Safe State und Aufrechterhalten kritischer Funktionen (z.B. Beatmung)
• Redundante Alarmierung von Benutzer und oder Umsystemen

 

Eingeschränkte Update-/Wartungsfähigkeit

Ein Embedded System kann nach dem Inverkehrbringen möglicherweise nicht oder nur schwer aktualisiert werden. So hat das Gerät oft keine Internetanbindung oder keine Schnittstellen, die ein Firmware Update erlauben. Diese erhöht die Wichtigkeit von Verifizierung und Validierung.

Die Wartung sollte bereits in der Definitionsphase berücksichtigt werden. Klares Design und gute Testabdeckung können ebenfalls helfen, die Notwendigkeit von Updates zur Fehlerkorrektur zu verringern.

 

Embedded System Engineering

Bei der Entwicklung eines Embedded Systems muss darauf geachtet werden, den oben beschriebenen besonderen Anforderungen und Einschränkungen Rechnung zu tragen. Wie bei jeder System- und Software Entwicklung empfiehlt sich dabei eine systematische und strukturierte Vorgehensweise nach einem etablierten Entwicklungsprozess.

Das Vorgehen kann dabei grob in die folgenden Phasen unterteilt werden:

• Definition
• Analyse und Spezifikation
• Entwicklung
• Integration und Verifikation
• Validierung
• Wartung

Definition

In dieser Phase sollten alle Funktionen des zu entwickelnden Systems definiert werden. Hier hat es sich in der Praxis bewährt, von Anfang an jede Definition klar zu nummerieren und zu versionieren. Einmal festgelegte Nummer sollten nicht mehr verändert werden. So kann anschliessend in den folgenden Phasen eindeutig auf die Definitionen referenziert werden. Vom Vorteil ist ein Requirement-Engineering-Tool einzusetzen. Die Definitionen in einem Word- oder Excel- Dokument zu schreiben, erscheint zu Beginn einfacher, doch es wird später für einen erhöhten Aufwand sorgen. Die Definition sollte folgende Anforderungen beinhalten:

• Geplanter Verwendungszweck
• Benutzerschnittstelle
• Umsysteme

 

Analyse und Spezifikation

Ist das System klar definiert, werden in der nächsten Phase die funktionellen Anforderungen erfasst. Diese sind, wie bereits bei den Definitionen erwähnt, klar zu nummerieren. Anforderungen sollten referenzieren, welche Definitionen sie abdecken.

Sind die Anforderungen klar, wird die Systemarchitektur erstellt. Dies sollte ganzheitlich nach dem Top-down Ansatz geschehen und sowohl Hardware als auch Software berücksichtigen. Die Architektur zerlegt das System in Subsysteme und diese wiederum in Komponenten. Die Schnittstellen zwischen den Komponenten sind ebenfalls klar zu definieren. Weiter sollte bei jeder Komponente und Schnittstelle referenziert werden, welche Anforderungen damit umgesetzt werden. Auch in der Architekturbeschreibung empfiehlt es sich, alle Design Artefakte zu nummerieren und zu versionieren, idealerweise mit dem gleichen Tool, das für die Definition und Spezifikation verwendet wurde.

Die Spezifikation sollte folgende Anforderungen beinhalten:

• Schnittstellen zu Umsystemen
• Zeitliches Verhalten
• Stromverbrauch / Akku Laufzeit
• Sicherheit
• Lebensdauer

 

Das gewählte Design sollte in der Lage sein, alle Anforderungen bei gleichzeitig geringen Herstellkosten zu erfüllen. Daher müssen die vorhandenen Hardware-Ressourcen optimal genutzt werden. Auch die Lebensdauer von Komponenten (z.B. Schreibzyklen bei Flash und EEPROM) sollten berücksichtigt werden.

Namen von Schnittstellen sollten über das ganze Design eindeutig sein (System, Elektronik, Software Diagramme und Dokumentation) um Verwechslungen auszuschliessen. Es empfiehlt sich auch, bei der Benennung ein Schema zu verwenden, das für Variablen Namen in den gewählten Programmiersprachen zulässig ist (keine Sonderzeichen, keine Zahl am Anfang des Namens).

 

Entwicklung

Stehen die Anforderungen und das Design fest, kann das System realisiert werden. Hierbei werden die einzelnen Komponenten zuerst einzeln entwickelt und anschliessend im Subsystem und zuletzt im kompletten System integriert.

Oft werden sich während der Umsetzung Anforderungen oder das Design noch ändern, daher ist es hier sehr wichtig, ein klar definiertes Änderungsmanagement zu befolgen damit die Anforderungen und Design Dokumentation immer mit dem tatsächlich umgesetzten System übereinstimmt. Die einzelnen Komponenten sollten bereits vor der Integration verifiziert werden (siehe unten), idealerweise mit automatisierten Tests. Das Verifizieren von Baugruppen kann zugunsten einer Verifikation des Systems weggelassen werden. Allerdings ist es oft einfacher, Fehlerfälle an Komponenten zu testen, da sie sich im System möglicherweise nicht mehr simulieren lassen.

 

Integration und Verifikation

Es muss sichergestellt werden, dass die Umsetzung der Komponenten dem vorher definierten Design entspricht. Daher werden die einzelnen Komponenten anhand der Anforderungen verifiziert. Bei der Integration sollten auch die integrierten Komponenten, Subsysteme und das fertig integrierte System verifiziert werden.

 

Validierung

Anschliessend sollte das System gegen die Definitionen validiert werden, um sicherzustellen, dass es diese auch erfüllen kann. Auch hier kann sich die Automatisierung von Tests auszahlen. Der initiale Aufwand ist aber nicht zu vernachlässigen, sollte sich aber in der Wartungsphase mehr als auszahlen.

 

Wartung

Ist das System einmal entwickelt, wird es produktiv eingesetzt. Dabei werden oft Fehler gefunden und neue Anforderungen tauchen auf. Um ihnen Rechnung zu tragen, wird das System während seiner Lebensdauer oft angepasst und erweitert. Hier empfiehlt sich, einen etablierten Prozess für Änderungsmanagement einzusetzen. Oft wird hier das V-Model nochmals durchlaufen. Wichtig ist, dass auch in dieser Phase die Anforderungen und das Design aktuell gehalten werden. Wurde dies bei der Entwicklung sauber dokumentiert, wird es sich hier besonders durch tiefere Kosten und weniger Anpassungsfehler auszahlen.

Bei Anpassungen am Design muss genau darauf geachtet werden, dass keine bestehenden Anforderungen verletzt werden. Müssen Hardware Komponenten ersetzt werden, ist genau darauf zu achten, dass das System weiterhin alle Anforderungen erfüllt.

 

Embedded System Engineering in der Medizintechnik

Wird ein Embedded System für ein reguliertes Umfeld wie Medizintechnikbranche entwickelt, sind einige weitere Aspekte zu beachten:

• Risiko Management
• Rückverfolgbarkeit
• Nachvollziehbares Design

 

Risiko Management

Aufgrund des System Designs und der Definition des Systems müssen anhand eines klar definierten Prozesses, z.B. ISO 14971, alle Risiken, die bei der Verwendung des Embedded Systems entstehen können, bewertet werden. Risiken, die nicht akzeptabel sind, müssen mit geeigneten Massnahmen reduziert werden. Dies kann das Design des Systems massgeblich beeinflussen, daher muss eine erste Risikobewertung bereits in der Spezifikationsphase erfolgen und das Risikomanagement während des gesamten Entwicklungsprozesses aktuell gehalten werden.

 

Rückverfolgbarkeit

Im regulierten Umfeld ist es notwendig, jederzeit aufzeigen zu können, wo im Design welche Anforderung umgesetzt wurde und wie sie getestet wurde. Hier ist es unumgänglich, ein Requirement-Engineering-Tool einzusetzen. Denn eine Traceability Matrix von Hand zu erstellen ist zwar möglich, doch sehr zeitaufwändig und fehleranfällig. Weiterhin wird sie nach der ersten Änderung (siehe Wartung oben) nicht mehr stimmen und muss erneut aktualisiert werden.

 

Nachvollziehbares Design

Das Design des Systems muss nachvollziehbar sein. Daher muss es dokumentiert sein. Hier ist auch wichtig, das Design Entscheidungen und Begründungen mit dokumentiert werden, um diese auch später, z.B. in der Wartungsphase nachvollziehen zu können.

Die Entwicklung von guten und sicheren Embedded Systemen stellt eine Herausforderung an ein Unternehmen und seine Entwickler dar. Doch mit einem gut geplanten Vorgehen und guter Dokumentation kann diese gemeistert werden und sowohl die Kosten als auch die Qualitätsziele erreicht werden.

Embedded Systeme haben speziellen Einschränkungen und Anforderungen wie zum Beispiel:

• Begrenzte Ressourcen
• Limitation von Bibliotheken und Tools
• Echtzeitfähigkeit
• Sicherheit und Zuverlässigkeit
• Eingeschränkte Update/Wartungsfähigkeit

Dadurch benötigen sie ein klar definiertes Design und müssen gut dokumentiert und getestet werden, da nachträgliche Anpassungen teuer werden können.

Im Regulierten Umfeld kommen weitere Aspekte dazu:

• Risiko Management
• Rückverfolgbarkeit
• Nachvollziehbares Design.

IMT kann Sie in allen Phasen des Lebenszyklus von Embedded Systemen beraten und unterstützen. Wir haben mehrere Embedded Systemprojekte in Medizintechnik und für andere Gerätehersteller erfolgreich umgesetzt.

Haben Sie weitere Fragen? Dann wenden Sie sich bitte an uns.