Inhalt. Einleitung Datenmodell DIAG-LAYER-CONTAINER COMPARAM-SPEC VEHICLE-INFO-SPEC FLASH ECU-CONFIG MULTIPLE-ECU-JOB-SPEC FUNCTION-DICTIONARY

Transkript

1

2 Inhalt 2

3 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 etc. ECU ECU ECU Anfrage über ShortName ODX, MCD 2 (ISO ) Rückgabe Temperatur D-PDU API, MCD 1 (ISO ) Diagnosesysteme im Automobil Wie lautet die PDU* zum Auslesen der Temperatur? D-Server API, MCD 3 (ISO ) ODX, MCD 2 (ISO ) 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 etc. (Request) und Protokolle 2. *PDU = Protocoll Data Unit 4. 3

4 Diagnoseprozesskette Aktueller Zustand 4 Systemlieferant Entwicklung Produktion Diagnosesystemlieferant Service Die heutige Diagnoseprozesskette ist gekennzeichnet durch einen heterogenen Austausch von diagnoserelevanten Informationen

5 Diagnoseprozesskette Datenfluss 5 Zentrale Datenbereitstellung und -weiterleitung ist Grundlage für die zukünftige Gestaltung der Diagnoseprozeßkette Quelle: ASAM e.v.,

6 Diagnoseprozesskette Zukunft: ODX 6 Systemlieferant Entwicklung Produktion Diagnosesystemlieferant Service Lieferanten Diagnose Datenbank Hersteller Diagnose Datenbank Hersteller Diagnose Datenbank Internet ODX PDX ODX PDX ODX PDX ODX PDX Austausch von standardisierten Diagnosedaten über alle Phasen des Fahrzeuglebenszyklus Grundprinzip: Single Source

7 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

8 Diagnoseprozesskette: Anwendungsbeispiel 8 Quelle: ASAM e.v.,

9 Diagnoseprozesskette: Anwendungsbeispiel 2 9 Quelle: ASAM e.v.,

10 Diagnoseprozesskette: Anwendungsbeispiel 3 10 Quelle: ASAM e.v.,

11 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 Kode-Generierung zur Konfiguration des Diagnose Kernels 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

12 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 Einfachere Wiederverwendbarkeit von verifizierten Diagnosedaten 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

13 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 Gesetzgeber 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

14 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 Herstellerunabhängigkeit Automatisierte Tools zur Konfiguration, Dokumentenerstellung, Kode- Erzeugung etc. Generische Erstellung von Diagnoseapplikationen

15 Risiken 15 Investitionsbedarf vs. Use-Case Sinkende Flexibilität Never change a running system Gibt es ein Geschäftsmodell?

16 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 kompletter Bedatungen zwischen OEM und Zulieferer Austausch von Revision-Historys und Configurations Management Informationen Verschiedene Versionen einer Datei können in einem PDX vorhanden sein Reduzierung der Dateigröße

17 Dateiendungen 17 Endung odx-c, odx-cs odx-d odx-e odx-f odx-fd odx-m Bedeutung COMPARAM-SPEC, COMPARAM-SUBSET DIAG-LAYER-CONTAINER ECU-CONFIG FLASH FUNCTION-DICTIONARY MULTIPLE-ECU-JOB-SPEC odx-v VEHICLE-INFORMATION-SPEC odx Alternative zu allen obigen Bezeichnungen, jedoch nicht so restriktiv

18 Inhalt 18

19 Hauptkomponenten 19 ODX = Open Diagnostic data exchange ADMIN-DATA ODX-CATEGORY COMPANY-DATAS VEHICLE-INFO- SPEC COMPARAM-SPEC DIAG-LAYER- CONTAINER FLASH MULTIPLE-ECU- JOB-SPEC ECU-CONFIG* COMPARAM- SUBSET* FUNCTION- DICTIONARY* ECU-SHARED-DATAS PROTOCOLS FUNCTIONAL-GROUPS BASE-VARIANTS ECU-VARIANTS SINGLE-ECU-JOB DIAG-SERVICE DATA-OBJECT-PROPS REQUEST POS-RESPONSES NEG-RESPONSES Vereinfachte Darstellung

20 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

