XCP als Kommunikationsprotokoll für Mess- und Kalibrieranwendungen

Transkript

1 Steuergeräte-Kalibrierung in der Produktentwicklung (Bild: BMW) XCP als Kommunikationsprotokoll für Mess- und Kalibrieranwendungen Immer mehr elektronische Funktionen für Sicherheit und Komfort finden den Weg in das moderne Automobil. Da die Anzahl der Steuergeräte nicht weiter zunehmen soll, steigt die Komplexität der einzelnen Geräte im Gegenzug an. Einen wichtigen Beitrag bei der Rationalisierung des Entwicklungsprozesses dieser verteilten Systeme leistet das Kommunikationsprotokoll XCP, zu dessen Hauptaufgaben das Messen und Verstellen steuergeräte-interner Größen während der Laufzeit zählt. Ein großer Vorteil des Nachfolgeprotokolls von CCP ist die Unabhängigkeit von der physikalischen Transportschicht. Von Andreas Patzer Steuergeräte mit mehr als Parametern sind heute keine Seltenheit mehr. Da in einem Fahrzeug zahlreiche dynamische Prozesse zu beherrschen sind, gehört die Optimierung von Regelalgorithmen zu den typischen Aufgaben der Steuergerätekalibrierung. Im Falle eines PID-Reglers gibt es bei der Parametrierung von Verstärkungs-, Integral- und Differenzialanteil fast grenzenlose Variationsmöglichkeiten (Bild ). Meistens bedarf es daher einiger Anstrengungen, bis ein hinreichend guter Kompromiss zwischen Stabilität, Schnelligkeit und Einschwingverhalten gefunden ist. Dies lässt sich durch Lesen und gezieltes Verändern der Parameter während der Laufzeit erreichen (Bild 2). Um Zeit und Kosten für die Steuergerätekalibrierung niedrig zu halten, sind die Ingenieure und Techniker auf leistungsfähige Tools und Standards angewiesen, die einen flexiblen Leseund Schreibzugriff auf Variablen bzw. Speicherinhalte gestatten. Für diesen Zweck wurde in den 90er Jahren, während CAN das allein dominierende Vernetzungssystem im Automobil war, als herstellerübergreifender Standard das CAN Calibration Protokoll (CCP) geschaffen. Mit der Weiterentwicklung der Automobilelektronik kamen zusätzliche Bussysteme wie FlexRay, LIN, MOST usw. ins Spiel. CCP stößt durch die Beschränkung auf CAN-vernetzte Anwendungen zunehmend an seine Grenzen, was zur Entwicklung des Nachfolgers XCP führte. Das Universal Measurement and Calibration Protocol (XCP) stammt wie CCP ebenfalls von der Association for Standardization of Automation and Measuring Systems (ASAM) [] und wurde im Jahr 2003 standardisiert. Das X steht für die variable und austauschbare Transportschicht. Über ein Zweischichtenprotokoll trennt XCP Protokollschicht und Transportschicht konsequent voneinander und nutzt ein Single-Master/Multi--Konzept. Je nach Transportschicht hat man es mit XCP on CAN, XCP on Ethernet, XCP on UART/SPI oder XCP on FlexRay zu tun (Bild 3). Ein Master ist in der Lage, gleichzeitig mit verschiedenen s zu kommunizieren. Dazu gehören: Steuergeräte und -Prototypen, Mess- und Kalibrier-Hardware mit Debug-Interfaces oder Speicheremulatoren. 62 Elektronik automotive

