In fast allen automobilen Klassen, vor allem aber natürlich in den Premiumbereichen, nehmen die Kundennachfrage nach Fahrerassistenzsystemen und entsprechende Herstellerangebote stark zu. Beispiele hierfür sind komfortable Einparkhilfen, automatisches Einparken, langsames Fahren ohne Zutun des Fahrers in Stausituationen, automatische Scheinwerferlichtanpassungen und Verkehrszeichenerkennungen, Spurhalteassistenten, adaptive Tempomate sowie Notbremsassistenten. OEMs widmen sich zudem bereits der Entwicklung von automatischem Einparken zum Beispiel in Parkhäusern, wobei der Fahrer das Fahrzeug auch vorher verlassen kann, sowie dem automatisierten Fahren auf der Autobahn.

1502-001-tttechcar-aufmacher.jpg

TTTech

Naturgemäß steigen damit auch die Anforderungen an die Steuergeräte. Dabei nimmt die benötigte Bandbreite für den Datenaustausch nicht nur zwischen den Steuergeräten ständig zu sondern vor allem innerhalb der Fahrerassistenz-ECU, in der mehrere Hochleistungsprozessoren vernetzt werden. Darüber hinaus steigt auch der Anteil an sicherheitsrelevanten Daten. Die immer größere Bedeutung der genauen Umfelderfassung sowie von Kamerasystemen, Radar und Laserscannern verstärken diesen Trend.

In Zeiten, in denen Luxusklassefahrzeuge über 100 Steuergeräte an Bord haben, wird gleichzeitig der Wunsch der OEMs nach einer Reduktion der ECU-Anzahl immer stärker. Als Premiumhersteller hat sich Audi daher das Ziel gesetzt, die Fahrerassistenzfunktionen in einer zentralen, zFAS genannten, Domain-ECUzu integrieren. TTTech entwickelt dafür auf Basis der bisher gewonnen Erfahrungen und Technologien eine Plattform, welche die unterschiedlichen Fahrerassistenzfunktionen aufnehmen und gleichzeitig höchste Sicherheitsstandards garantieren kann.

Funktionssicherheit

Der anhaltende Trend des kontinuierlich wachsenden Funktionsumfangs in der Fahrzeugelektronik lässt die elektronischen Systeme immer mehr und auch immer komplexere Aufgaben zur Unterstützung sowie zum Schutz des Fahrers und anderer Verkehrsteilnehmer wahrnehmen. Die schrittweise Ausdehnung der Eingriffsmöglichkeiten – insbesondere moderner Fahrerassistenzsysteme – bringt eine stets größer werdende Abhängigkeit von der Verlässlichkeit des elektronischen Systems mit sich. Dafür ist es notwendig, unter allen Umständen neben der ISO 26262-konformen Sicherheit des Systems auch die Verfügbarkeit von kritischen Teilfunktionen zu gewährleisten. Das gilt insbesondere, wenn während der Fahrt kein einfacher – zum Beispiel durch eine Abschaltung erreichbarer – sicherer Zustand eingenommen werden kann und eine Fortsetzung des Betriebs auch im Fehlerfall unbedingt erforderlich ist. Diese Anforderung trägt die Bezeichnung „Fail-Operational“ und ist in der modernen Luftfahrt (in Fly-by-Wire-Systemen) schon länger etabliert.

Die zFAS-Platine ist das zentrale Hardware-Element in Audis ECU-Strategie auf dem Weg zum pilotierten Fahren.

Die zFAS-Platine ist das zentrale Hardware-Element in Audis ECU-Strategie auf dem Weg zum pilotierten Fahren.TTTech

Von Fail-Stop zu Fail-Operational

Derartige Fail-Operational-Systeme sind im automotiven Bereich noch nicht in breiterem Einsatz, da die aktuellen „Fail-Stop“-Systeme – kombiniert mit dem Vorhandensein eines mechanischen Backups und dem Fahrer – meist ausreichen. Natürlich erfordern Fail-Operational-Systeme mehr Redundanz in der Systemauslegung, um die Funktion trotz eines aufgetretenen Einzelfehlers weiterhin erfüllen zu können. Ein intelligentes Redundanzkonzept lässt sich auch als Weiterentwicklung bestehender Konzepte in einer automotiven Kostenstruktur umsetzen.

Die Weiterentwicklung von Fail-Stop-Systemen zu Fail-Operational-Systemen ist nicht nur für die künftige Erweiterung von Fahrerassistenzsystemen in Richtung (teil-)autonome Fahrfunktionen erforderlich; auch heutige Systeme wie beispielsweise die elektromechanische Servolenkung könnten davon profitieren. Sicherheitsanforderungen und Verfügbarkeitsanforderungen ergänzen sich somit und dienen beide dem übergeordneten Ziel, Menschenleben zu schützen.

Worin liegt der Paradigmenwechsel?

