Teil 4: FlexRay für den Datenaustausch in sicherheitskritischen Anwendungen
Serielle Bussysteme im Automobil IV
Fortsetzung des Artikels von Teil 1
Durchgängige Lösung für Entwicklung, Simulation und Verifikation
Bereits im Jahr 2001 bot die Vector Informatik die erste Lösung für die Entwicklung von FlexRay-Systemen an. In der Zwischenzeit erhält der Entwickler ein umfassendes Portfolio [9]. Dazu gehören Werkzeuge für Design, Entwicklung, Simulation, Analyse, Test und Kalibrierung von Steuergeräten und verteilten Netzwerken. Mit dem DaVinci Network Designer FlexRay existiert eine Umgebung zum effizienten Design der Vernetzungsarchitektur und der Kommunikationsbeziehungen. Simulation, Analyse und Test von FlexRay-Systemen erfolgen mit CANoe.FlexRay, dessen Multibus-Konzept den gleichzeitigen Betrieb der Bussysteme FlexRay, CAN, LIN und MOST ermöglicht. Um das Systemverhalten des FlexRay-Netzwerkes bei Fehlern und Störungen genau zu untersuchen, generiert FRstress diese auf einem Kanal im FlexRay-Cluster.
Für den direkten Zugriff auf Steuergeräte-interne Größen benötigt der Entwickler ein spezielles Mess- und Verstellprotokoll: XCP on FlexRay. Im Rahmen der Entwicklung des aktiven Fahrwerksystems des neuen BMW X5 setzten die BMW-Ingenieure das Mess-, Kalibrier- und Diagnose-Tool CANape ein. Als XCP on FlexRay Master misst und verstellt CANape einzelne Steuergeräteparameter direkt über FlexRay. Neben Software entwickelt Vector Informatik auch Stacks für Steuergeräte. Mit den FlexRay-Softwarekomponenten lassen sich Applikationen unkompliziert an verschiedene Bus- oder Betriebssysteme anbinden. Für den hardwareseitigen Zugang zu FlexRay-Bussen sorgen passende Businterfaces für die USB-, PCI- und PCMCIA-Schnittstelle eines PC oder Notebooks.
Das notwendige Basiswissen, um sich mit den vielfältigen Entwicklungstätigkeiten rund um die Steuergerätekommunikation im Automobil vertraut zu machen, werden von der Vector Academy [10] im Rahmen von Seminaren zu CAN, LIN, FlexRay und MOST vermittelt.
Die bisher erschienenen drei Teile dieser Beitragsreihe befassten sich allgemein mit dem seriellen Datenaustausch im Automobil, mit CAN und LIN. Im letzten Beitrag wird auf die Übertragung von Multimediadaten mit MOST eingegangen. Der interessierte Leser findet zu den bereits veröffentlichten Themen auf der Internetseite der Vector Academy ergänzende und vertiefende Informationen, unter anderem in Form von E-Books.
Jobangebote+ passend zum Thema
Literatur und Links:
[1] www.destatis.de
[2] www.bosch.de
[3] Mayer, E.: Datenkommunikation im Automobil. Teil 2: Sicherer Datenaustausch mit CAN. Elektronik automotive 2006, H. 8, S. 34ff.
[4] www.tttech.com
[5] www.byteflight.com
[6] can/ttcan>www.can-cia.org/can/ttcan
[7] www.vector-informatik.de
[8] www.flexray.com
[9] www.flexray-solutions.de
[10] www.vector-academy.de
 | Dipl.-Ing., Dipl.-Techpaed. Eugen Mayer hat nach der Berufsausbildung zum Kommunikationselektroniker an der FH Ravensburg/ Weingarten Elektronik und an der Universität Stuttgart Elektrotechnik und Berufspädagogik studiert. Er arbeitet seit 1999 bei der Vector Informatik und ist dort als Senior Trainer tätig. eugen.mayer@vector-informatik.de |
