FlexRay-Komponenten testen ohne FlexRay-Cluster Restbussimulation für FlexRay-Systeme

In der Restbussimulation werden Nachrichten von (noch) nicht real im Netzwerk vorhandenen Steuergeräten nachgebildet. Auf diese Weise können Steuergeräte getestet werden, ohne dass der komplette Bus aufgebaut werden muss.

FlexRay-Komponenten testen ohne FlexRay-Cluster

In der Restbussimulation werden Nachrichten von (noch) nicht real im Netzwerk vorhandenen Steuergeräten nachgebildet. Auf diese Weise können Steuergeräte getestet werden, ohne dass der komplette Bus aufgebaut werden muss.

Embedded-Systeme erleben in den letzten Jahren einen regelrechten Siegeszug. Was mit wenigen Anwendungen begann, entwickelt sich noch vor der Einführung der X-by-Wire-Techniken zu einem neuen Massenmarkt im Automobilbereich. Die Schlüsselfaktoren liegen hier bei Zuverlässigkeit, Fehlertoleranz, Vorhersagbarkeit – und bei den Kosten, die eine treibende Kraft in diesem Markt sind. Mit anderen Worten: Keine Autofirma der Welt kann mit dem Testen eines Systems vor der Serienproduktion warten, bis alle Knoten eines verteilten Systems vorhanden sind. Und keine ist bereit, für die dafür anfallenden Kosten zu zahlen. Dennoch besteht die Automobilindustrie richtigerweise auf vollständigen Tests, um die Ausfallsicherheit und Systemstabilität zu erhöhen und Kosten für die Integration der verschiedenen Steuergeräte zu verringern.

Der vorliegende Artikel zeigt eine Testlösung für FlexRay-Systeme. Da dieser neue Standard für Kommunikation im Automobil auf TDMA (Time Division Multiple Access) aufbaut, ist es einfacher, die Restbussimulation heranzuziehen, um das Verhalten eines Knotens vor seiner Integration in das gesamte System zu testen und zu validieren.

Mittels Restbussimulation werden Knoten umfangreich und ausführlich getestet, ohne einen vollständigen Cluster aufbauen zu müssen. Der OEM liefert üblicherweise das globale Design und die Beschreibung des Systems bis hinunter zu der Partitionierung der ECUs (Electronic Control Units). Da ein solches System aus tausenden Signalen mit allen Arten von Eigenschaften und Werten besteht, muss die damit verbundene enorme Komplexität verringert werden. Daher müssen erstens die relevanten Signale mit Auswirkung auf die ECU-Anwendung identifiziert werden (Bild 1). Zweitens muss die Konfiguration ein adäquates Timing-Verhalten bieten, um die Simulation des Echtzeit-Verhaltens des gewählten Systems zu ermöglichen.

FlexRay definiert ein striktes Timing, das für alle Knoten hinsichtlich ihrer Kommunikations-Slots verbindlich ist. Diese Eigenschaft reduziert die Komplexität der Schnittstelle zwischen ECU(s) unter Test (EUT) und dem restlichen Cluster. Schließlich ist die Anwendungssicht der Kommunikation unabhängig von der Topologie. Deshalb darf die Schnittstelle des getesteten Gerätes auf eine einfache Verbindung des FlexRay-Physical-Layers reduziert werden, ohne gleichzeitig auch das Modell der Topologie und die einzelnen Knoten des Clusters modellieren zu müssen (Bild 2).

Zwei Beweggründe machen die FlexRay-Restbussimulation so interessant: Entweder soll ein bestehendes System (das z.B. auf CAN beruht) erweitert bzw. ersetzt oder eine neue FlexRay-Anwendung entwickelt werden. Derzeit wird FlexRay vor allem als Ersatz bzw. Erweiterung eines bestehenden Systems eingesetzt. Diese Systeme verfügen bereits über Anwendungsmodelle und Emulationshardware und müssen um die FlexRay-Komponente erweitert werden. So besteht die Restbussimulation aus zwei verschiedenen Teilen: Der eine Teil umfasst das bestehende Anwendungsmodell, der andere besteht aus dem Modell der FlexRay-Kommunikationsschichten, auf der die Anwendung aufbaut – hier als FlexRay-Modell bezeichnet (Bild 3).