V 13.0.0 Stand: 10.05.

2019

VW-MCD

ODX-Converter

Transformator von ODX-Daten der

Standardversionen 2.0.1, 2.1 und 2.2

Installation, Konfiguration, Betrieb

Druckdatum: 11.04.19 File: VW-MCD_ODXConverter.doc

2 V13.0.0 / 10.05.2019

Inhaltsverzeichnis

1 Übersicht VW-MCD ....................................................................................... 3

2 Übersicht ODX-Converter ............................................................................ 5

3 Unterstützte ASAM-ODX-Standards ............................................................ 6

4 Bedienung ..................................................................................................... 6

4.1 Erstellung reduzierter Laufzeitdatenprojekte ........................................................... 13

4.2 Textdatenbank ........................................................................................................ 13

4.3 Laufzeitdatenmodularisierung ................................................................................. 15

4.4 Transformieren von Basisvarianten und Varianten in gemeinsame Datenbanken ... 19

4.5 Ignorieren von Job-Dateien und externen Bibliotheken ........................................... 20

4.6 Ignorieren von Job-Unterverzeichnissen ................................................................. 20

4.7 Konvertierung von Java-Dateien ............................................................................. 21

4.8 Anlegen eines Upload-Verzeichnisses .................................................................... 21

4.9 Rückgabe und Ignorieren von Konvertierungsfehlern ............................................. 21

4.10 Überschreiben von ODX-Daten zur Converter-Laufzeit .......................................... 22

4.11 Optimierter Transformationslauf in Abhängigkeit von Bedatungsrichtlinien ............. 23

4.12 Steuerung der Fehlertoleranz ................................................................................. 24

5 ODX-Standard übergreifende Datenprojekte ............................................ 26

6 Systemanforderungen ................................................................................ 27

6.1 Betriebssysteme ..................................................................................................... 27

6.2 Minimale Hardwareausstattung............................................................................... 27

6.3 Datengetriebene Restriktionen................................................................................ 27

7 Installation ................................................................................................... 29

8 Hinweis auf Fremdkomponenten............................................................... 30

V13.0.0 / 10.05.2019 1. Übersicht VW-MCD 3

1 Übersicht VW-MCD

Die nachfolgende Abbildung skizziert den Zusammenhang der einzelnen VW-MCD-

Komponenten und ihr Zusammenspiel in einer Anwendungsumgebung.

PDX-Builder

ODX Files

(Project Source Data)

ODX-Converter

Source-PDX

Runtime DB Files

(Project Runtime Data)

Application

Runtime-PDX

C++ Java DCom

ISO 22900-3 MCD-3D Interface

DB
ODX-ProjectUpdater Connector MCD-Kernel

ISO 22900-2 D-PDU-API

D-PDU-API Library

VCI-Driver

Abbildung 1. VW-MCD Komponenten im Zusammenspiel

4 1. Übersicht VW-MCD V13.0.0 / 10.05.2019

In einem typischen Anwendungsszenario, das bei Weitem nicht das vollständige

Einsatzspektrum von VW-MCD abdeckt, werden ODX-Daten mit Hilfe des PDX-Builders zu
einem Source-PDX zusammengestellt und in ein Runtime-PDX transformiert. Für den
Transformationsschritt verwendet der PDX-Builder den ODX-Converter. Die entstehenden
einzelnen Laufzeitdatenbanken werden anschließend wieder zu einem Runtime-PDX
zusammengefasst.

Dieses Runtime-PDX wird dem MCD-Kernel als Laufzeitdatenprojekt beigestellt,

gegebenenfalls über den ODX-ProjectUpdater.

In Abhängigkeit von der Applikation lädt der MCD-Kernel die jeweils benötigten Projektdaten
und kommuniziert über eine standardkonforme D-PDU-API mit einem Fahrzeug.

Gegenstand dieser Dokumentation ist der ODX-Converter.

V13.0.0 / 10.05.2019 2. Übersicht ODX-Converter 5

2 Übersicht ODX-Converter
VW-MCD verwendet ein binäres Laufzeitformat, welches durch den ODX-Converter aus
ODX-Daten erstellt wird. Ein binäres Laufzeitformat hat verschiedene wesentliche Vorteile.
Es ermöglicht eine deutlich bessere Performanz des Gesamtsystems, bei der Erstellung
werden zusätzliche Konsistenzprüfungen der ODX-Daten durchgeführt, und es ermöglicht
eine deutlich größere Flexibilität.

• Flexibilität

Der ODX-Converter ist fähig, alle wesentlichen ODX Standards in ein gemeinsames
Laufzeitformat zu transformieren. Der MCD-Kernel kann dadurch unabhängig von der
ODX-Version implementiert werden.

• Performanz zur Laufzeit

Das Laufzeitformat ermöglicht einen hochperformanten Zugriff auf die konvertierten

Daten, welches eine wesentlich schnellere Ausführungsgeschwindigkeit des MCD-
Kernels ermöglicht.

• Größe der verteilten Daten

Zusätzlich können durch die Transformierung Redundanzen vermieden werden, was zu

einer wesentlichen Reduktion des Datenvolumens auf dem Laufzeitsystem führt. Dies
bedeutet für den Prozess der Datenverteilung auf die Laufzeitsysteme einen hohen
Zeitgewinn.

• Prüfen der Datenkonsistenz

Während der Transformation werden verschiedene Überprüfungen der ODX-

Eingangsdaten durchgeführt. Etwaige Fehler in den Daten können somit frühzeitig
erkannt werden und erscheinen nicht erst zur Laufzeit. Über Log-Ausgaben informiert der
ODX-Converter über die entdeckten Fehler.

• Laufzeitdatenmodularisierung

Die resultierenden Laufzeitdateien sind nach verschiedenen ODX-Elementen aufgeteilt.

Dadurch können ODX-Projekte flexibel und individuell aus einem Gesamt-Datenpool
zusammengestellt werden. Lediglich die Import- und Vererbungsbeziehungen müssen
dabei beachtet werden. Der MCD-Kernel überprüft diese Beziehungen beim Hochfahren
und meldet entsprechende Fehler frühzeitig.

Unter Berücksichtigung gewisser Randbedingungen ist es möglich, Teilprojekte zu einem

Gesamtprojekt zusammenzustellen, die auf unterschiedlichen ODX-Standards beruhen.
So kann beispielsweise aus den Bedatungen einzelner Steuergeräte je ein Teilprojekt
erstellt und in einem übergreifenden Baureihenprojekt verwendet werden, auch wenn die
einzelnen Steuergerätebedatungen unterschiedlichen ODX-Standards genügen.
6 3. Unterstützte ASAM-ODX-Standards V13.0.0 / 10.05.2019

3 Unterstützte ASAM-ODX-Standards

Der ODX-Converter verarbeitet ODX-Dateien der folgenden ODX Standard-Versionen:

• Standard-Version ASAM-MCD-2D (ODX) 2.0.1

• Standard-Version ASAM-MCD-2D (ODX) 2.1

• Standard-Version ASAM-MCD-2D (ODX) 2.2 (ISO 22901-1)

4 Bedienung

Der ODX-Converter ist eine Konsolenapplikation und wird wie folgt gestartet:
converter.exe
–project <project name>
Name des Projekts
ist die Option –create_pdx gesetzt, bezeichnet das Argument
den Namen des zu erstellenden PDX ohne Dateiendung
-in <input directory>
Pfad und Name des Verzeichnisses mit den zu konvertierenden
ODX-Dateien;
alternativ: Pfad und Name eines Source-PDX mit den zu
konvertierenden ODX-Dateien
-out <output directory>
Pfad und Name des Verzeichnisses, in das die entstehenden
Laufzeitdatenbanken abgelegt werden sollen;
ist die Option –create_pdx gesetzt, bezeichnet das Argument
den Pfad des zu erstellenden PDX
[-create_pdx]
Ist diese Option gesetzt, benennt das Argument zu –out den
Pfad und das Argument zu –project den Namen des zu
erstellenden PDX ohne Dateiendung, die entsprechend dem
Converter-Modus ergänzt wird.
[-out_reduced]
Ist diese Option gesetzt, wird ein entsprechend der
Konfiguration reduziertes Laufzeitdatenprojekt erstellt.
Das Argument zu –out bezeichnet das Zielverzeichnis. Ist die
Option –create_pdx gesetzt, wird ein reduziertes
Laufzeitdaten-PDX erstellt.
[-filetrace <loglevel>]
Loglevel für Dateiausgabe; Voreinstellung 0
[-consoletrace <loglevel>]
Loglevel für Konsolenausgabe; Voreinstellung 5
[-ignoreerror <ignore error>]
V13.0.0 / 10.05.2019 4. Bedienung 7

