Handbuch AUTOSAR Calibration Inhaltsverzeichnis · Handbuch AUTOSAR Calibration Inhaltsverzeichnis © Vector Informatik GmbH Version 2.0 - II - 5.4 Konfiguration des XCP-Moduls 42

Impressum Vector Informatik GmbH Ingersheimer Straße 24 D-70499 Stuttgart Vector behält sich vor, die in diesen Dokumenten enthaltenen Angaben und Daten jederzeit ohne vorherige Ankündigung zu ändern. Ohne ausdrückliche schriftliche Zustimmung von Vector dürfen diese Dokumente, auch nicht teilweise, vervielfältigt oder übertragen werden, unabhängig davon, auf welche Weise oder mit welchen Mitteln dies geschieht. Alle technischen Angaben, Texte, Bilder und Grafiken einschließlich deren Anordnung unterliegen soweit gesetzlich zulässig den geltenden gesetzlichen Vorschriften zum Schutz des geistigen Eigentums, insb. dem Schutz des Urheberrechts. Jede nicht genehmigte Verwendung kann eine Verletzung dieser Vorschriften darstellen.

Copyright 2019, Vector Informatik GmbH. Printed in Germany. Alle Rechte vorbehalten.

Handbuch AUTOSAR Calibration Inhaltsverzeichnis

© Vector Informatik GmbH Version 2.0 - I -

Inhaltsverzeichnis

1 Einführung 3

1.1 Verwendungszweck des AUTOSAR Calibration Handbuchs 4

1.2 Zu diesem Handbuch 5 1.2.1 Gewährleistung 6 1.2.2 Support 6 1.2.3 Marken 6 1.2.4 Referenzdokumente 6

2 Einführung in AUTOSAR 7

2.1 Hintergrund 8

2.2 Ansatz 9

2.3 Basiskonzept 10

2.4 Architektur 11

3 Messen und Kalibrieren von Steuergerätesoftware 13

3.1 Grundlegendes 14

3.2 XCP-Treiber 15 3.2.1 Measurement Modi 17 3.2.2 Autoselektion und Softwarestandprüfung der A2L-Datei 18 3.2.3 Online Calibration 19 3.2.4 Page Switching 19 3.2.5 Bypassing 20 3.2.6 Resume Mode 21

3.3 A2L-Datei 23 3.3.1 Aufbau 23 3.3.2 Funktionsprinzip 32

4 OEM 33

4.1 Zielsetzung 34

4.2 Inhalt des Lastenhefts 34

4.3 Messaufgabe 34

4.4 Kalibrieraufgabe 35

4.5 XCP-Features 35

5 Lieferant 36

5.1 Einleitung 37

5.2 Voraussetzungen 37

5.3 Definition von Mess- und Verstellgrößen 37 5.3.1 Messen und Kalibrieren von AUTOSAR Softwarekomponenten 38 5.3.2 Messen von Ports und Variablen 38 5.3.3 XCP-Events 39 5.3.4 Softwarekomponente mit Verstellgrößen 39 5.3.5 Verstellgrößen für mehrere Softwarekomponenten 40 5.3.6 Konfiguration der RTE (Runtime Environment) 41 5.3.7 Messen und Kalibrieren ohne Unterstützung der RTE 41 5.3.8 Debuggen der BSW (Basic Software) 42

Handbuch AUTOSAR Calibration Inhaltsverzeichnis

© Vector Informatik GmbH Version 2.0 - II -

5.4 Konfiguration des XCP-Moduls 42 5.4.1 DAQ-Listen-Konfiguration 43 5.4.2 Tool-gesteuerte DAQ-Zeitstempel-Option 43 5.4.3 XCP-Event-Information 43 5.4.4 Softwarestandprüfung 44

5.5 Konfiguration der Speicherverwaltung 45 5.5.1 Konfiguration für den Resume Mode 45

5.6 Erstellen einer A2L-Datei 46 5.6.1 Erstellen einer Master-A2L-Datei 46 5.6.2 Erweiterung der Master-A2L-Datei 48 5.6.3 Arbeiten mit dem ASAP2 Tool-Set 49 5.6.4 Arbeiten mit CANape und dem ASAP2 Editor 52

5.7 Schneller Zugriff auf das Steuergerät über das VX-Modul 53

5.8 Weiterführende Themen 53

6 Abgabetest/Quickstart 54

7 CANape Einführung 55

7.1 Erstellung eines Projektes 56

7.2 Gerätekonfiguration 57 7.2.1 Geräte 58 7.2.2 Netzwerke 59 7.2.3 Vector Hardware 59 7.2.4 XCP-Features in CANape 60

7.3 Online-Messkonfiguration 61 7.3.1 Messoptionen 61 7.3.2 Messsignale 62 7.3.3 Rekorderliste 64 7.3.4 Ereignisliste 66

7.4 Arbeiten mit Parametersatzdateien 66

7.5 Datenstandsverwaltung 67 7.5.1 Toolbasiert ab CANape 11.0 67

7.6 Offline-Auswertung 69

7.7 Flashen 71

8 Adressen 72

9 Abkürzungen 73

Handbuch AUTOSAR Calibration Einführung

© Vector Informatik GmbH Version 2.0 - 3 -

1 Einführung

In diesem Kapitel finden Sie die folgenden Informationen:

1.1 Verwendungszweck des AUTOSAR Calibration Handbuchs Seite 4

1.2 Zu diesem Handbuch Seite 5

Gewährleistung

Support

Marken

Referenzdokumente



1.1 Verwendungszweck des AUTOSAR Calibration Handbuchs

AUTOSAR Standard Der AUTOSAR Standard beschreibt Methoden, die es ermöglichen, Software-Komponenten im Fahrzeug einheitlich zu entwickeln, damit diese wiederverwendbar und austauschbar sind. Auf diese Weise wird der Entwicklungsaufwand für die Steuergerätesoftware minimiert. Das Optimieren der Software erfolgt dann über CANape.

Verstell-und Messgrößen

Da der Softwareentwickler die Parameter für einen Regelalgorithmus des Steuergerätes bei der Implementierung noch nicht optimieren kann, werden diese als Verstellgrößen in der Software definiert. Dabei handelt es sich letztlich um Variablen im Quellcode, die im RAM liegen und vom Algorithmus selbst unverändert bleiben. Anschließend können sie mithilfe von CANape kalibriert werden. Um die Auswirkungen dieses Vorgangs zu erfassen, werden zusätzlich Messgrößen in der Software definiert. Auch diese sind Variablen im Quellcode und liegen im RAM. Im Gegensatz zu den Verstellgrößen werden sie allerdings laufend vom Steuergerätealgorithmus verändert und geben den aktuellen Wert wieder. Dadurch werden die Auswirkungen des Kalibriervorgangs sichtbar und das Verhalten des Steuergeräts kann optimiert werden. So wird beispielsweise die Raddrehzahl (Verstellgröße) eines Fahrdynamik-Regelsystems verändert und die Messtechnik greift die entsprechenden Sensorwerte (Messgrößen) ab, um die Verhaltensveränderung des Algorithmus zu erfassen.

CCP/XCP-Protokolle mit A2L-Datei

Um auf die steuergeräte-internen Mess- und Verstellgrößen zur Laufzeit zugreifen zu können, werden die Protokolle CCP und XCP verwendet. Elementarer Bestandteil dieser adressorientierten Protokolle ist eine A2L-Datei. Diese erleichtert das Datenhandling, da sie die symbolische Auswahl von Datenobjekten unabhängig von deren Speicheradressen im Steuergerät ermöglicht. So kann auf steuergeräte-interne Größen über symbolische Namen zugegriffen werden. Die Verknüpfung der steuergeräte-internen Adressen mit den dazugehörigen symbolischen Namen übernimmt das Mess-, Kalibrier- und Diagnosesystem (CANape). Für jedes Steuergerät ist dabei eine eigene A2L-Datei notwendig. Abbildung 1-1 zeigt die Einbindung der A2L-Datei in das MCD-System.

Abbildung 1-1: Einbindung der A2L-Datei in das MCD-System

ECU

Steuergeräte-Beschreibungsdatei

*.A2L

CCP/XCP

CAN, Ethernet, FlexRay, ...

CANape

CCP/XCP

Steuergeräteunab-hängiges Konzept

Für die Entwicklung von Steuergeräten, die auf dem AUTOSAR Standard basieren, wird ein steuergeräteunabhängiges Konzept zum Messen und Verstellen von AUTOSAR Applikationen benötigt. Das AUTOSAR Calibration Handbuch beschreibt ein einheitliches Vorgehen zur Implementierung und Applikation eines Steuergerätes nach AUTOSAR.

Struktur dieses Dokuments

Zu Beginn des Dokuments steht nochmals eine kurze Einführung in den AUTOSAR Standard. Danach werden Aspekte des Messen und Kalibrieren von



Steuergerätesoftware erläutert.

Das Kapitel OEM dient als Checkliste zur Lastenhefterstellung für den OEM. Dabei wird kurz erklärt, welche Details dem Zulieferer mitgeteilt werden müssen, um die gewünschte Messaufgabe zu realisieren.

Das Kapitel Lieferant beschreibt das Vorgehen auf der Seite des Lieferanten. Es geht auf die Details zur Konfiguration von MICROSAR XCP sowie der Softwarekomponenten von AUTOSAR ein. Zudem wird der Generierungsprozess der A2L-Datei erläutert.

Anschließend wird im Kapitel Abgabetest/Quickstart erläutert, wie CANape für einen einfachen Abgabetest der A2L-Datei eingesetzt werden kann. Dieser kann zusätzlich als CANape Quickstart für den OEM verwendet werden.

Der letzte Teil CANape Einführung beschreibt den Weg von der Projekterstellung bis hin zum Flashen der optimierten Parameter in CANape.

1.2 Zu diesem Handbuch

Informationen schnell finden

Diese Zugriffshilfen bietet Ihnen das Handbuch:

> Zu Beginn eines Kapitels finden Sie eine Zusammenfassung der Inhalte.

> An der Kopfzeile erkennen Sie, in welchem Kapitel des Handbuchs Sie sich gerade befinden.

> An der Fußzeile erkennen Sie die Version des Handbuchs.

> Am Ende des Handbuchs finden Sie ein Abkürzungsverzeichnis, in dem Sie verwendete Abkürzungen nachschlagen können.

Konventionen In den beiden folgenden Tabellen finden Sie die durchgängig im ganzen Handbuch verwendeten Konventionen für Schreibweisen und Symbole.

Stil Verwendung

fett Felder, Oberflächenelemente, Fenster- und Dialognamen der Software, besondere Hervorhebungen.

[OK] Schaltflächen in eckigen Klammern

File|Save Notation für Menüs und Menüeinträge

eASEE Rechtlich geschützte Eigennamen und Marginalientext.

Quellcode Datei- und Verzeichnisnamen, Quellcode, Klassen- und Objektnamen, Objektattribute und Werte.

Hyperlink Hyperlinks und Verweise.

<Strg>+<S> Notation für Tastaturkürzel.

Symbol Verwendung

Dieses Symbol gibt Ihnen Hinweise und Tipps, die Ihnen die Arbeit erleichtern.

Dieses Symbol warnt Sie vor Gefahren, die zu Sachschäden führen können.



Symbol Verwendung

Dieses Symbol weist Sie auf weiterführende Informationen hin.

Dieses Symbol weist Sie auf Beispiele hin.

Dieses Symbol weist Sie auf Schritt-für-Schritt Anleitungen hin.

1.2.1 Gewährleistung

Einschränkung der Gewährleistung

Wir behalten uns inhaltliche Änderungen der Dokumentation und der Software ohne Ankündigung vor. Vector übernimmt keine Gewährleistung und/oder Haftung für die Vollständigkeit oder Richtigkeit der Inhalte oder für Schäden, die sich aus dem Gebrauch der Dokumentation ergeben.

1.2.2 Support

Sie benötigen Hilfe? Sie können unsere Hotline telefonisch unter der Rufnummer

+49 (0)711 80670-200

oder per E-Mail unter [email protected] erreichen.

1.2.3 Marken

Geschützte Marken Alle in dieser Dokumentation genannten Produktbezeichnungen sind eingetragene oder nicht eingetragene Marken ihrer jeweiligen Inhaber.

1.2.4 Referenzdokumente

No. Source Title Version

[1] AUTOSAR AUTOSAR Virtual Function Bus Release 4.3.0

[2] AUTOSAR AUTOSAR Specification of RTE Release 4.3.0

[3] ASAM ASAM MCD-2 MC Programmers Guide 1.6.1

[4] ASAM XCP Version 1.1 Part 1 - Overview 1.1

[5] VECTOR MICROSAR RTE - Technical Reference 4.17.0

[6] VECTOR XCP Measurement of BSW Modules - Technical Reference

1.2

[7] VECTOR MICROSAR XCP – Technical Reference 2.0.0

[8] VECTOR ASAP2 Tool-Set Handbuch 7.0

[9] AUTOSAR AUTOSAR Layered Software Architecture Release 4.3.0

mailto:[email protected]

Handbuch AUTOSAR Calibration Einführung in AUTOSAR


2 Einführung in AUTOSAR


2.1 Hintergrund Seite 8

2.2 Ansatz Seite 9

2.3 Basiskonzept Seite 10

2.4 Architektur Seite 11



2.1 Hintergrund

AUTOSAR AUTOSAR (AUTomotive Open System ARchitecture) AUTOSAR ist ein Arbeitskreis von Automobilherstellern und Zulieferern mit dem Ziel, einen gemeinsamen Industriestandard für E/E-Architekturen im Fahrzeug zu etablieren.

Kernanliegen Die Kernanliegen dabei sind:

> Verwaltung der steigenden E/E-Komplexität

> Verbesserung der Flexibilität für Updates und Modifikationen

> Skalierbarkeit von unterschiedlichen Fahrzeug- und Plattformvarianten

> Verbesserung der Verlässlichkeit und der Qualität von E/E-Systemen

> Möglichkeit, in frühen Entwicklungsphasen Fehler zu entdecken

> Wiederverwendbarkeit von Funktionen unabhängig vom Hersteller

> Standardisierte Modelwerkzeuge und Code-Generatoren



2.2 Ansatz

AUTOSAR Elemente Die Abbildung 2-1 zeigt den AUTOSAR Ansatz. Die einzelnen Elemente werden im Anschluss genauer erläutert.

Abbildung 2-1: Konzept von AUTOSAR1

AUTOSAR SW-C Die AUTOSAR Softwarekomponenten bilden das Gerüst einer Applikation, die auf der AUTOSAR Infrastruktur läuft.

Verweis: Die Schichtenarchitektur von AUTOSAR wird in AUTOSAR Layered Software Architecture näher beschrieben.

SW-C Description Die Softwarekomponenten-Beschreibung wird von AUTOSAR beispielweise zur Definition von Schnittstellen zur Verfügung gestellt.

Virtual Functional Bus (VFB)

Der VFB beschreibt alle Kommunikationsmechanismen von AUTOSAR auf einem abstrakten Level.

1 Abbildungsnachweis: AUTOSAR Virtual Function Bus



System Constraint and ECU Descriptions

Um Softwarekomponenten in ein Netzwerk eines Steuergerätes zu integrieren, werden von AUTOSAR Beschreibungen für gesamte Systeme oder auch Konfigurationen und Signale einzelner Steuergeräte zur Verfügung gestellt.