21 Minimalstruktur einer ODX-Bedatung 21 Beschreibt die Fahrzeugtopologie VEHICLE-INFO-SPEC VEHICLE-INFORMATION PHYSICAL-LAYER LOGICAL-LINKS BASE-VARIANT-REF Beschreibt das Bussystem COMPARAM-SPEC Bus-Parameter z.b. Baudrate, Timings, CAN- IDs etc. verweist auf Beschreibt die Steuergeräte DIAG-LAYER-CONTAINER PROTOCOL COMPARAM-SPEC-REF verweist auf BASE-VARIANT DIAG-SERVICES SINGLE-ECU-JOBS COMPARAM-REFS

22 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 Enthält detaillierte Informationen über das ODX-Objekt (keine Längenbegrenzung, mit HTML Format-Tags) 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

23 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 AUDIENCE & ADDITIONAL-AUDIENCES Zuordnung der Verfügbarkeit von Diagnose-Elementen zu bestimmten Benutzergruppen 5 vordefinierte boolesche Werte Kann um benutzerdefinierte Attribute erweitert werden (ADDITIONAL-AUDIENCES)

24 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 Referenz ist ein Objekt Referenziert eine ID (ID sollte im gesamten Projekt eindeutig sein, GUID empfohlen) 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 Erben eines Parent-Objektes, das überschrieben werden kann SN-REF können verwendet werden Enterbung 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)

25 Referenzen und Vererbung OTX-LINK oder ID-REF 25 Objekte O 1 und O 2 Link-Auflösung Sichtbarkeit zur Laufzeit Existenz zur Laufzeit ODX-LINK Layer A O 1 O 2 O 1 O 2 O 1 O 2 O 1 O 2 erbt von Layer B O O 1 2 O 1 O 2 O 1 O 2 O 1 O 2 O 2 erbt von Layer C O O 1 2 O 1 O 2 O 1 O 2 O 1 O 2 O 2 Hochkomma = Objekt wurde im Layer überschrieben

26 Referenzen und Vererbung SHORT-NAME-REF (SN-REF) 26 Objekte O 1 und O 2 Link-Auflösung Sichtbarkeit zur Laufzeit Existenz zur Laufzeit SN-REF Layer A O 1 O 2 O 1 O 2 O 1 O 2 O 1 O 2 erbt von SN-REF Layer B O O 1 2 O 1 O 2 O 1 O 2 O 1 O 2 erbt von SN-REF Layer C O O 1 2 O 1 O 2 O 1 O 2 O 1 O 2 Hochkomma = Objekt wurde im Layer überschrieben

27 Referenzen und Vererbung Enterben 27 Objekte O 1, O 2 und O 3 Link-Auflösung Sichtbarkeit zur Laufzeit Existenz zur Laufzeit Layer A O 3 O 3 O 3 erbt von ODX-LINK B O 1 O 2 O 3 O 1 O 2 O 3 O 1 O 2 O 1 O 2 erbt von NOT-INHERITED O 3 O 3 O 3 C O 2 O 1 O 1 O 2 O 3 O 1 O 2 O 1 O 2 O 2 O 3 Hochkomma = Objekt wurde im Layer überschrieben

28 Testfragen Einleitung 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) DIAG-LAYER-CONTAINER 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 4. 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

29 Inhalt 29

30 Grundstruktur DIAG-LAYER-CONTAINER 30 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

31 DIAG-LAYER-CONTAINER 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 Schichtenmodell (Diagnostic Layer): 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)

32 ECU-SHARED-DATA z.b.: PID-LIBRARY, UNITS-OEM DIAG-LAYER-CONTAINER Vererbung 32 Hoher Level 0 erben o. import Beispiel: Türsteuergeräte PROTOCOL * z.b.: ISO 15765, ISO 14229, ReadDataByLocalID erbt von 0 0 Allgemeiner 0 erben o. import FUNCTIONAL-GROUP z.b.: DOORS 0 erbt von erbt von 0 erben o. import BASE-VARIANT * z.b.: DCM (Door Control Module) 1 erbt von Niedriger Level 0 erben o. import ECU-VARIANT z.b.: DCM-Front, DCM-Heck Spezieller Bibliothek Diagnoseschichten DIAG-LAYER * Layer muss existieren