Verwandte Artikel:
Serielle Bussysteme im Automobil I
Serielle Bussysteme im Automobil II
Serielle Bussysteme im Automobil III
Das Netzwerk für das Auto von morgen
Im Anschluss an das statische Segment folgt optional das je Kommunikationszyklus gleich lange dynamische Segment. Auch dieses Segment ist in Zeitschlitze gegliedert, aber nicht in statische Zeitschlitze, sondern in Minislots (Bild 1). Die Kommunikation im dynamischen Segment (Minislotting) basiert ebenfalls auf Zuordnungen und dem synchronen Inkrementieren der Slot-Counter.
Allerdings werden die den Minislots zugewiesenen FlexRay-Botschaften nicht zwangsläufig in jedem Kommunikationszyklus übertragen, sondern lediglich bei Bedarf. Wenn kein Bedarf vorliegt, werden die Slot-Counter nach der definierten Zeit eines Minislots inkrementiert. Bei der Übertragung einer dynamischen FlexRay-Botschaft verzögert sich die Inkrementierung der Slot-Counter um die Zeit der Botschaftsübertragung (Bild 5).
Die Zuordnung einer dynamischen FlexRay-Botschaft zu einem Minislot legt implizit die Priorität der FlexRay-Botschaft fest: Je niedriger die Nummer des Minislots, desto höher ist die Priorität der dynamischen FlexRay-Botschaft, dementsprechend früher erfolgt die Übertragung und folglich ist vor dem Hintergrund eines begrenzten dynamischen Zeitsegments auch die Übertragungswahrscheinlichkeit höher. Diejenige dynamische FlexRay-Botschaft, die dem ersten Minislot zugeordnet ist, wird bei Bedarf auf jeden Fall übertragen, wenn man von einem ausreichend langen dynamischen Zeitsegment ausgeht.
Beim Kommunikationsdesign muss man sicherstellen, dass auch die dynamische FlexRay-Botschaft mit der niedrigsten Priorität übertragen werden kann – zumindest, wenn sonst kein anderer Bedarf mit höherer Priorität vorliegt. Der Designer eines FlexRay-Clusters hat auch darauf zu achten, dass die Übertragung der längsten dynamischen FlexRay-Botschaft möglich ist.
Der Kommunikationszyklus wird durch zwei weitere Zeitsegmente komplettiert (Bild 1). Das Segment „Symbol Window“ dient zur Überprüfung der Funktion des Buswächters und das Zeitsegment „Network Idle Time“ (NIT) schließt den Kommunikationszyklus ab. Während der NIT berechnen die FlexRay-Knoten die zur Synchronisation der lokalen Uhren erforderlichen Korrekturfaktoren. Am Ende der NIT wird im Bedarfsfall die Offsetkorrektur durchgeführt (die Steigungskorrektur findet stets über den ganzen Kommunikationszyklus verteilt statt). Eine Datenübertragung findet während der NIT nicht statt.
Die Übertragung von Signalen in einem FlexRay-Cluster erfolgt mittels der exakt definierten FlexRay-Botschaft, wobei es zwischen der im statischen Segment und der im dynamischen Segment übertragenen FlexRay-Botschaft im Aufbau prinzipiell keinen Unterschied gibt. Sie setzt sich stets aus einem Header, der Payload und dem Trailer zusammen (Bild 6).
Der Header umfasst das 5 bit breite Statusfeld, die ID, die Payload Length und den Cycle Counter. Die Header-CRC (11 bit) sichert Teile des Statusfeldes, die ID und die Payload Length mit einer Hamming-Distanz von sechs. Die ID kennzeichnet die FlexRay-Botschaft und korrespondiert mit einem Zeitschlitz im statischen oder dynamischen Segment. Im dynamischen Segment entspricht die ID der Priorität der FlexRay-Botschaft. Die einzelnen Bits des Statusfeldes spezifizieren die FlexRay-Botschaft genauer. Beispielsweise zeigt das „Sync Frame Indicator Bit“ an, ob die FlexRay-Botschaft zur Uhrensynchronisation verwendet werden darf.
Im Anschluss an den Header folgt die Payload. Insgesamt lassen sich mit einer FlexRay-Botschaft bis zu 254 byte an Nutzdaten transportie-ren. Der Trailer umfasst die den Header und die Payload sichernde CRC (24 bit). Bei einer Payload bis zu 248 byte garantiert die CRC eine Hamming-Distanz von sechs, für eine größere Payload liegt die Hamming-Distanz bei vier [8].
Dem Paradigma zeitgesteuerter Kommunikationsarchitekturen folgend, besteht die grundlegende Logik der FlexRay-Kommunikation in der Auslösung aller Systemaktivitäten durch das Erreichen bestimmter Punkte im Zeitablauf. Den dazu erforderlichen netzwerkweiten Gleichlauf der FlexRay-Knoten wird mittels verteiltem, fehlertoleranten Uhrensynchronisationsmechanismus sichergestellt: Alle FlexRay-Knoten korrigieren mittels regelmäßig übertragener Synchronisationsbotschaften nicht nur laufend den Beginn (Offsetkorrektur), sondern auch die Dauer (Steigungskorrektur) der Kommunikationszyklen (Bild 2). Dadurch erhöht sich sowohl die Bandbreiteneffizienz als auch die Robustheit der Synchronisation.
Der FlexRay-Kommunikation kann entweder ein elektrischer oder ein optischer Physical Layer zugrunde gelegt werden. Für die elektrische Signalübertragung spricht die Einfachheit, woraus sich Kostenvorteile ergeben. Die vergleichsweise kostenintensive optische Signalübertragung zeichnet sich durch eine im Vergleich zur elektrischen Signalübertragung deutlich bessere elektromagnetische Verträglichkeit (EMV) aus.
Die FlexRay-Kommunikation ist nicht an eine bestimmte Topologie gebunden. Eine einfache passive Busstruktur ist genauso möglich wie eine aktive Sterntopologie oder eine Kombination aus beidem (Bild 3). Die Vorteile der aktiven Sterntopologie bestehen primär in der Möglichkeit zum Abschalten von fehlerhaften Kommunikationszweigen beziehungsweise von FlexRay-Knoten sowie im Aufbau größerer Cluster mit idealen Busabschlüssen, wenn die physikalische Signalübertragung elektrisch erfolgt.
Zur Minimierung des Ausfallrisikos sieht FlexRay die redundante Auslegung des Kommunikationskanals vor (Bild 4). Dieser redundante Kommunikationskanal kann allerdings auch zur Erhöhung der Datenrate auf bis zu 20 Mbit/s herangezogen werden. Die Wahl zwischen Fehlertoleranz und erhöhter Übertragungsrate lässt sich für jede einzelne FlexRay-Botschaft treffen.
Schließlich sorgt ein unabhängiger Kontrollmechanismus (Buswächter – Bus Guardian) dafür, dass ein FlexRay-Knoten nur dann Zugang zum Bus erhält, wenn er laut Kommunikationszyklus an der Reihe ist. Dadurch wird die Busmonopolisierung durch einen defekten FlexRay-Knoten (Babbling Idiot) verhindert.
Jeder Kommunikationszyklus ist gleich lang und prinzipiell gegliedert in ein statisches und ein dynamisches Zeitsegment (Bild 1). Von zentraler Bedeutung ist das statische Segment, mit dem jeder Kommunikationszyklus beginnt. Es ist in eine frei definierbare Anzahl von maximal 1023 gleich langen statischen Zeitschlitzen (static slots) unterteilt.
Jedem statischen Zeitschlitz ist eine FlexRay-Botschaft zugeordnet, die von einem FlexRay-Knoten übertragen wird. Die Zuordnung von statischem Zeitschlitz, FlexRay-Botschaft und FlexRay-Knoten erfolgt mittels Slotnummer, Botschaftskennung (Identifier, ID) und dem Wert des auf jedem FlexRay-Knoten implementierten Slot-Counters. Damit pro Zyklus alle FlexRay-Botschaften in der richtigen Reihenfolge zeitlich korrekt übertragen werden, werden die Slot-Counter zu Beginn eines jeden statischen Zeitschlitzes auf allen FlexRay-Knoten synchron inkrementiert. Wegen der garantierten äquidistanten und somit deterministischen Datenübertragung ist das statische Segment prädestiniert für die Übertragung von echtzeit-relevanten Botschaften.
- Serielle Bussysteme im Automobil IV
- Durchgängige Lösung für Entwicklung, Simulation und Verifikation
- FlexRay beantwortet die Frage nach Determinismus und Fehlertoleranz
