- Historie
- Die Konsequenzen
- Die Architektur
- Ein Technologievergleich
- Die Werkzeuge (tools)
- Verteilte Funktionen
- Ein Anwendungsbeispiel


Historie

In der Vergangenheit gab es verschiedene ereignisgesteuerte Kommunikationssysteme, wie A-BUS, VAN, M-Bus.

(bisherige Struktur im TT)  

Aber keines dieser Protokolle wurde zu einem weit verbreiteten Standard. Die meisten blieben herstellerspezifisch oder verschwanden nach kurzer Zeit wieder vom Markt. Nur der CAN (Controller Area Network) wurde in Europa zum Standard. Diese Rolle wurde in den USA durch das Protokoll J1850 ausgefüllt, wobei es auch hier herstellerspezifische Ausprägungen gab, was dazu führte, dass die Systeme nicht kompatibel waren.

Im Bereich der Infotainmentsysteme hat sich der low-speed CAN durchgesetzt. Dies gilt jedoch nur für den Austausch von Informationen. Wenn die Anforderung an die Übertragungsrate, in diesem Zusammenhang auch Bandbreite genannt, steigt, weil auch Audio- und Videodaten übertragen werden sollen, so ist der CAN überfordert. Aus diesem Grund haben diverse Hersteller gemeinsam das MOST-Konsortium gegründet und ein optisches Datenbus-System entwickelt. Dadurch besteht nun die Möglichkeit, Daten mit einer Bandbreite von 21 Mbit/s im Fahrzeug zu verteilen.

Auf dem Gebiet der Komfortsysteme wird derzeit ebenfalls ein 100kBit/s low-speed CAN-System eingesetzt. Das genügt den derzeitigen Anforderungen. Mit der Steigerung der Funktionalitäten werden zukünftig auch hier zeitgesteuerte Architekturen eingesetzt.

Im Bereich des Antriebsstrangs werden heute 500 kBit/s high-speed CAN-Systeme eingesetzt. Die Anforderungen an die zu übertragende Datenmenge, wie sie in absehbarer Zeit auf uns zu kommen, können damit nicht mehr abgedeckt werden. Auf Grund des hohen Bedarfs an Bandbreite und der damit verbundenen hohen Auslastung des Systems verschlechtert sich das zeitliche Verhalten. Der Bedarf nach einem neuen Bussystem tritt hier am deutlichsten zu Tage.

Ein neues Bussystem, welches die zukünftigen Anforderungen und Funktionalitäten erfüllt, ist dringend notwendig. Über die Beseitigung der bekannten Engpässe der heutigen Systeme hinaus, muss es auch zukunftssicher sein.


Die Konsequenzen

Audi hat festgestellt, dass die aktuell im Einsatz befindlichen Kommunikationssysteme nicht dazu geeignet sind, zukünftigen Anforderungen gerecht zu werden. Die innovativen Möglichkeiten und die zunehmende Komplexität vernetzter elektronischer Systeme in Automobilen, wie drive by wire oder brake by wire , erfordern schnellen und sicheren Datentransfer in Echtzeit.

Wenn ein neues Datenübertragungssystem die Anforderungen von verteilten Regelsystemen und “by-wire” Anwendungen erfüllen soll, ist der wichtigste Punkt Sicherheit. Sie ist eines der wesentlichen Vorteile des Bus-Protokolls TTP. Dieses Time-Triggered-(zeitgesteuerte) Protokoll kommt unseren Anforderungen am nächsten. Die Erfahrungen der Luftfahrtindustrie und deren Entscheidung TTP für by-wire Anwendungen einzusetzen, war ebenfalls ein wichtiger Aspekt.
TTP ist derzeit das Kommunikationsprotokoll für integrierte Echtzeitsysteme. Diese Technologie ermöglicht Entwurf, Einsatz und Wartung fehlertoleranter, d.h. redundant ausgelegter Systeme.

Die AUDI AG hat mit der TTTech Computertechnik AG mit Sitz in Wien einen adäquaten und innovativen Partner mit umfassendem Know-how auf diesem Gebiet gefunden. Die TTTech AG verfügt über breite Erfahrungen mit der schnellen, komfortablen und sicheren Verknüpfung unterschiedlicher Systeme mittels TTA.


Die Architektur

Die neue Architektur in der Fahrzeugelektronik ist die Basis, um verteilte Regelsysteme und im nächsten Schritt “by-wire”-Anwendungen in Serie bringen zu können.

