Pdf-ODX

Transcription

Pdf-ODX

Inhalt
2
Copyright © 4/7/2011 emotive GmbH - All rights reserved
Diagnosesysteme im Automobil
Einleitung Datenmodell DIAG-LAYER-CONTAINER COMPARAM-SPEC VEHICLE-INFO-SPEC FLASH ECU-CONFIG MULTIPLE-ECU-JOB-SPEC FUNCTION-DICTIONARY
MVCI-Server (ASAM 3D-Server, ODX-Kernel)
Test- und Diagnoseanwendungen
Die Kühlwassertemperatur = 64 oC
Wie wird die PDU
in die Temperatur n
umgerechnet?
Wie groß ist die Kühlwassertemperatur?
API
Übergabe
der PDU
Modular VCI
Runtime System
(MVCI, ISO 22900)
Entpacken der PDU
aus der Antwortbotschaft
Vehicle Communication Interface – VCI
Empfangen einer Botschaft auf den Bus
(Response)
3.
Bussysteme
ISO 11898 etc.
ECU
ECU
ECU
Anfrage über
ShortName
ODX, MCD 2
(ISO 22901-1)
Rückgabe
Temperatur
D-PDU API, MCD 1 (ISO 22900-2)
Wie lautet die PDU*
zum Auslesen der
Temperatur?
D-Server API, MCD 3 (ISO 22900-3)
ODX, MCD 2
(ISO 22901-1)
Steuergeräte
Diagnosedaten
Beschreibung
1.
Rückgabe
der PDU
Steuergeräte
Diagnosedaten
Beschreibung
Buskonfiguration &
Verpacken der PDU
in eine Botschaft
Versenden einer Botschaft auf den Bus
ISO 14229, ISO 15765 etc.
(Request)
und Protokolle
2.
*PDU
= Protocoll Data Unit
4.
3
Diagnoseprozesskette – Aktueller Zustand
Entwicklung
Produktion
Diagnosesystemlieferant
Service
Die heutige Diagnoseprozesskette ist gekennzeichnet durch einen
heterogenen Austausch von diagnoserelevanten Informationen
Systemlieferant
4
Diagnoseprozesskette – Datenfluss
Zentrale Datenbereitstellung und -weiterleitung ist Grundlage für die
zukünftige Gestaltung der Diagnoseprozeßkette
Quelle: ASAM e.V., www.ASAM.net
5
Diagnoseprozesskette – Zukunft: ODX
Entwicklung
Produktion
Diagnosesystemlieferant
Lieferanten
Diagnose
Datenbank
Hersteller
Diagnose
Datenbank
Hersteller
Diagnose
Datenbank
Internet
ODX
PDX
ODX
PDX
ODX
PDX
Service
ODX
PDX
Austausch von standardisierten Diagnosedaten über alle Phasen des
Fahrzeuglebenszyklus – Grundprinzip: Single Source
Systemlieferant
6
Was ist das?
7
 ODX = Open Diagnostic Data Exchange
 Austausch- und Beschreibungsformat für alle Diagnose relevanten Daten
eines ganzen Fahrzeugs:
Protokollspezifikation für die Kommunikation zwischen Tester & Steuergerät
Kommunikationsparameter für ISO/OSI-Schichten und Steuergerätesoftware
Steuergeräte-Programmierdaten (Flash)
Beschreibung der Fahrzeugschnittstelle (Steckverbinder und Pinbelegung)
Funktionale Beschreibung der Diagnosefähigkeiten eines Netzwerks von
Steuergeräten
• Steuergeräte-Konfiguration (Variantenkodierung)
 Ein MVCI Server kann über ODX mit den Steuergeräten kommunizieren
und die Diagnosedaten interpretieren
 Für eine technisch lesbare Darstellung der Diagnosedaten auf dem Tester
ist keine Programmierung erforderlich – generischer Tester
 ASAM AE MCD 2D oder ISO 22901-1
•
•
•
•
•
Diagnoseprozesskette: Anwendungsbeispiel
8
Diagnoseprozesskette: Anwendungsbeispiel 2
9
Diagnoseprozesskette: Anwendungsbeispiel 3
10
Vorteile und Nutzen I
11
 Zulieferer
• Automatische Konfiguration der Steuergerätediagnosedaten und des
Kommunikationsprotokolls
• Automatische Erzeugung der Dokumentation (Steuergerätediagnose-daten =
Dokumentation)
• Automatische Konfiguration des Entwicklungstesters zur Überprüfung der
implementierten Diagnosedienste
• Maschinenlesbares Format (XML) für den Import in die eigene
Diagnosedatenbank
 Fahrzeughersteller – Entwicklung
• Aufwandsreduktion bei der Diagnosedatenerstellung
• Single-Source Prinzip: Alle Entwicklungstester unterstützen das selbe Format.
• Nur ein Format für den Im- und Export mit der zentralen Diagnosedatenbank
• Kode-Generierung zur Konfiguration des Diagnose Kernels
Vorteile und Nutzen II
12
 Fahrzeughersteller – Produktion
• Aufwandsreduktion bei der Diagnosedatenverifikation – Daten müssen nur
einmal verifiziert werden
• Wiederverwendung von verifizierten Diagnosedaten
• Weniger Fehler wegen geringerer Anzahl von Prozessschritten
• End-Of-Line Tester verwenden die selben Diagnosedaten und den selben
Diagnosetester wie in der Entwicklung
 Fahrzeughersteller – After Sales
• Geringerer Aufwand bei der Verteilung der Diagnosedaten
• „Abrufen“ von Diagnosedaten via Intranet/Internet vs. „Bereitstellen“ von
Softwareupdates auf CD-Rom
• Ein Format für die verschiedenen Diagnosesysteme
• Einfachere Wiederverwendbarkeit von verifizierten Diagnosedaten
Vorteile und Nutzen III
13
 Toolhersteller
• Geringerer Aufwand bei der Erstellung von Diagnoseapplikationen durch die
Verwendung eines generischen datengetriebenen Ansatzes
• Focus: Diagnose-Killer-Applikationen vs. Bits & Bytes
• Einfachere Wiederverwendbarkeit von verifizierten Diagnosedaten
 Werkstatt