1:“leichte” Fehler, die das Erstellen von in Tests

nutzbaren Daten nicht verhindern, werden ignoriert;
Laufzeitdaten werden erstellt
0: Fehler werden nicht ignoriert;
im Fehlerfall werden keine Laufzeitdaten erstellt
Voreinstellung
[-majornr <major number>]
„major“ Versionsnummer; Voreinstellung 0
[-minornr <minor number>]
„minor“ Versionsnummer; Voreinstellung 0
[-revisionnr <revision number>]
„revision“ Versionsnummer; Voreinstellung 0
[-<mode> [<selection>]]
Transformationsmodus plus Spezialisierung, siehe unten
[-lbdir]
Unterverzeichnis des Projektverzeichnisses, in das alle
Dateien kopiert werden, die im Source-PDX enthalten, aber
nicht in der index.xml referenziert sind.
[-classpath <class path>]
Pfade und Namen zusätzlicher Jars, die für die Job-
Kompilierung erforderlich sind;
nur für Jobs, die als Java-Code vorliegen
[-ignorecodefiles <code file mode>]
0: Job-JARs, Job-Classes und die über LIBRARY
referenzierten externen Bibliotheken werden in das
Laufzeitdatenprojekt kopiert
1: Job-JARs, Job-Classes und die über LIBRARY
referenzierten externen Bibliotheken werden nicht in
das Laufzeitdatenprojekt kopiert, wenn sie nicht in der
index.xml referenziert sind; sie müssen spätestens bis
zum Zeitpunkt der ersten Verwendung zur Laufzeit im
Projektverzeichnis verfügbar sein; die Verantwortung
liegt bei der Applikation
Voreinstellung 0
[-notxtdb]
Alle Texte in den ODX-Daten werden direkt in den
serialisierten Datenstrom geschrieben, nicht in eine
Textdatenbank. Diese Option ist erforderlich, um Flash-
Projekte isoliert konvertieren und zu einem Basisprojekt
hinzufügen zu können, das keine globale, sondern eine lokale
Textdatenbank verwendet.
8 4. Bedienung V13.0.0 / 10.05.2019

[-dontziptxtdb]
Die gegebenenfalls im Verlauf der Konvertierung erstellten
Textdatenbankdateien werden nicht komprimiert.
Sollten wegen des gewählten Transformationsmodus keine
Textdatenbankdateien erzeugt werden, wird die Option
ignoriert.
[-licenses]
Anzeige der Lizenztexte lizensierter Fremdsoftware

Mögliche Werte für <mode>:

• full
Transformation des kompletten Projekts

• ecu_full <selection>
Transformation aller Daten des Quellprojekts, die für die Basisvariante <selection>
relevant sind

• ecu_basic <selection>
Transformation der Basisdaten des Quellprojekts, die für die Basisvariante <selection>
relevant sind

• ecu_basic_vit <selection>
Zusätzliche Transformation der VIT zur Basisvariante <selection>

• ecu_variant <selection>
Transformation aller Daten des Quellprojekts, die für die Variante <selection> relevant
sind; das Quellprojekt muss in sich geschlossen sein, die Ausgabe umfasst nur die Daten
der Variante und damit einen geringeren Umfang als die im Prozess konvertierten Daten

• protocol <selection>
Transformation der zum Protokoll <selection> gehörenden Daten des Quellprojekts

• functional_group <selection>
Transformation der zur Funktionalen Gruppe <selection> gehörenden Daten des
Quellprojekts

• cps
Transformation aller ComparamSpecs und ComparamSubsets des Quellprojekts

• vit
Transformation aller VITs des Quellprojekts

• vit <selection>
Transformation der VIT <selection> des Quellprojekts

• ecu_config
Transformation aller ECU-Config-Daten des Quellprojekts

• ecu_config <selection>
V13.0.0 / 10.05.2019 4. Bedienung 9

Transformation der zur ECU-Config <selection> gehörenden Daten des Quellprojekts

• flash
Transformation aller Flash-Daten des Quellprojekts

• function_dictionary
Transformation aller Function-Dictionary-Daten des Quellprojekts

• frf_flash <frf flash file>

Transformation aller Flash-Daten der angegebenen FRF-Datei
Tabellarische Zusammenfassung des Inhalts eines Laufzeitdatenpakets in Abhängigkeit vom
Transformationsmodus:

MULTIPLE-ECU-JOB-SPEC

FUNCTION-DICTIONARY

PROGRAMMING-DATA
FUNCTIONAL-GROUP

COMPARAM-SUBSET

VEHICLE-INFO-SPEC
ECU-SHARED-DATA

COMPARAM-SPEC

other CATEGORY
BASE-VARIANT
ECU-VARIANT

ECU-CONFIG
PROTOCOL

ODX-JOB
FLASH

LIB
full a a a a a a a a a a a a a a a a
ecu_full s s s s a - - a a s - a a a a a
ecu_basic s s s s a - - - a - - a a - - -
ecu_basic_vit s s s s a - - - a s - a a - - -
ecu_variant s - - - - - - - a - - a a a a a
protocol - - - s a - - - a - - a a a a a
functional_group - - s s a - - - a - - a a a a a
cps - - - - - a a - a - - a a - - -
vit - - - - - - - - a s/a - a a - - -
ecu_config - - - - - - - s/a - - - - a a - -
flash - - - - - - - - a - - - a a - -
function_dictionary - - - - - - - - - - - a a - - -
frf-flash - - - - - - - - a - - - a a - -

Legende
- keine
a alle
s spezifisch

Grundsätzlich gilt, dass, wenn das Eingabeverzeichnis über eine index.xml verfügt oder die
Eingabe aus einem Source-PDX besteht, das eine index.xml enthält, nur Dateien für die
Erstellung des Laufzeitprojekts herangezogen werden, die in der index.xml referenziert sind.
Enthält das Eingabeverzeichnis keine index.xml, werden alle ODX-Dateien transformiert und
die resultierenden Laufzeitdatenbanken, gemäß Transformationsmodus gefiltert, zusammen
mit den in den ODX-Daten referenzierten Job-, CompuCode- und Flash-Dateien, gemäß
10 4. Bedienung V13.0.0 / 10.05.2019

Transformationsmodus gefiltert, in das Laufzeitdatenprojekt übernommen. Alle anderen

Dateien werden ignoriert.

Bei erfolgreichem Durchlauf wird ein Verzeichnis

.\<output directory>\<project name>

und wenn gewünscht das optionale Verzeichnis

.\<reduced output directory>\<project name>

angelegt, in das die resultierenden projektspezifischen Datenbankdateien gespeichert

werden.

Sollte ein Verzeichnis bereits existieren, werden zuvor alle enthaltenen Dateien gelöscht.
Datenbanken anderer Projekte sind davon nicht betroffen.

Weiter kann die Arbeitsweise und das Ergebnis eines ODX-Converter-Laufs über eine
Konfigurationsdatei gesteuert werden.
Diese Datei converter.ini befindet sich nach der Installation im selben Verzeichnis wie das
ausführbare Programm.

Auszug aus der converter.ini:

[BASICS]