Runtime Environment (RTE)

Die RTE implementiert die Funktionalität des VFB eines bestimmten Steuergerätes. Sie kann einen Teil davon aber an die Basissoftware delegieren.

Basic Software (BSW)

Die Basissoftware stellt die infrastrukturelle Funktionalität des Steuergerätes bereit.

2.3 Basiskonzept

Kommunikation über VFB

Über den Virtual Functional Bus (VFB) läuft die Kommunikation zwischen den einzelnen Komponenten. Zu diesem Zeitpunkt liegt noch keine Speicherverwaltung der Steuergeräte vor. Der VFB wird sowohl innerhalb des Steuergerätes als auch steuergeräteübergreifend verwendet und hat keine Kenntnis über die verwendete Bustechnologie. Dies ermöglicht einen Austausch der Applikationssoftware unabhängig von der genutzten Bustechnologie. Abbildung 2-2 zeigt den Kommunikationsverlauf des Virtual Functional Bus.

Abbildung 2-2: Kommunikationsverlauf des VFB

Ausführung der Komponenten

Sobald alle relevanten Objekte definiert wurden, werden diese auf das Steuergerät abgebildet. Der VFB wird mithilfe einer steuergerätespezifischen Runtime Environment (RTE) implementiert und übernimmt mit dem Betriebssystem die Ausführung der Komponenten.

Zusammensetzung der Softwarekompo-nenten

Softwarekomponenten, wie hier z.B. Left Door und Right Door, bestehen aus:

> Ports: Diese dienen als Schnittstelle zur Kommunikation mit anderen Softwarekomponenten. Sie können entweder als Sender/Receiver oder Client/Server fungieren. Über sogenannte Connectors werden die Ports miteinander verbunden.

> Runnables: Jede atomic SW-C enthält ein oder mehrere Runnables. Diese stellen den ausführbaren Teil der Softwarekomponente dar und beziehen sich auf Funktionen und Prozeduren.



2.4 Architektur

Layers Die AUTOSAR Architektur hat im Wesentlichen 7 unterschiedliche Layer (vgl. Abbildung 2-3) Die oberste und unterste Schicht werden an dieser Stelle nicht näher erläutert, da sie nicht zur Basissoftware gehören.

Abbildung 2-3: Übersicht der AUTOSAR Layer

Microcontroller Abstraction Layer

Der Microcontroller Abstraction Layer ist der niedrigste Software Layer der Basissoftware-Architektur und gewährt die Unabhängigkeit der oberen Schichten vom eigentlichen Mikrocontroller.

ECU Abstraction Layer

Die Aufgabe des ECU Abstraction Layers ist, die Unabhängigkeit höherer Schichten von dem eigentlichen Steuergerät zu gewährleisten.

Service Layer Der Service Layer ist die höchste Schicht der Basissoftware. Er enthält das Betriebssystem und übernimmt Funktionen wie das Netzwerk- und NVRAM-Management oder auch Diagnoseservices.

Complex Device Drivers

Der Gerätetreiber-Layer steuert spezielle Sensoren und Aktoren über den direkten Zugang zum Mikrocontroller an. Es handelt sich dabei um Sensoren mit besonderen Zeitbedingungen, die z.B. die Benzineinspritzung in die Wege leiten.

Runtime Environment

Die Runtime Environment (RTE) integriert als Middleware unterschiedliche Applikationen mit der Basissoftware. Sie organisiert die Kommunikation und den Datenaustausch zwischen den beiden Schichten und wickelt die Ausführung der Runnables ab. Da alle Schichten exakt beschrieben sind, kann die Applikationssoftware unabhängig von der Hardware und ohne Wissen über die Verhaltensweise anderer Schichten implementiert werden. Die Kommunikation zwischen den Schichten erfolgt dabei über zuvor definierte Ports.

Die folgende Abbildung 2-4 zeigt die gesamte AUTOSAR Steuergeräte-Softwarearchitektur.



Abbildung 2-4: AUTOSAR mehrschichtige Softwarearchitektur2

2 Abbildungsnachweis: AUTOSAR Layered Software Architecture

Handbuch AUTOSAR Calibration Messen und Kalibrieren von Steuergerätesoftware


3 Messen und Kalibrieren von Steuergerätesoftware


3.1 Grundlegendes Seite 14

3.2 XCP-Treiber Seite 15

Measurement Modi

Autoselektion und Softwarestandprüfung der A2L-Datei

Online Calibration

Page Switching

Bypassing

Resume Mode

3.3 A2L-Datei Seite 23

Aufbau

Funktionsprinzip



3.1 Grundlegendes

Herausforderung In der Steuergerätesoftware sind Variablen im Quellcode als Mess- und Verstellgrößen implementiert. Die Aufgabe des Applikationsingenieurs besteht darin, diese zu messen und zu verstellen, sodass das Verhalten des Steuergerätes optimiert wird. Um diesen Vorgang komfortabel zu machen, werden Applikationswerkzeuge, wie das MCD-Tool (Measurement, Calibration, Diagnostics) CANape, verwendet. Zur Kommunikation mit dem Steuergerät benötigt ein solches Tool einen XCP-Treiber und eine A2L-Datei. Der XCP-Treiber ermöglicht das Zugreifen auf steuergeräte-interne Größen zur Laufzeit. Die A2L-Datei wiederum verknüpft die symbolischen Namen einer Mess- oder Verstellgröße mit seiner Speicheradresse. Auf diese Weise kann der Applikationsingenieur mit CANape einzelne Verstellgrößen kalibrieren, ohne dabei selbst die Speicheradresse der Größe zu kennen.

Abbildung 3-1: Vorgang Messen und Verstellen



3.2 XCP-Treiber

Protokoll Der XCP-Treiber – wie zum Beispiel MICROSAR XCP – ist eine Weiterentwicklung des CCP-Treibers und kann universal für verschiedene Bussysteme verwendet werden. Es handelt sich dabei um ein Protokoll, das auf dem Prinzip Single-Master/Multi-Slave beruht. Ein XCP-Master wie CANape ist in der Lage, gleichzeitig mit verschiedenen XCP-Slaves zu kommunizieren. Dazu gehören z.B. das Steuergerät (ECU) oder HIL/SIL-Systeme. Abbildung 3-2 zeigt die Slave-Anbindung über XCP.

Abbildung 3-2: Kommunikationsmöglichkeiten eines XCP-Masters wie CANape

Kommunikation über A2L-Datei

CANape kommuniziert über den XCP-Treiber mit dem Steuergerät. Wichtiger Bestandteil dieser Kommunikation ist dabei die A2L-Datei. Der XCP-Master liest daraus alle wichtigen Informationen zum Kommunikationsaufbau und -ablauf.



Abbildung 3-3: Single-Master/Multi-Slave-Konzept

Transfer Objects Bei dem XCP-Protokoll unterscheidet man dabei zwischen "Command Transfer Objects (CTO)" und "Data Transfer Objects (DTO)"(vgl. Abbildung 3-3). Die Object Description Table (ODT) beschreibt dabei das Mapping der DTOs und des Speichers des Slaves. Das Empfangen eines CTO signalisiert dem Slave, dass er einen bestimmten Dienst ausführen soll. Das Senden eines DTO dient dem ereignisgesteuerten Lesen und Schreiben von Objekten aus dem Speicher des XCP-Slaves. Dazu werden DAQ (Data Acquisition)-Listen aus mehreren ODTs erstellt, um die Messwerte gleichzeitig beim Eintreten eines Events an den Master zu senden. Die Events werden über Eventkanäle definiert und übernehmen mithilfe von definierten Zeitrastern dabei das Timing zum tasksynchronen Senden von Messdaten.

Empfehlung: Dynamische Konfiguration von DAQ-Listen

Mit XCP besteht die Möglichkeit die DAQ-Listen sowohl statisch als auch dynamisch zu konfigurieren.

Bei einer statischen Konfiguration werden die maximale Anzahl der DAQ-Listen, der ODT-Tabellen und der ODT-Einträge pro DAQ-Liste zur Kompilierzeit fest definiert.

Bei dynamischen DAQ-Listen hingegen wird nur die maximale Speichergröße zur Kompilierzeit festgelegt. Dies ermöglicht eine effizientere Speichernutzung, da die Größe der DAQ-Listen individuell festgelegt wird, und gegebenenfalls die Messung von mehr Messsignalen im Vergleich zur statischen Konfiguration.

Hinweis: Die dynamische Konfiguration ist daher die einzige unterstützte Möglichkeit in MICROSAR XCP.

XCP Features Das XCP-Protokoll ermöglicht außerdem die Verwendung einiger optionaler XCP-Features. Diese müssen explizit implementiert und daher dem Zulieferer bekannt sein. Die nächsten Kapitel stellen die XCP-Features Measurement Modi,



Autoselektion der A2L-Datei, Online Calibration, Page Switching, Bypassing und Resume Mode näher vor.

3.2.1 Measurement Modi

Messmodi Das XCP-Protokoll ermöglicht zwei unterschiedliche Messmodi: Polling und die DAQ-Messung. Beide Varianten werden hier kurz erläutert.

Polling Polling ist der einfachste Messmodus des XCP-Protokolls. Dabei fordert der XCP-Master über einen XCP-Befehl (SHORT_UPLOAD) in einem einheitlichen Zeitraster die

Messwerte an. Die Messdaten sind in diesem Modus nicht äquidistant. Liegt eine hohe Buslast vor, wird die Messgröße möglicherweise mit einem Zeitverzug übertragen. Die Abbildung 3-4 zeigt den Kommunikationsablauf für den Messmodus Polling.

Abbildung 3-4: Kommunikationsablauf für den Messmodus Polling

DAQ Der Messmodus DAQ verwendet eine optimierte Methode, um auf steuergeräte-interne Werte zuzugreifen. Vor Messungsstart gruppiert der XCP-Master im Messmodus DAQ die zu messenden Mess- und Verstellgrößen in ODTs und weist diese den entsprechenden DAQ-Events zu. Während der Messung sendet der XCP-Slave die Messwerte beim Eintreten des zyklischen oder zeitlich asynchronen DAQ-Event ohne weitere Anfragen an den Master (siehe auch Abschnitt XCP-Treiber auf Seite 15).

Im Messmodus DAQ wird außerdem zwischen den Modi Consistency ODT und Consistency DAQ unterschieden. Im ersten Fall sind die Messdaten einer ODT konsistent. Im zweiten Fall ist die DAQ-Liste als Ganzes konsistent. Die Messdaten können daher auf zwei ODTs gesplittet werden. In Abbildung 3-5 wird der Kommunikationsablauf des DAQ-Messmodus in einem Trace dargestellt.

Hinweis: Zur Zeit wird lediglich die Consistency ODT von MICROSAR unterstützt.



Abbildung 3-5: Kommunikationsablauf für den Messmodus DAQ

Zeitstempel Sind die Anforderungen an die zeitliche Genauigkeit der Messwerte hoch, so empfiehlt sich die Generierung der Zeitstempel direkt in der ECU. Beim DAQ-Messmodus überträgt der XCP-Treiber den Zeitstempel für jeden aufgetretenen Event mit, sodass die Messung nicht durch die Laufzeit der Übertragung zum MCD-Tool verfälscht wird. Hierbei wird jedoch der Durchsatz an Messwerten verringert. Da die Zeitstempel zusätzlich Last auf dem Bus darstellen, kann die Generierung auch über das MCD-Tool gesteuert werden.

Bei einem CAN-Bus sollte es zum Beispiel möglich sein, den Zeitstempel auszuschalten. Bei Ethernet fällt der Zeitstempel nicht ins Gewicht.

Bei FlexRay sind Zeitstempel obligatorisch, wenn eine Zykluszeit verwendet wird, die schneller ist als der FlexRay-Buszyklus.

3.2.2 Autoselektion und Softwarestandprüfung der A2L-Datei

Softwarestand prüfen CANape bietet die Möglichkeit den Softwarestand zu prüfen. Das bedeutet, dass anhand bestimmter Informationen überprüft wird, ob die in CANape eingebundene A2L-Datei dem aktuellen Softwarestand des angeschlossenen Steuergerätes entspricht. Außerdem besteht auch die Möglichkeit über einen XCP-Protokollbefehl die A2L-Datei automatisch auszuwählen.

CANape kann folgende Information für die Softwarestandprüfung verwenden:

> XCP Station Identifier (Protokollbefehl GET_ID)

> EPK-Prüfung

> Checksumme über Code-Segmente im Steuergerät (ab CANape 11.0)

XCP Station Identifier

Der "XCP Station Identifier" (GET_ID) repräsentiert bei der Softwarestandprüfung den

Namen der A2L-Datei. Dieser beschreibt sinnvollerweise den Softwarestand (zum Beispiel EcuName_V1-2-0.a2l). CANape kann mit diesem Identifier prüfen, ob die

korrekte A2L-Datei geladen ist oder entsprechend automatisch die passende A2L-Datei laden.



EPK-Kennung Die EPK-Kennung (EPROM-Kennung) ist eine Zeichenkette, welche sowohl in der ECU als auch in der Datenbasis vorhanden ist. In der Datenbasis ist festgelegt an welcher Adresse in der ECU diese Kennung zu finden ist. Diese Zeichenkette kann wiederum den Softwarestand anhand des Projektnamens und seiner Version kennzeichnen.

Checksumme Die Berechnung der Checksumme von Code-Segmenten (Speichersegmente mit ECU-Code) kann für die HEX-Datei und das Steuergerät (ECU) ausgeführt werden. Anhand der Checksumme kann festgestellt werden, ob die HEX-Datei, die A2L-Datei und die Software auf dem Steuergerät zueinander passen. Bei dieser Vorgehensweise wird vorausgesetzt, dass die HEX-Datei und die A2L-Datei als eine Einheit gesehen werden.

Verfahren anwenden Die beschriebenen Verfahren können unabhängig voneinander angewandt werden. Jedes einzelne Verfahren erhöht die Sicherheit mit korrekten Daten zu arbeiten. Es ist zum Beispiel möglich die automatische Auswahl der A2L-Datei anhand des "XCP Station Identifier" und zusätzlich die Prüfung anhand der EPK-Kennung zu verwenden.

3.2.3 Online Calibration

Voraussetzung In diesem Kapitel werden die wichtigsten Begriffe zur Online-Kalibrierung eingeführt. Online-Kalibrierung ermöglicht die Optimierung der Verstellgrößen des Steuergeräte-algorithmus zur Laufzeit, sodass die Auswirkungen der Änderung direkt messbar sind. Voraussetzung dafür ist die Verfügbarkeit eines entsprechend großen RAM-Speichers.

Kalibrierkonzepte Zur Kalibrierung mit XCP und AUTOSAR stehen zwei unterschiedliche Kalibrierkonzepte zur Verfügung:

> InitRAM

> AUTOSAR Single Pointered

Verweis: Weitere Informationen zum Thema Kalibrierkonzepte können in der entsprechenden AUTOSAR Specification of RTE im Kapitel "Calibration" nachgelesen werden.

3.2.4 Page Switching

Umschaltung von Speichersegment-seiten zwischen RAM und FLASH

