FlexRay

international standardisiertes Netzwerkprotokoll
(Weitergeleitet von Flexray)

FlexRay ist ein serielles, deterministisches und fehlertolerantes Feldbussystem für den Einsatz im Automobil, vergleichbar mit TTP. Das FlexRay-Konsortium wurde 2000 von den Unternehmen BMW, Daimler AG, Motorola und Philips gegründet. Von 2001 bis 2004 traten als Core-Partner die Unternehmen Bosch, General Motors und Volkswagen bei. 2004 übernahm Freescale Semiconductor die Rechte und Pflichten als Core-Mitglied im Konsortium von Motorola. 2006 übernahm NXP Semiconductors die Rechte und Pflichten als Core-Mitglied im Konsortium von Philips. 2010 löste sich das FlexRay-Konsortium auf. Der FlexRay Standard wurde danach in einen ISO-Standard überführt (ISO 17458-1 bis 17458-5).

FlexRay-Logo

Allgemeine Beschreibung

Bearbeiten

Entwicklung und Erwartungen

Bearbeiten

FlexRay sollte die erhöhten Anforderungen zukünftiger Vernetzung im Fahrzeug erfüllen, die durch den CAN-Bus nicht befriedigt werden können, insbesondere eine höhere Datenübertragungsrate, Echtzeit-Fähigkeit und Ausfallsicherheit (für X-by-Wire-Systeme). Im aktuellen Fokus steht jedoch vorrangig die höhere Datenrate, welche durch den kontinuierlichen Anstieg von Fahrerassistenzsystemen im Bereich Antrieb und Fahrwerk in Premiumfahrzeugen heute notwendig ist. FlexRay definiert die Layer 1 (physische Schicht) und 2 (Datensicherungsschicht) im ISO/OSI-Referenzmodell. Der Serieneinsatz im Automobil erfolgte erstmals 2006 im BMW X5. Der FlexRay-Cluster in diesem Fahrzeug basiert auf der Protokollversion v2.0, der Physical Layer Spezifikation v2.1 Revision A.

Um auch die Anforderungen aktiver Sicherheitssysteme zu erfüllen, wurde FlexRay vor allem in Bezug auf zeitlichen Determinismus und Fehlertoleranz weiter entwickelt. Ein Bus-Guardian sollte eine zentrale bzw. dezentrale Überwachung der Buszugriffe auf Basis des statisch festgelegten TDMA-Schemas ermöglichen, kommt aber praktisch nicht zum Einsatz. FlexRay bietet zusätzlich zu ByteFlight eine Nachrichtenkommunikation mit einem festgelegten TDMA-Schema. Dabei setzt FlexRay ähnliche Mechanismen ein, wie das an der Technischen Universität Wien entwickelte Time-Triggered Protocol TTP. Zusätzlich zum TDMA-Schema bietet das von ByteFlight übernommene Minislotting-Protokoll einen kollisionsfreien, priorisierten, dynamischen Kommunikationskanal.

Um einen Knoten, zum Beispiel ein Steuergerät, an einem FlexRay-Bus zu betreiben, braucht man zwei Komponenten: den Bus Transceiver und den Communication Controller. Der Bus Transceiver stellt die direkte Verbindung zur Datenleitung her: Einerseits schreibt er die logische Information, die versendet werden soll, in Form von Spannungspulsen auf den Bus; andererseits liest er die Signale aus, die von anderen Teilnehmern auf dem Bus gesendet werden. Diese Ebene wird als physische Bitübertragungsschicht oder Physical Layer bezeichnet. Außerdem umfasst FlexRay noch das Busprotokoll. Das Busprotokoll regelt, wie ein Netzwerk startet, wie eine global Clock etabliert wird und welche Steuergeräte zu welchem Zeitpunkt senden dürfen. Der Communication Controller setzt das Busprotokoll in jedem Steuergerät um, beispielsweise verpackt er die zu übertragenden Informationen in ein Datenpaket und übergibt dieses Datenpaket zum richtigen Zeitpunkt zur Übertragung an den Bus Transceiver.

Leistungsmerkmale

Bearbeiten

FlexRay unterstützt:

  • Bitraten bis 10 Mbit/s je Kanal
  • dezentrale Uhrensynchronisation
  • garantierte Latenzzeiten (=> Determinismus)
  • Zweikanaligkeit im Protokoll
  • zentrale & dezentrale Zugriffskontrolle
  • Stern-, Bustopologie sowie Topologien mit Bussen an den Sternarmen

Kommunikationsprotokoll

Bearbeiten
 
TDMA (Time Division Multiple Access) nach FlexRay-Version 2.1

Die Kommunikation auf dem Bus läuft in Zyklen ab. Jeder dieser Zyklen ist in verschiedene Segmente unterteilt:

  • Im statischen Segment hat jedes Steuergerät seinen bestimmten Slot (Zeitfenster), in dem es Nachrichten senden kann. Es darf dabei die zeitliche Länge seines Slots nicht überschreiten. Ist die Nachricht zu lang, muss der nächste Zyklus oder das dynamische Segment genutzt werden, um die Nachricht fortzusetzen.
