Systemarchitektur eingebetteter Systeme

1. Allgemeine Situation
2. Häufige Schwierigkeiten
3. Geeignete Kombination aus Bussen und Verarbeitungseinheiten
4. Innerhalb von FPGAs und FPGA-SoCs

1. Allgemeine Situation

Es ist interessant festzustellen, dass viele industrielle Forschungs- und Entwicklungsbereiche, bezüglich eingebetteter Systeme, vor technisch ähnlichen Herausforderungen stehen, es aber Unterschiede bei deren Handhabung und deren interner Verbindungen (Busse) gibt. Während beispielsweise die Automobilindustrie nach Vereinheitlichung strebt und damit bereits die Anforderung der Zuverlässigkeit adressiert, findet sich dagegen in manchen Branchen der Elektroindustrie eine rege Vielfalt an technischen Umsetzungen. Mit dieser Vielfalt sind nicht etwa vielfältige Eigenentwicklungen von Bussystemen gemeint. Es wird sehr wohl auf bekannte Standards gesetzt. Vielmehr ist die verwendete Kombination standardisierter Bussysteme zwischen den Verarbeitungseinheiten des eingebetteten Systems gemeint. Dabei werden häufig Bustopologien gebildet, deren Teil-Bussysteme nicht durch Brücken miteinander verbunden sind.

Auch der Einsatz von Bussystemen wie dem USB (Universal Serial Bus), welcher vorwiegend in der Consumer-Elektronik eingesetzt wird, ist häufig innerhalb der eingebetteten Systeme anzutreffen. Die Gründe für diese Verbreitung sind unter anderem die Bereitstellung vieler Sensoren für den Zugriff über USB und die verhältnismäßig preisgünstige Möglichkeit zur Anbindung mehrerer sogenannter downstream-Ports an einem upstream-Port durch USB-Hub-Controller. Gerade diese Kombination an vermeintlichen Vorteilen trägt zwar zu einer zügigen Entwicklung von prinzipiell funktionierenden Prototypen bei, führt aber häufig zu Problemen bei der Serienfertigung.

2. Häufige Schwierigkeiten

Unter anderem sind Schwierigkeiten bei folgenden Bereichen wiederkehrend bemerkbar.

Zuverlässigkeit und Signalintegrität

An diesem Punkt kann die Situation aus der oberen Sektion bzgl. einer auf USB basierenden Systemarchitektur aufgegriffen werden. Liegt dieser Fall vor, dass beispielsweise mehrere Signal- oder Bildsensoren über USB mit einem Host-System über USB-Hub-Controller verbunden sind, so sind häufig folgende Defizite anzutreffen:

  1. Die Zuverlässigkeit der Funktion eines Gerätes variiert stark bei der Serienfertigung über mehrere Chargen oder gar einzelne Geräte. Dies macht sich konkret dadurch bemerkbar, dass einzelne USB-Devices nicht mehr korrekt von Host-System erkannt werden, oder eine etablierte Kommunikation während des Betriebs unterbrochen wird.
  2. Wird das Host-System wegen Abkündigungen oder anderen Gründen ausgetauscht, so ist möglich, dass sich die funktionale Stabilität des Gesamtsystems verändert. Im ungünstigen Fall verschlechtert. Dies liegt an den unterschiedlichen USB-Host-Controllern, welche sich selbst bei verwandten Produktfamilien grundlegend unterscheiden können und industrielle und Consumer-Host-Systeme gleichermaßen betrifft. Die Ursache dieses Defizits findet sich auch nicht allein beim ausgetauschten Host-System. Es ist eher die Kombination der Komponenten aus USB-Devices, USB-Controllern, USB-Kabeln, USB-Hub-Controllern, USB-Repeatern, Leitungslängen und dem Host-System (inkl. Betriebssystem, USB-Treiber und Chipsatzeinstellungen), welche die Zuverlässigkeit des Gerätes so stark über den Betriebszustand und die Gerätevariationen schwanken lässt. Dies sollte bei der Entwicklung eines solchen Systems berücksichtigt werden. Das nachträgliche Korrigieren dieser Defizite ist unter Umständen mit sehr viel Aufwand verbunden und kann bereits bei der Konzeption der Systemarchitektur vermieden werden.

Mikrocontroller als zentraler Punkt der Datenkommunikation