Welche wichtigen Attribute muss eine solche Architektur haben?
• Sie muss deterministisch sein. Das bedeutet vorhersagbar in ihrem zeitlichen Verhalten.
• Sie muss fehlertolerant sein. Das bedeutet, dass das System hypothetisch auftretende Fehler toleriert. Alle bisherigen Systeme in Fahrzeugen waren lediglich fehlersicher und hatten mechanische Backup-Funktionen. Dies ist für echte “by-wire”-Anwendungen nicht ausreichend.
• Das Kommunikationssystem muss während des Lebenszyklusses erweiterbar sein.
• Alle Funktionen der immer komplexeren Systeme müssen einzeln und im Gesamtsystem testbar sein.
• Die Architektur muss in der Lage sein, verteilte Systeme und Funktionen zu unterstützen.

Die Applikation bestimmt einen großen Teil der Anforderungen. Sie ist die finale Instanz, und Sicherheit muss letzten Endes auf dieser Ebene gewährleistet sein. Dies kann nur garantiert werden, wenn die unter der Applikation liegenden Schichten Dienste zur Verfügung stellen, die Sicherheit unterstützen. Zudem muss auch die Topologie der Verteilung bestimmt werden.

An zweiter Stelle ist die Diagnose zu nennen. Für welche neuen Dienste kann ein zeitgesteuertes Protokoll sorgen? Hier sind zwei Schwerpunkte zu nennen:
Erstens, die übergeordnete Diagnose. Hier können neue Dienste etabliert werden, welche im Falle einer Wartung oder Reparatur zu einer optimierten Diagnose und damit zu einer erhöhten Reparaturqualität führen.
Zweitens, der Einsatz einer sogenannten Fehlertoleranzschicht. Diese sorgt dafür, dass beispielsweise auch bei redundanten Systemen immer nur ein nach fest definierten Regeln bestimmter Wert an die Applikation geliefert wird. Diese Softwareebene sollte standardisiert sein, um Kompatibilität unter den verschiedenen Komponenten-Lieferanten zu gewährleisten und um die Komplexität zu reduzieren. Dieser Teil der Software benötigt also eine exakte Definition der Schnittstellen, um die Module flexibel für diverse Einsatzzwecke einsetzen zu können.

Es ist zudem erforderlich auch die Hardware anzusehen, denn die Hardware der Steuergeräte, muss ein gewisses Sicherheitsniveau haben, um die Gesamtsicherheit zu gewährleisten. An mechatronische, d.h. mechanisch-elektronische, Komponenten werden besondere Anforderungen bezüglich der Sicherheit gestellt. Die Funktionen müssen immer verfügbar sein. Und sie müssen “fail safe” Eigenschaften aufweisen. Schließlich ist ein robustes Energienetz nötig, um alle Komponenten mit Leistung zu versorgen.


Ein Technologievergleich

 Grafische Übersicht TTA und CAN

CAN: “Controller area network” Hierbei handelt es sich wohl um das am weitesten verbreitete Netzwerk in Automobilen Applikationen. Es beruht auf einer reinen Ereignissteuerung. Das bedeutet, dass Informationen immer beim Auftreten eines Ereignisses ins Kommunikationssystem eingestellt werden. Die Steuerung der Priorität erfolgt mit Hilfe einer der Nachricht vorangestellten Identifikation. Je höher die Priorität ist, um so größer ist die Wahrscheinlichkeit, dass sich diese Nachricht am Bus durchsetzen wird. Der Vorteil liegt in der Flexibilität des Systems. Es ist leicht, neue Nachrichten in ein vorhandenes Netz einzufügen, und der Zugriff auf den Bus kann ohne Verlust von Botschaften stattfinden. Hier liegen allerdings auch die Probleme, denn dieses Verfahren verhindert in größeren Netzen eine Erhöhung der Übertragungsrate auf über 1Mbit/s. Durch die Prioritätssteuerung kommt es zu zeitlichen Abhängigkeiten innerhalb eines Netzes. Je höher also die Auslastung des Bus ist, desto größer wird der zeitliche Versatz des Informationstransports und damit die Unsicherheit, wann und ob überhaupt eine Nachricht beim Empfänger ankommt.