2 XCP IIII Entwicklung + Test Rapid-Prototyping-Hardware, HiL-/SiL-Systeme. Um dem Anspruch als universelle Kommunikationslösung für eine Vielfalt von Anwendungen gerecht zu werden, legte der ASAM-Arbeitskreis beim Design von XCP besonderes Augenmerk auf folgende Kriterien: Minimaler Ressourcen-Verbrauch im Steuergerät für RAM, ROM und benötigte Laufzeit, effiziente Kommunikation, einfache Implementierung des s, Plug&Play-Fähigkeit mit geringem Konfigurationsaufwand und kleiner Parameterzahl sowie Skalierbarkeit. Austauschbare Transportschicht universelle Protokollschicht CNTL + - Lad.s+Ra Transfer Fcn Ziel- Verhalten u() x Ke Fcn2 u() x Kt Fcn I Bild. Um den Algorithmus eines PID-Reglers zu optimieren, müssen viele Parameter-Variationen betrachtet werden. (Alle Bilder: Vector Informatik GmbH) 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 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 Masters, während das Steuergerät als fungiert. Master und kommunizieren jeweils über die in ihnen eingebundenen XCP Driver. Für jeden 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 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 Jm.s Transfer Fcn Auswertungszeitraum tatsächliches Verhalten u() x 60/(2 x ) Fcn (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 (Bild 4). N Elektronik automotive

3 I Bild 2. Bei der Parametrierung eines PID-Regler muss ein Kompromiss zwischen Stabilität, Schnelligkeit und Einschwingverhalten gefunden werden. Gezieltes Verändern während der Laufzeit ist hier von Vorteil. Die Ausgangsparameter (links) können entsprechend den spezifischen Anforderungen angepasst werden (rechts). XCP ermöglicht die Anbindung von Fahrzeugsystemen an Standard-PCs XCP on CAN XCP on FlexRay XCP on LIN 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 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 CANape Master XCP on USB XCP on Ethernet XCP on ## XCP on RS 232 I Bild 3. Durch die Trennung von Transport- und Protokollschicht ermöglicht XCP den Einsatz unterschiedlichster Hardware-Schnittstellen. ETH SxI 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. Universeller Treibercode ist vielseitig einsetzbar Bei allen Kommunikationsvorgängen kommt ein und derselbe 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 ETH DPRAM Master CTO CMD funktioniert derselbe Code auch zum Senden von Datenmengen mit 32-bit- Prozessoren über Hochgeschwindigkeitsnetze wie Ethernet. Da sich ein 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. 0 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 zu erhalten, wird der DAQ-Mechanismus des Protokolls genutzt. Dabei teilt der XCP Driver RES ERR EV SERV Command/Response/Error/Event/ Service Request Processor DTO DAQ DAQ Processor Bypass STIM STIM Processor I Bild 4. Beim Single-Master/Multi--Konzept von XCP erfolgt die Kommunikation zwischen Master und über CTOs (Command Transfer Object) und DTOs (Data Transfer Objects). 64 Elektronik automotive

4 Master vor Beginn der Messung dem mit, welche Signale zum Ablauf bestimmter Ereignisse gemessen werden sollen. Tritt nun das Ereignis ein (z.b. der 0-ms-Timer läuft ab), so liest der 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 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 BUS Master I Bild 5. Der Einsatz von Zeitstempel erlaubt bei XCP die Darstellung unterschiedlicher Signale aus verschiedenen Quellen auf einer Zeitachse. auf einer globalen Zeitachse visualisiert (Bild 5). In einem Schaubild sind so mehrere Datenkanäle von verschiedenen s 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 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. Kennlinien und Kennfelder optimieren Neben Regelalgorithmen, die auf der Grundlage mathematischer Modelle basieren, werden in Steuergeräten auch Kennlinien und -felder eingesetzt, die sich aus diskreten Stützwerten zusammensetzen. Um das gewünschte Systemverhalten zu erreichen, ermittelt und optimiert man solche Kennwerttabellen meist experimentell am Prüfstand. Zur Beschreibung der Messgrößen und Verstellparameter dienen die A2L-Dateien. Die Beschreibungsmöglichkeiten in den A2L-Dateien reichen von einfachen Skalarwert-Parametern bis hin zu komplexen Tabellen. Die Beschreibungen umfassen dabei die Datentypen, Umrechnungsregeln zwischen den Roh- und den physikalischen Werten, Abwww.elektroniknet.de Elektronik automotive

5 Input I Bild 6. Mit Hilfe des MCD-Tools CANape kann beim Bypassing ein gewöhnlicher PC verwendet werden. Windows-PC Zyklische Messwerterfassung ECU CANape x y lageschemata der Kennfelder und vieles mehr. Leistungsfähige Kalibrier- Tools wie CANape von Vector Informatik stellen die Kennlinien und Kennfelder in grafischen Diagrammen oder als Zahlenwerte in Tabellen übersichtlich auf dem Bildschirm dar. Rapid Prototyping mit CANape und XCP x y Zyklische Werteinspeisung Modell.DLL y = f(x) Output Während der Steuergeräte-Entwicklung werden neue Funktionen häufig auf externen Simulationssysteme getestet, um sie ohne großen Aufwand berechnen zu lassen. Dazu bietet es sich an, dass der Code des neuen Funktionsmodells auf vorhandenen PCs als preiswerte Ablaufumgebung genutzt werden kann. Um nun das Zusammenspiel der neuen Funktionen, die auf dem PC laufen, mit dem Steuergerät testen zu können, wird eine leistungsfähige Kopplung benötigt, die zeitsynchronisiert Daten zwischen dem Steuergerät und dem PC austauschen kann. Beim Bypassing mit XCP liest der Master per DAQ Daten aus dem Steuergerät aus, übergibt die Werte als Eingangswerte an das Modell und sendet die Ergebnisse des Modells wieder per STIM an das Steuergerät. In Verbindung mit CANape kann dabei das Modell auf dem gleichen PC ablaufen. Für sehr viele Anwendungen sind die damit erreichbare Latenzzeit von deutlich unter 0 ms und der gleichzeitig geringe Jitter absolut ausreichend. Somit stellt jeder vorhandene PC, ohne weiteren Aufpreis, eine vollständige Entwicklungsumgebung dar. Die meist schon vorhandenen dedizierten Lösungen auf Basis spezieller Echtzeit-Hardware stehen dann für spezielle Aufgaben zur Verfügung. Sie sind in aller Regel kostspielig und in den Entwicklungsabteilungen meist nur in begrenzter Zahl vorhanden. CANape als hochoptimierter Master wickelt gleichzeitig die Kommunikation mit dem realen Steuergerät und mit dem im PC laufenden Modell ab (Bild 6). Über CANape und XCP können sowohl die Parameter des Steuergeräts als auch die Parameter des Modells kalibriert werden. Dabei können die optimierten Parametrierungen des Modells wieder in den Quellcode zurückgeführt werden. So werden für die Funktionsoptimierung und die Steuergerätekalibrierung das gleiche Werkzeug und die gleichen Mechanismen und Vorgehensweisen eingesetzt, was zu einer deutlichen Vereinfachung der Prozesse führt. Steuergeräte via XCP reprogrammieren Auch beim Programmieren der Steuergeräte bietet XCP dem Anwender Vorteile. Die Daten im Flash-Speicher des Steuergeräts sind nur über die dafür bereitgestellten Flash-Routinen reprogrammierbar, die sich dazu im Steuergerät befinden müssen. Prinzipiell sind zwei Lösungswege denkbar: Entweder sind die Flash-Routinen dauerhaft im Flash untergebracht, wodurch Speicher verschwendet wird und was bei ausgelieferten Fahrzeugen ein Sicherheitsproblem darstellt, oder ein PC- Tool lädt einen Flash-Kernel über XCP nur dann in das RAM des Mikrocontrollers, wenn er zum Reprogrammieren benötigt wird. Der Flash-Kernel enthält neben den Flash-Routinen zum Löschen des Flash-Speichers und Neuschreiben der Daten auch den eigenen Bus- und Treiber für die Kommunikation über das Businterface mit dem PC-Tool. XCP on FlexRay bewährt sich in der Serienentwicklung XCP ist ein standardisiertes und universell verwendbares Protokoll mit viel Rationalisierungs-Potential. Zum Einsatz kommt es nicht nur bei der Steuergeräte-Entwicklung, -kalibrierung und -programmierung, sondern auch zur Einbindung von Messtechnik, zur Prototypen-Entwicklung, zur Funktionsentwicklung mit Bypassing und an SiL- und HiL-Prüfständen. Für den schnellen Zugriff auf interne Daten über Mikrocontroller-Debug- Schnittstellen, wie beispielsweise NEXUS, erfolgt die Kommunikation problemlos über eine dedizierte Hardware. Diese setzt die Kommunikation von NEXUS auf XCP on Ethernet um. Der Vorteil für den Anwender ist die Unabhängigkeit von Tool-Herstellern mit proprietären Lösungen und die Wiederverwendbarkeit der Komponenten. Zum Aufbau eines s stellt Vector Informatik einen Treiber auf der Website [3] zum freien Download zur Verfügung. Das bereits seit 996 in der Steuergeräte-Kalibrierung eingesetzte MCD-Tool CANape ist durch die aktive Beteiligung von Vector in den ASAM-Arbeitskreisen als Master immer auf dem neuesten Stand der Standardisierung. CANape verfügt als erstes Werkzeug auf dem Markt über eine XCP on FlexRay -Schnittstelle. Dies war ausschlaggebend dafür, dass bei der Entwicklung des ersten Serienfahrzeugs mit FlexRay, dem BMW X5, die BMW-Ingenieure zum Kalibrieren des Dämpferkontrollsystems auf Vectors Stack und auf CANape setzten. sj Links [] [2] [3] Andreas Patzer studierte Elektrotechnik an der Technischen Universität zu Karlsruhe. Schwerpunkte waren dabei Mess- und Regelungstechnik sowie Informations- und Automatisierungtechnik. Seit 2003 ist er bei Vector Informatik GmbH in Stuttgart und bildet als Business Development Manager in der Produktlinie Measurement and Calibration die Schnittstelle zwischen Entwicklung, Vertrieb und Kunden. andreas.patzer@vector-informatik.de 66 Elektronik automotive