Der Einsatz von FlexRay in einem Oberklasse-Fahrzeug
Oben angekommen
Fortsetzung des Artikels von Teil 2
Oben angekommen
Die Basis-Software (BSW) einer AUTOSAR-ECU für FlexRay umfasst daher die folgenden Software-Module:
- FlexRay-Treiber: Wird speziell auf die FlexRay-Hardware ausgerichtet und entsprechend den Anforderungen einer ECU an die Netzwerk-Kommunikation konfiguriert.
- FlexRay-Schnittstelle: Wird gemäß den Zeitvorgaben von Versandprozessen, Empfangsprozessen, Versandmeldungen und Empfangsbestätigungen aus dem AUTOSAR-Modell konfiguriert.
- PDU-Router: Regelt den Ablaufplan von FlexRay-PDUs und eventuell anderen Kommunikationssystemen.
- Transport-Protocol-Schicht: Bewältigt die TP-Kommunikation für verschiedene Funktionen. Das TP kann speziell für das Kommunikationsprotokoll ausgelegt sein.
- COM-Schicht: Steuert die signalbasierte Kommunikation durch das Packen/Entpacken von Applikationssignalen aus den Netzwerk-PDUs.
- Network-Management-Schicht: Ist speziell auf das Kommunikationsprotokoll ausgelegt (FlexRay-NM).
- Andere kommunikationsbezogene Schichten; z.B. XCP für die Daten-Erfassung und -Kalibrierung.
Jobangebote+ passend zum Thema
Beim Einsatz standardisierter Software (SSW) ist besonderes Augenmerk auf die Leistungsdaten – CPU-Last sowie den RAM- und ROM-Verbrauch – zu legen. Eine SSW mit einem Ressourcen-Verbrauch, der deutlich höher als der von maßgeschneiderten, proprietären Lösungen ist, stellt einen klaren Nachteil für die Produktionseinführung dar, auch wenn die Vorteile der Wiederverwendbarkeit bei SSW groß sind. Es lässt sich beobachten, dass der mögliche Ressourcen-Verbrauch einer standardisierten Lösung im Vergleich zu einer optimierten Variante mit Größe, Komplexität und Modularität der Software-Schichten steigt.
Für einen FlexRay-Serieneinsatz ist es wichtig herauszufinden, wo eine AUTOSAR-Lösung Leistungsnachteile zur Folge hat und wie diese minimiert werden können. Daher liegt der Fokus auch darauf, den Einfluss von Netzwerken und deren Kommunikationsbedarf auf die Leistung von SSW zu analysieren und optimierte Spezifikationen und Implementierungen zu erstellen. Es ist gelungen, eine produktionstaugliche SSW für FlexRay zur Verfügung zu stellen. In größeren ECUs können die Kommunikationsanforderungen über die verschiedenen Datenschnittstellen mehr als tausend Datensignale umfassen, die in hunderten PDUs und schließlich Frames auf ein Kommunikationsnetzwerk gepackt und aus ihnen entpackt werden (Bild 1). Um die ECU-Ressourcen auf einem vergleichbaren Niveau mit aktuell üblichen CAN-Steuergeräten zu halten, wurden intelligente Optimierungen in der Funktionsumsetzung durchgeführt. Eine enge Kooperation zwischen Automobilhersteller, Zulieferer und Software-Entwickler ist dabei für die erfolgreiche Optimierung unerlässlich.
Die Konzepte einer echten Bus- und einer passiven Stern-Architektur, wie sie in der EPL-Spezifikation definiert sind, erwiesen sich für die geforderten Netzwerkgrößen und -topologien als nicht ausreichend. Daher wird eine aktive Stern-Architektur verwendet. Prüfstände mit speziell entwickelter Hard-und Software, die das Verhalten von FlexRay unter verschiedenen Betriebsbedingungen analysieren, wurden eingesetzt. Damit ist es gelungen, die robusteste und kostengünstigste Topologie für das FlexRay-Netzwerk zu bestimmen. Die Ergebnisse werden sich für kommende Generationen von FlexRay-Netzwerken als nützlich erweisen, selbst wenn Fortschritte bei EPL-Spezifikation und Leitungstreiberkomponenten dem zukünftigen FlexRay-Netzwerk-Design mehr Freiheit eröffnen werden.
Verifikation von FlexRay-Konfigurationsparametern
Während ein CAN-Kommunikationscontroller zwischen fünf und zehn globale Konfigurationswerte kennt, wird die Konfiguration eines FlexRay-Kommunikationscontrollers durch viele Parameter bestimmt:
- Zwei Dutzend „globale“ Parameter (g-Parameter) werden systemweit definiert und müssen beim Aufbau jedes FlexRay-Controllers konfiguriert werden.
- 16 weitere globale Parameter spiegeln sich zwar nicht unmittelbar in den Konfigurationsregistern wider, müssen aber bei der Berechnung der zwei Dutzend ECU-lokalen Parameter (p-Parameter) beachtet werden, weil sie für den ordnungsgemäßen Betrieb des FlexRay-Kommunikationscontrollers erforderlich sind.
Die viel umfangreichere Datenmenge, die von einem FlexRay-Controller bewältigt werden muss (auf einem FlexRay-Kanal 20-mal so viel wie bei CAN) führte zur Einführung verschiedener Optionen zur Kommunikation zwischen FlexRay-Controller und dessen Host-Prozessor über parallele und serielle Schnittstellen wie SPI, MLI und DMA. Der richtige Einsatz dieser Schnittstellen – einschließlich der zeitlichen Beschränkungen bei der Übertragung von Inhalten aus Puffern – erfordert viele Konfigurationsinformationen.
In beiden Fällen (CAN und Flex-Ray) bezieht sich dies nur auf das Basic Setup des Kommunikationscontrollers. Zusätzlich muss die Konfiguration die Frame-Puffer für die eigentliche Kommunikation festlegen. Der Spielraum bei der Konfiguration von FlexRay ist auf Grund des deutlich umfangreicheren Kommunikations-RAMs sowie in Folge der zahlreichen Optionen für die Puffer-Konfiguration viel größer als bei CAN.
- Oben angekommen
- Oben angekommen
- Oben angekommen