Häufig ist festzustellen, dass Mikrocontroller (µC) und deren Programme als zentrale Elemente nicht nur der Datenverarbeitung, sondern auch der Datenpfadkette zum Einsatz kommen. Besonders die letzte Verwendung bewirkt, dass die Datentransfers, von höheren hierarchischen Ebenen des eingebetteten Systems zu Niedrigeren oder zu Endpunkten wie Sensoren oder Aktoren, durch Software stattfindet. Damit können sich folgende Defizite im Gesamtsystem etablieren:

  1. Der Datentransfer über die Ebenen des eingebetteten Systems verhält sich nicht-deterministisch.
  2. Die Echtzeitfähigkeit eines Gesamtsystems kann reduziert sein.
  3. Die Zuverlässigkeit und Stabilität des Gesamtsystems kann reduziert sein.
  4. Die Datentransferrate eines Datenpfades, welches den µC beinhaltet, kann durch den µC eingeschränkt sein.

Um eine geeignete Lösung aus dem unteren Teil dieses Beitrages vorwegzunehmen, ist es zur Auflösung dieser Situation sinnvoll auf eine ASIC gestützte Bus-Erweiterung des eingebetteten System zu setzen oder FPGAs, FPGA-SoCs als zentrales oder erweiterndes Datenkommunikationselemente einzusetzen.

Fehlen ausreichender Bus-Brücken

Ein nicht zu unterschätzendes Defizit vieler eingebetteter Systeme ist das Fehlen ausreichender Bus-Brücken, welche die gewählten Busse, auch über verschiedene Standards hinweg, miteinander verbinden und damit eine direkte Übersetzungsmöglichkeit von Bus-Transfers des einen Busses zu einem anderen ermöglichen. Dies betrifft in der Entwicklung oft gleichermaßen eingebettete Systeme, welche auf µC, FPGAs und FPGA-SoCs basieren, was allerdings bei der Verwendung dieser Technologien nicht so sein muss. Wird dagegen mehr auf Zukauflösungen wie Einplatinencomputer gesetzt, so ist das Defizit durch die implizit gegebene Teil-Architektur weitestgehend entschärft. Durch das Fehlen ausreichender Bus-Brücken kann es beim Gesamtsystem zu folgenden Defiziten kommen:

  1. Register-Zugriffe auf Bus-Teilnehmer werden häufig in den Verarbeitungseinheiten des eingebetteten Systems vorgesehen. Es wird also zusätzlicher Programm-Code oder zusätzliche Logik benötigt, um die Datentransferfunktion sozusagen künstlich umzusetzen.
  2. Nützliche Memory Mapping Funktionen können nicht direkt umgesetzt werden.
  3. Die Speicherbereitstellung über zwei Ebenen des eingebetteten Systems hinweg kann erschwert sein.
  4. Der direkte Speicherzugriff (Direct Memory Access DMA) über zwei Ebenen des eingebetteten Systems hinweg kann erschwert sein.
  5. Es können der Datendurchsatz und die Latenzzeit des Gesamtsystems stark beeinträchtigt sein.

3. Geeignete Kombination aus Bussen und Verarbeitungseinheiten

Eine einfache and bewährte Vorgehensweise

Um eine geeignete Systemarchitektur eines eingebetteten Systems zu konzeptionieren, ist ein erprobter Ansatz sozusagen von außen nach innen zu denken. Damit ist gemeint, nach folgenden groben Schritten, eine Betrachtung von den äußeren Anforderungen des Gesamtsystems nach innen durchzuführen, um zur detaillierten Spezifikation des eingebetteten Systems zu gelangen:

  1. Zuerst führt man eine Auflistung der gewünschten Interaktionsmöglichkeiten des Gesamtsystems mit der Umwelt, zum Beispiel mit Sensorik, Aktorik, Anzeigen und Schnittstellen, aus.
  2. Dann kann eine Analyse der Betriebsanforderungen wie Datendurchsatz, Latenzzeit, Betriebsmodi, Kosten und anderer Anforderungen der in Punkt 1 ermittelten Elemente erfolgen.
  3. Nun ist es möglich, die geeigneten Verarbeitungseinheiten des eingebetteten Systems auszusuchen. Dies erfolgt unter Berücksichtigung der nutzbaren Schnittstellen der Elemente aus Punkt 1 und sollte die Anforderungen aus Punkt 2 erfüllen.
  4. Wenn die notwendigen Verarbeitungseinheiten bekannt sind, so kann nun die Auswahl der passenden Bussysteme zwischen diesen erfolgen, wenn diese nicht schon durch die Verarbeitungseinheiten vorgegeben sind. Dieser Punkt kann in Rückkopplung mit Punkt 3 stehen.
  5. Zwar als letztes genannt aber nicht unbedingt als letztes zu beginnen, kann nun die Konzeption der Systemarchitektur bezüglich der eingebetteten Software und der programmierbaren Logik wie in FPGAs oder FPGA-SoCs ausgeführt werden. Diese Systemarchitekturen sind Teile des Gesamtsystems und sollten nicht unterschätzt werden. Im Prinzip kann hier angepasst wieder bei den Punkten 1 bis 4 vorgegangen werden.

