Eckdaten

Bei der weiteren Entwicklung von Fahrerassistenzsystemen werden offene Plattform-Architekturen eine wichtige Rolle spielen. Mit der Middleware setzt TTTech auf die Weiterentwicklung bestehender Konzepte und Architekturen hin zu Fail-operational-Plattformen für autonomes Fahren.

Moderne Autos müssen eine ständig steigende Zahl an elektronischen Funktionen in allen Fahrzeugdomänen bieten. Dazu zählen solche wie ADAS (Advanced Driver Assistance Systems), Infotainment, Fahrzeugdynamik und Hybrid- oder Elektroantriebe. Die Zeiten, in denen für jede neue Kunden-Funktion ein weiteres Steuergerät (ECU) hinzugefügt wurde, sind aufgrund von Mehrkosten, aufwendigerer Verkabelung und Einschränkungen beim Packaging vorbei. Deswegen geht der Trend immer stärker in Richtung Modularisierung von automotiven elektronischen Systemen und der Implementierung von neuen Funktionen auf Softwareebene. Das senkt die Zahl der ECUs oder lässt sie zumindest nicht weiter wachsen.

Parallel zu diesem Trend lässt sich auch eine Veränderung der Zulieferkette und verschiedener Kooperationsmodelle beobachten. Bisher lieferte fallweise ein einzelner Tier1-Zulieferer ein komplettes „Closed-box“-System. Das ist angesichts der extrem hohen Komplexität im Bereich ADAS jedoch kaum mehr möglich, weil ein einzelner Lieferant nicht mehr alle Bereiche als „best in class“ abdecken kann. Deshalb setzen die OEMs zunehmend auf die besten Zulieferer für Einzelelemente wie Sensoren und deren Verarbeitungssoftware, ECU-Hardware und Plattform-Software, Applikationen und Aktuatoren. Aus einer Vielzahl an Tier1- und Software-Lieferanten wählt man die besten aus und integriert das Komplettsystem entweder selbst oder mit Partnern.

Bei High-end-ADAS-Systemen steht die Fusion verschiedener Assistenzsysteme im Mittelpunkt .

Bei High-end-ADAS-Systemen steht die Fusion verschiedener Assistenzsysteme im Mittelpunkt . TTTech Computertechnik

Trend zur offenen Architektur

Beide Trends führen zur Entstehung von zentralen Domänen-ECUs, die auf offenen Plattform-Architekturen basieren. So führt zum Beispiel in der ADAS-Domäne die Anforderung optimaler Sensordatenfusion naturgemäß zu einer zentralen Fusion und einer Reihe von darauf basierenden Funktionen. Offene Plattformen sind notwendig, um die Wiederverwendung von Funktionssoftware in mehreren verschiedenen Automodellen zu ermöglichen, was umgekehrt wiederum notwendig ist, um die hohen Kosten und Aufwände für die Funktionsvalidierung besser und breiter verteilen zu können.

Aufgrund dieses veränderten Zusammenarbeitsmodells und der dramatisch angestiegenen technischen Komplexität erhält in diesem Szenario die neue Rolle des Software-Integrators völlig neue Bedeutung. Darüber hinaus sind die Anforderungen an die Domänenarchitektur, die Softwareplattform und den Integrationsprozess um ein vielfaches höher als bei traditionellen ECUs.

Wunsch nach weniger ECUs

Die Fahrzeughersteller (OEMs) müssen sich mit der Tatsache auseinandersetzen, dass bisher eingesetzte Mikrocontroller die Anforderungen von ADAS hinsichtlich Rechenleistung und Speicherkapazität kaum mehr erfüllen können. Zumindest theoretisch sind zwar fast alle neuen ADAS-Funktionen auch in diskreten Lösungen darstellbar, dem steht aber der Wunsch nach weniger ECUs an Bord entgegen. Die Integration weiterer ECUs ist indes aufwendig und erhöht die Komplexität des Bordnetzes. Insbesondere der Aufwand für sicherheitsrelevante Funktionen steigt sprunghaft an. Deshalb ist die Hochintegration an Stelle verteilter Netzwerke sowie der Einsatz von Domänensteuergeräten immer mehr im Fokus der OEMs. Das gilt derzeit insbesondere für die Bereiche Entertainment/Infotainment, ADAS und Chassis Control/Body Control. Weitere Domains, bis hin zum im Automobil verbauten Server, werden in Zukunft folgen. Mit dieser Entwicklung gehen weitere Trends beziehungsweise Notwendigkeiten einher: Die Backbone-Kommunikation für zuverlässigen Datenverkehr zwischen den ECUs gewinnt enorm an Bedeutung und die sichere Intra-ECU-Kommunikation wird wichtiger. Extrem hochleistungsfähige Multicore-SoCs, die bisher im Automobil eher unüblich waren, kommen zum Einsatz, und auch diese verlangen nach entsprechender Vernetzung.