• Wiederverwendung von verifizierten Diagnosedaten
• Tester Konfiguration durch Daten-Download vs. Software Modifikation
• Download nach Bedarf vs. Kauf eines Softwareupdates
• Standardisiertes Format für die Dokumentation der relevanten Diagnosedaten
(z.B. DTCs, PIDs, etc.)
• Ermöglicht herstellerunabhängige Scan-Tools und Tools für Service und
Instanthaltung
• Erfüllt die Forderung freier Werkstätten auf Zugang zu erweiterten
Diagnosedaten
 Gesetzgeber
Vorteile und Nutzen – Zusammenfassung
14
 Wiederverwendbarkeit (Single-Source)
 Erhöhung der Sicherheit, durch weniger Prozessschritte
 Einfache und schnelle Verifizierbarkeit
 Verbesserung der Wartbarkeit
 XML Format: Maschinen- und Menschenlesbarkeit
 Automatisierte Tools zur Konfiguration, Dokumentenerstellung, KodeErzeugung etc.
 Generische Erstellung von Diagnoseapplikationen
…
 Herstellerunabhängigkeit
Risiken
15
 Investitionsbedarf vs. Use-Case
 Sinkende Flexibilität
 „Never change a running system“
 Gibt es ein Geschäftsmodell?
PACKAGED ODX (PDX)
16
 Eine ODX-Bedatung besteht niemals aus nur einer Datei
 PDX ist ein Archivformat in welchem alle, zu einem Projekt gehörenden,
Dateien (XML und auch Binärformat) zusammengefasst werden
 PDX ist ein ZIP-Archiv erweitert um eine sg. „PDX package catalogue“
Datei mit Namen index.xml, welche das Inhaltsverzeichnis des Projekts
enthält
 Anwendungen:
• Austausch von Revision-Historys und Configurations Management
Informationen
• Verschiedene Versionen einer Datei können in einem PDX vorhanden sein
• Reduzierung der Dateigröße
• Austausch kompletter Bedatungen zwischen OEM und Zulieferer
Dateiendungen
Endung
Bedeutung
odx-c, odx-cs
COMPARAM-SPEC, COMPARAM-SUBSET
odx-d
DIAG-LAYER-CONTAINER
odx-e
ECU-CONFIG
odx-f
FLASH
odx-fd
FUNCTION-DICTIONARY
odx-m
MULTIPLE-ECU-JOB-SPEC
odx-v
VEHICLE-INFORMATION-SPEC
odx
Alternative zu allen obigen Bezeichnungen, jedoch nicht so
restriktiv
17
Inhalt
18
Hauptkomponenten
19
ODX = Open Diagnostic data eXchange
ODX-CATEGORY
COMPANY-DATAS
COMPARAM-SPEC
DIAG-LAYERCONTAINER
FLASH
ECU-CONFIG*
ECU-SHARED-DATAS
COMPARAMSUBSET*
MULTIPLE-ECUJOB-SPEC
FUNCTIONDICTIONARY*
PROTOCOLS
FUNCTIONAL-GROUPS
BASE-VARIANTS
SINGLE-ECU-JOB
DIAG-SERVICE
DATA-OBJECT-PROPS
REQUEST
POS-RESPONSES
NEG-RESPONSES
ECU-VARIANTS
…
Vereinfachte Darstellung
VEHICLE-INFOSPEC
ADMIN-DATA
Grundstruktur
20
 DIAG-LAYER-CONTAINER
Beschreibung der Diagnosedienste inkl. aller erforderlichen Daten für
ein oder mehrere Steuergeräte und deren Varianten
 COMPARAM-SPEC
Beschreibung von vordefinierten Sets von
Kommunikationsparametern für das Diagnoseprotokoll
 VEHICLE-INFO-SPEC
Beschreibung aller Infos zur Fahrzeugidentifikation und zum
Fahrzeugzugang, wie Netzwerktopologie, SG-Gruppen,
Steckerbelegungen etc.
 FLASH
Beschreibung aller zum Flashen der Steuergeräte notwendigen Daten
und Parameter
 ECU-CONFIG*
 MULTIPLE-ECU-JOB-SPEC
Beschreibung von Jobs, welche sich auf mehrere Steuergeräte
beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYERCONTAINERs
 COMPARAM-SUBSET*
Beschreibung von vordefinierten Kommunikationsparametern für
Physical Layer, Transport Layer oder Diagnoseprotokoll
 FUNCTION-DICTIONARY*
Beschreibung von Informationen zur funktionsorientierten Diagnose
Beschreibung der Steuergerätekonfiguration - Variantenkodierung
Minimalstruktur einer ODX-Bedatung
Beschreibt die Fahrzeugtopologie
Beschreibt das Bussystem
VEHICLE-INFO-SPEC
•
•
•
•
21
COMPARAM-SPEC
VEHICLE-INFORMATION
PHYSICAL-LAYER
LOGICAL-LINKS
BASE-VARIANT-REF
• Bus-Parameter
z.B. Baudrate, Timings, CANIDs etc.
Beschreibt die Steuergeräte
verweist auf
verweist auf
PROTOCOL
BASE-VARIANT
• DIAG-SERVICES
• SINGLE-ECU-JOBS
• COMPARAM-REFS
• COMPARAM-SPEC-REF
Gemeinsame Elemente I
22
 ADMIN-DATA
Informationen zur Versionskontrolle und dem
Konfigurationsmanagement (keine Guidelines)
 COMPANY-DATA
Firmeninformationen (z.B.: Funktionen, Mitglieder des
Teams und firmenspezifische Daten)
 SHORT-NAME
Identifiziert ein ODX-Objekt (max. 128 Zeichen
[a-zA-Z0-9_]+)
 LONG-NAME
Name des ODX-Objekts für die Anzeige innerhalb des GUI
(max. 255 Zeichen)
 DESC
 ELEMENT-ID
Allgemeiner Typ für SHORT-, LONG-NAME und DESC
 ID