Verstellgrößen stehen normalerweise im Flash-Speicher und werden bei Bedarf ins RAM umkopiert. Je nach Implementierung bieten manche Steuergeräte die Möglichkeit der XCP-Umschaltung von Speichersegmentseiten zwischen RAM und FLASH, die sogenannte Seitenumschaltung (Page Switching). Mithilfe dieses Features werden Verstellgrößen kalibrierbar und es besteht die Möglichkeit, schnell wieder auf die Werte, die im Flash hinterlegt sind, umzuschalten. Dieser XCP-Mechanismus ist dabei unabhängig vom verwendeten Kalibrierkonzept.

Logischer Aufbau des Speichers in Segmenten

Der logische Aufbau des Speichers erfolgt prinzipiell in Segmenten. Diese geben an, wo die Verstellgrößen liegen. Jedes Segment kann wiederum mehrere Seiten (Pages) haben. Eine Page beschreibt dieselben Daten an derselben Adresse, aber mit unterschiedlichen Eigenschaften bzw. Werten (vgl. Abbildung 3-6).



Abbildung 3-6: Physikalisches Layout des Speichers

Zuordnung Die Zuordnung des Algorithmus zu einer Seite innerhalb eines Segments muss zu jedem Zeitpunkt eindeutig sein. Es kann auch in einem Segment immer nur eine Seite aktiv sein. Diese Seite ist die sogenannte "Aktive Seite für das Steuergerät in diesem Segment".

Zugriff Es kann individuell geregelt werden auf welche Seite das Steuergerät oder der XCP-Treiber zugreift. Die aktive Seite für den XCP-Zugriff heißt "Aktive Seite für den XCP-Zugriff in diesem Segment".

Befehle Um die Seitenumschaltung verwenden zu können, müssen die XCP-Befehle GET_CAL_PAGE und SET_CAL_PAGE vom Steuergerät unterstützt werden.

Mit dem Befehl GET_CAL_PAGE fragt der Master den Slave welche Seite eines

Segments gerade aktiv ist. Mit dem Befehl SET_CAL_PAGE hingegen kann der

Master bestimmen, auf welcher Seite er selbst bzw. der Steuergerätealgorithmus zugreift.

3.2.5 Bypassing

Änderungen des Steuergerätealgo-rithmus

Mithilfe des Bypassing-Features können Änderungen des Steuergerätealgorithmus ohne Anpassung und anschließendes Flashen der Software vorgenommen werden.



Implementierung Um Bypassing zu realisieren, werden mindestens 2 XCP-Events sowie schreibbarer Zugang zu dem Steuergeräte-RAM über XCP benötigt. Die Events müssen sich dabei in der Richtung unterscheiden (STIM, DAQ). Die Abbildung 3-7 zeigt die Verwendung des Bypassing.

Abbildung 3-7: Verwendung des Bypassing

Signalpfad: 1. Empfang von Signalen des Steuergerätes (DAQ) 2. Senden von Signalen als Eingang des Models 3. Senden der Ergebnisse zurück zum XCP-Master 4. Senden der Ergebnisse zurück zum Steuergerät (STIM)

Kalibrierungspfad: 5. Kalibrierung des Steuergerätes (XCP) 6. Kalibrierung des Models mit XCP

Verweis: In der Spezifikation ASAM XCP Version 1.1 Part 1 - Overview werden unter "1.3 BYPASSING (BYP)" alle weiteren Funktionen und Implementierungen zum Thema Bypassing näher erläutert.

3.2.6 Resume Mode

Automatischer Datentransfer

Der Resume Mode ermöglicht den automatischen Datentransfer direkt nach dem Einschalten des Steuergerätes. Dies wird häufig verwendet, um bereits beim Start des Steuergerätes Daten aufzuzeichnen und diese auszuwerten. Der Resume Mode unterstützt dabei sowohl die STIM- als auch die DAQ-Richtung. In der A2L-Datei muss das RESUME_SUPPORTED Flag in den DAQ-Eigenschaften dementsprechend

gesetzt sein.

Befehle Mit dem Befehl START_STOP_DAQ_LIST(select), kann der Master eine DAQ-Liste

als Teil einer DAQ-Listenkonfiguration, die der Slave in den nicht flüchtigen Speicher

http://www.asam.net/nc/home/standards/standard-detail.html?tx_rbwbmasamstandards_pi1%5bshowUid%5d=519&start=



ablegt, auswählen. Der Master sendet anschließend die Konfigurations-ID, die er selbst berechnet und abgelegt hat, an den Slave. Der Slave weiß daraufhin, dass er die DAQ-Listen in den nicht flüchtigen Speicher ablegt, sobald der Befehl STORE_DAQ_REQ_RESUME an ihn gesendet wird. Die Konfigurations-ID wird ebenfalls

in den nicht flüchtigen Speicher gelegt, sodass der Slave diese auf den Befehl GET_STATUS zurückliefern kann. Der Master erkennt über den Befehl GET_STATUS,

ob ein Slave sich im Resume Modus befindet. Vor dem Abspeichern löscht der Slave den bisherigen Inhalt des nicht flüchtigen Speichers.

Nach jedem Hochfahren des Slaves sendet dieser den Befehl EV_RESUME_MODE an

den Master. Dieser Befehl enthält die folgenden Daten:

Abbildung 3-8: Daten des Befehls EV_RESUME_MODE

Kommunikations-ablauf

Der Kommunikationsablauf zwischen dem Master und dem Slave kann in Abbildung 3-9 nachverfolgt werden.

Abbildung 3-9: Kommunikationsablauf zwischen Master und Slave

Verweis: Weitere XCP-Befehle und Informationen zum Resume Mode sind in der Spezifikation ASAM XCP Version 1.1 Part 1 - Overview zu finden.




3.3 A2L-Datei

Ziel Die A2L-Datei wurde von der Association for Standardization of Automation and Measuring Systems (ASAM) mit dem Ziel, kompatible und austauschbare Module für die Elektronikentwicklung im Automobilbereich zu definieren, spezifiziert.

Abbildung 3-10: ASAM-Schnittstellen

Steuergerätebe-schreibungsdatei

Die Beschreibungsdatei des Steuergerätes zur Konfiguration der Modelle und des Layouts der änderbaren und messbaren Objekte liefert die ASAP2 (ASAM MCD 2MC)-Schnittstelle in Form von der A2L-Datei. Der Datenaustausch zwischen dem MCD-System und dem Steuergerät wird schließlich über die ASAM MCD 1MC (ASAP1b)-Schnittstelle spezifiziert.

3.3.1 Aufbau

Modularer Aufbau Die A2L-Datei ist modular aufgebaut und ermöglicht somit den Austausch einzelner Module, ohne die ganze A2L-Datei anpassen zu müssen. Abbildung 3-11 zeigt diesen modularen Aufbau.



Abbildung 3-11: Struktur der A2L-Datei

4 wesentliche Teile Die projektrelevanten Daten zu Beginn der A2L-Datei werden über das Schlüsselwort PROJECT definiert und bilden den Rahmen der A2L-Datei. Diese beinhalten auch die

Steuergerätebeschreibung, die mit dem Schlüsselwort MODULE beschrieben und in 4

große Teile gegliedert werden kann:

> AML

> General ECU Implementation

> IF_DATA

> A2L Objects

Im Folgenden werden diese Teile nun näher erläutert.

3.3.1.1 AML

Schnittstellenspezi-fische Parameter

Im ersten Teil werden die schnittstellenspezifischen Parameter definiert. Dadurch entsteht das Gerüst des IF_DATA Bereichs, das über die Metasprache A2ML mit

dem Schlüsselwort AML definiert wird. Die AML wird in der Regel einmalig

konfiguriert, da auch die Festlegung auf einen Treiber und die entsprechenden Features einmalig durchgeführt wird.

Verweis: Nähere Informationen zur Metasprache sind in der ASAP2-Spezifikation ASAM MCD-2 MC, Kapitel 5, zu finden.




3.3.1.2 General ECU Implementation

Steuergerätebe-schreibung

In diesem Teil der A2L-Datei wird die Steuergerätebeschreibung angegeben. Hier werden einheitliche Strukturen des Steuergeräts und die generelle Beschreibung über die Schlüsselworte MOD_COMMON und MOD_PAR definiert. Auch dieser Teil der A2L-

Datei bleibt in der Regel unverändert, da die Strukturen des Steuergerätes feststehen. Die Schlüsselworte werden nun kurz vorgestellt:

MOD_COMMON Das Schlüsselwort MOD_COMMON beschreibt die internen Strukturen des

Steuergerätes. Es besteht die Möglichkeit, bestimmte Parameter für das komplette Steuergerät zu definieren. Sofern beispielsweise eine einheitliche Byte-Reihenfolge vorliegt, kann dies in diesem Bereich für das gesamte Gerät angegeben werden.

Beispiel:

/begin MOD_COMMON ""

BYTE_ORDER MSB_LAST

…

/end MOD_COMMON

MOD_PAR Das Schlüsselwort MOD_PAR beschreibt die steuergerätespezifischen

Beschreibungsdaten, wie z.B. die EPROM-Kennung oder die Speichersegmente.

Beispiel:

/begin MOD_PAR "Comment"

ADDR_EPK 0x12345

EPK "EPROM identifier test"

/begin MEMORY_SEGMENT Data0001 "Data segment" DATA

FLASH INTERN 0x30000 0x1000 -1 -1 -1 -1 -1

/end MEMORY_SEGMENT

SYSTEM_CONSTANT "CONTROLLERx CONSTANT1" "0.99"

/end MOD_PAR



3.3.1.3 IF_DATA

Kommunikations-schnittstelle

Anschließend wird die Kommunikationsschnittstelle mit dem Schlüsselwort IF_DATA

spezifiziert. Diese wird nur angepasst, wenn z.B. bestimmte XCP-Befehle im Nachhinein noch verwendet werden sollen.

IF_DATA Das Schlüsselwort IF_DATA beschreibt die schnittstellenspezifischen Daten wie

Protocol Layer oder DAQ-Listen. Diese können auch als Unterkategorie bei diversen A2L-Objekten direkt definiert werden.

Beispiel:

/begin IF_DATA XCP

/begin PROTOCOL_LAYER

…

/end PROTOCOL_LAYER

/begin DAQ

…

/end DAQ

/begin XCP_ON_CAN

…

/end XCP_ON_CAN

/end IF_DATA

DAQ-Konfiguration Die DAQ-Konfiguration ist wesentlicher Bestandteil des XCP-Protokolls und wird daher nochmals näher vorgestellt. Unter dem Schlüsselwort DAQ in der IF_DATA

Sektion wird die Konfiguration vorgenommen und die einzelnen Events unter diesem Punkt definiert.

Verweis: Näheres zur Definition von Events ist in der Spezifikation ASAM XCP Version 1.1 Part 1 - Overview unter "1.1.1.5. Event Channels" zu finden.

Spezifikation von DAQ-Listen

Die Tabelle 3-1: Spezifikation der DAQ-Listen in der IF_DATA Sektion stellt die

statische und dynamische DAQ-Konfiguration in der A2L-Datei gegenüber.





XCP (statisch) XCP (dynamisch) Erklärung

/begin DAQ /begin DAQ

STATIC DYNAMIC DAQ-Konfiguration

RESUME_SUPPORTED RESUME_SUPPORTED Resume Mode wird unterstützt

/begin DAQ_LIST

0x0 DAQ-Listennummer

DAQ_LIST_TYPE DAQ Richtung (DAQ | STIM)

MAX_ODT 0xB Maximale ODTs

MAX_ODT_ENTRIES 0x7 Maximale Einträge in einer ODT

FIRST_PID 0x3 Paketbezeichner

EVENT_FIXED 0x0 Eventkanal ist fest vorgegeben

/end DAQ_LIST

/begin EVENT /begin EVENT

"10 ms Liste 1" "10 ms Liste 1" Name des Eventkanals

"10 ms Lis" "10 ms Lis" Kurzname des Eventkanals

0x0000 0x0000 Nummer des Eventskanals

DAQ DAQ Richtung (DAQ | STIM)

0x01 0x01 Maximum an DAQ-Listen

0x0A 0x0A Abtastperiode (0 entspricht nicht

zyklisch)

0x06 0x06 Zeitbasis(0x06 entspricht 1ms)

0x00 0x00 Priorität

/end EVENT /end EVENT

/end DAQ /end DAQ

Tabelle 3-1: Spezifikation der DAQ-Listen in der IF_DATA Sektion

Default-Event Es wird empfohlen, jeder Mess- und Verstellgröße zumindest ein Default-Event zuzuweisen um sicherzustellen, dass die Objekte zum jeweils richtigen Zeitpunkt gemessen werden (Beispiel unter A2L Objects|Messgrößen im nächsten Abschnitt). Mithilfe dieser Zuordnung kann das Drag-and-Drop-Feature der Anzeige-Fenster in CANape optimal verwendet werden. Falls kein Default-Event definiert ist, muss der Messmodus manuell von Polling auf den passenden Event geändert werden.



3.3.1.4 A2L Objects

Spezifikation über Parameter und Schlüsselwörter

Im letzten Teil befinden sich die A2L-Objekte. Hier werden die Mess- und Verstellgrößen über verschiedene Parameter und Schlüsselwörter spezifiziert. In diesem Bereich kann es auch nach Fertigstellung der A2L-Datei noch zu Änderungen kommen, da auch im Laufe des Projektes z.B. noch Messgrößen hinzugefügt werden.

Messgrößen Die Messgrößen werden über das Schlüsselwort MEASUREMENT definiert. Manche

Parameterangaben sind opti0onal (gekennzeichnet in[]), während andere Angaben

wie der Name verpflichtend sind.

Prototype:

/begin MEASUREMENT

ident Name

string LongIdentifier

datatype Datatype

ident Conversion

uint Resolution

float Accuracy

float LowerLimit

float UpperLimit

[-> ANNOTATION]*

[-> ARRAY_SIZE]

[-> BIT_MASK]

[-> BIT_OPERATION]

[-> BYTE_ORDER]

[-> DISCRETE]

[-> DISPLAY_IDENTIFIER]

[-> ECU_ADDRESS]

[-> ECU_ADDRESS_EXTENSION]

[-> ERROR_MASK]

[-> FORMAT]

[-> FUNCTION_LIST]

[-> IF_DATA]*

[-> LAYOUT]

[-> MATRIX_DIM]

[-> MAX_REFRESH]

[-> PHYS_UNIT]

[-> READ_WRITE]

[-> REF_MEMORY_SEGMENT]

[-> SYMBOL_LINK]

[-> VIRTUAL]

/end MEASUREMENT



Beispiel:

/begin MEASUREMENT

FP_LED

"Rohwert Ziel-Fahrprogramm"

UBYTE NonDim_2p0 0 0 0 10

ECU_ADDRESS 0xD000B47C

ECU_ADDRESS_EXTENSION 0x0

/begin IF_DATA XCP

/begin DAQ_EVENT VARIABLE

/begin DEFAULT_EVENT_LIST

EVENT 0001

/end DEFAULT_EVENT_LIST

/end DAQ_EVENT

/end IF_DATA

/end MEASUREMENT

Verstellgrößen Die Verstellgrößen werden in der A2L-Datei über das Schlüsselwort CHARACTERISTIC spezifiziert. Auch hier gibt es optionale [] und obligatorische

Parameterangaben.

Prototype:

/begin CHARACTERISTIC ident Name


enum Type

ulong Address

ident Deposit

float MaxDiff

ident Conversion

float LowerLimit

float UpperLimit

[-> ANNOTATION]*

[-> AXIS_DESCR]*

