XCP on FlexRay – Herausforderungen bei der Funktionsentwicklung und der HiL-Simulation
Zum Protokoll, bitte
Fortsetzung des Artikels von Teil 1
Anforderungen bei Funktionsentwicklung und Steuergerätetest
Wegen der Komplexität moderner Steuergeräte und der kurzen Entwicklungszeiten werden für neue Steuergerätegenerationen nur selten alle Software-Funktionen neu entwickelt. In der Regel wird der bereits existierende Code angepasst und erweitert. In diesem Zusammenhang stellt die Bypass-Methode einen etablierten Entwicklungsansatz dar, bei dem nur die neuen oder zu modifizierenden Funktionen auf einem Rapid-Control-Prototyping-System (RCP) berechnet werden. Über geeignete Steuergeräteschnittstellen werden dabei Ein- und Ausgangsvariablen der Bypass-Funktion ausgetauscht und die Berechnung synchronisiert. Aus Kostengründen ist es häufig wünschenswert, den existierenden Fahrzeugbus und den vorhandenen Kabelbaum zum Steuergerät für die Bypass-Kommunikation zu nutzen. Primäres Ziel bei der Funktionsentwicklung ist es, neue Funktionen mittels schneller Iterationen entwerfen und absichern zu können, ohne sich mit Details zur Kommunikationsschnittstelle auseinandersetzen zu müssen. Aufgrund der Komplexität von FlexRay stellt jedoch die Verwendung von XCP on FlexRay als Bypass-Schnittstelle besondere Herausforderungen an Entwicklungswerkzeuge.
Jobangebote+ passend zum Thema
Der automatisierte Steuergerätetest mit Hilfe der Hardware-in-the-Loop-Simulation (HiL) erfordert ebenfalls, steuergeräteinterne Größen in Korrelation mit der Echtzeit-Simulation zu erfassen und zu beeinflussen. Es besteht der Bedarf, ohne Anpassung und Neukompilierung des Simulationsmodells flexibel auf beliebige Größen im Steuergerät zugreifen und unterschiedliche Software-Stände testen zu können. Darüber hinaus ist es notwendig, die Kommunikation zwischen HiL-Simulator und Steuergerät während der Simulation automatisch wieder aufbauen zu können, falls die Kommunikation temporär unterbrochen wurde.
Herausforderungen bei XCP on FlexRay
Das XCP-Protokoll basiert auf einem Master-Slave-Konzept, bei dem ein Applikations- und Messwerkzeug auf einem MS-Windows-PC oder eine Echtzeit-Simulationsplattform den Master darstellt. Die Steuergeräte repräsentieren XCP-Slaves, wobei der XCP-Treibercode in der Regel in der Serien-Software verbleibt. Das XCPProtokoll ist unabhängig von der physikalischen Datenübertragungsschicht. Bei XCP on FlexRay besteht die besondere Herausforderung, die XCP-typische ereignisorientierte Kommunikation in die deterministische Kommunikation des FlexRay-Busses zu integrieren. Zu diesem Zweck werden in dem FlexRay-Kommunikationszyklus Slots für die XCP-Kommunikation reserviert und diese in der FIBEX-Netzwerkbeschreibungsdatei als XCP-Slots gekennzeichnet.
Die Kommunikation über FlexRay mit allen im Netzwerk vorhandenen Steuergeräten erfordert wegen der im Datenstrom der XCP-Steuerbefehle (Command Transfer Objects, CTO) vorhandenen slave-bezogenen Knotenadresse typischerweise nur zwei einzelne XCP-Slots für den Austausch von Kommando-Antwort-Sequenzen (CMD, RES).
Je nach benötigter Bandbreite, insbesondere mit Bezug auf die zyklische Übertragung von Mess- und Stimulusdaten (DAQ, STIM) über Data Transfer Objects (DTO), kann die Kommunikation um weitere XCP-Slots ergänzt werden (Bild 2). Generell können XCP-Slots sowohl im statischen als auch im dynamischen Segment des FlexRay-Kommunikationszyklus liegen. Die Mehrzahl der XCP-Slots findet man in der Regel im dynamischen Segment, um für Messaufgaben Bandbreite dynamisch erweitern zu können und nicht statisch zuweisen zu müssen.
- Zum Protokoll, bitte
- Anforderungen bei Funktionsentwicklung und Steuergerätetest
- Zum Protokoll, bitte
- Anwendungsbeispiele