Über die gesamte Datenbank eindeutiger Identifier für das
ODX-Referenzkonzept „odx-link“
 OID
Über den gesamten Life-Cycle eindeutiger Object-ID,
ähnlich dem Universally Unique Identifiers (UUID) nach
ISO/IEC 11578:1996
Enthält detaillierte Informationen über das ODX-Objekt
(keine Längenbegrenzung, mit HTML Format-Tags)
Gemeinsame Elemente II
23
 SDGS – Special Data Groups
• Standard-Erweiterungsmechanismus
• Alle nicht standardkonformen Daten können strukturiert
abgelegt werden
• Nur die Struktur und nicht der Inhalt sind definiert
• Baumstruktur ohne Restriktionen (beliebige Tiefe,
Rekursionen etc.)
• Sehr komplexe Datenstrukturen abbildbar
• Ein Diagnosetool kann SDGS ignorieren
• Beispiel: COMPANYDOC-INFO
• Zuordnung der Verfügbarkeit von Diagnose-Elementen zu
bestimmten Benutzergruppen
• 5 vordefinierte boolesche Werte
• Kann um benutzerdefinierte Attribute erweitert werden
(ADDITIONAL-AUDIENCES)
 AUDIENCE & ADDITIONAL-AUDIENCES
Referenzen und Vererbung
24
Vererbung ist das Kernkonzept von ODX:





Wiederverwendung von Diagnosedaten für mehrere Steuergeräte oder Steuergerätevariante (Single-Source Prinzip)
Reduzierung der Datenmenge indem nur noch die Änderungen beschrieben werden
Erhöhung der Datensicherheit und -integrität
Keine fehleranfälligen Kopien von identischen Datensätzen zwischen Steuergeräteprojekten
Aber: unter Umständen komplexe Vernetzung
Referenzen:
 ODX-LINK oder ID-REF
•
•
SHORT-NAME-REF oder SN-REF
•
•
Eine SHORT-NAME-REF ist nur im eigenen DIAG-LAYER bzw. Namensraum eindeutig. Bei gleichnamigen Elementen beispielsweise in
verschiedenen Containern hat das lokale Element Gültigkeit
Tipp: Benutzen Sie SN-REF, um gezielt Elemente zu überschreiben. So vermeiden Sie redundante Daten!
Vererbung (nur bei DIAG-LAYER)
 Gilt nur für folgende Objekte: COMPANY-DATA, FUNCT-CLASS, DIAG-COMM, RESPONSE, REQUEST, TABLE, DOP-BASE,
UNIT, PHYSICAL-DIMENSION, UNIT-GROUP, DIAG-VARIABLE, VARIABLE-GROUP
 Vererbung
•
•

Enterbung
•

Erben eines Parent-Objektes, das überschrieben werden kann
SN-REF können verwendet werden
Parent-Objekt in diesem Layer nicht mehr sichtbar
Import
•
•
Nur ECU-SHARED-DATAS können importiert werden
Das importierte Objekt kann nicht weitervererbt und nicht überschrieben werden (Bibliothek)

Referenz ist ein Objekt
Referenziert eine ID (ID sollte im gesamten Projekt eindeutig sein, GUID empfohlen)
OTX-LINK oder ID-REF
Objekte O1 und O2
LayerA
O1
Link-Auflösung
Sichtbarkeit
zur Laufzeit
Existenz
zur Laufzeit
O2
O1
O2
O1
O2
O1
O2
O1
O2‘
O1
O2
O1 O2‘
O1
O2 O2‘
O1
O2‘‘
O1
O2
O1 O2‘‘
O1
O2 O2‘‘
ODX-LINK
25
LayerB
erbt von
LayerC
‘ Hochkomma = Objekt wurde im Layer überschrieben
erbt von
SHORT-NAME-REF (SN-REF)
Objekte O1 und O2
LayerA
Link-Auflösung
Sichtbarkeit
zur Laufzeit
O2
26
Existenz
zur Laufzeit
O1
SN-REF
O2
O1
O2
O1
O1
O2
O1
SN-REF
O2‘
O1
O2‘
O1 O2‘
O1 O2‘
O1
SN-REF
O2‘‘
O1
O2‘‘
O1 O2‘‘
O1 O2‘‘
LayerB
erbt von
LayerC
erbt von
Enterben
Objekte O1, O2 und O3
LayerA
Link-Auflösung
O3
Sichtbarkeit
zur Laufzeit
O3
27
Existenz
zur Laufzeit
O3
erbt von
ODX-LINK
O1
O3
O1
O2
O3
O1
O2
O1
O3
O3
O1 O2‘
O1
O2
NOT-INHERITED O3
erbt von
C
O2
O1
O2‘
O1
O2
O3
O2
O2‘ O3
B
Testfragen – Einleitung
1.
28
Mit welcher Abkürzung wird das Format bezeichnet, mit dem alle ODX-Dateien eines Projektes in einem
Archiv zusammengefasst werden?
a) PDX
b) ODX-Container
c) ZIP
2.
Welcher der folgenden ODX-Container ist optional und muss nicht in jedem Projekt vorhanden sein?
a)
b) VEHICLE-INFO-SPEC
c) FLASH
d) COMPARAM-SPEC
3.
Kann man Diagnoseabläufe, die das Zusammenwirken mehrerer Steuergeräte gleichzeitig erfordern,
innerhalb eines DIAG-LAYER-CONTAINERs beschreiben?
a)
Ja
b) Nein
Wie identifiziert ein ODX-Link das Ziel der Referenz?
a) Durch den SHORT-NAME des Zielelements
b) Durch die ID des Zielelements
5.
Auf was verweist die Referenz mit einem SHORT-NAME?
a) Auf ein beliebiges Element, da der SHORT-NAME im gesamten ODX-Datensatz eindeutig sein muss.
b) Auf ein durch den SHORT-NAME bezeichnetes Element, das im selben Layer definiert bzw. sichtbar sein muss.
c) Verweise können nur IDs verwenden
4.
Inhalt
29
Grundstruktur – DIAG-LAYER-CONTAINER
30
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
31
 Wichtigster Teil der Bedatung für jedes im Fahrzeug verbaute Steuergerät
 Enthält sämtliche Diagnosedienste und -abläufe (Jobs) eines Steuergeräts sowie