TTP: ”Time triggered protocol” Hier handelt es sich um ein rein zeitgesteuertes Protokoll. Es baut auf einem TDMA-Verfahren (Time Division Multiple Access = Einteilung in Zeitsegmente mit Mehrfachzugriff) auf. Jedem Knoten wird eine vorherbestimmte Framelänge zugeordnet. Damit ist das Zeitfenster definiert, das dem Informationsknoten zum Senden zur Verfügung steht und es ist exakt vorbestimmt, wann eine Information auf dem Bus liegt.

Dies ermöglicht eine Abstimmung der Aufgaben auf den einzelnen Knoten und damit sehr eng verbundene Regelschleifen. Dieses Protokoll liefert darüber hinaus auch die Möglichkeiten für eine relativ leichte Implementierung von Sicherheitsmechanismen.


Die Werkzeuge (tools)

Um komplexe und sicherheitsrelevante, verteilte Funktionen entwickeln zu können ist eine vollständige Toolkette notwendig. Diese muss alle Entwicklungsschritte, vom abstrakten Reglerdesign bis hin zum Generieren des Codes. Die Toolkette von TTTech offeriert dem Anwender alle Hilfsmittel für den Bereich der Kommunikation und der Applikation.

Um das Verhalten der Regler und der Software in einem möglichst frühen Stadium der Entwicklung testen zu können, ist ein sogenannter SIL (Software in the loop) Test notwendig. Es muss das Reglerverhalten mit allen Einflüssen durch die Kommunikation und die Fehlertoleranzschicht simulierbar sein. Auch dies wird bereits durch die Toolkette von TTTech gewährleistet. Nachdem die Gesamtfunktion getestet ist, kann die optimierte Verteilung der Funktion auf die verschiedenen Zielsysteme erfolgen. Durch die strikte Trennung (Kapselung) der Funktionen ist ein Test der Teilfunktion in einem Steuergerät gegen eine definierte Schnittstelle möglich. Verlaufen diese Tests positiv, kann die komplette Funktion implementiert werden. Eine gegenseitige Beeinflussung der unterschiedlichen Funktionen wie bei einem CAN-System ist hier ausgeschlossen. Somit ist Zusammensetzbarkeit gewährleistet. Die Bestätigung erfolgt dann im Fahrzeug mit Rapid-Prototyping Systemen von TTTech.


Verteilte Funktionen

Die Basis eines sicheren, fehlertoleranten Systems ist eine robuste Energieversorgung.
Die nächste Ebene betrifft das Kommunikationssystem mit den geschilderten Eigenschaften. Wenn diese erfüllt sind, kann man von einem sicheren Kommunikationsnetz sprechen.

Darauf aufbauend kommt die Fehlertoleranzschicht. Sie ist von herausragender Bedeutung, da sie das Systemverhalten im Falle eines Fehlers wesentlich bestimmt.
Die Applikation als letzte Ebene umfasst die meist zugelieferten lokalen Regler genauso wie den globalen Regler, der Kernkompetenz von Audi ist.


Ein Anwendungsbeispiel

 Übersicht Bussysteme

In den aktuellen Audi-Modellen sind im Bereich Fahrwerk schon lokale Regler implementiert. Dies sind Systeme wie das Elektronische Stabilitätsprogramm ESP, die Elektronische Differenzialsperre EDS, Antriebs-Schlupf-Regelung ASR oder Luftfederung. Diese Fahrassistenzsysteme sind wesentlich durch den Bremseingriff bestimmt. Die Luftfederung arbeitet weitgehend autark. Auch die Informationen der Sensoren stehen nur den direkt angeschlossenen Steuergeräten zur Verfügung. Die Verknüpfung der einzelnen Systeme über CAN-Bus beschränkt sich weitestgehend auf den Austausch von Statusinformationen. Die Regler sind nur gering vernetzt. Durch die Ungenauigkeit des Systems, müssen die Regler darauf vorbereitet sein, eine oder mehrere Botschaften zu verpassen. Daraus folgt eine sehr eingeschränkte Möglichkeit verteilte Regelungen zu implementieren.

Wenn die Möglichkeit besteht, die einzelnen Systeme wesentlich enger zueinander zu bringen und funktional zu verkoppeln, ist damit auch eine verteilte Regelung möglich. Ausschlaggebend dafür ist ein deterministisches Verhalten, in dem der Zeitpunkt des Eintreffens einer Information beim Empfänger von vornherein bekannt ist und alle Systeme zeitlich synchronisiert sind.