XCP als Kommunikationsprotokoll für Mess- und Kalibrieranwendungen
Steuergeräte-Kalibrierung in der Produktentwicklung
Fortsetzung des Artikels von Teil 3
XCP ermöglicht die Anbindung von Fahrzeugsystemen an Standard-PCs
Als Master für die Mess- und Kalibrieraufgaben kommen praktisch ausschließlich PC-Plattformen zum Einsatz. Für direkte Verbindungen zu Automotive-Bussystemen wie CAN, LIN, FlexRay, MOST oder K-Line ist der PC in der Regel mit einer oder mehreren Hardware-Schnittstellen ausgestattet. Darüber hinaus ist der XCP-Master in der Lage, PC-Standardschnittstellen wie Ethernet, USB und RS 232 zu nutzen. Bei solchen Lösungen fallen keine weiteren Kosten für Schnittstellen-Hardware an. Realisierbar sind auf diese Weise Mess- und Kalibriersysteme mit Debug-Schnittstellen (JTAG, TRACE etc.) und Speicheremulatoren. Prinzipiell eignen sich die Standard-PC-Schnittstellen auch zur Ankopplung von Gateways für verschiedene Bussysteme; denkbar wäre etwa auch FlexRay über Ethernet. Außerdem gibt es noch konventionelle analoge und digitale I/O-Kanäle, die bei vielen Entwicklungs- und Testanordnungen für besonders zeitkritische Messungen genutzt werden können.
Ein wesentlicher Vorteil beim Einsatz von XCP liegt darin, dass für alle diese Anwendungen ein einziges standardisiertes Protokoll ausreicht. Ohne XCP müsste man für jeden Kommunikationskanal einen proprietären Treiber implementieren, was neben einem Performance-Verlust auch eine erhöhte Gefahr von unerwünschten Wechselwirkungen und Instabilitäten bedeuten würde.
Jobangebote+ passend zum Thema
Universeller XCP-Treibercode ist vielseitig einsetzbar
Bei allen Kommunikationsvorgängen kommt ein und derselbe XCP-Treibercode zur Anwendung. Dieser kann zum Senden einiger weniger Bytes dienen, die beispielsweise von kleinen 8-bit-Prozessoren mit integrierter serieller Schnittstelle stammen können. Ebenso funktioniert derselbe Code auch zum Senden von Datenmengen mit 32-bit-Prozessoren über Hochgeschwindigkeitsnetze wie Ethernet.
Da sich ein XCP-Treiber aus obligatorischen und optionalen Funktionen zusammensetzt, lässt sich die Treibergröße in Richtung der verfügbaren Speicher-Größe skalieren. Im Steuergerät wird der Ressourcenverbrauch dadurch bestimmt, ob man den Schwerpunkt auf hohen Datendurchsatz oder geringe Prozessorbelastung und Speicher-Größe legt.
Ereignisgesteuerte oder zyklische Datenerfassung möglich
Steuergeräte arbeiten in diskreten Zeitintervallen. Die Länge eines solchen Zeitintervalls kann fest (z.B. 10 Millisekunden) oder ereignisabhängig (z.B. eine Motordrehung) definiert sein. Bei fest definierten Zeitintervallen wird über einen Timerablauf das Ende der Zeitscheibe angezeigt. Die Aufgabe des Steuergerätes liegt nun darin, alle Berechnungs- und Regelaufgaben innerhalb der jeweiligen Zeitscheibe zu erledigen. Um nun korrelierte Daten aus dem XCP-Slave zu erhalten, wird der DAQ-Mechanismus des XCP-Protokolls genutzt. Dabei teilt der XCP-Master vor Beginn der Messung dem Slave mit, welche Signale zum Ablauf bestimmter Ereignisse gemessen werden sollen. Tritt nun das Ereignis ein (z.B. der 10-ms-Timer läuft ab), so liest der XCP-Slave die vorher definierten Daten aus dem Speicher, kopiert sie in einen geschützten Speicher-Bereich und versendet sie in Form von Botschaften an den Master. Damit ist sichergestellt, dass die Werte aus dem gleichen Ereigniszyklus stammen und entsprechend korrelieren.
Der Master nimmt die mit einem Zeitstempel versehenen Daten in Empfang und speichert sie in einer Messdatei ab. Der Zeitstempel wird dabei entweder vom XCP-Slave als Datum mit versendet oder er wird von der jeweiligen Schnittstellen-Hardware den Botschaften zugeordnet. In der Messdatei werden sämtliche Daten anhand der Master-Zeitbasis synchronisiert und anschließend weiterverarbeitet, etwa, indem man die Messwerte auf einer globalen Zeitachse visualisiert (Bild 5). In einem Schaubild sind so mehrere Datenkanäle von verschiedenen XCP-Slaves konsistent darstellbar.
Bei der zyklischen Datenerfassung bietet XCP auch Unterstützung für Kaltstartmessungen und steuergeräte-interne Zeitstempel. Bei der Kaltstartmessung lässt sich das Steuergerät derart konfigurieren, dass es sofort nach dem Einschalten mit dem zyklischen Versenden von Daten beginnt, ohne dass der Master dies explizit veranlasst. Verwendet man den steuergeräte-internen Zeitstempel, ist für die spätere Auswertung nicht der Zeitpunkt des Empfangs beim Mess- und Kalibriersystem relevant, sondern der Zeitpunkt, an dem die Daten im XCP-Slave entstanden sind. Damit lassen sich Ungenauigkeiten eliminieren, die auf eventuelle Verzögerungen, ausgelöst durch zu hohe Buslast oder zu geringe Datenübertragungsrate, beim Übertragungsvorgang zurückzuführen sind.
XCP ist in der Lage, auf der Basis verschiedener Transportschichten dieselbe Protokollschicht zu nutzen. Damit handelt es sich um ein universelles Mess- und Kalibrierprotokoll, das unabhängig vom verwendeten Netzwerktyp arbeitet. ASAM definiert als Standard derzeit die Transport Layer „XCP on CAN“, „XCP on SxI“ (SPI, SCI), „XCP on Ethernet“ (TCP/IP und UDP/IP), „XCP on USB“ und „XCP on FlexRay“. Die zuletzt genannte Variante ist das jüngste Mitglied der Protokollfamilie und seit Frühjahr 2006 spezifiziert. Eine technische Besonderheit von XCP on FlexRay ist unter anderem die dynamische Bandbreitenregelung. Ein Mess-, Kalibrier- und Diagnose-Tool (MCD-Tool; Measurement, Calibration, Diagnosis) wie CANape [2] identifiziert damit die noch freie Bandbreite und weist diese dem aktuellen Applikationsdatenverkehr dynamisch und sehr effizient zu. Die freie Bandbreite wird somit optimal für die XCP-Kommunikation genutzt und beeinflusst die normale FlexRay-Kommunikation kaum.
Als weitere Möglichkeiten für die Zukunft denkt man über „XCP on LIN“ nach; ebenfalls möglich wäre ein „XCP on K-Line“ oder „XCP on MOST“, falls aus Anwenderkreisen entsprechende Nachfrage dazu kommt. Durch die Vielfalt der unterstützten Transport Layer ist in der Entwicklungsphase eine einfache Migration von Lösungen mit hoher Datenübertragungsrate, wie Ethernet und USB, zu einer für die Serie benötigten CAN-Schnittstelle möglich.
Das Mess- und Kalibriersystem übernimmt die Rolle des XCP-Masters, während das Steuergerät als Slave fungiert. Master und Slave kommunizieren jeweils über die in ihnen eingebundenen XCP Driver. Für jeden Slave gibt es eine Steuergeräte-Beschreibungsdatei, in der unter anderem Zuordnungen zwischen symbolischen Variablennamen und den zugehörigen Adressen, den physikalischen Umrechnungsregeln und auch die Kommunikationsparameter spezifiziert sind. Der XCP-Master kann aus diesen A2L-Beschreibungsdateien alle für ihn notwendigen Informationen herauslesen.
Im Detail unterscheidet man bei der Kommunikation via XCP zwischen „Command Transfer Object“ (CTO) und „Data Transfer Object“ (DTO). Der Master sendet über ein CTO beispielsweise ein Kommando über den Bus an das Steuergerät, welches dieses nach der Ausführung des angeforderten Dienstes über denselben Weg quittiert. Als CTOs stehen CMD (Command), RES (Response), ERR (Error), EV (Event) und SERV (Service Request Processor) zur Verfügung. Die Data Transfer Objekte DAQ (Data Acquisition) und STIM (Stimulation) dienen dem ereignisgesteuerten Lesen von Messgrößen aus dem Speicher beziehungsweise dem Schreiben von Werten in den Speicher des XCP-Slave (Bild 4).
- Steuergeräte-Kalibrierung in der Produktentwicklung
- Steuergeräte via XCP reprogrammieren
- Kennlinien und Kennfelder optimieren
- XCP ermöglicht die Anbindung von Fahrzeugsystemen an Standard-PCs