alle zugehörigen Daten
 Nur in diesem Container können Objekte vererbt werden
• ECU-SHARED-DATA: Bibliothek, für alle immer wiederkehrenden oder OEMspezifischen Daten, z.B.: Einheiten, PIDs etc.
• PROTOCOL: Alle protokollrelevanten Daten und Dienste und dazugehörige
Kommunikationsparameter, z.B.: UDS Diagnoseservice „StartRoutineByLocalID“
• FUNCTIONAL-GROUP: Gruppierungsmöglichkeit von Daten einer Funktionsgruppe,
z.B.: Karosserieelektronik
• BASE-VARIANT: Parameter der Dienste, die bei jedem Steuergerät andere Werte
haben, z.B.: Local-IDs für „Heckleuchte an“ und „Heckleuchte aus“
• ECU-VARIANT: Darstellung von Unterschieden zwischen fast identischen
Steuergeräten, z.B.: BCM vorn und BCM hinten (BCM = Body Control Module)
 Schichtenmodell (Diagnostic Layer):
DIAG-LAYER-CONTAINER – Vererbung
Beispiel: Türsteuergeräte
Hoher Level
0…∞
erben
o. import
Allgemeiner
PROTOCOL*
z.B.: ISO 15765, ISO 14229, ReadDataByLocalID
0…∞
erbt von
0…∞
erben
o. import
FUNCTIONAL-GROUP
z.B.: DOORS
0…∞
erbt von
0…∞
erben
o. import
erbt von
BASE-VARIANT*
z.B.: DCM (Door Control Module)
1
erbt von
0…∞
erben
o. import
Bibliothek
ECU-VARIANT
z.B.: DCM-Front, DCM-Heck
Diagnoseschichten – DIAG-LAYER
Spezieller
* Layer
muss existieren
ECU-SHARED-DATA
z.B.: PID-LIBRARY, UNITS-OEM
0…∞
Niedriger Level
32
DATA-OBJECT-PROPERTY (DOP)
33
 Kernelement im DIAG-LAYER-CONTAINER zur
Interpretation der Parameter eines Diagnoseservices in
menschenlesbarer Form
- Complex DOP
 COMPU-METHOD
Umrechnungsmethode zw.
Kodierten Wert und der
physikalischen Größe
 DIAG-CODED-TYPE
Datentyp des kodierten Wertes
eines Parameters
 PHYSICAL-TYPE
Datentyp des physikalischen
Wertes eines Parameters
 INTERNAL-CONSTR
PDU
PARAM
Wert
IDREF / SNREF
1
DOP
PHYSICAL-TYPE
COMPU-METHOD
DIAG-CODED-TYPE
IDREF
1
UNIT
IDREF
1
PHYSICAL
DIMENSION
Gültigkeitsintervalle für den Parameter im kodierten Format
 UNIT-REF
Referenz zur physikalischen Einheit des Parameters
 PHYS-CONSTR
Gültigkeitsintervalle für den physikalischen Parameter
 2 Typen: - Simple DOP
DOP – COMPU-METHOD
0x21
0x31
Kodierter Wert wird einem Text aus
einer Tabelle zugeordnet
kodierter Wert
RAT-FUNC
Kodierter Wert wird über eine
gebrochen rationale Funktion in den
physikalischen Wert umgerechnet
kodierter Wert
physikalisch
Kodierter Wert ist gleich dem
physikalischem Wert
physikalisch
y=
IDENTICAL
kodierter Wert
physikalisch
LINEAR
Kodierter Wert wird über eine
lineare Funktion (y = mx + n) in den
physikalisch
Kodierter Wert wird abschnittsweise
über eine lineare Funktionen in den
kodierter Wert
VD0 + VD1x + VD2x2 + … + VDnxn
Kodierter Wert wird abschnittsweise
über gebrochen rationale Funktionen
in den phys. Wert umgerechnet
TAB-INTERP
Kodierter Wert wird über definierte
LOWER-LIMITS interpolierend in den
kodierter Wert
SCALE-LINEAR
physikalisch
kodierter Wert
VN0 + VN1x + VN2x2 + … + VNmxm
SCALE-RAT-FUNC
physikalisch
kodierter Wert
34
COMPUCODE
Java
Code
kodierter Wert
TEXTTABLE
physikalisch
physikalisch
Kodierter Wert wird über ein JavaProgramm mit dem Interface
I_CompuCode() in den physikalischen
Wert umgerechnet
DOP – DIAG-CODED-TYPES
LEADING-LENGTH-INFO-TYPE:
010
BIT-LENGTH = 16
kodierter Wert
BIT-LENGTH
= 3 Bit
LENGTH_INFO
= 2 Byte
Die Länge des Parameters steht in BIT-LENGTH
(BIT-MASK)
BIT-LENGTH enthält die Anzahl der folgenden
Bytes, welche die Längeninformation ebenfalls in
Bytes enthalten. Die Bits stehen am Anfang des
Parameters und gehören nicht zum kodierten Wert
MIN-MAX-LENGTH-TYPE:
PARAM-LENGTH-INFO-TYPE:
MIN-LENGTH = 8 (ab da wird die Endemarke gesucht)
TERMINATION
0xFF oder 0x00
MAX-LENGTH = 24
Das Ende des Parameters definiert entweder die
Endemarke, die maximale Länge oder das Ende der
PDU (END-OF-PDU)
LENGTH-KEY-REF
PARAM
[LENGTH-KEY]
kodierter Wert
DOP
16 Bit
Die Länge des Parameters ist
in einem vorangegangenen Parameter des Typs
LENGTH-KEY enthalten
STANDARD-LENGTH-TYPE:
35
Diagnostic Communication Primitives
(DIAG-COMMS)
36
 Die Diagnosedienste DIAG-SERVICE beschreiben die Diagnosefunktionalitäten des DIAGLAYER in welchem sich der Dienst befindet