33 DATA-OBJECT-PROPERTY (DOP) 33 Kernelement im DIAG-LAYER-CONTAINER zur Interpretation der Parameter eines Diagnoseservices in menschenlesbarer Form 2 Typen: - Simple DOP - Complex DOP COMPU-METHOD Umrechnungsmethode zw. Kodierten Wert und der physikalischen Größe DIAG-CODED-TYPE Datentyp des kodierten Wertes eines Parameters PDU IDREF / SNREF PARAM Wert 1 DOP PHYSICAL-TYPE COMPU-METHOD DIAG-CODED-TYPE IDREF 1 PHYSICAL-TYPE Datentyp des physikalischen Wertes eines Parameters INTERNAL-CONSTR IDREF UNIT Gültigkeitsintervalle für den Parameter im kodierten Format 1 PHYSICAL DIMENSION UNIT-REF Referenz zur physikalischen Einheit des Parameters PHYS-CONSTR Gültigkeitsintervalle für den physikalischen Parameter

34 physikalisch physikalisch physikalisch physikalisch physikalisch physikalisch physikalisch physikalisch DOP COMPU-METHOD 34 0x21 0x31 kodierter Wert kodierter Wert TEXTTABLE Kodierter Wert wird einem Text aus einer Tabelle zugeordnet IDENTICAL Kodierter Wert ist gleich dem physikalischem Wert kodierter Wert kodierter Wert RAT-FUNC Kodierter Wert wird über eine gebrochen rationale Funktion in den physikalischen Wert umgerechnet V N0 + V N1 x + V N2 x V Nm x m y = V D0 + V D1 x + V D2 x V Dn x n SCALE-RAT-FUNC Kodierter Wert wird abschnittsweise über gebrochen rationale Funktionen in den phys. Wert umgerechnet kodierter Wert LINEAR Kodierter Wert wird über eine lineare Funktion (y = mx + n) in den physikalischen Wert umgerechnet kodierter Wert TAB-INTERP Kodierter Wert wird über definierte LOWER-LIMITS interpolierend in den physikalischen Wert umgerechnet kodierter Wert SCALE-LINEAR Kodierter Wert wird abschnittsweise über eine lineare Funktionen in den physikalischen Wert umgerechnet Java Code kodierter Wert COMPUCODE Kodierter Wert wird über ein Java- Programm mit dem Interface I_CompuCode() in den physikalischen Wert umgerechnet

35 DOP DIAG-CODED-TYPES 35 STANDARD-LENGTH-TYPE: LEADING-LENGTH-INFO-TYPE: 010 kodierter Wert BIT-LENGTH = 16 BIT-LENGTH = 3 Bit LENGTH_INFO = 2 Byte Die Länge des Parameters steht in BIT-LENGTH (BIT-MASK) MIN-MAX-LENGTH-TYPE: MIN-LENGTH = 8 (ab da wird die Endemarke gesucht) 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 PARAM-LENGTH-INFO-TYPE: LENGTH-KEY-REF TERMINATION 0xFF oder 0x00 PARAM [LENGTH-KEY] kodierter Wert MAX-LENGTH = 24 DOP 16 Bit Das Ende des Parameters definiert entweder die Endemarke, die maximale Länge oder das Ende der PDU (END-OF-PDU) Die Länge des Parameters ist in einem vorangegangenen Parameter des Typs LENGTH-KEY enthalten

36 Diagnostic Communication Primitives (DIAG-COMMS) 36 Die Diagnosedienste DIAG-SERVICE beschreiben die Diagnosefunktionalitäten des DIAG- LAYER in welchem sich der Dienst befindet 0 1 REQUEST ( ) PARAM DOP 0 1 UNIT DIAG-SERVICE 0 POS-RESPONSE (63 ( E5) E5) 1 PARAM 0 1 DOP 0 1 UNIT ID-REF 0 NEG-RESPONSE (7F (7F ) 31) 1 PARAM 0 1 DOP 0 1 UNIT 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. 0 INPUT-PARAMS 0 1 DOP 0 1 UNIT SINGLE-ECU-JOB 0 OUTPUT-PARAMS 0 1 DOP 0 1 UNIT 1 Java Code ID-REF 0 NEG-OUTPUT-PARAMS 0 1 DOP 0 1 UNIT ID-REF/SN-REF

37 Diagnoseservices (DIAG-SERVICE) 37

38 Typen von Parametern 38 Typ VALUE CODED-CONST DYNAMIC LENGTH-KEY MATCHING-REQUEST-PARAM PHYS-CONST RESERVED Beschreibung Datenwert, verweist auf ein DOP Konstante (z.b. SID) Parametertyp wird erst zur Laufzeit festgelegt (nur für Response) Die Länge des Parameters hängt von einem anderen Parameter ab Ein Parameter der Response muß mit einem Parameter des Requests zur Laufzeit verglichen werden (z.b.: Local-ID) Konstante mit Umrechnung für physikalischen Wert Parameter wird vom Laufzeitsystem ignoriert SYSTEM TABLE-KEY TABLE-STRUCT TABLE-ENTRY Parameter enthält Systeminformationen Für COMPLEX-DOPs wenn Datenstrukturen (Tabellen) über Indentifier indexiert werden (z.b.: ReadDataByIdentifier oder WriteDataByIdentifier)

