Dr. Stefan Poledna (links) im Interview mit AUTOMOBIL-ELEKTRONIK-Chefredakteur Alfred Vollmer: „Durch das autonome Fahren geht die Komplexität in eine komplett andere Dimension, wo es Netzwerke von Partnern mit unterschiedlichen Expertisen braucht.“ TTTech

(Bild: Alfred Vollmer)

| von Alfred Vollmer

AUTOMOBIL-ELEKTRONIK: TTTech hat sehr aktiv am Entstehen von Audis ECU für das Automatisierte Fahren ZFAS mitgewirkt. Welche Schwerpunkte gibt es dabei?

Dr. Stefan Poledna: Die Kernidee von ZFAS besteht darin, eine Anzahl von Steuergeräten zentralisiert in einer ECU zusammenzufassen. Dieses zentrale Steuergerät erfasst die Datenströme aller Sensordaten und fusioniert sie, um so Funktionen für automatisiertes Fahren wie Spurhalten, Abstandsregelung, Parken, Birds-Eye-View etc. zu realisieren. Durch die zentrale Auswertung der Sensordaten stehen dem Steuergerät viel mehr Informationen zur Verfügung, die durch das Fusionieren auch zuverlässiger sind. Die ZFAS-ECU von Audi ermöglicht es, fast 40 unterschiedliche Funktionen zusammenzufassen und fungiert als Host für diese Funktionen. TTTech war von Beginn an in die Architekturentwicklung eingebunden. ZFAS ist ja keine klassische ECU mehr mit einem Mikrocontroller und Peripherie, sondern ein Hochleistungs-Computersystem, das unterschiedliche Mikrocontroller, Hochleistungs-Chips zur Bildverarbeitung, Grafikverarbeitung mit GPUs, eine Vielzahl von ARM-CPU-Kernen mit hoher Rechenleistung und natürlich auch Safety-Controller wie den Aurix von Infineon enthält. Wir waren vom Start weg in die Architekturentwicklung wie auch in die prototypische Implementierung eng eingebunden, als dann die Entscheidung für die Serie fiel.

Dr. Stefan Poledna: „Wir sind der neutrale Integrationspartner, der die Verantwortung der Gesamt­integration trägt.“ TTTech

Dr. Stefan Poledna: „Wir sind der neutrale Integrationspartner, der die Verantwortung der Gesamt­integration trägt.“







Alfred Vollmer

Welches Geschäftsmodell lag dabei zugrunde?

Dr. Stefan Poledna: Wir haben für das System unsere Lösungen aus dem Bereich der Vernetzung und für das Safe-Computing – zum Beispiel für Fly-by-wire-Anwendungen im Luftfahrtbereich – als Ausgangsbasis herangezogen und in Kooperation mit Audi für die ganz spezifischen Herausforderungen des Autonomen Fahrens angepasst und weiterentwickelt. Nach der Entscheidung, ZFAS in die Serie zu bringen, haben wir dann bis in die B-Muster-Phase hinein auch die Hardware entwickelt.

In der Serie sind wir für die komplette Plattformsoftware, das Safety-Konzept der ECU und für die komplette Software-Integration zuständig. In der Integrationsphase ist es zentral, sowohl Hardware- als auch Softwarefehler zu erkennen. Nur wenn die Schnittstellen stimmen und die Komponenten in punkto Laufzeit, Speicher, Sicherheits- und Überwachungsfunktionen korrekt sind, funktioniert auch die ECU.

Auf Basis unseres Hintergrundwissens entstand unsere sichere Plattform-Software, die den Produktnamen Motionwise trägt. Motionwise ermöglicht die sichere und koordinierte Abarbeitung vieler unterschiedlicher Anwendungen und integriert die Kernfunktionalitäten von Betriebssystem, Diagnose, Kommunikation sowie aller Sicherheitsfunktionen.

Welche Technik steckt hinter Motionwise?

