AUTOSAR-Steuergeräte-Software mit XCP analysieren

Transkript

1 Fachartikel AUTOSAR-Steuergeräte-Software mit XCP analysieren Komfortable Fehlersuche durch Erweiterung der AUTOSAR-Basissoftware Bei der Fehlersuche im Steuer geräte verbund ist der Einsatz von Debuggern oft nur eingeschränkt möglich, vor allem wenn Fehler nur sporadisch oder im Testfahrzeug auftreten. Das bewährte Mess- und Kalibrierprotokoll XCP leistet in diesen Fällen nützliche Dienste. Nachfolgend wird beschrieben, wie mit XCP Abläufe in der AUTOSAR-Basissoftware (BSW) und den Softwarekomponenten (SWCs) verfolgt werden können. Die Basissoftware muss für diese Messzwecke um bestimmte Eigen schaften ergänzt werden. Für eine effiziente Fehlersuche und einfache Auswertung benötigt der Testingenieur auch spezielle Erweiterungen der Analysewerkzeuge. Eine große Anzahl der heute verfügbaren Testwerkzeuge unterstützt das Testen einzelner Steuergeräte mithilfe einer Restbussimulation. Damit werden die geforderten Funktionen unabhängig vom Steuergeräteverbund frühzeitig verifiziert. Die Software er reicht so bereits eine sehr hohe Qualitätsstufe. Sobald ein Steuergerät im Brettaufbau oder im Testfahrzeug verbaut wird, bzw. die Funktion sich über einen Verbund mehrerer Steuergeräte erstreckt, reduzieren sich die Testmöglichkeiten erheblich. Auftretende Fehler können nun nicht mehr so leicht eingegrenzt werden. Die Ursachen dafür sind: >> Ein Steuergerät ist schwer zugänglich verbaut. >> Es sind keine Anschlüsse für das Debugging mehr verfügbar. >> Die Debugger für die verschiedenen Steuergeräte bereiten die Daten nicht einheitlich auf. >> Die Testwerkzeuge können nicht im Fahrzeug untergebracht werden. Neben den eingeschränkten physikalischen Gegebenheiten für eine Fehlersuche im Fahrzeug, kommt noch ein weiterer Faktor hinzu: Einige Fehler treten nur sporadisch auf. Die Ursachenforschung bei sporadischen Fehlern ist auch im Labor nicht immer einfach. Anforderungen an die Fehlersuche Um die Ursache eines Fehlers zu finden, werden typischerweise die Werte verschiedener Variablen der Software geprüft. Ebenso ist es wichtig, auch die Variablen mehrerer Softwaremodule zeitgleich zu einem Triggerpunkt zu prüfen. Dadurch lassen sich modulübergreifende Konsistenzbedingungen überwachen. Beispiele dafür sind vor allem Managermodule, deren Zustandsmaschinen voneinander abhängen, z.b. die AUTOSAR Bus State Manager und der Communication Manager (ComM). Ebenso muss der Testingenieur prüfen, aufgrund welcher Anforderungen aus der Applikation die gemessenen Zustände eingenommen wurden. Weiterhin ist es nötig, Wirkketten über Modulgrenzen hinweg zu beobachten, um z.b. einen Signalpfad vom Empfang eines Bussignals bis hin zur Applikation zu verfolgen. Außerdem sind Zeitstempel notwendig, um bei der Analyse die Fehlerhistorie zu rekonstruieren. Einsatz von XCP in AUTOSAR 3.x-Projekten Im AUTOSAR 3.x-Standard sind für das Echtzeit-Debugging keine Mechanismen spezifiziert. Seit Jahren ist jedoch das Universal Measurement and Calibration Protocol (XCP) in der Fahrzeugentwicklung erfolgreich für das Messen und Kalibrie ren von Steuergeräten im Einsatz und deckt die oben genannten Anforderungen sehr gut ab. XCP stellt Mechanismen zum Lesen und Schreiben von Variablen über Bussysteme zur Verfügung. Anhand von DAQ-Listen (Data Acquisition) können mehrere Variablen konsistent und mit einem gemeinsamen Zeitstempel gemessen werden. Dynamische DAQ-Listen ermöglichen das Umkonfigurieren der auszulesenden Datensätze während der Messung. Somit wird die zur Verfügung stehende Bandbreite des Kommunikationsbusses optimal ausgenutzt. Für das Messen über XCP wurde das A2L-Datenformat spezifiziert. Eine A2L-Datei beinhaltet Informationen über die relevanten Messobjekte im Steuergerät. Für jedes dieser Objekte wer 1