# data modularization
#
# Base variants and their variants can be stored either in separate databases or
# in one common database. In case of large numbers of variants, the latter behaviour
# should be preferred to prevent the runtime system from running into problems
# due to too many file handles.
#
# 0: a base variant and the corresponding variants are stored in a common database
# 1: for each base variant and variant, an own database is created
STORE_VARIANTS_IN_SEPARATE_FILES=0

# free configurable log file extension for the active logfile(e.g. "log" instead of "lg0")
LogfileExtension=log

# alternative log directory

;LogDirectory=../log

# define, that program is executed by wine

# 0 not wine
# 1 wine
WINE=0

# to be considered in case of source PDX input

#
# 0: files of catalogue block category ODX-JOB (.jar, .class) contained in an additional
# sub-directory are stored with this sub-directory in the target project directory;
# references to those files within ODX data must contain the corresponding path
V13.0.0 / 10.05.2019 4. Bedienung 11

# 1: files of catalogue block category ODX-JOB (.jar, .class) contained in an additional

# sub-directory are stored without this sub-directory in the target project directory;
# references to those files within ODX data mustn't contain the corresponding path
#
ODXCONV_Ignore_Job_Subdir=0

# upload directory used at runtime

ODXCONV_Upload_Files_Subdir="./UploadFiles"

[REDUCED_DATA]

# parallel creation of a runtime project with reduced data

# only considered if the converter is run with the -out_reduced <out-dir> option
# 0: the corresponding data will NOT be generated into the runtime data
# 1: the data will be generated into the runtime data

LONGNAMES=0
DESCRIPTIONS=0
SDGS=0
AUDIENCES=0
OIDS=0
TEXTIDS=0

[TEXT_DATABASE]

# text database strategy

#
# The VW-MCD text database consists of four files
# - AStringData.data and AStringData.idx for ASCIISTRING text entries
# - UStringData.data and UStringData.idx for UNICODE2STRING text entries
#
# Depending on the configured behaviour it contains all strings used in one or
# more ODX projects mapped with a unique key that is used by the MCD-Kernel
# when a string is needed, e.g. if an application calls getShortName().
# The global reference text database is stored in the MCD-Kernel directory.
# Project specific text databases are stored in the project directory.
# At runtime the MCD-Kernel prefers local (project specific) text databases.
#
#
# USE_REFERENCE_DATABASE=0, ENLARGE_REFERENCE_DATABASE=0
# --> a project specific text database is created; it contains all text entries
# of the ODX files belonging to the current project
#
# USE_REFERENCE_DATABASE=0, ENLARGE_REFERENCE_DATABASE=1
# --> invalid combination
#
# USE_REFERENCE_DATABASE=1, ENLARGE_REFERENCE_DATABASE=0
# --> a global reference text database is used but not enlarged;
# that is, all text entries found during ODX file conversion are looked up
# in this global text database;
# if a text is already contained, its key is stored in the runtime database
# stream of the corresponding ODX item;
# if a text is not contained, this text is stored in the runtime database stream
# of the corresponding ODX item;
#
# USE_REFERENCE_DATABASE=1, ENLARGE_REFERENCE_DATABASE=1
# --> a global reference text database has to be used and enlarged;
# that is, all text entries found during ODX file conversion are looked up
# in this global text database;
12 4. Bedienung V13.0.0 / 10.05.2019

# if a text is already contained, its key is stored in the runtime database

# stream of the corresponding ODX item;
# if a text is not contained, a new entry in the global reference text database,
# and the new key is stored in the runtime database stream of the corresponding ODX item;

USE_REFERENCE_DATABASE=0
ENLARGE_REFERENCE_DATABASE=0

[DATA_PROPERTIES]

# Some data properties determined by authoring rules could lead to a higher performance
# if known in advance.
#
# ESD_IMPORT_ALLOWED
# 0: It is not allowed to import ECU-SHARED-DATAs by IMPORT-REF.
# Those base libraries can only be included by PARENT-REF.
# 1: It is allowed to import ECU-SHARED-DATAs by IMPORT-REF. Default behaviour.
#
# EV_IMPORT_ALLOWED
# 0: ECU-VARIANTs of the same BASE-VARIANT must not import items from each other.
# 1: ECU-VARIANTs of the same BASE-VARIANT are allowed to import items from each other.
# Default behaviour.
#
#
# ENV_DATA_DESCS_IN_ESD_ALLOWED
# 0: ECU-SHARED-DATAs must not contain ENV-DATA-DESCs.
# 1: ECU-SHARED-DATAs are allowed to contain ENV-DATA-DESCs. Default behaviour.
#
# ENV_DATA_DESCS_IN_EV_ALLOWED
# 0: ECU-VARIANTs must not contain ENV-DATA-DESCs.
# 1: ECU-VARIANTs are allowed to contain ENV-DATA-DESCs. Default behaviour.

ESD_IMPORT_ALLOWED=1
EV_IMPORT_ALLOWED=1
ENV_DATA_DESCS_IN_ESD_ALLOWED=1
ENV_DATA_DESCS_IN_EV_ALLOWED=1

[CHECKER_RULES]
# The ODX-Converter performs different data consistency checks to provide runtime databases
# usable within an MCD-Kernel runtime session.
# In some scenarios (e.g. ECU development) an ODX data project might contain errors or might
# be incomplete but shall be transformed anyway, since the application does not use the faulty
# data.
#
# IMPORTANT:
# For those scenarios it is possible to ignore certain types of errors.
# For the creation of runtime projects used in an non-experimental environment
# the default settings MUST NOT BE CHANGED!
#
# ODXCONV_CHECK_UNRESOLVED_REF
# 0: unresolved references (e.g. odxlinks) are ignored as far as possible
# 1: in case of unresolved references the runtime data project is removed (default)
#
# ODXCONV_CHECK_INVALID_BITMASK
# 0: bitmasks with invalid length are accepted
# 1: in case of invalid bitmasks the runtime data project is removed (default)
#
# ODXCONV_CHECK_NOT_UNIQUE_TROUBLE_CODE
# 0: not unique trouble codes in context of one DTC-DOP are accepted
V13.0.0 / 10.05.2019 4. Bedienung 13

# 1: in case of not unique trouble codes the runtime data project is removed (default)
#
# ODXCONV_CHECK_JAVA_COMPILE_ERROR
# 0: no error if java code cannot be compiled
# 1: a java compilation error triggers removing the runtime data project (default)
#
# ODXCONV_CHECK_MISSING_EXTERNAL_DATA
# 0: no error in case of missing external flash-, config-, or java-data files
# 1: missing external flash-, config-, or java-data files trigger removing the runtime data
# project (default)

ODXCONV_CHECK_UNRESOLVED_REF=1
ODXCONV_CHECK_INVALID_BITMASK=1
ODXCONV_CHECK_NOT_UNIQUE_TROUBLE_CODE=1
ODXCONV_CHECK_JAVA_COMPILE_ERROR=1
ODXCONV_CHECK_MISSING_EXTERNAL_DATA=1

[MULTI_CORE]
# ODXCONV_USE_CORES=0
# number of cores to use
# 0: use all available cores
# n > 0: use <n> cores
ODXCONV_USE_CORES=0

4.1 Erstellung reduzierter Laufzeitdatenprojekte

Über die Aufruf-Option –out_reduced ist es möglich, ein reduziertes Laufzeitprojekt zu

erstellen. Dazu wird in der Konfigurationsdatei eingestellt, welche Daten in dem
Laufzeitdatenprojekt nicht enthalten sein sollen.
Die entsprechende Konfiguration (siehe converter.ini) erfolgt in der Sektion
[REDUCED_DATA] und bietet die Einstellung für die ODX-Elemente

• LONG-NAMEs
• DESCs
• SDGs
• AUDIENCEs
• OIDs
• TIs

Eine 0 bedeutet, dass die entsprechenden Daten nicht in dem Laufzeitdatenprojekt enthalten
sein sollen, bei einer 1 werden sie in das Projekt übernommen.
Man beachte, dass die jeweiligen Einstellungen keinen Einfluss auf Laufzeitdatenprojekt
haben, wenn die Konvertierung ohne –out_reduced angestoßen wird.
Die Verwendung eines reduzierten Laufzeitdatenprojekts bietet sich insbesondere für den
Produktionsbereich an, wo derartige Informationen in der Regel nicht benötigt werden.