[-> BIT_MASK]

[-> BYTE_ORDER]

[-> CALIBRATION_ACCESS]

[-> COMPARISON_QUANTITY]

[-> DEPENDENT_CHARACTERISTIC]

[-> DISCRETE]

[-> DISPLAY_IDENTIFIER]

[-> ECU_ADDRESS_EXTENSION]

[-> EXTENDED_LIMITS]

[-> FORMAT]

[-> FUNCTION_LIST]

[-> GUARD_RAILS]

[-> IF_DATA]*

[-> MAP_LIST]

[-> MATRIX_DIM]

[-> MAX_REFRESH]

[-> NUMBER]



[-> PHYS_UNIT]

[-> READ_ONLY]

[-> REF_MEMORY_SEGMENT]

[-> STEP_SIZE]

[-> SYMBOL_LINK]

[-> VIRTUAL_CHARACTERISTIC]

/end CHARACTERISTIC

Beispiel:

/begin CHARACTERISTIC Pehp_IDATA.T_FP_delay

"Zeit für Übergang von Ziel- auf Ist-Fahrprogramm HPP"

VALUE 0xA01350CC UWORD_COL_DIRECT 0 ms_f10 0 60000


EXTENDED_LIMITS 0 60000

BYTE_ORDER MSB_LAST

FORMAT "%6.0"

/end CHARACTERISTIC

Umrechnungs-vorschriften

Häufig werden für Mess- oder Verstellgrößen zusätzlich Umrechnungsvorschriften definiert, wenn beispielsweise ein Objekt in eine physikalische Einheit umgerechnet werden soll. Dies erfolgt über das Schlüsselwort COMPU_METHOD.

Prototype:

/begin COMPU_METHOD ident Name


enum ConversionType

string Format

string Unit

[-> COEFFS]

[-> COEFFS_LINEAR]

[-> COMPU_TAB_REF]

[-> FORMULA]

[-> REF_UNIT]

[-> STATUS_STRING_REF]

/end COMPU_METHOD

Dabei gibt es verschiedene Umrechnungstypen:

IDENTICAL Rohwert und physikalischer Wert sind identisch, keine Umrechnung erforderlich

FORM Umrechnung erfolgt über eine Formel (wird mit dem Schlüsselwort FORMULA

spezifiziert)

LINEAR Umrechnung erfolgt linear nach f(x)=ax+b

(a und b werden über das Schlüsselwort COEFFS_LINEAR spezifiziert)

RAT_FUNC Umrechnung erfolgt über eine rationale Funktion: f(x) = (axx+bx+c)/(dxx+ex+f)

a, b, c, d, e, f werden dabei über das Schlüsselwort COEFFS spezifiziert.

TAB_INTP Umrechnungstabelle mit Interpolation

TAB_NOINTP Umrechnungstabelle ohne Interpolation

TAB_VERB Verbale Umrechnungstabelle



Beispiel:

/begin COMPU_METHOD NonDim_2p0_a ""

RAT_FUNC "%5.0" "-"

COEFFS 2 1 0 0 4 1

/end COMPU_METHOD

Gruppen Hierarchieebenen werden in der A2L-Datei über Gruppen realisiert. In einem Projekt mit vielen Mess- und Verstellgrößen können diese so unterteilt und kategorisiert werden. Es besteht außerdem die Möglichkeit auch Untergruppen zu definieren. Dies verbessert die Übersichtlichkeit in CANape.

Prototype:

/begin GROUP ident GroupName

string GroupLongIdentifier

[-> ANNOTATION]*

[-> FUNCTION_LIST]

[-> IF_DATA]*

[-> REF_CHARACTERISTIC]

[-> REF_MEASUREMENT]

[-> ROOT]

[-> SUB_GROUP]

/end GROUP

Beispiel:

/begin GROUP Maps "Calibration Maps"

ROOT

/begin SUB_GROUP

WorkingPoint

/end SUB_GROUP

/begin REF_CHARACTERISTIC

KF1 KF2 KF3 KF4 KF5 KF6 KF7 KF8

TestKennfeld map1_8_8_uc map4_80_uc map5_82_uc

/end REF_CHARACTERISTIC

/end GROUP

Strukturen In der A2L-Spezifikation existiert kein Schlüsselwort für Strukturen. CANape erkennt diese anhand der Analyse des Objektnamens.

Die gültige Syntax für Strukturen in der A2L sieht folgendermaßen aus:

"." für Objekte (e.g., "TestStructStruct1.TestStruct2.s1")

"[]" for Arrays (e.g., "TestStructStruct1.TestStruct2.s1[0]")



Beispiel:

/begin CHARACTERISTIC Test1.s0 ""

VALUE 0x2080D0 __ULONG_S 0 Test1.s0.CONVERSION 0 4294967295


EXTENDED_LIMITS 0 4294967295

FORMAT "%.15"

/end CHARACTERISTIC

Verweis: Detaillierte Informationen zur Bedeutung der einzelnen Parameter sind in der ASAP2-Spezifikation ASAM MCD-2 MC unter dem jeweiligen Schlüsselwort zu finden.

3.3.2 Funktionsprinzip

Abbildung 3-12: Funktionsprinzip der A2L

Motorgeschwindig-keit als Beispiel

Abbildung 3-12 veranschaulicht das Funktionsprinzip einer A2L-Datei. Als Beispiel soll hier die Motorgeschwindigkeit ausgelesen werden. Über die A2L-Datei erfährt dass Mess- und Kalibriersystem (CANape), an welcher Speicheradresse die Motorgeschwindigkeit liegt und wie die ASAM MCD 1MC-Schnittstelle parametrisiert werden muss. Der ausgelesene Rohwert wird anschließend mithilfe einer Umrechnungsvorschrift, die in der A2L-Datei beschrieben ist, in einen physikalischen Wert umgewandelt.


Handbuch AUTOSAR Calibration OEM


4 OEM


4.1 Zielsetzung Seite 34

4.2 Inhalt des Lastenhefts Seite 34

4.3 Messaufgabe Seite 34

4.4 Kalibrieraufgabe Seite 35

4.5 XCP-Features Seite 35



4.1 Zielsetzung

Checkliste zur Lastenhefterstellung

Dieses Kapitel dient als Checkliste zur Lastenhefterstellung. Der OEM muss sicherstellen, dass die erwähnten Punkte bedacht und je nach Bedarf in das Lastenheft aufgenommen werden.

4.2 Inhalt des Lastenhefts

Der Inhalt des Lastenhefts muss die gewünschten Anforderungen an den Lieferanten definieren. Diese können dabei in obligatorische und optionale Anforderungen unterteilt werden.

Obligatorische Anforderungen

> Auslieferung einer zum Softwarestand passenden A2L

> Konfigurierter XCP-Treiber

> Vorkonfiguriertes CANape Projekt

Optionale Anforderungen

> Build-Umgebung, die die A2L generieren kann

> Auslieferung einer Linker MAP-Datei

Die Auslieferung einer Linker MAP-Datei hat den Vorteil, dass neue Mess- und Verstellgrößen direkt in die A2L-Datei aufgenommen werden können. Wenn im Laufe einer Messaufgabe der Wunsch entsteht weitere Objekte zu messen, sind die Speicheradressen bekannt und diese können hinzugefügt werden.

4.3 Messaufgabe

Zu vermittelnde Informationen

Um die obligatorischen Anforderungen in Bezug auf die Messaufgabe realisieren zu können, benötigt der Zulieferer einige Angaben, wie z.B. die Kategorie der Messgrößen. Doch auch verschiedene Details zur DAQ-Konfiguration sind sowohl für den konfigurierten XCP-Treiber als auch für die A2L-Datei von Bedeutung.

Im Einzelnen müssen Angaben zu folgenden Punkten dem Zulieferer mitgeteilt werden:

> Kategorie der Messgrößen

> Softwarekomponente

> Basissoftware

> BSW Module (z.B. COM, CanNm)

> Laufzeitüberwachung

> Eventgesteuertes Messen über DAQ

> Statische oder dynamische DAQ-Listen

Vector empfiehlt dynamische DAQ-Listen, um Speicher effizienter zu nutzen und gegebenenfalls mehr Signale messen zu können

> Definition der DAQ-Event-Zeitraster

> Verwendung von Zeitstempel

> Verwendung von DAQ-Default-Events



4.4 Kalibrieraufgabe

Zu beachtende Punkte

Auch die Kalibrieraufgabe nimmt Einfluss auf die obligatorischen Anforderungen (A2L-Datei, XCP-Treiber) an den Zulieferer. Die folgenden Punkte sollten dabei bedacht werden:

> Lage der Verstellgrößen

> Softwarekomponente

> NVRAM

> Optimiertes "Online gehen"

Die Zugriffe auf das Steuergerät werden beim optimierten "Online gehen" verringert. Ein Upload-Vorgang findet nur statt, wenn Unterschiede zwischen den Daten im Spiegelspeicher und im Steuergerät festgestellt werden. Diese Vorgehensweise beschleunigt das "Online Gehen".

Für das optimierte "Online gehen" wird die Verwendung eines Spiegelspeichers benötigt. Der Spiegelspeicher wird anhand von Speichersegmenten beschrieben, welche ausschließlich Verstellgrößen beinhalten. Zudem muss im Steuergerät die Checksummenberechnung implementiert sein.

Das optimierte "Online gehen" ist außerdem Voraussetzung für das Offline-Kalibrieren und die Verwendung der Datenstandsverwaltung.

> Verwendung einer flashbaren Hex-Datei (mit kalibrierten Verstellgrößen aus CANape)

4.5 XCP-Features

Zu unterstützende Features

Im Kapitel XCP-Treiber wurden einige Aspekte und Features des XCP-Protokolls erläutert. Im Einzelnen handelt es sich dabei um die Measurement Modi, die Autoselektion und Softwarestandprüfung der A2L-Datei, Online Calibration, Page Switching, Bypassing und den Resume Mode. An dieser Stelle ist es als OEM wichtig dem Lieferanten mitzuteilen, welches dieser Features vom XCP-Treiber unterstützt werden soll.

Wir empfehlen, folgende XCP-Features ins Lastenheft aufzunehmen:

> Measurement Modi Polling und DAQ

> Autoselektion der A2L und die Softwarestandprüfung

> Online Calibration

> Resume Mode

Handbuch AUTOSAR Calibration Lieferant


5 Lieferant


5.1 Einleitung Seite 37

5.2 Voraussetzungen Seite 37

5.3 Definition von Mess- und Verstellgrößen Seite 37

Messen und Kalibrieren von AUTOSAR Softwarekomponenten

Messen von Ports und Variablen

XCP-Events

Softwarekomponente mit Verstellgrößen

Verstellgrößen für mehrere Softwarekomponenten

Konfiguration der RTE (Runtime Environment)

Messen und Kalibrieren ohne Unterstützung der RTE

Debuggen der BSW (Basic Software)

5.4 Konfiguration des XCP-Moduls Seite 42

DAQ-Listen-Konfiguration

Tool-gesteuerte DAQ-Zeitstempel-Option

XCP-Event-Information

Softwarestandprüfung

5.5 Konfiguration der Speicherverwaltung Seite 45

Konfiguration für den Resume Mode

5.6 Erstellen einer A2L-Datei Seite 46

Erstellen einer Master-A2L-Datei

Erweiterung der Master-A2L-Datei

Arbeiten mit dem ASAP2 Tool-Set

Arbeiten mit CANape und dem ASAP2 Editor

5.7 Schneller Zugriff auf das Steuergerät über das VX-Modul Seite 53

5.8 Weiterführende Themen Seite 53



5.1 Einleitung

Bestimmte Funktionen und Konfigurationen für AUTOSAR

Die vom OEM gestellte Mess- und Kalibrieraufgabe wird bei der Implementierung der Steuergerätesoftware umgesetzt. Bei der Verwendung von AUTOSAR konformen Softwaremodulen ist es erforderlich, die Module entsprechend zu konfigurieren und bestimmte Funktionen zu implementieren.

Das folgende Kapitel erläutert Vorgehensweisen, wie die Anforderungen an die Steuergerätesoftware umgesetzt werden. Die Beschreibung bezieht sich auf das Produkt MICROSAR.

Im ersten Teil wird auf die Konfiguration der Softwarekomponenten (SW-C), der MIRCOSAR RTE und der MICROSAR BSW Module eingegangen.

Anschließend gibt es einen kurzen Überblick über die Integration des XCP-Slaves. Der XCP-Slave wird vom XCP-Modul bereitgestellt.

Abschließend wird auf die Erstellung der A2L-Beschreibungsdatei eingegangen, welche zentraler Bestandteil der CANape Konfiguration sein wird.

5.2 Voraussetzungen

Softwarekomponen-ten

Die folgenden Softwarekomponenten ab mindestens den folgenden Versionen werden für die Beschreibungen vorausgesetzt:

> Vector Informatik DaVinci Developer 3.13.12 (SP1)

> Vector Informatik DaVinci Configurator 5.13.13 (SP2)

> Vector Informatik ASAP2 Tool-Set 7.0

> Vector Informatik CANape 10.0 SP4

> Vector MICROSAR 4 Basic Software ab Release 16 inklusive MICROSAR XCP und den MICROSAR RTE

5.3 Definition von Mess- und Verstellgrößen

Über Softwarekom-ponenten

Die Mess- und Verstellgrößen für die Mess- bzw. Kalibrieraufgabe des OEM befinden sich üblicherweise in den Softwarekomponenten (SW-C). Diese Größen werden mit Konfigurationswerkzeugen wie z.B. dem DaVinci Developer definiert. Hierzu ist auch die Konfiguration der RTE notwendig.

Ohne RTE Weitere Mess- und Verstellgrößen können auch ohne die Unterstützung der AUTOSAR Schnittstellen bereitgestellt werden. Eine kurze Erläuterung wird in Kapitel Messen und Kalibrieren ohne Unterstützung der RTE gegeben.

Über A2L-Datei Zusätzlich können auch Messgrößen innerhalb der AUTOSAR Basissoftware zur Messkonfiguration hinzugefügt werden. Dies erfolgt, indem bekannte Messgrößen aus der Basissoftware in die A2L-Datei eingefügt werden.



5.3.1 Messen und Kalibrieren von AUTOSAR Softwarekomponenten

Messbare Objekte Messbare Objekte können mithilfe eines Konfigurationswerkzeuges, z.B. des DaVinci Developers, konfiguriert werden. Zu messbaren Objekten gehören Datenelemente (data elements) von Anwendungs- und Service-Ports (application port

interfaces), Variablen für die Kommunikation zwischen Runnables (inter-

runnable variables) und Verstellgrößen (calibration parameters).

Abbildung 5-1: SW-C verbunden mit Ports

Abbildung 5-2: Calibration Port interface mit Parameter zum Messen/Kalibrieren

Calibration Access Die oben genannten Objekte können im DaVinci Developer über den Calibration Access mit der Einstellung ReadOnly messbar gemacht werden. Die Einstellung ReadWrite ermöglicht das Schreiben von Objekten mit CANape. In den von CANape gebräuchlichen Anwendungsfall "Kalibrieren" fällt das Schreiben von Verstellgrößen. Das Schreiben von anderen Datenelementen kann zwar konfiguriert werden, ist jedoch nicht empfehlenswert. Gründe hierfür sind der fehlende exklusive Schreibzugriff, sodass die Informationen durch den Anwendungscode wieder überschrieben werden können.