2 den Informationen, wie Speicheradresse, Datentyp, symbolische Interpretation und Umrechnungsvorschriften benötigt. Darüber hinaus be inhaltet eine A2L-Datei neben der Beschreibung der Parameter für die Kommunikation zwischen dem XCP-Master (z.b. Analyse-Werkzeug) und dem XCP-Slave (Steuergerät) auch eine hierarchisch strukturierte Darstellung der Messobjekte. Mit den vielfältigen Zugriffsmöglichkeiten auf steuergeräteinterne Variablen und der komfortablen Konfiguration über eine A2L-Datei ist XCP ein leistungsstarkes Protokoll für die Fehlersuche. Die Umsetzung des XCP-Protokolls erfolgt in einem eigenen BSW-Modul, das aber nicht im AUTOSAR 3.x-Standard definiert ist. Dieses wird je nach verwendetem Bussystem (CAN, FlexRay, Ethernet, etc.) an den entsprechenden AUTOSAR-Kommunikations-Treiber angebunden (Bild 1). Um eine komfortable Konfiguration von XCP und der übrigen Module zu erhalten, wird der XCP- Treiber nahtlos in die bestehende BSW-Konfigurationskette eingefügt. Erstellen einer A2L-Datei Das Erstellen der A2L-Datei mit den oben genannten hilfreichen Zusatzinformationen ist eine Herausforderung. Dafür benötigt der Testingenieur einen definierten Prozess und geeignete Werkzeuge. Aufgrund der vielfältigen Konfigurationsmöglichkeiten der AUTOSAR BSW ist es von Vorteil die A2L-Datei zu generieren. Bei der Erzeugung werden Änderungen der BSW-Konfiguration in die A2L-Datei umgesetzt. Die für das Messen der Datenflüsse zwischen Softwarekomponenten (SWC) benötigte A2L-Datei erzeugt der RTE-Generator von Vector (Bild 2). Damit ist es möglich die Intra- und Inter-ECU-Kommunikation zu verfolgen sowie nicht verbundene Sender/Receiver- Ports zu messen und zu stimulieren. Basierend auf der mit dem DaVinci Developer erstellten RTE-Konfiguration erfolgt das Generieren der A2L-Datei. Zusätzlich fügt der RTE-Generator auch notwendige Änderungen für die Messung in den RTE-Code ein. Um auch den Datenfluss in den Modulen unterhalb der RTE zu verfolgen, stellt Vector ebenso einen A2L-Generator für die Messgrößen in der Basissoftware zur Verfügung (Bild 2). Das Generieren der A2L-Datei erfolgt ebenfalls auf Basis der Konfiguration. Die Messobjekte werden in der A2L-Datei in einer Ordnerstruktur hierarchisch abgelegt, um das Auffinden zu erleichtern. Messdaten erfassen Oft kann der Testingenieur anhand des Fehlerbildes bereits die für den Fehler verantwortlichen Module einschränken und die zur Analyse auszulesenden Daten definieren. Zunächst wird mit dem XCP- Master eine Verbindung zum XCP-Slave aufgebaut. Direkt im Anschluss an den Verbindungsaufbau können erste Daten aus dem Steuergerät ausgelesen werden. Das sind in der Regel Informationen wie Versionsnummern, Variantenkennungen, usw. Anhand dieser Information wählt der Testingenieur die zum Versionsstand des Steuergerätes passende A2L-Datei aus und startet die Messung der Daten. Bei schwer zu reproduzierenden Fehlern ist eine schnelle Analyse der Daten während der laufenden Messung unter Umständen nicht möglich. In diesen Fällen speichern Daten-Logger mit Bild 1: MICROSAR die AUTOSAR-Basissoftware von Vector enthält Module für das Messen von steuergeräteinternen Daten mittels XCP November