Dies ist der deterministische Teil des Protokolls, mit dem sichergestellt werden kann, dass wichtige Nachrichten (zum Beispiel Lenkung, Bremse) innerhalb einer bekannten Zeit übertragen werden.
  • Das dynamische Segment kann von einem Steuergerät benutzt werden, wenn es längere oder zusätzliche Nachrichten senden möchte, und beispielsweise die Breite seines statischen Slots nicht ausreicht oder für wichtigere Nachrichten benötigt wird.
    • Wenn ein Steuergerät keine Nachricht absetzen möchte, läuft sein Zeitfenster (Minislot) einfach ab (Mini 1 bis Mini 3).
    • Will das Steuergerät beispielsweise in Minislot 4 eine längere Nachricht senden, so verschiebt sich der Zeitpunkt, an dem das nächste Steuergerät senden kann, nach hinten. Im ungünstigsten Fall ist der dynamische Minislot 4 so lang, dass in diesem Zyklus kein weiteres Steuergerät mehr senden kann.
    • Weil für Steuergeräte, die im dynamischen Slot am hinteren Ende der Reihenfolge stehen, die Wahrscheinlichkeit am größten ist, dass sie mit einer Nachricht in diesem Slot warten müssten (oder gar herausfallen würden), sollte die Anzahl der dynamischen Slots k > n sein (n ist die Anzahl der Steuergeräte, die auf dem Bus kommunizieren und dazu einen Slot haben).
Dieser Teil entspricht von seiner Übertragungsstruktur eher dem CAN-Bus.
  • Das Symbolfenster (symbol) war für den Test des Buszugriffs vorgesehen und wird voraussichtlich nicht mehr zum Einsatz kommen.
  • NIT (Network Idle Time) soll den am Bus hängenden Steuergeräten ermöglichen, sich wieder mit dem Bus exakt zu synchronisieren.

Die Synchronisation bewirkt, dass alle Steuergeräte am Bus nach dem gleichen Takt Nachrichten senden und nicht durch zeitliche Verschiebungen im Minislot (Zeitfenster) eines fremden Steuergerätes senden. Der Zeittakt wird von den Steuergeräten nach bestimmten Regeln beim Aufwachen ausgehandelt. Es ist daher kein Master notwendig, der den Takt vorgibt und bei seinem Ausfall den Bus lahmlegen könnte.

Der Rahmen

Bearbeiten
 
Der FlexRay-Rahmen

Der FlexRay-Rahmen (englisch Frame) ist wie in nebenstehender Abbildung dargestellt aufgebaut.

Hardware

Bearbeiten

FlexRay nutzt ähnlich wie der CAN-Bus verdrillte Zweidrahtleitungen, aus Redundanzgründen werden zwei solcher Leitungen verwendet. Um Reflexionen an den Leitungsenden zu verhindern, wird jede Leitung mit ihrem Leitungswellenwiderstand im Bereich von 80 Ω bis 110 Ω abgeschlossen. Die maximale Leitungslänge hängt von der Datenrate und der Anzahl, Länge und Position der Stichleitungen ab. BMW und andere OEMs setzen spezielle TP-Leitungen mit PE-Isolation ein, da PE als Isolierwerkstoff gegenüber PVC erhebliche Vorteile bei der temperaturbedingten Toleranz hat, folglich die Anforderungen an die Impedanz erfüllt werden können. Für Laboraufbauten eignen sich Ethernet-Kabel, sowohl Standardvarianten (CAT5 etc.) wie auch Profinet-Kabel, letztere gibt es in robusten Ausführungen und eignen sich auch für Verkabelungen im Fahrzeug.

Die Signale werden durch Spannungspegel von 1,5 V und 3,5 V übertragen, je nach Lage dieser Spannungspegel auf den Leitungen wird eine 0 oder 1 übertragen. Haben beide Leitungen den Pegel 2,5 V, ist der Bus im Leerlauf (Idle). Zur Energieeinsparung kann auch der Pegel 0 V für beide Leitungen verwendet werden.

Siehe auch

Bearbeiten

Literatur

Bearbeiten
  • Ausführlich ist FlexRay beschrieben in: Mathias Rausch: FlexRay – Grundlagen, Funktionsweise, Anwendung. Hanser-Verlag, 2007, ISBN 3-446-41249-2 bzw. ISBN 978-3-446-41249-1.
  • Eine Gegenüberstellung mit anderen automobilen Feldbussen erfolgt in: Werner Zimmermann und Ralf Schmidgall: Bussysteme in der Fahrzeugtechnik – Protokolle, Standards und Softwarearchitektur. 5. Auflage, Springer Vieweg, 2014, ISBN 978-3-658-02418-5.
  • Eine Einführung in FlexRay ist in: Mathias Rausch: Kommunikationssysteme im Automobil – LIN, CAN, CAN FD, CAN XL, FlexRay, Automotive Ethernet. Hanser, München 2022, ISBN 978-3-446-47035-4.
Bearbeiten