39 COMPLEX-DOP Typen 39 COMPLEX-DOPs sind aus einfachen Datenobjekten zusammengesetzte Strukturen 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 MUX DYNAMIC-LENGTH-FIELD DYNAMIC-ENDMARKER- FIELD STATIC-FIELD END-OF-PDU-FIELD Für Datenstrukturen (Tabellen) die über Indentifier indexiert werden (z.b.: ReadDataByIdentifier oder WriteDataByIdentifier). Besteht aus KEY- und STRUCTURE-Spalte. 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) Dynamische Wiederholung der selben STRUCTURE. Anzahl ist nur zur Laufzeit bekannt. Wiederholung der selben STRUCTURE bis ein definierter TERMINATION- VALUE erkannt wird (z.b.: 0xFF). Feste Anzahl von Wiederholungen der selben STRUCTURE Wiederholung der selben STRUCTURE bis das Ende der PDU erreicht wird.

40 Fehlerspeicher (DTC-DOP, ENV-DATA-DESC) 40 Inhalt des Fehlerspeichers (Ereignisspeicher): - Anzahl der Ereignisse - Fehlerkode (DTC = Diagnostic Trouble Code) - StatusOfDTC - Umgebungsdaten (FREEZE-FRAMES) Auslesen des Fehlerspeichers (ISOTP Sequenz): 1. Lesen des Fehlerspeichestatus ServiceID StatusOfDTC GroupOfDTC ServiceID NoOfDTC Fehlerkode (DTC) StatusOfDTC ReadDTCByStatus 0x18 0x02 0xFF 0xFF 0x58 0x02 0xFF 0x01 0x08 StatusOfDTC 0x02 = requestidentifed2bytehexdtcandstatus, 0x03 = requestsupported2bytehexdtcandstatus; GroupOFDTC 0xFFFF = allgroups 2. Iteratives Lesen der einzelnen Fehlerspeichereinträge ServiceID Fehlerkode (DTC) ServiceID NoOfDTC Fehlerkode (DTC) EnviromentData ReadStatusOfDTC 0x17 0xFF 0x01 0x57 0x02 0xFF 0x01 ReadStatusOfDTC 0x17 0xFF 0x02 0x57 0x02 0xFF 0x02 Diagnoseservice Request (Tester) Response (ECU)

41 Fehlerspeicher Positive Response 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 STRUCTURE PARAM DTC PARAM Status DTC-DOP ID-REF/SN-REF DTC 0x01 0x02 Beschreibung Text1 Text2

42 Fehlerspeicher ReadStatusOfDTC Iteratives Lesen der einzelnen Fehlerspeichereinträge PDU Response ReadStatusOfDTC PARAM [VALUE] DTC und Status ID-REF/SN-REF STRUCTURE PARAM [VALUE] Umgebungsdaten (DTC spezifisch) ID-REF/SN-REF ENV-DATA-DESC PARAM DTC PARAM Status ENV-DATA ENV-DATA ENV-DATA ID-REF/SN-REF DTC-DOP DTC 0x01 0x02 Beschreibung Text1 Text2 DTC-VALUE1 DTC-VALUE2 PARAM1 PARAM2 ALL-VALUE PARAM1

43 Diagnosesitzungen STATE-CHART 43 Diagnosedienst DIAG-COMM-Element STATE-TRANSITION-REF Diagnosedienst triggert Zustandsübergang PRE-CONDITION-STATE-REF Diagnosedienst wird nur in diesem Zustand ausgeführt STATE-CHART STATE z.b.: Default-Session STATE-TRANSITION STATE z.b.: Non-Default-Session Zustandsautomat 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