DIAG-SERVICE
0…1
REQUEST (23 12 05 24 02)
1…∞
PARAM
PARAM
0…1
DOP
0…1
UNIT
0…∞
POS-RESPONSE (63
(6304
04E5)
E5)
POS-RESPONSE
1…∞
PARAM
PARAM
0…1
DOP
0…1
UNIT
0…∞
NEG-RESPONSE(7F
(7F23
2331)
31)
NEG-RESPONSE
1…∞
PARAM
PARAM
0…1
DOP
0…1
UNIT
ID-REF
ID-REF/SN-REF
SINGLE-ECU-JOB
1…∞
Java Code
0…∞
INPUT-PARAMS
INPUT-PARAMS
0…1
DOP
0…1
UNIT
0…∞
OUTPUT-PARAMS
OUTPUT-PARAMS
0…1
DOP
0…1
UNIT
0…∞
NEG-OUTPUT-PARAMS
NEG-OUTPUT-PARAMS
0…1
DOP
0…1
UNIT
ID-REF
ID-REF/SN-REF
 JOBs sind Makros für komplexere Aufgaben, die über einen einfachen DIAG-SERVICE
hinausgehen. Sie werden im Laufzeitsystem wie Diagnosedienste behandelt.
Diagnoseservices (DIAG-SERVICE)
37
Typen von Parametern
Typ
Beschreibung
VALUE
Datenwert, verweist auf ein DOP
CODED-CONST
Konstante (z.B. SID)
DYNAMIC
Parametertyp wird erst zur Laufzeit festgelegt (nur für Response)
LENGTH-KEY
Die Länge des Parameters hängt von einem anderen Parameter ab
MATCHING-REQUEST-PARAM
Ein Parameter der Response muß mit einem Parameter des Requests
zur Laufzeit verglichen werden (z.B.: Local-ID)
PHYS-CONST
Konstante mit Umrechnung für physikalischen Wert
RESERVED
Parameter wird vom Laufzeitsystem ignoriert
SYSTEM
Parameter enthält Systeminformationen
TABLE-KEY
TABLE-STRUCT
TABLE-ENTRY
Für COMPLEX-DOPs wenn Datenstrukturen (Tabellen)
Indentifier indexiert werden (z.B.: ReadDataByIdentifier
WriteDataByIdentifier)
über
oder
38
COMPLEX-DOP – Typen
 Werden u. a. verwendet, wenn die Art und
Zusammensetzung der Parameter erst zur Laufzeit
bestimmt werden kann
 Anwendung: zum Beispiel DTC
Typ
Beschreibung
STRUCTURE
Fasst mehrere Parameter in einer Struktur zusammen (wie in ANSI C)
TABLE
Für Datenstrukturen (Tabellen) die über Indentifier indexiert werden (z.B.:
ReadDataByIdentifier oder WriteDataByIdentifier). Besteht aus KEY- und
STRUCTURE-Spalte.
MUX
Verzweigung, nur bei RESPONSE – der Wert des SWITCH-KEYs selektiert
den CASE, der auf die eigentliche Parameterstruktur verweist (z.B.:
Modellierung der Sub-Identifier der Diagnosebotschaften mit den
zugehörigen Parameterstrukturen)
DYNAMIC-LENGTH-FIELD
Dynamische Wiederholung der selben STRUCTURE. Anzahl ist nur zur
Laufzeit bekannt.
DYNAMIC-ENDMARKERFIELD
Wiederholung der selben STRUCTURE bis ein definierter TERMINATIONVALUE erkannt wird (z.B.: 0xFF).
STATIC-FIELD
Feste Anzahl von Wiederholungen der selben STRUCTURE
END-OF-PDU-FIELD
Wiederholung der selben STRUCTURE bis das Ende der PDU erreicht wird.
 COMPLEX-DOPs sind aus einfachen
Datenobjekten zusammengesetzte Strukturen
39
Fehlerspeicher (DTC-DOP, ENV-DATA-DESC)
40
Inhalt des Fehlerspeichers (Ereignisspeicher):
-
Anzahl der Ereignisse
StatusOfDTC
- Fehlerkode (DTC = Diagnostic Trouble Code)
- Umgebungsdaten (FREEZE-FRAMES)
Auslesen des Fehlerspeichers
(ISOTP Sequenz):
1. Lesen des Fehlerspeichestatus
ServiceID StatusOfDTC
ReadDTCByStatus
0x18
0x02
GroupOfDTC
0xFF
0xFF
ServiceID
0x58
NoOfDTC Fehlerkode (DTC)
0x02
0xFF
StatusOfDTC
0x01
0x08
…
StatusOfDTC 0x02 = requestIdentifed2ByteHexDTCAndStatus, 0x03 = requestSupported2ByteHexDTCAndStatus; GroupOFDTC 0xFFFF = allGroups
ServiceID
ServiceID
NoOfDTC Fehlerkode (DTC)
EnviromentData …
ReadStatusOfDTC
0x17
0xFF
0x01
0x57
0x02
0xFF
0x01
…
ReadStatusOfDTC
0x17
0xFF
0x02
0x57
0x02
0xFF
0x02
…
…
Fehlerkode (DTC)
Diagnoseservice
Request (Tester)
Response (ECU)
2. Iteratives Lesen der einzelnen Fehlerspeichereinträge
Fehlerspeicher – Positive Response
41
1. Lesen des Fehlerspeicherstatus
PDU Response
ReadDTCByStatus
PARAM [VALUE]
Anzahl der DTCs
PARAM [VALUE]
Liste aller vorhandenen DTCs mit Status
ID-REF/SN-REF
DYNAMIC-LENGTH-FIELD
PARAM [VALUE]
DTC #1
PARAM [VALUE]
DTC #2
PARAM [VALUE]
DTC #3
…
PARAM [VALUE]
DTC #n
ID-REF/SN-REF
PARAM
DTC
PARAM
Status
ID-REF/SN-REF
DTC-DOP
DTC
Beschreibung
0x01
Text1
0x02
Text2
STRUCTURE
Fehlerspeicher – ReadStatusOfDTC
42
2. Iteratives Lesen der einzelnen Fehlerspeichereinträge
ReadStatusOfDTC
PARAM [VALUE]
DTC und Status
ID-REF/SN-REF
ENV-DATA-DESC
PARAM
Status
ID-REF/SN-REF
DTC-DOP
Umgebungsdaten (DTC spezifisch)
ID-REF/SN-REF
STRUCTURE
PARAM
DTC
PARAM [VALUE]
DTC
Beschreibung
0x01
Text1
0x02
Text2
ENV-DATA
ENV-DATA
DTC-VALUE1
ALL-VALUE
DTC-VALUE2
PARAM1
ENV-DATA
…
PARAM1
PARAM2
PDU Response
Diagnosesitzungen – STATE-CHART
43
Diagnosedienst
DIAG-COMM-Element
PRE-CONDITION-STATE-REF
STATE-TRANSITION-REF
Diagnosedienst wird nur
in diesem Zustand ausgeführt
Diagnosedienst triggert Zustandsübergang
STATE-CHART
STATE
z.B.: Default-Session
STATE
STATE-TRANSITION
z.B.: Non-Default-Session
 Neu ab Version 2.1
 Bildet Diagnosesitzungen auf einen