Abbildung 5-3: Mess- und Verstelloption für ein Objekt (z.B. data

element)

Verstellgrößen spezifizieren

Der AUTOSAR Standard bietet die Möglichkeit, Verstellgrößen zu spezifizieren. Es wird zwischen zwei Varianten unterschieden.

Verstellgrößen können innerhalb einer Softwarekomponente definiert werden. Diese sind dann auch nur für diese Softwarekomponente verfügbar.

Die zweite Variante ist die Verwendung einer Kalibrier-Softwarekomponente, welche Verstellgrößen für mehrere Softwarekomponenten bereitstellen kann.

5.3.2 Messen von Ports und Variablen

Konfiguration der Datenelemente

Datenelemente, welche gemessen werden sollen, müssen anhand des Calibration & Measurement Support entsprechend konfiguriert werden. Für das Messen ist der Calibration Access auf den Wert ReadOnly zu setzen.

Folgende Datenelemente können gemessen werden:

> Data Elements of Sender/Receiver Ports

> Operation Arguments of Client/Server Ports (derzeit nicht von RTE

unterstützt)



> Inter-Runnable Variables

> Calibration Parameters

Für Sender und Receiver Ports können die Datenelemente auf einfache Art und

Weise über die Eigenschaften (Properties) für das Verstellen konfiguriert werden.

Abbildung 5-4: Konfiguration eines Sender/Receiver

Ports

5.3.3 XCP-Events

RTE-Unterstützung Die RTE unterstützt die Generierung von XCP-Events. Zum einen wird für jede Task ein Event erstellt. Diese Events dienen zum Messen von Variablen der Runnables,

welche innerhalb der Task ausgeführt werden. Hierbei sollten folgende Punkte beachtet werden:

> Die RTE generiert XCP-Events am Ende jeder Task. Ein XCP-Event hat somit keinen direkten Bezug zu der Ausführung eines Runnable. Es kommt also

durchaus vor, dass zwischen XCP-Events ein Runnable nicht durchläuft.

> Werden von der RTE XCP-Events generiert, so muss im XCP-Modul auch der DAQ-Messmodus aktiviert werden.

> Es ist damit zu rechnen, dass die XCP-Events der RTE sehr oft aufgerufen werden.

> Die generierten XCP-Events sind nicht zyklisch, daher kann keine Aussage über die zu erwartende Buslast getroffen werden.

Zum anderen generiert die RTE auch XCP-Events für den oben erwähnten Zugriff auf gepufferte Ports. Über die Beschreibung in der A2L-Datei wird sichergestellt, dass diese Ports fix mit dem generierten Event gemessen werden.

5.3.4 Softwarekomponente mit Verstellgrößen

Zugriff von außen Die Definition von Verstellgrößen (Calibration Parameter) ermöglicht es, eine

Verstellgröße innerhalb der Softwarekomponente von außen über XCP zu verändern.

Innerhalb der Softwarekomponente wird auf diese Verstellgröße nur lesend



zugegriffen. Außerhalb der SW-C besteht allerdings die Möglichkeit, diese Verstellgrößen zu ändern.

Abbildung 5-5: Eigenschaften einer Verstellgröße

Eine Verstellgröße besitzt einen Datentyp und einen Initialwert. Der Gültigkeitsbereich (Scope) und der Mess- und Kalibrierzugriff kann konfiguriert werden.

Hinweis: Weitere Informationen über diese Parameter können der DaVinci Developer Hilfe entnommen werden.

5.3.5 Verstellgrößen für mehrere Softwarekomponenten

Softwarekomponente vom Typ Kalibrieren

Für die Bereitstellung von Verstellgrößen für mehrere Softwarekomponenten wird eine Softwarekomponente vom Typ Kalibrieren verwendet.

Eine solche Softwarekomponente besitzt nur Kalibrier-Ports (Calibration Ports),

die für andere SW-Cs Verstellgrößen zur Verfügung stellen und als Sender-Ports agieren.

Darstellung einer Kalibrier-Softwarekomponente im DaVinci Developer:

Abbildung 5-6: Grafisches Interface

Abbildung 5-7: List with the configured ports

Jeder Kalibrier-Port enthält wiederum Verstellgrößen. Diese Verstellgrößen sind genauso zu handhaben wie Verstellgrößen innerhalb einer Softwarekomponente.



5.3.6 Konfiguration der RTE (Runtime Environment)

Unterstützung der RTE notwendig

Um Softwarekomponenten über das XCP-Protokoll messen und kalibrieren zu können, ist die Unterstützung der RTE notwendig. Der MICROSAR RTE Generator bietet diese Mess- und Kalibierunterstützung.

Verweis: Die Aktivierung der Mess- und Kalibrierunterstützung kann anhand der Technischen Referenz MICROSAR RTE - Technical Reference, Kapitel "Measurement and Calibration" nachvollzogen werden.

Von CANape unterstützte Online-Kalibrierverfahren

CANape unterstützt derzeit folgende Online-Kalibrierverfahren:

> Initialized RAM

> Single Pointered

Initialized RAM Das Standard-Kalibrierverfahren mit CANape ist das "Initialized RAM". Dieses Verfahren eignet sich dann, wenn das Steuergerät genügend Speicher im RAM für alle zu kalibrierenden Verstellgrößen hat.

Single Pointered Der Vorteil des Kalibrierkonzeptes "Single Pointered" besteht darin, dass nicht alle Verstellgrößen ständig eine Kopie im RAM-Speicher haben. Somit ist bei eingeschränkter RAM-Speicherkapazität dieses Verfahren zu wählen.

Bei der Generierung des Steuergeräte Quellcodes durch den DaVinci Configurator werden auch A2L-Fragmente erzeugt. Das Einbinden der erstellten A2L-Fragmente Rte.a2l und XCP_events.a2l wird im Kapitel Erstellen einer A2L-Datei näher

beschrieben.

5.3.7 Messen und Kalibrieren ohne Unterstützung der RTE

Zu beachtende Punkte

Es besteht die Möglichkeit, das Messen und Kalibrieren auch ohne die Unterstützung der RTE zu verwenden.

Hierbei sind folgende Punkte zu beachten.

> Das Messen per DAQ-Events erfordert, dass entsprechende XCP-Events programmiert werden und diese dann in der A2L-Datei beschrieben werden.

Beispiel: Einbinden eines XCP-Events innerhalb eines Runnables

FUNC(void, RTE_CTAPMCU_APPL_CODE) RCtApMy_Algo(void)

{

// Perform algorithm within my runnable

...

// Trigger user defined XCP Event

Xcp_Event(12);

}

> Für das Online-Kalibrieren muss eine eigene Implementierung der Kalibriermethode ("Initialized RAM" oder AUTOSAR "Single Pointered") umgesetzt werden.

> Kalibrieren und Messen erfordern eine oder mehrere A2L-Dateien, welche



manuell oder mit einem externen Programm (z.B. ASAP2 Creator oder TargetLink) erstellt werden. Diese A2L-Dateien müssen mit den von den Vector Werkzeugen generierten A2L-Dateien zusammengeführt werden. Für das Zusammenführen kann wie im Kapitel Erstellen einer A2L-Datei auf Seite 46 noch erklärt wird, das Programm ASAP2 Merger verwendet werden.

5.3.8 Debuggen der BSW (Basic Software)

Module, die Messgrößen bereitstellen

MICROSAR AMD ermöglicht die Messung BSW interner Statusinformationen über XCP, um das Debuggen zu erleichtern. Zu diesem Zweck liefert MICROSAR AMD Messgrößen für MICROSAR Module wie COM, CANNM oder CANTP.

Generierung der A2L-Informationen

Für die Generierung der A2L-Informationen erstellt DaVinci Configurator automatisch die für die A2L notwendigen A2L-Fragmente McData.a2l und

McData_Events.a2l.

Verweis: Informationen für die Konfiguration und ausführlichere Anleitungen sind im User Manual AMD aufgeführt.

5.4 Konfiguration des XCP-Moduls

Konfigurationswerk-zeug DaVinci Configurator Pro

Das XCP-Modul wird mit dem Konfigurationswerkzeug DaVinci Configurator Pro Software Component Configuration konfiguriert. Auf Basis dieser Konfiguration wird anschließend der Quellcode für die XCP-Slave-Implementierung erzeugt.

UserManual_AMD.pdf



Abbildung 5-8: Einstellungen in DaVinci Configurator Pro

Verweis: Informationen und eine Anleitung zur Konfiguration des Moduls sind in dem Dokument MICROSAR XCP – Technical Reference enthalten.

Vorschau Im Folgenden wird auf die wichtigsten Konfigurationsparameter eingegangen. Zusätzlich werden die optionalen XCP-Features Measurement Modi und Autoselektion und Softwarestandprüfung der A2L-Datei im Kontext des XCP-Moduls beschrieben.

5.4.1 DAQ-Listen-Konfiguration

Implementierung für dynamische DAQ-Listen

Das XCP-Modul besitzt zum aktuellen Stand nur die Implementierung für dynamische DAQ-Listen.

Vordefinierte DAQ-Listen (statische DAQ-Listen) werden aktuell nicht vom XCP-Modul unterstützt. Für die Verwendung eines XCP-Slaves innerhalb eines AUTOSAR Software-Stacks sind statische DAQ-Listen nicht geeignet. Zum einen benötigen diese unnötig viel Speicherplatz. Zum anderen kann bei sehr vielen implementierten XCP-Events die Anzahl möglicher statischer DAQ-Listen überschritten werden, falls eine fixe Zuordnung verwendet wird.

Größe des Speicherplatzes

Die Größe des für die DAQ-Konfiguration bereitgestellten Speicherplatzes kann implizit durch die Festlegung der maximal zulässigen Anzahl von DAQ-Listen pro XCP-Ereignis, der maximalen Anzahl von ODTs und ODT-Einträgen pro DAQ-Liste limitiert werden.

5.4.2 Tool-gesteuerte DAQ-Zeitstempel-Option

Zusätzliche Optionen für Zeitstempel

Wie im Kapitel Measurement Modi bereits beschrieben, besteht die Möglichkeit einen Zeitstempel des Steuergeräts zu verwenden. Dazu muss dies im XCP-Treiber unterstützt werden. Als zusätzliche Option kann der XCP-Treiber grundsätzlich ("timestamp fixed") oder auf Anfrage die Zeitstempel mitliefern. Die Größe des Zeitstempels (1-, 2-, 4-Byte pro Event) sollte, wie im Beispiel ersichtlich, wohl überlegt gewählt werden.

Beispiel: Die ECU verwendet einen 1-µs-Zähler für die Generierung von DAQ-Zeitstempeln. Es wird nur ein 2-Byte-großer Zeitstempel gewählt.

Dies hat zur Folge, dass der Zeitstempel alle 65 ms überläuft. Damit das MCD-Tool einen Überlauf erkennen kann, muss im Messaufbau mindestens ein Signal gemessen werden, welches öfter als 65 ms einen Messwert und somit auch einen Zeitstempel liefert.

5.4.3 XCP-Event-Information

XCP-Slave an den XCP-Master

XCP-Event-Informationen können auf zwei Arten vom XCP-Slave bereit gestellt werden: Entweder durch eine generierte A2L-Datei, welche die konfigurierten Events enthält. Oder über den XCP-Befehl GET_DAQ_EVENT_INFO, der die Event-

Informationen direkt vom Steuergerät liefert. In beiden Fällen müssen die Event-Informationen in dem entsprechenden Generator konfiguriert werden.



Achtung: Wenn das GET_DAQ_EVENT_INFO-Feature im XCP-Modul aktiviert ist, so

werden die automatisch erzeugten Events der RTE nicht berücksichtigt.

Empfehlung:

Keine RTE-Events werden genutzt:

Wenn keine RTE-Events benutzt werden, kann die Funktionalität der XCP-Event-Information verwendet werden. Es ist jedoch darauf zu achten, dass alle Events beschrieben werden, welche implementiert sind (auch die der BSW-Komponente).

RTE-Events werden genutzt:

Da die Funktion GET_DAQ_EVENT_INFO alle Events, die in A2L-Dateien definiert

wurden, überschreibt, wird die Deaktivierung dieser Funktion empfohlen, wenn RTE-Events genutzt werden. In diesem Fall kann das erzeugte A2L-Fragment XCP_events.a2l in die Master-A2L eingefügt werden (siehe Kapitel Erstellen einer

A2L-Datei).

5.4.4 Softwarestandprüfung

Aspekte zur Implementierung

In Kapitel Autoselektion und Softwarestandprüfung der A2L-Datei wurden bereits die Möglichkeiten zur Softwarestandprüfung vorgestellt. An dieser Stelle sollen die Aspekte zur Implementierung erklärt werden.

XCP Station Identifier (Protokollbefehl GET_ID)

Sinnvollerweise sollte der Station Identifier zentral definiert werden und anschließend nur noch eingebunden werden. Dies kann wie folgt erreicht werden:

> Keine manuelle Konfiguration des XCP-Identifier in DaVinci Configurator Pro ausführen.

> Eine benutzerdefinierte Konfiguration anlegen mit exemplarischem Inhalt, z.B.:

Beispiel: user_cfg.h: /* Standard commands */

#define kXcpStationIdLength 7u

extern CONST(XcpCharType, XCP_CONST) kXcpStationId[];

user_cfg.c: CONST(XcpCharType, XCP_CONST) kXcpStationId[] = "EcuName_V1-2-

0";

Werden diese Informationen in den Build-Prozess eingebunden, so wird der Station Identifier EcuName_V1-2-0 verwendet.

EPK-Prüfung Es empfiehlt sich, die EPK-Kennung sowohl im Quellcode als auch in der A2L-Datei mit jedem Kompiliervorgang automatisch und konsistent erzeugen zu lassen.

Im Steuergerät wird die EPK idealerweise an eine konstante Adresse abgelegt. Dies könnte im Quellcode wie folgt aussehen:

Beispiel: __attribute__((section("calflash_signature"))) const char

epk[26] = "EcuName V1.2.0 01.03.2012";

In der A2L-Datei muss die EPK-Kennung ebenfalls entsprechend implementiert sein. Für das obige Beispiel in der Steuergerätesoftware sieht der Eintrag in der A2L folgendermaßen aus:



Beispiel:

/begin MOD_PAR "EcuName"

ADDR_EPK 0x350002

EPK "EcuName V1.2.0 01.03.2012"

/end MOD_PAR

Checksumme über Code-Segmente im Steuergerät (ab CANape 11.0)

Damit CANape die Checksumme über Code-Segmente berechnen kann, werden einige Informationen benötigt. Zum einen müssen die Code-Segmente in der A2L-Datei definiert sein. Zum anderen benötigt CANape eine HEX-Datei, welche ebenfalls die Code-Segmente enthält.

5.5 Konfiguration der Speicherverwaltung

NVM-Module Der AUTOSAR Standard sieht ein Modul NVM für die Speicherverwaltung vor. Messen und Kalibrieren haben meistens keine direkten Berührungspunkte mit der Speicherverwaltung.

Der einzige Anwendungsfall für die Konfiguration des NVM in Bezug auf das XCP-Modul ist die Verwendung des Resume Mode.

5.5.1 Konfiguration für den Resume Mode