Dr. Stefan Poledna: Das Rückgrat des Steuergeräts bildet ein deterministisches Gigabit-Ethernet-Backbone, das die harte Echtzeit zwischen den Prozessorkernen abbilden kann. Alle Rechenkerne und die Betriebssysteme sind über Ethernet synchronisiert, um wirklich die gesamte Abarbeitungskette von den Sensoren bis zu einer Reaktion im System garantieren zu können. Diese deterministische Ethernet-IP ist ein von TTTech entwickeltes Produkt. Darüber hinaus wird auch PCIe unterstützt.

Die Infrastruktur nutzt dabei auch einen Mikrocontroller von Infineon, der unter Autosar Classic arbeitet; es handelt sich somit um ein sehr breites Ökosystem. Wie vielfältig und offen das Ökosystem ist, erkennt man bei einem Blick auf die Hardware-Elemente. Wir nutzen Infineon-Aurix-Mikrocontroller, FPGAs des Typs Cyclone 5 von Intel PSG, Prozessoren von Nvidia sowie ASSPs von Mobileye zusammen in einer ECU. Durch unsere Kooperation mit Renesas können wir aber auch Lösungen mit Renesas-MCUs realisieren. Auf der Softwareseite unterstützt Motionwise neben dem Autosar-Betriebssystem auch komplexe Betriebssysteme wie Linux, VxWorks, QNX oder andere. Die kommende Version von Motionwise wird auch Adaptive Autosar unterstützen.

Auf der nächsten Seite lesen Sie mehr über die Zusammenarbeit mit Delphi.

Das Seriensteuergerät liefert Delphi. Wie arbeiten Sie da zusammen?

Dr. Stefan Poledna: TTTech hat den Architekturprototypen des ZFAS bis in die B-Serien entwickelt. Hierzu gehörte auch die Wahl der Chips und Chipsets, Interfaces etc. gemeinsam mit Audi. An dieser Stelle hat Delphi die Verantwortung übernommen, die Hardware in die Serienentwicklung zu führen und zu industrialisieren.

Alle beteiligten Partner betreten hier Neuland, weil bisher die Safety-Steuergeräte immer aus einer Hand entwickelt wurden – Hardware und Software. Durch das autonome Fahren geht die Komplexität in eine komplett andere Dimension, wo es Netzwerke von Partnern mit unterschiedlichen Expertisen braucht. Es gibt nicht mehr „die“ Firma, die vom Lasersensor, Radarsensor, Kamera über die Verarbeitung dieser Sensordaten bis zur Park-Applikation und zur Bildverarbeitung sozusagen diese komplette Breite des ganzen Themas automatisiertes Fahren abdeckt. Dort arbeiten wir in Ökosystemen, in Partnerschaften zusammen, und das hat natürlich auch ein ganz anderes Modell der Zusammenarbeit beziehungsweise Entwicklung zur Folge. Wir sind dabei der neutrale Integrations­partner der die Verantwortung der Gesamtintegration trägt.

Inwiefern sind Sie dabei neutral?

Dr. Stefan Poledna: Wir sind neutral in dem Sinn, dass wir keine Applikationen wie die Parkfunktion, keinen Staupiloten, kein Birds-Eye-View, keine Sensoren oder ähnliches entwickeln. Wir sind auch neutral bei der Wahl des Mikrocontrollers – ob von Infineon, Renesas, Mobileye oder von anderen. Wir sind auch neutral in punkto Betriebssystem, ob jemand Vector-Autosar verwendet oder Linux oder vielleicht doch VxWorks. Wir stellen mit Motionwise eine sichere Plattform zur Verfügung, die es dem Fahrzeughersteller oder Tier1 erlaubt, sehr flexibel, skalierbar unterschiedliche Halbleiter und Betriebssysteme zu verwenden und obendrauf unterschiedliche Funktionen mit einem unterschiedlichen Sourcing zu integrieren. In diesem Sinn sind wir neutral und bringen alles auf Systemebene zusammen.

Was bedeutet das neue Modell der Zusammenarbeit für den OEM?