Die aufgezeigte Darstellung ist natürlich nur eine grobe Skizzierung einer möglichen Vorgehensweise und muss im Speziellen angepasst werden.

Verarbeitungseinheiten

Die Wahl der Verarbeitungseinheiten ist natürlich eine der interessantesten Aufgaben während der Konzeption einer eingebetteten Systemarchitektur. Hier kann man die Leistungsfähigkeit, die Flexibilität aber auch die Baugröße und die Kosten des eingebetteten Systems entscheidend beeinflussen. Da die Auswahl der geeigneten Verarbeitungseinheiten konkret von den Anforderungen abhängt, kann es keine allgemeingültige Empfehlung für eine spezielle Verarbeitungseinheit geben. An dieser Stelle soll aber mit Tabelle 1 eine grobe Übersicht gegeben sein, welche häufig genutzte Verarbeitungseinheiten in eingebetteten Systemen mit einigen ihrer Eigenschaften (relativ zu einander bewertet) aufzeigt. Durch die Kenntnisse dieser Eigenschaften kann eine bessere Auswahl getroffen werden.

Tabelle 1: Übersicht häufiger Verarbeitungseinheiten in eingebetteten Systemen und deren Eigenschaften

Es kann in Tabelle 1 nur eine grobe Einschätzung der durchschnittlichen Bewertung erfolgen, da sich die Eigenschaften mancher Verarbeitungseinheiten stark überlappen können und von vielen Bedingungen abhängen, oder es Spezialanfertigungen pro Klasse gibt, welche bessere Eigenschaften besitzen.

Im Folgenden sollen ein paar häufig eingesetzte Verarbeitungseinheiten näher erläutert sein:

ASICs

Benutzerdefinierte ASIC-Lösungen kommen recht selten bei gewöhnlichen eingebetteten Systemen zum Einsatz. Wenn sie allerdings notwendig sind, so betrifft dies meist Kernfunktionen des Gesamtsystems, welches dadurch höchst individuell und leistungsfähig wird.

Mikrocontroller (µC)

Mikrocontroller sind ein sehr verbreitetes Element in eingebetteten Systemen. Sie sind kostengünstig und übernehmen meist elementare Datenverarbeitungs- und Datentransferaufgaben. Leider limitieren Sie damit häufig maßgeblich die Leistungsfähigkeit und das Potential des Gesamtsystems (siehe Punkt 2). Dies ist unter anderem daran bemerkbar, dass nachträgliche Funktionserweiterungen des Systems gar nicht oder nur mit sehr viel Aufwand umgesetzt werden können.

Einplatinencomputer

Einplatinencomputer sind eine äußerst effiziente und trotzdem preisgünstige Klasse der Verarbeitungseinheiten. Bekannte Beispiele sind das Raspberry Pi oder auch die NVIDIA Jetson-Systeme. Die Vorteile dieser Systeme bestehen in Ihren vielseitig einsetzbaren SoCs. Damit können die Einplatinencomputer Anwendungen wie Videoverarbeitung mit Videocodierung oder Videodecodierung, DSP-Funktionen, Betriebssystemfunktionen aber auch beschleunigte Machine Learning Funktionen abdecken. Die im SoC und auf der Platine vorhandenen Bussysteme sind für die Kombination aus den verwendeten Verarbeitungseinheiten optimiert. Ein Schwachpunkt von Einplatinencomputer ist dagegen der Durchsatz und die Latenzzeit für High-End-Anwendungen.

FPGAs und FPGA-SoCs

Wer benutzerspezifische Algorithmen mit hohem Durchsatz und niedriger Latenzzeit implementieren muss, ist bei FPGAs bestens aufgehoben. Sie sind je nach Stückzahl preisgünstiger als ASICs und in Ihrer Funktion (auch Konfiguration genannt) nachträglich anpassbar. Sie können in Kombination mit DDR-Speichern und geeignetem Zugriff auf USB- oder PCIe-Schnittstellen, neben hochperformanter Datenverarbeitung, zusätzlich die Datentransportfunktionen eines eingebetteten Systems übernehmen (siehe Punkt 4). Möchte man zusätzlich leistungsfähige Softwarefunktionen oder Betriebssysteme integrieren so sind die FPGA-SoCs interessant, welche klassische FPGAs mit Prozessorsystemen kombinieren.

Adaptive Compute Acceleration Platform (ACAP)