Die System-Design-Entscheidungen, die in der Vergangenheit meist nach dem Motto „im Fehlerfall abschalten“ erfolgten, sind nun zu überdenken. Dabei stehen meist zwei diametral entgegengesetzte Systemreaktionen zur Auswahl. Einerseits lässt sich im Sinne bisheriger, als sicher eingestufter, Fail-Stop-Design-Ansätze im Fehlerfall durch eine einfache Abschaltung der sichere Zustand einnehmen. Andererseits kann zu Gunsten der Verfügbarkeit versucht werden, mit voller Funktionalität den Betrieb aufrecht zu erhalten (Fail-Operational). Diese erhöhte Verfügbarkeit kommt jedoch stets in Begleitung einer mit ihr einhergehenden höheren Komplexität des Systems. Als dazwischenliegende Lösung besteht im Fehlerfall auch die Möglichkeit, in einen Degraded Mode zu wechseln, sodass eine Kernfunktion aufrecht erhalten werden kann. Auch hier ist die Komplexität allerdings höher als beim Fail-Stop-Ansatz.

Ist ein Fail-Operational-Ansatz erforderlich, dann gilt es, Sicherheitsziele und Verfügbarkeitsanforderungen unter einen Hut zu bringen und eine darauf abgestimmte System-Architektur zu entwerfen, die sämtliche relevanten Fehlerfälle beherrscht. Besonderes Augenmerk gilt dabei den „Common Cause Failures“ – also jenen Fehlern, die trotz vorgesehener Redundanzen zu einem Ausfall aufgrund einer gemeinsamen Ursache führen können. Dazu gehören zum Beispiel eine Unterbrechung der Versorgungsspannung, Clock-Ausfall oder Kommunikationsausfall. Die Weiterentwicklung bestehender automotiver Konzepte lässt die Konstruktion geeigneter System-Architekturen zu, wobei eine beispielhafte kosteneffiziente Lösung mit diversitärer Redundanz präsentiert wird.

Die Middleware TTIntegration ermöglicht die Partitionierung und die gleichzeitige Berücksichtigung unterschiedlicher ASIL-Sicherheitslevel.

Die Middleware TTIntegration ermöglicht die Partitionierung und die gleichzeitige Berücksichtigung unterschiedlicher ASIL-Sicherheitslevel.TTTech

Middleware für zFAS

Das von TTTech mit Audi entwickelte Plattformsteuergerät zFAS hatte in der Version, die Audi auf der CES 2014 in Las Vegas der Öffentlichkeit präsentierte, noch in etwa A4-Format. Die in der Serienentwicklung befindlichen Varianten wurden nochmals deutlich in der Größe reduziert.

Die entwickelte Architektur für Fahrerassistenzsysteme ist sehr gut skalierbar. Je nach Anzahl und Leistungsbedarf der vollständig voneinander abgekapselten eingesetzten Applikationen (aktuell mehrere Dutzend gleichzeitig) lässt sich die Ausstattung mit unterschiedlichen Multi-Core-SoCs, die auch nebeneinander mit verschiedenen Betriebssystemen (Autosar, VxWorks, Linux und Weitere) laufen können, entsprechend dem tatsächlich benötigten Ressourcenbedarf anpassen.

Die von TTTech entwickelte Middleware, als Paket TTIntegration genannt, sorgt zunächst für die Abstraktion der verteilten Hardware in Richtung der Applikationen. Applikationen sind entsprechende feste Ressourcen wie zum Beispiel Speicher, CPU-Zeit oder Bandbreite zugeteilt. Da aber die Rechenleistung von den Applikationen entkoppelt ist und auf allen Betriebssystemen ein Autosar-Interface zur Verfügung steht, besteht die Möglichkeit, die Applikationen auch beliebig zwischen den Rechnerkernen und Mikrocontrollern zu verschieben (Location Transparency).

TTIntegration unterstützt die Partitionierung von Anwendungen unterschiedlicher ASIL-Sicherheitslevel von A bis D sowie eine klare Nachvollziehbarkeit von Datenherkunft und Datenfluss für den Systemtest. Weil von Anfang an die Möglichkeit der Co-Simulation auf einem Standard-PC besteht, kann ein Teil der Software auf der ECU ablaufen, während der PC gleichzeitig andere Teile abarbeitet. Dabei kann sowohl auf der ECU wie auch auf dem PC der exakt gleiche Programmcode zum Einsatz kommen. Auch das Zeitverhalten wird dabei angepasst. Dies ermöglicht die gleichzeitige Applikationsentwicklung in einer PC-Umgebung sowie den vorzeitigen Start des Integrationsprozesses.