Dr. Stefan Poledna: Die OEMs schreiben nicht mehr ein Steuergerät aus und kaufen es ein, sondern sie agieren in einem komplexeren Ökosystem, in dem die besten SoCs, Sensoren und Softwarefunktionen integriert werden. Daraus erwachsen außerordentlich hohe organisatorische Anforderungen an die Supply-Chain, das Sourcing, den Integrationsprozess, den Support, das Testen und vieles mehr. Unsere Erfahrung hat gezeigt, dass diese Plattform dabei eine sehr wesentliche Rolle spielt, denn es geht darum, ein durchgängiges Konzept zu haben. Bei einer derart komplexen Systemausgangslage mit über 30 oder 40 Funktionen kommt es automatisch zu Situationen, in denen die eine Funktion schon fertig ausentwickelt ist, während andere noch sehr viel Entwicklungsaufwand benötigen.

Deswegen haben wir bei Motionwise einen Schwerpunkt darauf gelegt, dass über eine Ethernet-Schnittstelle ein Laptop oder PC verbunden werden kann. Motionwise ist auch auf PCs und Servern lauffähig, so dass der gleiche Source-Code parallel mit dem Embedded Target auch auf dem PC abgearbeitet werden kann; der PC stellt dabei so etwas wie eine Erweiterung der ECU mit zusätzlicher Rechenleistung dar. Damit wird ein wesentlich schnelleres Entwickeln oder Testen möglich. Die komplette Entwicklung, das Debugging, die Visualisierung und das Testen des Codes kann auf dem PC erfolgen; auf Knopfdruck läuft der Code dann auch im Embedded-Steuergerät. Der wesentliche Punkt ist die Durchgängigkeit in der Entwicklungskette, um die Prototypen-Entwicklungsphase mit der Integrationsphase im Sinne der agilen Methodik quasi zu verschmelzen.

Wie gehen Sie bei derart vielen Partnern und Funktionen mit eventuellen Problemen um?

Dr. Stefan Poledna: Es ist ein ganz zentrales Element, dass in der Plattform die gesamte Funktionalität für die Ablaufsteuerung und Überwachung integriert ist. Damit können die Ingenieure nicht nur feststellen, ob es Probleme gibt, sondern diese auch präzise lokalisieren. Motionwise unterstützt sehr viele Überwachungsmechanismen bezüglich Laufzeit, Speicherplatz und Stack, aber auch Safety-Funktionen, Schnittstellenüberwachungen etc. Damit lässt sich in der Integrationsphase sehr schnell die Ursache von Problemen finden.

Ohne diese Überwachungsmechanismen entsteht schnell eine Situation, in der über 20 Firmen behaupten, dass ihre voll getestete Funktion bestens funktioniert, obwohl die gesamte ECU nicht funktioniert. Dann stellt sich die Frage, wo mit dem Debugging beginnen? Deswegen haben wir noch zusätzlich sehr viel Tooling eingebaut, um mit Tracing, Logging, Monitoring etc. an dieser Stelle effizient zum Ziel zu kommen. Solche Tools existieren heute für Autosar-ECUs mit einem SoC, aber nicht für so komplexe ECUs wie ZFAS mit einem derart komplexen Innenleben. Hier betreten wir absolutes Neuland.

Auch in Bezug auf Skalierbarkeit betreten wir Neuland, wenn wir Software-Funktionen von einem Linux/POSIX-Umfeld auf ein Autosar-Umfeld verschieben wollen, ohne die Funktion zu portieren. Wir haben Motionwise daher so entwickelt, dass die Standard-RTE-Schnittstellen von Autosar auf allen Rechnern zur Verfügung stehen, um durchgängig die gleichen Interfaces zu haben. Im nächsten Release von Motionwise werden auch die Adaptive-Autosar-Interfaces unterstützt.

Thema auf der nächsten Seite: Testen, Validieren & Safety.

Wie bekommen Sie das Testen und Validieren in den Griff?

Dr. Stefan Poledna: Mit Software-in-the-Loop- und Hardware-in-the-Loop-Validierung ist die Plattform in der Lage, die ganzen Tests automatisiert abzuarbeiten; auf einer Serverfarm im Rack laufen dann möglichst viele Testkilometer parallel ab. Im Backend liegen die Szenariendaten vor, die systematisch durchlaufen werden. Damit bekommt das Thema Plattform eine viel breitere Bedeutung, weil sie für den gesamten Entwicklungsprozess vom beschleunigten Prototyping über die hocheffiziente Integration bis zur beschleunigten Validierung eine durchgängige Kette anbieten muss.