4.2 Textdatenbank

Einen Großteil des Datenvolumens eines Projektes wird bestimmt durch Texte aller Art. Um
sowohl in den Laufzeitdatenprojekten als auch zur Laufzeit Redundanzen zu vermeiden,
14 4. Bedienung V13.0.0 / 10.05.2019

werden die Texte mit einem eindeutigen Schlüssel versehen, in einer Textdatenbank
abgespeichert und von den verwendenden Stellen über diesen Schlüssel referenziert.

Bei der Erstellung dieser Textdatenbank können unterschiedliche Strategien angewendet

werden, die von der späteren Verwendung der Projekte zur Laufzeit abhängt. Die Strategie
wird in der converter.ini in der Sektion [TEXT_DATABASE] eingestellt, siehe oben.

Die Textdatenbank besteht aus vier Dateien

• AStringData.data und AStringData.idx für A_ASCIISTRING Texte

• UStringData.data und UStringData.idx für A_UNICODE2STRING Texte

Bei Verwendung einer globalen Referenztextdatenbank befinden sich diese Dateien im

MCD-Kernel-Verzeichnis.

Bei Verwendung einer projektspezifischen Textdatenbank befinden sich diese Dateien im

Projektverzeichnis.

Findet der MCD-Kernel zur Laufzeit im Projektverzeichnis eine Textdatenbank, wird diese
bedarfsgetrieben herangezogen. Die globale Referenztextdatenbank wird in diesem Fall
ignoriert. Ansonsten werden Schlüssel in der globalen Referenztextdatenbank gesucht.
Texte, die direkt in die Laufzeitdatenbanken geschrieben werden, benötigen keine
Textdatenbank.

Einstellungen:

• USE_REFERENCE_DATABASE=0, ENLARGE_REFERENCE_DATABASE=0

Der ODX-Converter erstellt eine projektspezifische Textdatenbank. Sie enthält alle ODX-
Texte, die zum aktuellen Projekt gehören. Andere Laufzeitdatenprojekte dürfen diese
Textdatenbank wegen der projektspezifischen Schlüsselvergabe nicht verwenden.

Möglicher Anwendungsfall:

Das Projekt wird stets isoliert und nicht in Kombination mit anderen Teilprojekten
verwendet.

• USE_REFERENCE_DATABASE=0, ENLARGE_REFERENCE_DATABASE=1

Diese Kombination ist eigentlich ungültig. Das Verhalten entspricht allerdings der obigen
Einstellung 0, 0.

• USE_REFERENCE_DATABASE=1, ENLARGE_REFERENCE_DATABASE=0

Eine globale Referenztextdatenbank wird beim Konvertieren genutzt, aber nicht

vergrößert. Das bedeutet, dass für alle Texte geprüft wird, ob es einen Eintrag in der
Referenztextdatenbank gibt. Wenn ja, wird der entsprechende Schlüssel in die
Laufzeitdaten übernommen. Wenn nicht, wird der Text selbst in die Laufzeitdaten
geschrieben.

Möglicher Anwendungsfall:
V13.0.0 / 10.05.2019 4. Bedienung 15

In einer Applikationsumgebung mit einem oder mehreren großen Projekten existiert

bereits eine umfassende Referenztextdatenbank, die nicht aktualisiert werden kann. Es
soll ein neues Projekt oder Teilprojekt hinzugefügt werden, beispielsweise die Bedatung
eines weiteren Steuergerätes. Dort, wo diese Bedatung konvertiert wird, liegt die
Referenztextdatenbank ebenfalls vor, so dass sie dazu genutzt werden kann, um einige
Texte in den Laufzeitdaten durch platzsparendere Schlüssel zu ersetzen. Texte, die nicht
in der Referenztextdatenbank enthalten sind, werden direkt in die Laufzeitdaten
geschrieben. Dieses neue (Teil-)Projekt ist in der Applikationsumgebung verwendbar.

• USE_REFERENCE_DATABASE=1, ENLARGE_REFERENCE_DATABASE=1

Eine globale Referenztextdatenbank wird beim Konvertieren genutzt und gegebenenfalls

vergrößert, was im initialen Fall einer Erstellung entspricht. Das bedeutet, dass für alle
Texte geprüft wird, ob es einen Eintrag in der Referenztextdatenbank gibt. Wenn ja, wird
der entsprechende Schlüssel in die Laufzeitdaten übernommen. Wenn nicht, wird ein
neuer Eintrag in der Textdatenbank erstellt und der neue Schlüssel in die Laufzeitdaten
geschrieben.

Möglicher Anwendungsfall:

Es existiert ein umfassender, einigermaßen stabiler Datenbestand, ein oder mehrere

Baureihen, der zur Erstellung einer „universellen“ Referenztextdatenbank konvertiert
wird. Diese Referenztextdatenbank wird ggfs. zusammen mit dem MCD-Kernel an die
unterschiedlichen Applikationsumgebungen verteilt. (Teil-)Projekte, die gegen diese
Referenztextdatenbank „gebaut“ werden, können also ohne die Texte verteilt werden und
sind damit in ihrem Volumen deutlich geringer, als wenn sie ihre lokale Textdatenbank
mitbrächten. Das geringere Volumen spielt für den Datenverteilprozess eine wichtige
Rolle.

4.3 Laufzeitdatenmodularisierung

In Abhängigkeit von den Eingabe-ODX-Daten und dem gewählten Transformationsmodus

erstellt der ODX-Converter unterschiedliche Arten von Laufzeitdatenbanken, deren
Ursprung, Typ und Version sich in der Namensgebung niederschlagen.

Zu jeder Laufzeitdatenbank gehören jeweils zwei Dateien, die sich bezogen auf den Namen
nur in der Endung unterscheiden. „.db“-Dateien enthalten die serialisierten und
komprimierten Laufzeitdatenströme, „.key“-Dateien die Schlüsselinformationen, mit denen
bestimmte Elemente in den .db-Dateien gefunden werden können.

Jede Laufzeitdatenbank unterliegt dem Namensschema

<Version Info>@<Base Name>.<Type>.db / .key.

Die mit <Version Info> gegebene Versionsinformation ist ab VW-MCD ODX-Converter

310.1.5 statisch mit 0.0.0 belegt und wird nur noch aus Kompatibilitätsgründen im
Dateinamen gehalten.

Altes Verhalten bis VW-MCD ODX-Converter 310.1.4 einschließlich:

16 4. Bedienung V13.0.0 / 10.05.2019

Wird beim ODX-Converterlauf über mindestens eine der Optionen –majornr, -

minornr oder –revisionnr eine Versionsinformation von außen vorgegeben, so
gilt diese für alle in diesem Converterlauf transformierten ODX-Elemente. Fehlende
Angaben werden in diesem Fall auf 0 gesetzt. Die einzelnen Angaben werden durch
einen Punkt getrennt zu einer Zeichenkette „<majornr>.<minornr>.<revisionnr>“
zusammengesetzt und zur Versionierung der Laufzeitdaten herangezogen, siehe
unten.

Wird beim ODX-Converterlauf keine der obigen Versionierungsoptionen angegeben,

so wird als Voreinstellung die Version „0.0.0“ verwendet. Diese Voreinstellung gilt für
alle in diesem Converterlauf transformierten ODX-Elemente.

Der <Base Name> und der <Type> einer Laufzeitdatenbank bedingen einander, wie aus den
nachfolgenden Tabellen hervorgeht. Die folgenden Arten von Laufzeitdatenbanken werden
unterschieden:

ECU-SHARED-DATA

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> ECU-SHARED-DATA / SHORT-NAME

<Type> sd

PROTOCOL

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> PROTOCOL / SHORT-NAME

<Type> pr

FUNCTIONAL-GROUP

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

V13.0.0 / 10.05.2019 4. Bedienung 17

