Integration von Autosar, IVI und Kombi-Instrumenten auf heterogenen SoCs

Heterogene Multicore-Systeme, das heißt Architekturen, die zwei oder mehr unterschiedliche Arten von Mikroprozessoren (MPUs) und/oder Mikrocontrollern (MCUs) kombinieren, gewinnen bei den Automobilherstellern und Tier-One-Zulieferern als Architektur der Wahl immer mehr an Bedeutung. Das schnelle Aufkommen dieser Systeme lässt sich auf mehrere Gründe zurückführen: auf die zunehmende Verwendung von Fahrzeugelektronik, auf die Notwendigkeit die Entwicklungskosten zu kontrollieren und gleichzeitig der Forderung nach mehr Komplexität nachzukommen, sowie auf die Möglichkeit, die Vorteile bei den großen Fortschritten bei Kfz-Halbeitern zu nutzen.

Moderne Fahrzeuge verfügen über eine Vielzahl elektrischer Systeme. Dazu gehören Nachtsichtgeräte, die Fußgänger beim Überqueren der Fahrbahn erkennen, moderne Sicherheitsprogramme, die das Auslösen von Airbags binnen Millisekunden gewährleisten, elektronische Stabilitätskontrolle und Antiblockiersysteme, Rückfahrkameras (und Sensoren), die dem Fahrer beim Erkennen kritischer Situationen helfen, und nicht zu vergessen das Anwender-Erlebnis, das IVI-Systeme (IVI: In-Vehicle Infotainment) heute bieten. Dabei ist es egal, ob das System mit einem Handheld-Gerät verbunden ist, ob darauf nur native Apps ablaufen oder ob es als Knoten für die neueste 4G/LTE-Wireless-Konnektivität dient. All diese Elektroniksysteme benötigen eine elektronische Steuereinheit (ECU). Wenn Entwickler beispielsweise ein IVI-Subsystem mit einem Kombi-Instrument kombinieren, dann stehen sie vor komplexen Konnektivitäts-Herausforderungen. Noch komplizierter wird es, wenn ein Subsystem mit niedriger Priorität eine ECU zusammen mit einem Subsystem nutzen muss, das als sicherheitskritisch eingestuft ist.

In diesem Beitrag geht es darum, wie neue ECU-Halbleiter-Plattformen die Integration voran getrieben haben und welche Rolle Autosar in der Entwicklung von Steuergeräten spielt.

Die zunehmende Verwendung von ECUs

Als Reaktion auf die verstärkte Nutzung von ECUs und die ständig wachsende Anzahl neuer Funktionsmerkmale bei aktuellen Fahrzeugen entwickeln Halbleiterhersteller aufwändige und anspruchsvolle SoC-Architekturen. Diese neuen Architekturen enthalten verschiedene Arten von Prozessorkernen mit hoher Kapazität, um die hochkomplexen und anspruchsvollen Aufgaben zu erfüllen. Bei den weltweit führenden Automobil-OEMs hat die Verringerung der Anzahl der Steuergeräte in einem Fahrzeug höchste Priorität. Premiumfahrzeuge enthalten heutzutage fast 100 ECUs. Dies wirkt sich auf die Herstellungskosten, die Kabelbaumverbindungen und die Teilebeschaffung aus. Ebenso gibt es eine Migration von 8- und 16-Bit-Anwendungsprozessoren hin zu Low-End-32-Bit-MCUs, die ein gutes Preis-/Leistungsverhältnis bieten und sich für komplexe Anwendungen in Fahrzeugen eignen.

Autosar