Die hierfür erforderliche Komplettlösung bündeln wir unter dem Namen Motionwise als eine offene Plattform – offen in Bezug auf unterschiedliche SOCs, MCUs und andere Halbleiter, aber auch offen in punkto Betriebssystem, weil wir die entsprechende Middleware-Funktionalität und das notwendige Tooling anbieten. Das Tooling berücksichtigt dabei auch Echtzeitanforderungen von Wirkketten, um zum Beispiel eine Notbremsung aus einer entsprechenden Sensor-Situation heraus durchführen zu können. Beim ZFAS gibt es über 50 komplexe Wirkketten, welche die Kommunikationsbeziehungen von Sensoren über unterschiedliche SoCs für die jeweiligen Verarbeitungsschritte und hin zu Aktuatoren beschreiben. Diese Wirkketten werden im Motionwise Planungstool beschrieben, das dann nach geeigneten Lösungen sucht, um alle Wirkketten zu jeder Zeit auch zu garantieren.

Wie gewährleisten Sie, dass die Safety-Kriterien erfüllt sind?

Dr. Stefan Poledna: Im Rahmen der Safety gemäß ISO 26262 stellen wir unter anderem folgende Fragen: Wie schauen diese ganzen Überwachungsmechanismen bezüglich Laufzeitüberwachung aus, wie schauen die Schutzmechanismen aus bezüglich Speicherschutz, damit nicht eine Applikation in der anderen irgendwo im Speicher unautorisiert Änderungen durchführt, dass nicht irgendwo Daten korrumpiert werden auf dem Weg durch diese Bearbeitungsketten? Hierfür kommt eine zusätzliche End-to-End-Absicherung hinzu, bei der alle Daten noch Sicherungsprüfsummen bekommen, damit auf dem Weg keine Daten verloren gehen.

Automatisiertes Fahren ist per se schon hochkomplex. Wie kamen Sie auf die Idee, einen modularen Ansatz zu wählen?

Dr. Stefan Poledna: Wir haben von vornherein einen modularen Ansatz gewählt, weil wir damit im Luftfahrtbereich sehr viel Erfahrung gesammelt haben. Dort gab es schon vor Jahren das Ziel, viele unterschiedliche Funktionen auf einer Computerplattform zusammenzufassen, Stichwort Integrated Modular Avionics. Wir konnten hier unsere Erfahrungen aus diesem Bereich einfließen lassen, da wir dort schon lange aktiv sind. Diesen Modularitätsgedanken haben wir dann für den Automobilbereich adaptiert, automatisiert und in ein Framework gebracht. Durch diesen Vorsprung konnten wir mit Audi im ZFAS-Projekt so eine Lösung als die ersten auf den Markt bringen.

Haben Sie neben Audi noch weitere Kunden für die Plattform?

Dr. Stefan Poledna: Motionwise kommt mittlerweile nicht nur bei Audi, sondern auch bei einigen anderen Prototyp- und Serienprojekten weiterer OEMs weltweit zum Einsatz. Darüber hinaus ist auch Samsung eine Partnerschaft mit TTTech im automobilen Bereich eingegangen, um gemeinsam in einem offenen Ökosystem Lösungen für das autonome Fahren anzubieten, wobei als Safety-Plattform Motionwise zum Einsatz kommen wird. Dazu hat Samsung Harman als Tier-1-Lieferanten übernommen und wird sich bei TTTech strategisch mit 75 Millionen Euro am Automobilgeschäft beteiligen. TTTech verfolgt hier ein offenes Modell, um strategische Partner, die mit Motionwise in den Markt gehen zu unterstützen.

„Die komplette Entwicklung, das Debugging, die Visualisierung und das Testen des Codes kann (bei Motionwise) auf dem PC erfolgen.“ Dr. Stefan Poledna, TTTech