Die SWC-Lieferanten integrieren und testen die verschiedenen Applikationen individuell im Rahmen der vorgegebenen Grenzen.

Die SWC-Lieferanten integrieren und testen die verschiedenen Applikationen individuell im Rahmen der vorgegebenen Grenzen. TTTech Computertechnik

Auf Grundlage der bisher gewonnen Erfahrungen mit sicheren vernetzten Echtzeitsteuerungen für Luftfahrt-, Industrie- und Automobilanwendungen hat TTTech einen zentralen Ansatz zur Hochintegration aller ADAS-Funktionen gewählt und weiterentwickelt. Das Ergebnis ist eine Plattform-ECU mit der Bezeichnung TTA-Drive, die verschiedene Fahrerassistenzfunktionen aufnehmen und gleichzeitig höchste Sicherheitsstandards garantieren kann.

Middleware für Plattform-ECU

Diese Architektur ist sehr gut skalierbar. Je nach Anzahl und Leistungsbedarf der vollständig voneinander isoliert eingesetzten Applikationen lässt sich die Ausstattung mit unterschiedlichen Multi-Core SoCs entsprechend dem tatsächlich benötigten Ressourcenbedarf anpassen. Die SoCs können auch nebeneinander mit verschiedenen Betriebssystemen, wie Autosar, VxWorks, Linux und ähnlichen, laufen.

Das Herzstück der Plattform-ECU ist die von TTTech entwickelte Middleware TTIntegration. Sie sorgt für die Abstraktion der Hardware in Richtung der einzelnen Applikationen. Diesen sind entsprechend ihren Maximalanforderungen genau definierte und feststehende Ressourcen wie Speicher, CPU-Zeit und andere zugeteilt. Da die Mikrocontroller-Hardware von den Applikationen entkoppelt ist und zudem auf allen Betriebssystemen ein Autosar-Interface bereitgestellt wird, lassen sich die Applikationen auch beliebig zwischen den Embedded Cores verschieben.

Die Middleware gewährleistet unter anderem die Partitionierung, das heißt die strikte Zuteilung von Systemressourcen an die einzelnen Applikationen, ohne jede Überschneidungsmöglichkeit, die gleichzeitige Berücksichtigung unterschiedlicher ASIL-Sicherheitslevels (A bis D), die jederzeit klare Nachvollziehbarkeit von Datenherkunft und Datenfluss für den Systemtest sowie die jederzeit volle Location Transparency, das heißt Funktionen lassen sich zwischen CPU-Kernen dank Entkopplung der Datenverwendung von der Datenherkunft verschieben.

Vom Entwicklungsbeginn der Plattform an standen Verbesserungen gegenüber den herkömmlichen, häufig ereignisgesteuerten ECU-Konfigurationen im Fokus, insbesondere mit Blick auf die Testbarkeit und Integration. So bietet die Plattform eine Reihe von Vorteilen wie beispielsweise die Beobachtbarkeit jeder einzelnen Funktion über das Intra-ECU-Ethernet-Netzwerk, die wesentlich verbesserte Testbarkeit und die effiziente Integration durch ein stabiles deterministisches Integrationsverhalten. Auch die Co-Simulation von Funktionen am PC und das Datalogging auf Funktionsebene sind möglich.

Der Integrationsprozess

Diese Vorteile und das Prinzip der Partitionierung auf Softwareebene tragen aus mehreren Gründen zu einer Zeit- und Kostenersparnis bei der Integration bei. Es müssen sich nicht alle Applikationen zur gleichen Zeit auf der gleichen Entwicklungsstufe befinden, und daher muss man auch nicht das Erreichen bestimmter Meilensteine abwarten, wie es bei der sequenziellen Integration von Applikationen der Fall ist, häufig auch noch auf einer provisorischen Hardware ohne konfigurierte Execution Frames.