<Base Name> FUNCTIONAL-GROUP / SHORT-NAME

<Type> fg

BASE-VARIANT

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> BASE-VARIANT / SHORT-NAME

<Type> bv

ECU-VARIANT

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> ECU-VARIANT / SHORT-NAME

<Type> ev

MULTIPLE-ECU-JOB

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> MULTIPLE-ECU-JOB-SPEC / SHORT-NAME

<Type> mj

FLASH

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;
18 4. Bedienung V13.0.0 / 10.05.2019

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> FLASH / SHORT-NAME

<Type> fl

ECU-CONFIG

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> ECU-CONFIG / SHORT-NAME

<Type> ec

FUNCTION-DICTIONARY

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> ECU-SHARED-DATA / SHORT-NAME

<Type> fd

VEHICLE-INFO-SPEC

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> VEHICLE-INFO-SPEC / SHORT-NAME

<Type> vi

COMPARAM-SPEC

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
V13.0.0 / 10.05.2019 4. Bedienung 19

vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> COMPARAM-SPEC / SHORT-NAME

<Type> cp

COMPARAM-SUBSET

<Version Info> 0.0.0, interpretiert als major.minor.revision, falls gegeben und nicht
über ODX-Converter-Option überschrieben; sonst wie von außen
vorgegeben;

nicht ermittelbare Angaben werden als 0 gesetzt

<Base Name> COMPARAM-SUBSET / SHORT-NAME

<Type> cs

Offensichtlich spiegeln sich die innerhalb eines Projekts verwendeten Versionsinformationen

im Namen der Laufzeitdatenbanken wider. Da der Datenbankname Teil des Schlüssels auf
die Inhalte ist, wird durch die Versionierung eine feste Kopplung zwischen den Laufzeitdaten
hergestellt, die auch der inhaltlichen Abhängigkeit entspricht. Eine ECU-SHARED-DATA-
Datenbank soll beispielsweise nicht gegen eine andere ESD-Datenbank anderen Inhalts (=
anderer Version) ausgetauscht werden, da Daten in den anderen Layerdatenbanken
abhängig vom Inhalt dieser ESD-Datenbank ist und entsprechende Elemente referenziert.
Die abhängigen Daten anderer DiagLayer müssen vielmehr gemeinsam mit diesen ESD-
Daten transformiert und versioniert werden. Durch die versionierten Datenbanken können
bestehende Abhängigkeiten zur Laufzeit identifiziert und bereits bei Projektstart überprüft
werden. Etwaige Fehler fallen also nicht erst während eines fortgeschrittenen
Applikationslaufs auf. Ohne Berücksichtigung von Versionen könnte dies nicht garantiert
werden.

4.4 Transformieren von Basisvarianten und Varianten in gemeinsame Datenbanken

Mit der Konfigurationseinstellung STORE_VARIANTS_IN_SEPARATE_FILES=0 (siehe

converter.ini) werden Basisvarianten und die jeweils zugehörigen Varianten in eine
gemeinsame Laufzeitdatenbanken transformiert. Dies bietet sich insbesondere dann an,
wenn zu einer Basisvariante sehr viele Varianten existieren, die sonst jeweils mit mindestens
zwei Dateien am Laufzeitdatenprojekt beteiligt sind. Der Nachteil besteht darin, dass bei
gemeinsamen Datenbanken zur Laufzeit keine einzelnen Varianten-Teilprojekte aktualisiert
werden können.
20 4. Bedienung V13.0.0 / 10.05.2019

4.5 Ignorieren von Job-Dateien und externen Bibliotheken

Über die Option –ignorecodefiles kann gesteuert werden, ob die in den ODX-Daten
referenzierten Job-Jars und –Classes sowie die bei LIBRARY aufgeführten Bibliotheken mit
in das Laufzeitdatenprojekt kopiert werden – Wert 1 - oder nicht – Wert 0. Da der MCD-
Kernel die Dateien erst zum Zeitpunkt der erstmaligen Verwendung benötigt, beeinflusst die
Einstellung nicht das Verhalten zur Laufzeit. Sie hat jedoch Einfluss auf die Größe des zu
verteilenden Laufzeitdatenpakets, auf die Prozesssicherheit, da bei dem Wert 0 die
Verantwortung für die Existenz der Dateien in die Laufzeit transferiert wird, auf die
Flexibilität, da bei einem Wert 1 Daten, die häufig von dritter Stelle beigestellt werden, bereits
zur Konvertierungszeit vorliegen müssen.

Die Voreinstellung lautet 0.

4.6 Ignorieren von Job-Unterverzeichnissen

Über den Konfigurationsparameter ODXCONV_Ignore_Job_Subdir kann gesteuert

werden, ob die Unterverzeichnisse von Job-Jars und Job-Klassen im Zielverzeichnis ignoriert
werden sollen – Wert 1 – oder nicht – Wert 0.

Beispiel:

In einem ABLOCK der Kategorie "ODX-JOB" sei ein Jar mit einem relativen Pfad
angegeben: "common_flash_jobs/FlashJob.jar", weil das Eingabeprojekt entsprechend
strukturiert ist.

Ist ODXCONV_Ignore_Job_Subdir auf den Wert 1 gesetzt, ignoriert der ODX-Converter

das Unterverzeichnis "common_flash_jobs" bei der Verarbeitung der Dateien unter der
Kategorie "ODX-JOB".

Ist ODXCONV_Ignore_Job_Subdir auf den Wert 0 gesetzt, berücksichtigt der ODX-

Converter das Unterverzeichnis "common_flash_jobs" bei der Verarbeitung der Dateien unter
der Kategorie "ODX-JOB". Dies ist die korrekte Vorgehensweise, die jedoch nicht zu allen im
Feld befindlichen Fahrzeugprojekten (ODX-Source-Daten) kompatibel ist.

In den ODX-Daten wird das Job-Jar mit oder ohne Angabe eines Pfades / Package
referenziert. Der ODX-Converter erwartet bei der Transformation die Jar-Daten so, wie sie in
den ODX-Daten angegeben sind.

Steht dort <CODE-FILE>common_flash_jobs/FlashJob.jar</CODE-FILE>, braucht

er im Eingabeverzeichnis das Jar im Unterordner: common_flash_jobs/FlashJob.jar.

Steht dort <CODE-FILE>FlashJob.jar</CODE-FILE>, braucht er im Eingabeverzeichnis

direkt das Jar ohne Unterordner: FlashJob.jar.

Mit ODXCONV_Ignore_Job_Subdir kann der Widerspruch zwischen Eingabe-

Projektstruktur und ODX-Daten aufgelöst werden.

Die Voreinstellung lautet 0.

V13.0.0 / 10.05.2019 4. Bedienung 21

4.7 Konvertierung von Java-Dateien

Der ODX-Converter ist neben der Konvertierung von ODX-Dateien auch für die Verarbeitung
der in diesen Dateien gegebenenfalls referenzierten Java-Jobs zuständig. Dabei wird bei
SYNTAX = JAVA Java-Quellcode kompiliert; das Resultat wird zusammen mit den anderen
referenzierten .class- oder .jar-Dateien in einem Verzeichnis Jobs unter <output
directory> abgelegt. Falls .java-Dateien referenziert werden, muss sich zur Laufzeit
des ODX-Converters ein Java-Compiler im Kommandopfad befinden.

Über die Option –classpath <classpath> müssen alle JARs und Klassen angegeben
werden, die zur Kompilation der Java-Datei erforderlich sind, insbesondere auch die zum
MCD-Kernel gehörenden JARs ASAMJavaInterfaces.jar und DAS_MCD3_Java.jar.

4.8 Anlegen eines Upload-Verzeichnisses

Über den Konfigurationsparameter ODXCONV_Upload_Files_Subdir kann das Erstellen

eines entsprechenden Unterordners im Zielverzeichnis gesteuert werden, der zur Laufzeit als
Ziel für Daten genutzt werden kann, die aus dem Steuergerät geladen werden.

