Eine zentrale Rolle in der Hardware- und Software-Sicht auf ein Embedded System hat die Architektur. Sie wird in Architekturbeschreibungen spezifiziert und charakterisiert.
Um Architekturbeschreibungen von Embedded Systems näher zu betrachten, müssen wir uns ihnen zunächst methodisch annähern.
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.
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 Anforderungen in konkrete Design-Entscheidungen aufgelöst werden, umzusetzen. Bei Embedded Systems teilt man typischerweise in Hardware- und Software-Sichten auf, die ein Gesamtbild ergeben. Eine ganzheitliche Sicht, die alle Aspekte - zeitlich, dynamisch und strukturell - gleichzeitig darstellen kann, ist nicht erstrebenswert.
Sichten der 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
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
Sichten der 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.
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 als erste Ausgangsbases einer funktionalen Sicht
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.
.png?width=605&height=140&name=Statische%20Sicht%20(Komponenten).png "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
Querschnittskonzepte: An letzter 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.
Kommentieren