Skip to content
Weiß Rechteck
CPU

Architekturen eingebetteter Systeme

Das Konzept der Embedded Systems entstammt der einfachen Idee, Software- und Hardwaresysteme zu integrieren, um Systeme mit bestimmten Eigenschaften zu erschaffen. Damit einhergehend spielen ihre Verwendung, Anwendungen und Struktur eine wichtige Rolle.

Eine Aufschlüsselung der Begriffe Eingebettet, Systeme und Architektur ist daher unabdingbar, das Thema Embedded Systems besser einzuordnen. Entscheidend ist der Zweck und der Nutzen des Systems.

 

Zentrale Begriffe im Bereich Embedded Systems
System

Ein System bezeichnet objektiv eine Ansammlung vieler Einheiten, die einer Reihe von Regeln folgen. Man kann also sagen, dass ein System eine Anordnung von Einheiten ist, die dabei helfen, verschiedene Arten von Arbeit nach einem festen Plan auszuführen. Ein PC beispielsweise funktioniert nach den geplanten Anweisungen, die ihm gegeben wurden, definiert sich also maßgeblich durch Endbenutzer-Eingaben. Wenn Sie eine Aufgabe auf dem System ausführen, können Sie das Ergebnis vorhersagen, da alle Komponenten des Systems voneinander abhängig sind.

Eingebettete Systeme

Ein eingebettetes System besteht aus mehreren Schichten von Komponenten, die spezifisch nach den festgelegten Regeln arbeiten können. Dabei ist zu beachten, dass es sich entweder um ein unabhängiges System handeln kann, das von der gestellten Aufgabe bestimmt wird, oder um einen Teil eines umfassenderen Systems, das die Aufgaben des letzteren erfüllt.

Im Allgemeinen gibt es die folgenden Hauptkomponenten von Embedded Systems:

  • Die grundlegende Hardwareschicht: sie bildet die Basis für die anderen Schichten des Systems;
  • die Applikationsschicht - fügt die wesentliche Software hinzu, die verarbeitet werden soll;
  • das OS- oder Plattform-Layer, welches die Regeln für die Applikationsschicht und das Zusammenwirken der Schichten festlegt. Zudem werden hier Überwachungs- und Kontrollroutinen abgelegt.

Eingebettete Systeme basieren in der Regel auf einem oder mehreren der Elemente Mikroprozessor oder Mikrocontrollern. Zudem kann ein programmierbares Logik-Device eingesetzt werden (FPGA, CPLD). Diese Steuerbausteine nehmen Aufgaben unabhängig innerhalb viel größerer Systeme wahr. Daher müssen sie während des gesamten Prozesses äußerst zuverlässig sein. Dies unterscheidet eingebettete System von bspw. PC-basierten Systemen.

 

Komponenten eines eingebetteten Systems

Die Architektur eines eingebetteten Systems hingegen bezieht sich auf den Aufbau des Systems. Sie ermöglicht es jedem Entwickler, die Qualität und Leistung des Systems zu verstehen. Die Architektur eines Embedded Systems steht für einen Umsetzungsplan als erster Schritt der Implementierungstätigkeiten auf technischem Niveau. Ausgehend von Kundenanforderungen werden Architekturen des Gesamt-Embedded-Systems, der verwendeten Hardware, also konkreter logischer Bausteine, und der Software innerhalb der programmierbaren Elemente des Systems.

Eine Architekturbeschreibung ist also immer dreischichtig und besteht aus der Hardware, der Software und der Hardware-Software-Integration. Die Architektur stellt daher die Komponenten des eingebetteten Systems für die Personen zusammen, die das System zur Realität bringen. Damit einhergehend entspringen aus der Architektur Anforderungen für das Design, den Entwurf und den Test.

Damit ist in der Regel die Funktionalität erst dann verständlich, wenn man die Architektur klar vor Augen hat. Jede Komponente hat einen bestimmten Zweck und es gilt jeden dieser Aspekte zu verstehen. Um das System auf Änderungen hin zu untersuchen und neue Elemente hinzuzufügen, ist es daher unerlässlich, die Architektur offen zu legen.

 

Merkmale von Embedded Systems