Implementierung Für die Implementierung des Resume Modes muss der XCP-Treiber seine DAQ-Konfiguration in einen nicht flüchtigen Speicher ablegen. Zwei Informationen müssen für den Resume Mode gespeichert werden: Zum einen der Umstand, dass der Modus aktiv ist und zum anderen die DAQ-Konfiguration an sich.

Hierzu wird im NVM-Modul ein Speicherblock konfiguriert, welcher groß genug für die Konfiguration ist. Dessen Größe lässt sich aus der im XCP-Modul konfigurierten Puffergröße ableiten.

Puffergröße Zur Berechnung der Puffergröße kann folgende Formel verwendet werden:

lsZeitstempe des Größej) ,l(Messsignatime cycle

1 PufferzeitePuffergröß

Signal

j

i Event

Event

i i

API-Methoden Die von dem NVM-Modul bereitgestellten API-Methoden können anschließend benutzt werden, um im XCP-Modul die Konfiguration zu speichern und zu laden. Dieser Programmteil wird nicht automatisch generiert und muss ausprogrammiert werden.

Verweis: Die zu implementierenden Methoden können im Dokument MICROSAR XCP – Technical Reference nachgeschlagen werden.



5.6 Erstellen einer A2L-Datei

Für eine vollständige A2L-Datei, alle relevanten Informationen bzgl. des Steuergeräts zusammenführen

Die A2L-Beschreibungsdatei enthält alle relevanten Informationen bezüglich des Steuergerätes. Diese Informationen werden beim Erstellungsprozess aus verschiedenen Generatoren erzeugt. Es werden auch Informationen benötigt, z.B. die physikalischen Adressen, welche erst nach dem Erstellen der Steuergeräte-Applikation vorhanden sind.

Um letztendlich eine vollständige A2L-Beschreibungsdatei zu erhalten, müssen alle Teile zusammengeführt werden. Abschließend müssen noch die Adressen in der A2L-Datei aktualisiert werden.

Idealerweise gliedert sich dieser Prozess in den automatisierten Erstellungsprozess der Steuergeräte-Applikation ein.

5.6.1 Erstellen einer Master-A2L-Datei

Hinweis: MICROSAR XCP stellt eine _Master.a2l-Datei als Vorlage in dem

Auslieferungsordner …\<Delivery>\Misc\McData bereit. Alle Dateien, die von

Vector Tools generiert werden, finden Sie im Projektordner …\<ProjectFolder>\Config\McData.

Ziel Es wird eine Master-A2L-Datei benötigt, welche alle Teildatenbasen zu einer vereinigt. Diese Masterdatei kann dann als Vorlage für die zu erstellende Datei verwendet werden. Ziel ist es, am Ende eine einzige Datei mit allen Informationen zu erhalten.

Projektspezifische Master-A2L-Datei

Diese Master-A2L-Datei ist sehr projektspezifisch. Die Informationen für eine A2L-Datei werden von unterschiedlichen Generatoren erstellt. Teilweise werden Informationen auch manuell hinzugefügt. Deshalb wird die Master-A2L-Datei nicht automatisch erstellt.

Abbildung 5-9: Prozess zur Erstellung einer Master-A2L-Datei (Beispiel)



include commands Der generelle Aufbau einer A2L-Datei ist bereits in der Abbildung 3-11: Struktur der A2L-Datei beschrieben. Um die einzelnen A2L-Fragmente zusammenzuführen, werden include-Befehle verwendet. Diese werden der modularen Struktur (AML, General ECU Implementation, IF_DATA and A2L Objects) entsprechend eingefügt.

Damit das Zusammenführen der einzelnen Speichersegmente reibungslos funktioniert, müssen in der Master-A2L-Datei projekt-spezifische Anpassungen vorgenommen werden. Diese sind mit einem // TODO gekennzeichnet.

Anpassen der include Befehle

Für die unten aufgeführten includes müssen die Dateipfade eventuell angepasst

werden. Entfernen Sie die entsprechenden includes, wenn diese für Ihr Projekt

nicht erforderlich sind.

Verwendung eines Texteditors

Um die Master-A2L-Datei anzulegen und anzupassen, verwenden Sie am besten einen Texteditor.

Master A2L file ASAP2_VERSION 1.60

/begin PROJECT ExampleProject ""

/begin MODULE MyModuleName ""

AML /begin A2ML

...

block "IF_DATA" taggedunion if_data {

...

};

...

//TODO: Include AML Information if required.

/end A2ML

General ECU implementation

/begin MOD_COMMON ""

// TODO: Set the Byte Order of the ECU as defined by the

ECUC module MSB_FIRST or MSB_LAST and configure the byte

alignment used in this project.

/end MOD_COMMON

/begin MOD_PAR ""

/include "Rte_MemSeg.a2l"

// TODO: Add or include MEMORY_SEGMENT information here.

/end MOD_PAR

IF_DATA /begin IF_DATA XCP

/include "XCP.a2l"

/begin DAQ

// TODO: Add or include further a2l file splitter that

provide XCP Events.

/include "XCP_daq.a2l"

/include "XCP_events.a2l"

/include "Rte_XcpEvents.a2l"

/include "McData_Events.a2l"

/end DAQ

/include "GenData\CanXcpAsr.a2l"



/end IF_DATA

A2L objects // TODO: Add or include further a2l splitter that provide

measurement objects.

/include "Rte.a2l"

/include "McData.a2l"

/end MODULE

/end PROJECT

5.6.2 Erweiterung der Master-A2L-Datei

Include-Befehle Eine gute Vorgehensweise für das Einbringen zusätzlicher Inhalte in die A2L-Datei ist die Erweiterung der Master-A2L-Datei über include-Befehle. Es wird davon

abgeraten weitere Informationen direkt zu kopieren und ohne include-Befehle

einzufügen.

Einbinden von Steuergeräte Informationen (General ECU Implementation)

Die A2L-Elemente MOD_COMMON und MOD_PAR werden am besten in weiteren A2L-

Dateien beschrieben, welche manuell per include-Befehl in die A2L-Datei

eingebunden werden. Diese include-Anweisungen sind in der Masterdatei bereits

eingefügt und liegen dem AUTOSAR Calibration Handbuch bei.

Einbinden von Schnittstellen-Daten (Interface Data)

Einige Teile der IF_DATA-Informationen werden von Generatoren erstellt. Diese Teile

werden per include-Befehl eingebunden. Sollen weitere manuelle Informationen

hinzugefügt werden, so ist das Erstellen zusätzlicher A2L-Dateien zu empfehlen. Diese müssen an den entsprechenden Stellen in die IF_DATA eingebunden werden.

Das Zusammenführen von IF_DATA-Informationen aus verschiedenen A2L-Dateien

mittels des ASAP2 Mergers wird nicht unterstützt.

Die include-Anweisung UserDefinedXcpEvents.a2l in der Masterdatei fügt

zum Beispiel manuell definierte XCP-Events der IF_DATA-Sektion hinzu.

Einbinden von A2L-Objekten (Mess- und Verstellgrößen)

Am häufigsten werden Teildatenbasen eingebunden, die Mess- und Verstellgrößen enthalten. Diese Dateien können z.B. von Generatoren wie Simulink, TargetLink oder dem ASAP2 Creator erstellt werden.

Ein weiteres Beispiel ist die Basissoftware, welche ebenfalls messbare Objekte enthält.

Diese Dateien können manuell über einen weiteren include-Befehl, mithilfe des

ASAP2 Tool-Sets oder des ASAP2 Editors eingebunden werden.

Hinweis: Eine Datei kann nur manuell per include-Befehl hinzugefügt werden,

wenn dies die Struktur der Datei zulässt. Eine vollständige A2L-Datei kann nicht per include hinzugefügt werden.



Beispiel: A2L-Fragment – Einfügen per include-Befehl möglich

/CHARACTERISTIC

…

/MEASUREMENT

…

Beispiel: Vollständige A2L-Datei – Einfügen nur per ASAP2 Merger möglich

/begin PROJECT ExampleProject ""

/begin MODULE MyModuleName ""

/CHARACTERISTIC

…

/MEASUREMENT

…

/end MODULE

/end PROJECT

5.6.3 Arbeiten mit dem ASAP2 Tool-Set

5.6.3.1 Zusammenführen von weiteren A2L-Dateien

Verfahren für vollständige A2L-Dateien

Eine vollständige A2L-Datei (wie im Beispiel oben) kann nicht per include-Befehl in

die Master-A2L-Datei eingebettet werden. Ein Zusammenführen solcher A2L-Dateien kann mithilfe des Programmes ASAP2 Merger, das Teil des ASAP2 Tool-Sets ist, ausgeführt werden.

Abbildung 5-10: Einbinden von A2L-Objekten

Verweis: Die Verwendung des ASAP2 Mergers und seine Einstellungsmöglichkeiten in der INI-Datei können im ASAP2 Tool-Set Handbuch nachgeschlagen werden.

Beispiel: Es werden die erzeugten Dateien Extern1.a2l und ExternN.a2l als Slave in die

Master-A2L-Datei Master.a2l eingespielt. Das Resultat des Zusammenführens

wird dann in die Datei ECU_merged.a2l geschrieben. Notwendige Einstellungen

ASAP2Tool-Set_Handbuch_V800_49.pdf



werden mit der Datei merger.ini mitgegeben. Die merger.ini muss vorhanden

sein, da der ASAP2 Merger die Einstellung aus dieser Datei bei jedem Kommandozeilenaufruf übernimmt.

Kommandozeilenaufruf: ASAP2Merger.exe -m Master.a2l -s Extern1.a2l -s ExternN.a2l -o

ECU_Merged.a2l -p "<INI_PATH>\merger.ini"

Merger.ini [OPTIONS]

MERGE_GROUP_CONTENTS = 1 // Bei Gruppen mit demselben Namen

werden die Inhalte gemergt

DISABLE_SUFFIXES = 1 // Keine Suffixe für importierte

Objekte erstellen

5.6.3.2 Aktualisierung der Adressen in der A2L-Datei

Notwendigkeit Das Aktualisieren der Mess- und Verstellgrößen in einer A2L-Datei ist notwendig, da die Adressen der Objekte erst nach dem Erstellen des Programmcodes (dem Kompilieren) bekannt sind.

Weiterer Vorteil Der Schritt der Aktualisierung kann auch dafür benutzt werden, mithilfe der Master-A2L-Datei eine vollständige A2L-Datei zu erstellen, welche keine Includes mehr

besitzt. Dies hat den Vorteil, dass später nur mit einer Datei gearbeitet werden muss und somit nicht immer alle Teildatenbasen separat kopiert werden müssen.

Abbildung 5-11: Aktualisierung der Adressen in der A2L-Datei

Verweis: Die Verwendung des ASAP2 Updaters und seine Einstellungsmöglichkeiten in der INI-Datei können im ASAP2 Tool-Set Handbuch nachgeschlagen werden.

Hinweis: Eine _Updater.ini-Datei finden Sie im Auslieferungsordner

…\Misc\McData. Sie wird mit dem AUTOSAR Calibration Handbuch mitgeliefert.

Template _Updater.ini

Die _Updater.ini-Datei wird als Template im Auslieferungsordner

…\Misc\McData mitgeliefert, was durch den Unterstrich gekennzeichnet ist.

Notwendige Anpassungen

Die _Updater.ini-Datei muss in jedem Falle noch angepasst werden, z.B. muss

mindestens das MAP_FORMAT angegeben werden. Die Array-Notation in [ ] ist

notwendig, da dies so von MICROSAR verwendet wird.



Beispiel: Die Datei Master.a2l wird eingelesen und die Adressen der Mess- und

Verstellgrößen werden aktualisiert und in die Datei ECU.a2l geschrieben. Die

Adressen für die Aktualisierung werden aus der Datei demo.elf entnommen.

Informationen des Aktualisierungsvorgangs werden in der Datei a2l.log

mitgeschrieben. Notwendige Einstellungen werden mit der Datei updater.ini

mitgegeben. Auch der ASAP2 Updater benötigt zwingend eine updater.ini-Datei.

Kommandozeilenaufruf: ASAP2Updater.exe -I Master.a2l -O ECU.a2l -A demo.elf -L

a2l.log -T "<INI_PATH>\Updater.ini"

updater.ini: [OPTIONS]

MAP_FORMAT=31 // Use ELF 32 Bit

5.6.3.3 Schritt-für-Schritt-Anleitung mit dem ASAP2 Tool-Set

Empfehlung Die Verwendung des ASAP2 Tool-Set wird empfohlen, da sich dieses in einen automatischen Generierungsprozess einbinden lässt. Der Adressupdate und der Export der Datenbasis kann als Post-Build-Aufgabe eingebunden werden.

STEP 1: A2L-Fragmentgenerierung Damit A2L-Fragmente generiert werden, müssen die entsprechenden Generatoren konfiguriert werden. Dies geschieht, indem man diese in den Build-Prozess einbindet.

Es muss sichergestellt sein, dass die A2L-Fragmente bei der Erstellung an einen fest definierten Ort abgelegt werden.

STEP 2: Manuelle Erstellung von A2L-Fragmenten Informationen, welche später in der A2L-Datei vorhanden sein sollen und nicht automatisch generiert werden, müssen manuell erstellt werden.

STEP 3: Anpassung der Master-A2L-Datei Eine Master-A2L-Datei muss erstellt werden. Hierbei sind die Pfade der include-

Befehle entsprechen anzupassen

STEP 4: Zusammenführen von weiteren A2L-Dateien Falls vollständige A2L-Dateien eingebunden werden müssen, ist hierzu der Merger des ASAP2 Tool-Set zu verwenden. Hierzu muss für jede weitere vollständige A2L-Datei der Merger mit entsprechenden Parametern aufgerufen werden.

STEP 5: Aktualisierung der Adressen und Export der finalen Datei Im letzten Schritt wird die Erstellung der finalen A2L-Datei konfiguriert. Hierzu wird der ASAP2 Updater in den Build-Prozess eingebunden, welcher die Adressen der Mess- und Kalibriergrößen aktualisiert. Gleichzeitig wird auch eine neue finale A2L erstellt, welche alle inkludierten A2L-Fragmente enthält.

STEP 6: Verwendung der A2L-Datei in CANape Nach Ausführen dieser Schritte sollte nun bei der Erstellung der Steuergerätesoftware automatisch eine aktuelle A2L-Datei generiert werden.

Diese finale A2L-Datei kann anschließend in CANape verwendet werden.



5.6.4 Arbeiten mit CANape und dem ASAP2 Editor

Exportierte Datenbasis ohne include-Befehle

verwenden

CANape und der ASAP2 Editor unterstützen eine interaktive Durchführung der oben beschriebenen Aktionen. Bei diesen Vorgehensweisen sollte jedoch darauf geachtet werden, dass die Masterdatei mit ihren include-Befehlen intakt bleibt. Es sollte

also nicht die Master-A2L-Datei direkt in CANape als Datenbasis für das Steuergerät angegeben werden, sondern immer eine exportiere Datenbasis, die keine include-

Anweisungen mehr enthält, verwendet werden.

Achtung: Der ASAP2 Editor überschreibt beim Speichern die existierende A2L-Datei und entfernt dabei die Includes. Speichern Sie daher immer nur eine Kopie.

INI-Datei Alle projektspezifischen Einstellungen von CANape werden in der CANape.ini

abgelegt. Änderungen an der Konfiguration können komfortabel über die Oberfläche in CANape vorgenommen werden.

Hinweis: Eine _CANape.ini-Datei finden Sie im Auslieferungsordner

…\Misc\McData. Sie wird mit dem AUTOSAR Calibration Handbuch mitgeliefert.

Template Die _CANape.ini-Datei wird als Template mitgeliefert, was durch den Unterstrich

gekennzeichnet ist. Die notwendigen Voreinstellungen, wie z.B. die für den Export wichtige Array-Notation in [ ], ist zur Erleichterung der Anwendung bereits vorkonfiguriert.

5.6.4.1 Schritt-für-Schritt-Anleitung

STEP 1: A2L-Fragmentgenerierung Damit A2L-Fragmente generiert werden, müssen die entsprechenden Generatoren konfiguriert werden. Dies geschieht, indem man diese in den Build-Prozess einbindet.

Es muss sichergestellt sein, dass die A2L-Fragmente bei der Erstellung an einen fest definierten Ort abgelegt werden.

STEP 2: Manuelle Erstellung von A2L-Fragmenten Informationen, welche später in der A2L-Datei vorhanden sein sollen und nicht automatisch generiert werden, müssen manuell erstellt werden.

STEP 3: INI-Datei einfügen Kopieren Sie die endgültige CANape.ini-Datei in das Verzeichnis der Master-

A2L-Datei.

STEP 4: Anpassung der Master A2L-Datei Eine Master-A2L-Datei muss erstellt werden. Hierbei sind die Pfade der include-

Befehle entsprechend anzupassen.

STEP 5: Start the ASAP2 Editor Starten Sie den ASAP2 Editor und laden Sie die Master-A2L. Der ASAP2 Editor wird verwendet, um die finale A2L-Datei zu erstellen.

STEP 6: Zusammenführen von weiteren A2L-Dateien Mithilfe des ASAP2 Editors können Inhalte aus bestehenden A2L-Datenbasen zusammengeführt werden. Wenn dies abgeschlossen ist, müssen die A2L-Dateien integriert werden. Die Import-Funktion kann hierfür genutzt werden. Entweder wählen Sie dazu Datei|Importieren oder Datei|Teildatenbasis hinzufügen aus dem Menü.



STEP 7: Aktualisierung der Adressen Für die Adressaktualisierung wird eine konfigurierte MAP-Datei benötigt. Eine MAP-Datei kann über den Eigenschaften-Dialog der Datenbasis hinzugefügt werden. Nach der Zuweisung einer MAP-Datei kann die Adresse über das Programmmenü Datei|Adressen aktualisieren auf den neuesten Stand gebracht werden.

STEP 8: Erzeugen der finalen A2L-Datei zur Verwendung in CANape Die Master-A2L-Datei sollte nicht mit dem ASAP2 Editor verändert werden. Stattdessen sollte eine neue A2L-Datei erzeugt werden. Dies kann durch das Speichern in eine neue Datenbasis über das MenüMenüeintrag Datei|Speichern unter erreicht werden.

Die finale A2L-Datei kann anschließend in CANape verwendet werden.

5.7 Schneller Zugriff auf das Steuergerät über das VX-Modul

Hohe Messbandbreite

Ein VX-Modul ist eine skalierbare Lösung mit höchster Leistungsfähigkeit für Mess- und Kalibrieraufgaben. Durch die Verwendung der VX-Messhardware, kann eine höhere Messbandbreite erreicht werden. Das System bildet die Schnittstelle zwischen dem Steuergerät und einem Mess- und Kalibriertool wie CANape. Für einen hohen Datendurchsatz bei minimaler Laufzeitbeeinflussung des Steuergerätes erfolgt der Datenzugriff über mikrocontrollerspezifische Daten-Trace- und Debug-Schnittstellen. Über XCP on Ethernet wird das VX-Modul an den PC angeschlossen. Die Anbindung der VX Messhardware an das Steuergerät erfolgt über einen POD (Plug-On Device).

Application Notes Die generelle Integration eines VX-Modules (VX1000) kann in folgenden Application Notes nachgelesen werden:

> AN-IMC-1-016 VX1000: Getting Started with Nexus JTAG and MPC5554

> AN-IMC-1-013 VX1000: Getting Started with Infineon XC2000

> AN-IMC-1-014 VX1000: Getting Started with Infineon TriCore

Hinweis: Diese Dokumente sind über das Vector Download-Center verfügbar.

5.8 Weiterführende Themen

Zu berücksichtigende Themen

Die folgenden Themen sollten für Messen und Kalibrieren berücksichtigt werden und erfordern eine zusätzliche Prüfung:

> Sicherheit

> Multicore

Hinweis: Bitte kontaktieren Sie Vector Informatik GmbH für weitere Informationen.

Handbuch AUTOSAR Calibration Abgabetest/Quickstart


6 Abgabetest/Quickstart

Ziele Dieses Kapitel beschreibt einen Abgabetest für die erstellte A2L-Datei des Lieferanten. Gleichzeitig kann es allerdings auch als CANape Quickstart für den OEM verwendet werden.

Test der A2L-Datei Um die Vollständigkeit und die Funktionalität der gelieferten A2L-Datei sicherzustellen, kann mithilfe von CANape ein einfacher Abgabetest durchgeführt werden. Sollte die A2L-Datei unvollständig oder korrupt sein, erscheint beim Einfügen der Datei ein Fehler. Im Erfolgsfall können einige Messsignale in Anzeige-Fenstern zum Test hinzugefügt und eine Messung gestartet werden. Erscheint daraufhin kein Fehler, ist die A2L-Datei funktionsfähig.

Abgabetest durchführen (Schritt für Schritt-Anleitung):

1. A2L-Datei in ein leeres Verzeichnis kopieren und Hardware anschließen.

2. CANape aus diesem Verzeichnis heraus starten (Rechtsklick auf canape32.exe|Eigenschaften|Ausführen in Verzeichnis der A2L-Datei einfügen)

3. Die A2L-Datei per Drag-and-Drop in CANape ziehen.

Im Falle einer Fehlermeldung ist die A2L-Datei unvollständig oder korrupt. Andernfalls wird das Steuergerät als online angezeigt.

4. Den Symbolexplorer öffnen und unter Geräte die Datenbasis aufklappen.

5. Einzelne Mess- und Verstellgrößen auswählen, per Drag-and-Drop auf die leere Anzeigeseite ziehen (vgl. Abbildung 6-1) und geeignete Mess- und Verstell-Fenster wählen.

Abbildung 6-1: Mess-und Verstellgrößen auf Anzeigeseite ziehen

6. Die Messung starten und die Verstellgrößen kalibrieren.

7. Die geforderten XCP-Features in den entsprechenden Einstellungen überprüfen (Näheres zu jedem Feature ist in der CANape Hilfe oder im Kapitel XCP-Features in CANape zu finden).

Falls keine Fehlermeldung auftritt, sinnvolle Messwerte in den Anzeige-Fenstern angezeigt werden, Verstellgrößen kalibrierbar und alle gewünschten XCP-Features zu finden sind, ist der Abgabetest erfolgreich.

Handbuch AUTOSAR Calibration CANape Einführung


7 CANape Einführung


7.1 Erstellung eines Projektes Seite 56

7.2 Gerätekonfiguration Seite 57

Geräte

Netzwerke

Vector Hardware

XCP-Features in CANape

7.3 Online-Messkonfiguration Seite 61

Messoptionen

Messsignale

Rekorderliste

Ereignisliste

7.4 Arbeiten mit Parametersatzdateien Seite 66

7.5 Datenstandsverwaltung Seite 67

Toolbasiert ab CANape 11.0

7.6 Offline-Auswertung Seite 69

7.7 Flashen Seite 71



7.1 Erstellung eines Projektes

Erste Schritte Die Erstellung eines CANape Projektes erfolgt entweder über den Auswahldialog

nach dem Start von CANape oder in CANape selbst über Backstage |Projekt|Neu. Nachdem im ersten Schritt ein Projektname definiert wurde, schlägt CANape im nächsten Schritt eine Projektverzeichnisstruktur mit dem Namen des Projektes als Unterverzeichnis vor.

Abbildung 7-1: Anlegen des Projektverzeich-nisses

Arbeitsverzeichnis Dieses dient für CANape als Arbeitsverzeichnis und sollte je nach Bedarf geändert werden. Dort sind üblicherweise enthalten:

> die Initialisierungsdatei CANape.ini, d.h. die globale Konfiguration des

Projektes

> mehrere Konfigurationsdateien (*.cna), d.h. lokale Konfigurationen für einzelne

Mess- und Verstellaufgaben

> ein Unterverzeichnis, in dem die Messdateien abgespeichert werden

> für jedes Steuergerät:

> ein Unterverzeichnis, in dem sich die A2L-Datei befindet

> ein Unterverzeichnis, in dem dessen Parametersatzdateien abgelegt werden

> weitere Unterverzeichnisse, je nach verwendeten Geräten (z.B. externe Messtechnikmodule)

Definition der Geräte Nach der Angabe der gewünschten Projektverzeichnisstruktur wird das neue Projekt geöffnet. Als nächster Schritt werden die Geräte definiert. Dazu wird in der Regel eine Steuergerätebeschreibungsdatei im A2L-Format oder ein Diagnose-Treiber im ODX-/ CDD-Format benötigt. Ein vollständiges Projekt besitzt am Ende mindestens eine Konfigurationsdatei (*.cna), die passende Initialisierungsdatei (*.ini) und

mindestens eine Steuergerätebeschreibungsdatei (*.a2l).

Abbildung 7-2 zeigt die empfohlene Projektverzeichnisstruktur.



Abbildung 7-2: Projektverzeichnis

Musterstand Release Für jeden Musterstand Release X.Y eines Steuergerätes werden Ordner für die projektrelevanten Dateien angelegt. Die CANape Konfigurationsdatei (*.cna) und die

canape.ini-Datei befinden sich in Ordnern im Unterverzeichnis CANape 10 SP4.

Die Hex-Datei, die Datenbasen (*.a2l, *.cdd) und die Netzwerkdateien (z.B.

*.axml) werden für jedes Musterstand Release als Unterordner eingefügt.

Außerdem werden die Mess-, Parametersatz- und die Skriptdateien ebenfalls in eigenen Ordner abgespeichert.

7.2 Gerätekonfiguration

Einstellungen In der Gerätekonfiguration können die Einstellungen für Geräte, Netzwerke und Kanäle modifiziert oder einzelne Geräte und Netzwerke hinzugefügt werden. Über

die Registerkarte Geräte|Gerätekonfiguration kann die Gerätekonfiguration geöffnet werden.

Grafische Darstellung

Mithilfe des Geräte-Fensters kann die Gerätekonfiguration auch grafisch dargestellt werden. Per Doppelklick auf die einzelnen Symbole öffnet sich ebenfalls der entsprechende Teil der Gerätekonfiguration oder der Datenbasis-Editor.



Abbildung 7-3: Geräte-Fenster in CANape

7.2.1 Geräte

Neue Geräte anlegen

In dem Unterpunkt Geräte der Gerätekonfiguration werden alle angelegten Geräte angezeigt. Hier können neue Steuergeräte entweder aus einer Datenbasis, dem MCD3-Server oder auch komplett neu erstellt werden. In letzterem Fall generiert CANape einen A2L-Rumpf, den der Benutzer über den ASAP2 Editor noch konfigurieren und vervollständigen muss. Neben den XCP- und CCP-Geräten können auch Diagnosetreiber bzw. Datenbasen verwendet werden. Ein Beispiel zur Integration einer Diagnose-Datenbasis und zur Verwendung von Panels dazu finden Sie im Installationsverzeichnis von CANape unter Examples|ODX. Durch Drag-and-Drop der Datenbasis in CANape kann direkt ein neues Gerät angelegt werden.

Busmonitoring Für das Busmonitoring können in CANape die Datenbasen des CAN (*.dbc), des

FlexRay (*.fibex) und des LIN-Bus (*.ldf) eingebunden werden. Im Kontext

AUTOSAR besteht die Möglichkeit, eine AUTOSAR Systembeschreibungsdatei (*.arxml) im Falle des CAN- oder FlexRay-Bus zu verwenden.

Konfiguration Für jedes angelegte Gerät stehen entsprechende Dialogseiten zur Konfiguration zur Verfügung. In der CANape Hilfe finden Sie weitere Informationen bezüglich der Konfigurationsmöglichkeiten. Je nach Zustand des Geräts ändert sich das Symbol von grün (online) zu gelb (offline) oder rot (inaktiv).



Abbildung 7-4: Gerätekonfiguration

7.2.2 Netzwerke

Auflistung In dem Unterpunkt Netzwerke werden alle in der aktuellen Konfiguration vorhandenen Netzwerke aufgelistet.

Konfiguration In CANape können die Netzwerke CAN, LIN, ETH, K-Line, FlexRay und MOST angelegt werden. Auf den entsprechenden Dialogseiten werden die Netzwerke konfiguriert.

7.2.3 Vector Hardware

Konfiguration der Hardware

Über die Vector Hardware wird die Konfiguration der Hardware durchgeführt. Sie kann über Geräte|Hardware-Interfaces|Vector Hardware oder in der Gerätekonfiguration im Abschnitt Kanäle|Vector geöffnet werden.

Über Application|CANape kann den jeweiligen Kanälen die passende Hardware zugeordnet werden. Dabei muss die physikalische Kanalnummer nicht der logischen Kanalnummer entsprechen. Es besteht außerdem die Möglichkeit die Anzahl der Kanäle für ein bestimmtes Bussystem zu ändern.

Abbildung 7-5: Vector Hardware Config



7.2.4 XCP-Features in CANape

Zeitstempel In der Gerätekonfiguration im Unterpunkt Protokoll|Event-Liste des Gerätes kann die Verwendung des Zeitstempels angegeben werden. Je nach Implementierung im Steuergerät besteht hier die Möglichkeit einen Zeitstempel des Slave anzufordern.

Abbildung 7-6: Zeitstempel in der Gerätekonfiguration

Resume Mode In den erweiterten Einstellungen des Unterpunktes DAQ-Liste wird angezeigt, ob der Resume Mode unterstützt wird.

Autoselektion/Soft-warestandprüfung

Die Autoselektion und die Softwarestandprüfung der A2L-Datei kann ebenfalls in der Gerätekonfiguration eingestellt werden. Diese Option ist im Unterpunkt Datenbasis zu finden

Im Falle der Verwendung der Optionen "Seitenumschaltung" oder "Checksummenberechnung" sind diese unter Speichersegmente des Gerätes zu finden (vgl. Abbildung 7-7).

Hilfe Alle XCP-Features sind nochmals ausführlicher in der CANape Hilfe beschrieben.



Abbildung 7-7: Seitenumschaltung im Geräte-Fenster

7.3 Online-Messkonfiguration

Aufruf In der Online-Messkonfiguration wird die gesamte Messung konfiguriert. Die

Messkonfiguration wird über das Symbol in der Schnellzugriffsleiste oder unter Start|Messaufbau aufgerufen.

Anzeigeseiten und -Fenster

Um die Mess- und Verstellgrößen darzustellen, stehen verschiedene Anzeigefenster zur Verfügung, welche in der CANape Hilfe ausführlich beschrieben sind. Zusätzlich können mehrere Anzeigeseiten erstellt werden, um die gesamte Konfiguration übersichtlich zu gestalten.

7.3.1 Messoptionen

Verhalten der Messung konfigurieren

In den Messoptionen der Messkonfiguration kann das Verhalten der Messung konfiguriert werden. So kann beispielsweise der Umgang mit Polling-Signalen während der Messung oder die Größe des Messpuffers angepasst werden. Außerdem kann hier eine Kommentarvorlage für neu erstellte Messdateien angegeben werden.



Abbildung 7-8: MDF-Messkommentar-vorlage

7.3.2 Messsignale

Messbare Signale Auf dieser Seite werden alle Signale der Messkonfiguration aufgelistet. Über Bearbeiten|Signal einfügen können Signale der Datenbasis ausgewählt werden. Es werden nur jene Signale gemessen, die sich in der Messsignalliste oder in den Anzeigefenstern von CANape befinden. Es besteht auch die Möglichkeit, Signale für einzelne Messungen zu deaktivieren anstatt diese zu löschen und neu hinzuzufügen. Für den Fall, dass ein Signal gemessen aber nicht aufgezeichnet werden soll, um Performance und Speicherplatz zu sparen, kann die Option Rekorder deaktiviert werden.

Messmodi Der Messmodus der Messsignale überlässt dem Benutzer einige Konfigurationsmöglichkeiten. Die meist verwendeten Messmodi sind:

> Event: Im Event-Modus schickt das Steuergerät eigenständig den aktuellen Messwert eines Signals. Die möglichen Events und DAQ-Listen sind im Steuergerät definiert und in der A2L beschrieben.

> Polling: Im Polling-Modus werden die Messwerte eines Signals auf Anfrage asynchron und entsprechend der Abtastrate vom Steuergerät zurückgegeben. Dieses Verfahren eignet sich für langsamere Messungen, wenn keine Anforderungen an eine synchrone Abtastung vorhanden sind.

> Cyclic: Bei XCP und CCP entspricht der Messmodus Cyclic dem Messmodus Event. Über seine Zykluszeit kann eine Datenreduktion erreicht werden.

> On key: Bei der Eingabe einer Tasten(-kombination) wird das Signal angefragt (Polling).

> On trigger: Beim Eintreten eines Triggerereignisses (StartTrigger, StopTrigger, LastTriggerFinished) misst CANape das gewünschte Signal (Polling).

> On event: Beim Eintreten eines bestimmten Systemereignisses (z.B. Messungsstart) wird das Signal gemessen (Polling).

Messrate In der Messkonfiguration der Messsignale wird rechts neben dem angezeigten



Messmodus die Messrate angezeigt. Sie gibt die Aufzeichnungsrate im Polling- oder Cyclic-Modus an. Die Rate wird als zeitlicher Abstand zwischen zwei Messwerten in Millisekunden angegeben.

Busauslastung Im unteren Teil der Messkonfiguration werden die Busauslastung und die Messevents für das markierte Gerät aufgeführt. Die Balken geben dabei die prozentuale Auslastung der einzelnen Eventraster und des Buses an.

Hilfe Neben den Signalen der einzelnen Datenbasen können auch weitere Messsignale wie globale Variablen in die Messkonfiguration übernommen werden. Nähere Informationen finden Sie dazu in der CANape Hilfe.

Abbildung 7-9: Messkonfiguration: Messsignalliste

Signale einfügen Mithilfe des Symbol Explorers können einzelne Messsignale des Gerätes direkt über Drag-and-Drop in ein Anzeigefenster eingefügt werden. Diese werden automatisch zur Messsignalliste hinzugefügt.

Kürzungsregel Um die Übersichtlichkeit im Symbol Explorer dafür bei langen Messsignalnamen zu

verbessern, kann unter Backstage |Optionen, Abschnitt Anzeige|Objektnamen, eine Kürzungsregel angegeben werden.



Abbildung 7-10: Einstellung einer Namenskürzungsregel

Diese deutet den Anfang des Signalnamens nur an und beschränkt sich in der Anzeige auf den letzten Teil nach dem angegebenen Trennzeichen.

Abbildung 7-11: Beispiel zur Verwendung einer Namenskürzungsregel

7.3.3 Rekorderliste

Definitionen/Einstel-lungen

Die Rekorderliste in der Messkonfiguration gibt einen Überblick über die definierten Rekorder. Es besteht die Möglichkeit einzelne Rekorder zu deaktivieren, um verschiedene Messaufgaben zu realisieren. Die Einstellung des Dateinamen der MDF-Datei kann individuell für jeden Rekorder vorgenommen werden. Dabei können verschiedene Makros verwendet werden, um beispielsweise die Uhrzeit im Dateinamen festzuhalten. Unter dem Bereich Optionen können verschiedene Einstellungen für jeden Rekorder vorgenommen werden. In der CANape Hilfe werden diese Einstellungen detailliert erklärt.



Abbildung 7-12: Messkonfiguration: Rekorderliste

Ereignisse zur Aufzeichnung

Neben der einfachsten Messung, die alle Signale über die gesamte Messdauer aufnimmt, besteht die Möglichkeit, die Aufzeichnung einzelner Signale durch bestimmte Ereignisse auszulösen. Diese werden im Bereich Trigger näher definiert.

Abbildung 7-13: Trigger-Einstellungen

Startereignisse Als Ereignistrigger können verschiedene Startereignisse ausgewählt werden.

Folgende Kategorien stehen über das Auswahlmenü der Schaltfläche [Neu] zur Verfügung:

> Signalereignisse: Werte aus der laufenden Messung)