Der Wert zu diesem Konfigurationsparameter ist ein relativer Pfad, dessen Bezugspunkt das
Zielverzeichnis ist. Ist der Wert leer, wird kein Unterverzeichnis erstellt.

Ist die Ausgabe des Konvertierungslaufs ein Laufzeit-PDX, so wird eine projektspezifische
Konfigurationsdatei MCD3D_CURR_PROJECT.INI erstellt, in die der Wert des
Konfigurationsparameters ODXCONV_Upload_Files_Subdir eingetragen wird.

Die Voreinstellung lautet „./UploadFiles“.

4.9 Rückgabe und Ignorieren von Konvertierungsfehlern

Der ODX-Converter erzeugt bei einem Konvertierungslauf Warnungen oder

Fehlermeldungen als Reaktion auf syntaktische oder semantische Fehler.

Das Programm liefert nach Ablauf der Konvertierung folgende Rückgaben:

• 0 (fehlerfrei)

• -1 (Warnungen vorhanden)

• -2 (Fehler aufgetreten)

Die Rückgabe 0 bedeutet, dass die Konvertierung warnungs- und fehlerfrei durchgeführt
wurde. Bei –1 sind Warnungen aufgetreten, das Konvertieren ist trotzdem fortgesetzt und
beendet worden. In diesem Fall kann das Projekt erstellt und theoretisch verwendet werden,
wobei die aufgetretenen Warnungen, aufgeführt in der Log-Datei, analysiert und bewertet
werden sollten. Die Rückgabe –2 weist auf gravierende Fehler hin, die vom ODX-Converter
nicht ignoriert werden können. In diesem Fall bricht die Konvertierung ab und kann nicht
beendet werden.
22 4. Bedienung V13.0.0 / 10.05.2019

Bei Fehlern oder Warnungen werden aus Sicherheitsgründen keine Laufzeitdatenbanken

erstellt. In Testumgebungen kann es jedoch sinnvoll sein, auch mit Warnungen behafteten
Datenbanken zu arbeiten. Zu diesem Zweck ist die Option –ignoreerror eingeführt
worden, über die das gewünschte Verhalten gesteuert werden kann. Die Voreinstellung
lautet –ignoreerror 0; Fehler und Warnungen werden in diesem Fall nicht ignoriert, und
die Laufzeitdatenbanken werden bei aufgetretenen Problemen gelöscht.

Man beachte, dass bei schwerwiegenden Fehlern, also solchen, die mit einem
Rückgabewert –2 quittiert werden, auch bei -ignoreerror 1 keine Laufzeitdatenbanken
erstellt werden, da der Konvertierungslauf nicht ordnungsgemäß beendet werden kann.

4.10 Überschreiben von ODX-Daten zur Converter-Laufzeit

Für sehr spezielle Anwendungsfälle bietet der ODX-Converter die Möglichkeit, gewisse
ODX-Daten aus dem Flash-Kontext durch Werte aus einer externen Datei meta_data.xml zu
überschreiben.
Die Struktur der meta_data.xml Datei ist über das Schema metadata.xsd definiert (Version
1.0).

Momentan können folgende ODX-Elemente überschrieben werden:

• PARTNUMBER von SESSION-DESC

• SECURITY von DATABLOCK

o SECURITY-METHOD

o FW-SIGNATURE

o FW-CHECKSUM

o VALIDITY-FOR

Anhand der angegebenen Shortnames von ECU-MEM-CONNECTOR, SESSION-DESC und

DATABLOCK können die zu überschreibenden Elemente eindeutig identifiziert werden.

Beispiel für meta_data.xml:

<?xml version="1.0" encoding="UTF-8"?>
<META-DATA xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="metadata.xsd">
<ECU-MEM-CONNECTORS>
<ECU-MEM-CONNECTOR>
<SHORT-NAME>EMC_A</SHORT-NAME>
<SESSION-DESCS>
<SESSION-DESC>
<SHORT-NAME>SESSION_DESC_A1</SHORT-NAME>
<PARTNUMBER>1234567890</PARTNUMBER>
<DATABLOCKS>
<DATABLOCK>
<SHORT-NAME>DATABLOCK_1</SHORT-NAME>
<SECURITY>
<SECURITY-METHOD>11</SECURITY-METHOD>
<FW-SIGNATURE TYPE="A_BYTEFIELD">22</FW-SIGNATURE>
</SECURITY>
V13.0.0 / 10.05.2019 4. Bedienung 23

</DATABLOCK>
<DATABLOCK>
<SHORT-NAME>DATABLOCK_2</SHORT-NAME>
<SECURITY>
<SECURITY-METHOD TYPE="A_UINT32">11</SECURITY-METHOD>
<FW-SIGNATURE>new_SIGNATURE</FW-SIGNATURE>
<FW-CHECKSUM TYPE="A_UINT32">33</FW-CHECKSUM>
<VALIDITY-FOR>new_VALIDITY</VALIDITY-FOR>
</SECURITY>
</DATABLOCK>
</DATABLOCKS>
</SESSION-DESC>
<SESSION-DESC>
<SHORT-NAME>SESSION_DESC_A2</SHORT-NAME>
<PARTNUMBER>new_A2</PARTNUMBER>
</SESSION-DESC>
</SESSION-DESCS>
</ECU-MEM-CONNECTOR>
<ECU-MEM-CONNECTOR>
<SHORT-NAME>EMC_B</SHORT-NAME>
<SESSION-DESCS>
<SESSION-DESC>
<SHORT-NAME>SESSION_DESC_B1</SHORT-NAME>
<DATABLOCKS>
<DATABLOCK>
<SHORT-NAME>DATABLOCK_1</SHORT-NAME>
<SECURITY>
<FW-CHECKSUM>77</FW-CHECKSUM>
<VALIDITY-FOR TYPE="A_BYTEFIELD">88</VALIDITY-FOR>
</SECURITY>
</DATABLOCK>
</DATABLOCKS>
</SESSION-DESC>
</SESSION-DESCS>
</ECU-MEM-CONNECTOR>
</ECU-MEM-CONNECTORS>
</META-DATA>

4.11 Optimierter Transformationslauf in Abhängigkeit von Bedatungsrichtlinien

Über die Konfigurationseinstellungen ESD_IMPORT_ALLOWED, EV_IMPORT_ALLOWED,

ENV_DATA_DESCS_IN_ESD_ALLOWED und ENV_DATA_DESCS_IN_EV_ALLOWED in
der Sektion [DATA_PROPERTIES] der converter.ini können dem ODX-Converter Hinweise
zur zugrunde liegenden Datenstruktur gegeben werden, die für einen performanteren
Transformationslauf genutzt werden können.

Wird über Bedatungsrichtlinien ausgeschlossen, dass ECU-SHARED-DATAs über eine

IMPORT-REF in andere ODX DIAG-LAYER integriert werden können, kann
ESD_IMPORT_ALLOWED auf 0 gesetzt werden.

Wird über Bedatungsrichtlinien ausgeschlossen, dass ECU-VARIANTs zu einer

gemeinsamen BASE-VARIANT voneinander importieren können, kann
EV_IMPORT_ALLOWED auf 0 gesetzt werden.
24 4. Bedienung V13.0.0 / 10.05.2019

Wird über Bedatungsrichtlinien ausgeschlossen, dass ENV-DATA-DESCs in ECU-SHARED-

DATAs definiert sein können, kann ENV_DATA_DESCS_IN_ESD_ALLOWED auf 0 gesetzt
werden.

Wird über Bedatungsrichtlinien ausgeschlossen, dass ENV-DATA-DESCs in ECU-

VARIANTs definiert sein können, kann ENV_DATA_DESCS_IN_EV_ALLOWED auf 0
gesetzt werden.

4.12 Steuerung der Fehlertoleranz

Bei der Verarbeitung von ODX-Projekten nimmt der ODX-Converter syntaktische und
semantische Überprüfungen vor, um inkonsistente Laufzeitdaten zu vermeiden, die bei der
Verwendung durch den MCD-Kernel zu Problemen führen können.

