Das neue ECU-Design basiert auf der Zynq-7000 Extensible Processing Plattform von Xilinx. Sie kombiniert einen ARM-Dual-Core-Prozessor des Typs Cortex-A9 MPCore und einen programmierbaren 28-nm-Xilinx-Logikbaustein der Serie 7 mit partieller dynamischer Rekonfigurierbarkeit. Die FPGA-Plattform erfüllt die Anforderungen im Automobilbereich, da sie auch die gebräuchlichen Kommunikations-Controller für CAN und Ethernet auf dem Chip enthält.
Die durch Autosar und den Sicherheitsstandard ISO-26262 etab-lierte Software-Architektur für ECUs involviert hohe Komplexität. Deshalb erfordert sie leistungsfähige Embedded-Prozessor-Plattformen. Derzeit basieren typische ECU-Implementierungen auf 32-bit-Single-Core-Prozessoren oder –Mikrocontrollern (MCUs), wobei erkennbar ist, dass Lösungen mit einem Kern in der Rechenleistung nicht ausreichen. Doch Multicore-CPUs verschlechtern unter Umständen die Performance, wenn diese per Arbitration auf Programm- und Datenspeicher über einen Multiprozessor-Bus zugreifen. Das macht die Lösungen über-komplex.
Bild 1 zeigt, wie sich eine MCU-basierte ECU-Architektur auf eine FPGA-basierte EPP-Architektur (Extensible Processing Platform) portieren lässt – mit klarer Partitionierung der Schichten. Unter der RTE (Autosar Runtime Environment, Autosar-Laufzeitumgebung) liegen Betriebssystem (OS), Speicher-, Kommunikations- und I/O-Stack etc., darüber die Software-Applikationen. Die hier gezeigte Alternative basiert auf programmierbarer Logik. Sie besteht aus einem Single-Core-Prozessor als Host mit intelligenter Peripherie wie Coprozessoren oder Slave-Prozessoren. Alle Einheiten lassen sich in FPGAs als Soft-Core-Prozessoren wie PicoBlaze und MicroBlaze von Xilinx realisieren. Sie arbeiten mit eigenem Code aus dedizierten RAM-Blöcken des FPGA oder maßgeschneiderten Hardware-Beschleunigern. Die Topologie ist immer eine Host-CPU mit smarter Peripherie, die CPU-Aufgaben übernimmt. Ergebnis: geringere Komplexität.
Somit verwaltet die Host-CPU den APP-Layer in Software, während die kundenspezifischen Peripherie-Einheiten den BSW-Layer darstellen. Sie sind parallel und autonom, und sollten die Ausführung der Software in der Host-CPU linearisieren – und zwar ohne exzessive Interrupt-Anforderungen der Peripherie über Interrupt-Service-Routinen (Bild 2).
Mehr I/Os
Mit der Komplexität von ECU-Plattformen wächst die Zahl der I/O-Verbindungen im System. Hier ist ein FPGA mit meist weitaus mehr Anschlüssen definitiv im Vorteil gegenüber einem Mikrocontroller. Gerade dies ist bei Steuergeräten auf Mikrocontroller-Basis relevant, denn sie müssen die Ein- und Ausgänge über externe digitale Schieberegister oder Analog-Multiplexer bedienen und die parallele/serielle Datenwandlung übernehmen. Ein FPGA umgeht diese Satellitenkonstellation und reduziert den Materialaufwand (BOM) ebenso wie die PCB-Fläche.
In führenden FPGAs sind A/D-Wandler bereits enthalten. Das ist gerade im Automotive-Design interessant, da viele ECUs mit analogen Signalen (zum Beispiel Batteriespannung) arbeiten, um einen Teil der benötigten Funktionalität zu implementieren. Die ADCs eröffnen FPGAs somit neue Anwendungsfelder.
Wie Mikrocontroller bieten auch FPGAs die Fähigkeit zum Remote-Update. Dabei gilt, dass sich der in das FPGA geladene Bitstrom nicht nur auf den Software-Code bezieht, sondern auch auf die Hardware-Konfiguration.
So lässt sich das Hardware-Design eines Produkts immer noch ändern, auch wenn es bereits im Einsatz ist – in diesem Fall über System-Updates oder Upgrades. Gerade die Automobilindustrie weiß solche Flexibilität zu schätzen, da sie Bug-Fixing erlaubt, auch wenn das Produkt bereits auf der Straße rollt.
Safety
In jeder ECU, die sicherheitsrelevante Funktionen nach ISO-26262 ausführt, muss die Hard- und Software ein gewisses Maß an Schutzfunktionen erfüllen, abhängig davon, wie diese kategorisiert ist. Für die Software muss Interferenzfreiheit nachgewiesen werden. Ein nicht sicherheitsrelevanter Code darf nicht die Funktion eines anderen, sicherheitsrelevanten Codes stören oder korrumpieren. Die gegenseitige Isolation soll die korrekte Ausführung von sicherheitsrelevanten und nicht sicherheitsrelevanten Funktionen auf demselben Prozessor garantieren. Oft ist das in programmierbarer Logik einfacher als mit MCUs.
In Automotive-Märkten mit größter Relevanz von Kosten und Leistungsverbrauch zählt besonders, dass programmierbare Logikbausteine wie der Zynq-7000 von Xilinx mehrere Funktionen unterstützen, die den System-Leistungsverbrauch verringern. Einige sind aus den MCUs übernommen, wie Sleep-Modus oder unabhängige Takt-Domains für die Peripherie. Dies senkt signifikant den Verbrauch, etwa im Leerlauf.
Eine attraktive Eigenschaft von FPGAs mit partieller Runtime-Rekonfigurierbarkeit ist die Fähigkeit zum Fault-Recovery durch die Verlagerung von Funktionen im Falle permanenter oder nicht reparierbarer Schaltungsfehler in einer spezifischen 2D-Position des FPGAs, etwa einer Logikzelle oder eines RAM-Blocks. Wird ein solcher Hardware- oder Software-Fehler identifiziert, lässt sich die benötigte Funktionalität automatisch in einen anderen Bereich derselben ECU, oder sogar einer anderen ECU, verlagern – unter Runtime-Bedingungen. Obwohl konzeptionell machbar, wird dies von den gegenwärtigen automatischen Tools nicht vollständig unterstützt.
Zeitmultiplex
Die wichtigste Charakteristik der Runtime-Rekonfigurierbarkeit in Automobilanwendungen ist zweifellos der durch die geteilten Hardware-Ressourcen mögliche Zeitmultiplex an Funktionalitäten. Das betrifft das Timesharing von Applikationen innerhalb einer ECU, die sich gegenseitig ausschließen. (Beispiel: Lane-Departure-Control, während das Fahrzeug geradeaus fährt, Rückwärtskamera beim Einparken.) Das reduziert die Kosten und Komplexität eingebetteter Systeme und spart Platz und Gewicht.
Doch die Idee trägt noch weiter: zur selbstständigen Adaption spezifischer Algorithmen bei der Änderung von Umgebungsbedingungen. So kann ein Algorithmus der Motorsteuerung mit partieller FPGA-Rekonfiguration bestimmte Hardware-Blocks adaptieren, um unter allen Temperaturbedingungen oder Batteriespannungen optimal zu arbeiten. Dieses Konzept gilt auch für Kommunikationssysteme, etwa für Krypto-Controller, die ihre Sicherheitsstufen als Funktion bestimmter Parameter unter Runtime-Bedingungen definieren. Ein weiteres Beispiel ist die Erstellung von ECC Coder/Decoder IP, die in störbehafteten Kommunikationskanälen Übertragungsfehler detektiert und korrigiert und die Hardware-Architektur mit dem aktuellen Signal/Rauschverhältnis dynamisch adaptiert.
Bild 3 zeigt ein ECU-System in einem Virtex-4-FPGA von Xilinx mit einer statischen und einer PR-Region. Die statische Region integriert einen Soft-Core-Prozessor des Typs MicroBlaze und einen ICAP-basierten Rekonfigurations-Controller. Der partiell rekonfigurierbare Teil übernimmt die Rolle einer geteilten Ressource zum Swap von funktionalen Tasks oder Applikationen zu unterschiedlichen Zeitpunkten.
Francisco und Mariano Fons
(av)