> Signalereignisse (algebraische Bedingung): Werte aus algebraischer Berechnung

> Tastaturereignisse: Benutzereingaben

Über die Schaltfläche [Ereignisse] können außerdem verschiedene Systemereignisse (Meldungen vom Computer oder den Steuergeräten) als



Startereignis ausgewählt werden.

Stoppereignis Die verschiedenen Ereignisse stehen ebenfalls als Stoppereignis wieder zur Verfügung. Es kann allerdings auch eine Zeitbeschränkung als Stoppereignis gewählt werden.

Signale den Rekordern zuweisen

Unter Aufgezeichnete Signale werden die Messsignale angezeigt, die von diesem Rekorder aufgezeichnet werden. Dabei können Signale einzelnen Rekorder zugewiesen werden, sodass diese nur beim Eintreten der Triggerbedingung auch aufgezeichnet werden.

7.3.4 Ereignisliste

Übergreifende Ereignisliste

Im Abschnitt Ereignisliste der Messkonfiguration werden alle Ereignisse mit ihren Eigenschaften aufgelistet. Dabei ist ersichtlich, ob es sich um ein Ereignis des Steuergerätes oder ein generelles Systemereignis handelt. An dieser Stelle werden auch die definierten Trigger-Ereignisse angezeigt.

Definition neuer Ereignisse