Die zunehmende Verwendung von ECUs erhöht die Notwendigkeit für Standardisierung und Konnektivität der Fahrzeugsysteme. Da sich die Hardware-Plattformen ändern, muss auch die Software neu entwickelt und unterstützt werden. Autosar macht einen außerordentlich guten Job bei der Definition einer Industriestandard-ECU-Architektur und der Bereitstellung einer konsistenten Designmethodik, die sich sowohl für OEMs als auch für Tier-One-Zulieferer eignet. Im Kern definiert Autosar eine Standard-ECU-Schnittstelle und erlaubt den Entwicklern, standardisierte, wieder verwendbare Softwareschichten und Komponenten zu spezifizieren, die in jedem Fahrzeugsteuergerät existieren können. Der Standard ist hardwareunabhängig, so dass sich eine klare Linie zwischen der Anwendungssoftware und der Hardwareplattform ziehen lässt, die als Host fungiert (Bild 1). Autosar unterstützt mehrere Bus-Technologien und bietet Fahrzeugentwicklern die Flexibilität, Flexray, CAN, LIN und Ethernet-Netzwerke miteinander zu verbinden. Zudem besteht die Möglichkeit, Netzwerke hierarchisch anzuordnen – beispielsweise mit Sub-Clustern mit einem Surround-Kameranetzwerk, das auf einem Ethernet-Netzwerk angeordnet ist, und Steuergeräte-Gruppen, die mit niedrigeren Datenraten arbeiten, zu denen auch die Türschlösser gehören, die noch auf traditionellen CAN-Bus-Clustern basieren.

Bild 1: ECU mit und ohne standardisierte Autosar-Schichten.Mentor Graphics

Mit der steigenden Komplexität der Subsysteme wächst auch die Komplexität des Autosar-Standards. Die aktuelle vierte Generation umfasst über 60 verschiedene ECU-Typen. Autosar-basierte Steuergeräte erfüllen die ASIL-Sicherheitsanforderungen für die wichtigsten Fahrzeugkomponenten. Autosar-ECU-Software läuft in der Regel auf zuverlässigen Echtzeit-Betriebssystemen auf Basis der OSEK-Spezifikationen.

Von Singlecore- über Multicore-Designs…

In Fahrzeugen gibt es heute viele verschiedene Funktonen, die sowohl Singlecore- als auch Multicore-Prozessorarchitekturen enthalten. Singlecore-Designs eignen sich für Embedded-Systeme, bei denen nur eine Funktion erforderlich ist. Ein Fahrzeug kann auch mehrere Designs enthalten, welche die Rechenleistung von Multicore- oder Grafikprozessoren (GPUs) erfordern. Das Display eines Kfz-Kombi-Instruments oder ein IVI-System sind typische Anwendungen, die die Vorteile moderner Multicore-Plattformen nutzen. Für Fahrzeuge mit Single- und Multicore-SoCs gibt es eine Reihe von Anwendungsfällen: Im ersten Anwendungsfall verfügt jedes SoC über sein eigenes Betriebssystem oder seine eigene Betriebsumgebung, die mit Werkzeugen entwickelt wurde, die für diese Betriebsumgebung konzipiert und für spezielle Anwendungen implementiert wurden.

Im zweiten Anwendungsfall enthält jedes SoC einen Mix aus diskreten Prozessoren, wobei diese Prozessoren in der Regel unterschiedlich sind.Die Art der Anwendung bedingt die Prozessorauswahl. Diese reicht von Low-end-Mikrocontrollern bis zu High-End-Anwendungsprozessoren. Jeder Benutzer des Systems besitzt all die Hardware, die für die Komponenten verfügbar ist. Beispiele für diese Hardware sind Prozessoren, Grafikverarbeitungseinheiten, Speicher, I/Os, Cache und Ähnliches.

Im dritten Anwendungsfall sind die diskreten Komponenten des Systems üblicherweise lose verbunden. Jede Komponente bootet unabhängig und kommuniziert mit anderen mithilfe von Nachrichten über einige physikalische Verbindungen. Die einzelnen Systemkomponenten hängen nicht voneinander ab; sie müssen nur miteinander kommunizieren, sobald sie gebootet haben und zur Kommunikation bereit sind.

Bild 2: Das SoC OMAP5432 von Texas Instruments – von Multicore bis zu heterogenen Umgebungen.Mentor Graphics

… bis zu heterogenen Designs