Durch den deterministischen Ansatz bei der TTTech-Lösung lässt sich das Zeitverhalten wesentlich früher als bei anderen Architekturen vorgeben und bestimmen, weil diese Lösung zeitliche Eigenschaften bereits von Anfang an integriert und nicht wie sonst üblich aus dem dann bereits fertigen System herausmessen und überprüfen muss. Gerade Letzteres führt oft zu einem unvorhersehbaren Aufwand bei der Fehlersuche im Nachhinein. Auch das oft praktizierte Optimieren, um mit den vorhanden Ressourcen in Bezug auf Rechenleistung und Speicher auszukommen, führt zu einem unkalkulierbaren Personal- und Kostenaufwand. Im Unterschied dazu wird die TTTech-Plattform-ECU von vornherein so vorkonfiguriert, dass jeder Applikationslieferant bei der Integration bereits in genau dem Bereich innerhalb der konfigurierten Execution Boundaries und mit genau den Systemressourcen arbeitet, die später auch in der fertiggestellten ECU für die jeweilige Applikation zum Tragen kommen werden. Der Projektrahmen und die Systemressourcen (Rechenzeit, Speicher, Stack, I/O) sind also bereits im Vorfeld definiert und konfiguriert.

Die unterschiedlichen Funktions-Lieferanten können ihre Anpassungen und die Integration gleichzeitig und völlig unabhängig voneinander vorantreiben. Zusätzlich ist eine PC-Co-Simulation vorgesehen, die weitere Zeitersparnis bedeutet. Durch die Definition durchgängiger Tools und Prozessketten werden die Aufwände überschaubarer und besser planbar. Durch die zeitliche und räumliche Entkoppelung der Applikationen ergibt sich auch automatisch Rückwirkungsfreiheit, was den Aufwand für Test und Fehlersuche noch weiter reduziert.

Der Lieferant einer Applikation, der eine Funktion fertig entwickelt hat, übergibt diese an den Systemintegrator als Object Files. TTTech übernimmt diese Rolle als Integrator bereits bei einer Reihe von Projekten, aber auch andere Dienstleistern können diese Rolle auf Basis der TTTech-Plattform wahrnehmen. Mithilfe des von der Plattform zur Verfügung gestellten Pre-Integration-Environments werden für jede Funktion in Isolation, das heißt gegen Simulationsmodelle, vielfältige Testvektoren (Inputs und erwartete Outputs) und Test Reports erstellt. Der Systemintegrator führt dann alle Funktionen auf der finalen Hardware mit den erhaltenen Testvektoren aus und stellt sicher, dass die Funktionen nicht nur einzeln, sondern auch gemeinsam auf der Plattform wunschgemäß funktionieren.

Die wichtigsten Vorteile der eingesetzten Middleware TTIntegration, die eine Klammer über verschiedene SoCs und Betriebssysteme bildet, sind die Verbindung von Safety und High Performance, die Konformität zu Standard-SW (Autosar), die Wiederverwendung bestehender SW-Komponenten und ein definierter und in punkto Aufwand genau planbarer Integrationsprozess. Hinzu kommt ein Serviceangebot von TTTech, das Planung, Consulting und Erstellung der Plattform, umfangreiches Tooling und Integration, Maintenance und SW-Releases umfasst.

Deterministisches Ethernet

Ein weiterer Grundpfeiler des Plattformsteuergerätes TTADrive ist neben TTIntegration der Einsatz von deterministischem Ethernet. Die zuverlässige und echtzeitfähige Ethernet-Backbone-Lösung ermöglicht einerseits den Datenaustausch zwischen den einzelnen SoCs innerhalb der ECU und andererseits auch die Kommunikation zur Simulationsumgebung und die PC-basierte Funktionsentwicklung. Dabei ist auch ein Datenaustausch zwischen den einzelnen Funktionen mit unterschiedlichen Sicherheits- und Echtzeitanforderungen möglich. Die verfügbare Bandbreite ist in drei Kommunikationsklassen unterteilt: Neben Standard-Ethernet-Traffic als Best Effort stehen auch AVB-/TSN-Streaming-Kommunikation sowie zeitgesteuerte Kommunikation für harte Echtzeitanforderungen zur Verfügung. Die dritte Kommunikationsklasse nutzt man in der ECU für alle sicherheitsrelevanten Echtzeit-Funktionen.