Die Definition neuer Ereignisse erfolgt über das Kontextmenü. Diese stehen anschließend als Messmodus in der Messsignalliste zur Verfügung, sodass ein Signal beispielsweise erst nach dem Drücken einer bestimmten Taste gemessen wird.

Abbildung 7-14: Messkonfiguration: Ereignisliste

7.4 Arbeiten mit Parametersatzdateien

Verwendungszwecke fürs Speichern von Parametersatzda-teien

In CANape besteht die Möglichkeit Verstellgrößen(Parameter) online zu verstellen und diese als Parametersatzdatei zu speichern. Dabei werden diese Dateien hauptsächlich für 2 Verwendungszwecke benutzt:

> Zum Speichern des aktuellen Stands und zur Dokumentation bzw. zum Austausch der Parameterwerte

Beim Abspeichern der Verstellgrößen kann aus verschiedenen Möglichkeiten ausgewählt werden. Zum einen können speziell die Parameter eines einzelnen



Verstell-Fensters in dessen Kontextmenü unter Speichern gesichert werden, zum anderen können auch di e Parameter aller Verstell-Fenster abgespeichert werden. Dies kann über Verstellen|Alle Verstell-Fenster speichern durchgeführt werden. Außerdem besteht auch die Möglichkeit über einen Filter bestimmte Parameter auszuwählen (Verstellen|Parametersatz speichern unter).

> Um das System in einen definierten Zustand zu bringen

Auch zum Laden einer Parametersatzdatei stehen mehrere Funktionen zur Verfügung. Verstellgrößen in einem bestimmten Verstell-Fenster können auch hier über dessen Kontextmenü unter Laden geöffnet werden. Das Auswählen bestimmter Verstellgrößen kann über Verstellen|Parametersatz laden von erreicht werden.

7.5 Datenstandsverwaltung

Definition von Datenständen

Ein Datenstand ist ein Satz verschiedener Parameter zu einem bestimmten Zeitpunkt der Bearbeitungshistorie. Normalerweise enthält er alle Parameter, die zu einem Steuergerät gehören und wird über folgende Dateien repräsentiert:

> Datenbasis-Datei (A2L-Datei)

> Spiegelspeicher-Inhalt (HEX-Datei)

> Parametersatzdatei (nur für Datenstände aus dem eCDM-System)

Der Datenstand ist das zentrale Objekt für die Versionierung und Konfiguration von Parametern.

7.5.1 Toolbasiert ab CANape 11.0

Datenstandsverwal-tung

In CANape 11.0 wurde eine komfortable Möglichkeit zur Datenstandsverwaltung eingeführt. Über die Gerätekonfiguration kann die [Datenstandsverwaltung] aufgerufen werden. Hier können verschiedene Datenstände eines Steuergerätes

hinzugefügt werden. Im Reiter Datenstände können über das Symbol neue Datenstände (A2L+HEX, HEX oder unbedatet) hinzugefügt werden. Weitere Einstellungen stehen im Kontextmenü zur Verfügung. Der Reiter Zeitstempel zeigt die Snapshots der Verstellhistorie und gibt deren Zeitstempel an.



Abbildung 7-15: Datenstandsverwaltung in CANape 11.0

Arbeiten mit mehreren Datenständen

Im Symbol Explorer werden die Datenstände anschließend angezeigt und können aktiviert werden. So ist es möglich, innerhalb eines Projektes komfortabel mit mehreren Datenständen zu arbeiten.



Abbildung 7-16: Datenstandsverwaltung im Symbol Explorer

Beispielkonfiguration In dem Ordner Examples des CANape Installationsverzeichnis liegt eine DemoBeispielkonfiguration mit dem Namen Datasets_Thesaurus, das die

Verwendung der Datenstandsverwaltung anhand eines Beispiels veranschaulicht.

7.6 Offline-Auswertung

Einlesen von Messdaten

Um die Messdaten offline auszuwerten, können diese über Analyse|Werte aus Messdatei anzeigen eingelesen werden.

Messdatei-Manager Der Messdatei-Manager (auch über den Menüpunkt Analyse erreichbar) zeigt alle geladenen MDF-Dateien sowie die virtuellen MDF-Kanäle. In der Symbolleiste des Messdatei-Managers stehen einige Einstellungsmöglichkeiten zur Verfügung, die in der CANape Hilfe näher beschrieben werden.

Data Mining Unter Analyse|Data Mining steht ein automatisches Verfahren zur Offline-Auswertung geladener MDF-Dateien zur Verfügung. Es besteht die Möglichkeit z.B. Zeitpunkte, in denen die Drehzahl größer als 3000 rpm ist, zu finden. In einem Suchlauf können dabei mehrere Messdateien mit möglichst gleichnamigen Messsignalen ausgewertet werden. Diese werden im Abschnitt Konfiguration|Dateifilterliste angegeben. Dabei besteht auch die Möglichkeit Wildcards (*.mdf) zu verwenden.



Berechnungsmetho-den

Im Abschnitt Konfiguration|Methoden werden die Berechnungsmethoden konfiguriert. Dabei stehen folgende zur Auswahl:

> Funktion (auf der Basis von benutzerdefinierten Funktionen, die im Funktionseditor erstellt werden oder aus der globalen Funktionsbibliothek)

> MATLAB/Simulink-Modell (auf der Basis von MATLAB/Simulink-Modellen, die als DLL verfügbar sind)

> arithmetische Bedingung (auf der Basis von benutzerdefinierten Kriterien)

> Skript (im Funktionseditor definiert)

Definition von algebraischen Bedingungen

Die Abbildung 7-17 zeigt die Definition einer algebraischen Bedingung. Unter Erweitert kann der auszuwertende Zeitbereich eingestellt werden.

Abbildung 7-17: Data Mining: Erstellen einer algebraischen Bedingung

Analysedatei benennen

Im Abschnitt Optionen kann der gewünschte Dateiname der Analysedatei eingegeben werden. Der Name kann verschiedene Makros enthalten, die über die entsprechende Schaltfläche eingefügt werden können.

Weitere Einstellungen

Des Weiteren besteht die Möglichkeit, die Anzahl der Treffer pro Datei einzuschränken. Die Angabe eines Erstelldatums der zu durchsuchenden Datei ist sinnvoll, wenn nur die Messdaten ab einem bestimmten Datum ausgewertet werden sollen.

Ausgabe im CSV-Format

Zur weiteren Analyse können die Ergebnisse auch im CSV-Format ausgegeben werden. Im Auswahlmenü dieses Abschnitts sollte das gewünschte Trennzeichen der Messdaten angegeben werden.



Skripte ausführen Zusätzlich können Skripte angegeben werden, die jeweils vor der Ausführung der Analyse, vor der Analyse jeder Datei, nach der Analyse jeder Datei oder nach der Beendigung der gesamten Analyse ausgeführt werden.

Beispiel zu Data Mining

Ein ausführliches Beispiel zu Data Mining befindet sich im Installationsverzeichnis von CANape unter Examples|Data Mining.

7.7 Flashen

Flashtools Aus CANape heraus können andere Flashtools, wie z.B. vFlash, aufgerufen werden.

Hilfe Weitere Informationen zum Thema Flashen mit CANape finden Sie in der CANape Hilfe.

Handbuch AUTOSAR Calibration Adressen


8 Adressen

Adressen auf Vector Homepage

Die Kontaktadressen der Vector Informatik GmbH und ihrer Töchter weltweit finden Sie unter:

http://www.vector.com/vi_adressen_de.html

Handbuch AUTOSAR Calibration Abkürzungen


9 Abkürzungen

Abkürzung Beschreibung

ASAM Association for Standardization of Automation and Measuring Systems

AUTOSAR AUTomotive Open System ARchitecture

BSW Basissoftware

CSA Common Software Architecture

CTO Command Transfer Object

DAQ Data Acquisition (Datenerfassung)

DTO Command Transfer Object (Datentransferobjekt)

E/E-Architektur Electrical/electronic architecture (Elektrisch/elektronische Architektur)

EPK EPROM-Kennung

EPROM Erasable Programmable Read Only Memory

MCD-System Measurement Calibration, and Diagnostics System (Mess-, Kalibrier- und Diagnosesystem)

ODT Object Description Table (Objektbeschreibungsstabelle)

RTE Runtime Environment (Laufzeitumgebung)

SW-C Software Component (Softwarekomponente)

VFB Virtual Function Bus (virtuelles Funktionsbussystem)

Sie möchten weitere Informationen!

> Neues

> Produkte

> Demosoftware

> Support

> Schulungen

> Adressen

www.vector.com

http://www.vector-worldwide.com/

Documents

Handbuch AUTOSAR Calibration Inhaltsverzeichnis · Handbuch AUTOSAR Calibration Inhaltsverzeichnis © Vector Informatik GmbH Version 2.0 - II - 5.4 Konfiguration des XCP-Moduls 42