FlexRay-Komponenten testen ohne FlexRay-Cluster
Restbussimulation für FlexRay-Systeme
Fortsetzung des Artikels von Teil 1
Restbussimulation für FlexRay-Systeme
Der sich daraus ergebende Anforderungskatalog sollte dann zu einem gangbaren Weg für die Realisierung einer FlexRay-Restbussimulation führen. Der folgende Abschnitt gibt einen Überblick über bereits umgesetzte Lösungen und derzeit in Planung befindliche Projekte von Decomsys.
Da der wichtigste Anwendungsfall für die FlexRay-Restbussimulation die Verbesserung eines bereits vorhandenen Systems mit der FlexRay-Option ist, setzt Decomsys auf einen modularen Ansatz, in dem das Anwendungsmodell und das FlexRay-Modell getrennt werden. Die derzeit laufenden Projekte benötigen eine Schnittstelle auf Signalebene, da die verteilte Anwendung lediglich hinsichtlich der Kommunikationsservices auf FlexRay angewiesen ist. Die internen Abläufe von FlexRay (zum Beipiel, wie ein Sende-Frame aussieht) sind nicht wirklich von Interesse auf dieser Ebene. Daher kommt das gesamte FlexRay-Modell in ein eigenes Subsystem, das auf einem PC oder einer FlexRay-Prototyping-Plattform läuft.
Der PC integriert die FlexRay-Funktionen mittels so genannter „Flexim“-Module, die mit einem Kommunikationscontroller und den notwendigen Physical-Layer-Treibern ausgestattet sind. Dieser Ansatz kann auch für einige andere Prototyping-Plattformen verwendet werden. Eine zweite Möglichkeit wird in naher Zukunft verwirklicht: Anstatt getrennte Module für FlexRay zu benutzen, werden IP-Module des FlexRay-Controllers wiederverwendet, die von den unterschiedlichen Herstellern lizenziert werden. Mittels FPGA wird die Controllerfunktion direkt auf der Prototyping-Plattform implementiert.
Beide Ansätze haben ihre Vorteile. Die PC-Lösung verwendet Standardbestandteile und ist punkto Rechenleistung in hohem Grade skalierbar. Daher kann sie auch für die Simulation großer FlexRay-Cluster verwendet werden, indem sie um zusätzliche PCs erweitert wird. Die Nachteile liegen in den eher hohen Anfangskosten für die Hardware und in der Größe der Hardware selbst.
Der zweite Ansatz, der eine bewusst kleine Prototyping-Plattform verwendet, erlaubt das Design kostengünstigerer Systeme, die auch außerhalb des Labors verwendbar sind (z.B. für Systemtests im Auto). Verglichen mit der PC-Lösung sind sie in ihrer Leistung begrenzt (Anzahl der Signale und der zusätzlichen Services). Beide Lösungen können aber benutzt werden, um das Anwendungsmodell von den Anwendungsservices zu entlasten (z.Zt. werden Alive Counters und Anwendungs-CRC unterstützt). Abhängig von der vorhandenen CPU-Kapazität ist es möglich, zeitkritische Aufgaben auf die CPU des FlexRay-Subsystems auszulagern.
Jobangebote+ passend zum Thema
Schnittstelle als Subsystem
Während die Koppelung des FlexRay-Modells mit der EUT immer die gleiche einfache FlexRay-Busverbindung ist, wird die Schnittstelle zwischen dem Anwendungsmodell und dem FlexRay-Subsystem nicht durch einen Standard definiert. Die grundlegende Funktion des Anwendungsmodells für eine FlexRay-Subsystemschnittstelle ist die Übertragung der Signale, die für die Prüfung der EUT benötigt wird. Zwei Faktoren sind für diese Schnittstelle entscheidend: die Last, die der Zugang zu dieser Schnittstelle auf beiden Seiten verursacht, und die Latenz der Schnittstelle, die auch durch die Last für den Schnittstellenzugang beeinflusst wird.
- Restbussimulation für FlexRay-Systeme
- Restbussimulation für FlexRay-Systeme
- Modellierung des FlexRay-Verhaltens
- Restbussimulation für FlexRay-Systeme