44 Testfragen DIAG-LAYER-CONTAINER Welche Schicht ist innerhalb des DIAG-LAYER- CONTAINERS hierarchisch am weitesten oben angeordnet? a) ECU-VARIANT b) BASE-VARIANT c) PROTOCOL-LAYER 6. Mit welcher Umrechnungsmethode kann man eine gemessene Kennlinie am einfachsten in ODX definieren? a) Mit SCALE-LINEAR b) Mit RAT-FUNC c) Mit TAB-INTERP 2. Wie überschreibt man ein geerbtes Element? a) Durch ein lokales Element mit dem Attribut NOT-INHERITED b) Durch ein lokales Element mit derselben ID c) Durch ein lokales Element mit demselben SHORT-NAME 3. Kann man Elemente, die man aus der ECU-SHARED-DATA Schicht importiert hat, lokal verändern? a) Ja, durch Überschreiben b) Nein, Überschreiben ist nur beim Vererben möglich, nicht beim Importieren 4. Wie definiert man die Vererbung zwischen den DIAG- LAYER 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. 7. Welcher Datentyp ist am besten für Textstrings geeignet? a) STANDARD-LENGTH-TYPE b) MIN-MAX-LENGTH-TYPE c) PARAM-LENGTH-TYPE 8. Was bezeichnet ODX als STATE? a) Ein Diagnoseprotokoll b) Eine Diagnosesitzung c) Einen Datenwert 9. 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. 5. 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.

45 Inhalt 45

46 Grundstruktur COMPARAM-SPEC 46 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

47 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 (PROT- STACK) zusammengefasst werden Beispiel: PhysicalLayer (ISO CAN): Baudrate, CAN-ID, WakeUp-Pattern etc. TranportLayer (ISO 15756): FlowControl etc. ApplicationLayer (ISO UDS): Anzahl der Sendewiederholungen 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

48 Kommunikationsparameter COMPARAM-SPEC 48 COMPARAM-SPEC PROT-STACK COMPARAM- SUBSET Application Layer z.b.: ISO (UDS) COMPARAM- SUBSET Transport Layer z.b.: ISO (TP) COMPARAM- SUBSET Physical Layer z.b.: ISO (CAN) COMPARAM ELEMENT-ID PARAM-CLASS * TIMING INIT COM ERRHDL BUSTYPE UNIQUE_ID CTYPE * STANDARD OEM-SPECIFIC OPTIONAL OEM-OPTIONAL DISPLAY- LEVEL * 1 (All) 2 (Restricted) 3 (Restricted) 4 (Restricted) 5 (Restricted) CPU-USAGE * ECU-SOFTWARE APPLICATION ECU-COMM TESTER ECU-SOFTWARE PHYSICAL- DEFAULT- VALUE * Attribute DOP-REF Vereinfachte Darstellung

49 Kommunikationsparameter COMPARAM-SPEC 49

50 Kommunikationsparameter Version

51 COMPARAM-SPEC Vererbung 51 Ort der Definition der Daten COMPARAM and COMPLEX-COMPARAM (in COMPARAM-SUBSET) diagnostic layer [PROTOCOL] diagnostic layer [FUNCTIONAL-GROUP] diagnostic layer [BASE-VARIANT] diagnostic layer [ECU-VARIANT] PHYSICAL-VEHICLE-LINK Art der Werte Standarddefinition Überschreiben Überschreiben Achtung: Die überschriebenen Werte innerhalb der FUNCTIONAL-GROUP sind nicht auf darunter liegende Schichten vererbbar! Überschreiben (PROTOCOL Layer) Überschreiben (PROTOCOL Layer, BASE-VARIANT Layer) Überschreiben LOGICAL-LINK DIAG-SERVICE Überschreiben Überschreiben Achtung: Sollte nur in Ausnahmefällen verwendet werden, da laufzeitkritisch!

52 Inhalt 52

53 Grundstruktur VEHICLE-INFO-SPEC 53 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

54 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 Beispiel, siehe Bild: 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 Quelle: ASAM e.v.,

55 VEHICLE-INFO-SPEC 55

56 Inhalt 56

57 Grundstruktur FLASH 57 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

58 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 Zusätzlich wird für die Programmierung noch ein Flash-Loader benötigt Es werden zwei SESSIONS angelegt, siehe nächste Seite

59 Steuergeräteprogrammierung Use-Case 59 FLASH SESSION SESSION1 USA SESSION2 EUROPA Parametersatz mph Applikation Tachoanzeige Flash-Treiber Parametersatz km/h DATABLOCK Programmierdatensätze für ein Tachometer-Steuergerät

60 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-END- ADDRESS abgegrenzt Der Zugriffsschutz (Seed & Key) erfolgt meist über SINGLE-ECU-JOBS welche auf eine externe *.JAR Datei verweisen In den SECURITY Objekten sind Prüfsummen und Signaturen abgelegt, welche einer SESSION oder einem DATABLOCK zugewiesen werden 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