Dr. Stefan Poledna: „Die komplette Entwicklung, das Debugging, die Visualisierung und das Testen des Codes kann (bei Motionwise) auf dem PC erfolgen.“ Alfred Vollmer

Ab Level 3 müssen Systeme fail-operational sein. Was bedeutet das in der Praxis?

Dr. Stefan Poledna: Level 3 heißt im Grunde genommen, dass der Fahrer in einem bestimmten, beschränkten Szenario die Verantwortung an das Fahrzeug übergibt, nicht mehr den Verkehr verfolgen muss und sich anderen Tätigkeiten widmen kann; das bringt Audi mit unserer Plattform erstmalig zur Serienreife. Das bedeutet natürlich aber auch, dass das Fahrzeug im Fehlerfall (Sensor, Aktuator, ECU, Kommunikation, …) nicht einfach die Fahraufgabe an den Fahrer rück-delegieren kann, da der Fahrer nicht mit der aktuellen Verkehrssituation vertraut ist. Dementsprechend muss die Steuerung auch im Fehlerfall weiterhin so lange erfolgen, bis sich der Fahrer mit der Verkehrssituation vertraut gemacht hat oder das Fahrzeug zu einem sicheren Halt gebracht wurde.

In der Praxis ist hierfür eine durchgängige Redundanz erforderlich. Die Sensoren zum Beispiel müssen nicht komplett redundant sein, aber ein bestimmter Redundanzlevel der Sensorik ist erforderlich. Hinzu kommt natürlich die Aktuatorik, also Lenken, Bremsen, Antriebsstrang sowie das gesamte Thema Vernetzung, Kabelbaum und Spannungsversorgung, wie auch die ECU mit Software und Hardware. Sowohl die Software als auch die Elektronikarchitektur muss den Fehlerfall beherrschen, und mit entsprechenden Überwachungsfunktionen muss das System auch fail-operational sein. Wir arbeiten gerade daran, Motionwise auch für Anwendungen auf Level 4 und Level 5 auszuprägen. Schon bald werden wir gemeinsam mit Samsung und Harman eine hochintegrierte Architektur zeigen, die genau diese Fail-Operational-Eigenschaften in einer hochskalierbaren Software- und Hardware-Architektur aufweist. Es handelt sich dabei um eine Art Data-Center innerhalb des Fahrzeugs, welches nicht nur Funktionen für das autonome Fahren sondern alle rechenintensiven Funktionen (Dashboard, Infotainment, Body, Gateway, Chassis, …) hosten kann.

Das In-Car-Data-Center sehen wir als ganz klaren Zukunftstrend. Gleichzeitig wird die Navigation mit den hochpräzisen Karten funktional vom Infotainment in die Automated-Driving-Plattform wandern, weil dort höhere Anforderungen in punkto Präzision und Aktualität bestehen als im Infotainment.

Für Software gibt es OTA-Updates, aber was passiert mit der Hardware?

Dr. Stefan Poledna: Heute treffen wir im Auto drei bis fünf Jahre vor SOP die Festlegungen bezüglich der Hardware und der Elektronik, so dass man meist schon fünf Jahre nach SOP mit einer 10 Jahre alten Elektronik konfrontiert ist, die nicht mehr up-to-date ist. Allein schon um Obsoleszenzprobleme zu vermeiden, sind Hardware-Upgrades in Zukunft erforderlich. In der digitalen Welt wird man Wege finden müssen, auch Hardware upzugraden, um dort eben zusätzliche Features, Funktionen, Leistungsfähigkeit darstellen zu können. Wer das schnell und effizient kann, wird einen Vorsprung haben. Deswegen beschäftigen wir uns auch mit diesem Thema und wollen schon bald erste Prototypen hochintegrierter Architekturen zeigen, die dann schon mehrere Domains zusammenfassen können.

Alfred Vollmer

Chefredakteur AUTOMOBIL-ELEKTRONIK

(av)

Kostenlose Registrierung

Der Eintrag "freemium_overlay_form_all" existiert leider nicht.

*) Pflichtfeld

Sie sind bereits registriert?