Um die Konsolidierung der Elektronikumgebung in Automobilen zu unterstützen, haben die Halbleiterhersteller komplexe SoC-Architekturen entwickelt, die heterogene Kerne und andere Geräte kombinieren. Das Kfz-Ökosystem ist ein gutes Beispiel dafür, wie die komplexe Funktionalität von diskreten Geräten auf einem heterogenen Multicore-SoC vereinigt werden kann, Ein Beispiel für ein solches SoC ist der OMAP5432 von Texas Instruments (Bild 2), der zwei Anwendungsprozessoren des Typs ARM-Cortex-A15 enthält.

Zusätzlich zu diesen verschiedenen Prozessorkernen gibt es auf den SoCs auch viele andere Komponenten einschließlich Speicher, Cache-Speicher, I/Os, Sicherheitsfunktionen und vieles mehr. Dies sind die SoC-Architekturen, die eine Zusammenlegung erlauben und es den Automobil-OEMs gestatten, auf den globalen Wettbewerbsdruck zu reagieren.

Heterogene Multicore-SoCs

Die bisher beschriebenen Domänen beinhalten mehrere Elektronikkomponenten sowie die Kommunikation zwischen ihnen. Aufgrund der größeren Verarbeitungskapazitäten und engeren Integration sind modernere Entwicklungstechniken für das Hardware- und Software-Design erforderlich. Mentor Graphics hat deshalb eine entsprechende Lösung entwickelt. Diese bietet eine umfassende Reihe kommerzieller Laufzeitumgebungen, Werkzeuge für die heterogene Multicore-Entwicklung sowie die Option, den Autosar-Standard zu integrieren. Ein Beispiel für solch eine SoC-Umgebung ist die heterogene Multicore-Plattform Jacinto-6 von Texas Instruments (Bild 3).

Bild 3: Kombination verschiedener Domänen auf heterogenen Multicore-SoCs.Mentor Graphics

Herausforderungen bei der Entwicklung heterogener SoCs

Wenn sich Projekte von der diskreten Entwicklung lose gekoppelter Systeme in Richtung einer integrierten heterogenen Umgebung bewegen, ist wahrscheinlich mit großen Entwicklungsherausforderungen zu rechnen. Diese treten in der Regel nicht während der Entwicklung diskreter Komponenten auf, da die Entwickler hier in der Lage sind, innerhalb der Grenzen ihres eignen Geräts zu designen, zu entwickeln, zu testen sowie zu optimieren und sie nur die Kommunikationsschnittstellen mit anderen Teilen des Systems entwerfen und testen müssen.

Durch die heterogene Konsolidierung entsteht eine Reihe neuer Herausforderungen, denen sich Embedded-Entwickler stellen müssen. Dazu gehören die Aspekte Systemarchitektur, Konfiguration, Booten, Debugging, Trennung, gemeinsame Nutzung von Geräten, Interprozessor-Kommunikation und Sicherheit.

Systemarchitektur

Auf Grund der vielen heterogenen Kerne auf einem SoC gibt es mehrere Möglichkeiten, um Betriebssysteme und Anwendungen den nun verfügbaren und möglicherweise gemeinsam nutzbaren Prozessorkernen, GPUs, Speichern, I/Os und anderen Ressourcen zuzuweisen. Entwickler müssen eine Architektur finden, die alle Systemanforderungen optimal erfüllt.

Konfiguration

Die Architekten müssen aber nicht nur über das Layout des Systems nachdenken, sondern sie benötigen auch einen Weg, um das System zu konfigurieren. Oft funktioniert die anfangs vorgeschlagene Architektur nicht in der von den Architekten erwarteten Art und Weise. Deshalb müssen Entwickler in der Lage sein, das System schnell neu zu konfigurieren und festzustellen, ob die Systemanforderungen erfüllt werden können. Die Konfiguration kann ein manueller und langsamer Prozess sein, der wertvolle Entwicklungszyklen vergeudet.

Booten