61 Steuergeräteprogrammierung Datencontainer 61 FLASH ECU-MEM ECU-MEM- CONNECTOR DIAG-LAYER- CONTAINER BASE-VARIANT Flash-Job SESSION z.b. USA, EUROPA ECU-VARIANT Flash-Job PHYS-MEM PHYS-SEGMENT FILLBYTE BLOCK-SIZE START-ADDRESS DATABLOCK SEGMENT FLASHDATA SECURITY SECURITY-METHOD FW-SIGNATURE FW-CHECKSUM VALIDITY-FOR <FLASHDATA> <DATA> : FC : F64FB F : F64FB F4FB : F64FB BC D : F64FB F64FB : F64FB B : F64FB F64FB800000F4 </DATA> </FLASHDATA> Vereinfachte Darstellung

62 Steuergeräteprogrammierung FLASH 62

63 Inhalt 63

64 Grundstruktur ECU-CONFIG 64 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

65 ECU-CONFIG Aufbau 65 Beschreibt die Konfiguration (Variantenkodierung) eines Steuergeräts: Anpassung des Steuergeräts an spezielles Fahrzeug (Reduzierung ECU-VARIANTS) Länderspezifische Einstellungen Kennfelder Freischaltung optionaler Funktionen Generische Variantenidentifikation (Rückwärts ReadECUIdentification) Steuergeräte-Speicher: 0A10: 1B A18: FE 1C 10 B0 01 0A20: B3 FF 26 AE A28: A0 09 1D 90 FF 0A30: VALID-BASE- VARIANTS DATA-RECORD ECU-CONFIG CONFIG-RECORDS SDGS CONFIG-ITEM DOP Steuergerät UDS: WriteDataByAddress 3D 08 0C COMPU-METHOD TEXTTABLE = Normal = Xenon Laufzeitsystem Vereinfachte Darstellung

66 ECU-CONFIG 66

67 Inhalt 67

68 Grundstruktur MULTIPLE-ECU-JOB-SPEC 68 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

69 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

70 Inhalt 70

71 Grundstruktur FUNCTION-DICTIONARY 71 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 * Beschreibung der Steuergerätekonfiguration - Variantenkodierung MULTIPLE-ECU-JOB-SPEC Beschreibung von Jobs, welche sich auf mehrere Steuergeräte beziehen. SINGLE-ECU-JOBs sind Bestandteil des DIAG-LAYER- CONTAINERs COMPARAM-SUBSET * Beschreibung von vordefinierten Kommunikationsparametern für Physical Layer, Transport Layer oder Diagnoseprotokoll FUNCTION-DICTIONARY * Beschreibung von Informationen zur funktionsorientierten Diagnose

72 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) Anwender sieht nur die Funktion; Muss nicht wissen, an welches SG welcher Service zum Ein- und Ausschalten gesendet wird Funktionen werden in FUNCTION-NODES und FUNCTION-NODE- GROUPS 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

73 FUNCTION-DICTIONARY 73 FUNCTION-DICTIONARY FUNCTION-NODE- GROUPS FUNCTION- NODES ADDITIONAL- AUDIENCES Rekursion FUNCTION-IN- PARAMS FUNCTION-OUT- PARAMS VEHICLE-INFORMATION- CONNECTORS FUNCTION-NODES ECU-VARIANT-REFS BASE-VARIANT- REFS DIAG-OBJECT- CONNECTOR VEHICLE- INFORMATION-REFS ENV-DATA-REFS TABLE-REFS TABLE-ROW- REFS EXECUTABLES DOP-BASE-REFS DTC-REFS DIAG-VARIABLE- REFS DIAG-COMM-REFS MULTIPLE-ECU- JOB-REFS Vereinfachte Darstell.

74 FUNCTION-DICTIONARY 74

75 Testfragen DIAG-LAYER-CONTAINER 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. 2. 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 3. 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. 4. 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 5. Wo ist ein SINGLE-ECU-JOB zu definieren? a) Als Teil eines MULTIPLE-ECU-JOBS b) Als Teil einer Schicht im DIAG-LAYER-CONTAINER 6. Wo wird die Variantenkodierung definiert? a) Im COMM-PARAM-SUBSET b) Im FLASH c) In der VEHICLE-INFO-SPEC d) In der ECU-CONFIG

76 Danke für Ihre Aufmerksamkeit! 76 Sprechen Sie mit uns! Wir helfen Ihnen gern.