Die Aufwände zur Absicherung der Echtzeitkommunikation für Standard-Ethernet sind sehr hoch, dagegen sind beim deterministischen Ethernet die höchstmöglichen Echtzeitgarantien bereits per Design gegeben.

Die Aufwände zur Absicherung der Echtzeitkommunikation für Standard-Ethernet sind sehr hoch, dagegen sind beim deterministischen Ethernet die höchstmöglichen Echtzeitgarantien bereits per Design gegeben. TTTech Computertechnik

Funktionssicherheit

Die vielfältigen Eingriffsmöglichkeiten moderner Fahrerassistenzsysteme bringen eine stetig wachsende Abhängigkeit von der Verlässlichkeit des elektronischen Systems mit sich. Während heute beim Ausfall eines Assistenzsystems der Fahrer stets in der Regelschleife und letztendlich in der Verantwortung bleibt, wird das beim künftigen autonomen Fahren anders sein. Neben der ISO-26262-konformen Sicherheit des Systems muss unter allen Umständen auch die Verfügbarkeit zumindest von Teilfunktionen gewährleistet sein. Das gilt insbesondere, wenn während der Fahrt kein einfacher, beispielsweise durch eine Abschaltung erreichbarer, sicherer Zustand erreichbar ist und eine Fortsetzung des Betriebs auch im Fehlerfall unbedingt erforderlich ist. Eine solche Auslegung ist etwa in der modernen Luftfahrt zum Beispiel in Fly-by-wire-Systemen schon länger etabliert.

Solche Fail-operational-Systeme sind im automotiven Bereich heute noch selten, da bisher die aktuellen Fail-silent-Systeme, kombiniert mit dem Vorhandensein eines mechanischen Backups, meist ausreichen. Fail-operational-Systeme erfordern ein bestimmtes Maß an Redundanz in der System-Auslegung, um die Funktion trotz eines aufgetretenen Einzelfehlers weiterhin erfüllen zu können. Ein intelligentes Konzept dazu lässt sich auch als Weiterentwicklung bestehender Konzepte in einer automotiven Kostenstruktur umsetzen.

Design-Entscheidungen

Die System-Design-Entscheidungen, die bisher meist nach dem Motto „im Fehlerfall abschalten“ erfolgten, sind zu überdenken. Dabei stehen meist zwei diametral entgegengesetzte Systemreaktionen zur Wahl. Wie bei bisherigen und als sicher eingestuften Fail-silent-Design-Ansätzen lässt sich im Fehlerfall durch eine einfache Abschaltung der sichere Zustand einnehmen. Umgekehrt kann man natürlich zu Gunsten der Verfügbarkeit versuchen, den Betrieb mit voller Funktionalität (fail-operational) aufrecht zu erhalten. Diese erhöhte Verfügbarkeit führt indes stets zu einer höheren Komplexität des Systems. Als dazwischenliegende Lösung kann man im Fehlerfall auch in einen Degraded Mode wechseln, sodass sich eine Teilfunktion aufrecht erhalten lässt. Auch hier ist aber die Komplexität höher als beim Fail-silent-Ansatz.

Ist ein Fail-operational-Ansatz zwingend erforderlich, sind die Sicherheitsziele mit den Verfügbarkeitsanforderungen zu vereinen und die entsprechende System-Architektur muss sämtliche relevanten Fehlerfälle beherrschen. Sehr wichtig sind dabei die Common Cause Failures, also jene Fehler, die trotz vorgesehener Redundanzen zu einem Ausfall auf Grund einer gemeinsamen Ursache führen können, wie etwa Unterbrechung der Versorgungsspannung, Clock-Ausfall oder Kommunikationsausfall.

TTTech treibt derzeit mit Hochdruck die Weiterentwicklung bestehender Konzepte und System-Architekturen hin zu Fail-operational-Plattformen für autonomes Fahren in mehreren Projekten mit verschiedenen Endkunden voran. Erste Serienanwendungen sind für 2020 in unterschiedlichen Fahrzeugmodellen geplant.