3 Fachartikel integrierter XCP-Funktionalität oder Softwarewerkzeuge mit einem XCP-Master über längere Zeiträume Messwerte im Fahrzeug. Bei der anschließenden Analyse der Daten kommen wieder XCP-Master- Werkzeuge wie z.b. das weit verbreitete Simulations-, Analyse- und Testwerkzeug CANoe von Vector zum Einsatz. Messdaten analysieren Um Steuergeräte unabhängig vom verwendeten Kommunikationsbus zu testen, muss der XCP-Master unterschiedliche Bussysteme wie CAN, FlexRay oder Ethernet unterstützen. Darüber hinaus kann es bei der Fehlersuche notwendig sein, Daten mehrerer Steuer geräte parallel zu messen und auszuwerten. Daher ist es vorteilhaft, wenn das Analysewerkzeug auch multi-master-fähig ist. CANoe wird mit der Option AMD (AUTOSAR Monitoring and Debugging) um die Funktionalität eines XCP-Masters erweitert, um dynamisch mehrere Slaves anzusprechen. Damit kann der Anwender die XCP-Konfiguration während einer laufenden Messung ändern. Mit der Option AMD stehen die Analysefenster State Tracker (Bild 3), Grafikfenster und Datenfenster auch für die über XCP gemessenen Variablen zur Verfügung. Ebenso kann der Zugriff auf die XCP-Variablen aus der integrierten Programmiersprache CAPL oder der Testautomatisierung erfolgen und ermöglicht so eine automatisierte Analyse. Die Analyse der aufgenommenen Messwerte aus dem Steuer gerät kann direkt während der Messung erfolgen. Hierzu muss der XCP- Master entsprechende Mechanismen bieten. Im Fall von CANoe sind das zum einen definierbare Triggerbedingungen im State Tracker- Fenster, wie z.b. das Einfrieren des Fensterinhalts beim Erreichen eines bestimmten Messwertes für eine schnelle Analyse. Zum anderen ermöglicht CANoe komplexe Auswertungen der Messwerte über ein CAPL-Programm. Sollen gespeicherte Messwerte detailliert untersucht werden, ist eine symbolische Darstellung der Werte für den Entwickler einfacher zu handhaben, als mit den Rohwerten zu arbeiten. Hierzu muss die A2L-Datei eine Zuordnung der Rohwerte zu symbolischen Bezeichnern enthalten ähnlich zu den aus der Programmier sprache C bekannten Enums. Die Anzeige der symbolischen Werte übernimmt CANoe. Diese Art der Darstellung eignet sich hervorragend zum Beobachten von Zustandsautomaten, deren Zustände oft über Enums im Code dargestellt werden. Das Verfahren lässt sich auf jede beliebige Variable übertragen, z.b. um symbolisch darzustellen, ob sie gerade mit einem Ersatz- oder Initialisierungswert geladen ist. Debugging in AUTOSAR 4.x-Projekten Der AUTOSAR 4.x-Standard wird der Anforderung an Debug-Möglichkeiten in der Software durch die Module DBG (Debug) und DLT (Diagnostic Log and Trace) gerecht. Diese zwei Module nutzen ähnliche Mechanismen, wie sie XCP zur Verfügung stellt. Die Haupt aufgabe des DBG-Moduls ist das Lesen von Daten im Steuergerät, die zwischengepuffert und an einen PC zum weiteren Auswerten durch den Entwickler geschickt werden. Die Kommunikation zum PC erfolgt über ein eigenes Kommunikationsprotokoll. Ähnlich zur A2L-Datei bei XCP wird beim DBG-Ansatz eine Beschreibung der zu messenden Daten erzeugt. Dies geschieht auf Basis der Modul beschreibung aller zu messenden BSW-Module. Das DLT-Modul hat die Aufgabe, Fehlermeldungen und Warnungen, die zur Laufzeit erzeugt werden, an einen PC weiterzuleiten. Diese Meldungen werden von den BSW-Modulen DET (Development Error Trace), DEM (Development Event Manager) und von den Softwarekomponenten der Applikation erzeugt. DLT hat ebenfalls ein eigenes Kommunikationsprotokoll, das nicht XCP-kompatibel ist. Die Funktionen der beiden Module DBG und DLT können aber auch mit XCP umgesetzt werden. Vector bietet dies bereits in seiner AUTOSAR 3.x-Lösung an (Bild 1). Bild 2: Generierung der A2L-Dateien, basierend auf der Steuergerätekonfiguration 3