So lässt sich eine hohe Zeit- und Kostenersparnis bei der Integration erreichen. Dabei müssen nicht alle Applikationen zur gleichen Zeit auf der gleichen Entwicklungsstufe sein. Durch den Einsatz einer zeitgesteuerten Technologie kann das Zeitverhalten wesentlich früher als bei anderen Architekturen vorgegeben und bestimmt werden, weil die zeitlichen Eigenschaften bereits von Anfang an definiert werden und nicht wie sonst aus dem fertigen System herausgemessen und überprüft werden müssen. Dies reduziert auch den Aufwand bei der Fehlersuche im Nachhinein. Durch die zeitliche und räumliche Entkoppelung der Applikationen ergibt sich auch automatisch Rückwirkungsfreiheit, was den Aufwand für Test und Fehlersuche weiter senkt.

Applikationen zum Laufen bringen

Ein Lieferant einer Applikation, der eine Funktion fertig entwickelt hat, übergibt diese an den Systemintegrator (eine Rolle, die TTTech in einer Reihe von Projekten wahrnimmt) als Object Files. Mithilfe der von der Plattform zur Verfügung gestellten Pre-Integration-Environment (ein System ohne Applikationen, aber mit den selben Einstellungen wie das fertige System) werden für jede Funktion in Isolation, also gegen Simulationsmodelle, 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.

shutterstock-156673100.jpg

TTTech

Echtzeitfähiges Ethernet

Ein Kernbestandteil des Plattformsteuergerätes ist TTEthernet, welches den TSN (Pre-)Standard umfasst. Diese zuverlässige und echtzeitfähige Ethernet-Backbone-Lösung ermöglicht sowohl den Datenaustausch zwischen den einzelnen SoCs innerhalb der ECU wie auch die Kommunikation zur Simulationsumgebung und für die PC-basierte Funktionsentwicklung. Zudem unterstützt der in die ECU integrierte TTEthernet-Switch den Datenaustausch zwischen den einzelnen Funktionen mit unterschiedlichen Sicherheits- und Echtzeitanforderungen. Die verfügbare Bandbreite wird dabei in drei Kommunikationsklassen unterteilt: Neben „Best Effort“ (= Standard Ethernet Traffic) stehen auch AVB-/TSN-Streaming-Kommunikation zur Verfügung sowie zeitgesteuerte Kommunikation für harte Echtzeitanforderungen. Naturgemäß nutzt die ECU mit sicherheitsrelevanten Funktionen hauptsächlich die letztgenannte Kommunikationsklasse.

Zusätzlich kommt der hauseigene modulare Baukasten TTSafety zur Anwendung, der unter Anderem CPU-Cores, Watchdogs, Safe-Drivers, Safety-SW, Middleware sowie Safe-I/Os umfasst. Mit dem Plattformsteuergerät lässt sich so eine breite Palette von Kundenanforderungen und Möglichkeiten abdecken – in diesem Fall mit der Verwendung als Domänensteuergerät zur Integration und Aussteuerung verschiedener Fahrerassistenzsysteme.

Eck-Daten

Das Plattformsteuergerät zFAS ermöglicht Audi den Wechsel von Fail-Stop-Systemen zu Fail-Operational-Systemen, die beispielsweise für die künftige Erweiterung von Fahrerassistenzsystemen in Richtung (teil-)autonome Fahrfunktionen erforderlich sind. Das TTIntegration genannte Middleware-Paket sowie die echtzeitfähige Ethernet-Backbone-Lösung TTEthernet spielen dabei wesentliche Rollen.

Serieneinsatz in 2016

Der Serieneinsatz des Plattformsteuergeräts zFAS ist bereits für 2016 geplant. Die Integration der unterschiedlichen Fahrerassistenzfunktionen läuft derzeit auf Hochtouren. TTTech geht aber schon weitere Schritte: Das jüngste Produkt TTA-Drive ist eine Fortführung dieser Plattformidee auf eine Prototyp-Plattform, die alle Kunden als Evaluierungsplattform nutzen können. Auf TTA-Drive kann der Kunde ADAS-Funktionen selbst implementieren und die Vorteile von TTIntegration nutzen. Als Kommunikationsschnittstellen stehen LIN, CAN, CAN-FD, FlexRay und (Automotive-)Ethernet zur Verfügung. TTA-Drive verfügt über einen eingebauten deterministischen Ethernet-Switch mit drei externen Ethernet-Ports. Dies erlaubt sowohl die komfortable Entwicklung mit PC-basierten Tools als auch die Vernetzung mit weiteren Steuergeräten.

Durch eine Zusammenschaltung von zwei TTA-Drives lässt sich auch eine fail-operational ADAS-Plattform realisieren, wobei jedes TTA-Drive über eine Rechenleistung von 5500 DMIPS verfügt. Sie ermöglicht den TTTech-Kunden die effektive Umsetzung von eigener Funktionssoftware auf Automotive-Embedded-Hardware und somit eine seriennahe Implementierung. Das bringt dem Kunden erneut zusätzliche Zeitersparnis in der Entwicklung und Evaluierung seiner eigenen Produkte.

Marc Lang

ist Director Business Development & Sales bei TTTech Automotive.

(av)

Sie möchten gerne weiterlesen?

Unternehmen

TTTech Automotive GmbH

Schönbrunner Straße 7
1040 Wien
Austria