Im diskreten Anwendungsfall bootet jede Betriebsumgebung auf ihrer eigenen Hardware. Bei heterogenen Multicore-Designs, wo mehrere Betriebssysteme meist in einer bestimmten Reihenfolge gebootet werden müssen, benötigt der Entwickler einen Rahmen und eine Methode, um unterschiedliche Teile eines Systems auf eine koordinierte Art und Weise gemäß den Systemanforderungen und unter Berücksichtigung der Gemeinsamkeiten der Hardware auf dem SoC hochzufahren. In einer Kfz-Umgebung muss der CAN-Bus üblicherweise innerhalb von 50 ms „wach“ sein, sodass er auf einen Low-Power-Kern gehostet werden kann. Bei leistungsstärkeren Kernen, die als Host für ein Infotainment-System dienen, kann das Booten länger dauern.

Debugging

Bei der Konsolidierung von Systemen müssen Entwickler und Tester einen Weg finden, um das System als Ganzes darzustellen. Sie müssen nicht nur verstehen, wie jedes Betriebssystem und jede Anwendungsumgebung funktioniert, sondern auch, wo es möglicherweise Konflikte mit gemeinsamen Ressourcen oder eine Sättigung von Prozessen, Bussen oder Geräten gibt. Außerdem müssen sie einen Weg finden, um zu sehen, wie das Verhalten in einem Teil des Systems das Verhalten in einem anderen Teil beeinflusst oder von diesem beeinflusst wird. Entwickler brauchen eine Möglichkeit, um die Gesamt-Performance des Systems zu optimieren.

Trennung

Der Designer muss eine gewisse Sicherheit haben, dass beim Ausfall eines Teils des Systems aufgrund schlechter Programmierung oder Vorsatz die anderen Teile des konsolidierten Systems nicht beeinträchtigt werden oder dass das gesamte System nicht gefährdet wird oder abstürzt.

Gemeinsame Nutzung von Geräten

Wenn zahlreiche Betriebssystemumgebungen und Anwendungen auf einem einzigen System integriert sind, kann die unterstützende Hardware begrenzt sein, was die gemeinsame Nutzung der Hardware-Ressourcen erforderlich macht. Architekten und Entwickler brauchen einen Weg, um diese Hardware auf eine Weise zu teilen, die gewährleistet, dass individuelle Funktionen nicht beeinflusst werden.

Interprozessor-Kommunikation (IPC)

Die Integration vieler Anwendungen auf einem SoC erfordert es, dass diese Anwendungen miteinander und mit dem System kommunizieren. Angesichts der Heterogenität der konsolidierten Systeme ist ein IPC-Framework notwendig, das sich über verschiedene Anwendungen skalieren lässt. Dies schließt Open-Source-Software und proprietäre Softwareumgebungen mit ein, bei denen der Schutz von IP von größter Bedeutung ist. Wenn ein Kombi-Instrument und ein Infotainment-System gemeinsam ein SoC nutzen, können beide Domänen gemeinsam über eine sichere Kommunikationsverbindung wie VirtIO oder RPMsg beispielsweise Informationen wie die Fahrzeugposition und Geschwindigkeit nutzen.

Sicherheit

Mit diskreten Architekturen können Systemarchitekten eine separate Funktion in ein Embedded-Gerät integrieren, die es mit der Außenwelt verbindet und alle böswilligen externen Angriffe vom Rest des Systems isoliert. Bei der Integration lassen sich diese Sicherheitsfunktionen auf einem heterogenen Multicore-SoC zusammenfassen. Die gemeinsame Natur der Hardware und anderer Geräte auf dem SoC schafft jedoch zusätzliche Möglichkeiten für Angriffe. Da drahtlose Kommunikationsmedien wie Bluetooth und Wi-Fi zunehmend in Fahrzeugen zum Einsatz kommen, erhöht sich die Anzahl der potenziellen Zugangspunkte für Denial-of-Service-Attacken.

Schlussfolgerung

Von Business-Trends, der Konsolidierung von Systemen und der Verfügbarkeit neuer Hardware angetrieben, sind heterogene SoC-Architekturen nicht mehr wegzudenken. OEMs, Gerätehersteller und Entwicklungsteams müssen an einem Strang ziehen. Dieser Trend zu heterogenen Systemen zieht zweifelsohne auch die Einführung neuer Entwicklungsmethoden nach sich.

(av)