Partner demonstrieren auf dem FlexRay-Symposium die erfolgreiche Systementwicklung
Symposium: FlexRay fährt
Fortsetzung des Artikels von Teil 1
Der Anfang ist gemacht
In FlexRay steckt viel Potential. Das Pilotprojekt von BMW ist erst der Anfang und hat gezeigt, dass ein FlexRay-System – einmal korrekt aufgesetzt – stabil läuft. Eine durchgängige Tool-Unterstützung ist für die verschiedenen Entwicklungsstufen unbedingt anzuraten, um den Überblick über die mannigfaltigen Anforderungen zu behalten. Tools erleichtern die Arbeit der Entwickler und helfen mit umfangreichen Kontrollmechanismen, Fehler von vornherein zu vermeiden. Eine Vielzahl rechen- und kommunikationsintensiver Anwendungen kann dank FlexRay bald Wirklichkeit werden. sj
Jobangebote+ passend zum Thema
Literatur:
[1] Mayer, E.: Serielle Bussysteme im Automobil. Teil 4: FlexRay für den Datenaustausch in sicherheitskritischen Anwendungen. Elektronik automotive 2007, H. 2, S. 42ff.
 | Dr. rer. nat. Carsten Böke |
Verwandte Artikel:
FlexRay in Betrieb nehmen
Bereit für FlexRay
Wachstum auf dem FlexRay-Chipmarkt
Die Entscheidung für eine harte Synchronisation (eine Tabelle springt zu einem definierten Ausführungspunkt oder wird kurz angehalten) oder eine weiche Synchronisation (bei jedem „Expiry Point“ wird angeglichen; diese Punkte sind aber unregelmäßig verteilt, daher ergibt sich ein etwas unregelmäßigeres Verhalten bei der Angleichung der Zeit) fällt anhand der Frage, ob die Applikation Sprünge und Pausen verträgt oder nicht.
Die Überwachung der Synchronität und der Datenkonsistenz ist während der Entwicklungsphase Aufgabe der Software-Tools. „Wir müssen ein Modell synchron abarbeiten können, ansonsten würden Daten verlorengehen“, stellte Dr. Carsten Böke ein Merkmal des Vector Tools CANoe heraus. Böke demonstrierte, welche Mechanismen das Tool bereitstellt, um die Synchronität zu gewährleisten und inkonsistente Daten zu erkennen. Grundlegende Architektur von CANoe zur Modellausführung ist ein Benachrichtigungskonzept durch so genannte „Notification Handler“. Dies umfasst die Modellaktivierung beim Erhalt von Nachrichten, beim Ablaufen von Timern oder bei der Erkennung von Fehlerzuständen. Insbesondere wurde dieses Konzept für FlexRay um synchrone Benachrichtigungen zu bestimmten Zeitpunkten im FlexRay-Zyklus erweitert (Bild 3). Zudem stellte er eine optimal auf die hohen Zeitanforderungen von FlexRay-Systemen zugeschnittene und für kleinere und mittlere Hardware-in-the-Loop-Simulationen geeignete Plattform mit CANoe RT und spezieller Hardware-Unterstützung vor.
Neue Software-Konzepte müssen, um zukunftsfähig zu sein, nach AUTOSAR-Richtlinien entworfen werden“, so Dirk Großmann, verantwortlich für die Entwicklung der FlexRay-Basis-Software. Da Vector Informatik Mitglied im AUTOSAR-Konsortium ist, fließen die dort gewonnenen Ergebnisse und Festlegungen sofort in die FlexRay-Entwicklung ein (Bild 4). FlexRay-Interface und FlexRay-Treiber von Vector sind bereits AUTOSAR-konform. Dadurch können diese Komponenten heute schon unabhängig von ihrem späteren Einsatzfall entwickelt werden und sind flexibel auf unterschiedliche Fahrzeug- und Plattformvarianten skalierbar. Der Flex-Ray-Treiber abstrahiert den „Communication Controller“ (CC), das Flex-Ray-Interface stellt die Zugriffe auf einzelne PDUs (Protocol Data Units) zeitlich entkoppelt vom FlexRay-Schedule bereit. Darüber hinaus bietet Vector AUTOSAR-konforme Implementierungen des Netzwerk-Managements und Transportprotokolls an. Als Ergänzung zu AUTOSAR ist das XCP-Protokoll im FlexRay-Stack integrierbar. Großmann wies außerdem auf die Möglichkeit des Flashens über Flex-Ray hin. „Ein Szenario ist, das Protokoll komplett umzustellen und für das Flashen ein eigenes Schedule zu verwenden.“
Auf die Kalibrierung der Steuergeräte mittels XCP ging Oliver Kitt in seinem Vortrag näher ein. Er ist bei Vector für die Integration von Hardware-Schnittstellen für das Mess-, Kalibrier- und Diagnose-Tool CANape verantwortlich. XCP ist ein von ASAM standardisiertes Kalibrierungsprotokoll. Das X steht dabei als Platzhalter für verschiedene „Transport Layer“.
So gibt es „XCP on CAN“, „XCP on Ethernet“ und seit Februar 2006 auch „XCP on FlexRay“. Es handelt sich um ein Single-Master/Multiple-Slave-Konzept, bei dem sehr effizient und mit variabler Datenübertragungsrate mit Steuergeräten zu Mess- und Kalibrierzwecken kommuniziert werden kann. Während der Slave im FlexRay-Stack integriert werden kann, stellt das Tool selbst die Master-Unterstützung für das Protokoll bereit. Die Übertragungsrate wird dabei je nach Bedarf zur Laufzeit den einzelnen Knoten neu zugewiesen. Um die Puffer-Rekonfiguration bei „XCP on FlexRay“ realisieren zu können, benötigt man die „Enhanced Version“ des FlexRay-Treibers. Auch hier zeigt sich wieder die flexible Handhabung der Komponenten.
Obwohl der Start bei einem neuen System naturgemäß schwierig ist, konnte die Integration der verschiedenen Komponenten relativ schnell umgesetzt werden. „Die zeitgesteuerte Kommunikation ist eine ideale Basis, um Komponenten oder Software-Teile verschiedener Hersteller zusammensetzen zu können“, weiß Florian Hartwich. Er arbeitet bei der Robert Bosch GmbH im Bereich Netzwerke für Kraftfahrzeuge, hat im FlexRay-Konsortium am Protokoll mitgewirkt und war schon an der Entwicklung und Standardisierung von CAN und TTCAN beteiligt. Da jede Applikation zu einem genau definierten Zeitpunkt Botschaften sendet und weiß, wann es welche zu empfangen hat, können die Komponenten eines verteilten Systems später einfacher zusammengefügt werden.
Die wichtigsten Aufgaben sind bereits beim Start der Entwicklung eines FlexRay-Systems zu bewältigen. Alle Parameter, die das System grundsätzlich beschreiben – wie Übertragungsrate, Zykluszeit, Anzahl der Slots, Slotlänge oder die Verteilung der Nachrichten auf das statische und dynamische Segment –, werden zu Beginn definiert. Da den Sendetasks feste Slots zugeordnet sind, muss man sich schon bei der Projektdefinition im Klaren sein, wie die Belegung der Slots mit Nachrichten strukturiert wird, welche Applikationen vielleicht besser im dynamischen, ereignisorientierten Segment aufgehoben sind und wie viele Slots für Applikationen späterer Baureihen reserviert werden (Bild 1).
Gerade bei verteilten Systemen ist es aber wichtig, den Überblick zu behalten. Anfangs wissen Netzwerkdesigner noch gar nicht im Detail, wie die späteren realen Applikationen wirklich kommunizieren und welche Ausführungszeiten diese dann haben. Steuergeräte-Entwickler hingegen möchten sich ausschließlich auf die Applikationsentwicklung konzentrieren, ohne ständig die Zeitbedingungen der gesamten FlexRay-Kommunikation im Auge behalten zu müssen. FlexRay-Daten in einem Zyklus müssen aber konsistent sein, und die Synchronität der Anwendung mit dem zeitgesteuerten Bus muss zu jedem Zeitpunkt gewährleistet sein.
Hartwich wies daher auf die Probleme hin, die eine Inkonsistenz von Daten hervorrufen kann. Es muss unbedingt vermieden werden, dass etwa das Update von Sendedaten während der Übertragung erfolgt, so dass innerhalb des gleichen Frames teilweise alte und neue Daten existieren. BMW hat dieses Problem dadurch gelöst, dass mit „Signal Windows“ sichergestellt wird, dass eine Task nur innerhalb dieses dedizierten Fensters sendet. Ein weiterer Vorteil dieser Maßnahme ist die Entkopplung von Applikation und Kommunikation: Ändert sich der Kommunikations-Schedule, bleibt die Applikation davon unberührt.
In einem echtzeitfähigen System ist die Synchronität der Tasks das zentrale Merkmal, dem man besondere Aufmerksamkeit widmen muss. „Die Frage nach der richtigen Synchronisation der Tabellen ist von entscheidender Bedeutung“, erläuterte Winfried Janz, Teamleiter und Produktmanager für die Entwicklung von OSEK-Echtzeit-Betriebssystemen bei Vector. In seinem Vortrag über OSEKtime und AUTOSAR OS referierte er über die Möglichkeiten, eine „Schedule Table“ gemäß Spezifikation mit der globalen Zeit zu synchronisieren (Bild 2).
- Symposium: FlexRay fährt
- Der Anfang ist gemacht