Nicht alle Fehlerfälle können zur Transformationszeit identifiziert werden, da einige

Referenzen erst zur Laufzeit im jeweiligen Kontext aufgelöst werden können.

Grundsätzlich werden im vom ODX-Converter identifizierten Fehlerfall keine

Laufzeitdatenbanken erstellt. Für bestimmte Anwendungsfälle kann jedoch eine größere
Fehlertoleranz sinnvoll und gewünscht sein, beispielsweise in der Entwicklung.

Der ODX-Converter unterscheidet zurzeit zwölf Fehlerkategorien, von denen sechs per
Konfiguration toleriert werden können. Die Konfiguration findet in der converter.ini in der
Sektion [CHECKER_RULES] statt (siehe oben).

Fehlerkategorie Bedeutung Konfigurierbarkeit / Parameter

Internal error Fehler im nein
Programmablauf

Invalid ODX data syntax Syntax der ODX-Daten ist nein

nicht schemakonform

Unresolved reference odxlink nicht im jeweiligen ja

Gültigkeitsbereich
ODXCONV_CHECK_UNRESOLVED_REF
auflösbar

Invalid BIT-MASK Länge einer Bitmaske ja

nicht passend zur Länge
ODXCONV_CHECK_INVALID_BITMASK
des zu maskierenden
Parameterwertes

Not unique TROUBLE- Vorkommen von DTCs ja

CODE mit gleichem Trouble
ODXCONV_CHECK_NOT_UNIQUE_TROUBLE_CODE
Code innerhalb eines
DTC-DOPs

Duplicated SHORT- Unzuässiges Vorkommen nein

NAME von gleichartigen ODX-
Elementen mit demselben
SHORT-NAME im
Gültigkeitsbereich
V13.0.0 / 10.05.2019 4. Bedienung 25

Invalid ODX data Fehlen von ODX-Dateien, nein

die in einer zum ODX-
Projekt gehörenden
index.xml referenziert
werden

Java compile error In ODX-Dateien ja

referenzierter Java-Code
ODXCONV_CHECK_JAVA_COMPILE_ERROR
kann nicht kompiliert
werden

Missing ODX files Fehlen von referenzierten ja

externen Java-, Flash-
ODXCONV_CHECK_MISSING_EXTERNAL_DATA
oder Config-Dateien, die
nicht als „LATEBOUND“
deklariert sind

Converter usage error Fehlbenutzung des ODX- nein

Converters

DB write failure Fehler beim Schreiben nein

von Objekten in die
Laufzeitdatenbank

Not specified error Unspezifierter Fehler; nein

entweder eine
Zusammenfassung obiger
Fehler oder unerwartete
Ausnahme

Das Converter-Aufrufargument „-ignoreerror 1“ hat denselben Effekt wie das Abstellen aller
konfigurierbaren Fehlerprüfungen und wird vorrangig gegenüber den Werten in der
Konfigurationsdatei betrachtet.

Man beachte, dass das Ignorieren von Transformationsfehlern nur zu Testzwecken

eingestellt werden darf. Produktive Laufzeitdaten müssen zwingend mit der Default-
Konfiguration transformiert werden, bei denen im Fehlerfall keine Laufzeitdaten erstellt
werden.
26 5. ODX-Standard übergreifende Datenprojekte V13.0.0 / 10.05.2019

5 ODX-Standard übergreifende Datenprojekte

Der ODX-Converter verarbeitet ODX 2.0.1-, ODX 2.1- und ODX 2.2-Daten und transformiert
diese in ein vom ODX-Standard unabhängiges Laufzeitdatenformat. Unter Berücksichtigung
gewisser Randbedingungen kann ein ODX-Datenprojekt ODX-Dateien unterschiedlicher
Standardversionen beinhalten. Auch können zur Laufzeit Teilprojekte zu einem
übergreifenden Laufzeitdatenprojekt kombiniert werden, die auf ODX-Daten
unterschiedlicher Standardversionen beruhen.

Die Randbedingungen sind in beiden Fällen dieselben:

a) Wie bei homogenen Datenprojekten gilt, dass Referenzen auf andere Elemente auflösbar
sein müssen. Hat also auf ODX-Ebene beispielsweise eine BASE-VARIANT eine
PARENT-REF auf ein PROTOCOL, so ist es unerheblich, ob die BASE-VARIANT dem
ODX 2.0.1- oder ODX 2.2-Schema entspricht und ob dieses Schema auch dem
PROTOCOL zugrunde liegt. Maßgeblich ist, dass das Ziel von der Quelle aus erreichbar
ist.

b) Wenn eine COMPARAM-SPEC nach ODX 2.0.1 verwendet wird, sollte das PROTOCOL
ebenfalls nach ODX 2.0.1 definiert sein, da es andernfalls keine Möglichkeit gibt, den zur
Laufzeit erforderlichen PROTOCOL-TYPE zu bedaten. Hintergrund: In ODX 2.2 und
ODX 2.1 wird diese Information nicht mehr am PROTOCOL, sondern als PDU-
PROTOCOL-TYPE am PROT-STACK definiert, ein Element, das es in ODX 2.0.1 nicht
gibt.

c) Kombiniert man eine COMPARAM-SPEC nach ODX 2.1 oder ODX 2.2 und ein
PROTOCOL nach ODX 2.0.1 mit einer VEHICLE-INFO-SPEC nach ODX 2.1 oder ODX
2.2, müssen die LOGICAL-LINKs der VEHICLE-INFO-SPEC die PROT-STACK-SNREF
enthalten, da die andere Möglichkeit, diese erforderliche Referenz einzutragen, nur für
PROTOCOLs nach ODX 2.1 oder ODX 2.2 gegeben ist, nicht aber für PROTOCOLs
nach ODX 2.0.1.

d) Daraus ergibt sich, dass eine Kombination aus COMPARAM-SPEC nach ODX 2.1 oder
ODX 2.2 mit einem PROTOCOL nach ODX 2.0.1 und einer VEHICLE-INFO-SPEC nach
ODX 2.0.1 mangels Angabe einer PROT-STACK-SNREF nicht zulässig ist.

An diesen Beispielen wird deutlich, dass die Restriktionen eher theoretischer Natur sind. Der
typische Anwendungsfall für den gleichzeitigen Einsatz unterschiedlicher ODX-
Standardversionen wird sein, dass die Kernbedatung (COMPARAM-SPEC und der
überwiegende Teil von Steuergerätebedatungen) auf ODX 2.2 beruht und einzelne „alte“
Steuergerätebedatungen nach ODX 2.0.1 hinzugenommen werden. In diesem Szenario
muss lediglich in der VEHICLE-INFO-SPEC dafür Sorge getragen werden, dass die
Bedingung c) erfüllt wird.
V13.0.0 / 10.05.2019 6. Systemanforderungen 27

6 Systemanforderungen

6.1 Betriebssysteme

Der ODX-Converter ist als 32-Bit Applikation sowohl auf Windows XP als auch Windows 7
32 / 64 Bit lauffähig.

Die 64-Bit Applikation ist unter Windows 7 und 10 64-Bit lauffähig.

Für Linux-Systeme gibt es RPM-Pakete oder TGZs für spezielle Linux-Distributionen:

Distribution Basis Linux-Kernel gcc rpm / Prozessor- 32/64 Bit

TGZ Architektur

elina Yocto V2.0 4.1.15 5.2.0 tgz ARMv7 32

SLES 11 openSUSE 3.0.93 4.3 rpm / tgz AMD64 64

11.x

RHEL7 Fedora19/20 3.10.0 4.8.5 rpm / tgz AMD64 64

6.2 Minimale Hardwareausstattung

• Prozessortyp: Intel Pentium-M 1.4GHz oder kompatibel

möglicherweise auf älteren Systemen - ungetestet

• RAM: 512 MB, abhängig von Anwendungsfall und Projektdatengröße

• Festplattenspeicher: 512 MB, abhängig von Anwendungsfall und Projektdatengröße

