Startseite > Automation > FlexRay - Vom Auto in die Industrie?

Feldbusse

FlexRay - Vom Auto in die Industrie?

3. August 2010, 11:18 Uhr | Von Gianfranco Camoirano

▶ Diesen Artikel anhören

Fortsetzung des Artikels von Teil 1

Deterministischer Bus mit hoher Bandbreite

Für Entwickler in der Industrie, in der Echtzeit-Steuerung und höchste Fehlertoleranz weit verbreitete Anforderungen sind, ist das deterministische Verhalten von FlexRay von besonderer Bedeutung. Bild 2 zeigt die Frames einer FlexRay-Übertragung: Während die gesendeten Meldungen im statischen Segment eine hohe Priorität haben (jeder Knoten verfügt über ein vordefiniertes Zeitfenster mit fester Länge), weisen die im dynamischen Segment gesendeten Meldungen eine niedrige Priorität auf.

Im Rahmen des TDMA-Verfahrens von FlexRay haben alle Knoten zugewiesene Zeitfenster. Bei den dynamischen Segmenten hängt die Länge des Fensters jedoch von der Größe der Meldung ab. Außerdem haben Zeitfenster mit hoher Priorität Vorrang gegenüber dynamischen Zeitfenstern. Dieser, als »Network Idle Time« (NIT) bezeichnete Teil gewährleistet, dass alle Knoten vor dem Beginn des nächsten Zyklus wieder synchronisiert werden können.

Bild 3 gibt eine ausführliche Übersicht über die Rahmenabfolge des Protokolls. Dies zeigt deutlich die feste Länge der statischen Fenster hoher Priorität und die variable Länge der dynamischen Segmente. Die Abbildung veranschaulicht auch, dass hochpriore Daten eine garantierte Latenz haben und nicht durch Buskonflikte verzögert werden.

Das TDMA-Verfahren bei FlexRay unterscheidet sich von der Single-Master-/Multiple-Slave-Anordnung, wie sie bei industriellen Feldbussen üblich ist. Für einen industriellen Feldbus ist es außerdem normal, nur einen einzigen physikalischen Bus zu verwenden. FlexRay dagegen unterstützt den Einsatz von zwei physikalischen Bussen, die zur Bereitstellung von Redundanz oder zur Erhöhung der Bandbreite oder Störfestigkeit verwendet werden können. Auch wenn einige industrielle Feldbusse eine höhere Datenrate als FlexRay angeben, sollte auf keinen Fall die von FlexRay gebotene Kombination aus hoher Datenrate und hoher Störfestigkeit übersehen werden.

Dank dieser Eigenschaften nämlich konnte FlexRay Anwender im Automobilbereich für sich gewinnen – das erste Serienfahrzeug mit einem FlexRay-Netzwerk war ein BMW X5, der 2006 eingeführt wurde. Zweifellos gehen die Halbleiterhersteller davon aus, dass FlexRay eine breite Anwendung in den Fahrzeugen finden wird, sodass ihre Investitionen der letzten Jahre nun Früchte tragen.

Flexray-Controller im Überblick

Ein FlexRay-Netzwerksystem umfasst folgende Hauptkomponenten:

Mikrocontroller oder Mikroprozessor mit integriertem oder diskretem Controller,
physikalische Schicht,
Software-Stack.

Freescale Semiconductor hält große Marktanteile im Kfz-Bereich und hat eine nennenswerte Anzahl von FlexRay-Produkten im Programm. Mit den Mikrocontrollern MC9S12XFxxx, MPC551xG, MPC5674F, MPC5561 und MPC5567 bietet das Unternehmen die größte Auswahl an Produkten, die alle diesen neuen Bus unterstützen. Freescale hat auch einen unabhängigen FlexRay-Controller im Portfolio, den MFR4310.

Ein FlexRay-Bus kann darüber hinaus mit einem ProASIC3-FPGA von Actel gesteuert werden, das über einen ARMCortex-M1-Kern verfügt. Bei diesem Bauelement kann Actel über einen externen Partner FlexRay-IPFunktionen anbieten.

Zu den führenden Anbietern von Bauelementen für die physikalische Schicht (Physical-Layer-Devices (PHYs)) für FlexRay zählen NXP Semiconductors und austriamicrosystems. Neben dem TJA1080A als Active-Star- oder als Node-Transceiver bietet NXP mit dem TJA1081 bzw. dem TJA1082 zwei FlexRay-Node-Transceiver. Mit dem AS8220, dem AS8221 und dem AS8224 bietet austriamicrosystems ebenfalls eine Reihe von Bauelementen.

Natürlich müssen die Entwickler auch einen FlexRay-Software-Stack implementieren. Dazu stellt der Markt bereits eine beträchtliche Auswahl zur Verfügung. Alle Anwender, die CANoder LIN-Anlagen entwickelt haben, werden mit den wichtigsten Software-Anbietern vertraut sein. Freescale kann (über Dritte) ebenfalls Software-Unterstützung anbieten. Doch der Stack ist nicht die einzige Anforderung: Da Entwicklungsingenieure auch Entwicklungswerkzeuge benötigen, sind es hier wieder dieselben Firmen, die neben der Protokoll-Software häufig auch Protokollanalysatoren und andere Werkzeuge zur Verfügung stellen.