Die Aufgabenspezifität bestimmt in hohem Maße, wie das Embedded System entwickelt wird. Nicht vollumfänglich, aber dafür in den meisten aller Fälle ist ein Embedded System durch die folgenden Merkmale gekennzeichnet:

Single-Purpose-Orientierung: Die gängigste Praxis für eingebettete Systeme ist die Ausführung einer bestimmten Aufgabe. Daher funktioniert es wiederholt nach den Regeln, die für die jeweilige Aufgabe festgelegt wurden.

Hohe Zeitkritikalität: Prozesse müssen bei begrenzten Ressourcen sehr schnell ausgeführt werden. Das wiederum bei einem stark begrenzten Stromverbrauch. Effizienz ist ein wesentliches Merkmal dieses softwaregesteuerten Systems.

Speicherverbrauch: Controller und Prozessoren verfügen über einen eigenen ROM-Speicher, was bedeutet, dass für den Betrieb des Systems zumeist kein sekundärer Speicher erforderlich ist. Allerdings überschreitet dieser Speicherbereich in der Regel einstellige Gigabyte-Bereiche nicht und ist daher deutlich geringer als herkömmliche Festplatten und Flash-Speicher.

Konsistenz und Zuverlässigkeit: Mikrocontroller- und Mikroprozessor-basierte Systeme sind äußerst zuverlässig, effizient und stabil in ihrer Arbeit. Allerdings sind anders als im Heim-Elektronik und PC-Bereich Lebensdauern und Uptimes im Bereich mehrerer Jahre nicht unüblich.

Interfaces: Um einen Anschluss an eine Peripherie, wie Sensorik oder Aktorik sowie Komponenten des Super-Systems zu ermöglichen, müssen Anschlüsse an die Außenwelt des Systems vorhanden sein. Diese Anschlüsse sind selten standardisiert und in den meisten Fällen herstellerabhängig.

 

Architekturen beschreiben

Die Architekturbeschreibung fasst final die erste Lösungsschicht zusammen und ist damit die Grundlage für die Implementierung des Eingebetten Systems als PCB-Layout einerseits und als Software andererseits. Die Architekturbeschreibung ist somit das wichtigste Element um die erste Implementierungsschicht, bei der die

Folgende Methoden haben sich dabei bewährt:

 

Hardware-Architektur

Blockschaltbild: Der Klassiker unter den Hardware-Architekturen. Hier wird das PCB-Layout grob festgelegt. Es werden erste Festlegungen in der Auswahl der Bausteine und des Pinnings vorgenommen. Wichtig ist hierbei, dass der Fokus auf zentralen Bauteilen liegen soll und die technische Lösung in den Vordergrund stellt.

Blockschaltbild

Blockschaltbild