ACAPs sind eine Weiterentwicklung von FPGA-SoCs und bilden eine höchst flexible Beschleunigungsplattform für verschiedenste Arten von Berechnungen. Dabei kombinieren ACAPs die SoC-Software-Funktionen, einen Bereich mit optimierter programmierbarer Logik (ähnlich der klassischen FPGAs) mit einer speziellen Engine für hochperformante DSP-Funktionen und Machine Learning Funktionen. Alle Einheiten werden zusätzlich durch ein Network-on-Chip (NoC) miteinander verbunden, um den Datentransfer zwischen den Einheiten ausreichend leistungsfähig zu gestalten.

4. Innerhalb von FPGAs und FPGA-SoCs

Genau wie für Software gilt auch für FPGAs oder SoC-FPGAs, dass die Systemarchitektur innerhalb dieser Komponenten nicht vernachlässigt werden sollte. Wenn dies berücksichtigt wird, können flexiblere und leistungsfähigere Systeme entstehen, ohne dass es zu höheren Entwicklungsaufwänden oder Entwicklungskosten kommen muss. FPGAs sind schon lange nicht mehr nur als „Glue Logic“, zur Anbindung von ADCs, DACs, oder anderer Peripherien mit speziellen Schnittstelleneigenschaften, zu verstehen und können, wenn eingesetzt, das gesamte Rückgrat für den Datentransport innerhalb eines eingebetteten Systems bilden. Zur Verdeutlichung dieses Potentials zeigt die Abbildung 1 ein beispielhaftes eingebettetes System und dessen Komponenten, sowie zusätzlich die Architektur innerhalb des verwendeten FPGA 1.

Eingebettete Systemarchitektur basierend auf FPGAs
Abbildung 1: Eingebettetes System basierend auf FPGAs zur hochperformanten Video- und Signalverarbeitung

Es ist zu erkennen, dass das FPGA 1 des eingebetteten Systems 1 nicht nur die Datenvorverarbeitung für die peripheren Komponenten wie Bildsensoren, ADCs oder DACs übernimmt, sondern zusätzlich die prozessierten Ergebnisdaten in einem externen DDR-Speicher ablegen kann. Dazu nutzt das FPGA 1 ein internes Bussystem, welches höchst individuell sein kann und einen maßgeblichen Einfluss auf die Leistungsfähigkeit des FPGA-internen Systemarchitektur hat.

Eine externer µC oder ein externes SoC ist in die hochperformante und mit niedrigen Latenzzeitanforderungen versehene Datenverarbeitung und den Datentransport des FPGA nicht eingebunden. Diese Komponenten können sich mit ihrer flexiblen auf Software basierenden Datenverarbeitung auf die Steuerung und Einstellung aller Komponenten der eingebetteten Systeme 1 und 2 konzentrieren und haben ebenfalls Zugriff auf den gesamten DDR-Speicher. Der Zugriff auf alle eingebetteten Systeme wird dadurch ermöglicht, dass die internen Bussysteme aller eingebetteten Systeme über Brücken miteinander verbunden sind. Dies ist auf speziellem Weg sogar zwischen verschiedenen FPGAs, wie die Abbildung 1 durch die FPGA-Brücke zwischen FPGA 1 und FPGA 2 zeigt, möglich.

Weiterhin ist in Abbildung 1 zu erkennen, dass das Host-System (z.b.: ein PC) über ein dedizierten Bussystem (wie USB, PCIe oder Ethernet) mit den eingebetteten Systemen über das FPGA verbunden ist. Hier kann durchaus USB zum Einsatz kommen, denn es handelt sich um eine direkte Verbindung von nur einem Hop ohne zusätzliche USB-Hubs. Diese Verbindung kann durch die Brückenverbindung zum internen Bussystem unabhängig entwickelt werden und beeinflusst so die Entwicklung des eingebetteten Systems nur geringfügig. Die Brückenverbindung ermöglicht dem Host-System zusätzlich vollen Zugriff auf alle eingebetteten Systeme. Wenn dies nicht gewünscht sein sollte, so sollte eine Einschränkung nicht durch das Entfernen von Verbindungsbrücken geschehen, sondern beispielsweise durch eine Einschränkung bei der Bus-Arbitrierung oder durch das Sperren von Speicherbereichen.

Auf die in Abbildung 1 dargestellte Weise können FPGAs zu einer optimalen Ergänzung von eingebetteten Systemen genutzt werden. Wie üblich übernehmen die FPGAs zusätzlich die anwendungsspezifische Vorverarbeitung von Sensordaten oder implementieren eine individuelle Datenverarbeitung und erfüllen so Ihre Aufgabe als Hardware-Beschleuniger.