Zustandsautomaten ab (STATE-CHART)
 Ist Bestandteil des DIAG-LAYER
 Es werden Zustände und Übergänge
definiert
 Zwei Funktionen:
1. Der Zustandsautomat wechselt in einen
anderen Zustand, wenn ein Diagnoseservice
korrekt ausgeführt wurde
2. Der Diagnoseservice kann nur in einem
bestimmten Zustand ausgeführt werden
Quelle: Zimmermann
Zustandsautomat
Testfragen – DIAG-LAYER-CONTAINER
2.
3.
4.
5.
Welche Schicht ist innerhalb des DIAG-LAYER6.
CONTAINERS hierarchisch am weitesten oben angeordnet?
Mit welcher Umrechnungsmethode kann man eine
gemessene Kennlinie am einfachsten in ODX definieren?
a)
ECU-VARIANT
a)
Mit SCALE-LINEAR
b)
BASE-VARIANT
b)
Mit RAT-FUNC
c)
PROTOCOL-LAYER
c)
Mit TAB-INTERP
Wie überschreibt man ein geerbtes Element?
7.
Welcher Datentyp ist am besten für Textstrings geeignet?
a)
Durch ein lokales Element mit dem Attribut NOT-INHERITED
a)
STANDARD-LENGTH-TYPE
b)
Durch ein lokales Element mit derselben ID
b)
MIN-MAX-LENGTH-TYPE
c)
Durch ein lokales Element mit demselben SHORT-NAME
c)
PARAM-LENGTH-TYPE
Kann man Elemente, die man aus der ECU-SHARED-DATA 8.
Schicht importiert hat, lokal verändern?
a)
Ja, durch Überschreiben
b)
Nein, Überschreiben ist nur beim Vererben möglich, nicht beim
Importieren
Wie definiert man die Vererbung zwischen den DIAGLAYER Schichten?
a)
Indem die erbende Schicht auf diejenige Schicht verweist, von
der sie erben soll.
b)
Indem die vererbende Schicht auf die Schicht verweist, die von
ihr erben soll.
c)
Das Vererben erfolgt automatisch, besondere Definitionen sind
nicht notwendig.
Wozu dient eine TEXTTABLE?
a)
Mit TEXTTABLE kann im ODX-Datensatz zu jedem Element ein
Kommentartext angegeben werden.
b)
TEXTTABLE beschreibt eine Zuordnungstabelle, mit der
hexadezimal kodierten Datenwerten ein Klartext zugeordnet
werden kann.
9.
Was bezeichnet ODX als STATE?
a)
Ein Diagnoseprotokoll
b)
Eine Diagnosesitzung
c)
Einen Datenwert
Wozu dient eine STATE-TRANSITION-REFERENZ?
a)
Beschreibt, in welche Diagnosesitzung (STATE) umgeschaltet
werden soll, wenn ein bestimmter Diagnosedienst ausgeführt
wurde.
b)
Beschreibt, welche Diagnosesitzung (STATE) notwendig ist, um
einen bestimmten Diagnosedienst auszuführen.
1.
44
Inhalt
45
Grundstruktur – COMPARAM-SPEC
46
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
Kommunikationsparameter – COMPARAM-SPEC
47
 Enthält für das Laufzeitsystem Angaben über das
Kommunikationsprotokoll
 Die Parameter sind nach ISO/OSI-Schichten getrennt in einzelne
COMPARAM-SUBSETS abgelegt, welche zu einem Protokollstapel (PROTSTACK) zusammengefasst werden
 Beispiel:
• PhysicalLayer (ISO 11898 CAN): Baudrate, CAN-ID, WakeUp-Pattern etc.
• TranportLayer (ISO 15756): FlowControl etc.
 Der DIAG-LAYER-CONTAINER referenziert auf den für das Steuergerät
gültigen PROT-STACK
 Kommunikationsparameter können mehrfach bis auf Service-Ebene