BoM als vorläufige Teileauswahl: Eine Bill of Material in Stücklistenform ist essenziell für die weitere Bestimmung der entwicklungstechnischen Stoßrichtungen. Hier werden tabellarisch die Komponenten festgelegt, sodass Sie beschaffbar sind. Tools wie das BOM-Tool von Octopart (https://octopart.com/bom-tool) dienen dazu bereits an dieser Stelle nicht in Obszoleszenz-Fallen zu tappen und liefern über die Distributor-Preise eine erste Kostenindikation. Wichtig ist dabei, den Fokus auf funktionale oder schwierig zu beschaffende Teile zu legen. Standard-Komponenten wie Ferrite, Widerstände, Kondensatoren, Spulen, Fuses oder LDOs sollten außen vor gelassen werden.

Power Domain Management: Als Spezialfall im Bereich der Embedded Systems-Hardware-Architektur, aber dafür mit besonderem Augenmerk. Das Power Domain Management dient der Zuordnung zentraler Bausteine auf der PCB-Hardware zu den einzelnen Versorgungsdomänen. Ein beispielhaftes Power Domain Diagram ist im Folgenden dargestellt und gestaltet die Spannungsversorgung für Input- und Output Größen eines PMIC-getriebenen Mikroprozessors aus.

Power Domain Diagram

Power Domain Diagram

Software-Architektur

Feature- oder Use-Case-Diagramm: Die erste Sicht im funktionellen Software-Kontext bildet die Kundensicht. Diese dient insbesondere auch auf planerischem und organisatorischem Niveau eine erste Grundlage dafür, was das System für den Kunden eigentlich leisten soll. So hilft eine Use-Case-Spezifikation dabei, die Software in erster Instanz in funktionale Blöcke herunterzubrechen und einzelne übergeordnete Domänen zu liefern.

UCD

Features im Use Case Diagram

Dynamische Sicht I - Ablauf-Diagramm: Das Ablauf-Diagramm dient an dieser Stelle nicht einer funktionalen Ausdefinition, sondern einer groben Zweckbestimmung der Software. Dabei eignet sich, nach dem EVA-Prinzip festzustellen, welche Daten pro Zyklus eingehen um in einem funktionalen Kontext Ausgangsdaten zu erzeugen.

Dynamische Sicht II - Datenfluss-Diagramm: Das Datenfluss-Diagramm beschreibt im Wesentlichen die Zusammenhänge zwischen modularen Konstrukten, die typischerweise in einer Source zusammengefasst sind. Es reicht an dieser Stelle aufzuzeigen, wie im Rahmen einer speziellen Aufgabe spezielle Komponenten miteinander interagieren. Eine die Lösung vorwegnehmende Sicht ist an dieser Stelle noch nicht notwendig.

ABlaufdiagramm

Ablaufdiagramm als erste Ausgangsbases einer funktionalen Sicht

Datenflusssicht

Datenflusssicht

Statische Sicht - Komponenten- und Schnittstellen-Architektur: Nach der dynamischen Sicht folgt die statische Sicht – nicht umgekehrt. Mit Festlegung auf den dynamischen Zusammenhalt des Systems kann der Übergang zur statischen Betrachtung erfolgen. Diese ist der erste Ansatz einer entwurfsorientierten Implementierung und steht daher an erster Stelle beim Aufbau des Source-Codes. Ein Entwickler wird somit vermutlich immer erst diesen Teil lesen, weil hier zentrale Forderungen an die gedachte Baum- oder Schichtstruktur der Source-Dateien abgelegt sind. Die Komponenten- und Schnittstellen-Architektur fasst Forderungen an Funktionen, Member, Speicher, Klassen und Typedefs zusammen.

Statische Sicht (Komponenten)

Komponentensicht

Zustands-Sicht: Die Zustands-Sicht ist ein wesentlicher konzeptueller Ansatz für die Darlegung, was ein Embedded-System bereit ist unter welchen Voraussetzungen zu leisten. Das bedeutet, dass eine Software gewissen Zyklen nur durchfahren darf, wenn bspw. äußere Rand- und Rahmenbedingungen durch Sensor- und Eingangswerte nicht über oder unterschritten sind. Für die Definition sicherheitskritischer Systeme ist damit dieser Teil einer der wichtigsten, weil er Fehlerzustände und kritische Übergänge berücksichtigen muss.

Zustandssicht

Zustandssicht

Querschnittskonzepte: An dieser Stelle werden allgemeine Strukturen und Aspekte, die systemweit gelten aufgelistet. Diese können im Kontext der Embedded Systems auch IDEs oder Compiler beinhalten. Soll beispielsweise ein einheitliches Tasksystem verwendet werden oder ein spezielles Memory-Konzept, wird dies an dieser Stelle genannt. Die Beschreibung ist an dieser Stelle textuell. Die Wahl der jeweiligen Konzepte ist zu begründen

 
Zusammenfassung

Die Beschreibung und Definition von Architekturen folgt keinem Standard-Werk, sondern ist ein Zusammenspiel verschiedener Block- und Gesichtspunkte. Insbesondere im stark normativ geregelten Kontext von industriellen Embedded Systems ist daher ein strukturierter und methodisch einwandfreier Ansatz notwendig, der den zentralen Fragen aus der Anforderungsspezifikation eine erste Implementierungsidee entgegensetzt.

Sie möchten mehr darüber wissen?

Fragen kostet nichts. Wie und warum wir die Dinge tun, beantworten wir Ihnen gerne in einem persönlichen Gespräch. Lassen Sie uns dazu gerne kurz persönlich sprechen.