4 Bild 3: Das CANoe State Tracker Fenster bietet eine komfortable Visualisierung von steuergeräte-internen Daten, die mit XCP erfasst wurden. Hochperformanter Zugriff auf Messdaten Mit den beschriebenen Mechanismen steht für jedes Steuergerät unabhängig von der AUTOSAR-Version ein mächtiges Debug- Werkzeug zur Verfügung. Der Entwickler verfolgt und analysiert mit den bewährten XCP-Werkzeugen wie z.b. CANoe und CANape von Vector komfortabel Abläufe im Steuergerät. Für das Messen großer Datenmengen mit bis zu 5 MByte/s bei minimaler Laufzeitbeeinflussung des Steuergeräts, bietet sich der Einsatz der VX1000 Mess- und Kalibrierhardware (Bild 4) an. Der Zugang zum Steuergerät erfolgt hierbei über die Debug-Schnittstellen JTAG oder NEXUS. Wie funktioniert XCP? Bereits seit Jahren ist das Universal Measurement and Calibration Protocol (XCP) in der Fahrzeugentwicklung erfolgreich für das Messen und Kalibrieren von Steuergeräten im Einsatz. XCP ist ein weltweiter Standard und wurde von der Association for Standardization of Automation and Measuring Systems (ASAM) im Jahr 2003 standardisiert. Während das CAN Calibration Protocol (CCP) auf den CAN-Bus beschränkt ist, erlaubt XCP den Austausch der Transportschicht. Es unterstützt z.b. CAN, FlexRay, Ethernet, USB, etc. und basiert auf einem Master/Slave-Prinzip. Der XCP-Master sendet über ein Command Transfer Object (CTO) Kommandos über den Bus an den XCP-Slave, worauf der XCP-Slave über ein Data Transfer Object (DTO) antwortet. Mit XCP lassen sich Werte im Speicher des Steuergerätes lesen und schreiben. Der XCP-Master fordert Messdaten zyklisch beim XCP-Slave an (Polling) oder lässt sich die Daten beim Auftreten bestimmter Ereignisse zuschicken (XCP-Events). Welcher Mechanismus zum Einsatz kommt, hängt von mehreren Faktoren ab: Beim Messen mit XCP-Events wird die Busbandbreite besser genutzt als beim Polling. Allerdings ist es notwendig den Steuergerätecode entsprechend anzupassen, um die XCP-Events auszulösen, was beim Polling nicht notwendig ist. Ebenso können XCP-Events bereits während der Entwicklung im Code der Applikation an bestimmten Stellen vorgesehen werden. Abgesehen von einem geringen Laufzeit-Overhead verhält sich der XCP-Code passiv. Werden die XCP- Events für das Messen benötigt, aktiviert der XCP-Master sie während der Messung. Ein weiterer Vorteil der XCP-Events ist die ereignisgesteuerte Ausgabe mehrerer Daten mit einem gemeinsamen Zeitstempel. Dadurch vollzieht der Entwickler bestimmte Vorgänge in der Software exakt nach und prüft, ob Variablen zueinander konsistent sind. Mit XCP-Events kann der Testingenieur Messungen unabhängig vom Zustand des Kommunikationsbusses durchführen. Während beim Polling die Messkommandos vom Master empfangen werden und somit die Buskommunikation zwingend erforderlich ist, kann dies bei einer Event-Messung entfallen. Dafür muss der XCP-Slave allerdings einen Puffer zur Verfügung stellen, der die Messdaten aufnimmt, bis die Kommunikation zum XCP-Master wiederhergestellt wurde. Aufgrund der im Steuergerät knappen Ressourcen ist ein dauerhaftes Puffern verständlicherweise nicht möglich. Hier sind zwei Pufferstrategien denkbar. Zum einen ein linearer Puffer, der Messwerte nur aufnimmt, bis er voll ist. Die andere Variante ist ein Ringpuffer, bei dem die ältesten Einträge mit neuen Werten überschrieben werden. Bevor eine Messung über XCP-Events erfolgen kann, muss der XCP-Master den Slave-Treiber entsprechend konfigurieren. Dies geschieht durch eine Reihe von Kommandos. Dazu verbindet sich der XCP-Master mit dem XCP-Slave und überträgt die notwendige November

5 Fachartikel Bild 4: Mit der VX1000 Mess- und Kalibrierhardware von Vector lassen sich große Datenmengen erfassen, bei minimaler Beeinflus sung der Steuergeräte-Laufzeit. Konfiguration. Soll die Messung jedoch unmittelbar nach der Initialisierung des Steuergerätes starten, muss die Messkonfigura tion im nicht-flüchtigen Speicher des Steuergeräts abgelegt sein. Dieser sogenannte Resume Mode erlaubt Messungen unmittelbar nach dem Start des Steuergerätes. Dipl.-Ing. (FH) Patrick Markl ist Teamleiter für die Konzeptentwicklung in der Produktlinie "Embedded Software" bei Vector. Die englische Originalversion wurde veröffentlicht in der Son derausgabe der Hanser automotive im November Alle Bilder: Vector Informatik GmbH Ihr Ansprechpartner Kontact 5 Dipl.-Ing. (FH) Stefan Albrecht ist Senior Product Management Engineer für die CANoe/CANalyzer Option AMD.