überschrieben werden
• ApplicationLayer (ISO 14229 UDS): Anzahl der Sendewiederholungen etc.
48
COMPARAM-SPEC
PROT-STACK
COMPARAMSUBSET
Application Layer
z.B.: ISO 14229 (UDS)
COMPARAMSUBSET
COMPARAMSUBSET
Transport Layer
z.B.: ISO 15765 (TP)
Physical Layer
z.B.: ISO 11898 (CAN)
PARAM-CLASS*
ELEMENT-ID
TIMING
INIT
COM
ERRHDL
BUSTYPE
UNIQUE_ID
CTYPE*
STANDARD
OEM-SPECIFIC
OPTIONAL
OEM-OPTIONAL
DISPLAYLEVEL*
1 (All)
2 (Restricted)
3 (Restricted)
4 (Restricted)
5 (Restricted)
CPU-USAGE*
ECU-SOFTWARE
APPLICATION
ECU-COMM
TESTER
ECU-SOFTWARE
PHYSICALDEFAULTVALUE
DOP-REF
*Attribute
COMPARAM
49
Kommunikationsparameter – Version 2.0.1
50
COMPARAM-SPEC – Vererbung
Ort der Definition der Daten
Art der Werte
COMPARAM and COMPLEX-COMPARAM
(in COMPARAM-SUBSET)
Standarddefinition
diagnostic layer [PROTOCOL]
Überschreiben
diagnostic layer [FUNCTIONAL-GROUP]
Überschreiben
Achtung: Die überschriebenen Werte innerhalb der
FUNCTIONAL-GROUP sind nicht auf darunter liegende
Schichten vererbbar!
diagnostic layer [BASE-VARIANT]
Überschreiben (PROTOCOL Layer)
diagnostic layer [ECU-VARIANT]
Überschreiben (PROTOCOL Layer, BASE-VARIANT Layer)
PHYSICAL-VEHICLE-LINK
Überschreiben
LOGICAL-LINK
Überschreiben
DIAG-SERVICE
Überschreiben
Achtung: Sollte nur in Ausnahmefällen verwendet werden, da
laufzeitkritisch!
51
Inhalt
52
Grundstruktur – VEHICLE-INFO-SPEC
53
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
VEHICLE-INFO-SPEC
54
 Dient der Fahrzeugidentifikation und beschreibt
• das Fahrzeugmodell für das die ODX-Bedatung gültig ist,
• welche Steuergeräte verbaut sind,
• über welche Schnittstellen der Diagnosetester Zugang zum
Fahrzeug hat (OBD-Steckebelegung) und
• wie die interne Topologie der Bussysteme im Fahrzeug
aufgebaut ist.
 Zugang des Laufzeitsystems auf das Fahrzeug
schrittweise über:
OEM → VEHICLE-TYPE → VEHICLE-MODEL →
MODEL-YEAR → LOGICAL-LINK → DIAG-SERVICE
1. PHYSICAL-VEHICLE-LINK
2. VEHICLE-CONNECTOR
3. VEHICLE-CONNECTOR-PIN
4. LOGICAL-LINK 1 zur ECU A
5. LOGICAL-LINK 2 zur ECU A
6. LOGICAL-LINK zum Gateway
7. GATEWAY-LOGICAL-LINK-REF zur ECU B
 Beispiel, siehe Bild:
VEHICLE-INFO-SPEC
55
Inhalt
56
Grundstruktur – FLASH
57
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
Steuergeräteprogrammierung – FLASH
58
 Beschreibung eines Datencontainers für alle bei der
Steuergeräteprogrammierung relevanten Daten
 Logische Gruppierung/Verwaltung der Daten in SESSIONS
 Beispiel Tacho-Steuergerät für Europa und USA:
• Software besteht aus einem Kodeteil (Applikation) und einem Datensatz
• Die Applikation ist für beide Varianten gleich
• Der Datensatz liegt als „km/h“ und „mph“ Variante vor
• Es werden zwei SESSIONS angelegt, siehe nächste Seite …
• Zusätzlich wird für die Programmierung noch ein Flash-Loader benötigt
Steuergeräteprogrammierung – Use-Case
59
FLASH
SESSION1
„USA“
Parametersatz
„mph“
Applikation
„Tachoanzeige“
SESSION2
„EUROPA“
Flash-Treiber
Parametersatz
„km/h“
DATABLOCK
Programmierdatensätze für ein Tachometer-Steuergerät
SESSION
Steuergeräteprogrammierung – Datencontainer
60
 DATABLOCK beschreibt die Struktur des zu programmierenden
Adressbereiches, er besitzt immer ein SEGMENT
 Zusammenhängende Programmierdaten im INTEL-HEX, MOTOROLA-S oder
BINARY Format (FLASHDATAS) werden in Datenblöcken auf SEGMENTS
abgebildet und durch SOURCE-START-ADDRESS und SOURCE-ENDADDRESS abgegrenzt
 Der Zugriffsschutz (Seed & Key) erfolgt meist über SINGLE-ECU-JOBS welche
auf eine externe *.JAR Datei verweisen
 PHYS-MEM beschreibt die reale Speicherstruktur eines Steuergeräts, damit
das Laufzeitsystem die Gültigkeit der Flash-Daten prüfen kann
 Die Programmierung erfolgt durch eine Aneinanderreihung verschiedener
Diagnosedienste innerhalb eines SINGLE-ECU-JOBs (Flash-Job)
 Der ECU-MEM-CONNECTOR stellt eine Verbindung zwischen dem Flash-Job
im DIAG-LAYER-CONTAINER und einer SESSION im FLASH-Objekt her
 In den SECURITY Objekten sind Prüfsummen und Signaturen abgelegt,
welche einer SESSION oder einem DATABLOCK zugewiesen werden
Steuergeräteprogrammierung – Datencontainer
61
FLASH
ECU-MEM
ECU-MEMCONNECTOR
DIAG-LAYERCONTAINER
BASE-VARIANT
Flash-Job
SESSION
ECU-VARIANT
z.B. USA, EUROPA
Flash-Job
PHYS-SEGMENT
FILLBYTE
BLOCK-SIZE
START-ADDRESS
DATABLOCK
SEGMENT
FLASHDATA
SECURITY
SECURITY-METHOD
FW-SIGNATURE
FW-CHECKSUM
VALIDITY-FOR
<FLASHDATA>
…
<DATA>
:020000020000FC
:100000003821F64FB…F193800000052
:100010003821F64FB…F4FB800000034
:100020003821F64FB…BC8138000004D
:100030003821F64FB…F64FB80000014
:100040003821F64FB…609880000006B
:100050003821F64FB…F64FB800000F4
</DATA>
…
</FLASHDATA>
PHYS-MEM
Steuergeräteprogrammierung – FLASH
62
Inhalt
63
Grundstruktur – ECU-CONFIG
64
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
ECU-CONFIG – Aufbau
65
 Beschreibt die Konfiguration (Variantenkodierung) eines Steuergeräts:
• Anpassung des Steuergeräts an spezielles Fahrzeug (Reduzierung ECU-VARIANTS)
• Länderspezifische
Einstellungen
ECU-CONFIG
• Kennfelder
• Freischaltung optionaler
Funktionen
 Generische Variantenidentifikation
VALID-BASEVARIANTS
CONFIG-RECORDS
SDGS
DATA-RECORD
00 01
CONFIG-ITEM
Steuergeräte-Speicher:
0A10:
0A18:
0A20:
0A28:
0A30:
1B
00
B3
62
17
…
90
00
FF
01
11
10
23
26
00
00
FE
AE
A0
45
1C
00
00
09
Steuergerät
67
10
01
01
1D
18
B0
00
00
90
92
01
00
00
FF
00 00
62 01
COMPU-METHOD
UDS: WriteDataByAddress
3D 08 0C 00 01
DOP
00 00
TEXTTABLE
00 00 = Normal
00 01 = Xenon
62 01
Laufzeitsystem
(Rückwärts – ReadECUIdentification)
ECU-CONFIG
66
Inhalt
67
Grundstruktur – MULTIPLE-ECU-JOB-SPEC
68
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
MULTIPLE-ECU-JOB
69
 Ein SINGLE-ECU-JOB kann nur mit einem Steuergerät kommunizieren
 MULTIPLE-ECU-JOBs beschreiben Jobs (Makros aus Java-Kode) für
Diagnoseabläufe, die sich auf mehrere Steuergeräte beziehen
 Das Laufzeitsystem muss dazu mehrere LOGICAL-LINKs gleichzeitig
verwalten
 Typische Anwendung Fahrzeugidentifikation: Es werden
Diagnoseanfragen gleichzeitig an alle verbauten Steuergeräte versendet
Inhalt
70
Grundstruktur – FUNCTION-DICTIONARY
71
 COMPARAM-SPEC
 FLASH
und Parameter
 ECU-CONFIG*
FUNCTION-DICTIONARY
72
 Funktionsorientierte Diagnose: Abstrakte Sichtweise auf die Diagnose
 Nicht das Steuergerät, sondern die Funktion wird betrachtet
 An einer Funktion können mehrere SG beteiligt sein
 Beispiel für die Außenbeleuchtung:
• Funktion: Lampentest (Alle Lampen ein- und ausschalten)
 BCM vorne (Steuergerät)
 BCM hinten (Steuergerät)
 Kombiinstrument (Steuergerät, Schalter)
 Funktionen werden in FUNCTION-NODES und FUNCTION-NODEGROUPS mit beliebiger Baumtiefe organisiert
 Über Referenzen auf ausführbare Dienste (EXECUTABLES) werden die
Verbindungen zu den einzelnen SG hergestellt
 Aber: Das FUNCTION-DICTIONARY kann keinen Workflow abbilden
 Anwender sieht nur die Funktion; Muss nicht wissen, an welches SG
welcher Service zum Ein- und Ausschalten gesendet wird
FUNCTION-DICTIONARY
73
FUNCTION-DICTIONARY
FUNCTION-NODEGROUPS
FUNCTIONNODES
ADDITIONALAUDIENCES
Rekursion
FUNCTION-OUTPARAMS
ECU-VARIANT-REFS
ENV-DATA-REFS
TABLE-REFS
VEHICLE-INFORMATIONCONNECTORS
BASE-VARIANTREFS
DIAG-OBJECTCONNECTOR
FUNCTION-NODES
VEHICLEINFORMATION-REFS
TABLE-ROWREFS
EXECUTABLES
DOP-BASE-REFS
DIAG-VARIABLEREFS
DIAG-COMM-REFS
MULTIPLE-ECUJOB-REFS
DTC-REFS
Vereinfachte Darstell.
FUNCTION-INPARAMS
FUNCTION-DICTIONARY
74
Testfragen – DIAG-LAYER-CONTAINER
2.
3.
4.
5.
6.
Was wird in COM-PARM-SUBSETS zusammengefasst?
a)
Die Kommunikationsparameter, die zu einem bestimmten Kommunikationsprotokoll bzw. einer bestimmten Protokollebene gehören.
b)
Die Kommunikationsparameter, die zu einer bestimmten Steuergerätefamilie gehören.
Wo werden LOGICAL LINKS definiert?
a)
Im COMM-PARAM-SUBSET
b)
Im DIAG-LAYER-CONTAINER
c)
In der VEHICLE-INFO-SPEC
d)
In der ECU-CONFIG
Wozu dient das SESSION-Element des ODX FLASH Containers?
a)
Definiert die Diagnosesitzung, in der das Flash-Programmieren erfolgt.
b)
Fasst alle notwendigen Informationen für einen Programmiervorgang für eine Fahrzeugvariante zusammen.
Welches Element des ODX FLASH Containers enthält die Speicheradressinformation für die Programmierdaten?
a)
Das FLASHDATA Element
b)
Das SEGMENT Element
c)
Das ECU-MEM Element
Wo ist ein SINGLE-ECU-JOB zu definieren?
a)
Als Teil eines MULTIPLE-ECU-JOBS
b)
Als Teil einer Schicht im DIAG-LAYER-CONTAINER
Wo wird die Variantenkodierung definiert?
a)
Im COMM-PARAM-SUBSET
b)
Im FLASH
c)
In der VEHICLE-INFO-SPEC
d)
In der ECU-CONFIG
1.
75
Danke für Ihre Aufmerksamkeit!
76
Sprechen Sie
mit uns!
www.emotive.de
Wir helfen Ihnen gern.

Pdf-ODX

Transcription

Similar documents

Produktinformation CANoe.A429

C - Mettler Toledo

Inhalt Leitartikel - Service Box

Diagnose über CAN

Produktinformation

13 - TROST

Feldbusschnittstelle DFE24B EtherCAT - SEW

Refabrikation von CAN basierten

Einführung in die Grundfunktionen von CANape

Quo Vadis SAE J1939

Automotive Diagnosekommunikation

Sonderausgabe 2016

Engineering-Lösungen und -Produkte für die

ethernet - Socomec