6.3 Datengetriebene Restriktionen

Der für den ODX-Converter-Prozess verfügbare Hauptspeicher ist in Abhängigkeit von der
Systemausstattung beschränkt. Wenn der Hauptspeicherbedarf diese Grenze während eines
Transformationslaufs überschreitet, ist eine weitere ordnungsgemäße Datenkonvertierung
nicht mehr möglich, und der Transformatorlauf bricht mit einer entsprechenden
Fehlermeldung ab.

Bei einer 32-Bit Applikation auf einem Windows-System liegt die kritische Grenze in der
Regel bei ca. 2 GB Hauptspeicherbedarf für den Konvertierungsprozess.

Der Speicherbedarf eines Transformationslaufs ergibt sich aus dem Inhalt und der Struktur
der zu konvertierenden Daten und kann daher nicht vorhergesagt werden. Da die in den
ODX-Daten enthaltenen Informationen für die Verwendung zur Laufzeit optimal aufbereitet
werden müssen, benötigt der Transformationslauf zeitweise deutlich mehr MB
Hauptspeicher, als die Größe der jeweils verarbeiteten ODX-Daten beträgt. Das frühzeitige
Entladen nicht mehr benötigter Informationen sorgt jedoch für problemlose und schnelle
Verarbeitung aller zum jetzigen Zeitpunkt existierenden Fahrzeugprojekte.
28 6. Systemanforderungen V13.0.0 / 10.05.2019

Da weiterhin mit einer deutlichen Vergrößerung der ODX-Fahrzeugprojekte zu rechnen ist,

werden im Folgenden die wesentlichen Faktoren genannt, die zu einem hohen
Hauptspeicherbedarf zur Transformationszeit führen:

Prinzipiell sind stets solche ODX-Daten als kritisch zu erachten, bei denen die Bedatung
eines einzelnen Layers, z.B. einer einzelnen Basisvariante, bereits mehrere hundert MB groß
ist, da der ODX-Converter steuergeräteweise arbeitet und bestimmte Teile der aufbereiteten
Daten einer Basisvariante zusammen mit denen der zugehörigen Varianten und den
referenzierten Protokollen, Funktionalen Gruppen und Shared-Datas im Speicher hält.
Entsprechend kann man in einen kritischen Speicherbedarf gelangen, wenn zu einer
Basisvariante mehrere hundert (> 750) Varianten mit vielen echt neuen Daten existieren.
Speicherintensive Daten sind in der Regel die mit großem Textanteil, also zum Beispiel
Special Data Groups.

Eine Restriktion mit Rückschluss auf die ODX-Daten ergibt sich durch die MCD-3D API, die
auch im Flashkontext nicht beliebige Datengrößen unterstützt. Als Start- und Endadresse
eines Flashsegments ist der Datentyp A_UINT32 vorgesehen. Es muss also sicher gestellt
werden, dass die zu einem einzelnen Flashsegment gehörenden Daten diesen Umfang (~ 4
GB) nicht überschreiten. Dies gilt auch für externe Flashdaten.

Eine für das Laufzeitsystem relevante Randbedingung ist an die Anzahl der ODX-Kategorien
und DIAG-LAYER im Projekt geknüpft. In Abhängigkeit von der Konfiguration des ODX-
Converters wird je Kategorie bzw. Layer eine Laufzeitdatenbank bestehend aus zwei Dateien
erstellt. Zur Laufzeit werden diese Dateien bedarfsweise nach und nach geöffnet und nach
der Projektinitialisierung offen gehalten, um die Ausführungsgeschwindigkeit auch in
„multithreaded“ Applikationen hoch zu halten. Sollten die ODX-Kategorien und DIAG-LAYER
SDGs enthalten, so werden hierfür wegen gesonderter Verwaltung zwei weitere
Laufzeitdatenbankdateien angelegt.

Zu beachten ist, dass Dateihandles eine limitierte Systemressource darstellen; auf Windows-
Systemen beträgt die maximale Anzahl 2048 pro Prozess.

Sollte ein Projekt mehr als 1024 ODX-Kategorien und Layer umfassen, kann das Problem
dadurch drastisch entschärft werden, dass eine Basisvariante zusammen mit allen ihren
Varianten per Konfiguration in eine einzige Laufzeitdatenbank (= zwei Dateien) geschrieben
werden kann. Wenn zu einer Basisvariante also 100 Varianten gehören, werden nur zwei
statt 202 Dateihandles benötigt – zuzüglich etwaiger SDG-Dateihandles.

Besteht das Projekt jedoch aus mehreren hundert Basisvarianten, Protokollen, Funktionalen
Gruppen, Basisbibliotheken zuzüglich ECU-Config und Flash pro Steuergerät, kann die
kritische Grenze von 1024 Laufzeitdatenbanken auch bei zusammengefassen BV- und EV-
Datenbanken erreicht werden.

Für den Einsatz des ODX-Converters auf ressourcenlimitierten Systemen ist zu beachten,
dass bei der Konvertierung sehr großer Projekte auch sehr große Einzeldateien entstehen
können, z.B. Textdatenbanken (AstringData.* / UstringData.*) mit Dateigrößen über 256 MB.
V13.0.0 / 10.05.2019 7. Installation 29

7 Installation

Der ODX-Converter wird durch Aufruf des Setups

SetupVWMCD_Converter_32_V<version>.exe

als 32 Bit Applikation oder durch Aufruf des Setups

SetupVWMCD_Converter_64_V<version>.exe

als 64 Bit Applikation installiert.

Alternativ kann dieses Setup auch über das übergeordnete Setup

SetupVWMCD_32_V<version>.exe

beziehungsweise

SetupVWMCD_64_V<version>.exe

aktiviert werden.

Zur Integration in übergeordnete Setups ist für das Einzelsetup auch ein sogenannter
„silent“-Modus wählbar:

SetupVWMCD_Converter_32 _V<version>.exe /verysilent /suppressmsgboxes

Optional kann mit

/dir <Installationspfad>

der Pfad auf das gewünschte Installationsverzeichnis angegeben werden.

Fehlt der Parameter, wird das zuletzt gewählte Installationsverzeichnis bzw. bei
Erstinstallation das Verzeichnis C:/%ProgramFiles%/Volkswagen/VW-MCD angenommen.

Optional kann mit

/confdir <Konfigurationspfad>

der Pfad auf das gewünschte Konfigurationsverzeichnis angegeben werden.

Fehlt der Parameter, wird das zuletzt gewählte Konfigurationsverzeichnis bzw. bei
Erstinstallation das Verzeichnis C:/ %ProgramFiles%//Volkswagen/VW-MCD (WinXP) oder
C:/users/public/Volkswagen/VW-MCD/config angenommen.

Standardmäßig werden bestehende Installationen im selben Zielverzeichnis nicht

überschrieben. Durch Angabe von

/overwrite

kann das Verhalten geändert werden.

Standardmäßig werden bei der Installation Startmenüeinträge erstellt. Durch Angabe von

/NOICONS
30 8. Hinweis auf Fremdkomponenten V13.0.0 / 10.05.2019

kann das Erstellen von Startmenüeinträgen verhindert werden.

Standardmäßig werden bei der Installation die Umgebungsvariablen VW_MCD_HOME und

VW_MCD_CONFIG gesetzt. Durch die Angabe von

/nosetenv

kann das Setzen der Umgebungsvariablen verhindert werden.

8 Hinweis auf Fremdkomponenten

Der ODX-Converter nutzt folgende OSS-Komponenten:

• boost*.dll; V 1.57

• expat_vc120.dll; V 2.0.1

• libxml2_vc120.dll; V 2.9.1

• zlib1.dll; V 1.2.6

• google sparse hash; V 1.4.2

• pbl; V 1.03

• loki; 2003_04_13

Der ODX-Converter nutzt folgende Fremd-Komponenten:

• ZipArchive; V 4.1.2

• LtXmlLib15_vc120_xp.dll; V 15.1.0.7451