FleyRay gehört zu den jüngeren, komplexen Bussystemen und bietet im Hinblick auf die FuSi (ISO26262) eine Vielzahl an Möglichkeiten für unterschiedliche Sicherheitskonzepte. Doch erstmal die Grundlagen, dann die wichtigsten Details. Beim FlexRay handelt es sich um ein nicht kommerzielles Bussystem mit bis zu 10Mbit/s. Es kann sowohl in passiver Linien-Topologie ähnlich dem CAN oder in einer Art Hybrid-Topologie aus Linien- und Sternkonfiguration mit „Active-Star“-Knoten betrieben werden mit bis zu 10Mbit/s zwischen den Sternen. In beide Topologie-Konfigurationen kann eine heiße Redundanz durch 2 Kanäle (A/B) genutzt werden. Jeder der bis zu 64 Netzteilnehmer besitzt ein Communication-Controller (CC) und 2 Bustreiber (BD) für je einen der beiden NRZ-kodierten Kanäle A und B.
Der FlexRay Node (Teilnehmer)
FlexRay bietet zeitgleich asynchrone und synchrone Übertragung, d.h. „Echtzeit“ durch deterministisches Übertragungsverhalten. Wie beim CAN ist auch hier eine CRC-Sicherung vorhanden, jedoch für jeden Kanal unabhängig mit unterschiedlichen Initialisierungsvektoren der zugrunde liegen Polynome 24. Ordnung. Angefangen von Header über die Nutzdaten (Payload) bis zum Ende des CRC-Feldes wird eine Hammingdistanz von 6 erreicht bei maximalen Payload von 248 Bytes. Die Hamingsdistanz schrumpft auf 4 sobald die maximale Datenkapazität (254 Bytes) für die Nutzdaten verwendet wird.
Weiterhin ist der Header der statischen Segmente „quasi-offline“ CRC-gesichert. Jeder CC prüft im operativen Betrieb beim Empfang von statischen Segmenten den Header mit einen CRC-Polynom 11. Ordnung (Hammingdistanz 6) auf die Richtigkeit einiger statischer Teilinformationen, um damit auch einen fehlerhaften CC im Cluster der eine fehlerhafte Nachricht sendet, zu identifizieren. Dabei werden das sync frame indicator Bit, das startup frame indicator Bit, die 11 frame ID Bits, and die 7 payload length Bits geprüft. Diese dürften sich nach der Start-Up Phase nicht mehr ändern.
FlexRay Standard-Frame, der in den statischen und dynamsichen Segmenten seinen Platz findet.
Interessant ist der Ansatz synchrone und asynchrone Daten in einen Datenstrom zu bündeln. Dabei kommt das TDMA(Time Division Multiple Access)/FTDMA(Flexible Time Division Multiple Access)-Verfahren für den Buszugriff zur Anwendung. Hierbei tritt demnach keine Kollision beim Zugriff auf den Bus auf, wie beim CAN in der Arbitrierungsphase. Es werden 4 globale Zeitschlitze innerhalb eines „Communication-Cycles“ gebildet. Der erste Zeitschlitz für das statische Segment mit TDMA, der synchrone Teil der Datenübertragung, es folgt ein dynamisches Segment mit FTDMA für den asynchronen Teil und dann folgen noch das „Symbol“-Segment für Inter-Node-Kontroll-Informationen und zum Schluss das Network-Idle-Segment, damit die Nodes sich synchronisieren können. Im operativen Betrieb des Clusters erkennt jeder Node anhand des Cycle-Wertes und seiner internen Uhr, wann seine Zeit gekommen ist. Ein wesentlicher Vorteil des TDMA-Verfahrens ist die Skalierbarkeit. Beim Hinzufügen eines CAN-Nodes ist ein Rework das Schedulings auf Fahrzeugebene notwendig und es kommt zu aufwendigen Tests um das Timing zu verifizieren. Beim FlexRay dagegen wird einfach der Zeitschlitz belegt und die spezifische Deterministik bleibt erhalten.
Der Kommunikationszyklus mit statischen udn dynamischen Segementen.
Die Synchronisierung der einzelnen Teilnehmer hat gerade beim TDMA-Verfahren eine höhere Bedeutung im Hinblick auf die FuSi als beim CSMA/CA-Verfahren wie beim CAN. Es würde zu einen kompromittierenden „Bubbling Idiot“ kommen, wenn eine Node-Uhr falsch tickt. Aber dagegen ist ein Kraut gewachsen. Der meist schon im Treiber integrierte Buswächter verhindert so manches Fehlverhalten in der Active-Star-Konfiguration und eine fehlertolerante, verteilte Start-Up-Sequenz bessert die Latent-Fault-Metrik auf. Doch welche Mechanismen zur Synchronisation sind vorhanden? Wahrend der CAN-Node bei der Resynchronisation seine Quanten errechnet aus dem Flankenwechsel im Bitstream und zum Nachrichtenstart hart synchronisiert, ist es beim FlexRay zum Teil dem Systemarchitekten überlassen wie synchronisiert wird und woher die Zeitinformation kommt. Es sind 3 verschiedene Sync-Cluster Konfigurationen (TT-D(FlexRay V.2.1), TT-L(FlexRay V.3.0.1), TT-E(FlexRay V.3.0.1) möglich.
Dual-Channel Hybrid-Architektur mit TT-D Sync-Charakteristik.
In der Start-Up-Sequenz (z.B. TT-D-Sync Konfiguration nach FlexRay V.2.1) des Netzwerks werden von mindestens 2 fehlerfreien „Coldstart“-Nodes nacheinander sogenannte CAS(collision avoidance symbol)-Symbole gesendet gefolgt von 3 Communication-Cycles mit aktiven StartUp-Frame-Indicator- und Sync-Frame-Indicator Bit in den Frames zur Synchronisation. Damit ist auch jeder Coldstart-Node ein „Sync“-Node. Es folgen die restlichen Nodes. Um ein Systemstart sicherzustellen, sollte mehr als 2 „Coldstart-Nodes“ im technischen Sicherheitskonzept eingeplant sein, wobei beachtet werden sollte, dass der „Leading-Coldstart-Node“ ein sicherheitskritisches Element darstellt. Um die Cluster-Konsistenz auch bei fehlerhaften Nodes zu gewähren, sollte in den höheren Ebenen des ISO/OSI-Modells eine Art „Membership-Protokoll“ implementiert werden. Empfehlenswert zum Lesen ist die „FlexRay Protocol Spezification Version 3.0.1“.
FlexRay V.3.0.1: Fehlerfreie Start-Up Sequenz [1]
Insgesamt ist FlexRay die Alternative zum TTCAN wenn es um sicherheitskritische Systeme mit deterministischen Anforderungen wie x-by-wire geht. Schneller, flexibler, zweikanalig. Doch die Komplexität steigt signifikant und birgt das Risiko vermehrt unentdeckte Fehler zu implementieren. Auch hier gilt, das Wissen über die verwendete Technologie ist die Grundlage um die funktionale Sicherheit zu gewährleisten.
Quellen:
[1]: FlexRay Protocol Specification V.3.0.2
