VW-MCD MCDKernel

V 14.0.0 - Stand: 31.10.
2019
VW-MCD
MCD-Kernel
Implementierung des Standards ASAM MCD-3D 3.0.0
Installation, Konfiguration, Betrieb
Druckdatum: 31.10.19 File: VW-MCD_MCDKernel.doc

2 V14.0.0 / 31.10.2019
V14.0.0 / 31.10.2019 3
Inhaltsverzeichnis
1 Übersicht VW-MCD ....................................................................................... 7
2 Übersicht MCD-Kernel ................................................................................ 10
3 Basiskonfiguration ..................................................................................... 11
3.1 MCD3D_SERVER.INI ............................................................................................. 11
3.2 MCD3D_PROJECTS.INI ........................................................................................ 17
3.3 MCD3D_CURR_PROJECT.INI............................................................................... 19
3.4 TESTERID.INI ........................................................................................................ 19
4 Jobdatenkonfiguration ............................................................................... 20
4.1 Problemstellung ...................................................................................................... 20
4.2 Möglichkeit zur Konfiguration des MCD-Kernels bezüglich Job-Ausführung .......... 20
4.2.1 Inhalt der Konfigurationsdateien .................................................................... 20
5 Flashdatenkonfiguration ............................................................................ 26
5.1 Late-bound-Mechanismus ...................................................................................... 26
5.2 Umsetzung im MCD-Kernel .................................................................................... 27
5.2.1 Gundsätzlicher Algorithmus zum Auffinden von Flashdaten ....................... 27
5.2.2 Spezialitäten hinsichtlich Latebound-Dateien................................................ 29
5.3 Flashdatenablage ................................................................................................... 32
5.3.1 Das Flashdatenunterverzeichnis..................................................................... 32
5.3.2 Ablagemöglichkeiten ....................................................................................... 32
5.4 Anwendung............................................................................................................. 32
5.5 Alternatives Flashprojektverzeichnis ....................................................................... 33
6 Textdatenbanken ........................................................................................ 34
7 Logging und Tracing .................................................................................. 36
8 Fehlerbehandlung ....................................................................................... 39
8.1 Standardisierte Fehlertexte ..................................................................................... 39

4 V14.0.0 / 31.10.2019
8.2 Herstellerspezifische Fehlertexte ............................................................................ 42
9 VIT-Generierung .......................................................................................... 56
9.1 Default-VIT ............................................................................................................. 56
9.1.1 Motivation ......................................................................................................... 56
9.1.2 Voraussetzungen ............................................................................................. 56
9.1.3 Vorgehensweise ............................................................................................... 61
9.2 Smart-VIT ............................................................................................................... 61
9.2.1 Motivation ......................................................................................................... 61
9.2.2 Voraussetzungen ............................................................................................. 62
9.2.3 Vorgehensweise ............................................................................................... 62
10 Schnittstellen .............................................................................................. 64
10.1 C++ ........................................................................................................................ 64
10.2 Java ........................................................................................................................ 64
10.3 DCOM .................................................................................................................... 64
11 Abweichungen von ASAM MCD-3D 3.0.0 .................................................. 65
11.1 Nicht vollständig standardkonform implementierbare Funktionalitäten .................... 65
11.2 Bewusst abweichend vom Standard implementierte Funktionalitäten ..................... 66
11.3 Nicht oder nicht vollständig implementierte Funktionalitäten ................................... 70
11.3.1 Überschreiben komplexer Kommunikationsparameter ................................. 70
11.3.2 Festlegung des PROT-STACKs ....................................................................... 71
11.3.3 Nutzung der C++ Schnittstelle ........................................................................ 71
11.4 Proprietäre Erweiterungen ...................................................................................... 73
11.4.1 Iteration über Flashdaten................................................................................. 73
11.4.2 Late-bound-Flashdaten .................................................................................... 74
11.4.3 Zugriff auf Flash-Securities ............................................................................. 75
11.4.4 Zugriff auf Flash-Job........................................................................................ 75
11.4.5 Erzeugen eines MCDValue-Elements ............................................................. 76
11.4.6 Zugriff auf Semantic-Attribute an SubComponents ...................................... 77
11.4.7 PDU-Timestamps ............................................................................................. 77

V14.0.0 / 31.10.2019 5
11.4.8 Abfrage des Text-Table-Elements am MCDParameter .................................. 78
11.4.9 Abfrage des Compu-Default-Value ................................................................. 78
11.4.10 Laden und Löschen von Teilprojekten im laufenden Betrieb ....................... 79
11.4.11 System-Properties ........................................................................................... 83
11.4.12 Abfrage installierter PDU-APIs ........................................................................ 85
11.4.13 Verhalten der addMuxBranch(...)-Methoden................................................... 86
11.4.14 „Suppress Positive Response“ für ODX 2.0.1 basierte Datenprojekte......... 86
11.4.15 MCDInterface::getModuleTypeName_NSF ..................................................... 87
11.4.16 MCDDbODXFile, MCDDbODXFiles .................................................................. 87
11.4.17 Unterstützung komplexer Kommunikationsparameter ................................. 88
11.4.18 MCDParameter::getUnitTextID_NSF ............................................................... 90
11.4.19 MCDDiagComPrimitive::cancel ....................................................................... 90
11.4.20 Simulationsmodus ........................................................................................... 90
11.4.21 Laden von MCD-Kernel DLLs .......................................................................... 95
11.4.22 Reaktion auf TCP-Verbindungsverlust ........................................................... 95
11.4.23 Erweiterte Parameterinformationen ................................................................ 96
11.4.24 Proprietäre Bibliothek zur Einheitenumrechnung ....................................... 108
11.4.25 Abfrage von Preconditions an Table-Rows .................................................. 113
11.4.26 MCDLogicalLink::isComParamSupportedByInterface_NSF ....................... 114
11.4.27 Verhalten von setSuppressPositiveResponse ............................................. 115
11.4.28 Zugriff auf am Service überschriebene Kommunikationsparameter .......... 118
12 Systemanforderungen .............................................................................. 120
12.1 Betriebssysteme ................................................................................................... 120
12.2 Minimale Hardwareausstattung............................................................................. 120
12.3 Daten- und applikationsgetriebene Restriktionen .................................................. 120
12.3.1 Anzahl der Laufzeitdatenbanken................................................................... 120
12.3.2 Volumen geladener DB-Objekte .................................................................... 121
12.3.3 Größe von Flashdateien ................................................................................ 122
12.4 C++ Entwicklungsumgebung ................................................................................ 122
13 Lizenzierung .............................................................................................. 122

6 V14.0.0 / 31.10.2019
13.1 Applikationskopplung ............................................................................................ 122
13.1.1 Details .............................................................................................................. 123
13.1.2 Randbedingungen ............................................................................................ 125
14 Installation für Windows .......................................................................... 125
14.1 Windows 7 Unterstützung ..................................................................................... 128
15 Hinweis auf Fremdkomponenten............................................................. 130
16 Sonstige Hinweise .................................................................................... 131

V14.0.0 / 31.10.2019 1. Übersicht VW-MCD 7
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)
Applications
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

8 1. Übersicht VW-MCD V14.0.0 / 31.10.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.
Details zur Anbindung von VCIs an den MCD-Kernel können der folgenden Darstellung
entnommen werden:
Applications
C++ Java DCom
ISO 22900-3 MCD-3D Interface
DB
Connector
MCD-Kernel
ISO 22900-2 D-PDU-API
XOR
D-PDU-API D-PDU-API
Library Library
TCP
PDU-Daemon VCI
TCP
CANcaseXL /CANcardXL(e)
Abbildung 2. Software-Architektur Fahrzeugdiagnose über VW-MCD

V14.0.0 / 31.10.2019 1. Übersicht VW-MCD 9
Die standardisierte MCD3D-API des MCD-Kernels kann wahlweise über einen Java-Client,
einen DCom-Client oder einen C++-Client betrieben werden. Der MCD-Kernel muss mit
einer ISO22900-2-konformen PDU-API-Implementierung verwendet werden, die über ein
herstellerspezifisches VCI oder auch einem PDU-Daemon mit dem Fahrzeug kommuniziert.
Der PDU-Daemon ist eine VCI-Implementierung, die auf einem Windows-PC läuft und als
CAN-Interface eine CANcardXL, CANCardXLe oder ein CANcaseXL der Firma Vector
Informatik verwendet.
Gegenstand dieser Dokumentation ist der MCD-Kernel.

10 2. Übersicht MCD-Kernel V14.0.0 / 31.10.2019
2 Übersicht MCD-Kernel
Der MCD-Kernel in der vorliegenden Version ist die Weiterentwicklung einer

Implementierung des Standards ASAM MCD3-D 2.00.02 mit diversen Erweiterungen als
Vorgriff auf ASAM MCD3-D 2.1.
Die Implementierung des MCD-Kernels entspricht weitgehend dem verabschiedeten ASAM

MCD 3.0.0 Standard bzw. der ISO-Norm 22900-3. Aktuelle Abweichungen aufgrund von
Kompatibilitätsanforderungen, technischen Restriktionen oder über den Standard
hinausgehende Anforderungen sind im Kapitel 11 aufgeführt.
V14.0.0 / 31.10.2019 3. Basiskonfiguration 11
3 Basiskonfiguration
Der MCD-Kernel kann über vier Konfigurationsdateien parametriert werden. Die zwei
Dateien MCD3D_SERVER.INI und MCD3D_PROJECTS.INI werden zur Laufzeit in dem
durch die Umgebungsvariable VW_MCD_CONFIG (Windows 7/10 Installation) bzw.
VW_MCD_HOME (Windows XP Installation) angegebenen Verzeichnis oder, falls die
Umgebungsvariable nicht gesetzt ist, im aktuellen Arbeitsverzeichnis gesucht.
Man beachte: Wird die Umgebungsvariable VW_MCD_CONFIG unter Windows XP

unabhängig vom Setup händisch oder von der verwendenden Applikation gesetzt, wird diese
Umgebungsvariable zuerst herangezogen und VW_MCD_HOME zum Auffinden der
Konfigurationsdateien ignoriert.
Die optionale Konfigurationsdatei MCD3D_CURR_PROJECT.INI ist laufzeitprojektspezifisch

und wird im aktuellen Projektverzeichnis angenommen, also dort, wo auch die
Laufzeitdatenbanken zu finden sind. Die optionale TESTERID.INI enthält verschlüsselt die
Tester-Id des Testers. Der Zugriff auf den Wert der Tester-Id kann über das Auslesen des
SYSTEM-Parameters „TESTERID“ erfolgen, sofern ein solcher in den ODX-Daten
bereitgestellt worden ist.
Grundsätzlich gilt, dass Modifikationen an den Konfigurationsparametern mit Bedacht

durchgeführt werden müssen, da fehlerhafte Einträge den Betrieb des MCD-Kernels
erheblich stören können.
3.1 MCD3D_SERVER.INI
In dieser Datei werden die Basiseinstellungen für den Betrieb des MCD-Kernels
vorgenommen. Sie wird einmalig bei Programmstart geladen. Die Bedeutung der Parameter
entnehme man der nachfolgenden Tabelle:
Parameter Bedeutung
MCD3D_MVCI_PDU_API_RDF_FILE Pfad und Name zu einer alternativen RDF-Datei, die den

entsprechenden „D-PDU API“ Eintrag in der Windows-
Registrierung überschreibt
aktuell deaktiviert
MCD3D_MVCI_PDU_API_Shortname Ausgewählter PDU-API-Eintrag aus der RDF-Datei
aktueller Wert: D_PDU_API_xxx
MCD3D_MVCI_PDU_API_OPTION_STRING Optionale Zeichenkette (max. 1024 Zeichen) zur Konfiguration

der D-PDU API über PDUConstruct, muss zur verwendeten
D-PDU-API passen
aktuell deaktiviert, entspricht Voreinstellung „“

12 3. Basiskonfiguration V14.0.0 / 31.10.2019
Parameter Bedeutung
MCD3D_SuppressPduApiConfigPathTransfer Einstellung hinsichtlich des Übertragens des

Konfigurationsverzeichnispfades an eine herstellerspezifische
D-PDU-API
Wert 0: Konfigurationsverzeichnispfad wird übertragen

und wird somit von der D-PDU-API genutzt,
um die eigenen Konfigurationsdateien zu suchen
Wert 1: Konfigurationsverzeichnispfad wird nicht

übertragen; damit erwartet die D-PDU-API
die Konfigurationsdatei im selben Verzeichnis,
in dem auch die Bibliothek selbst liegt
aktueller Wert: 0 (Voreinstellung)
MCD3D_CONSTRAINT_CHECK Berücksichtigung von Scale Constraints bzgl. Gültigkeit von

Parameterwerten in Kombination mit ODX 2.0.1:
Wert 0: Scale-Constraints beeinflussen nicht die

Gültigkeit eines Parameterwertes
Wert 1: Scale-Constraints beeinflussen die Gültigkeit

eines Parameterwertes. Werte in Constraint-
Intervallen != VALID sind ungültig.
MCD3D_CONSTRAINT_CHECK_ODX_21_22 Berücksichtigung von Scale Constraints bzgl. Gültigkeit von

Parameterwerten in Kombination mit ODX 2.1 und ODX 2.2:
Wert 0: Scale-Constraints beeinflussen nicht die

Gültigkeit eines Parameterwertes
Wert 1: Scale-Constraints beeinflussen die Gültigkeit

eines Parameterwertes. Werte in Constraint-
Intervallen != VALID sind ungültig.
MCD3D_LogLevel Globaler Log-Level für das MCD-System ohne PDU
mögliche Einstellungen sind im Kapitel Logging & Tracing

beschrieben

Parameter Bedeutung
MCD3D_LogLevel_DB Log-Level für bereichsweises Logging im MCD-System;
MCD3D_LogLevel_DB_LOAD Die Einträge überschreiben den Wert des mit

MCD3D_LogLevel eingestellten globalen Log-Levels
MCD3D_LogLevel_DB_CALC
MCD3D_LogLevel_DB_FLASH
beschrieben
MCD3D_LogLevel_DB_ECU_CONFIG
aktuell deaktiviert
MCD3D_LogLevel_DB_EPI
MCD3D_LogLevel_DB_FD
MCD3D_LogLevel_RT
MCD3D_LogLevel_RT_LINK
MCD3D_LogLevel_RT_SERVICE
MCD3D_LogLevel_RT_PARAM
MCD3D_LogLevel_RT_ECU_CONFIG
MCD3D_LogLevel_RT_VI
MCD3D_LogLevel_RT_JOB
MCD3D_LogLevel_RT_DYN_ID
MCD3D_LogLevel_RT_MON_LINK
MCD3D_LogLevel_JNI
MCD3D_LogLevel_PDU_API
MCD3D_ShowLoggerModuleInLogs Ausgabe des speziellen Loggers in der Logdatei
Wert 0: Der spezielle Logger wird nicht in der Logdatei

aufgeführt (Voreinstellung).
Wert 1: Der spezielle Logger wird in der Logdatei

aufgeführt.
aktueller Wert: nicht aktiv, d.h. Voreinstellung
MCD3D_Java_LogLevel Log-Level für den Java-Layer des MCD-Kernels

beschrieben

Parameter Bedeutung
MCD3D_LogDirectory Ausgabeverzeichnis für die Log-Dateien
Die Angabe erfolgt relativ zu VW_MCD_CONFIG oder

absolut.
Wenn der Konfigurationsparameter fehlt, wird als

Voreinstellung das Verzeichnis <Ausführungslaufwerk>:/log
angenommen, also in der Regel C:/log oder D:/log.
Weitere Details sind im Kapitel sind im Kapitel Logging &

Tracing beschrieben.
aktueller Wert: nicht aktiv, d.h. Voreinstellung
MCD3D_LogfileExtension Alternative Dateiendung für die aktuelle Logdatei
Wenn der Konfigurationsparameter aktiviert wird, wird die

standardmäßige Endung .lg0 durch die dann gewählte
Endung ersetzt.
aktueller Wert: aktiv mit Einstellung „.log“
MCD3D_STRUCTURE_VISIBILITY Sichtbarkeit von Strukturparametern gemäß ASAM MCD 3.0
Wert 0: Sichtbarkeit abgeschaltet, Modus kompatibel zur

Implementierung des ASAM MCD-3D 2.00.02
Standards
Wert 1: Sichtbarkeit eingeschaltet, Modus kompatibel zu

ASAM MCD 3.0.0
MCD3D_MAX_CACHE_SIZE Maximale Anzahl von DB Elementen im internen Datenpool:

ein Wert 0 bedeutet, dass die Anzahl nicht limitiert ist.
MCD3D_PDU_LENGTH_CHECK Längenüberprüfung einer Antwort-PDU gemäß ASAM MCD

3.0.0
Wert 0: Längenüberprüfung abgeschaltet, Modus

kompatibel zur Implementierung des ASAM
MCD-3D 2.00.02 Standards
Wert 1: Längenüberprüfung eingeschaltet, Modus

kompatibel zu ASAM MCD 3.0.0

Parameter Bedeutung
MCD3D_SESSION_RENAMING Namensgebung für MCDDbFlashSession-Objekte
Wert 0: Benennung einer MCDDbFlashSession nach

dem ODX-Element SESSION, Modus
kompatibel zur Implementierung des ASAM
MCD-3D 2.00.02 Standards
Wert 1: Benennen einer MCDDbFlashSession nach dem

ODX-Element SESSION-DESC gemäß ASAM
MCD 3.0
MCD3D_SUPPRESS_EXCEPTION Reaktion auf nicht vorhandene Elemente beim Aufruf der

MCDDbObject-Methoden getDescriptionID, getLongNameID
und getUniqueObjectIdentifier
Wert 0: Der Aufruf der Methoden wird gemäß ASAM

MCD 3.0.0 mit einer MCDException quittiert,
wenn die gefragten Elemente nicht geliefert
werden können.
Wert 1: Der Aufruf der Methoden liefert eine leere

Zeichenkette, wenn die gefragten Elemente
nicht existieren. Dieses Verhalten ist kompatibel
zur Implementierung des ASAM MCD-3D
2.00.02 Standards
MCD3D_LATEBOUND_FILESIZE_CHECK Überprüfung der Größe von Latebound-Flashdateien
Wert 0: Beim Lesen der Daten aus einer Latebound-

Flashdatei wird nicht geprüft, ob genügend
Daten entsprechend der gegebenen
Segmentgröße verfügbar sind. Im Zweifelsfall
werden die vorhandenen Daten geliefert.
Wert 1: Enthält eine Latebound-Flashdatei nicht

genügend Daten gemäß der gegebenen
Segmentgröße, wird das Lesen mit einer
Fehlermeldung quittiert.

Parameter Bedeutung
MCD3D_KEEP_UNCOMPRESSED_TDB Verhalten im Umgang mit komprimierten Textdatenbank-

Dateien im aktuellen Projektverzeichnis
Wert 0: Die komprimierten Dateien der Textdatenbank

werden temporär entpackt und nach
Deselektieren des Projekts wieder gelöscht.
Wert 1: Die komprimierten Dateien der Textdatenbank

werden permanent in das Projektverzeichnis
entpackt; die entsprechenden komprimierten
Dateien werden gelöscht.
MCD3D_SERVER_JavaExternals Pfad auf die vom Job-Prozessor benötigten Java-Klassen und

JARs; über diesen Pfad sowie die entsprechenden Einträge in
MCD3D_PROJECTS.INI und MCD3D_CURR_PROJECT.INI
müssen die mitgelieferten JARs sowie alle weiteren von Jobs
zur Ausführung benötigten JARs gefunden werden, die nicht
in der ODX-Bedatung referenziert sind.
aktueller Wert: „“
MCD3D_SERVER_CppExternalDirs Suchpfade für die in Jobs benötigten DLLs
MCD3D_Audience Audience-Filter des MCD-3D-Systems, beinhaltet folgende

Gruppen: Supplier, Development, Manufacturing, After-Sales
und After-Market. Pro Gruppe ist ein boolescher Wert zu
erwarten, Default-Wert ist ‘1’, falls die Gruppe fehlt oder mit
keinem booleschen Wert versehen wurde.
Beispiel:
SUPPLIER=1
DEVELOPMENT=0
MANUFACTURING=1
AFTERSALES=1
AFTERMARKET=0
aktuelle Werte:
SUPPLIER=1
DEVELOPMENT=1
MANUFACTURING=1
AFTERSALES=1
AFTERMARKET=1
Alle Dienste sind sichtbar.

Parameter Bedeutung
MCD3D_DEFAULT_VIT Generierung einer Default VIT auf Basis vorhandener DIAG-

LAYER mit PARENT-Beziehung und einer MCD3D_PINS.INI,
siehe Kapitel 9.1
Wert 0: deaktiviert
Wert 1: aktiviert
aktueller Wert: 0
MCD3D_SMART_VIT Generierung einer „intelligenten“ VIT auf Basis vorhandener

MCDDbVehicleInformations, siehe Kapitel 9.2
Wert 0: deaktiviert
Wert 1: aktiviert
aktueller Wert: 0
Abbildung 3. MCD3D_SERVER.INI
*) Man beachte, dass der ODX-Converter grundsätzlich alle Java-Job-Klassen und JARs in
dem Verzeichnis Jobs unter dem Projektordner abspeichert. Dies ist nicht parametrierbar.
Bei Bedarf können diese Dateien jedoch in ein anderes Verzeichnis verschoben werden, das
der MCD-Kernel durch Auswertung des entsprechenden Konfigurationsparameters
MCD3D_JobSubDirectory findet.
3.2 MCD3D_PROJECTS.INI
Diese Konfigurationsdatei enthält projektglobale Einstellungen, die unter bestimmten

Voraussetzungen zur Laufzeit modifiziert werden können.
Anders als die MCD3D_SERVER.INI wird diese Konfigurationsdatei sowohl bei

Programmstart als auch bei jedem Aufruf der Methode
MCDSystem::getDbProjectDescriptions gelesen. Dies ermöglicht das Nachladen von
Projekten zur Laufzeit.
Parameter Bedeutung
MCD3D_ProjectRootDir_001 Wurzelverzeichnis für Projektordner
Alle Ordner, die unter diesem Verzeichnis zu finden sind und

darüber hinaus eine als Laufzeitdatenbank identifizierbare
Datei enthalten, werden als Projektordner interpretiert, wobei
der jeweilige Ordnername als Bezeichner des MCDProject-
Objekts verwendet wird.
aktueller Wert: „./../Projects“

MCD3D_FlashProjectDirectory alternatives Flashprojektverzeichnis; überschreibt das

Standardverhalten, dass Flash-Laufzeitdatenbanken im
aktuellen Projektverzeichnis gesucht werden.
MCD3D_FlashDataRootDirectory Wurzelverzeichnis für Flash-Daten
MCD3D_EcuConfigRootDirectory Suchpfad für die ECU-Config-Datendateien
Beispiel: „./../Projects/EcuData“
Aktueller Wert: „“
MCD3D_PROJECTS_JavaExternals Pfad auf die vom Job-Prozessor benötigten Java-Klassen und

JARs; über diesen Pfad sowie die entsprechenden Einträge in
MCD3D_SERVER.INI und MCD3D_CURR_PROJECT.INI
müssen die mitgelieferten JARs sowie alle weiteren von Jobs
zur Ausführung benötigten JARs gefunden werden, die nicht in
der ODX-Bedatung referenziert sind.
Beispiel: „./FlashJobs/BootLoaderFlash.jar“
MCD3D_PROJECTS_CppExternalDirs Suchpfade für die in Jobs benötigten DLLs
Beispiel: „./FlashUtilities;./JNIWrapper“
MCD3D_LateboundFilesDirectory Verzeichnis zur Ablage von Latebound-Flash- oder Config-

Dateien
aktueller Wert: „CommonLBFiles“
Abbildung 4. MCD3D_PROJECTS.INI
3.3 MCD3D_CURR_PROJECT.INI
Diese optionale Konfigurationsdatei enthält projektspezifische Einstellungen zur Job-

Konfiguration. Sie wird beim Selektieren eines speziellen Projekts gelesen und ausgewertet.
Parameter Bedeutung
MCD3D_CURR_PROJECT_JavaExternals Pfad auf die projektspezifischen, vom Job-Prozessor

benötigten Java-Klassen und JARs; über diesen Pfad sowie
die entsprechenden Einträge in MCD3D_SERVER.INI und
MCD3D_ PROJECTS.INI müssen die mitgelieferten JARs
sowie alle weiteren von Jobs zur Ausführung benötigten JARs
gefunden werden, die nicht in der ODX-Bedatung referenziert
sind.
Beispiel: "./SeedAndKey.jar"
MCD3D_CURR_PROJECT_CppExternalDirs Suchpfade für die in Jobs benötigten DLLs
Beispiel: "./SecurityAccess;./JNIWrapper"
MCD3D_CURR_PROJECT_UploadFiles Relativer Pfad auf das vom ODX-Converter erstellte Upload-

Verzeichnis (relativ zum Laufzeitprojekt)
Beispiel: "./UploadFiles"
(siehe Abschnitt 4.2.1.3)
Abbildung 5. MCD3D_CURR_PROJECT.INI
3.4 TESTERID.INI
Die optionale TESTERID.INI enthält die Tester-Id des Testers auf dem der Server läuft. Die
Tester-Id wird mittels des Kommandozeilenprogramms settesterid.exe gesetzt und
verschlüsselt in der TESTERID.INI abgelegt. Diese Datei soll nicht manuell geändert werden.
Eine neue Tester-Id kann mit dem oben genannten Programm gesetzt werden.
Parameter Bedeutung
ENCRYPTED_TESTER_ID verschlüsselte Tester-Id
TESTER_ID_CHECKSUM Checksumme der Tester-Id zur Sicherung der Integrität
Abbildung 6. TESTERID.INI
20 4. Jobdatenkonfiguration V14.0.0 / 31.10.2019
4 Jobdatenkonfiguration
4.1 Problemstellung
Durch die Möglichkeit, über die MCD3D-Schnittstelle Java-Code in Form von sogenannten
Jobs auszuführen, deren Inhalt dem Laufzeitsystem nicht bekannt ist, kann zur Laufzeit die
Situation entstehen, dass kontextabhängig externe Bibliotheken – JARs oder DLLs – oder
Flash-Dateien genutzt werden sollen, die vor dem Start der VW-MCD CD-Applikation nicht
konfigurierbar sind. Der Umgang mit einer solchen Situation ist nicht durch ein
standardisiertes Verfahren geregelt und obliegt der Applikationsentwicklung. VW-MCD bietet
dabei eine umfassende und flexible Unterstützung.
JARs und DLLs werden in Java üblicherweise bei Applikationsstart über zwei Pfadvariablen
bekannt gemacht, die zur Laufzeit als „Properties“ „java.class.path“ bzw. „java.library.path“
abfragbar sind. Dabei gibt es verschiedene Möglichkeiten, diese Pfade beim Start zu setzen.
Gebraucht werden die Werte als Suchpfade beim Laden von Java-Klassen oder C++-
Bibliotheken.
Ein nachträgliches Umsetzen der beiden „Properties“ hat jedoch keine Auswirkung auf die
Pfade, die beim anschließenden Laden von Java-Klassen oder C++-Bibliotheken tatsächlich
herangezogen werden, so dass man andere Mechanismen entwickeln muss, um zur Laufzeit
neue Pfade nutzen zu können.
Hinweis für Projekte auf Basis von ODX 2.2-Daten
Man beachte, dass ODX 2.2 über das LIBRARY-Element die Möglichkeit zur Referenzierung
externer JARs und DLLs bietet und damit keiner gesonderten Konfiguration bedarf.
Die LIBRARY-Unterstützung existiert parallel zur nachfolgend erläuterten

Konfigurationsmöglichkeit, die für Projekte auf Basis älterer ODX-Standardversionen 2.0.1
oder 2.1 alternativlos ist.
4.2 Möglichkeit zur Konfiguration des MCD-Kernels bezüglich Job-Ausführung
Nachfolgend wird erläutert, wie man unterschiedliche Parametrierungsebenen nutzen kann,

um dem speziellen Anwendungsgebiet „Job-Ausführung“ von VW-MCD gerecht zu werden.
4.2.1 Inhalt der Konfigurationsdateien
Für VW-MCD können Pfade auf externe DLLs, externe JARs und Java-Klassen konfiguriert
werden.
In beiden Fällen erfolgt die Parametrierung dreistufig über unterschiedliche

Konfigurationsdateien:
1. MCD3D_SERVER.INI
V14.0.0 / 31.10.2019 4. Jobdatenkonfiguration 21
Hier werden projektübergreifende Pfade in absoluter oder relativer Notation eingestellt,

wobei relative Angaben relativ zum Konfigurationsverzeichnis des MCD-Kernels
(VW_MCD_CONFIG in einer Windows 7- oder Windows-10-Umgebung, sonst
VW_MCD_HOME) betrachtet werden, falls die entsprechende Umgebungsvariable
gesetzt ist, ansonsten relativ zum aktuellen Arbeitsverzeichnis.
Beispiel:
MCD3D_SERVER_JavaExternals=“C:/JavaInstallation/log4j.jar;“
MCD3D_SERVER_CppExternalDirs=”C:/external_dlls”
2. MCD3D_PROJECTS.INI
Hier werden projektübergreifende Pfade eingestellt, wobei ausschließlich relative
Angaben zulässig sind. Der Bezugspunkt für solche Pfade ist das aktuelle
Projektwurzelverzeichnis. Man beachte, dass es mehr als ein Projektwurzelverzeichnis
geben kann. Das jeweils aktuelle wird anhand des selektierten Projekts ermittelt.
Beispiel:
MCD3D_PROJECTS_JavaExternals=”./../CommonJars/ErrorHandling.jar;”
MCD3D_PROJECTS_CppExternalDirs=”./../CommonDlls”
3. MCD3D_CURR_PROJECT.INI
Hier werden projektspezifische relative Pfade eingestellt, die sich auf das aktuelle
Projektverzeichnis beziehen.
Diese Konfigurationsdatei ist optional. Sie kann wahlweise vom PDX-Builder anhand des
Laufzeit-PDX generiert und als Bestandteil dieses Pakets verteilt oder vom Kunden / von
einer Kundenapplikation bereitgestellt werden.
Beispiel:
MCD3D_CURR_PROJECT_JavaExternals=”./ExternalJars/JobSupport.jar;”
MCD3D_CURR_PROJECT_CppExternalDirs=”./ExternalDlls”
4.2.1.1 Verarbeitung der Konfigurationsdateien
Beim Systemstart liest der MCD-Kernel die Konfigurationsdatei MCD3D_SERVER.INI und

speichert die Werte für MCD3D_SERVER_JavaExternals und
MCD3D_SERVER_CppExternalDirs. Im Fall von relativen Pfaden wird VW_MCD_HOME
ausgewertet und, so gesetzt, den Pfaden vorangestellt. Andernfalls bleiben die Pfade
unverändert, so dass relative Pfade zur Laufzeit vom aktuellen Arbeitsverzeichnis ausgehen.
Ebenso wird die Konfigurationsdatei MCD3D_PROJECTS.INI gelesen, und die Werte für
MCD3D_PROJECTS_JavaExternals und MCD3D_PROJECTS_CppExternalDirs werden
intern gespeichert.
Beim Selektieren eines konkreten Projekts wird in dem aktuellen Projektverzeichnis nach
einer Datei MCD3D_CURR_PROJECT.INI gesucht. Existiert diese Datei, werden die Werte
für MCD3D_CURR_PROJECT_JavaExternals und

MCD3D_CURR_PROJECT_CppExternalDirs gelesen und abgespeichert.
4.2.1.2 Job-Ausführung
Der auszuführende Job befindet sich entweder als .class-Datei oder als Bestandteil eines
JARs im aktuellen Projektverzeichnis unter Jobs. Etwaige Paketstrukturen gemäß Bedatung
bleiben erhalten, so dass zur Laufzeit stets bekannt ist, auf welche Weise der Job-Code
ansprechbar ist. Wie schon in Kapitel 4.1 erwähnt, hat ein MCD3D-Laufzeitsystem dagegen
prinzipiell keine Kenntnisse über die innerhalb von Jobs verwendeten JARs und DLLs. In
VW-MCD soll nun folgendes Vorgehen umgesetzt werden:
Dem bei der Job-Ausführung gültigen „Class Loader“ werden alle konfigurierten Pfade mit
abnehmender Spezialisierung mitgegeben, wobei diese Pfade absolut angegeben werden.
Somit findet der Job-Prozessor bei jeder Applikationsart alle auf diese Weise referenzierten
JARs, sofern die Referenzen korrekt sind. Sollten in den unterschiedlichen
Konfigurationsdateien JARs gleichen Namens notiert sein, so würde zur Laufzeit stets die
speziellste Angabe präferiert.
Beispiel:
Katalog Baureihe_XYZ.pdx:
index.xml
common_dlls/CppUtils.dll
common_jars/JavaJobUtilities.jar
vehicle_info_spec.odx-v
comparam_spec.odx-c
ECU_A/ecu_a.odx-d
ECU_A/ecuAJobSupport.jar
ECU_A/ecuAJobUtilities.jar
ecu_a_jobs.jar /* enthält in der Bedatung referenzierte Jobs */
Laufzeit-PDX:
index.xml
common_dlls/CppUtils.dll
common_jars/JavaJobUtilities.jar
ECU_A.db
ECU_A.key
ECU_A/ecuAJobSupport.jar
ECU_A/ecuAJobUtilities.dll
Jobs/ecu_a_jobs.jar
MCD3D_CURR_PROJECT.INI
mit MCD3D_CURR_PROJECT.INI:
MCD3D_CURR_PROJECT_JavaExternals=”./common_jars/JavaJobUtilities.jar;
./ECU_A/ecuAJobUtilities.jar”
MCD3D_CURR_PROJECT_CppExternalDirs=”./common_dlls;./ECU_A”
Weiter gelten die folgenden Einträge:

MCD3D_SERVER_JavaExternals=“C:/JavaInstallation/log4j.jar;“
MCD3D_SERVER_CppExternalDirs=“C:/CppInstallation“
MCD3D_PROJECTS_JavaExternals=“./../ExternalJars/ErrorHandling.jar;
./SeedAndKey.jar;”
MCD3D_PROJECTS_CppExternalDirs=”./../ExternalDlls”
Sei CurrProj der Name des aktuell selektierten Projekts.
Sei C:/Programme/Volkswagen/VW-MCD/Projekte/Baureihe_XYZ der Wert des

Parameters MCD3D_ProjectRootDir_001.
Dann werden dem „Class Loader“ die folgenden Pfade in gegebener Reihenfolge bekannt
gemacht:
C:/Programme/Volkswagen/VW-MCD
/Projekte/Baureihe_XYZ/CurrProj/common_jars/JavaJobUtilities.jar
/Projekte/Baureihe_XYZ/CurrProj/ECU_A/ecuAJobUtilities.jar
/Projekte/ExternalJars/ErrorHandling.jar
C:/Programme/ Volkswagen/VW-MCD/Projekte/Baureihe_XYZ/SeedAndKey.jar
C:/JavaInstallation/log4j.jar
Man beachte, dass es bei gegebenen Ablagestrukturen nicht möglich ist,

ErrorHandling.jar in das PDX aufzunehmen, da das Verzeichnis ExternalJars
parallel zum PDX liegt und somit nicht referenzierbar ist.
Noch zu lösen ist das Problem, dass während der Job-Ausführung potenziell die im PDX
enthaltenen oder auch global parametrierten DLLs gefunden werden sollen. Dies ist nicht
analog zum „Class Loader“-Mechanismus realisierbar. Vielmehr muss der Anwender durch
Setzen geeigneter Umgebungsvariablen, z. B. PATH, java.library.path, vor dem Start
der Applikation selbst dafür Sorge tragen, dass die zu ladenden DLLs erreichbar sind.
Eine Alternative kann VW-MCD bieten, indem zur Laufzeit eine sogenannte Java-Property
gesetzt wird, die im Job-Code genutzt werden kann. Aus den verfügbaren
Konfigurationsdateieinträgen wird die „Property“ VW_MCD_JOB_DLL_PATH gebildet, der der
Job-Code die potenziellen DLL-Suchpfade entnehmen kann. Es ist jedoch nicht zu
vermeiden, dass im Job-Code diese „Property“ zerlegt wird und für jede zu ladende DLL
geprüft werden muss, in welchem Verzeichnis sie sich tatsächlich befindet, damit beim
Ladebefehl der konkrete absolute Pfad angegeben werden kann. Zu diesem Zweck sind
auch hier die potenziellen Pfade mit abnehmender Spezialisierung aufgeführt.
Für das obige Beispiel lautet der Wert von VW_MCD_JOB_DLL_PATH:

C:/Programme/Volkswagen/VW-MCD/Projekte/Baureihe_XYZ/CurrProj/common_dlls;
C:/Programme/Volkswagen/VW-MCD/Projekte/Baureihe_XYZ/CurrProj/ECU_A;
C:/Programme/ Volkswagen/VW-MCD/Projekte/ExternalDlls;C:/CppInstallation;
Aus praktischen Erwägungen werden anders als bei den JAR-Referenzen die DLL-Namen
selbst nicht mit aufgenommen.
Im Job-Code können aus der „Property“ nun die einzelnen DLL-Pfade

C:/Programme/Volkswagen/VW-MCD/Projekte/Baureihe_XYZ/
CurrProj/common_dlls
C:/Programme/Volkswagen/VW-MCD/Projekte/Baureihe_XYZ/CurrProj/ECU_A
C:/Programme/Volkswagen/VW-MCD/Projekte/ExternalDlls
C:/CppInstallation
extrahiert und zum Laden der DLLs herangezogen werden.
4.2.1.3 Upload-Verzeichnis für Job-Ausführung
VW-MCD bietet die Möglichkeit, einem Upload-Java-Job ein Verzeichnis zur Verfügung zu
stellen, in dem der Job Upload-Dateien abspeichern kann. Der Verzeichnisname wird dem
Job über eine Java-Property bekannt gegeben.
Das Verzeichnis befindet sich immer unterhalb des Root-Verzeichnisses eines

Laufzeitprojekts. Die Konfiguration eines globalen Upload-Verzeichnisses, d.h.
Laufzeitprojekt übergreifend, ist nicht möglich.
Das Tool ODX-Converter erzeugt automatisch das Upload-Verzeichnis, nach erfolgreicher

ODX-Konvertierung, unterhalb des Laufzeitprojekts.
Der Verzeichnisname wird in der Datei converter.ini über den Schlüssel

UploadFilesSubDirectory definiert.
Beispiel einer converter.ini Konfigurationsdatei
[BASIC]
# upload directory used at runtime

ODXCONV_Upload_Files_Subdir="./UploadFiles"
Ist der Schlüssel ODXCONV_Upload_Files_Subdir nicht definiert oder leer, so wird das
Upload-Verzeichnis nicht durch den ODX-Converter erzeugt.
Des Weiteren fügt der ODX-Converter den Schlüssel

MCD3D_CURR_PROJECT_UploadFiles in die Konfigurationsdatei
MCD3D_CURR_PROJECT.INI ein.
Beispiel einer MCD3D_CURR_PROJECT.INI Konfigurationsdatei

[MCD3D_JOB_PROCESSOR]
MCD3D_CURR_PROJECT_JavaExternals=""
MCD3D_CURR_PROJECT_CppExternalDirs="./allgemein"
MCD3D_CURR_PROJECT_UploadFiles="./UploadFiles"
Der Schlüssel MCD3D_CURR_PROJECT_UploadFiles definiert den relativen Pfad auf das

erstellte Upload-Verzeichnis. Der Pfad ist relativ zum Laufzeitprojekt, in dem die
Konfigurationsdatei MCD3D_CURR_PROJECT.INI erzeugt wird. Der Eintrag wird nur
erstellt, wenn der entsprechende Name des Upload-Verzeichnisses in der converter.ini-
Konfigurationsdatei definiert ist.
Der PDX-Builder erzeugt das Verzeichnis und passt die MCD3D_CURR_PROJECT.INI an,
wenn die Konvertierung über folgende Menüoptionen gestartet wird:
• File -> Export Runtime PDX -> Full...
• File -> Export Runtime PDX -> Basicdata...
• Convert -> Convert All...
Folgende Schritte führt VW-MCD zur Bereitstellung des Verzeichnisnamens für Upload-
Dateien durch:
1. Eine Diagnoseanwendung erzeugt über die MCD 3D API den gewünschten Upload-Job
(MCDLogicalLink.createDiagComPrimitiveByName(„JobName“)) und startet den Job
(MCDJob.executeSync())
2. VW-MCD liest den Eintrag MCD3D_CURR_PROJECT_UploadFiles aus der Datei

MCD3D_CURR_PROJECT.ini und setzt vor den gelesenen Wert den absoluten Pfad auf
das aktuell selektierte Projekt. Mit dieser zusammengesetzten Zeichenkette wird nun die
„Java-Property“ VW_MCD_JOB_UPLOAD_FILES gebildet.
Beispiel:
Es sei „./UploadFiles“ der Wert des Eintrags MCD3D_CURR_PROJECT_UploadFiles
und „C:\Programme\Volkswagen\VW-MCD\Projects\CurrProj“ der absolute Pfad auf das
Laufzeitprojekt. Die Property VW_MCD_JOB_UPLOAD_FILES hat nun den Wert
„C:/Programme/Volkswagen/VW-MCD/Projects/CurrProj/UploadFiles“
3. VW-MCD lädt den Job, der sich entweder als .class-Datei oder als Bestandteil eines
JARs im aktuellen Projektverzeichnis unter „Jobs“ befindet, über den für die Ausführung
gültigen „Class Loader“. Nun setzt VW-MCD für den „Class Loader“ die Property
VW_MCD_JOB_UPLOAD_FILES und führt den Job aus.
4. Der Upload-Job ermittelt über den Java-Aufruf

System.getProperty("VW_MCD_JOB_UPLOAD_FILES") den Namen des
Verzeichnisses, in das der Upload-Vorgang die empfangenen Steuergeräte-Daten
speichern kann.
4.2.1.4 Log-Verzeichnis für Job-Ausführung
Das aktuelle Log-Verzeichnis von VW-MCD ist in der Property „VW_MCD_JOB_LOG_DIR“

hinterlegt. Dieser Pfad-Wert kann im Job genutzt werden, um Logdateien oder andere Daten
in das Log-Verzeichnis abzulegen.
Der Default-Wert unter Windows ist ein relativer Pfad zum Laufwerk des aktuellen
Arbeitsverzeichnisses: „\Log\“. Unter Linux ist der Default-Wert konfigurationsabhängig, z.B.
26 5. Flashdatenkonfiguration V14.0.0 / 31.10.2019
„/var/opt/vw/log/“. Der Wert des Log-Verzeichnisses kann in der MCD3D_SERVER.INI

konfiguriert werden (siehe Abschnitt 3.1).
4.2.1.5 Abfrage der Strukturparametersichtbarkeit während der Job-Ausführung
Die Sichtbarkeit von Strukturparametern kann in der MCD3D_SERVER.INI über den

Parameter MCD3D_STRUCTURE_VISIBILITY konfiguriert werden (siehe Abschnitt 3.1).
Für das Erstellen einer Job-Response ist es je nach Antwortstruktur wichtig zu wissen,
welcher Wert eingestellt worden ist. Daher wird dieser Wert als Java-Property
„VW_MCD_JOB_STRUCTURE_VISIBILITY“ mit den möglichen Werten „on“ (entspricht dem
Konfigurationswert 1) und „off“ (entspricht dem Konfigurationswert 0) hinterlegt. Dieser Wert
kann im Job zur korrekten Response-Strukturverarbeitung genutzt werden.
4.2.1.6 Abfrage des aktuellen Projektverzeichnisses während der Job-Ausführung
Das aktuelle Projektverzeichnis kann im Job über die Java-Property

„VW_MCD_JOB_PROJECT_DIR“ erfragt werden.
4.2.1.7 Abfrage des konfigurierten Latebound-Verzeichnisses während der Job-

Ausführung
Das in der MCD3D_PROJECTS.INI konfigurierte Latebound-Verzeichnis kann im Job über

die Java-Property „VW_MCD_JOB_LATEBOUND_FILES“ erfragt werden.
5 Flashdatenkonfiguration
5.1 Late-bound-Mechanismus
Als Late-bound-Mechanismus im Zusammenhang mit dem Laden von Flashdateien wird hier
eine Vorgehensweise bezeichnet, bei der Flashdateien in der ODX-Bedatung mit
sogenannten Wildcards aufgeführt sind, die zur MCD-Kernellaufzeit bei Bedarf aufgelöst
werden müssen. Da gegebenenfalls mehr als eine Flashdatei zum bedateten
Dateinamensmuster passt, muss die Applikation aktiv die möglichen vollständigen
Dateinamen erfragen und aus der Menge der Möglichkeiten genau eine auswählen, um mit
dieser weiterzuarbeiten.
Da der MCD3D 2.00.02-Standard keinen Late-bound-Mechanismus unterstützt hat, ist nach

Verabschiedung des Standards ein Vorschlag zur Definition eines geeigneten Latebound-
Mechanismus eingebracht und im MCD-Kernel umgesetzt worden. Dieser ergänzt die
letztlich für den Standard ASAM MCD 3.0.0 verabschiedete Lösung um die Methode
MCDDbFlashDataBlock::loadSegments, deren Verwendung im Kapitel 5.4 beschrieben wird.
Man beachte:
Im eigentlichen Sinne wird der Begriff „late-bound“ bereits dann verwendet, wenn der MCD-
Kernel die Flashdaten nicht unmittelbar bei Programmstart in den Speicher lädt, sondern
V14.0.0 / 31.10.2019 5. Flashdatenkonfiguration 27
dies bedarfsgetrieben tut. Da der MCD-Kernel die Flashdaten ohnehin schon zum
spätestmöglichen Zeitpunkt lädt, wird über „late-bound“ lediglich unterschieden, ob der
gegebene Dateiname Wildcards enthält oder direkt verwendet werden kann.
5.2 Umsetzung im MCD-Kernel
5.2.1 Gundsätzlicher Algorithmus zum Auffinden von Flashdaten
Flashdateien können in der ODX-Bedatung prinzipiell mit absolutem Pfad notiert sein, auch
wenn dies im Normalfall nicht sinnvoll sein wird.
1. Bei absolut gegebenen Flashdateien werden keine Konfigurationsparameter,

Umgebungsvariablen oder Projektverzeichnisse berücksichtigt. Sie werden exakt dort zu
laden versucht, wo sie gemäß ODX-Bedatung liegen müssten.
Beispiel
<FLASHDATA xsi:type=“EXTERN-FLASHDATA“ ID=“FLASHDATA_Latebound_abs_ID“>
<SHORT-NAME>FLASHDATA_Latebound_abs</SHORT-NAME>
<DATAFORMAT SELECTION=“BINARY“/>
<DATAFILE LATEBOUND-DATAFILE=“true“>C:/flashfiles/flash.bin</DATAFILE>
</FLASHDATA>
Die Flashdatei flash.bin wird ausschließlich im Verzeichnis C:/flashfiles gesucht.
2. Bei relativ gegebenen Flashdateien tragen mehrere Einträge zum Bezugspunkt bei.
2.1. Ist der Wert des Konfigurationsparameters MCD3D_FlashDataRootDirectory

in der MCD3D_PROJECTS.INI nicht leer, dann wird der Eintrag in einen absoluten
Pfad umgewandelt, wenn er relativ gegeben ist. Der Bezugspunkt ist entweder der
Wert der Umgebungsvariable VW_MCD_CONFIG in einer Windows 7-Umgebung
bzw. VW_MCD_HOME in einer Windows XP-Umgebung oder, falls diese nicht
gesetzt ist, das aktuelle Arbeitsverzeichnis. An diesen Pfad wird zunächst das
Flashdatenunterverzeichnis (siehe Kapitel 5.3.1) gehängt und im Anschluss daran
der bedatete Flashdateiname.
Beispiel:
Auszug aus MCD3D_PROJECTS.INI

# root directory of the flash files;
# to be set, if flash files are not stored in the corresponding project directory
MCD3D_FlashDataRootDirectory="./../Flashware"
VW_MCD_CONFIG sei auf C:/users/public/Volkswagen/VW-MCD/config gesetzt.
Auszug aus ODX-Daten

<FLASH ID="FLASH_BCM_ID">
<SHORT-NAME>FLASH_BCM</SHORT-NAME>
<FLASHDATA xsi:type=“EXTERN-FLASHDATA“ ID=“FLASHDATA_Latebound_rel_ID“>
<SHORT-NAME>FLASHDATA_Latebound_rel</SHORT-NAME>
<DATAFILE LATEBOUND-DATAFILE=“true“>flash.bin</DATAFILE>
</FLASHDATA>
Die Datei flash.bin wird zunächst unter

C:/users/public/Volkswagen/VW-MCD/Flashware/FLASH_BCM
gesucht.
2.1.1. Kann die so festgelegte Datei nicht gefunden werden, wird das
Flashdatenunterverzeichnis im Pfad weggelassen und die Datei im daraus
resultierenden Verzeichnis gesucht.
Fortsetzung Beispiel
Die Datei flash.bin wird nun unter

C:/users/public/Volkswagen/VW-MCD/Flashware
gesucht.
2.1.1.1. Kann die so festgelegte Datei nicht gefunden werden, wird der Pfad zum
aktuellen Projekt ermittelt, an diesen das Flashdatenunterverzeichnis
gehängt und im Anschluss daran der bedatete Flashdateiname.
Der Pfad zum aktuellen Projekt sei

C:/users/public/Volkswagen/VW-MCD/projects/MyProject

C:/users/public/Volkswagen/VW-MCD/projects/MyProject/FLASH_BCM
gesucht.
2.1.1.1.1. Kann die so festgelegte Datei nicht gefunden werden, wird das
Flashdatenunterverzeichnis im Pfad weggelassen und die Datei im
daraus resultierenden Verzeichnis gesucht.

gesucht.

in der MCD3D_PROJECTS.INI leer, wird der Pfad zum aktuellen Projekt ermittelt,
an diesen das Flashdatenunterverzeichnis gehängt und im Anschluss daran der
bedatete Flashdateiname.

MCD3D_FlashDataRootDirectory=""


C:/users/public/Volkswagen/VW-MCD/projects/MyProject/FLASH_BCM
gesucht.
2.2.1. Kann die so festgelegte Datei nicht gefunden werden, wird das
Flashdatenverzeichnis im Pfad weggelassen und die Datei im daraus
resultierenden Verzeichnis gesucht.

gesucht.
5.2.2 Spezialitäten hinsichtlich Latebound-Dateien
Bei der Verwendung von Wildcards in Flashdateien müssen diese explizit auf Anforderung
der Applikation aufgelöst werden, so dass die Applikation eine Datei aus potenziell mehreren
passenden Dateien auswählen und festlegen kann.
Wo passende Dateien gesucht werden, hängt sowohl von der Bedatung als auch von der
MCD-Kernel-Konfiguration ab:
1. Enthält der Flashdateieintrag in der ODX-Bedatung einen absoluten Pfad, so wird

ausschließlich im darüber bestimmten Verzeichnis nach passenden Dateien gesucht.
Beispiel
Gegeben sei folgender Extrakt einer ODX-Bedatung:

<FLASHDATA xsi:type=“EXTERN-FLASHDATA“ ID=“FLASHDATA_Latebound_abs_ID“>
<SHORT-NAME>FLASHDATA_Latebound_abs</SHORT-NAME>
<DATAFILE LATEBOUND-DATAFILE=“true“>C:/flashfiles/*.bin</DATAFILE>
</FLASHDATA>
Das Verzeichnis C:/flashfiles enthalte die Dateien binaryFlash1.bin,

binaryFlash2.bin sowie motorolaFlash1.mot und motorolaFlash2.mot.
Dann liefert getMatchingFileNames nur die Elemente binaryFlash1.bin und

binaryFlash2.bin. In anderen Verzeichnissen als C:/flashfiles wird nicht mehr
nach passenden Dateien gesucht.
2. Sonst (Der Flashdateieintrag in der ODX-Bedatung enthält einen (möglicherweise

leeren) relativen Pfad):

in der MCD3D_PROJECTS.INI nicht leer, dann wird der Eintrag in einen absoluten
Pfad umgewandelt, wenn er relativ gegeben ist. Im vorherigen Abschnitt ist

beschrieben, nach welchen Regeln dies geschieht. An diesen Pfad wird zunächst
das Flashdatenunterverzeichnis (siehe Kapitel 5.3.1) gehängt und im Anschluss
daran der bedatete Flashdateiname. Anhand dieses zusammengesetzten
Dateinamens wird bei getMatchingFileNames nach allen Dateien gesucht, die
dem Muster entsprechen.
Beispiel

MCD3D_FlashDataRootDirectory="./../Flashware"
VW_MCD_CONFIG sei auf C:/users/public/Volkswagen/VW-MCD/config gesetzt.
Auszug aus ODX-Daten

<FLASH ID="FLASH_BCM_ID">
<SHORT-NAME>FLASH_BCM</SHORT-NAME>
<FLASHDATA xsi:type=“EXTERN-FLASHDATA“ ID=“FLASHDATA_Latebound_rel_ID“>
<SHORT-NAME>FLASHDATA_Latebound_rel</SHORT-NAME>
<DATAFILE LATEBOUND-DATAFILE=“true“>flashdata/*.bin</DATAFILE>
</FLASHDATA>
Dann wird in dem Verzeichnis

C:/Programme/Volkswagen/VW-MCD/Flashware/FLASH_BCM/flashdata
nach allen Dateien gesucht, die dem Muster „*.bin“ genügen.
2.1.1. Ist das Resultat eine leere Menge, wird Gleiches mit dem aus
MCD3D_FlashDataRootDirectory und bedatetem Dateinamen
zusammengesetzten Namen versucht. Das Flashdatenunterverzeichnis
wird weggelassen.
Es wird im Verzeichnis C:/Programme/Volkswagen/VW-MCD/Flashware/flashdata

2.1.1.1. Ist das Resultat eine leere Menge, wird der absolute Pfad zum
aktuellen Projekt ermittelt, an diesen das Flashdatenunterverzeichnis
gehängt und im Anschluss daran der bedatete Flashdateiname.
Anhand dieses zusammengesetzten Dateinamens wird bei
getMatchingFileNames nach allen Dateien gesucht, die dem
Muster entsprechen.

Es wird im Verzeichnis C:/Programme/Volkswagen/VW-

MCD/projects/MyProject/FLASH_BCM/flashdata nach allen Dateien gesucht,
die dem Muster „*.bin“ genügen.
2.1.1.1.1. Ist das Resultat eine leere Menge, wird Gleiches ohne das
Flashdatenunterverzeichnis versucht.
Es wird im Verzeichnis C:/Programme/Volkswagen/VW-

MCD/projects/MyProject/flashdata nach allen Dateien gesucht, die
dem Muster „*.bin“ genügen.

in der MCD3D_PROJECTS.INI leer, wird der absolute Pfad zum aktuellen Projekt
ermittelt, an diesen das Flashdatenunterverzeichnis gehängt und im Anschluss
daran der bedatete Flashdateiname – vgl. 2.1. Anhand dieses
zusammengesetzten Dateinamens wird bei getMatchingFileNames nach allen
Dateien gesucht, die dem Muster entsprechen.

MCD3D_FlashDataRootDirectory=""

Es wird im Verzeichnis
C:/Programme/Volkswagen/VW-MCD/projects/MyProject/FLASH_BCM/flashdata
2.2.1. Ist das Resultat eine leere Menge, wird Gleiches mit dem aus absolutem
Projektpfad und bedatetem Dateinamen zusammengesetzten Namen
versucht. Das Flashdatenunterverzeichnis wird ausgelassen.
Es wird im Verzeichnis
C:/Programme/Volkswagen/VW-MCD/projects/MyProject/flashdata

5.3 Flashdatenablage
5.3.1 Das Flashdatenunterverzeichnis
Um mit gleichlautenden Flashdateien in einem Laufzeitdatenprojekt umgehen zu können,

werden bei der Konvertierung von ODX FLASH Flashdatenunterverzeichnisse mit dem
innerhalb eines Laufzeitdatenprojekts eindeutigen Namen ODX / FLASH / SHORT-MAME
angelegt.
Aus Kompatibilitätsgründen wird im MCD-Kernel berücksichtigt, dass die Flashdaten

gegebenenfalls nachträglich ins aktuelle Projekt gebracht werden, indem bei der Dateisuche
in einem zweiten Schritt stets der analoge Pfad ohne Flashdatenunterverzeichnis geprüft
wird, so die Suche mit Flashdatenunterverzeichnis fehlgeschlagen ist.
5.3.2 Ablagemöglichkeiten
Wenn Flashdaten projektübergreifend zentral abgelegt werden sollen, muss der Ablageort
dem MCD-Kernel über den Konfigurationsparameter MCD3D_FlashDataRootDirectory
mitgeteilt werden.
Wenn Flashdaten ausschließlich zusammen mit den restlichen Projektlaufzeitdaten abgelegt

werden sollen, so muss der Konfigurationsparameter MCD3D_FlashDataRootDirectory
leer sein. Ob die Flashdaten noch in flashspezifische Unterverzeichnisse gelegt werden,
hängt davon ab, ob sie schon bei der Konvertierung vorhanden waren. Man beachte, dass
der MCD-Kernel nur Unterverzeichnisse erkennt und durchsucht, die nach im Projekt
enthaltenen ODX FLASH benannt sind. Alle anderen Unterverzeichnisse müssen explizit in
der ODX-Bedatung notiert sein.
5.4 Anwendung
Um den Late-bound-Mechanismus zu nutzen, muss eine Flash-Applikation folgende Schritte

durchführen:
1. Bereitstellen der Flashdaten in einem Verzeichnis passend zur Konfiguration (siehe

oben).
2. Navigieren zum zu flashenden MCDDbFlashDataBlock.
3. Zugriff auf das MCDDbFlashData-Element am MCDDbFlashDataBlock über

getDbFlashData.
4. Ermitteln aller hinsichtlich möglicherweise mit Wildcards bedatetem Dateinamen und

gegebenen Dateien geeigneten Flashdateinamen über
MCDDbFlashData::getMatchingFileNames.
5. Falls für den aktuellen MCDDbFlashDataBlock MCDDbFlashSegment-Elemente

bedatet sind:
5.1. Auswahl eines dieser Flashdateinamen als Eingabe für

MCDDbFlashData::setActiveFileName.
5.2. Weiter wie beim „nicht-latebound“-Flashen.
6. Sonst:
6.1. Laden bzw. Erzeugen eines neuen MCDDbFlashSegment-Elements unter Angabe

eines der Flashdateinamen aus der über getMatchingFileNames gelieferten
Kollektion möglicher Dateinamen. Die entsprechende Methode lautet
MCDDbFlashData::loadSegments.
6.2. Weiter wie beim „nicht-latebound“-Flashen.
Man beachte: Die Methode loadSegments kann prinzipiell immer aufgerufen werden, wenn
das MCDDbFlashData-Objekt auf eine „late-bound“-Flashdatei verweist, die Methode
isLateBound also true liefert. Jedoch gehen dabei alle etwaigen Segment-Informationen
aus der ODX-Bedatung verloren, und es existiert im Anschluss an den Aufruf von
loadSegments genau ein Segment, das den kompletten Datenbereich abdeckt. Wenn die
ODX-Bedatung trotz „latebound“-Flashdateien bereits Segmente enthält, sollte eine
Applikation lediglich über setActiveFileName die konkrete Flashdatei festlegen und dann
verfahren wie bei Verarbeitung von „nicht-latebound“-Flashdaten.
5.5 Alternatives Flashprojektverzeichnis
Normalerweise werden Flash-Laufzeitprojekte in das zugehörige Basisprojekt installiert, so

dass zur Laufzeit alle benötigten Datenbanken im selben Projektverzeichnis liegen. Für den
Fall, dass sich mehrere Basisprojekte ein Flashprojekt teilen, besteht die Anforderung,
dieses Flashprojekt zentral abzulegen und für alle Basisprojekte zugänglich zu machen, um
ein Duplizieren des Flashprojekts zu verhindern.
Gelöst wird diese Anforderung durch die Konfiguration eines zentralen Verzeichnisses für
Flashprojekte in der MCD3D_PROJECTS.INI.
Hier wird mit dem Konfigurationsparameter MCD3D_FlashProjectDirectory in der Sektion

[MCD3D_FLASH] über einen relativen oder absoluten Pfad das zentrale
Flashprojektverzeichnis angegeben. Relative Pfade haben wie gewöhnlich das
Konfigurationsverzeichnis als Bezugspunkt, oder aber das aktuelle Arbeitsverzeichnis, falls
die entsprechende Umgebungsvariable nicht gesetzt ist.
Folgende Bedingungen müssen berücksichtigt werden:
Sei <FlashProjectRootDir> das zentrale Verzeichnis, in das Flashprojekte abgelegt werden

sollen.
a) Alle Flashprojekte, die gleichzeitig in dieses Verzeichnis installiert werden sollen, müssen
aus ODX-Elementen „FLASH“ unterschiedlichen Namens (SHORT-NAME) erzeugt
34 6. Textdatenbanken V14.0.0 / 31.10.2019
worden sein, da pro FLASH-Element eine Laufzeitdatenbank mit Namen

FLASH_<FLASH-SHORT-NAME>.db/.key angelegt wird. Diese Dateien dürfen nicht
überschrieben werden.
b) Die Namen (SHORT-NAME) der ECU-MEMs müssen über alle gemeinsam abgelegten
Flashprojekte hinweg eindeutig sein, da pro SESSION-Element eine Laufzeitdatenbank
mit Namen <ECU-MEM-SHORT-NAME>_<SESSION-SHORT-NAME>.db/.key erzeugt
wird. Die globale Eindeutigkeit des ECU-MEM-SHORT-NAME ist gemäß ODX gefordert,
und der MCD-Kernel verlässt sich darauf.
c) Wenn ein Flashprojekt zu einem ODX-Element „FLASH“ mit Namen X in das zentrale
Verzeichnis installiert wird, das schon ein Projekt zu diesem FLASH-Namen X enthält, so
müssen die beiden ODX-Flash-Projekte dieselben ECU-MEMs und SESSIONs enthalten,
damit alle alten Laufzeitdatenbanken vollständig überschrieben werden. Grundsätzlich ist
jedoch aufgrund der möglichen, schwer zu identifizierenden Fehler davon abzuraten.
d) Pro MCD-Kernel-Sitzung kann höchstens ein zentrales Flashprojektwurzelverzeichnis

konfiguriert werden. Die Konfiguration muss erfolgen, bevor ein Projekt, das dieses
Verzeichnis nutzen soll, geladen wird.
e) In dem konfigurierten Flashprojektwurzelverzeichnis müssen alle Laufzeitdatenbanken

und die Textdateien flach abgelegt sein. Unter Linux reichen Verknüpfungen, unter
Windows müssen es die tatsächlichen Dateien sein.
f) Der Suchalgorithmus für die Flashdaten ist unabhängig von der Einstellung eines
zentralen Flashprojektverzeichnisses, d.h. ist ein solches konfiguriert und sollen die
Flashdaten ebenfalls in diesem zentralen Verzeichnis gesucht werden, muss dies durch
eine entsprechende Einstellung des Konfigurationsparameters
MCD3D_FlashDataRootDirectory in der MCD3D_PROJECTS.INI gefordert werden.
g) Die Verwendung eines alternativen Flashprojektverzeichnisses schließt die gleichzeitige

Ablage von Flashdaten im Basisprojekt aus.
6 Textdatenbanken
Der VW-MCD implementiert Textdatenbanken zum effizienten und ressourcenschonenden
Umgang mit Zeichenketten sowohl in Bezug auf Laufzeitdatengrößen als auch zur Laufzeit
selbst. Hierbei wird eine Zeichenkette einem Schlüssel zugeordnet, und in den
verwendenden Objekten wird der Schlüssel statt der Zeichenkette selbst gespeichert,
während die Zeichenkette in eine Textdatenbank eingetragen und bei Bedarf geladen wird.
Zeichenketten sind hierbei ODX-Strings aller Art, die beim Konvertieren eines ODX-Projekts
in Laufzeitdaten identifiziert werden, außerdem auch generierte intern verwendete
Zeichenketten wie Bezeichner für Objektreferenzen.
Eine Textdatenbank eines Laufzeitdatenprojekts besteht aus vier Dateien

AStringData.data(.gz), AStringData.idx(.gz), UStringData.data(.gz) und UStringData.idx(.gz).
Die AStringData-Dateien beziehen sich auf A_ASCIISTRING-Zeichenketten, die
V14.0.0 / 31.10.2019 6. Textdatenbanken 35
UStringData-Dateien auf die in der Regel geringere Anzahl der A_UNICODE2STRING-

Zeichenketten. Die .data-Dateien enthalten die Zeichenketten, die .idx-Dateien die Schlüssel
und alle Informationen zum wahlfreien Zugriff auf die Zeichenketten.
Alle vier Dateien werden bei der Konvertierung durch den VW-MCD ODX-Converter gzip-
komprimiert, wenn nicht beim Aufruf des ODX-Converters anders angegeben.
Der VW-MCD MCD-Kernel prüft beim Laden eines Laufzeitdatenprojekts zunächst, ob im

Projektverzeichnis eine vollständige nicht komprimierte Textdatenbank, bestehend aus den
vier Dateien AStringData.data, AStringData.idx, UStringData.data und UStringData.idx,
vorliegt. In diesem Fall werden diese Dateien für die interne Nutzung herangezogen.
Liegt im Projektverzeichnis eine unvollständige nicht komprimierte Textdatenbank, so wird

das Laden des Projekts mit einem entsprechenden Fehler abgebrochen.
Liegt keine nicht komprimierte Textdatenbank im Projektverzeichnis, wird die Existenz einer
vollständigen komprimierten Textdatenbank, bestehend aus den vier Dateien
AStringData.data.gz, AStringData.idx.gz, UStringData.data.gz und UStringData.idx.gz,
geprüft, im positiven Fall das Entpacken der Dateien angestoßen und der Inhalt zur internen
Nutzung herangezogen.
Liegt im Projektverzeichnis eine unvollständige komprimierte Textdatenbank, so wird das

Laden des Projekts mit einem entsprechenden Fehler abgebrochen.
Liegt keine komprimierte Textdatenbank im Projektverzeichnis, wird im

Konfigurationsverzeichnis die Existenz einer vollständigen projektübergreifenden
Textdatenbank geprüft, die niemals komprimiert ist und daher aus den vier Dateien
AStringData.data, AStringData.idx, UStringData.data und UStringData.idx besteht. Im
positiven Fall werden diese Dateien für die interne Nutzung herangezogen.
Liegt im Konfigurationsverzeichnis eine unvollständige Textdatenbank, so wird das Laden

des Projekts mit einem entsprechenden Fehler abgebrochen.
Liegt auch im Konfigurationsverzeichnis keine Textdatenbank, so wird davon ausgegangen,

dass die Laufzeitdatenbanken des Projekts mit der Option –notxtdb konvertiert wurden und
somit die Zeichenketten statt Textdatenbankschlüssel enthalten.
Das Entpacken einer etwaigen komprimierten Textdatenbank geschieht in Abhängigkeit von

der aktuellen VW-MCD MCD-Kernel-Konfiguration temporär oder permanent. Beim
temporären Entpacken werden die .data-Dateien der Textdatenbank iterativ in eine
temporäre Datei auf Platte extrahiert, um bei Bedarf einen schnellen Zugriff auf die
enthaltenen Texte zu gewährleisten, ohne die Textdatenbank von Anfang an vollständig im
Speicher halten zu müssen.
Je nach Dateigröße und Schreibgeschwindigkeit des Speichermediums kann das Entpacken

auf schwächer ausgestatteten Systemen unerwartet lange dauern und die Projektladezeiten
maßgeblich erhöhen.
36 7. Logging und Tracing V14.0.0 / 31.10.2019
Bei einem Projektwechsel oder Schließen des Laufzeitdatenprojekts werden die temporären
Dateien wieder gelöscht, sodass die Textdatenbanken bei einer erneuten Verwendung des
Laufzeitdatenprojekts wieder entpackt werden müssen. Dies wirkt sich neben der wiederholt
erhöhten Zeit für das Laden eines Laufzeitdatenprojekts negativ auf die Lebensdauer des
Speichermediums aus, das gegebenenfalls unter den vielen Schreibzugriffen leidet.
Beim permanenten Entpacken werden alle vier Textdatenbankdateien direkt in das

Projektverzeichnis extrahiert und die komprimierten Dateien im Anschluss gelöscht. Der
weitere Prozess entspricht dem Umgang mit einer nicht komprimierten Textdatenbank im
Projektverzeichnis, siehe oben.
7 Logging und Tracing

Der MCD-Kernel nutzt ein eigenes Logmodul. Es unterscheidet eine Vielzahl von Log-
Einstellungen, wie zum Beispiel PANIC, ERROR, WARNING, MESSAGE, TRACE und
DEBUG. Die Konfiguration des zugehörigen Log-Levels erfolgt für den MCD-Kernel in der
Konfigurationsdatei MCD3D_SERVER.INI, siehe Kapitel 3.1.
Als Log-Level kommen folgende Werte in Frage:
• 0: kein Logging
• <= 3: Protokollieren aller Einträge der Kategorie ERROR und höher
• <= 4: Protokollieren aller Einträge der Kategorie WARNING und höher
• <= 5: Protokollieren aller Einträge der Kategorie MESSAGE und höher
• <= 7: Protokollieren aller Einträge der Kategorie TRACE und höher
• <= 8: Protokollieren aller Einträge der Kategorie RECEIVE und höher
• <= 9: Protokollieren aller Einträge der Kategorie SEND und höher
• <= 10: Protokollieren aller Einträge der Kategorie INFORMATION und höher
• <= 15: Protokollieren aller Einträge der Kategorie DEBUG und höher
Darüber hinaus erlaubt der MCD-Kernel die Angabe mehrstufig unterschiedlicher Log-Level
für unterschiedliche Funktionalitäten und Bereiche, beispielsweise für DB-Browsing,
Variantenerkennung, Flash, ECU-Config, Parameterauswertung, Dienstausführung und
PDU-Anbindung. Diese speziellen Log-Level überschreiben die globale Einstellung in beide
Richtungen. Man kann also für ausgesuchte Bereiche auf einem höheren oder niedrigeren
Niveau loggen, als es die globale Konfiguration vorgibt.
Für die schmale Schicht zur Anbindung der Java-Schnittstelle existiert ein eigener Log-Level-
Konfigurationsparameter „MCD3D_Java_LogLevel“.
Der MCD-Kernel schreibt unter Windows seine Log-Dateien als Textdatei standardmäßig in
ein Verzeichnis <Ausführungslaufwerk:>\log, wenn ein solches Verzeichnis existiert.
Gibt es dieses Verzeichnis nicht, wird geprüft, ob ein Konfigurationsverzeichnis gesetzt ist.
V14.0.0 / 31.10.2019 7. Logging und Tracing 37
Ist dieses Verzeichnis nicht definiert, wird das aktuelle Arbeitsverzeichnis als Log-
Verzeichnis angenommen.
Alternativ zur Verwendung des so ermittelten Verzeichnisses ist das Log-Verzeichnis über
den Eintrag MCD3D_LogDirectory der MCD3D_SERVER.INI konfigurierbar. Die Angabe
kann als relativer oder absoluter Pfad vorgenommen werden, wobei relative Pfade als
Bezugspunkt ebenfalls das definierte Konfigurationsverzeichnis oder das aktuelle
Arbeitsverzeichnis annehmen. Man beachte, dass ein so konfiguriertes Logverzeichnis beim
Programmstart existieren muss, damit es genutzt wird.
Etwaige Pfadangaben können mit Slashes („/“) oder doppelten Back-Slashes („\\“) notiert
sein. Leerzeichen im Pfad erfordern Hochkommata.
Unter Linux findet man die Log-Dateien im Verzeichnis /var/opt/vw/log, soweit nicht anders
angegeben.
Zur Unterstützung von Logging aus Java-Jobs heraus hinterlegt der MCD-Kernel das nach
obigen Regeln identifizierte Log-Verzeichnis als Wert der Java System-Property
„VW_MCD_JOB_LOG_DIR“, die im Job-Code als Ablage jobspezifischer Log-Informationen
genutzt werden kann. Dies ermöglicht das Schreiben plattformunabhängiger Jobs, die sonst
keine Möglichkeit haben, das konfigurierte Log-Verzeichnis zu ermitteln. Man beachte, dass
diese Property nur informativen Charakter hat und nicht zur Konfiguration des
Logverzeichnisses genutzt werden kann.
Der eingestellte Log-Mechanismus basiert auf einem Ringpuffer, so dass nach Ausschöpfen
der maximalen Log-Kapazität – konfigurierbar in Anzahl und Größe der Log-Dateien,
Voreinstellung 5x1024K, die jeweils ältesten Daten überschrieben werden.
Das Log-Format genügt folgender Grammatik:
Logeintrag ::= <Kennung>LEER<Zeitstempel>LEER.<ThreadID>LEER.<Kontext>LEER<Meldung>
Kennung ::= P|E|W|M|T|R|S|I|D
Zeitstempel ::= <Datum>LEER<Uhrzeit>

Datum ::= <JJ><MM><TT>
Uhrzeit ::= <hh><mm><ss>.<dddddd>
Kontext ::= [<Datei>:<Zeilennummer>]
ThreadID ::= Thread ID, vierstellig
Datei ::= Datei, in der die Meldung geschrieben wurde, bis zu 32 Zeichen
Zeilennummer ::= Zeile, in der die Meldung geschrieben wurde, bis zu vier Stellen
Meldung ::= Protokolleintrag
<JJ> ::= Jahresangabe, zweistellig
<MM> ::= Monatsangabe, zweistellig

38 7. Logging und Tracing V14.0.0 / 31.10.2019
<TT> ::= Tagesangabe, zweistellig
<hh> ::= Stundenangabe, zweistellig
<mm> ::= Minutenangabe, zweistellig
<ss> ::= Sekundenangabe, zweistellig
<dddddd> ::= Mikrosekunden, sechsstellig
P : Panic
E : Error
W : Warning
M : Message
T : Trace
R : Receive
S : Send
I : Information
D : Debug
Abbildung 7. Grammatik eines Eintrags in der mcd3dserver-Logdatei
Beispiel: Eine fehlerhafte PDU Länge wird bei der Auswertung der Parameter erkannt
T 100720 094525.699320 . 2040 [MCDResponseParameterImpl.cpp : 568] ---> provideFieldParameter –
DTCAndStatusRecord
T 100720 094525.699446 . 2040 [MCDResponseParameterImpl.cpp : 681] -- END-OF-PDU-FIELD; item byte
size variable; at least one item
T 100720 094525.699590 . 2040 [MCDResponseParametersImpl.cpp : 522] ---> createResponseParameters
for PDU 78
T 100720 094525.699710 . 2040 [MCDResponseParametersImpl.cpp : 524] -- handling 2 DB parameters
T 100720 094525.699855 . 2040 [MCDResponseParameterImpl.cpp : 320] ---> provideSimpleParameter –

DTCRecord
E 100720 094525.700289 . 2040 [DbServiceResponseHelper.cpp : 456] MCD3D Exception in
asam::database::helper::DbServiceResponseHelper::performStandardLengthExtraction: 0xE519 ("E519;803;a
calculation of a CompuMethod failed, e.g. boundaries of intervals overlap at Compu Method Scale Linear") /
0x691C ("691C;VWMCD: Invalid parameter length. Parameter DTCRecord - (sub) PDU bytes 78 - byte size 1 -
expected byte size 3.")
T 100720 094525.715004 . 2040 [MCDResponseParameterImpl.cpp : 807] ---> provideStructureParameter -
StatusOfDTC_DtcStatusDataType_1Byte_STRUCTURE
E 100720 094525.715173 . 2040 [DbServiceResponseHelper.cpp : 410] MCD3D Exception in
asam::database::helper::DbServiceResponseHelper::skipBytes: 0xD043 ("D043;803;An internal error occurred in
the MCD3 Server. See vendor specific code for details.") / 0x1835 ("1835;VWMCD: Extracting data from
response PDU failed. Current PDU bytes: 78; current PDU size: 1; number of bytes to skip: 3.")
V14.0.0 / 31.10.2019 8. Fehlerbehandlung 39
8 Fehlerbehandlung
Im Standard ASAM MCD 3.0.0 ist eine Fehlerklasse MCDError mit den Attributen
Fehlercode, Fehlerbeschreibung, Gewicht, spezifischer Fehlercode und spezifische
Fehlerbeschreibung definiert. Während die ersten drei Eigenschaften standardisiert sind,
können in den restlichen Feldern implementierungsspezifische Informationen abgelegt
werden.
Mit ASAM MCD3-D 2.00.02 sind für die jeweiligen Fehlernummern Fehlertexte spezifiziert
worden, die aus Kompatibilitätsgründen beibehalten werden. Die mit den Fehlernummern
verbundene Schwere des Fehler, ausgedrückt über Elemente des Aufzählungstyps
MCDSeverity, ist für alle Fehler auf MCDSeverity.eERROR (0x803) festgelegt worden.
Die VW-MCD-Implementierung sieht für jeden Standard-Fehlercode mindestens ein

spezifisches Pendant vor. Nicht alle sind jedoch derzeit in Verwendung.
Mit jedem benutzten Fehlercode ist ein statischer Fehlertext verbunden, der zur Laufzeit
gegebenenfalls mit Kontextinformationen gefüllt und so komplettiert als spezifischer
Fehlertext in das MCDError-Objekt eingetragen wird.
8.1 Standardisierte Fehlertexte
Fehlernummer Fehlertext
0x0000 0000;803;Indicates that no error had occured.
0xC010 C010;803;invalid type of input parameter
0xC011 C011;803;invalid MCDObjectType
0xC012 C012;803;invalid MCDObjectType for Communication Primitives
0xC013 C013;803;the given data base object has an invalid type
0xC014 C014;803;parameter out of range
0xC019 C019;803;ShortName invalid
0xC01A C01A;803;Communication Primitive type invalid for this location
0xC01E C01E;803;The static DynIdDefineService cannot add dynamic parameters.
0xC01F C01F;803;Index Parameter not inside available range
0xC020 C020;803;Object with name not found
0xC021 C021;803;invalid AccessKey string(wrong order, wrong type of Locationtype)
0xC022 C022;803;AccessKey : Protocol invalid
0xC023 C023;803;AccessKey : FunctionalGroup invalid
0xC024 C024;803;AccessKey : BaseVariant invalid
0xC025 C025;803;AccessKey : Variant invalid
0xC026 C026;803;AccessKey : MultipleEcuJob invalid
0xC030 C030;803;Parametertype is not eEND_OF_PDU.

40 8. Fehlerbehandlung V14.0.0 / 31.10.2019
0xC031 C031;803;The value can not be converted into the expected type.
0xC032 C032;803;This error code indicates that not some request parameter have not been assigend valid values.
0xC033 C033;803;Indicates that a CODED-CONST or PHYS-CONST parameter can not change the value.
0xC035 C035;803;value of parameter 1 is greater than value of parameter 2
0xC036 C036;803;The logical link is not part of the selected vehicle information table
0xD010 D010;803;method not allowed in state eINITIALIZED
0xD011 D011;803;method not allowed in state ePROJECT_SELECTED
0xD012 D012;803;method not allowed in state eLOGICALLY_CONNECTED
0xD013 D013;803;method is not allowed in state eDBPROJECT_CONFIGURATION
0xD014 D014;803;The internal object for the project could not be created
0xD015 D015;803;The internal object for the logical link could not be created
0xD016 D016;803;Logical Link Queue full
0xD017 D017;803;deleting of Logical Link not possible, not all of its Subobjects are deleted. See vendor specific code for details.
0xD018 D018;803;method not allowed in state eCREATED
0xD019 D019;803;method not allowed in state eOFFLINE
0xD01A D01A;803;method not allowed in state eONLINE
0xD01B D01B;803;method not allowed in state eCOMMUNICATION
0xD01D D01D;803;method not allowed in state eIDLE
0xD01E D01E;803;method not allowed in state ePENDING
0xD01F D01F;803;method not allowed in state eNOT_REPEATING
0xD020 D020;803;method not allowed in state
0xD021 D021;803;This error is thrown in case a method is called in an invalid state of the associated or a dependent object.
0xD022 D022;803;Method is not allowed in case the MCDInterface Object represents a DoIP Module
0xD038 D038;803;synchronous execution not allowed
0xD039 D039;803;asynchronous execution not allowed
0xD03A D03A;803;repeated execution not allowed
0xD03B D03B;803;repeated execution of Service can not be stopped
0xD03C D03C;803;Service execution can not be canceled
0xD03D D03D;803;MCDResult has type eREQUEST_ONLY; no response parameter available
0xD03E D03E;803;MCDResult has type eREPONSE_ONLY; no request parameter available
0xD040 D040;803;The parent object has the wrong type
0xD041 D041;803;There is no active object available
0xD042 D042;803;The client holds a reference to an object which has no connection to the server anymore
0xD043 D043;803;An internal error occurred in the MVCI diagnostic Server. See vendor specific code for details.
0xD044 D044;803;Execution of a job, which supports dynamically reduced results, is only in dynamic mode possible.
0xD046 D046;803;service can not created, because semantic attribute is used more than once.
0xD047 D047;803;Method is DataComPrimitive.
0xD048 D048;803;Method is an AccessComPrimitive.
0xD04A D04A;803;method not allowed in state eACTIVITY_IDLE
0xD04B D04B;803;method not allowed in state eACTIVITY_RUNNING.
0xD04C D04C;803;method not allowed in state eACTIVITY_SUSPENDED
0xD04D D04D;803;method not allowed in state eACTIVITY_IDLE
0xD04E D04E;803;method not allowed in state eACTIVITY_RUNNING.
0xD04F D04F;803;The execution of the data primitive has failed.
0xD052 D052;803;The array contains only elements with the same name. It is not possible to get one of them by method getItemByName.
0xD053 D053;803;Filter can not set because service was started.
0xD054 D054;803;The execution of the DiagComPrimitive MCDProtocolParameterSet was faulty.
0xD055 D055;803;Indicates that the related actions or services have been executed in wrong sequence. Correct sequences are described in the
specification document.
0xD056 D056;803;The FlashJob is the only MCDDataPrimitive which can not be executed repeated.
0xD057 D057;803;Indicates that an ECU returned a wrong value for a CODED-CONST / PHYS-CONST parameter.
0xD058 D058;803;Indicates that a MCDResponse object has no response parameter because the execution failed.
0xD059 D059;803;Indicates that a MCDRequestParameter object has no corresponding request parameter with length key information.
0xD05A D05A;803;Indicates that the DynId is CODED-CONST.
0xD05B D05B;803;Indicates that a DynId is already used. Thrown while trying to executeAsync a MCDDynIdDefineComPrimitive.
0xD05D D05D;803;Indicates that this request has no D-PDU information.
0xD05F D05F;803;Indicates that the feature the Client wants to use is not available (e.g. at Service the feature suppress positive response).
0xD066 D066;803;The requested flash data is not latebound.
0xD067 D067;803;The given file name does not match against the filename pattern.
0xD073 D073;803;Method is not allowed for this parameter type.
0xD089 D089;803;There is no interface connected
0xD090 D090;803;The D-PDU API call has failed
0xD091 D091;803;The optional D-PDU API is not supported from the D-Server
0xD093 D093;803;The value cannot be determined completely, e.g. because no value has been set.
0xD0AC D0AC;803;The conversion from coded-type to physical-type fails for some configuration items.
0xD0AD D0AD;803;The PDU Timestamp can not be determined.
0xD0AE D0AE;803;Not all ReadDiagComPrimitives were executed.
0xD0AF D0AF;803;The Write-/ReadDiagComPrimitives need to be executed in the order given by the ODX Data.
0xD0B1 D0B1;803;The VCI access layer is already prepared.
0xD0B2 D0B2;803;The VCI access layer is not prepared.
0xD0B3 D0B3;803;The PhysicalVehicleLink cannot be determined
0xD0B4 D0B4;803;Operation is not allowed until a VIT is selected
0xD0B5 D0B5;803;Only allowed in MCDInterface state eREADY
0xD0B6 D0B6;803;The protocol of the logical is not supported by the D-Server
0xD0B7 D0B7;803;the file with the given name could not be found
0xE010 E010;803;MCD 2 data access impossible. The vendor specific part contains detailed information about the error.
0xE011 E011;803;Error while parsing data base. The vendor specific part contains detailed information about the error.
0xE012 E012;803;Information not available in Db
0xE013 E013;803;Object not found in data base. The vendor specific part contains detailed information about the error.
0xE014 E014;803;There is no length information available.
0xE016 E016;803;There is no default value available.
0xE017 E017;803;The consistency check of the data base failed. This check is made when selecting a project, loading a new ECUMem or when get
additional ECUMems.
0xE018 E018;803;While getting segments of flash data (file) the end was already reached.
0xE020 E020;803;The given data of the FlashSegment is malformed.
0xE021 E021;803;The MCDFlashDataFormat is not of type eUSER_DEFINED
0xE022 E022;803;The parameter is not a numerical value.
0xE510 E510;803;Resource not available
0xE511 E511;803;The MCDInterfaceResource does not support monitoring
0xE512 E512;803;Interface not supported
0xE513 E513;803;Method not supported

0xE514 E514;803;System timeout
0xE515 E515;803;MUX switch value is not defined in ODX.
0xE516 E516;803;System overflow
0xE517 E517;803;System division by zero
0xE518 E518;803;System: CompuMethod TAB-Interpolated has an internal error.
0xE519 E519;803;System : Boundaries of intervals overlap at CompuMethod Scale Linear.
0xE51B E51B;803;A subsystem function call failed.
0xEA10 EA10;803;no connection to location
0xEA11 EA11;803;ECU connection interrupted
0xEA12 EA12;803;connection to hardware resource failed.
0xEA13 EA13;803;disconnection from hardware resource failed.
0xEA14 EA14;803;Indicates that one of the addressed ECUs did not respond. Leads to execution state eFAILED.
0xEA15 EA15;803;The D-server has lost the communication with the VCI
0xEA16 EA16;803;A hardware failure within the VCI has occurred
0xEA17 EA17;803;the control primitive MCDVariantIdentificationAndSelection has not been executed or the execution has failed
0xEA18 EA18;803;method not allowed for this location type
0xF010 F010;803;method not allowed, MCDSystem is eLOCKED_BY_ANOTHER_OBJECT
0xF011 F011;803;method not allowed, Logical Link is eLOCKED_BY_ANOTHER_OBJECT
0xF012 F012;803;method not allowed, Logical Link is eLOCKED_BY_THIS_OBJECT
0xF013 F013;803;method not allowed, Logical Link is eUNLOCKED
0xF014 F014;803;method not allowed, System is eLOCKED_BY_THIS_OBJECT
0xF015 F015;803;method not allowed, System is eUNLOCKED
Abbildung 8. Standardisierte Fehlertexte
8.2 Herstellerspezifische Fehlertexte
Fehlernummer Fehlertext
0x0000 0000;VWMCD:
0x1000 1000;VWMCD:
0x1010 1010;VWMCD:
0x1020 1020;VWMCD:
0x1030 1030;VWMCD:
0x1040 1040;VWMCD:
0x1050 1050;VWMCD:
0x1060 1060;VWMCD:
0x1070 1070;VWMCD:
0x1080 1080;VWMCD:
0x1090 1090;VWMCD:
0x10A0 10A0;VWMCD:
0x10B0 10B0;VWMCD:
0x10C0 10C0;VWMCD:
0x10D0 10D0;VWMCD:
0x10E0 10E0;VWMCD:
0x10F0 10F0;VWMCD:
0x1100 1100;VWMCD:
0x1110 1110;VWMCD:
0x1120 1120;VWMCD: Unknown internal error.
0x1121 1121;VWMCD: Internal error: weak ptr lock failed; item type %s.
0x1122 1122;VWMCD: Operation not allowed; mux branch already added to multiplexer response parameter.
0x1123 1123;VWMCD: Internal error: %s.
0x1124 1124;VWMCD: Internal error: %s%s.
0x1125 1125;VWMCD: %s: JNI internal error. The enum value %d is out of range: Min:%d Max:%d.
0x1126 1126;VWMCD: JNI internal error. The int to enum cast is invalid. Int value %d cannot be mapped to a valid enum.
0x1127 1127;VWMCD: %s: JNI internal error. The given value %s exceeds the bounds min: %s and max: %s for the datatype %s.
0x1130 1130;VWMCD: Invalid parent object type <%s>. Expected: %s.
0x1131 1131;VWMCD: Invalid parent object type <%s>. Expected: %s or %s.
0x1140 1140;VWMCD: <executeSync> not allowed for communication primitives with runtime mode eCYCLIC or attribute IS-MULTIPLE. Use
<excuteAsync> instead. Failed communication primitive: %s.
0x1150 1150;VWMCD: Invalid transmission mode <%s>.
0x1151 1151;VWMCD: Not able to set the transmission mode <%s> because there is no request found on service <%s>. The current transmission
mode is <%s>.
0x1152 1152;VWMCD: Not able to set the transmission mode <%s> because there is no positive response found on service <%s>. The current
transmission mode is <%s>.
0x1160 1160;VWMCD:
0x1170 1170;VWMCD: Communication primitive insertion failed - logical link queue is full. Maximum number of queued items: %u.
0x1180 1180;VWMCD:
0x1190 1190;VWMCD:
0x11A0 11A0;VWMCD:
0x11B0 11B0;VWMCD:
0x11C0 11C0;VWMCD:
0x11D0 11D0;VWMCD:
0x11E0 11E0;VWMCD: Collection of request parameters is empty.
0x11F0 11F0;VWMCD: Collection of response parameters is empty.
0x1200 1200;VWMCD: Action not allowed for collections with field parameter parent: %s. Parent type %s, parent name %s, item name %s.
0x1201 1201;VWMCD: The parameter %s is already contained in the list of DDLID parameters.
0x1202 1202;VWMCD: Failed to resolve short name path %s by single param algorithm: the runtime parameter %s is of type eFIELD.
0x1210 1210;VWMCD: The semantic attribute %s is not unique, i.e. the current location contains zero or more than one item with this semantic.
0x1220 1220;VWMCD: Action not allowed in activity state eACTIVITY_SUSPENDED: %s. Expected state: %s.
0x1221 1221;VWMCD: Action not allowed in activity state eACTIVITY_SUSPENDED: %s. Expected states: eACTIVITY_IDLE or
eACTIVITY_RUNNING.
0x1230 1230;VWMCD: Action not allowed in activity state eACTIVITY_IDLE: %s. Expected state: %s.
0x1231 1231;VWMCD: Action not allowed in activity state eACTIVITY_IDLE: %s. Expected states: eACTIVITY_SUSPENDED or
eACTIVITY_RUNNING.
0x1240 1240;VWMCD: Action not allowed in activity state eACTIVITY_RUNNING: %s. Expected state: %s.
0x1241 1241;VWMCD: Action not allowed in activity state eACTIVITY_RUNNING: %s. Expected states: eACTIVITY_IDLE or
eACTIVITY_SUSPENDED.
0x1250 1250;VWMCD:
0x1260 1260;VWMCD:
0x1270 1270;VWMCD:
0x1280 1280;VWMCD: Event not allowed in logical link state eCOMMUNICATION: %s.
0x1281 1281;VWMCD: Action not allowed in logical link state eCOMMUNICATION: %s.
0x1282 1282;VWMCD: Action not allowed in logical link state eCOMMUNICATION: %s. Expected state: %s.
0x1283 1283;VWMCD: Action not allowed in logical link state eCOMMUNICATION: %s. Expected states: %s or %s.
0x1290 1290;VWMCD: Event not allowed in logical link state eCREATED: %s.
0x1291 1291;VWMCD: Action not allowed in logical link state eCREATED: %s.
0x1292 1292;VWMCD: Action not allowed in logical link state eCREATED: %s. Expected state: %s.
0x1293 1293;VWMCD: Action not allowed in logical link state eCREATED: %s. Expected states: %s or %s.
0x12A0 12A0;VWMCD: Event not allowed in logical link state eOFFLINE: %s.
0x12A1 12A1;VWMCD: Action not allowed in logical link state eOFFLINE: %s.
0x12A2 12A2;VWMCD: Action not allowed in logical link state eOFFLINE: %s. Expected state: %s.
0x12A3 12A3;VWMCD: Action not allowed in logical link state eOFFLINE: %s. Expected states: %s or %s.
0x12B0 12B0;VWMCD: Event not allowed in logical link state eONLINE: %s.
0x12B1 12B1;VWMCD: Action not allowed in logical link state eONLINE: %s.
0x12B2 12B2;VWMCD: Action not allowed in logical link state eONLINE: %s. Expected state: %s.
0x12B3 12B3;VWMCD: Action not allowed in logical link state eONLINE: %s. Expected states: %s or %s.
0x12C0 12C0;VWMCD:
0x12D0 12D0;VWMCD:
0x12E0 12E0;VWMCD: Action not allowed in service state ePENDING: %s. Expected state: eIDLE. Failed communication primitive: %s.
0x12F0 12F0;VWMCD:
0x1300 1300;VWMCD: Action not allowed in system state eDBPROJECT_CONFIGURATION: %s.
0x1301 1301;VWMCD: Action not allowed in system state eDBPROJECT_CONFIGURATION: %s. Expected state: %s.
0x1302 1302;VWMCD: Action not allowed in system state eDBPROJECT_CONFIGURATION: %s. Expected states: %s or %s.
0x1303 1303;VWMCD: Action not allowed in system state eDBPROJECT_CONFIGURATION: %s. Active project: %s; project to select: %s.
0x1310 1310;VWMCD: Action not allowed in system state eINITIALIZED: %s.
0x1311 1311;VWMCD: Action not allowed in system state eINITIALIZED: %s. Expected state: %s.
0x1312 1312;VWMCD: Action not allowed in system state eINITIALIZED: %s. Expected states: %s or %s.
0x1320 1320;VWMCD: Action not allowed in system state eLOGICALLY_CONNECTED: %s.
0x1321 1321;VWMCD: Action not allowed in system state eLOGICALLY_CONNECTED: %s. Expected state: %s.
0x1322 1322;VWMCD: Action not allowed in system state eLOGICALLY_CONNECTED: %s. Expected states: %s or %s.
0x1330 1330;VWMCD: Action not allowed in system state ePROJECT_SELECTED: %s.
0x1331 1331;VWMCD: Action not allowed in system state ePROJECT_SELECTED: %s. Expected state: %s.
0x1332 1332;VWMCD: Action not allowed in system state ePROJECT_SELECTED: %s. Expected states: %s or %s.
0x1333 1333;VWMCD: Action allowed in system state eINITIALIZED only.
0x1334 1334;VWMCD: Action not allowed in simulation mode.
0x1335 1335;VWMCD: Action not allowed outside simulation mode.
0x1340 1340;VWMCD:
0x1350 1350;VWMCD:
0x1360 1360;VWMCD:
0x1370 1370;VWMCD:
0x1380 1380;VWMCD:
0x1390 1390;VWMCD:
0x13A0 13A0;VWMCD:
0x13C0 13C0;VWMCD: <executeAsync> not allowed for communication primitives with repetition mode eREPEATED. Use <startRepetition> instead.
Failed communication primitive: %s.
0x13C1 13C1;VWMCD: <executeAsync> not allowed for control primitives. Use <executeSync> instead. Failed control primitive: %s.
0x13D0 13D0;VWMCD: Execution start of service %s failed with PDU error %s.
0x13D1 13D1;VWMCD: Execution start of service %s failed with exception: %s

0x13D2 13D2;VWMCD: Execution of service <%s> failed with PDU error code %s, PDU extra error info 0x%08X %s (%s).
0x13D3 13D3;VWMCD: Execution start of service %s failed due to thread creation error %d.
0x13D4 13D4;VWMCD: Execution of service <%s> failed. No final result from job received.
0x13D5 13D5;VWMCD: Execution of service <%s> failed. Too many final results from job received.
0x13D6 13D6;VWMCD: Synchronous execution of service <%s> cancelled by application.
0x13E0 13E0;VWMCD: Cancellation of service <%s> failed. PDUCancelComPrimitive returned PDU error %s.
0x13F0 13F0;VWMCD:
0x1400 1400;VWMCD:
0x1410 1410;VWMCD:
0x1420 1420;VWMCD: <executeSync> not allowed for communication primitives with repetition mode eREPEATED. Use <startRepetition> instead.
Failed communication primitive: %s.
0x1430 1430;VWMCD: Wrong sequence: execute MCDDynIdDefineComPrimitive before MCDDynIdReadComPrimitive and

MCDDynIdClearComPrimitive - dynId %s, definition mode %s.
0x1431 1431;VWMCD: Execution of service %s with addressing mode eFUNCTIONAL only allowed in FUNCTIONAL-GROUP layer.
0x1432 1432;VWMCD: Execution of service %s with addressing mode ePHYSICAL not allowed in FUNCTIONAL-GROUP layer.
0x1433 1433;VWMCD: Invalid call sequence: getFirstBinaryDataChunk was not called before.
0x1434 1434;VWMCD: Monitoring link %s already %s.
0x1440 1440;VWMCD: The DDLID with value %s is already in use.
0x1450 1450;VWMCD: Length key information not available for parameter %s.
0x1451 1451;VWMCD: Table key information not available for parameter %s.
0x1452 1452;VWMCD: DDLID information not available in the current response parameter collection.
0x1453 1453;VWMCD: No matching db item value found in the db item values of this option item with value %s.
0x1454 1454;VWMCD: No matching db %s found in the db.
0x1455 1455;VWMCD: The request for service %s is not available.
0x1456 1456;VWMCD: DTC runtime parameter with name %s not found. Cannot determine DTC value for env data selection.
0x1457 1457;VWMCD: DTC runtime parameter with short name path %s not found. Cannot determine DTC value for env data selection.
0x1458 1458;VWMCD: %s cannot be determined.
0x1459 1459;VWMCD: This configuration record has no configuration id item.
0x1460 1460;VWMCD:
0x1470 1470;VWMCD: No matching DB response template found for the response PDU. See log file for details.
0x1471 1471;VWMCD: PDU delivered response with invalid UniqueResponseID. See log file for details.
0x1472 1472;VWMCD: PDU delivered response with invalid AcceptanceID. See log file for details.
0x1473 1473;VWMCD: PDU delivered response with AcceptanceId invalid for UniqueRespId. See log file for details.
0x1474 1474;VWMCD: The identification of a unique variant failed.
0x1475 1475;VWMCD: The value of the read parameter <%s> with the data from the ECU is not valid.
0x1477 1477;VWMCD: The value of the read parameter <%s> has the wrong length %u (expected: %u, ConfigRecName: %s).
0x1478 1478;VWMCD: The read parameter <%s> is not found in all results of the diag com primitive.
0x1479 1479;VWMCD: The location type is not supported by method %s.
0x1480 1480;VWMCD: \"setDynId\" is not allowed, if the DYN-ID parameter of the corresponding service is CODED-CONST.
0x1481 1481;VWMCD: Operation not possible: the server is locked by another client.
0x1482 1482;VWMCD: %s can be called solely through eKEY parameters.
0x1484 1484;VWMCD: %s can be called solely through eTABLE parameters.
0x1485 1485;VWMCD: Operation %s not possible in state %s.
0x1486 1486;VWMCD: Item %s does not support %s.
0x1490 1490;VWMCD: The server parameter cannot be set, while the server is locked.
0x14A0 14A0;VWMCD: Method %s not supported for parameter type %s. Expected: %s.
0x14B0 14B0;VWMCD: No unit group is set for logical link %s.
0x14B1 14B1;VWMCD: Unit conversion failed: No suitable unit is found in the given unit group %s.
0x14B2 14B2;VWMCD: Unit conversion failed: The units %s and %s do not have the same physical dimension.
0x14B3 14B3;VWMCD: Diag com primitive %s is marked as not executable.
0x14B4 14B4;VWMCD: Set unit group at logical link failed: The unit group with short name %s not found.
0x14B5 14B5;VWMCD: Set unit group at logical link failed: The unit group %s is not of category eCOUNTRY.
0x14B6 14B6;VWMCD: Performing <%s> not possible. An instance of <%s> was already created.
0x14B7 14B7;VWMCD: Action <%s> failed for input value %s. Internal conversion error! %s
0x1800 1800;VWMCD: Invalid file name - mustn't be empty!
0x1801 1801;VWMCD: File <%s> could not be opened! Check system configuration.
0x1802 1802;VWMCD: Conversion of %c to decimal value failed. Check input character.
0x1803 1803;VWMCD: Conversion from enum to string failed - unknown enum value %d.
0x1804 1804;VWMCD: Conversion from string to enum failed - unknown enum string %s.
0x1805 1805;VWMCD: The requested item <%s> is not available.
0x1806 1806;VWMCD: PDURegisterEventCallback at PDU module=%u, link=%d failed with PDU error %s.
0x1807 1807;VWMCD: Response object creation failed due to empty request or result data. Request data size: %d. Result data size: %d.
0x1808 1808;VWMCD: Dynamic cast failed. Source type: %s. Target type: %s.
0x1809 1809;VWMCD: Cannot determine multiplexer case. Invalid switch key %s.
0x180A 180A;VWMCD: Cannot determine environment data set. Invalid diagnostic trouble code %d.
0x180B 180B;VWMCD: Collection of responses is empty.
0x180C 180C;VWMCD: Invalid result type <%s>. Expected: %s or %s.
0x180D 180D;VWMCD: The directory \"%s\" is not writeable.
0x180E 180E;VWMCD: Database object set failed - <%s> empty.
0x180F 180F;VWMCD: Invalid flash data format <%s>. Expected: %s.
0x1810 1810;VWMCD: Flash data retrieval not initialized.
0x1811 1811;VWMCD: Collection of results is empty.
0x1812 1812;VWMCD: PDUGetModuleIds failed with PDU error %s
0x1813 1813;VWMCD: Protocol parameter <%s> not initialized.
0x1814 1814;VWMCD: Protocol parameter <%s> not set: PDUSetComParam failed with PDU error %s.
0x1815 1815;VWMCD: Protocol parameter <%s> not retrieved: PDUGetComParam failed with PDU error %s.
0x1816 1816;VWMCD: PDUGetVersion failed with PDU error %s
0x1817 1817;VWMCD: action not allowed for Protocol parameter <%s> - not a simple or complex root parameter.
0x1818 1818;VWMCD: ProtocolParameter %s: %sFIELD length %u exceeds maximum length %u of PDU ComParam
0x1819 1819;VWMCD: PDU parameter %s is of unexpected type %s.
0x181A 181A;VWMCD: Data type mismatch for ProtocolParameter %s - MCD data type: %s, PDU data type: %s
0x181B 181B;VWMCD: ProtocolParameter %s: number of entries %u exceeds maximum number of entries %u provided with PDUGetComParam.
0x181C 181C;VWMCD: Cannot access further binary flash data - end of segment reached.
0x181D 181D;VWMCD: Binary flash data incomplete.
0x181E 181E;VWMCD: Binary flash data start address 0x%08X not found.
0x181F 181F;VWMCD: PDUConstruct failed with PDU error %s.
0x1820 1820;VWMCD: PDUDestruct failed with PDU error %s.
0x1822 1822;VWMCD: Invalid clamp <%s> - cannot be handled.
0x1823 1823;VWMCD: PDUIoCtl %s failed with PDU error %s.
0x1824 1824;VWMCD: PDUIoCtl returned invalid data.
0x1825 1825;VWMCD: Action not allowed while logical command queue not empty: %s.
0x1826 1826;VWMCD: Invalid PDU result item retrieved for communication primitive <%s>.
0x1827 1827;VWMCD: Element access failed in <%s> for communication primitive <%s>. Requested element: %s.
0x1828 1828;VWMCD: Set value as string failed for input type <%s>. Input is empty!
0x1829 1829;VWMCD: Action <%s> failed. Invalid data type <%s>!
0x182A 182A;VWMCD: Action <%s> failed for input value %s. Internal conversion error!
0x182B 182B;VWMCD: Convert and copy value failed. Input is empty!
0x182C 182C;VWMCD: Action <%s> failed. Reason: %s!
0x182D 182D;VWMCD: No vehicle information selected!
0x182E 182E;VWMCD: Cannot find reference target: <%s> with short name <%s>!
0x182F 182F;VWMCD: Error collection empty!
0x1830 1830;VWMCD: Parent object of <%s> not available!
0x1831 1831;VWMCD: A vehicle information with name %s has already been or is still selected!
0x1832 1832;VWMCD: Action <%s> failed. The parent DB template contains an invalid number of children %u. Expected: %u.
0x1834 1834;VWMCD: Extracting data from response PDU failed for parameter %s - empty (sub) PDU.
0x1835 1835;VWMCD: Extracting data from response PDU failed. Current PDU bytes: %s; current PDU size: %u; number of bytes to skip: %u.
0x1836 1836;VWMCD: Action <%s> failed. Invalid character %c; expected: %s.
0x1837 1837;VWMCD: Action <%s> not allowed for db location type <%s>.
0x1838 1838;VWMCD: Interface not prepared!
0x1839 1839;VWMCD: <%s> does not represent a late-bound file.
0x183A 183A;VWMCD: <%s> does not match filname/pattern <%s>.
0x183B 183B;VWMCD: File <%s> not found.
0x183C 183C;VWMCD: Response (collection) creation failed due to empty result data.
0x183D 183D;VWMCD: The requested element %s is not available in the context of low-level (hex) services or error results.
0x183E 183E;VWMCD: Flash root directory in ini-file is invalid: %s.
0x183F 183F;VWMCD: Creation of Java VM failed with error code %d.
0x1840 1840;VWMCD: Java job processor <%s> not found. Current class path option: %s.
0x1841 1841;VWMCD: Java job processor method <%s> not found.
0x1842 1842;VWMCD: Java class <%s> not found.
0x1843 1843;VWMCD: Java method <%s> of class <%s> not found.
0x1844 1844;VWMCD: Java object creation of class %s failed.
0x1845 1845;VWMCD: Action <%s> not allowed. Job context required.
0x1846 1846;VWMCD: Java job execution failed.
0x1847 1847;VWMCD: Retrieved PDU event for unexpected PDU primitive handle %d. Expected handle: %d.
0x1848 1848;VWMCD: Flash session not set.
0x1849 1849;VWMCD: Invalid attempt to change (create(Coded)Value, set(Coded)Value) a parameter that is constant. Parameter : %s
0x184A 184A;VWMCD: clampName %s is invalid.
0x184B 184B;VWMCD: Protocol parameter <%s> has an invalid value.
0x184C 184C;VWMCD: Failed to accept unsupported protocol parameters for the logical link %s as they are system wide unaccepted.
0x184D 184D;VWMCD: At least one of the protocol parameters to be set is not supported by the PDU API. See log file for details.
0x184E 184E;VWMCD: Action <%s> not allowed in job context.
0x184F 184F;VWMCD: No file in use.
0x1850 1850;VWMCD: Invalid control primitive type %s. Expected: %s or %s.
0x1851 1851;VWMCD: Length data missing for parameter %s.
0x1852 1852;VWMCD: Length of parameter <%s> not variable.
0x1853 1853;VWMCD: Parameter <%s> is not a table struct and thus cannot take a table key reference.
0x1854 1854;VWMCD: Bus type <%s> not supported by PDU.
0x1855 1855;VWMCD: Invalid byte length: %u.
0x1856 1856;VWMCD: Invalid byte length %u for parameter %s. Current (sub) PDU bytes: %s.
0x1857 1857;VWMCD: Invalid request parameter type: %s (expected types: %s, %s, %s, %s or %s).
0x1858 1858;VWMCD: Invalid response parameter type %s of parameter %s - expected types: %s, %s, %s, %s or %s.
0x1859 1859;VWMCD: New database object could not be created.
0x185A 185A;VWMCD: No valid data type for adjusting: %s (expected: %s).
0x185B 185B;VWMCD: Bit mask contains not allowed characters (other than 0 and 1).
0x185C 185C;VWMCD: PDU data extraction failed for parameter %s. Extracted value %s, expected value: %s.
0x185D 185D;VWMCD: Value creation not allowed for complex parameters. Parameter: %s.
0x185E 185E;VWMCD: Client changed the key of the structure parameter %s, but did not call getParameters before execution. Client has invalid
parameters.
0x185F 185F;VWMCD: Table key parameter value missing for structure parameter %s.
0x1860 1860;VWMCD: No object loader instance is set.
0x1861 1861;VWMCD: No object writer instance is set.
0x1862 1862;VWMCD: Database object could not be added to the repository (object id: %s, pool id: %s).
0x1863 1863;VWMCD: Save object into database failed.
0x1864 1864;VWMCD: Truncate database failed.
0x1865 1865;VWMCD: No variant identified.
0x1866 1866;VWMCD: No variant selected.
0x1867 1867;VWMCD: Service not valid for execution anymore, since in the meantime, a variant has been selected.
0x1868 1868;VWMCD: Logical link creation for base variant %s and variant %s failed: logical link already existing for this base variant.
0x1869 1869;VWMCD: Save object into database failed: %s.
0x186A 186A;VWMCD: The method %s has been called in a VI or VIS context.
0x186B 186B;VWMCD: The converter was not successful for file %s.
0x186C 186C;VWMCD: Method %s has been called before method %s.
0x186D 186D;VWMCD: Method %s has been called before method %s for MCDDbLocation %s.
0x186E 186E;VWMCD: The logical link of base variant %s is not in an idle mode (must be eCREATED).
0x186F 186F;VWMCD: At least one of the logical links in scope of the base variant %s is not in an idle mode (eCREATED). Action not allowed: %s.
0x1870 1870;VWMCD: Dynamically defined local id not set.
0x1871 1871;VWMCD: Protocol type %s not supported (yet). Please contact the MVCI server provider.
0x1872 1872;VWMCD: Parsing of the dynIdParam %s failed: %s.
0x1873 1873;VWMCD: %s not allowed for the protocol type %s. Expected type: %s, %s, or %s.
0x1874 1874;VWMCD: %s failed. More than one db template with type %s found in database.
0x1875 1875;VWMCD: No MCDDbDataRecord selected. Use method setConfigurationRecordValueByDbObject to select one.
0x1880 1880;VWMCD: VciConnect failed with error %s for VCI address %s, port %d
0x1881 1881;VWMCD: VciDisconnect failed with error %s for VCI handle %d
0x1882 1882;VWMCD: PDUModuleConnect failed with error %s for VCI handle %d
0x1883 1883;VWMCD: PDUModuleDisconnect failed with error %s for VCI handle %d
0x1884 1884;VWMCD: VCIAPIConstruct failed with error %s
0x1885 1885;VWMCD: VCIAPIDestruct failed with error %s
0x1886 1886;VWMCD: connection to vehicle communication interface (VCI) lost; PDU error code %s, PDU extra error info 0x%08X %s (%s).
0x1887 1887;VWMCD: connection to vehicle communication interface (VCI) failed.
0x1888 1888;VWMCD: Error of vehicle communication interface (VCI); PDU error code %s, PDU extra error info 0x%08X %s (%s).
0x1889 1889;VWMCD: Error of logical link; PDU error code %s, PDU extra error info 0x%08X %s (%s).
0x1890 1890;VWMCD: Error creating PDU expected responses for DiagComPrimitive / Parameter %s
0x1891 1891;VWMCD: PDUGetObjectId returned unknown ID or failed with PDU error %s for object %s, type %s
0x1892 1892;VWMCD: PDUIoCtrl has mismatch in OutputData for expected data type 0x%08X
0x1893 1893;VWMCD: PDUGetModuleIds delivered empty or invalid list of module data items
0x1894 1894;VWMCD: PDUCreateComLogicalLink failed with PDU error %s for logical link %s
0x1895 1895;VWMCD: PDUDestroyComLogicalLink failed with PDU error %s for logical link %s
0x1896 1896;VWMCD: PDUGetUniqueResponseIdTable failed with PDU error %s for logical link %s
0x1897 1897;VWMCD: PDUSetUniqueResponseIdTable failed with PDU error %s for logical link %s
0x1898 1898;VWMCD: PDU ComParam %s from database not found in PDUGetUniqueResponseIdTable
0x1899 1899;VWMCD: PDUGetUniqueResponseIdTable delivered empty table in function %s
0x189A 189A;VWMCD: PDU timestamp not available
0x189B 189B;VWMCD: failed trying to parse the PDU API root description file (RDF) - %s
0x189C 189C;VWMCD: could not find a PDU API with shortname %s in the PDU API root description file (RDF)
0x189D 189D;VWMCD: missing prefix 'file://' in the URI of the PDU API library with shortname %s in the PDU API root description file (RDF)
0x189E 189E;VWMCD: PDUGetUniqueResponseIdTable size mismatch in function %s
0x189F 189F;VWMCD: IOCTL command %s not supported by PDU API
0x18A0 18A0;VWMCD: Cannot handle unexpected protocol parameter %s.
0x18A1 18A1;VWMCD: PDU Item not available
0x18A2 18A2;VWMCD: Physical vehicle link %s not available for link with access key %s.
0x18B5 18B5;VWMCD: The method execution is allowed only in case of inline flash data.
0x18C0 18C0;VWMCD: Invalid project selection or database format version file missing for project %s.
0x18C1 18C1;VWMCD: Database format version incompatibility: kernel version %s - project version %s.
0x18C2 18C2;VWMCD: Flash database format version incompatibility: kernel version %s - project version %s.
0x18D0 18D0;VWMCD: ECU-Config root directory in ini-file is invalid: %s.
0x18D1 18D1;VWMCD: For option item %s is no parent configuration record set.
0x18E0 18E0;VWMCD: Filesystem error: deletion of %s failed: %s.
0x18E1 18E1;VWMCD: Filesystem error: renaming %s to %s failed. %s.
0x18F0 18F0;VWMCD: Dead singleton reference detected.
0x18FF 18FF;VWMCD: Not implemented yet: %s - parameter name %s!
0x1900 1900;VWMCD: Unexpected PDU link state transition from PDU_CLLST_COM_STARTED to PDU_CLLST_OFFLINE; loss of TCP connection
probable.
0x1910 1910;VWMCD: The property [%s] cannot be set, because it is set to read only.
0x1911 1911;VWMCD: Not able to write the parameter value in the server parameter.
0x1912 1912;VWMCD: Not able to read section [%s] from file <%s>.
0x1913 1913;VWMCD: Not able to write one of the keys in section [%s] from file <%s>.
0x1914 1914;VWMCD: Not able to set property [%s] with value <%s> because the value is not in the list of valid values.
0x1915 1915;VWMCD: Expexted %u bytes to read from file but read %u from file <%s>.
0x1916 1916;VWMCD: The datafile is too long. Expected <%d> bytes of input data in file <%s>.
0x1917 1917;VWMCD: Expexted %u bytes to read, but there are %lu bytes to read from input data file <%s>.
0x1918 1918;VWMCD: Expexted %d bytes to read, but there are %lu bytes to read from input data file <%s>.
0x1919 1919;VWMCD: Invalid value on stream. Expexted %d, going to save %u.
0x1920 1920;VWMCD: Configuration item conversion coded value to physical value failed.
0x1921 1921;VWMCD: The configuration record value is invalid.
0x1922 1922;VWMCD: The configuration record value is invalid because not all read diag com primitives are executed or they are executed in the
wrong order.
0x1923 1923;VWMCD: No scale constraints defined for parameter %s.

0x1924 1924;VWMCD: No matching scale constraint for the coded value %s of parameter %s.
0x1925 1925;VWMCD: Cannot retrieve or compute any value for parameter %s --> scale constraint cannot be determined.
0x1930 1930;VWMCD: The matching request parameter <%s> is not allowed in a positive or negative response of a receive only service.
0x1931 1931;VWMCD: The receive only service <%s> contains a matching request parameter on a positive or negative response. %s
0x1932 1932;VWMCD: Checksum mismatch for flash record <%s>, expected: <%X> but was: <%X>.
0x1933 1933;VWMCD: Mismatch between read and specified number of data records, expected <%u> but was <%u>.
0x1934 1934;VWMCD: %s: The detected number of data bytes <%u> exceeds the allowed maximum <%d>. Record <%.15s...>.
0x1945 1945;VWMCD: The address range within the segment is not continuous.
0x1946 1946;VWMCD: The start address of the segment <%s> is out of all filtered address ranges.
0x1947 1947;VWMCD: The number of bytes within the segment <%s> is not equal to the compressed size.
0x1948 1948;VWMCD: Invalid flash record <%s>. Actual length of data field length: %u bytes; expected: %u bytes.
0x1949 1949;VWMCD: There is no internal constraint available for this parameter. Check the ODX data.
0x194E 194E;VWMCD: Invalid flash record <%s>. Byte count %u not sufficient for address field (%u byte(s)) and checksum (%u byte(s)).
0x194F 194F;VWMCD: Invalid flash record <%s>. Record length %u not sufficient. Cannot determine %s with length %u at position %u.
0x1990 1990;VWMCD: The Java job processor failed with an exception of type: InstantiationException.
0x1991 1991;VWMCD: The Java job processor failed with an exception of type: IllegalAccessException.
0x1992 1992;VWMCD: The Java job processor failed with an exception of type: ClassNotFoundException.
0x1993 1993;VWMCD: The Java job processor failed with an exception of type: LinkageError.
0x1994 1994;VWMCD: The Java job processor failed with an exception of type: NoSuchMethodException.
0x1995 1995;VWMCD: The Java job processor failed with an exception of type: NullPointerException.
0x1996 1996;VWMCD: The Java job processor failed with an exception of type: InvocationTargetException.
0x1A00 1A00;VWMCD: Retrieval of shared pointer from object repository failed - called in <%s>.
0x1B00 1B00;VWMCD: The location context is missing.
0x1C00 1C00;VWMCD: The VCI access layer is already prepared by the method %s.
0x1C01 1C01;VWMCD: The VCI access layer is not prepared by the method %s.
0x1C02 1C02;VWMCD: The VCI access layer is not prepared by the method %s, but by the method %s.
0x1C03 1C03;VWMCD: PDUGetResourceStatus failed with error %s for VCI handle %u and resource id %u.
0x1C04 1C04;VWMCD: The interface %s with VCI handle %u is not connected.
0x1C05 1C05;VWMCD: The interface %s with VCI handle %u is not disconnected.
0x1C06 1C06;VWMCD: PDUGetStatus failed with error %s for VCI handle %u.
0x1C07 1C07;VWMCD: Failed to map PDU status 0x%08X to MCDInterfaceStatus. Expected PDU status: PDU_MODST_READY (0x8060),
PDU_MODST_NOT_READY (0x8061), PDU_MODST_NOT_AVAIL (0x8062) or PDU_MODST_AVAIL (0x8063)
0x1C08 1C08;VWMCD: PDUGetTimestamp failed with error %s for VCI handle %u.
0x1C09 1C09;VWMCD: IO-Control <%s> not supported.
0x1C0A 1C0A;VWMCD: The logical link %s is not in state eCREATED.
0x1C0B 1C0B;VWMCD: The option string has an invalid format: %s
0x1C0C 1C0C;VWMCD: Format error in option string at position %ld in \"%.*s\"#FORMAT_ERROR#
0x1C0D 1C0D;VWMCD: Interface %s (module handle %u, module type id %u) not found in pool of interfaces.
0x2000 2000;VWMCD:
0x2010 2010;VWMCD:
0x2020 2020;VWMCD:
0x2030 2030;VWMCD:
0x2040 2040;VWMCD:
0x2045 2045;VWMCD: No item available in the collection.
0x2050 2050;VWMCD:
0x2060 2060;VWMCD: Invalid access key %s. Expected: %s.
0x2062 2062;VWMCD: ECU state chart with semantic %s not found.
0x2065 2065;VWMCD: The database object can not be retrieved by short name (the collection of item short names is empty).
0x2070 2070;VWMCD:
0x2080 2080;VWMCD: For static MCDDynIdDefineComPrimitive objects it is not allowed to modify the parameter list.
0x2090 2090;VWMCD: Index %d out of range [%d;%d).
0x2091 2091;VWMCD: Index %d not found in hash map.
0x20A0 20A0;VWMCD:
0x20B0 20B0;VWMCD: Invalid database object type %s. Expected: %s.
0x20B5 20B5;VWMCD: The given location does not match the existing location context.
0x20C0 20C0;VWMCD:
0x20D0 20D0;VWMCD:
0x20E0 20E0;VWMCD: Invalid object type %s. Expected: %s.
0x20E1 20E1;VWMCD: Invalid object type %s. Expected: %s or %s.
0x20E2 20E2;VWMCD: Invalid object type %s.
0x20E3 20E3;VWMCD: Invalid file object type %s. Expected: %s.
0x20E4 20E4;VWMCD: Object type not defined for %s.
0x20F0 20F0;VWMCD: The creation of a diagnostic communication primitive by type is not allowed for a type %s.
0x2100 2100;VWMCD:
0x2110 2110;VWMCD: Invalid value data type %s. Expected: %s.
0x2111 2111;VWMCD: Invalid value data type %s. Expected: simple data type.
0x2112 2112;VWMCD: Invalid value data type %s.
0x2113 2113;VWMCD: Invalid parameter type %s. Expected: %s.
0x2114 2114;VWMCD: Pattern matching failed due to invalid parameter type %s (parameter short name %s). Expected: %s (parameter short name
%s).
0x2115 2115;VWMCD: Pattern matching failed due to different numbers of parameters. Expected: %u (parameter short name %s); actual: %u
(parameter short name %s).
0x2116 2116;VWMCD: Pattern matching failed due to different numbers of parameters. Expected: %u ; actual: %u .
0x2120 2120;VWMCD:
0x2130 2130;VWMCD: Item %s not found in collection.
0x2131 2131;VWMCD: Item with index %u not found in collection.
0x2132 2132;VWMCD: Item with semantic %s not found in collection.
0x2133 2133;VWMCD: Item with data type %s not found in collection.
0x2134 2134;VWMCD: Property %s not found in the property list.
0x2135 2135;VWMCD: Item with value %s not found in collection.
0x2136 2136;VWMCD: Item with key %s not found in collection.
0x2137 2137;VWMCD: DiagComPrimitives not found.
0x2138 2138;VWMCD: Name not known at configuration data.
0x2139 2139;VWMCD: Configuration Data not found at current logical link.
0x213A 213A;VWMCD: Flash package %s not found on file system.
0x213B 213B;VWMCD: Transition %s not found at current state chart.
0x213C 213C;VWMCD: Item %s not found in project %s.
0x213D 213D;VWMCD: ECU variant data %s not found on file system.
0x213E 213E;VWMCD: MCDMessageFilter item not found in MCDMessageFilters collection.
0x2140 2140;VWMCD: Invalid parameter type %s. Expected: field parameter type eEND_OF_PDU.
0x2141 2141;VWMCD: Invalid parameter type %s. Expected: field parameter type eSTRUCT_FIELD.
0x2142 2142;VWMCD: Cannot extend CP_UniqueRespIdTable of BV or EV link %s.
0x2145 2145;VWMCD: Item with the given name (%s) not found in the database collection.
0x2146 2146;VWMCD: The parameter <%s> to fill is not found in the diag com <%s> of config record <%s>. Check the ODX data: param-snref of diag
com data connector must match one request/response param of the referenced service.
0x2147 2147;VWMCD: The request parameter with the given short name %s is not found in the request %s.
0x2148 2148;VWMCD: The request parameter with the given short name path %s is not found in the request %s.
0x2150 2150;VWMCD:
0x2160 2160;VWMCD: Short name is empty.
0x2170 2170;VWMCD:
0x2180 2180;VWMCD: %s value %u out of range [%u;%u].
0x2181 2181;VWMCD: value out of range
0x2182 2182;VWMCD: DDLID value %s not in the list of supported local IDs.
0x2183 2183;VWMCD: No response parameters stored for this DDLID %s.
0x2184 2184;VWMCD: DTC level (%u) out of range: expected range is 1...255.
0x2185 2185;VWMCD: lower/upper limit of DTC level are swapped (%u/%u).
0x2186 2186;VWMCD: Invalid definition mode of DynDefinedSpecTable (%s).
0x2187 2187;VWMCD: Filter mask / pattern value out of range. Maximum no of bytes: %u; actual: %u.
0x2188 2188;VWMCD: JNI Failure: Input string contains invalid non-ASCII characters.
0x2190 2190;VWMCD:
0x21A0 21A0;VWMCD: The MCDValue has the wrong datatype.
0x21A1 21A1;VWMCD: No registered MCDConfigurationRecordEventHandler for the given index %u found.
0x21A3 21A3;VWMCD: Item with the given key (%s) not found in the database collection.
0x21A4 21A4;VWMCD: Try to set invalid value <%s> for texttable parameter. Check list of valid texttable values.
0x21B0 21B0;VWMCD: Table row with key %s not found.
0x21B1 21B1;VWMCD: The value (%s) in table key parameter (%s) does not match the predefined const value. Error while trying to find table row for
parameter (%s).
0x21B4 21B4;VWMCD: Diag. com. primitive with the connector semantic %s not found.
0x21B8 21B8;VWMCD: The connector semantic is empty.
0x21BA 21BA;VWMCD: No semantic available.
0x21BB 21BB;VWMCD: The given parameter is not set.
0x21BF 21BF;VWMCD: The given parameter does not have a method getShortName.
0x21C4 21C4;VWMCD: The given parameter with shortname %s already exists in the collection.
0x21D4 21D4;VWMCD: The logical link %s is not from the current selected VehicleInformation &s.
0x21E0 21E0;VWMCD: Monitoring: Message filtering not supported. Method not allowed: %s.
0x21F1 21F1;VWMCD: Configuration record item value update by config item %s failed: %s.
0x3000 3000;VWMCD: Access to database element failed.
0x3001 3001;VWMCD: Access to database element failed - %s not set.
0x3002 3002;VWMCD: Access to database element %s not allowed for object of type %s - parameter %s.
0x3003 3003;VWMCD: Access to database element failed - %s not set for %s (%s).
0x3004 3004;VWMCD: Not enough database elements for computing code conversion: No program code available.
0x3005 3005;VWMCD: Not enough database elements for computing code conversion: Neither code file nor byte stream available.
0x3006 3006;VWMCD: Not enough database elements for computing code conversion: No entry point available.
0x3007 3007;VWMCD: Not enough database elements for computing code conversion: Open class file %s failed.
0x3008 3008;VWMCD: Not enough database elements for computing code conversion: Read from class file %s failed.
0x3009 3009;VWMCD: Not enough database elements for computing code conversion: No syntax available, expected JAVA, JAR or CLASS.
0x300A 300A;VWMCD: Cannot determine suitable location context for pool id %s.
0x300B 300B;VWMCD: Project not found: %s.
0x300C 300C;VWMCD: COMPU-DEFAULT-VALUE not available for parameter %s.
0x3010 3010;VWMCD: The consistency check of the database failed.
0x3011 3011;VWMCD: Expected exactly 1 matching file for MCDDbDataRecord for file <%s> but found %u matching file(s).
0x3012 3012;VWMCD: At least the semantic %s is set for more than one MCDDbEcuStateChart, but duplicates are not allowed.
0x3013 3013;VWMCD: EnvData parameter %s cannot be stored; DTC value %d not unique in corresponding envDataDesc.
0x3014 3014;VWMCD: Short name reference %s (%s) cannot be resolved in current context %s (%s).
0x3015 3015;VWMCD: ALL-VALUE EnvData parameter %s cannot be stored in EnvDataDesc %s; an ALL-VALUE EnvData is already set.
0x3016 3016;VWMCD: The current location contains more than one %s.
0x3017 3017;VWMCD: Inconsistent database: %s not available.
0x3018 3018;VWMCD: Element %s removed from database and marked as invalid. Action not allowed: %s.
0x3020 3020;VWMCD:
0x3030 3030;VWMCD: No physical default value available for parameter %s.
0x3040 3040;VWMCD:
0x3050 3050;VWMCD:
0x3060 3060;VWMCD:
0x3070 3070;VWMCD:
0x3080 3080;VWMCD:
0x3081 3081;VWMCD: The data referenced from the MCDDbFlashSegment %s is malformed.
0x3082 3082;VWMCD: The flash data format is not user defined.
0x3083 3083;VWMCD: The binary ECU config data is malformed.
0x3084 3084;VWMCD: No physical default value available for option item %s.
0x3085 3085;VWMCD: The value of configuration record %s does not contain enough data for preparation of write diag com primitive %s. Expected
number of bytes: %d. Actual: %d.
0x3090 3090;VWMCD: The method is not allowed for this value data type %s; expected type: %s.
0x3800 3800;VWMCD: Reading data for (object id: %s, pool id: %s) from database file failed: expected no. of bytes: %d; actual no. of bytes: %d.
0x3900 3900;VWMCD: Tried to add invalid/empty item of type %s to database collection.
0x3901 3901;VWMCD: No item available in the database collection.
0x3902 3902;VWMCD: Item with the given index (%d) not found in the database collection.
0x3903 3903;VWMCD: Item with the given type (%s) not found in the database collection.
0x3904 3904;VWMCD: Tried to insert invalid (empty) database reference object into reference collection.
0x3905 3905;VWMCD: Reference collection not available.
0x3906 3906;VWMCD: Reference object does not have any valid object type.
0x3907 3907;VWMCD: No item available in the reference collection. Item %s not found.
0x3908 3908;VWMCD: Reference with the given short name (%s) not found in the reference collection.
0x3909 3909;VWMCD: Reference with the given index (%d) not found in the reference collection.
0x390A 390A;VWMCD: Reference with the given type not found in the reference collection.
0x390B 390B;VWMCD: Reference with the given attribute (%s) not found in the reference collection.
0x390C 390C;VWMCD: Could not open database file: %s; %s.
0x390D 390D;VWMCD: Load object from database failed; object id: %s, pool id: %s.
0x390E 390E;VWMCD: Empty object stream, load object from database failed; object id: %s, pool id: %s.
0x390F 390F;VWMCD: Database object cannot be retrieved: pool id or object id not available.
0x3910 3910;VWMCD: Database object could not be retrieved (object id: %s, pool id: %s).
0x3911 3911;VWMCD: Database object could not be found in the repository (object id: %s, pool id: %s).
0x3912 3912;VWMCD: No item available in the vector.

0x3913 3913;VWMCD: Bit length not available for DiagCodedType eMIN_MAX_LENGTH_TYPE.
0x3914 3914;VWMCD: Information only for DiagCodedType eMIN_MAX_LENGTH_TYPE available.
0x3915 3915;VWMCD: Information only for DiagCodedType eSTANDARD_LENGTH_TYPE available.
0x3916 3916;VWMCD: No bit mask available.
0x3917 3917;VWMCD: No memory layout available: %s (expected: %s or %s).
0x3918 3918;VWMCD: No diagnostic coded type available.
0x3919 3919;VWMCD: Validity type of scale constraint not valid: %s (expected: %s, %s, %s or %s).
0x391A 391A;VWMCD: Response doesn't match any given response in runtime database.
0x391B 391B;VWMCD: No scale constraints available in runtime database.
0x391C 391C;VWMCD: Access to database element failed - DynDefinedSpecTable for the definition mode %s not set.
0x391D 391D;VWMCD: Access to database element failed - DynDefinedSpecTable with short name %s not set.
0x391E 391E;VWMCD: Access to database element failed - no supported dynamic ids for definition mode %s available.
0x391F 391F;VWMCD: MCD Version is not available in database.
0x3920 3920;VWMCD: Invalid system parameter name %s.
0x3921 3921;VWMCD: The intel flash data format is currently not supported.
0x3922 3922;VWMCD: Reference with the given data id (%s) not found in the reference collection.
0x3923 3923;VWMCD: Reference with the given key (%s) not found in the reference collection.
0x3924 3924;VWMCD: No location found that matches the access key string %s.
0x3925 3925;VWMCD: Reference with the given configuration id (%s) not found in the reference collection.
0x3926 3926;VWMCD: Reference with the given semantic (%s) not found in the reference collection.
0x3927 3927;VWMCD: Database object could not be retrieved (object id: %s, pool id: %s); stdexception: %s.
0x3928 3928;VWMCD: The method is not allowed for the parameter with data object prop <%s>. Check the ODX data.
0x3929 3929;VWMCD: No mapping found in MCD3D_PINS.INI for protocol %s.
0x392A 392A;VWMCD: Unable to load or open MCD3D_PINS.INI.
0x392B 392B;VWMCD: No ProtocolParameterSet available for location %s. Possibly no PROT-STACK-SNREF set in protocol %s and use of default
VIT.
0x392C 392C;VWMCD: Illegal comparam reference in diaglayer %s. Comparam %s is not valid in this layer.
0x392D 392D;VWMCD: No valid protocol stack set for location %s, neither at the protocol nor at a logical link suitable for this location. Check the ODX
data.
0x392E 392E;VWMCD: No valid parent protocol set for location %s.
0x392F 392F;VWMCD: Creation of VI(S) control primitive failed due to lack of variant patterns for layer %s.
0x3930 3930;VWMCD: Cable with id %u not found in the CDF.
0x4000 4000;VWMCD: PDU connection failure. %s failed with PDU error %s.
0x4010 4010;VWMCD:
0x4020 4020;VWMCD: PDU disconnection failure. %s failed with PDU error %s.
0x4030 4030;VWMCD:
0x4040 4040;VWMCD: Service execution failed: One of the ECUs didn't respond.
0x5000 5000;VWMCD: Action not allowed in logical link lock state eLOCKED_BY_ANOTHER_OBJECT: %s. Expected state: %s.
0x5001 5001;VWMCD: Action not allowed in logical link lock state eLOCKED_BY_ANOTHER_OBJECT: %s. Expected states:
eLOCKED_BY_THIS_OBJECT or eUNLOCKED.
0x5010 5010;VWMCD: Action not allowed in logical link lock state eLOCKED_BY_THIS_OBJECT: %s. Expected state: %s.
0x5011 5011;VWMCD: Action not allowed in logical link lock state eLOCKED_BY_THIS_OBJECT: %s. Expected states:
eLOCKED_BY_ANOTHER_OBJECT or eUNLOCKED.
0x5020 5020;VWMCD: Action not allowed in logical link lock state eUNLOCKED: %s. Expected state: %s.
0x5021 5021;VWMCD: Action not allowed in logical link lock state eUNLOCKED: %s. Expected states: eLOCKED_BY_THIS_OBJECT or
eLOCKED_BY_ANOTHER_OBJECT.
0x5030 5030;VWMCD: Action not allowed in system lock state eLOCKED_BY_ANOTHER_OBJECT: %s. Expected state: %s.
0x5031 5031;VWMCD: Action not allowed in system lock state eLOCKED_BY_ANOTHER_OBJECT: %s. Expected states:
eLOCKED_BY_THIS_OBJECT or eUNLOCKED.
0x5040 5040;VWMCD: Action not allowed in system lock state eLOCKED_BY_THIS_OBJECT: %s. Expected state: %s.
0x5041 5041;VWMCD: Action not allowed in system lock state eLOCKED_BY_THIS_OBJECT: %s. Expected states:
eLOCKED_BY_ANOTHER_OBJECT or eUNLOCKED.
0x5050 5050;VWMCD: Action not allowed in system lock state eUNLOCKED: %s. Expected state: %s.
0x5051 5051;VWMCD: Action not allowed in system lock state eUNLOCKED: %s. Expected states: eLOCKED_BY_THIS_OBJECT or
eLOCKED_BY_ANOTHER_OBJECT.
0x5060 5060;VWMCD: Action not allowed: called object is locked by another client.
0x5064 5064;VWMCD: Action not allowed: called object not locked.
0x6000 6000;VWMCD: Executing CompuMethod on %s failed.
0x6001 6001;VWMCD: Not able to encode the value from parameter <%s>.
0x6002 6002;VWMCD: CompuCode <%s> could not be loaded.
0x6010 6010;VWMCD: Division by zero occurred during conversion computing.
0x6020 6020;VWMCD: Interface %s not supported (yet). Please contact the MVCI server provider.
0x6030 6030;VWMCD:
0x6040 6040;VWMCD: Method %s not supported (yet). Please contact the MVCI server provider.
0x6041 6041;VWMCD: %s not supported (yet). Please contact the MVCI server provider.
0x6042 6042;VWMCD: Method %s not supported for %s
0x6050 6050;VWMCD:
0x6060 6060;VWMCD:
0x6070 6070;VWMCD: Too many resources: %s.
0x6071 6071;VWMCD: Thread creation failed with error %d(0x%08x).
0x6080 6080;VWMCD:
0x6090 6090;VWMCD:
0x60A0 60A0;VWMCD: %s currently not available - check installation.
0x6900 6900;VWMCD: No valid MCDValue object available.
0x6901 6901;VWMCD: No valid type to create MCDValue object: %s (expected types: %s, ..., %s).
0x6902 6902;VWMCD: No valid diagnostic coded type for request: %s (expected types: %s, %s, %s or %s).
0x6903 6903;VWMCD: No valid diagnostic coded type for response: %s (expected types: %s, %s or %s).
0x6904 6904;VWMCD: No valid encoding type to create encoding object: %s (expected types: %s, ..., %s).
0x6905 6905;VWMCD: Encoding object could not be created: %s.
0x6906 6906;VWMCD: Invalid parameter length: %u byte(s) (expected: %u byte(s)).
0x6907 6907;VWMCD: Invalid parameter length: %u byte(s) (expected: [%u;%u] byte(s)).
0x6908 6908;VWMCD: Invalid parameter bit length: %u (expected: %u).
0x6909 6909;VWMCD: No valid data type: %s (expected type: %s).
0x690A 690A;VWMCD: No valid data type: %s (expected types: %s or %s).
0x690B 690B;VWMCD: No valid data type: %s (expected types: %s, %s, %s, %s, %s or %s).
0x690C 690C;VWMCD: No valid data type: %s (expected types: %s, %s, %s, %s, %s, %s or %s).
0x690D 690D;VWMCD: No valid internal base data type: expected types: %s, %s, %s, %s, %s, %s, %s or %s.
0x690E 690E;VWMCD: No valid physical base data type: expected types: %s, %s, %s, %s, %s or %s.
0x690F 690F;VWMCD: Failure during encoding; %u : %s.
0x6910 6910;VWMCD: Failure during decoding; %u : %s.
0x6911 6911;VWMCD: Converted value (%s) out of limits (%s, %s).
0x6912 6912;VWMCD: Converted value (%s) out of all scales.
0x6913 6913;VWMCD: Internal value (%s) of parameter <%s> out of internal constraint limits (%s, %s).
56 9. VIT-Generierung V14.0.0 / 31.10.2019
0x6914 6914;VWMCD: Internal value (%s) of parameter <%s> is not valid. Scale constraint <%s> with validity <%s> has been violated.
0x6915 6915;VWMCD: Internal value (%s) within %s interval (%s, %s).
0x6916 6916;VWMCD: Calculation from physical to internal is not allowed for rational functions.
0x6917 6917;VWMCD: Invalid bit position: %u.
0x6918 6918;VWMCD: Java exception during computing code conversion: %s.
0x6919 6919;VWMCD: Unknown Java exception during computing code conversion.
0x691A 691A;VWMCD: Cannot get JNI Java environment for current thread; retrieved JNI error %d.
0x691C 691C;VWMCD: Invalid parameter length. Parameter %s - (sub) PDU bytes %s - byte size %u - expected byte size %u.
0x6920 6920;VWMCD: Invalid parameter length (LEADING_LENGTH_INFO_TYPE). Parameter: %s - (sub) PDU length: %u bits - leading info length:
%u bits - parameter length (derived from leading info) %u bits.
0x6921 6921;VWMCD: Invalid PDU length. DB response template %s: byte size %u - response PDU byte size %u.
0x6922 6922;VWMCD: Invalid basic structure parameter <%s> with length: %u byte(s) - expected length: <= %u byte(s), see BYTE-SIZE element in
ODX data.
0x6923 6923;VWMCD: Invalid parameter bit length.
0x6924 6924;VWMCD: The parameter value cannot be interpreted as a byte field with <%s> encoding.
0x6930 6930;VWMCD: ODX standard version of runtime data project not supported. Found %s - expected %s.
0x6931 6931;VWMCD: Invalid UNICODE2STRING size: %u byte(s) (expected: [%u;%u] byte(s)).
Abbildung 9. Herstellerspezifische Fehlertexte
9 VIT-Generierung
9.1 Default-VIT
9.1.1 Motivation
Häufig werden Steuergerätebedatungen ohne zugehörige Vehicle Information Table erstellt

und verteilt. Ein MCD-Kernel braucht jedoch diese VIT-Informationen, um zur Laufzeit
Logical Links zu den Steuergeräten zu erstellen und zu konfigurieren. Abhilfe kann durch die
Generierung einer sogenannten Default-VIT geschaffen werden, die alle gemäß ODX-
Bedatung möglichen Logical Links enthält.
9.1.2 Voraussetzungen
Um eine VIT generieren zu können, müssen alle benötigten Informationen in irgendeiner

Form verfügbar sein. Hierzu betrachte man die an der MCD-Schnittstelle abfragbaren
Informationen und die in einer ODX-VIT bereitgestellten Daten.
MCD-Schnittstelle
• MCDDbVehicleInformation(s)
Zugriff auf MCDDbVehicleConnectors, MCDDbPhysicalVehicleLinkOrInterfaces,

MCDDbLogicalLinks
V14.0.0 / 31.10.2019 9. VIT-Generierung 57
• MCDDbVehicleConnector(s)
Zugriff auf MCDDbVehicleConnectorPins
• MCDDbVehicleConnectorPin(s)
Zugriff auf MCDDbVehicleConnector, Pin Number
• MCDDbPhysicalVehicleLinkOrInterface(s)
Zugriff auf MCDDbVehicleConnectorPins, Type
• MCDPhysicalLinkOrInterfaceType
Mögliche Werte für den Typ eines MCDDbPhysicalVehicleLinkOrInterface
• MCDDbLogicalLink(s)
Zugriff auf MCDDbPhysicalVehicleLinkOrInterface, Gateway Mode, Gateway

MCDDbLogicalLinks, MCDDbLocation (1:1-Beziehung zum Link)
• MCDDbLocation(s)
Zugriff auf MCDDbConfigurationDatas, MCDDbDiagComPrimitives, MCDDbDTCs,

MCDDbFlashSessions, MCDDbTables, MCDDbEcuStateCharts,
MCDDbSubComponents, ...
ODX VEHICLE-INFORMATION-SPEC
Abbildung 10. VEHICLE-INFORMATION-SPEC in ODX 2.2 (Quelle: ODX 2.2 Standard)
Darüber hinaus werden die PARENT-Beziehungen der einzelnen ODX DIAG-LAYER zur
VIT-Generierung genutzt.
Generierbare VIT-Informationen
• eine MCDDbLocation pro PROTOCOL in den Laufzeit-Datenbanken
• eine MCDDbLocation pro Kombination aus FUNCTIONAL-GROUPs und den jeweiligen

PARENT PROTOCOLs
• eine MCDDbLocation pro Kombination aus BASE-VARIANTs und den jeweiligen

PARENT PROTOCOLs, gegebenenfalls indirekt über PARENT FUNCTIONAL-GROUPs
referenziert
• je ein MCDDbLogicalLink pro MCDDbLocation
• pro ECU-VARIANT eine variantenspezifische Ausprägung einer wie oben beschrieben

erzeugten BASE-VARIANT-MCDDbLocation; kein MCDDbLogicalLink
• bedarfsgetriebenes Laden der an einer MCDDbLocation abfragbaren Elemente, z.B. der

MCDDbTables
• Erforderliche Informationen sind in den Laufzeitdatenbanken des jeweiligen Projekts zum

effizienten Zusammenstellen aufbereitet.
• Berücksichtigung der durch ODX vorgegebenen Vererbungs- und Sichtbarkeitsregeln
Nicht generierbare VIT-Informationen
Nicht generierbar sind hingegen die Connector- und Pin-Daten sowie die Informationen zum
Physical Link. Sie müssen anderweitig bereitgestellt und vom MCD-Kernel im Zuge der VIT-
Generierung verarbeitet werden. Dies geschieht mit Hilfe der MCD3D_PINS.INI, die hier
auszugsweise aufgeführt ist:
##############################################################################################
#
# Configuration file for the VW-MCD default VIT
#
# When using the default VIT, the MCD-Kernel has to retrieve some information
# usually contained in an ODX vehicle information spec from this file.
#
# For each protocol of the current project there has to be at least one data set
# containing the protocol short name, the bus type and up to four pins described
# with the pin value and pin type.
#
# MCD3D_BusType: ODX PHYSICAL-LINK-TYPE of the PROT-STACK referenced by the PROTOCOL
# MCD3D_ProtocolName: SHORT-NAME of the ODX PROTOCOL
# MCD3D_Pin_Type: one of the ODX PIN-TYPE enumeration values
# (HI, LOW, K, L, TX, RX, PLUS, MINUS, SINGLE)
# MCD3D_Pin_Value: pin number depending on the hardware
#
# Example:
#
# [PROTOCOL]
# MCD3D_BusType=ISO_11898_2_DWCAN
# MCD3D_ProtocolName=UDS_CAN_B
#
# [PIN1]
# MCD3D_Pin_Type=HI
# MCD3D_Pin_Value=1
#
# [PIN2]
# MCD3D_Pin_Type=LOW
# MCD3D_Pin_Value=2
#
##############################################################################################
[PROTOCOL]
MCD3D_BusType=ISO_11898_2_DWCAN
MCD3D_ProtocolName=UDS_CAN_B
[PIN1]
MCD3D_Pin_Type=HI
MCD3D_Pin_Value=1
[PIN2]
MCD3D_Pin_Type=LOW
MCD3D_Pin_Value=2
[PROTOCOL]
MCD3D_ProtocolName=UDS_CAN_C
[PIN1]
MCD3D_Pin_Type=HI
MCD3D_Pin_Value=1
[PIN2]
MCD3D_Pin_Type=LOW
MCD3D_Pin_Value=2
[PROTOCOL]
MCD3D_ProtocolName=UDS_CAN_D
[PIN1]
MCD3D_Pin_Type=HI
MCD3D_Pin_Value=1
[PIN2]
MCD3D_Pin_Type=LOW
MCD3D_Pin_Value=2
[PROTOCOL]
MCD3D_ProtocolName=KWP_CAN_B
[PIN1]
MCD3D_Pin_Type=HI
MCD3D_Pin_Value=1
[PIN2]
MCD3D_Pin_Type=LOW
MCD3D_Pin_Value=2
[PROTOCOL]
MCD3D_ProtocolName=KWP_CAN_C
[PIN1]
MCD3D_Pin_Type=HI
MCD3D_Pin_Value=1
[PIN2]
MCD3D_Pin_Type=LOW
MCD3D_Pin_Value=2
[PROTOCOL]
MCD3D_ProtocolName=KWP_CAN_D
[PIN1]
MCD3D_Pin_Type=HI
MCD3D_Pin_Value=1
[PIN2]
MCD3D_Pin_Type=LOW
MCD3D_Pin_Value=2
Abbildung 11. Auszug aus MCD3D_PINS.INI
9.1.3 Vorgehensweise
• Pro Eintrag in der MCD3D_PINS.INI, bestehend aus MCD3D_BusType,

MCD3D_ProtocolName und bis zu vier Paaren MCD3D_PinType und
MCD3D_Pin_Value, wird ein MCDDbVehicleConnector erzeugt.
• Pro PIN eines Eintrags wird ein MCDDbVehicleConnectorPin erzeugt und am

MCDDbVehicleConnector eingehängt.
• Pro Eintrag wird ein MCDDbPhysicalVehicleLinkOrInterface erzeugt, an dem die

zugehörigen MCDDbVehicleConnectorPins eingehängt werden.
• Dieses MCDDbPhysicalVehicleLinkOrInterface wird an allen MCDDbLogicalLinks

gehängt, die das in dem Eintrag benannte Protokoll referenzieren.
• Pro Projekt wird eine Default-MCDDbVehicleInformation erzeugt, falls dies in der

MCD3D_SERVER.INI entsprechend eingestellt ist.
• An dieser MCDDbVehicleInformation werden alle generierten MCDDbLogicalLinks

eingehängt.
• An dieser MCDDbVehicleInformation werden alle generierten MCDDbVehicleConnectors

eingehängt.
• An dieser MCDDbVehicleInformation werden alle generierten

MCDDbPhysicalVehicleLinkOrInterfaces eingehängt.
Man beachte:
• Generierte MCDDbLogicalLinks können nicht als Member- oder Gateway-Link

klassifiziert werden.
• Am generierten MCDDbLogicalLink können keine Kommunikationsparameter

überschrieben werden.
9.2 Smart-VIT
9.2.1 Motivation
Eine in der Praxis vom obigen Szenario abweichende, aber ebenso gängige
Vorgehensweise bei der Erstellung und Verteilung von Steuergerätebedatungen ist, pro
Steuergerät ein PDX zu erstellen, das neben den tatsächlichen Steuergeräteinformationen
auch eine Vehicle Information Table mit den Logical Links für genau dieses Steuergerät
enthält.
Zur Laufzeit entstehen dadurch zahlreiche MCDDbVehicleInformation-Objekte, je eines pro

ODX-VIT, und der MCD3D-Standard sieht vor, dass zu einem Zeitpunkt auf genau einer
MCDDbVehicleInformation gearbeitet werden kann.
Der Wechsel auf ein anderes Steuergerät bedeutet also auch ein Wechsel auf eine andere
MCDDbVehicleInformation.
Neben den bedateten VITs erstellt der MCD-Kernel auf Basis der gegebenen Layer und
Beziehungen zwischen den Layern eine sogenannte Default-VIT (siehe oben), die alle
potenziellen Logical Links enthält. In der Regel werden dies deutlich mehr Links sein, als in
der Praxis tatsächlich von Bedeutung und nutzbar sind.
Die sogenannte „Smart VIT“ bietet nun einen Kompromiss zwischen der einen Default-VIT
und den zahlreichen Steuergeräte-VITs, indem sie die Informationen der einzelnen
Steuergeräte-VITs zu einer MCDDbVehicleInformation zusammenführt. Man kann also ohne
Wechsel der MCDDbVehicleInformation mit allen Steuergeräten arbeiten, sofern für sie eine
Einzel-VIT existiert.
9.2.2 Voraussetzungen
Ein Zusammenführen einzelner VITs bedeutet das Übernehmen der MCD-Objekte

MCDDbLogicalLink, MCDDbPhysicalVehicleLinkOrInterface, MCDDbVehicleConnector und
MCDDbVehicleConnectorPin.
Dabei muss entschieden werden können, ob Objekte gleich sind oder nicht, da gleiche
Objekte nur einmal in den entsprechenden Kollektionen auftauchen dürfen.
Als Kriterium für die Gleichheit wird ausschließlich die Namensgleichheit betrachtet.
Enthalten also zwei MCDDbVehicleInformation-Objekte jeweils einen
MCDDbVehicleConnector mit dem Shortname „VCONN_CAN_D“, so muss angenommen
werden können, dass die Elemente auch inhaltlich gleich sind, damit nur eines dieser
Elemente in der Intelligenten VIT abgespeichert werden kann. Dies gilt für alle Elemente
einer VIT.
Man beachte, dass diese Forderung restriktiver ist als das, was durch ODX 2.2 vorgegeben
ist. Hier muss zum Beispiel der Name eines VEHICLE-CONNECTORs nur bis zur Grenze
VEHICLE-INFORMATION eindeutig sein.
9.2.3 Vorgehensweise
Beim Zusammenführen der VITs werden bezüglich des Namens doppelte Elemente
aussortiert. Dabei wird zuvor überprüft, ob die Elemente tatsächlich auch inhaltlich gleich
waren und gegebenenfalls eine Warnung protokolliert. Es ist nicht sinnvoll, gleichnamige,
aber inhaltlich unterschiedliche Objekte doch doppelt zu bewahren, da die Elemente
umbenannt werden müssten, und damit unter Umständen bestehende Referenzen auf diese
Objekte zerstört würden.
Wenn die Vorgabe nicht beachtet wurde und dadurch tatsächlich Elemente anderen Inhalts
aussortiert wurden, kann es zur Laufzeit beim Arbeiten über diese Smart VIT bei diversen
Gelegenheiten zu unerwartetem Verhalten oder MCDExceptions kommen.
64 10. Schnittstellen V14.0.0 / 31.10.2019
10 Schnittstellen
10.1 C++
Die Integration des MCD-Kernels in eine C++-Applikation erfolgt über die mitgelieferten API-
Header und Import-Bibliotheken.
Eine Instanz der Klasse MCDSystem wird über

MCDSystem mySystem = MCDSystem::createInstance();
erzeugt.
10.2 Java
Die Anbindung des MCD-Kernels an eine Java-Applikation erfolgt über die Jars
ASAMJavaInterfaces.jar (Interfaces) und McdKernel.jar (Implementierung).
Eine Instanz der Klasse MCDSystem wird über

MCDSystem mySystem = new MCDSystemImp();
erzeugt.
Alternativ können die Jars MCD3D_Java_Interfaces.jar und McdKernel.jar genutzt werden,

wenn ausschließlich standardkonforme Schnittstellen verwendet werden sollen.
Alle proprietären Erweiterungen der MCD3D-API, die nicht im MCD3D-Standard beschrieben

sind, sind zusätzlich in ein eigenes, abgeleitetes Interface ausgelagert worden. Diese
Interfaces liegen in einem eigenen Namensraum (asam.d.ext.volkswagen) sowie einem
eigenen JAR MCD3D_Java_Extended_Interfaces.jar. Für jedes Interface
asam.d.<if_name>, das mit proprietären Methoden erweitert ist, gibt es folglich ein
zusätzliches abgeleitetes Interface asam.d.ext.volkswagen.<if_name>_NSF, das
ausschließlich die proprietären Methoden enthält.
Die gegenüber den proprietär erweiterten Standard-Interfaces aus ASAMInterfaces.jar

geänderten Interface-Namen und Namensräume müssen bei der Verwendung des Jars
beachtet werden.
10.3 DCOM
Die der DCOM-Schnittstelle zugeordnete Bibliothek ist die DSystemLib

(„McdKernelDCom_vc120(_64).dll“). Die zugehörige Typbibliothek ist die
„McdKernelDCom.tlb“. Um eine Instanz auf dem Server zu erhalten, muss die Klasse
DSystem mit der CLSID „CLSID_DSystem“ angefordert werden.
V14.0.0 / 31.10.2019 11. Abweichungen von ASAM MCD-3D 3.0.0 65
11 Abweichungen von ASAM MCD-3D 3.0.0
Der MCD-Kernel bietet grundsätzlich eine Implementierung des Standards ASAM MCD-3D
3.0.0. In einigen Punkten weicht er jedoch von diesem Standard ab, weil einzelne Methoden
oder auch ganze Bereiche nicht komplett standardkonform implementiert werden können,
weil einzelne Bereiche noch nicht oder nicht vollständig implementiert sind und weil der
MCD-Kernel um proprietäre Methoden erweitert worden ist.
11.1 Nicht vollständig standardkonform implementierbare Funktionalitäten
Die folgenden Methoden des Standards lassen sich nicht hundertprozentig standardkonform
implementieren:
• MCDDataPrimitive::executeAsync
Grundsätzlich ist diese zentrale Methode des MCD-Kernels natürlich nach Standard
implementiert und funktionstüchtig. Lediglich kann nicht geprüft werden, ob der Dienst in
einem Job oder außerhalb eines Jobs ausgeführt werden soll. In einem Job ist gemäß
Standard die asynchrone Dienstausführung nicht erlaubt und mit einer
MCDProgramViolationException (eRT_SERVICE_ASYNC_NOT_ALLOWED) zu
quittieren. Der MCD-Kernel hat jedoch keine Möglichkeit, gesichert festzustellen, ob ein
Dienst aus einem Job heraus gestartet wurde oder nicht, insbesondere vor dem
Hintergrund, dass mehrere parallele Threads auf demselben MCDLogicalLink Dienste
einsteuern und Jobs selbst auch asynchron gestartet sein können. Daher kann die vom
Standard geforderte Überprüfung nicht stattfinden, und es ist in der Verantwortung des
Job-Entwicklers, für eine standardkonforme Dienstausführung zu sorgen.
• MCDDbTableParameter::isApiExecutable, MCDDbDiagComPrimitive::isApiExecutable
Die Methoden selbst sind sehr wohl implementierbar und auch implementiert, da sie ja
lediglich ODX-Informationen transportieren. Die mit diesen Methoden verbundene
Semantik ist jedoch aus denselben Gründen nicht sicher zu stellen, die beim
„executeAsync“ aufgeführt sind. Laut Standard soll „isApiExecutable“ nur bei Diensten
berücksichtigt werden, die nicht in Jobs ausgeführt werden. Wie oben erläutert, kann der
Kontext der Dienstausführung allerdings nicht hundertprozentig getroffen werden. Die
Annahme ist nun, dass, wenn auf dem relevanten MCDLogicalLink nun ein Job läuft und
ein weiterer Dienst synchron ausgeführt werden soll, dies im Job geschieht und die
Dienstausführung auch erlaubt ist, wenn „isApiExecutable“ den Wert „false“ liefert. Diese
Annahme kann falsch sein, ist aber unkritischer als das unzulässige Verhindern der
Ausführung eines Dienstes, der nicht im Job gestartet wird.
• Generisches Busmonitoring
• MCDDbDataFormat::getUserDefinedFormat
66 11. Abweichungen von ASAM MCD-3D 3.0.0 V14.0.0 / 31.10.2019
Gemäß Standard soll die Methode den Wert des ODX-Attributs USER-SELECTION
liefern. Dieses Attribut ist jedoch nur am ODX-Element DATAFORMAT verfügbar, das
wiederum nur im Flash-Kontext (FLASHDATA) existiert, nicht aber am DATA-RECORD.
Der bietet lediglich das Attribut DATAFORMAT-SELECTION, das nicht an der MCD-3D
Schnittstelle abfragbar ist. Insofern kann die Methode nicht implementiert werden.
11.2 Bewusst abweichend vom Standard implementierte Funktionalitäten
Manche Methodendefinitionen des Standards weisen gewisse Mängel auf, die sich nachteilig
auf die Applikationen auswirken, so dass bewusst vom Standard abgewichen wird, obwohl
eine standardkonforme Implementierung möglich wäre.
• MCDInterface::getStatus
Gemäß Standard soll die Methode eine MCDProgramViolationException werfen, wenn

das aktuelle MCDInterface nicht verbunden ist (eRT_INTERFACE_NOT_CONNECTED).
Das ist insofern nicht sinnvoll, als getStatus ja genau den Verbindungsstatus liefern soll.
Es können die Werte eAVAILABLE, eNOT_AVAILABLE, eREADY und eNOT_READY
angenommen werden. Ihnen sind seitens der D-PDU-API die Zustände
PDU_MODST_AVAIL, PDU_MODST_NOT_AVAIL, PDU_MODST_READY und
PDU_MODST_NOT_READY zugeordnet.
PDU_MODST_AVAIL bedeutet, dass das Module (also MCDInterface) verfügbar, aber

noch nicht verbunden ist. Wird nun bei getStatus immer verlangt, dass das MCDInterface
verbunden ist, kann der Zustand eAVAILABLE niemals angenommen werden.
Die aktuelle Implementierung quittiert den Aufruf der Methode mit einer
MCDProgramViolationException und Fehlernummern eRT_PDU_API_CALL_FAILED
und eVS_RT_PDU_GET_STATUS_ERROR, wenn der interne Aufruf von PDUGetStatus
einen Fehler geliefert hat.
Weiter wird eine MCDProgramViolationException mit Fehlernummern

eRT_INTERNAL_ERROR und eVS_RT_MAPPING_PDU_STATUS_FAILED geliefert,
wenn PDUGetStatus einen Status ungleich der oben genannten Werte liefert.
Darüber hinaus wird keine Exception geworfen.
• MCDEventHandler::onLinkActivityStateIdle/Running
Gemäß Standard soll jeder Statuswechsel der Logical Link Queue von eACTITY_IDLE
nach eACTIVITY_RUNNING und zurück mit einem Aufruf des entsprechenden Callbacks
registrierter MCDEventHandler-Implementierungen quittiert werden. Dies ist nicht
sinnvoll, da diagnoselastige Applikationen, bei denen der Status ständig wechselt,
dadurch vollkommen ausgebremst würden. Darüber hinaus ist der aktuelle Status nur
eine Momentaufnahme und daher nur in ganz speziellen Situationen für eine Applikation
von Interesse. In diesen Fällen kann er am MCDLogicalLink aktiv erfragt werden.
Die aktuelle Implementierung ruft die genannten Callbacks nicht auf.

• MCDInterface::getCurrentDbInterfaceCable
Der Methodenbeschreibung gemäß Standard fehlt die Angabe einer sinnvollen Exception
für den Fall, dass der Aufruf der D-PDU API Methode PDUIoCtl fehlschlägt. Analog zu
anderen Methoden, die intern einen Aufruf an die D-PDU API absetzen, kann die aktuelle
Implementierung zusätzlich zu den im Standard angegebenen Exceptions eine
MCDProgramViolationException mit dem Fehlerwert eRT_PDU_API_CALL_FAILED
werfen.
• MCDProject::createLogicalLinkByAccessKeyAndInterface
Im Falle eines Aufrufs mit einem ungültigen Access Key soll laut Standard eine
MCDProgramViolationException mit Fehlerwert ePAR_DB_INVALID_ACCESS_KEY
geworfen werden. „ePAR_...“-Fehlerwerte werden aber normalerweise über eine
MCDParameterizationException transportiert, was in der aktuellen Implementierung auch
für diese Methode so gehandhabt wird. Daher weicht die Fehlerbehandlung an dieser
Stelle vom nicht ganz sauberen Standard ab.
• MCDConfigurationRecord::loadCodingData
Der Methodenbeschreibung gemäß Standard fehlt die Angabe einer sinnvollen Exception
für den Fall, dass dem Configuration Record noch kein MCDDbDataRecord über
setConfigurationRecordByDbObject zugewiesen wurde. Die aktuelle Implementierung
sieht für diesen Fall eine zusätzliche MCDDatabaseException mit Fehlerwert
eDB_INCONSISTENT_DATABASE vor.
Die Standard-Methode MCDConfigurationRecord::loadCodingData wird in ihrem

Verhalten inkompatibel geändert. Die modifizierte Methode hat folgendes Verhalten:
Beim Füllen eines MCDConfigurationRecords mit dem Inhalt einer zu großen Datei wird
nur die erforderliche Anzahl an Bytes, gegeben durch UNCOMPRESSED-SIZE, gelesen
und der Rest ignoriert.
Die zugehörigen MCDConfigurationItem-Elemente werden mit dem Wert des

Configuration Records aktualisiert.
Beim Füllen eines MCDConfigurationRecords mit dem Inhalt einer zu kleinen Datei
werden alle verfügbaren Bytes in den Configuration Record übertragen.
Die zugehörigen MCDConfigurationItem-Elemente werden nicht mit dem Wert des

Configuration Records aktualisiert, da dies nicht erfolgreich sein kann.
In beiden Fällen wird am MCDConfigurationRecord ein MCDError gesetzt, der über

MCDConfigurationRecord::getError() abgefragt werden kann.
MCDConfigurationRecord::hasError() liefert true.
• Flash-Segment-Generierung durch den MCD-Kernel
Wenn im ODX für Flash-Daten keine SEGMENTs definiert sind, sollen gemäß Standard
MCDDbFlashSegment-Objekte durch den MCD-Kernel generiert und in der über
MCDDbFlashDataBlock::getDbFlashSegments gelieferten MCDDbFlashSegments-

Kollektion zur Verfügung gestellt werden. Die Segmente werden auf Basis der
Adressbereiche in den Flashdaten erstellt. Diese Vorgehensweise soll allerdings
ausschließlich für MOTOROLA-S- oder INTEL-HEX-formatierte Flashdaten umgesetzt
werden. Für BINARY-formatierte Flashdaten müssen dagegen über ODX die
SEGMENTs geeignet bedatet sein.
Die aktuelle Implementierung generiert allerdings auch für BINARY-formatierte

Flashdaten ein MCDDbFlashSegment über die kompletten Daten und weicht damit vom
Standard ab. In der Praxis hat sich diese Abweichung bewährt und soll daher aus
Kompatibilitätsgründen nicht rückgängig gemacht werden.
• MCDResponseParameter::setValue
Beim Aufruf von MCDResponseParameter::setValue aus einem Job heraus findet für
TEXTTABLE-Parameter eine Überprüfung des Eingabewertes statt. Ist er nicht in der
Liste der gültigen Texttable-Elemente, wird die Eingabe mit einer Exception quittiert.
• Gültigkeit von Flash-Sessions
Der Standard ODX 2.0.1 bietet keine Möglichkeit, die Gültigkeit von Sessions von einer
Basisvariante an die zugehörigen Varianten zu propagieren, ohne alle Varianten explizit
zu referenzieren. In ODX 2.2.0 wird dies über das ODX-Element ALL-VARIANT-REFS
zum Ausdruck gebracht. Auf Wunsch des Auftraggebers wird jetzt für ODX 2.0.1-
Bedatungen die Gültigkeit einer Flash-Session immer von einer Basisvariante an alle
Varianten übertragen, auch wenn eine oder mehrere dieser Varianten zusätzlich explizit
referenziert werden.
• MCDParameter::getUnit
Die Methode liefert eine leere Zeichenkette, wenn der zugehörige ODX PARAM keine
UNIT referenziert oder diese UNIT keinen DISPLAY-NAME beinhaltet.
• MCDRequestParameter::setValue
Die Methode MCDRequestParameter::setValue verhält sich abweichend vom MCD-3D
3.0.0 Standard wie folgt:
MCDRequestParameter::setValue (asam::mcd::MCDValue value)
Sets the parameter value.
The input parameter value is taken by copy and overwrites the value in the server.
Precondition:
The parameter object must be valid.
Postcondition:
An exception (MCDParameterizationException: ePAR_INVALID_VALUE) will be

thrown if
- the data type of the value does not match the data type of the MCDValue object
which can be retrieved by calling getValue() or createValue() at this parameter
- the parameter is a complex parameter
- the parameter is a simple parameter of ODX type CODED-CONST, PHYS-
CONST, SYSTEM, or RESERVED
- the value does not fit the value range of the physical constraint (PHYS-CONSTR),
if available
- For ODX 2.1 or ODX 2.2 based runtime projects and
MCD3D_CONSTRAINT_CHECK_ODX_21_22=1: the value fits a physical scale
constraint with validity NOT-VALID, NOT-DEFINED, or NOT-AVAILABLE (PHYS-
CONSTR / SCALE-CONSTR)
- the calculation of the coded value using the corresponding compu-method failed
- the coded value does not fit the parameter size (bit length, # 1 in the condensed
bit mask), encoding, or value range of the internal constraint (INTERNAL-
CONSTR), if available
- For ODX 2.0.1 based runtime project and MCD3D_CONSTRAINT_CHECK=1: the
coded value fits an internal scale constraint with validity NOT-VALID, NOT-
DEFINED, or NOT-AVAILABLE (INTERNAL-CONSTR / SCALE-CONSTR)
- For ODX 2.1 or ODX 2.2 based runtime projects and
MCD3D_CONSTRAINT_CHECK_ODX_21_22=1: the coded value fits an internal
scale constraint with validity NOT-VALID, NOT-DEFINED, or NOT-AVAILABLE
(INTERNAL-CONSTR / SCALE-CONSTR)
Die Berechnung eines MCDResponseParameter-Wertes aus den entsprechenden Bytes

einer Steuergeräteantwort schlägt in Bezug auf einfache eVALUE-Parameter
abweichend vom MCD-3D 3.0.0 Standard unter folgenden Bedingungen fehl:
a) Die erforderlichen PDU-Bytes können nicht gemäß den Angaben des Parameters
extrahiert werden.
b) Die Dekodierung der extrahierten PDU-Bytes zur Bestimmung des internen Wertes
schlägt fehl.
c) Der ermittelte interne Wert passt nicht in den Wertebereich eines etwaigen internen
Constraint (INTERNAL-CONSTR).
d) Für ODX 2.0.1 basierte Laufzeitdatenprojekte und

MCD3D_CONSTRAINT_CHECK=1: der interne Wert passt in einen Wertebereich
eines internen Scale Constraint (INTERNAL-CONSTR / SCALE-CONSTR) mit
VALIDITY = eNOT_VALID, eNOT_DEFINED oder eNOT_AVAILABLE.
e) Für ODX 2.1 oder ODX 2.2 basierte Laufzeitdatenprojekte und

MCD3D_CONSTRAINT_CHECK_ODX_21_22=1: der interne Wert passt in einen
Wertebereich eines internen Scale Constraint (INTERNAL-CONSTR / SCALE-
CONSTR) mit VALIDITY = eNOT_VALID, eNOT_DEFINED oder eNOT_AVAILABLE.
f) Die Umrechnung des internen Wertes in den physikalischen Wert gemäß Compu-
Method schlägt fehl.
g) Für MCD3D_CONSTRAINT_CHECK_ODX_21_22=1: der physikalische Wert passt in

einen Wertebereich eines physikalischen Scale Constraint (PHYS-CONSTR /
SCALE-CONSTR) mit VALIDITY = eNOT_VALID, eNOT_DEFINED oder
eNOT_AVAILABLE.
Als Resultat einer solchen fehlgeschlagenen Berechnung wirft die Methode

MCDParameter::getValue() für den entsprechenden MCDResponseParameter eine
MCDProgramViolationException mit Fehler eRT_VALUE_NOT_AVAILABLE.
• MCDParameter::getBitPos, MCDParameter::getBytePos, MCDParameter::getByteLength
Ein Aufruf der entsprechenden Methoden an Parametern eines MCDJob-Elements soll

gemäß Standard mit einer MCDException quittiert werden. Da auf RT-Parameter-Ebene
die zur Überprüfung erforderliche Kontextinformation nur mit hohem Aufwand ermittelt
werden kann, wird auf diese Exception verzichtet. Statt dessen werden bei Request-
Parametern die Werte wie bei Request-Parametern „normaler“ Dienste entsprechend den
DOPs der ODX-Daten berechnet. Bei Response-Parametern wird für alle drei Methoden
der Wert 0 geliefert.
11.3 Nicht oder nicht vollständig implementierte Funktionalitäten
Zum jetzigen Zeitpunkt sind noch nicht alle Klassen und Methoden des Standards vollständig
implementiert. Ein Zugriff auf diese Methoden wird mit einer MCDSystemException und dem
Fehlercode „eVS_SYSTEM_METHOD_NOT_SUPPORTED“ quittiert.
Dies betrifft alle Methoden im Kontext von Dynamically Defined Identifiers. Die Monitoring-
Schnittstelle kann aktuell nur in Verbindung mit einer D-PDU-API-Implementierung der
Softing AG verwendet werden, da die Anbindung der D-PDU-API nicht standardisiert ist und
daher proprietär vorgenommen werden muss.
Weitere vereinzelte Methoden werden bislang noch nicht unterstützt:
MCDDbLocation::getAuthorizedMethods
MCDParameter::setValuePDUConform
MCDLogicalLink::sendBreak
MCDDbProject::loadNewECUMEM
Ausführung von Control-Primitiven in Jobs, außer MCDProtocolParameterSet
11.3.1 Überschreiben komplexer Kommunikationsparameter
Bezüglich der ODX 2.2-Unterstützung gibt es einen offenen Punkt im Bereich der
Comparams. Es ist gemäß Standard möglich, COMPARAM-REFs auf die Unterelemente von
COMPLEX-COMPARAMs zu bedaten und somit zum Ausdruck zu bringen, dass alle
anderen Werte des COMPLEX-COMPARAMs den auf der gerade aktuellen Ebene gültigen
Default haben. Diese Form des Überschreibens der COMPLEX-COMPARAMs unterstützt
VW-MCD derzeit nicht. Um COMPLEX-COMPARAMs zu überschreiben, muss eine
COMPARAM-REF auf diesen COMPLEX-COMPARAM verweisen und für alle einzelnen
Elemente Werte angegeben werden. Dies ist konform zum Standard, erhöht die
Übersichtlichkeit in den ODX-Daten und stellt gegenüber der anderen Form der
Überschreibung zur Laufzeit keinen Nachteil dar.
11.3.2 Festlegung des PROT-STACKs
Bezüglich der ODX 2.1- und ODX 2.2-Unterstützung gibt es Restriktionen für die Angaben
von PROT-STACK-Referenzen, um den gültigen Satz an Comparams zu definieren: Gemäß
ODX kann die PROT-STACK-Referenz wahlweise am PROTOCOL oder am LOGICAL-LINK
bedatet sein. Für den VW-MCD besteht die Einschränkung, dass es keine zwei LOGICAL-
LINKs geben darf, die sich ausschließlich im verwendeten PROT-STACK unterscheiden,
sonst aber auf die gleiche Location verweisen. Die folgende Konstellation in einer VEHICLE-
INFORMATION-SPEC ist also nicht erlaubt:
<LOGICAL-LINK ID="LL_1_ID" xsi:type="MEMBER-LOGICAL-LINK">
<SHORT-NAME>LL_1</SHORT-NAME>
<LONG-NAME>LL_1</LONG-NAME>
<PHYSICAL-VEHICLE-LINK-REF ID-REF="PHYS_LINK_ID"/>
<PROTOCOL-REF DOCREF="PROT" DOCTYPE="LAYER" ID-REF="PROT_ID"/>
<BASE-VARIANT-REF DOCREF="BV" DOCTYPE="LAYER" ID-REF="BV_ID"/>
<PROT-STACK-SNREF SHORT-NAME="PS_1"/>
</LOGICAL-LINK>
<LOGICAL-LINK ID="LL_2_ID" xsi:type="MEMBER-LOGICAL-LINK">
<SHORT-NAME>LL_2</SHORT-NAME>
<LONG-NAME>LL_2</LONG-NAME>
<PHYSICAL-VEHICLE-LINK-REF ID-REF="PHYS_LINK_ID"/>
<PROTOCOL-REF DOCREF="PROT" DOCTYPE="LAYER" ID-REF="PROT_ID"/>
<BASE-VARIANT-REF DOCREF="BV" DOCTYPE="LAYER" ID-REF="BV_ID"/>
<PROT-STACK-SNREF SHORT-NAME="PS_2"/>
</LOGICAL-LINK>
Der Grund ist, dass beide resultierenden MCDDbLogicalLinks auf dieselbe MCDDbLocation
verweisen, die durch ihren MCDAccessKey eindeutig bestimmt sein muss, welcher
wiederum über die Referenzen auf BV und PROT definiert wird. Zu einer MCDDbLocation
gehört aber auch das MCDDbProtocolParameterSet, also der vordefinierte Satz an
Kommunikationsparametern. Dieser hängt jedoch vom PROT-STACK ab, der in obigem
Beispiel für beide MCDDbLogicalLinks unterschiedlich ist, was im Widerspruch zur
Eindeutigkeit der MCDDbLocation steht.
Sollen unterschiedliche PROT-STACKs verwendet werden, so muss das im Fall von VW-
MCD am PROTOCOL zum Ausdruck gebracht werden. Im obigen Beispiel resultierten zwei
Protokolle und damit zwei MCDDbLocations, womit der Widerspruch aufgelöst ist.
11.3.3 Nutzung der C++ Schnittstelle

Der ASAM MCD-3D 3.0.0 Standard beschreibt in seiner C++ Technologiereferenz, dass
MCD-Objekte, die über Zeiger an die Applikation herausgereicht werden, in den Besitz der
Applikation übergehen. Die Applikationen sollen für die Freigabe dieser Objekte
verantwortlich sein und diese dann bei Bedarf per „delete“ vornehmen.
Für den Vorgänger dieses Standards, also für ASAM-MCD-3D 2.0.0, wurde eine solche
Festlegung nicht getroffen, so dass die Basis dieses MCD-Kernels unter einer anderen
Voraussetzung implementiert worden ist. Aus Kompatibilitätsgründen wird bis dato die
ursprünglich umgesetzte Objektverwaltung beibehalten.
Für integrierende C++ Applikationen des MCD-Kernels bedeutet dies:
• Alle vom MCD-Kernel erstellten und über Zeiger herausgereichten MCD-Objekte bleiben
im Besitz des MCD-Kernels.
• Eine C++ Applikation darf auf keinem MCD-Objektzeiger ein „delete“ aufrufen.
• Datenbankobjekte (MCDDb*) werden in der Regel dem aktuellen MCDProject
zugeordnet. Zeiger auf solche DB-Objekte behalten ihre Gültigkeit bis zum Schließen des
Projekts über „MCDSystem::deselectProject“.
• Die über das MCDSystem abfragbaren Objekte der Klasse MCDDbProjectDescription
bleiben bis zu einem nächsten Aufruf von MCDSystem::getDbProjectDescriptions oder
MCDSystem::selectProject(ByName) gültig. Es besteht die Annahme, dass die Objekte
danach für Applikationen keine Relevanz mehr haben, so dass eine Freigabe des
Speichers erfolgt.
• Das über das MCDSystem abfragbare Objekt der Klasse MCDDbProjectConfiguration
bleibt bis zum nächsten Aufruf von MCDSystem::getDbProjectConfiguration gültig. Es
besteht die Annahme, dass die Objekte danach für Applikationen keine Relevanz mehr
haben, so dass eine Freigabe des Speichers erfolgt.
• Das über MCDDbLocation::getDbDTCs angeforderte Objekt der Klasse
MCDDbDiagTroubleCodes gehört nominell zwar zu den Datenbankobjekten, liefert
jedoch eine in Abhängigkeit von den Eingabeparametern der Methode dynamische
Information. Das Objekt bleibt daher ebenfalls nur bis zum nächsten Aufruf der Methode
gültig. Man beachte, dass dies ausdrücklich nur für die Kollektion gilt, nicht aber für die
einzelnen MCDDbDiagTroubleCode-Elemente der Kollektion.
• MCD Laufzeitobjekte (Nicht-MCDDb*) werden vom MCD-Kernel dem Objekt zugeordnet,
für das es direkt oder indirekt erstellt worden ist. Hierbei muss man explizit und implizit
erstellte Objekte unterscheiden:
Explizit erstellte Objekte sind diejenigen Objekte, die eine Applikation mit einer „create“-
Methode erstellt. Diese müssen über eine entsprechende „remove“-Methode wieder
entfernt werden und dürfen im Anschluss nicht weiter verwendet werden.
Zum Beispiel gehört ein Objekt der Klasse MCDDiagComPrimitive zu einem bestimmten
MCDLogicalLink, da es an diesem Link über den Aufruf von
MCDLogicalLink::createDiagComPrimitive(By…) kreiert worden ist. Dieses Objekt wird
seitens Applikation durch den Aufruf von MCDLogicalLink::removeDiagComPrimitive(…)
wieder gelöscht. Nach dem „remove“-Aufruf darf eine Applikation den Objektzeiger in
keinem Programm-Thread mehr verwenden, da die Gültigkeit des Objekts nicht mehr
durch die Applikation kontrolliert werden kann.
Eine Art der implizit erstellten Objekte sind Objekte, die im Kontext eines explizit
erstellten Objekts erzeugt werden und deren Gültigkeit an die Lebensdauer des
übergeordneten Objekts gekoppelt ist. Solche Objekte sind direkt oder indirekt über
Methodenaufrufe (get…) an den explizit erstellten Objekten abfragbar.
So wird zum Beispiel an einer MCDDiagComPrimitive über „getRequest“ ein Zeiger auf
ein MCDRequest-Objekt geliefert, über den dann auf MCDRequestParameter(s)
zugegriffen werden kann. Die Objekte verlieren ihre Gültigkeit mit dem Löschen der
übergeordneten MCDDiagComPrimitive.
Die zweite Art der implizit erstellten Objekte sind dynamische Ergebnisse eines
Methodenaufrufs an einem Laufzeitobjekt. Sie verlieren ihre Gültigkeit mit dem nächsten
Aufruf derselben Methode.
Beispielsweise liefert der Aufruf von MCDDiagComPrimitive::executeSync einen Zeiger
auf ein MCDResult-Objekt. Dieses Objekt sowie alle Laufzeitobjekte, die von ihm
ausgehend erreichbar sind (MCDResponse(s), MCDResponseParameter(s), …) bleiben
bis zum nächsten Aufruf von „executeSync“ gültig, längstens solange, wie die
übergeordnete MCDDiagComPrimitive existiert.
Die MCDValues-Objekte, die beim Aufruf von MCDProject::execIOCtrl,

MCDInterface::execIOCtrl oder MCDLogicalLink::execIOCtrl geliefert werden, bleiben bis
zum nächsten Aufruf der entsprechenden Methode, maximal für die Lebensdauer der
jeweiligen MCDProject-, MCDInterface- bzw. MCDLogicalLink-Instanz erhalten. Das
bedeutet, dass mehrfach parallele IOControl-Abfrage auf demselben MCDObjekt zum
Programmabsturz führen kann und daher seitens der Applikation ausgeschlossen
werden muss.
11.4 Proprietäre Erweiterungen
In einigen Bereichen ist der MCD-Kernel um proprietäre Schnittstellen erweitert worden, um

bestimmte Funktionalitäten im Vorgriff auf neue Standards anzubieten. Aus
Kompatibilitätsgründen werden diese proprietären Erweiterungen bis auf Weiteres weiterhin
unterstützt, sofern sich dies mit der Standardschnittstelle vereinbaren lässt. Dies gilt für die
C++-, Java- und DCOM-API.
Grundsätzlich wird empfohlen, bestehende Applikationen auf die neuen Schnittstellen

umzustellen. Die Verwendung proprietärer Methoden sollte nur in Absprache mit Volkswagen
geschehen.
11.4.1 Iteration über Flashdaten
Die MCD-Kernel Schnittstelle ist als Vorgriff auf einen Standard ASAM MCD 3D V 2.1 um
einen iterativen Zugriff auf Flashdaten erweitert worden. Die für den ASAM MCD 3.0.0
Standard definierte Schnittstelle weicht geringfügig, für bestehende Applikationen,
insbesondere FlashJobs, aber entscheidend insofern davon ab, als es ein explizites Iterator-
Element gibt.
Die proprietäre C++-Schnittstelle bietet an der Klasse MCDDbFlashSegment folgende

zusätzliche Methoden:
/**
* Returns the first BYTEFIELD of the flash data belonging to this flash segment.
* The maximum size of the data chunk is defined with the input parameter "size".
*
* \note provided by VW-MCD for compatibility reasons - deprecated
*
* \param size (in): the size of the chunk to be returned; this size will also
* be considered at getNextBinaryDataChunk
*
* \return a flash data BYTEFIELD with at most "size" bytes contained; if the flash
* data contains less than "size" bytes, the bytefield contains the available
* data
* \throw MCDProgramViolationException eRT_INTERNAL_ERROR
* flash file access failed
* MCDDatabaseException eDB_END_OF_FLASH_FILE
* the data to be returned does not pass the given flash filter
*/
virtual asam::A_BYTEFIELD getFirstBinaryDataChunk(A_UINT32 size)=0;
/**
* Checks whether the flash data belonging to the current segment contains another
* chunk of flash data
*
*
* \param -
* \retval true at least one more data chunk available
* \retval false no more data chunks available
*/
virtual asam::A_BOOLEAN hasNextBinaryDataChunk()=0;
/**
* Returns the next BYTEFIELD of the flash data belonging to this flash segment.
* The maximum size of the data chunk is defined with the input parameter "size"
* of the method getFirstBinaryDataChunk.
*
*
* \return a flash data BYTEFIELD with at most "size" bytes contained; if the remaining
* flash data contains less than "size" bytes, the bytefield contains the
* available data
* \throw MCDProgramViolationException eRT_INTERNAL_ERROR
* flash data iteration has not been started with getFirstBinaryDataChunk
* no next chunk available
* the data to be returned does not pass the given flash filter
*/
virtual asam::A_BYTEFIELD getNextBinaryDataChunk()=0;
11.4.2 Late-bound-Flashdaten
Die Schnittstelle zur Verarbeitung von Late-bound-Flashdaten verfügt über eine weitere
Methode zum Laden neuer Flashsegmente; vgl auch Kapitel 5.4.
Die proprietäre C++-Schnittstelle bietet an der Klasse MCDDbFlashDataBlock folgende

zusätzliche Methode:
/**
* Creates new flash segment items according to the data contained in the flash file
* given as input parameter.
*
*
* \pre
* The flash data belonging to this data block is defined as late-bound.
* The flash data format is eBINARY, eMOTOROLA_S, or eINTEL_HEX.
*
* \param
* filename (in): name of the flash file to be loaded; the name shall be contained
* in the list returned from getMatchingFileNames
* \post
* An exception will be thrown if
* - the flash data is not defined as late-bound
* (MCDDatabaseException, eRT_NO_LATE_BOUND_DATA_FILE)
* - invalid flash data format
* (MCDProgramViolationException, eRT_INTERNAL_ERROR)
* - empty flash data
* (MCDDatabaseException, eDB_END_OF_FLASH_FILE)
*/
virtual void loadSegments(asam::A_ASCIISTRING& fileame)=0;
11.4.3 Zugriff auf Flash-Securities
Als Umgehungslösung für eine in ASAM MCD 3D 2.00.02 nicht verwendbar definierte
Methode MCDDbFlashDataBlock::getDbSecurities ist die korrigierte Methode
MCDDbFlashDataBlock::getDbSecurities2 bereitgestellt worden. Sie entspricht der im neuen
Standard korrigierten Methode MCDDbFlashDataBlock::getDbSecurities:
/**
* Returns the securities for this FlashDataBlock.
*
*
* \pre
* The data base shall be consistent.
*
* Semantic:
* Returns the securities for this FlashDataBlock. With the securitiy it is
* possible to define security specific information like checksum or
* signature for the data block. This information can be used to check the
* integrity and the authencity of the flash data.
*
*
* \post
* Returns the securities for this FlashDataBlock as collection. The return
* value is always an object collection. The collection can be empty. An
* exception will be thrown, if
* - the collection can not be determined because the data base is
* inconsistent (eDB_INCONSISTENT_DATABASE, MCDDatabaseException).
* - in case the resulting collection would contain at least one duplicate
* shortname (eDB_INCONSISTENT_DATABASE,MCDDatabaseException)
*/
virtual asam::d::MCDDbFlashSecurities* getDbSecurities2()=0;
11.4.4 Zugriff auf Flash-Job
Als Umgehungslösung für eine in ASAM MCD 3D 2.00.02 definierte Methode

MCDDbFlashSession::getDbFlashJob ohne den erforderlichen MCDDbLocation-Kontext ist
die eine gleichnamige Methode mit erweiterter Signatur bereitgestellt worden. Sie entspricht
der im neuen Standard ergänzten Methode
MCDDbFlashSession::getDbFlashJobByLocation:
/**
* Returns the FlashJob object specified for this session in the projects
* databases.
*
*
*
* \pre
* A flash job shall be referenced in the given MCDDbLocation.
*
*
* Semantic:
* Returns the FlashJob specified for this session in the projects databases.
* This FlashJob has to be executed, when you want to be sure to flash the
* session with the correct flash job.
*
* \post
* Returns the FlashJob object specified for this session in the projects
* databases.
* An exception will be thrown,
* - if the MCDDbLocation supplied as parameter or its DIAG-LAYER,
* respectively, is not referenced by the corresponding ECU-MEM-CONNECTOR in
* ODX, that is, no MCDDbFlashJob can be identified for this MCDDbLocation
* (eRT_ELEMENT_NOT_AVAILABLE, MCDProgramViolationException)
* - if a location context is already available and the supplied location
* parameter does not match that location context (ePAR_INVALID_DB_OBJECT,
* MCDParameterizationException)
* - if no MCDDbFlashJob can be obtained from the underlying ODX data
* (eDB_ELEMENT_NOT_AVAILABLE, MCDDatabaseException).
* - if the element referenced as a flash job in ODX is not a MCDDbFlashJob
* (ODX allows DIAG-COMMs here) (eDB_WRONG_DATATYPE, MCDDatabaseException).
* - the data base is invalid or the flash job can not be determined.
* (eDB_INCONSISTENT_DATABASE, MCDDatabaseException)
*
*/
virtual asam::d::MCDDbFlashJob* getDbFlashJob(asam::mcd::MCDDbLocation& dbLocation)=0;
11.4.5 Erzeugen eines MCDValue-Elements
An einem MCDRequestParameter ist die Methode setCodedValue zum Setzen eines

internen Wertes eingeführt worden, die in den neuen Standard übernommen wurde.
Zusätzlich zum Setzen bietet der MCD-Kernel eine Methode zum Erzeugen eines internen
Wertes mit dem richtigen Datentyp, der im Anschluss befüllt und gesetzt werden kann:
/**
* Creates a coded value for this RequestParameter.
*
*
* \pre
* The parameter object must be valid.
*
* Semantic:
* Creates a coded value for this RequestParameter. The data type depends on
* the diagnostic coded type of the parameter as defined in ODX.
* ParameterType. It can only be of simple data type.
* If the coded MCDValue already exists another reference to it will be returned.
*
* \post
* If the method succeeds, a reference of the coded MCDValue will be returned.
* An exception will be thrown, if
* - the parameter is a complex parameter (MCDParameterizationException,
* ePAR_INVALID_TYPE)
* - the parameter is a simple parameter of type eCODED_CONST, ePHYS_CONST,
* eRESERVED, or eSYSTEM (MCDParameterizationException, ePAR_INVALID_TYPE)
* - the parameter is a simple parameter of type eTABLE_KEY, and it
* statically references a table row (MCDParameterizationException,
* ePAR_INVALID_TYPE)
*/
virtual asam::mcd::MCDValue* createCodedValue()=0;
11.4.6 Zugriff auf Semantic-Attribute an SubComponents
An einer Kollektion vom Typ MCDDbSubComponents kann ein einzelnes

MCDDbSubComponent-Element über die Semantic geholt werden. Der Standard bietet
jedoch keine Methode, um herauszufinden, welche Semantic-Attribute überhaupt gültig sind.
Hierzu bietet der MCD-Kernel die folgende Methode:
/**
* Returns the collection of semantics (A_ASCIISTRINGS) that are available for the
* MCDDbSubComponent items of this collection. The collection does not contain empty
* strings.
* The collection might be empty.
*
*
* ODX 2.2 / ODX 2.1: DIAG-LAYER - SUB-COMPONENT - SEMANTIC
*
* \param -
* \return collection of semantic attributes
* \throw MCDDatabaseException (eDB_INCONSISTENT_DATABASE)
* The collection cannot be created due to an inconsistent database.
*
* \see getSemantics
*/
virtual asam::mcd::MCDDatatypeAsciiStrings getSemantics()=0;
11.4.7 PDU-Timestamps
Bevor für ASAM MCD 3D 3.0.0 Methoden zum Abfragen von PDU-API-Zeitstempeln definiert
wurden, sind entsprechende Methoden mit gleicher Semantik, ähnlicher Signatur, aber
anderen Namen definiert worden.
MCDResponse:
/**
* returns the PDU timestamp of the start of the response message
*
*
* \param -
* \return PDU timestamp in microseconds
* \throw MCDProgramViolationException eRT_NO_PDU_TIMESTAMP_AVAILABLE
* if PDU timestamp is not available
*/
virtual asam::A_UINT32 getMessageStartPduTimestamp()=0;
/**
* returns the PDU timestamp of the end of the response message
*
*
* \param -
*/
virtual asam::A_UINT32 getMessageEndPduTimestamp()=0;
MCDResult:
/**
* returns the PDU timestamp of the end of the request message
*
*
* \param -

*/
virtual asam::A_UINT32 getRequestMessageEndPduTimestamp()=0;
11.4.8 Abfrage des Text-Table-Elements am MCDParameter
Eine für bestimmte Applikationen sinnvolle Methode zum Zugriff auf das wertabhängige
MCDTextTableElement am MCDParameter hat den Weg nicht in den ASAM MCD 3D 3.0.0
Standard gefunden. Da sie in Gebrauch ist, wird sie beibehalten:
/**
* Returns the MCDTextTableElement of the current parameter, if available.
*
*
* \note provided by VW-MCD as standard enhancement
*
* \pre the corresponding DB parameter has a data type eTEXTTABLE or a parameter type
* eTABLE_KEY internally referencing a text table DOP
* \param -
* \throw MCDProgramViolationException invalid parameter type
* eRT_METHOD_NOT_SUPPORTED_FOR_PARAMETER_TYPE
* \throw MCDParameterizationException text table element not available for the
* current value
* ePAR_ITEM_NOT_FOUND
* \return corresponding MCDTextTableElement
*/
virtual asam::d::MCDTextTableElement* getTextTableElement()=0;
11.4.9 Abfrage des Compu-Default-Value
Der MCD-Kernel verfügt über zwei Methoden zur Abfrage des ODX-Elements COMPU-
DEFAULT-VALUE.
MCDDbParameter::getIntToPhysCompuDefaultValue_NSF() : asam::mcd::MCDValue
Returns the compu default value of the parameter as MCDValue. The information is
retrieved from the ODX element COMPU-INTERNAL-TO-PHYS / COMPU-DEFAULT-VALUE.
The data type of the MCDValue returned is the physical data type of the parameter.
Precondition:
The corresponding ODX data is available.
Postcondition:
An exception will be thrown if
- the compu default value cannot be determined
(MCDDatabaseException, eDB_ELEMENT_NOT_AVAILABLE)
MCDDbParameter::getPhysToIntCompuDefaultValue_NSF() : asam::mcd::MCDValue
Returns the compu default value of the parameter as MCDValue. The information is
retrieved from the ODX element COMPU-PHYS-TO-INTERNAL / COMPU-DEFAULT-VALUE /
COMPU-INVERSE-VALUE.
The data type of the MCDValue returned is the physical data type of the parameter.
Precondition:
The corresponding ODX data is available.
Postcondition:
- the compu default value cannot be determined
11.4.10 Laden und Löschen von Teilprojekten im laufenden Betrieb
Unter bestimmten Randbedingungen können im laufenden Betrieb Teilprojekte (Varianten-,

Flash- oder Ecu-Config-Pakete) nachgeladen bzw. entfernt werden.
Das Installieren und Löschen von Teilprojekten im laufenden Betrieb hat massiven Einfluss
auf die Datenkonsistenz im Laufzeitsystem. Welche Modifikation des Datenbestands zur
Laufzeit im Detail benötigt wird und was unter Berücksichtigung von klar definierten
Randbedingungen realisiert werden kann, muss noch mit dem Auftraggeber abgestimmt
werden. Bis dahin sollte nach Anwenden der nachfolgend aufgeführten Methoden das
aktuelle Projekt deselektiert und im Anschluss wieder selektiert werden, um dann auf einem
sauberen Datenbestand arbeiten zu können. Alle Methoden sind am MCDProject definiert.
11.4.10.1 Laden eines Flashdatenpakets
Zu dem aktuellen MCDProject können unter gewissen Bedingungen neue Flashdaten

hinzugeladen werden.
/**
* Extends the database of the current project with the runtime database files of a
* new flash package.
* The input argument ‘flashPackage’ points to a single source flash file (*.odx(-f)),
* a source flash PDX (*.pdx), a runtime flash PDX (*.FLASH.pdx-r), or an FRF package
* (*.frf), i.e. an encrypted source flash PDX.
* The input parameter provides the name of the new package including the path.
* This path is either absolute or relative to the current project directory.
* The return value is the ODX FLASH / SHORT-NAME. This name is needed for deleting the
* data afterwards. In case of an input source flash PDX containing more than one ODX
* FLASH container the return value is the first ODX FLASH / SHORT-NAME.
*
* \pre
* - The ODX-Converter is available and executable for the MVCI server.
* - The package described with the input parameter exists.
* - The package has a correct file extension, see above.
* - The flash package does not contain any ECU-MEMs (MCDDbEcuMem objects) and SESSIONs
* (MCDDbFlashSession objects) already existing in the current project.
* - If the package contains an ODX FLASH category with a SHORT-NAME not existing
* in the current project, the new flash package does not contain any ECU-MEMs
* (MCDDbEcuMem objects) and SESSIONs (MCDDbFlashSession objects) already
* existing in the current project.
*
* Example:
* Already contained in the target project:
* FLASH / SHORT-NAME “MyFlash”
* - ECU-MEM-CONNECTOR / SHORT-NAME “EcuMemConn1”
* New flash package:
* FLASH / SHORT-NAME “YourFlash”
* - ECU-MEM-CONNECTOR / SHORT-NAME “EcuMemConn1” error!
*
* Semantic:
* Extends the database of the current project with the runtime database files of a
* new flash package.
*
* \post
* In case of success the new flash package will be available in the current project.
* The following collections, if already passed to the client application, are
* outdated, and have to be required again:
* - MCDDbEcuMems returned from MCDDbProject::getDbEcuMems
* - MCDDbFlashSessions, MCDDbFlashSessionClasses, MCDDbPhysicalMemories returned
* from any MCDDbLocation in scope of the MCDDbEcuMem objects in the new package.
* - MCDDatatypeAsciiStrings returned from ‘getNames’ called at any of the upper
* collections.
* The behaviour of iterations over any of the upper collections(getItemByIndex/Name)
* running in parallel to the execution of this method will be undefined.
* Note: files installed due to a call of this method will be removed from the
* current project on ‘deselectProject’.
* - the method is called from Linux, i.e. the ODX-Converter is not available
* (MCDSystemException, eSYSTEM_METHOD_NOT_SUPPORTED)
* - the ODX-Converter is not available
* (MCDSystemException, eSYSTEM_SUBSYSTEM_FUNCTION_CALL_FAILED)
* - the input package does not exist
* (MCDParameterizationException, ePAR_ITEM_NOT_FOUND)
* - the input package has the wrong file type
* (MCDParameterizationException, ePAR_INVALID_OBJECTTYPE)
* - the conversion of the input package failed
* - the new flash runtime database contains MCDDbEcuMems already existing in the
* base project
* (MCDDatabaseException, eDB_INCONSISTENT_DATABASE)
* the input package contains ODX FLASH categories with SHORT-NAMEs already
* existing in the base project
virtual asam::mcd::MCDDatatypeShortName loadNewFlashPackage_NSF
(asam::A_ASCIISTRING& flashPackagePath)=0;
11.4.10.2 Löschen von Flash-Paketen

/**
* Removes the runtime database files and the flash subdirectory of the given flash item
* from the database of the current project when deselecting this project.
* MCDDbObject-items created from this flash item are removed immediately from the
* corresponding collections.
* The contents of collections already passed to the client application is not changed.
* Single items already passed to the client application are still available.
* An application has to call again the corresponding access method in order to get the
* updated collection.
* flashName = ODX FLASH / SHORT-NAME
*
* \pre
* - The project database contains a flash item with the given name.
* - The current project is located in a directory writable for the application.
* - All MCDLogicalLink items based on any MCDDbLocation containing the parent base
* variant or any of its variants must be in an idle mode.
*
* Semantic:
* Removes the runtime database files of the given flash item from the database of the
* current project when deselecting this project.
* Additionally, the flash package specific subdirectory and its complete contents is
* removed, if existing. This directory is placed directly below the base project and
* has the same name as the flash package it belongs to, in this case “<flashName>”.
* External data, e.g. jobs, DLLs, or flashware placed outsice the flash package
* specific flashware directory, is not removed, since it is not sure that this data
* is not used as well in a different context.
*
* \post
* In case of success the runtime database files belonging to the flash item are
* removed from the current project when deselecting this project.
* The following collections, if already passed to the client application,
* are outdated immediately and have to be requested again:
* - MCDDbEcuMems returned from MCDDbProejct::getDbEcuMems
* - MCDDbFlashSEssions, MCDDbFlashSessionClasses, MCDDbPhysicalMemories returned
* from any MCDDbLocation in scope of the MCDDbEcuMem objects of the flash database
* removed.
* - MCDDatatypeAsciiStrings returned from ‘getNames’ called at any of the upper

* collections.
* When selecting the project again, the flash package specific data is not available
* anymore.
* If deselecting the current project is not performed, e.g. due to an unexpected
* termination of the current session, the data remains in the current project.
* - the input flash item does not exist.
* (MCDParameterizationException , ePAR_ITEM_NOT_FOUND)
* - the current project directory is not writable
* - the command queue of at least one logical link belonging to the flash item is
* not idle
* (MCDProgramViolationException, eRT_NOT_ALLOWED_IN_THIS_OBJECT_STATE)
*/
virtual void removeFlashData_NSF (asam::mcd::MCDDatatypeShortName& flashName)=0;
11.4.10.3 Laden von eines EV-Teilprojekts

/**
* Extends the database of the current project with the runtime data of a new variant.
* The input argument 'evRuntimeData' points to a runtime pdx of the category "EV",
* i.e. to a file with the file name ending .EV.pdx-r. The name contains an absolute
* path or a path relative to the current project directory.
* 'baseVariantName' is the short name of the parent base variant of the new variant.
* The return value is the ODX ECU-VARIANT / SHORT-NAME. This name is needed for
* deleting the data afterwards.
*
* Exception:
* MCDException
*
* \pre
* - The project database contains a base variant with the given name.
* - The variant runtime database package exists.
* - The variant runtime database has the file extension ".EV.pdx-r".
* - The project database does not contain a variant with the same name as the new one.
* - MCDLogicalLink items based on any MCDDbLocation containing the input base variant
* must be in an idle mode.
*
* Semantic:
* Extends the database of the current project with the runtime data of a new variant.
*
* \post
* In case of success the new variant is part of the runtime database of the current
* project.
* MCDDbEcuVariants collections returned in scope of the input base variant, or
* config data, flash data, or function dictionary data referencing the base variant
* or any of its variants are not valid anymore.
* MCDAccessKeys collections returned from MCDDbProject::getAccessKeys() are invalid
* and must not be used anymore.
* The short name returned from this method can be used for deleting this package
* calling "removeEcuVariantData_NSF".
*
* - the input base variant does not exist.
* - the input package does not exist.
* - the input package has the wrong file type.
* - the input package is invalid.
* - the project database already contains a variant with the name of the new variant
* - at least one of the logical links in scope of the current base variant is not
* idle.
*/
virtual asam::mcd::MCDDatatypeShortName loadNewEcuVariantData_NSF
(asam::mcd::MCDDatatypeShortName& baseVariantName,
asam::A_ASCIISTRING& evRuntimeData)=0;
11.4.10.4 Löschen von EV-Teilprojekten

/**
* Removes the runtime data of the given ecu variant from the database of the
* current project.
*
* Exception:
* MCDException
*
* \pre
* - The project database contains a variant with the given name.
* - MCDLogicalLink items based on any MCDDbLocation containing the parent base
*
* Semantic:
* Removes the runtime data of the given ecu variant from the database of the
* current project.
*
* \post
* In case of success the runtime database files belonging to the variant are removed
* from the current project.
* Items referencing elements of those database files are invalid.
*
* - the input variant does not exist.
* - at least one of the logical links in scope of the current base variant is not
* idle.
*/
virtual void removeEcuVariantData_NSF(asam::mcd::MCDDatatypeShortName& variantName)=0;
11.4.10.5 Laden von ECU-Config-Paketen

/**
* Adds a new ecu config data package to the current project.
* This package might be a single source ecu config file (*.odx-e), a source ecu config
* PDX (*.pdx), or a runtime ecu config PDX (*.CONFIG.pdx-r).
* The input parameter provides the name of the new package including the path.
* This path is either absolute or relative to the currect project directory.
* The return value is the ODX ECU-CONFIG / SHORT-NAME. This name is needed for deleting
* the data afterwards.
*
* Exception:
* MCDException
*
* \pre
* - The ODX-Converter is available and executable for the MVCI server.
* - The package described with the input parameter exists.
* - The package has a correct file extension, see above.
* - The application has not called MCDDbLocation::getDbConfigurationDatas for any
* location in the scope of the MCDDbConfigurationData object in the new package.
* - The current project does not contain any data for an ECU-CONFIG with the same
* short name as the ODX ECU-CONFIG within the new package.
* - The current project does not contain any data for CONFIGURATION-DATAs with the
* same short names as the ODX CONFIGURATION-DATAs within the new package.
*
* Semantic:
* Adds a new ecu config data package to the current project.
*
* \post
* In case of success the new ecu config package will be available for the next ECU
* configuration process. The short name returned from this mehtod can be used for
* deleting this package calling "removeDbEcuConfigData_NSF".
*
* - the ODX-Converter is not available.
* (MCDSystemException, eSYSTEM_SUBSYSTEM_FUNCTION_CALL_FAILED)
* - the input package does not exist.
* - the input package has the wrong file type.
* - the input package is invalid.
* - the project database already contains ECU config items with the same short names
* as found in the new package.
*/
virtual asam::mcd::MCDDatatypeShortName loadNewEcuConfigData_NSF
(asam::A_ASCIISTRING& configPackagePath)=0;
11.4.10.6 Löschen von ECU-Config-Paketen

/**
* Removes the runtime data of the given ecu config from the database of the
* current project.
*
* Exception:
* MCDException
*
* \pre
* - The project database contains an ecu config with the given name.
* - MCDLogicalLink items based on any MCDDbLocation containing the parent base
*
* Semantic:
* Removes the runtime data of the given ecu config from the database of the
* current project.
*
* \post
* In case of success the runtime database files belonging to the ecu config
* are removed from the current project.
* Items referencing elements of those database files are invalid.
*
* - the input ecu config does not exist.
* - at least one of the logical links in scope of the ecu config is not idle.
*/
virtual void removeEcuConfigData_NSF(asam::mcd::MCDDatatypeShortName& ecuConfigName)=0;
11.4.11 System-Properties
Über die standardkonforme Schnittstelle zum Setzen und Abfragen sogenannter System-
Properties können herstellerspezifische Konfigurationen zur Laufzeit programmatisch
manipuliert werden.
Als Namenskonvention gilt für alle System-Properties, dass sie unter

„de.volkswagen.<ConfigParamKey>“ angesprochen werden, wobei <ConfigParamKey> der
Name des Konfigurationsparameters ist, wie er in der Konfigurationsdatei verwendet wird.
Für den MCD-Kernel werden alle Log-Level als System-Properties angeboten, siehe [3.1].
Exemplarisch sei „de.volkswagen.MCD3D_LogLevel“ genannt. Diese System-Properties
können nach Systemstart jederzeit abgefragt oder gesetzt werden. Der MCDValue-Typ
dieser Properties ist eA_INT32.
Die Anzahl und Größe der Logdateien können über die System-Properties
„de.volkswagen.MCD3D_MAX_NO_OF_LOGFILES“ – Datentyp A_UINT8, maximaler Wert 9
- bzw. „de.volkswagen.MCD3D_MAX_SIZE_OF_LOGFILE“ – Datentyp A_UINT16, Angabe
in KB - erfragt und modifiziert werden. Das Setzen eines Wertes ist jedoch nur im
Systemzustand eINITIALIZED erlaubt.
Über die Property „de.volkswagen.MCD3D_ProjectRootDir_001“ kann der Pfad des ersten

Projektwurzelverzeichnisses erfragt werden. Initial hat die Property mit MCDValue-Typ den
Wert der entsprechenden Konfigurationsvariablen. Ist diese in der MCD3D_PROJECTS.INI
als relativer Pfad notiert, enthält die Property den absoluten Pfad, wobei als Bezugspunkt der
Wert des Konfigurationsverzeichnisses genommen wird. Das Setzen der Property ist
jederzeit möglich und greift bei nächster Gelegenheit, d.h. bei einem erneuten
MCDSystem::selectProject(ByName). Die Property ersetzt dann den Wert aus der
Konfigurationsdatei, die jedoch nicht persistent überschrieben wird. Mit einem
Systemneustart greift initial wieder der Wert aus der Konfigurationsdatei.
Über die Property „de.volkswagen.MCD3D_MCD3D_PDU_LENGTH_CHECK“ kann

gesteuert werden, ob bei der Auswertung einer Antwort-PDU gegen ein DB-Response-
Template auf Basis der ODX-Bedatung eine Längenüberprüfung stattfindet oder nicht, siehe
[3.1]. Bei eingeschalteter Längenprüfung muss die Antwort PDU exakt zum DB-Response-
Template passen. Bei ausgeschalteter Längenprüfung kann die Antwort PDU länger sein als
für das DB-Response-Template benötigt. Dies unterstützt (nicht saubere) ODX-Bedatungen,
bei denen nur die interessierenden Response-Parameter bedatet sind, auch wenn ein
Steuergerät mehr Antwortdaten schickt. Korrekterweise müssten die restlichen Antwortdaten
über RESERVED-Parameter abdeckt werden. Die Property kann jederzeit nach Systemstart
gelesen werden. Gesetzt werden kann sie in den Systemzuständen
eDBPROJECT_CONFIGURATION, eINITIALIZED und ePROJECT_SELECTED, nicht aber
in eLOGICALLY_CONNECTED. Eine steuergerätespezifische Einstellung ist damit nicht
möglich. Der MCDValue-Typ der Property ist eA_BOOLEAN.
Darüber hinaus kann die PDU-API-Auswahl über die System-Property

„de.volkswagen.MCD3D_MVCI_PDU_API_Shortname“ erfolgen, solange die PDU-API noch
nicht über prepareInterface oder prepareVciAccessLayer geladen wurde. Der MCDValue-
Typ dieser Property ist eA_ASCIISTRING.
Die für die Methode PDUConstruct optionale Zeichenkette zur Konfiguration der D-PDU-API
kann mittels System-Property „de.volkswagen.MCD3D_MVCI_PDU_API_OPTION_STRING“
gesteuert werden. Der schreibende Zugriff ist möglich, solange die PDU-API noch nicht über
prepareInterface oder prepareVciAccessLayer geladen wurde. Der MCDValue-Typ dieser
Property ist eA_ASCIISTRING.
Unter denselben Bedingungen kann ebenfalls über eine System-Property

„de.volkswagen.MCD3D_VciVendorModuleName“ die VCI-Auswahl vorgenommen werden.
Der MCDValue-Typ dieser Property ist eA_ASCIISTRING.
Über die System-Property „de.volkswagen.MCD3D_KEEP_UNCOMPRESSED_TDB” kann

eingestellt werden, ob eine im Laufzeitdatenprojekt komprimiert vorliegende Textdatenbank
dauerhaft oder temporär entpackt werden soll. Die Property mit MCDValue-Typ
eA_BOOLEAN wird initial mit dem Wert des entsprechenden Konfigurationsparameters
MCD3D_KEEP_UNCOMPRESSED_TDB aus der MCD3D_SERVER.INI belegt. Fehlt der
Konfigurationsparameter, so wird aus Kompatibiltätsgründen der Wert „false“ angenommen.
Das Lesen und Schreiben der Property ist jederzeit möglich, und ein neuer Wert greift bei
nächster Gelegenheit, d.h. bei einer erneuten Projektselektion.
Die folgenden System-Properties ermöglichen einen lesenden Zugriff auf die

entsprechenden Konfigurationsparameter:
• „de.volkswagen.VW_MCD_HOME“ Typ: eA_ASCIISTRING
• „de.volkswagen.VW_MCD_CONFIG“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_LogDirectory“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_FlashProjectDirectory“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_FlashDataRootDirectory“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_EcuConfigRootDirectory“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_SERVER_CppExternalDirs“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_SERVER_JavaExternals“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_PROJECTS_JavaExternals“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_PROJECTS_CppExternalDirs“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_CURR_PROJECT_JavaExternals“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_CURR_PROJECT_CppExternalDirs“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_CURR_PROJECT_UploadFiles“ Typ: eA_ASCIISTRING
• „de.volkswagen.MCD3D_LateboundFilesDirectory“ Typ: eA_ASCIISTRING
Die folgenden System-Properties ermöglichen einen lesenden und schreibenden Zugriff auf
die entsprechenden Konfigurationsparameter, wobei das Schreiben neuer Werte nur im
Systemzustand eINITIALIZED erlaubt ist:
• „de.volkswagen.MCD3D_PDU_LENGTH_CHECK“ Typ: eA_BOOLEAN
• „de.volkswagen.MCD3D_STRUCTURE_VISIBILITY“ Typ: eA_BOOLEAN
• „de.volkswagen.MCD3D_SESSION_RENAMING“ Typ: eA_BOOLEAN
• „de.volkswagen.MCD3D_SUPPRESS_EXCEPTION“ Typ: eA_BOOLEAN
• „de.volkswagen.ENCRYPTED_TESTER_ID“ Typ: eA_BYTEFIELD
• „de.volkswagen.MCD3D_LATEBOUND_FILESIZE_CHECK“ Typ: eA_BOOLEAN
• „de.volkswagen.MCD3D_CONSTRAINT_CHECK“ Typ: eA_BOOLEAN
• „de.volkswagen.MCD3D_CONSTRAINT_CHECK_ODX_21_22“ Typ: eA_BOOLEAN
11.4.12 Abfrage installierter PDU-APIs
Um eine PDU-API zur Laufzeit über eine System-Property auswählen zu können, muss eine
Applikation wissen, welche PDU-APIs grundsätzlich zur Verfügung stehen. Entsprechende
Informationen findet man in der RDF. Als Komfort-Methode bietet der MCD-Kernel am
MCDSystem eine Funktion zur Abfrage der Short-Names aller in der aktuellen RDF notierten
PDU-APIs:
/**
* returns the list of PDU API identifiers registered in the current RDF.
* Items of this list may serve as valid values for the system property
* de.volkswagen.MCD3D_MVCI_PDU_API_Shortname.
*
* \note provided by VW-MCD as enhancement of the ASAM MCD 3.0.0 standard interface
*
* \param -
* \return list of PDU API short names, empty if the RDF is not available or does
* not contain any valid items;
* note, that the existence of the mentioned PDU APIs is not checked in this
* method.
* \see getProperty, setProperty
*/
virtual asam::mcd::MCDDatatypeAsciiStrings getPduApiNames_NSF()=0;
11.4.13 Verhalten der addMuxBranch(...)-Methoden
In einem Job kann man zum Erzeugen der Response-Struktur über die
MCDResponseParameters-Methoden addMuxBranch, addMuxBranchByIndex,
addMuxBranchByIndexWithContent, addMuxBranchWithContent und
addMuxBranchByMuxValue einem MULTIPLEXER-Parameter um einen bestimmten MUX-
Case erweitern. In der Laufzeit-Parameterstruktur kann nur ein Case-Zweig expandiert sein.
Dieser Tatsache wird in den vom Standard gelieferten Methodenbeschreibungen keine
Rechnung getragen, so dass diese Lücke in Anlehnung an den zurückgezogenen Standard
ASAM MCD-3 D 2.2 wie folgt geschlossen wird:
Der Aufruf einer der Methoden an der Parameter-Kollektion eines bereits expandierten
MULTIPLEXER-Parameters wird mit einer MCDProgramViolationException mit dem
Fehlercode eRT_INTERNAL_ERROR und dem herstellerspezifischen Fehlercode
eVS_RT_ELEMENT_ALREADY_EXISTS quittiert.
Die Methodenbeschreibungen der Java- und C++-API sind entsprechend ergänzt worden.
11.4.14 „Suppress Positive Response“ für ODX 2.0.1 basierte Datenprojekte
Für ODX 2.0.1-Daten kann ein Dienst nicht für „Suppress Positive Response“ bedatet
werden. Die nachfolgende Methode, die an den Klassen MCDService,
MCDStartCommunication und MCDStopCommunication ergänzt worden ist, ermöglicht
Applikationen die Nutzung dieser Funktionalität auch für ODX 2.0.1 basierte Datenprojekte.
/**
* Set the new suppressing mode for positive responses, without checking.
*
* to be used for ODX 2.0.1 based data projects
*
* \usage
* \param suppress (in):
* \return -
* \see setSuppressPositiveResponse
*/
virtual void setSuppressPositiveResponseUnchecked_NSF(asam::A_BOOLEAN suppress)=0;
11.4.15 MCDInterface::getModuleTypeName_NSF
/**
* Returns the name of the module type as defined in the MDF of the current PDU API.
*
* <MODULETYPE>
* <ID>nnn</ID>
* <SHORT_NAME>...</SHORT_NAME> <---
* (...)
* </MODULETYPE>
*
*
* \param -
* \return the short names of the corresponding module type as defined in the MDF
*/
virtual asam::A_ASCIISTRING getModuleTypeName_NSF()=0;
11.4.16 MCDDbODXFile, MCDDbODXFiles
Der initiale Zugriff auf die proprietäte MCDDbODXFile(s)-Schnittstelle erfolgt am

MCDDbProject:
/**
* Returns a collection of ODX files defined in the project’s database.
*
* \pre The project database must be consistent.
* \post The return value is always an MCDDbODXFiles collection.
* The length of the collection is zero if no ODX file is defined in the
* project’s database.
* - the information is not available due to an inconsistent database
* (eDB_INCONSISTENT_DATABASE, MCDDatabaseException)
*/
virtual asam::d::MCDDbODXFiles* getDbODXFiles_NSF()=0;
Die proprietäte MCDDbODXFiles-Schnittstelle bietet einen indizierten Zugriff auf einzelne

MCDDbODXFile-Elemente:
/**
* Returns the MCDDbODXFile item with the given index.
*
* \pre The index shall be in range of the data type and the collection shall have
* such an index.
* \post Returns the MCDDbODXFile item with the given index.
* - the index supplied as parameter is invalid for the current collection,
* i.e. the index is greater than the number of items - 1
* (ePAR_INDEX_OUT_OF_RANGE, MCDParameterizationException).
* This also applies in case of an empty collection.
* Note that the numbering in the collection starts at zero.
*/
virtual asam::d::MCDDbODXFile* getItemByIndex(asam::A_UINT32 ix)=0;
Die proprietäte MCDDbODXFile-Schnittstelle liefert folgende Informationen:

/**
* Returns the file name of the referenced ODX file.
* This information is retrieved from the index.xml entry ABLOCK / FILE
*
* \pre
* The ODX file information is available at the current database.
*
* Semantic:
*
* \post

*/
virtual asam::A_ASCIISTRING getFileName()=0;
/**
* Returns the file version of the referenced ODX file if named according to the VW
* authoring rule VW80128_T1_221 (Version 3.1.0):
* “Der Dateiname einer ODX-Datei wird aus der ID des DIAG-LAYERs, einem
* nachfolgenden ‚_’ sowie der Version der Datei (6 Ziffern) gebildet.”
* This information is retrieved from the index.xml entry ABLOCK / FILE.
* If the file name does not follow this rule, an empty version string is returned.
*
* \pre
*
* Semantic:
* Returns the file version of the referenced ODX file.
*
* \post
* Returns the file version of the referenced ODX file if this version is authored
* according to the VW authoring rule VW80128_T1_221 Version 3.1.0, otherwise an empty
* string.
*/
virtual asam::A_UNICODE2STRING getFileVersion()=0;
/**
* Returns the version of the ODX standard for this file.
* In case of source projects with mixed ODX standard versions
* major, minor and revision number will be set to 0.
* \pre
*
* Semantic:
*
* \post
*/
virtual asam::mcd::MCDVersion* getODXVersion()=0;
11.4.17 Unterstützung komplexer Kommunikationsparameter
Komplexe Kommunikationsparameter können vom MCD-Kernel nicht generisch verarbeitet

werden, sondern brauchen jeweils ein Spezialverhalten, um die Parameter auf die
zugehörigen D-PDU-API-Strukturen abzubilden.
Dazu muss der Aufbau des komplexen Parameters fix sein; insbesondere müssen die
Namen der Unterparameter fest definiert sein, da ansonsten die Zuordnung von Werten zu
Parametern nicht in jedem Fall vorgenommen werden kann. Da in der Praxis bezüglich der
Unterparameternamen unterschiedliche Namenskonventionen bestehen, unterstützt der
MCD-Kernel die beiden bislang bekannten, nämlich die von der ODX-
Standardisierungsgruppe propagierte und die bereits vorab im ODX2.1-Umfeld verwendete.
Die Liste der vom MCD-Kernel unterstützten komplexen Kommunikationsparameter mit den
jeweiligen Unterparametern:
- CP_UniqueRespTable
o Benennung der Unterparameter wegen flexibler Struktur und dadurch

erforderlicher Spezialbehandlung egal.
- CP_SessionTiming_Ecu, CP_AccessTiming_Ecu
o Benennung der Unterparameter egal, da die Parameter die ODX CPUSAGE

„ECU-SOFTWARE“ haben und daher standardkonform ignoriert werden.
- CP_SessionTimingOverride
o CP_SessionTimingOverride_P2Max_High
o CP_SessionTimingOverride_P2Max_Low
o CP_SessionTimingOverride_P2Star_High
o CP_SessionTimingOverride_P2Star_Low
o CP_SessionTimingOverride_SessionNumber
bzw.
o CP_P2Max_High
o CP_P2Max_Low
o CP_P2Star_High
o CP_P2Star_Low
o CP_SessionNumber
- CP_AccessTimingOverride
o CP_AccessTimingOverride_P2Max
o CP_AccessTimingOverride_P2Min
o CP_AccessTimingOverride_P3Max
o CP_AccessTimingOverride_TimingSet
bzw.
o CP_P2Max
o CP_P2Min
o CP_P3Max
o CP_P3Min
o CP_P4Min
o CP_TimingSet
- CP_ExtendedTiming
o CP_ExtendedTiming_P2Max
o CP_ExtendedTiming_P2Min
o CP_ExtendedTiming_P3Max
o CP_ExtendedTiming_TimingSet
bzw.
o CP_P2Max
o CP_P2Min
o CP_P3Max
o CP_P3Min
o CP_P4Min
o CP_TimingSet
Andere komplexe Kommunikationsparameter oder die Verwendung anderer oder gemischter

Namensschemata für die jeweiligen Unterparameter werden nicht unterstützt und müssen
bei Bedarf implementiert werden.
11.4.18 MCDParameter::getUnitTextID_NSF
/**
* Returns the text identifier of the unit belonging to this parameter.
* This method is a short cut of MCDParameter.getDbObject().getDbUnit().getLongNameID.
* The ODX item returned is PARAM / DATA-OBJECT-PROP / UNIT / LONG-NAME TI.
* If the UNIT or the TI are not available, an empty string is returned.
*
* Precondition:
* The parameter object must be valid.
* Postcondition:
* An exception (MCDProgramViolationException: eRT_INTERNAL_ERROR) will be thrown if
* - the parameter object is not valid.
*
*
* \param -
* \return the long name ID of the parameter unit
*/
virtual asam::A_ASCIISTRING getUnitTextID_NSF()=0;
11.4.19 MCDDiagComPrimitive::cancel
Die Methode MCDDiagComPrimitive::cancel darf abweichend vom MCD-3D 3.0.0 Standard

auch auf synchron gestartete Dienste, ausgenommen MCDJobs, angewendet werden.
Dies ermöglicht den geordneten Abbruch lang laufender Dienste, insbesondere

Variantenerkennungsdienste. Man beachte, dass Variantenerkennungsdienste, die intern
MCDJobs aufrufen nicht sauber abgebrochen werden können.
11.4.20 Simulationsmodus
11.4.20.1 MCD-Kernel in Simulationsmodus versetzen
Der VWMCD MCD-Kernel kann über eine Methode MCDSystem::enableSimMode_NSF in

einen Simulationsmodus versetzt werden. Dieser Modus muss unmittelbar nach Systemstart
geschaltet werden und dauert für den Rest der aktuellen Sitzung an. Ein Wechsel zurück in
den Normalmodus während einer laufenden Sitzung ist nicht möglich.
Der Simulationsmodus gilt für die komplette Sitzung und bezieht sich auf ein konkretes
Laufzeitdatenprojekt. Alle MCD-Objekte, die im Kontext dieses Projekts erstellt werden,
befinden sich ebenfalls im Simulationsmodus, was eine eingeschränkte Nutzbarkeit der

Objekte mit sich bringt.
Um den Simulationsmodus flexibel, d.h. für mehrere Logical Links nutzen zu können, wird
beim Setzen des Simulationsmodus nur der Projektname angegeben.
/**
* Activates the simulation mode for the current MCDSystem instance and returns the
* selected project.
* The simulation mode can be used to determine services matching a certain request PDU
* or to compute response parameter structures and values from a given response PDU.
* These tasks can be performed without any VCI hardware.
*
* \pre
* The MCDSystem is in state eINITIALIZED.
* Neither prepareInterface nor prepareVciAccessLayer were called yet.
*
* \post
* In case of success the simulation mode is enabled; the MCDSystem usage is restricted.
* The MCDProject returned is selected and has to be released with “deselectProject” at
* the end of the session.
* Parts of the API cannot be used in this simulation mode; some methods get a slightly
* different semantic.
*
* - the MCDSystem is in state eDBPROJECT_CONFIGURATION
* (eMCDPROGRAMVIOLATIONEXCEPTION, eRT_NOT_ALLOWED_IN_THIS_OBJECT_STATE)
* - the MCDSystem is in state eLOGICALLLY_CONNECTED
* - the MCDSystem is in state ePROJECT_SELECTED
* (eMCDPROGRAMVIOLATIONEXCEPTION, eRT_NOT_ALLOWED_IN_STATE_PROJECT_SELECTED)
* - prepareInterface has been called
* (eMCDPROGRAMVIOLATIONEXCEPTION, eRT_VCI_ACCESS_LAYER_ALREADY_PREPARED)
* - prepareVciAccessLayer has been called
* (eMCDPROGRAMVIOLATIONEXCEPTION, eRT_VCI_ACCESS_LAYER_ALREADY_PREPARED)
* - a project with the given name cannot be found
* (eMCDDATABASEEXCEPTION, eDB_ELEMENT_NOT_AVAILABLE)
*
*
* \param projectName (in): the name of the project to run in simulation mode
*
* \return the project with the given name
*/
virtual asam::mcd::MCDProject* enableSimMode_NSF(MCDDatatypeShortName& projectName)=0;
MCD3D-Methoden, die im Simulationsmodus erlaubt sind:
Klasse Methode
MCDSystem deselectProject
getActiveProject
getASAMMCDVersion
getDbProjectDescriptions
getEnumValue
getProperty
getPropertyNames
getServerType
getState
getSystemParameter
getVersion
enableSimMode_NSF (neu)
MCDProject createLogicalLink
createLogicalLinkByName
createLogicalLinkByVariant
getActiveDbVehicleInformation
getDbProject
deselectVehicleInformation
removeLogicalLink
selectDbVehicleInformation
selectDbVehicleInformationByName
MCDLogicalLink createDiagComPrimitiveByDbObject
createDiagComPrimitiveByName
removeDiagComPrimitive
getDbObject
getState
getType
getUniqueRuntimeID
MCDDiagComPrimitive und Spezialisierungen getDbObject
getRequest
MCDDiagService createResult_NSF (neu)
MCDResult getError
getResponses
hasError
getServiceShortName
MCDResponse getContainedResponseMessage
getDbObject
getError
getResponseParameters
getResponseMessage
hasError
enterResponsePDU_NSF (neu)
MCDDb… alle Standard-Methoden
Alle anderen Methoden der genannten Klassen werden im Simulationsmodus mit einer
MCDProgramViolationException (eRT_NOT_ALLOWED_IN_THIS_OBJECT_STATE)
quittiert.
Nicht genannte Klassen, die über die obigen Schnittstellen erreichbar sind, können
voraussichtlich gegenüber dem Standard unverändert genutzt werden.
11.4.20.2 Auswahl passender Dienste zu Request-PDU
Der VWMCD MCD-Kernel liefert über die Methode

MCDDbLocation::getDbDiagComPrimitivesByRequestPDU_NSF eine Liste von
MCDDbDiagComPrimitive-Objekten, die zur gegebenen Request-PDU passen, d.h. bei
denen der Aufruf von enterPDU am MCDRequest des zugehörigen Laufzeitdienstes
(MCDDiagComPrimitive) zu keinem Fehler führte. Das Ergebnis kann eine leere Kollektion
sein.
/**
* Detects all MCDDbDiagComPrimitive items of the current location accepting a certain
* request PDU.
*
* \pre
* The MCDSystem is in simulation mode.
*
* \post
* In case of success the MCDDbDiagComPrimitives collection contains all services
* (MCDDbDiagComPrimitive items) of the current location accepting the given request PDU.
* The collection is empty, if no service request matches.
* The collection gets invalid for further access when this method is called again at the
* same location.
*
* - the MCDSystem is not in simulation mode
*
*
* \param requestPDU (in): the request PDU byte field that shall match the services
*
* \return the collection of db services accepting the given request PDU
*/
virtual asam::d::MCDDbDiagComPrimitives*
getDbDiagComPrimitivesByRequestPDU_NSF(asam::A_BYTEFIELD& requestPDU)=0;
11.4.20.3 Erzeugen eines MCDResult-Objekts für einen MCDDiagService
Der VWMCD MCD-Kernel bietet über die Methode MCDDiagService::createResult_NSF die

Möglichkeit, im Simulationsmodus ein MCDResult für den gegebenen Dienst zu erzeugen.
Die weitere Befüllung des MCDResult kann analog zum Füllen eines MCDJob-MCDResult-
Objekts unter Verwendung der Methoden MCDResult::getResponses und
MCDResponses::add vorgenommen werden.
/**
* Creates an empty MCDResult item at the current MCDDiagComPrimitive.
*
* \pre
* The MCDDiagComPrimitive does not contain any MCDResult items.
*
* \post
* In case of success the MCDDiagComPrimitive contains an MCDResult item with an empty
* MCDResponses collection. The MCDResult contains an MCDError item with the given error
* properties.
*
* - the MCDDiagComPrimitive already contains an MCDResult item
* (eMCDPROGRAMVIOLATIONEXCEPTION, eRT_INTERNAL_ERROR)
*
*
* \param resultType (in): the type of the result, see MCDResultType
* \param errorCode (in): the error code of the MCDError set at the MCDResult,
* see MCDDErrorCodes
* \param errorCodeDesc (in): the error description of the MCDError set at the MCDResult
* \param vendorErrorCode (in): the vendor error code of the MCDError set at the MCDResult
* \param vendorCodeDesc (in): the vendor error description of the MCDError set at the
* MCDResult
* \param severity (in): the severity of the MCDError set at the MCDResult,
* see MCDSeverity
*
* \return empty MCDResult created with the given properties
*/
virtual asam::mcd::MCDResult* createResult_NSF(asam::mcd::MCDResultType resultType,
asam::mcd::MCDErrorCodes errorCode,
asam::A_ASCIISTRING& errorCodeDesc,
asam::A_UINT16 vendorErrorCode,
asam::A_ASCIISTRING& vendorCodeDesc,
asam::mcd::MCDSeverity severity)=0;
11.4.20.4 Setzen einer Response-PDU
Der VWMCD MCD-Kernel bietet über die Methode MCDResponse:enterResponsePDU_NSF

die Möglichkeit, im Simulationsmodus eine MCDResponse über eine Response-PDU zu
expandieren. Das Erstellen der Response-Parameter auf Basis der PDU erfolgt inklusive der
Fehlerbehandlung analog zur regulären Dienstausführung.
/**
* Sets a certain response PDU at the current MCDResponse.
* If the MCDResponse has been added with the flag “positive”, the response PDU is used with
* the positive db response templates.
* If the MCDResponse has been added with the flag “negative”, the response PDU is used with
* the local and global negative db response templates. The local negative templates are
* checked first.
* In both cases, positive or negative responses, the first matching db response template is
* considered for the creation of the corresponding response parameter structure and the
* parameter values.
* If the response PDU does not fit to any db response template an MCDError is set at the
* MCDResponse.
* Db response templates containing matching request parameters cannot be checked, since the
* request PDU is unknown.
*
* \pre
* The MCDDiagComPrimitive does not contain any MCDResult items.
*
* \post
* In case of success the MCDResponse structure is expanded according to the given
* response PDU. If the PDU does not match any db response template, the MCDResponse
* contains an MCDError item.
*
*
*
* \param responsePDU (in): the response PDU byte field that shall be applied to the
* current MCDResponse
*
* \return -
*/
virtual void enterResponsePDU_NSF(asam::A_BYTEFIELD responsePDU)=0;
11.4.21 Laden von MCD-Kernel DLLs
Wenn der MCD-Kernel über eine Java-Applikation betrieben wird, muss er bei der
Ausführung von Java-Jobs die Java VM der Applikation nutzen. Dies wird erreicht, indem die
Applikation den MCD-Kernel lädt, also eine MCDSystem-Instanz erstellt. Wenn sich die
Applikation selbst nicht beim MCD-Kernel freischaltet, sondern dies erst in einer
unterlagerten Software-Komponente geschieht, wird das Erstellen der MCDSystem-Instanz
mit einem Lizenzfehler quittiert.
Zur Vermeidung der Lizenzfehlermeldung stellt der MCD-Kernel an der internen Java-Klasse
MCDSystemImp eine Methode zur Verfügung, über die eine Java-Applikation nur die MCD-
Kernel-DLLs laden kann, ohne eine MCDSystem-Instanz zu erstellen.
public static void preloadMCDKernelDlls_NSF() throws Exception
11.4.22 Reaktion auf TCP-Verbindungsverlust
Eine standardkonforme D-PDU-API reagiert auf einen TCP-Verbindungsverlust, wie er zum

Beispiel im DoIP-Kontext auftreten kann, mit einem Statuswechsel des zugehörigen PDU-
Links nach PDU_CLLST_OFFLINE.
Aus MCD-Sicht ist dieser Statuswechsel nicht vorgesehen: Der zugehörige MCDLogicalLink-
Status eOFFLINE ist laut MCD-Standard erreichbar durch Öffnen eines MCDLogicalLinks
(LL.open()) oder nach einem VCI-Verbindungsverlust. Der MCD-Kernel reagiert also bis dato
nicht auf diesen Statuswechsel, so dass die Applikation zwar beim Ausführen der Dienste
Fehler vermeldet bekommt, aber ansonsten nicht aktiv über einen Link-Fehler informiert wird.
Diese Diskrepanz zwischen den Status des MCDLogicalLinks und des PDU-Links kann je
nach sonstiger Fehlerbehandlung durch die D-PDU-API zu unauflösbaren Zuständen im
MCD-Kernel führen.
Als Lösung dieses Konflikts vermeldet der MCD-Kernel den unerwarteten Wechsel von
PDU_CLLST_COM_STARTED nach PDU_CLLST_OFFLINE über das Event onLinkError
mit einem aussagekräftigen MCDError an die Applikation, auch wenn die D-PDU-API kein
Error-Event geschickt hat.
Der MCD-Kernel nimmt für den MCDLogicalLink keinen Statuswechsel vor. Vielmehr kann
die Applikation auf onLinkError mit einem LL.reset reagieren, um den MCDLogicalLink selbst
in einen sauberen Status zu bringen, von dem aus weiter gearbeitet werden kann.
Diese Lösung steht nicht im unmittelbaren Widerspruch zum MCD-Standard, der den Fall
einfach nicht behandelt.
11.4.23 Erweiterte Parameterinformationen
Über die MCD3D-API können nicht alle Informtationen abgefragt werden, um einen internen
Parameterwert gemäß ODX in einen physikalischen Wert umzurechnen.
Als Ergänzung zur Standard-API werden die fehlenden Informationen über die zentrale
Schnittstelle ExtendedParameterInfo zur Verfügung gestellt.
API-Methoden von ExtendedParameterInfo
getPhysicalDataType_NSF() : asam::mcd::MCDDataType
Returns the physical data type of the corresponding parameter DOP.
If the corresponding parameter does not contain a DOP, but only a DIAG-CODED-TYPE, the
coded data type is returned, because in this case both values are identical.
ODX: DATA-OBJECT-PROP/PHYSICAL-TYPE/BASE-DATA-TYPE
ODX: DIAG-CODED-TYPE/BASE-DATA-TYPE
isDiagCodedTypeAvailable_NSF() : asam::A_BOOLEAN
Checks whether the diag coded type is given with the corresponding parameter.
This method should be used before calling the methods getCodedDataType and
getDiagCodedType, because these methods throw an exception if the diag coded type is not
available.
getCodedDataType_NSF() : asam::mcd::MCDDataType
Returns the coded data type of the corresponding parameter DIAG-CODED-TYPE.
ODX: DIAG-CODED-TYPE / BASE-DATA-TYPE
Postcondition:
- the diag coded type is not available
getDiagCodedType_NSF() : asam::ext::EDbDiagCodedType
Returns the special type of the corresponding parameter DIAG-CODED-TYPE.
ODX: DIAG-CODED-TYPE / PARAM-LENGTH-INFO-TYPE

ODX: DIAG-CODED-TYPE / LEADING-LENGTH-INFO-TYPE
ODX: DIAG-CODED-TYPE / MIN-MAX-LENGTH-TYPE
ODX: DIAG-CODED-TYPE / STANDARD-LENGTH-TYPE
Postcondition:
- the diag coded type is not available
getRequestBytePosition_NSF() : asam::A_UINT32
Returns the request byte position of the corresponding matching request parameter.
The request byte position is only available for parameters with MCDParameterType
eMATCHING_REQUEST_PARAM.
ODX: MATCHING-REQUEST-PARAM / REQUEST-BYTE-POS
Postcondition:
- the method is not supported for the current parameter type
isBitMaskAvailable_NSF() : asam::A_BOOLEAN
Checks, whether a bit mask is given with the corresponding parameter DIAG-CODED-TYPE.
This method should be used before calling getBitMask, because this method throws an
exception if the bit mask is not available.
getBitMask_NSF() : asam::A_BYTEFIELD
Returns the bit mask of the corresponding parameter DIAG-CODED-TYPE.
ODX: STANDARD-LENGTH-TYPE / BIT-MASK
Postcondition:
- the bit mask is not available
isCondensedBitMask_NSF() : asam::A_BOOLEAN
Checks, whether the bit mask of the corresponding parameter DIAG-CODED-TYPE is

condensed.
Postcondition:
- the bit mask is not available
isTerminationAvailable_NSF() : asam::A_BOOLEAN
Checks, whether a termination information is given with the corresponding parameter DIAG-
CODED-TYPE.
This method should be used before calling getTermination, because this method throws an
exception if the termination information is not available.
getTermination_NSF() : asam::ext::EDbTermination
Returns the termination information of the corresponding parameter DIAG-CODED-TYPE.
ODX: MIN-MAX-LENGTH-TYPE / TERMINATION
Postcondition:
- the termination information is not available
getEncoding_NSF() : asam::ext::EDbEncoding
Returns the encoding.
ODX: DIAG-CODED-TYPE / BASE-TYPE-ENCODING
Postcondition:
- the encoding information is not available
isHighLowByteOrder_NSF() : asam::A_BOOLEAN
Returns the PDU byte order interpretation determined for the corresponding parameter.
isCompuCategoryAvailable_NSF() : asam::A_BOOLEAN
Checks, whether the computation method category is given with the corresponding
parameter.
This method should be used before calling getCompuCategory.
getCompuCategory_NSF() : asam::ext::EDbCompuCategory
Returns the computation method category of the corresponding parameter DOP.
It is possible to provide ODX data with both, COMPU-PHYS-TO-INTERNAL and COMPU-

INTERNAL-TO-PHYS, at one DOP, but there's only one compu-category set at the COMPU-
METHOD.
ODX: COMPU-METHOD / COMPU-CATEGORY
Postcondition:
- the computation method category is not available
isCodedToPhysConversionAvailable_NSF() : asam::A_BOOLEAN
Checks, whether the computation method of the corresponding parameter DOP contains a
"coded to physical"-conversion.
The method returns false, if the ODX data contains only the COMPU-PHYS-TO-INTERNAL
element, even if this conversion is invertible.
getCodedToPhysCompuDefaultValue_NSF() : asam::mcd::MCDValue
Returns the computation default value of the corresponding parameter DOP computation
method for the conversion direction COMPU-INTERNAL-TO-PHYS.
ODX: COMPU-METHOD/COMPU-INTERNAL-TO-PHYS/COMPU-DEFAULT-VALUE
Postcondition:
- the computation default value is not available
getCodedToPhysCompuDefaultInverseValue_NSF() : asam::mcd::MCDValue
Returns the computation default invers value of the corresponding parameter DOP
computation method for the conversion direction COMPU-INTERNAL-TO-PHYS.
ODX: COMPU-METHOD / COMPU-INTERNAL-TO-PHYS / COMPU-DEFAULT-VALUE /

COMPU-INVERSE-VALUE
Postcondition:
- the computation default inverse value is not available
getCodedToPhysCompuScales_NSF() : asam::ext::EPIDbCompuScales
Returns the computation scale collection of the corresponding parameter DOP for the
conversion direction COMPU-INTERNAL-TO-PHYS.
ODX: COMPU-METHOD / COMPU-INTERNAL-TO-PHYS / COMPU-SCALE
Postcondition:
- the computation scales are not available
isCodedToPhysProgCodeAvailable_NSF() : asam::A_BOOLEAN
Checks, whether the computation method of the corresponding parameter DOP for the
conversion direction COMPU-INTERNAL-TO-PHYS contains prog code data.
getCodedToPhysProgCodeCodeFile_NSF() : asam::A_UNICODE2STRING
Returns the prog code code file of the corresponding parameter DOP computation method
for the conversion direction COMPU-INTERNAL-TO-PHYS.
ODX: COMPU-METHOD / COMPU-INTERNAL-TO-PHYS / PROG-CODE/ CODE-FILE
Postcondition:
- the prog code is not available
getCodedToPhysProgCodeSyntax_NSF() : asam::A_UNICODE2STRING
Returns the prog code syntax of the corresponding parameter DOP computation method for
the conversion direction COMPU-INTERNAL-TO-PHYS.
ODX: COMPU-METHOD / COMPU-INTERNAL-TO-PHYS / PROG-CODE / SYNTAX
Postcondition:
getCodedToPhysProgCodeEntrypoint_NSF() : asam::A_UNICODE2STRING
Returns the prog code entry point of the corresponding parameter DOP computation method
for the conversion direction COMPU-INTERNAL-TO-PHYS.
If the prog code item is available, but the optional entry point data is missing, an empty string
will be returned.
ODX: COMPU-METHOD / COMPU-INTERNAL-TO-PHYS / PROG-CODE / ENTRYPOINT
Postcondition:
isPhysToCodedConversionAvailable_NSF() : asam::A_BOOLEAN
Checks, whether the computation method of the corresponding parameter DOP contains a
"physical to coded"-conversion.
The method returns false, if the ODX data contains only the COMPU-INTERNAL-TO-PHYS
element, even if this conversion is invertible.
getPhysToCodedCompuDefaultValue_NSF() : asam::mcd::MCDValue
Returns the computation default value of the corresponding parameter DOP computation
method for the conversion direction COMPU-PHYS-TO-INTERNAL.
ODX: COMPU-METHOD/COMPU-PHYS-TO-INTERNAL/COMPU-DEFAULT-VALUE
Postcondition:
- the computation default value is not available
getPhysToCodedCompuDefaultValueInverseValue_NSF() : asam::mcd::MCDValue
Returns the computation default inverse value of the corresponding parameter DOP
computation method for the conversion direction COMPU-PHYS-TO-INTERNAL.
ODX: COMPU-METHOD / COMPU-PHYS-TO-INTERNAL / COMPU-DEFAULT-VALUE /

COMPU-INVERSE-VALUE
Postcondition:
- the computation default inverse value is not available
getPhysToCodedCompuScales_NSF() : asam::ext::EPIDbCompuScales
Returns the computation scale collection of the corresponding parameter DOP for the
conversion direction COMPU-PHYS-TO-INTERNAL.
ODX: COMPU-METHOD / COMPU-PHYS-TO-INTERNAL / COMPU-SCALE
Postcondition:
- the compu scales are not available
isPhysToCodedProgCodeAvailable_NSF() : asam::A_BOOLEAN
Checks, whether the computation method of the corresponding parameter DOP for the
conversion direction COMPU-PHYS-TO-INTERNAL contains prog code data.
getPhysToCodedProgCodeCodeFile_NSF() : asam::A_UNICODE2STRING
Returns the prog code code file of the corresponding parameter DOP computation method
for the conversion direction COMPU-PHYS-TO-INTERNAL.
ODX: COMPU-METHOD / COMPU-PHYS-TO-INTERNAL / PROG-CODE / CODE-FILE
Postcondition:
getPhysToCodedProgCodeSyntax_NSF() : asam::A_UNICODE2STRING
Returns the prog code syntax of the of the corresponding parameter DOP computation
ODX: COMPU-METHOD/COMPU-PHYS-TO-INTERNAL/PROG-CODE/SYNTAX
Postcondition:
getPhysToCodedProgCodeEntrypoint_NSF() : asam::A_UNICODE2STRING
Returns the prog code entry point of the of the corresponding parameter DOP computation
ODX: COMPU-METHOD / COMPU-PHYS-TO-INTERNAL / PROG-CODE / ENTRYPOINT
Postcondition:
Für die Bereitstellung bestimmter ODX-Datendetails werden zusätzliche Aufzählungstypen

benötigt, nämlich EDbCompuCategory, EDbDiagCodedType, EDbEncoding und
EDbTermination.
Elemente des Aufzählungstyps EDbCompuCategory
eIDENTICAL // ODX: COMPU-METHOD / CATEGORY / IDENTICAL
eLINEAR // ODX: COMPU-METHOD / CATEGORY / LINEAR
eSCALE_LINEAR // ODX: COMPU-METHOD / CATEGORY / SCALE-LINEAR
eTEXTTAB // ODX: COMPU-METHOD / CATEGORY / TEXTTABLE

eCOMPUCODE // ODX: COMPU-METHOD / CATEGORY / COMPUCODE
eTAB_INTP // ODX: COMPU-METHOD / CATEGORY / TAB-INTP
eRAT_FUNC // ODX: COMPU-METHOD / CATEGORY / RAT-FUNC
eSCALE_RAT_FUNC// ODX: COMPU-METHOD / CATEGORY / SCALE-RAT-FUNC
Elemente des Aufzählungstyps EDbDiagCodedType
eLEADING_LENGTH_INFO_TYPE // ODX: LEADING-LENGTH-INFO-TYPE
eMIN_MAX_LENGTH_TYPE // ODX: MIN-MAX-LENGTH-TYPE
eSTANDARD_LENGTH_TYPE // ODX: STANDARD-LENGTH-TYPE
ePARAM_LENGTH_INFO_TYPE // ODX: PARAM-LENGTH-INFO-TYPE
Elemente des Aufzählungstyps EDbEncoding
eBCD_P // ODX: ENCODING / BCD-P
eBCD_UP // ODX: ENCODING / BCD-UP
e1C // ODX: ENCODING / 1C
e2C // ODX: ENCODING / 2C
eSM // ODX: ENCODING / SM
eUTF_8 // ODX: ENCODING / UTF-8
eUCS_2 // ODX: ENCODING / UCS-2
eIEEE754 // Default-Encoding für A_FLOAT32/64
eISO_8859_1 // ODX: ENCODING / ISO-8859-1
eISO_8859_2 // ODX: ENCODING / ISO-8859-2
eWINDOWS_1252 // ODX: ENCODING / WINDOWS-1252
eNONE // ODX: ENCODING / NONE
Elemente des Aufzählungstyps EDbTermination
eENDOFPDU // ODX: MIN-MAX-LENGTH-TYPE / TERMINATION / END-OF-PDU
eZERO // ODX: MIN-MAX-LENGTH-TYPE / TERMINATION / ZERO
eHEX_FF // ODX: MIN-MAX-LENGTH-TYPE / TERMINATION / HEX-FF
ODX COMPU-SCALEs werden als Kollektion EPIDbCompuScales geliefert; der Zugriff auf
einzelne EPIDbCompuScale-Elemente, die intervallbezogene Umrechnungsformeln
enthalten, erfolgt per Index.
API-Methoden von EPIDbCompuScales
getItemByIndex_NSF(asam::A_UINT32 index) : asam::ext::EDbCompuScale
Returns the item with the given index from the collection.
Postcondition:
- the index is out of range
(MCDParameterizationException, ePAR_INDEX_OUT_OF_RANGE)
getCount_NSF() : asam::A_UINT32
Returns the number of computation scales in the current computation scale collection.
API-Methoden von EPIDbCompuScale
getLowerLimit_NSF() : asam::mcd::MCDValue
Returns the value of the lower limit of the current computation scale.
ODX: COMPU-SCALE / LOWER-LIMIT / CONTENT
Postcondition:
- the lower limit is not available
getLowerLimitType_NSF() : asam::mcd::MCDLimitType
Returns the lower limit type of the current computation scale.
ODX: COMPU-SCALE / LOWER-LIMIT / INTERVAL-TYPE
Postcondition:
- the lower limit is not available
getUpperLimit_NSF() : asam::mcd::MCDValue
Returns the value of the upper limit of the current computation scale.
ODX: COMPU-SCALE / UPPER-LIMIT / CONTENT
Postcondition:
- the upper limit is not available
getUpperLimitType_NSF() : asam::mcd::MCDLimitType
Returns the upper limit type of the current computation scale.
ODX: COMPU-SCALE / UPPER-LIMIT / INTERVAL-TYPE
Postcondition:
- the upper limit is not available
getCompuInverseValue_NSF() : asam::mcd::MCDValue
Returns the computation inverse value of the current computation scale.
ODX: COMPU-SCALE / COMPU-INVERSE-VALUE
Postcondition:
- the computation inverse value is not available
getCompuConst_NSF() : asam::mcd::MCDValue
Returns the physical constant value of the current computation scale.
ODX: COMPU-SCALE / COMPU-CONST
Postcondition:
- the physical constant value is not available
getNoOfNumerators_NSF() : asam::A_UINT32
Returns the number of numerators of the current computation scale.
getNumeratorByIndex_NSF(asam::A_UINT32 index) : asam::A_FLOAT64
Returns the numerator with the given index.
ODX: COMPU-SCALE / COMPU-RATIONAL-COEFFS / COMPU-NUMERATOR
Postcondition:
getNoOfDenominators_NSF() : asam::A_UINT32
Returns the number of denominators of the current computation scale.
getDenominatorByIndex_NSF(asam::A_UINT32 index) : asam::A_FLOAT64
Returns the denominator with the given index.
ODX: COMPU-SCALE / COMPU-RATIONAL-COEFFS / COMPU-DENOMINATOR
Postcondition:
ExtendedParameterInfo ist erreichbar über die proprietäre Methode

getExtendedParameterInfo_NSF am MCDDbParameter.
getExtendedParameterInfo_NSF() : asam::ext::ExtendedParameterInfo
Returns the extended parameter information of the current parameter.
Die erweiterte Schnittstelle wird für C++ und Java angeboten, aber nicht über die COM-API
zur Verfügung gestellt.
11.4.24 Proprietäre Bibliothek zur Einheitenumrechnung
Die Java-Schnittstelle UnitConversion in McdKernelUnitConversion.jar bietet die folgenden

Methoden zur Einheitenumrechnung:
/**
* Returns the value of the given parameter which is converted according to the given
* unit group.
*
* First of all the current unit of the given parameter is determined via the given
* logical link.
* Then - by calling the function convertValueByUnitGroup - the parameter's value is converted
* from the current unit into the corresponding unit containing in the given unit group
* (target unit).
*
* @param param (in): parameter whose value should be converted
* (it must contain a default unit with a physical dimension)
* @param logLink (in): the corresponding logical link
* (it is needed to determine the current unit of the parameter value)
* @param unitGroup (in): unit group containing a suitable unit for the conversion of
* parameter value,
* i.e. it must contain a unit with the same physical dimension as the
* parameter's default unit
* @return converted parameter value
* @throws MCDDataBaseException DB element not available
* (eVS_DB_ELEMENT_NOT_AVAILABLE_2)
* if the given parameter does not have a default unit or
* if the default unit does not have a physical dimension.
* MCDParameterizationException invalid value data type
* (eVS_PAR_INVALID_TYPE_3)
* if the parameter's type is not set.
* MCDProgramViolationException no suitable unit found
* (eVS_RT_NO_SUITABLE_UNIT_FOUND)
* if no target unit is found within the given unit
* group.
*/
public abstract MCDValue getValueByUnitGroup (MCDParameter param,
MCDLogicalLink logLink,
MCDDbUnitGroup unitGroup) throws MCDException;
/**
* Converts the given parameter value of type MCDValue from the given current unit into the
* corresponding unit containing in the given unit group (target unit) and returns the
* converted parameter value.
*
* @param paramValue (in): current parameter value of type MCDValue
* (its value and type must be set)
* @param currUnit (in): current unit of the parameter value
* Note: Make sure that this unit corresponds to the given parameter
* value
* parameter value,
* given current unit
* @return converted parameter value of type MCDValue
* @throws MCDParameterizationException invalid value data type
* (eVS_PAR_INVALID_TYPE_3)
* if the parameter's type is not set.
* MCDDataBaseException DB element not available
* if the current unit does not have a physical dimension.
* if no target unit is found within the given unit group.
*/
public abstract MCDValue convertValueByUnitGroup(MCDValue paramValue,
MCDDbUnit currUnit,
MCDDbUnitGroup unitGroup)throws MCDException;
/**
* Converts the given parameter value of type long from the given current unit into the
*
* @param paramValue (in): current parameter value of type long
* parameter value,
* @return converted parameter value of type long
*/
public abstract long convertLongByUnitGroup(long paramValue,
MCDDbUnit currUnit,
/**
* Converts the given parameter value of type double from the given current unit into the
*
* @param paramValue (in): current parameter value of type double
* parameter value,
* @return converted parameter value of type double
*/
public abstract double convertDoubleByUnitGroup(double paramValue,
MCDDbUnit currUnit,
/**
* Returns the target unit containing in the given unit group which has the same physical
* dimension as the given current unit.
*
* @param currUnit (in): current unit
* @param unitGroup (in): unit group in which the target unit (= unit with the same physical
* dimension as the given current unit) will be searched for.
* @return target unit
*/
public abstract MCDDbUnit getTargetUnit(MCDDbUnit currUnit,
/**
* Converts a parameter value of type MCDValue from a certain source unit into the suitable
* target unit contained in the given unit group and returns the converted parameter value.
* The target unit is determined as follows:
* - Get the collection of MCDDbUnitGroups with category "eEQUIVALENT_UNIT" available for the
* current logical link.
* - Within this collection look for an MCDDbUnitGroup referencing a matching MCDDbUnit.
* The MCDDbUnit matches if
* 1) it has the same physical dimensions as the source MCDDbUnit
* 2) the target MCDDbUnitGroup with category "eCOUNTRY" references an MCDDbUnit with the
* same short name.
* - If the collection of MCDDbUnitGroups with category "eEQUIVALENT_UNIT" is empty, try to
* find a matching MCDDbUnit in the target unit group with category "eCOUNTRY".
* 1) it has the same physical dimensions as the source MCDDbUnit.
*
* @param paramValue (in): current parameter value of type MCDValue
* parameter value, i.e. it must contain a unit with the same
* physical dimension as the given current unit
* @param logLink (in): the logical link serving as context for the eEQUIVALENT_UNIT-
* detection
*
* @return converted parameter value of type MCDValue
* @throws MCDParameterizationException if the parameter's type is not set.
* (ePAR_INVALID_TYPE)
*
* MCDDatabaseException if the current unit does not have any physical
* dimension.
* (eDB_ELEMENT_NOT_AVAILABLE)
*
* MCDProgramViolationException if no target unit is found within the given
* unit group
* (eRT_INTERNAL_ERROR)
*
* MCDProgramViolationException if the value conversion failed
*
*/
public abstract MCDValue convertValueByEquivUnitGroup(MCDValue paramValue,
MCDDbUnit currUnit,
MCDDbUnitGroup unitGroup,
MCDLogicalLink logLink)
throws MCDException;
/**
* Converts a parameter value of type long from a certain source unit into the suitable
* same short name.
*
* @param paramValue (in): current parameter value of type long
* detection
*
* @return converted parameter value of type long
* @throws MCDDatabaseException if the current unit does not have any physical
* dimension.
*
* unit group
*
*
*/
public abstract long convertLongByEquivUnitGroup(long paramValue,

MCDDbUnit currUnit,
MCDLogicalLink logLink) throws MCDException;
/**
* Converts a parameter value of type double from a certain source unit into the suitable

* same short name.
*
* @param paramValue (in): current parameter value of type double
* detection
*
* @return converted parameter value of type double
* dimension.
*
* unit group
*
*
*/
public abstract double convertDoubleByEquivUnitGroup(double paramValue,
MCDDbUnit currUnit,
/**
* Returns the matching target unit contained in the given unit group.
* same short name.
*
* detection
*
* @return the matching target unit if any

* dimension.
*
* unit group
*
*/
public abstract MCDDbUnit getTargetUnitByEquivUnitGroup(MCDDbUnit currUnit,
11.4.25 Abfrage von Preconditions an Table-Rows
Über die Standard MCD3D-API können an einem MCDDbTableParameter (entspricht einer

ODX TABLE-ROW) keine Preconditions (ODX PRE-CONDITION-STATE-REFs) abgefragt
werden.
Als Ergänzung zur Standard-API werden die fehlenden Informationen über zusätzliche
Methoden an bestehenden Schnittstellen zur Verfügung gestellt.
Erweiterungen an MCDDbTableParameter
getDbPreConditionStatesByDbObject_NSF
(asam::d::MCDDbEcuStateChart stateChart) : asam::d::MCDDbEcuStates
Returns the collection of ECU states belonging to the given MCDDbEcuStateChart which are
considered as precondition states for the execution of the current table row.
The collection might be empty if the execution of the current table row is not restricted by any
precondition of the state chart context.
- the input ecu state chart is not valid in the current context
(MCDParameterizationException, ePAR_INVALID_OBJECT)
- the resulting collection would contain at least one duplicate short name entry
(MCDDatabaseException, eDB_INCONSISTENT_DATABASE)
getDbPreConditionStatesBySemantic_NSF
(asam::A_ASCIISTRING semantic) : asam::d::MCDDbEcuStates
Returns the collection of ECU states belonging to the given MCDDbEcuStateChart semantic
which are considered as precondition states for the execution of the current table row.
The collection might be empty if the execution of the current table row is not restricted by any
precondition of the semantic context.
- the resulting collection would contain at least one duplicate short name entry
(MCDDatabaseException, eDB_INCONSISTENT_DATABASE)
Erweiterungen an MCDDbEcuState
getDbRestrictedTableParameters_NSF() : asam::d::MCDDbPreconditionDefinitions
Returns a collection of precondition definitions for table rows “executable” in the current ECU
state. The collection migth be empty if the current ECU state is not a precondition state for
any table row.
Erweiterungen an MCDDbPreconditionDefinition
getDbTableParameter_NSF() : asam::d::MCDDbTableParameter
Returns the table parameter (table row) of which the current ECU state is considered an
execution precondition.
An MCDDatabaseException with error code eDB_ELEMENT_NOT_AVAILABLE will be

thrown if the MCDDbTableParameter cannot be determined.
Restriktionen
MCDDbEcuStateChart stellt keine zu getDbPreConditionStateDiagComPrimitives() und

getDbStateTransitionDiagComPrimitives() analogen Methoden
getDbPreConditionStateTableParameters_NSF() und
getDbStateTransitionTableParameters_NSF() zur Verfügung.
11.4.26 MCDLogicalLink::isComParamSupportedByInterface_NSF
Es gibt über die standardisierte MCD-API keine Möglichkeit herauszufinden, ob ein

ComParam-Wert der Default aus dem ODX oder ein tatsächlich über das VCI ermittelter
Wert ist. Ein Wertevergleich hilft einer Applikation somit nicht, die gewünschte Information zu
ermitteln.
In der Praxis ist die CAN-FD-Fähigkeit an einzelne Ressourcen des jeweiligen VCI-Typs
gekoppelt. Ein MCDLogicalLink kann mit oder ohne Angabe einer speziellen Ressource
geöffnet werden.
Um herauszufinden, ob die vom VCI für den MCDLogicalLink verwendete Ressource eine
Diagnose über CAN-FD ermöglicht oder nicht, muss also der MCDLogicalLink auf jeden Fall
geöffnet sein.
Anschließend benötigt man eine zusätzliche Methode, die dann für einen beliebigen
ComParam die Info liefert, ob die D-PDU-API ihn unterstützt oder nicht, unabhängig davon,
ob der ComParam optional ist oder nicht. Die Methode kann dann applikationsseitig für einen
speziellen CAN FD ComParam aufgerufen werden, um auf diese Weise zu erfahren, ob über
CAN FD kommuniziert werden kann.
Die Schnittstelle des MCD-Kernels, konkret die Klasse asam::mcd::MCDLogicalLink, wird um

folgende Methode erweitert:
/**
* Returns true, if the vehicle interface used by the logical link supports the given
* communication parameter on this logical link, otherwise false.
*
*
* \note provided by DSA as standard enhancement for CAN FD support
*
* \param comParamName (in): name of communication parameter to be checked
*
* Precondition:
* The MCDLogicalLink object must be valid, created and opened.
* Postcondition:
* An exception (MCDProgramViolationException: eRT_NOT_ALLOWED_IN_LL_STATE_CREATED)
* will be thrown if
* - the logical link is in state eCREATED (not opened).
*/
virtual asam::A_BOOLEAN isComParamSupportedByInterface_NSF
(asam::mcd::MCDDatatypeShortName comParamName)=0;
11.4.27 Verhalten von setSuppressPositiveResponse
Für die Methode setSuppressPositiveResponse der MCD API-Klassen MCDService,

MCDStartCommunication und MCDStopCommunication liefert der MCD-Kernel folgendes
Verhalten:
/**
* Set the new suppressing mode for positive responses.
*
* \pre
* The Service/Control Primitive shall be able to suppress positive responses.
*
* Semantic:
* Enables (input value = true) or disables (input value = false)
* suppression of positive responses for the current service/control primitive by means of
* - the current internal value 'intVal'of the request parameter that shall be considered
* for positive response suppression, see ODX / POS-RESPONSE-SUPPRESSABLE / VALUE-SNREF
* - the bit mask value 'bmVal' that shall be considered for positive response
* suppression, see ODX / POS-RESPONSE-SUPPRESSABLE / BIT-MASK
*
* In case of input value true:
* The bit mask value 'bmVal' is applied with an OR-semantic to the parameter value
* 'intVal'.
* The result is stored in the request PDU of the service/control primitive being executed.
* Additionally the control flag SUPPRESS_POS_RESP is set in the PDU_COP_CTRL_DATA.
*
* In case of input value false:
* The bit mask value 'bmVal' is negated and applied with an AND-semantic to the parameter
* value 'intVal'.
* The result is stored in the request PDU of the service/control primitive being executed.
* The control flag SUPPRESS_POS_RESP is not set in the PDU_COP_CTRL_DATA.
*
* \post
* If the method succeeds, the new suppress mode is set.
* - the Service/Control Primitive does not support suppressing positive response
* (MCDProgramViolationxception: eRT_FEATURE_NOT_AVAILABLE)
*/
virtual void setSuppressPositiveResponse(asam::A_BOOLEAN suppress)=0;
Das beschriebene Verhalten gilt für Laufzeitdaten auf Basis von ODX 2.2 oder ODX 2.1.0.
Beispiel
Gegeben sei die folgende ODX-Bedatung (Auszug):

<DATA-OBJECT-PROP ID="SIMPLE_DOP">
<SHORT-NAME>SIMPLE_DOP</SHORT-NAME>
<COMPU-METHOD>
<CATEGORY>IDENTICAL</CATEGORY>
</COMPU-METHOD>
<DIAG-CODED-TYPE xsi:type="STANDARD-LENGTH-TYPE" BASE-DATA-TYPE="A_UINT32">
<BIT-LENGTH>8</BIT-LENGTH>
</DIAG-CODED-TYPE>
<PHYSICAL-TYPE BASE-DATA-TYPE="A_UINT32"/>
</DATA-OBJECT-PROP>
<DIAG-SERVICE ID="DIAG_NO_DEF_SPR_ID">
<SHORT-NAME>DIAG_NO_DEF_SPR</SHORT-NAME>
<AUDIENCE/>
<REQUEST-REF ID-REF="REQ_NO_DEF_SPR_ID"/>
<POS-RESPONSE-REFS>
<POS-RESPONSE-REF ID-REF="RESPONSE_ID"/>
</POS-RESPONSE-REFS>
<NEG-RESPONSE-REFS>
<NEG-RESPONSE-REF ID-REF="NEG_RESPONSE_ID"/>
</NEG-RESPONSE-REFS>
<POS-RESPONSE-SUPPRESSABLE>
<BIT-MASK>80</BIT-MASK> 
<VALUE-SNREF SHORT-NAME="REQ_PAR_SPR"/>
</POS-RESPONSE-SUPPRESSABLE>
</DIAG-SERVICE>
<DIAG-SERVICE ID="DIAG_DEF_SPR_ID">
<SHORT-NAME>DIAG_DEF_SPR</SHORT-NAME>
<AUDIENCE/>
<REQUEST-REF ID-REF="REQ_DEF_SPR_ID"/>
<POS-RESPONSE-REFS>
<POS-RESPONSE-REF ID-REF="RESPONSE_ID"/>
</POS-RESPONSE-REFS>
<NEG-RESPONSE-REFS>
<NEG-RESPONSE-REF ID-REF="NEG_RESPONSE_ID"/>
</NEG-RESPONSE-REFS>
<POS-RESPONSE-SUPPRESSABLE>
<BIT-MASK>80</BIT-MASK> 
<VALUE-SNREF SHORT-NAME="REQ_PAR_SPR"/>
</POS-RESPONSE-SUPPRESSABLE>
</DIAG-SERVICE>
<REQUEST ID="REQ_NO_DEF_SPR_ID">
<SHORT-NAME>REQ_NO_DEF_SPR</SHORT-NAME>
<PARAMS>
<PARAM xsi:type="CODED-CONST">
<SHORT-NAME>REQ_PAR</SHORT-NAME>
<BYTE-POSITION>0</BYTE-POSITION>
<CODED-VALUE>40</CODED-VALUE>
<DIAG-CODED-TYPE BASE-DATA-TYPE="A_UINT32" xsi:type="STANDARD-LENGTH-TYPE">
</DIAG-CODED-TYPE>
</PARAM>
<PARAM xsi:type="VALUE">
<SHORT-NAME>REQ_PAR_SPR</SHORT-NAME>
<PHYSICAL-DEFAULT-VALUE>1</PHYSICAL-DEFAULT-VALUE> 
<DOP-SNREF SHORT-NAME="SIMPLE_DOP"/>
</PARAM>
</PARAMS>
</REQUEST>
<REQUEST ID="REQ_DEF_SPR_ID">
<SHORT-NAME>REQ_DEF_SPR</SHORT-NAME>
<PARAMS>
<PARAM xsi:type="CODED-CONST">
<SHORT-NAME>REQ_PAR</SHORT-NAME>
<BYTE-POSITION>0</BYTE-POSITION>
<CODED-VALUE>40</CODED-VALUE>
<DIAG-CODED-TYPE BASE-DATA-TYPE="A_UINT32" xsi:type="STANDARD-LENGTH-TYPE">
</DIAG-CODED-TYPE>
</PARAM>
<PARAM xsi:type="VALUE">
<SHORT-NAME>REQ_PAR_SPR</SHORT-NAME>
<PHYSICAL-DEFAULT-VALUE>129</PHYSICAL-DEFAULT-VALUE> 
<DOP-SNREF SHORT-NAME="SIMPLE_DOP"/>
</PARAM>
</PARAMS>
</REQUEST>
Mit POS-RESPONSE-SUPPRESSABLE sind beide Dienste DIAG_NO_DEF_SPR und

DIAG_DEF_SPR als „unterstützt grundsätzlich Suppress Positive Response (SPR)“ markiert.
Ob bei der Dienstausführung das Flag SUPPRESS_POS_RESP an der D-PDU-API gesetzt

wird oder nicht, hängt von der Voreinstellung für ein internes boolesches Flag des Dienstes,
im Folgenden mit SET_SPR bezeichnet, und etwaigen vorherigen Aufrufen der Methode
setSuppressPositiveResponse ab, über die dieses Flag manipuliert wird.
Ermitteln der Voreinstellung für SET_SPR
SET_SPR erhält initial den Wert true, wenn der in der ODX-Bedatung referenzierte Request-
Parameter einen internen Default-Wert - bedatet oder berechnet – hat, der sich durch OR-
Verknüpfung mit der ODX / POS-RESPONSE-SUPPRESSABLE / BIT-MASK nicht

verändert. In allen anderen Fällen lautet die Voreinstellung für SET_SPR false.
Für die Voreinstellung des Flags SET_SPR für den Dienst DIAG_NO_DEF_SPR wird der
Wert false ermittelt:
defVal 1 (dez) = 00000001 (bin) // interner Default-Wert
bmVal 80 (hex) = 10000000 (bin) // Bit-Maske
Verknüpfung 00000001
| 10000000
----------
10000001 (bin) // 0x81 != Default
Für die Voreinstellung des Flags SET_SPR für den Dienst DIAG_DEF_SPR wird der Wert
true ermittelt:
defVal 129 (dez) = 10000001 (bin) // interner Default-Wert
bmVal 80 (hex) = 10000000 (bin) // Bit-Maske
Verknüpfung 10000001
| 10000000
----------
10000001 (bin) // 0x81 == Default
11.4.28 Zugriff auf am Service überschriebene Kommunikationsparameter
Die MCD3-D Schnittstelle bietet diverse Klassen und Methoden für das Ermitteln und Setzen
von Kommunikationsparametern:
MCDDbProtocolParameterSet, Spezialisierung einer MCDDbControlPrimitive

• Abfragbar an einer MCDDbLocation.
• Enthält über die zugehörigen MCDDbRequestParameter die für diese
MCDDbLocation bedateten ComParams nebst Default-Werten.
• Die an einem ODX / LOGICAL-LINK (-> MCD(Db)LogicalLink) überschriebenen
COM-PARAMs sind hier nicht berücksichtigt, da es keine 1:1-Beziehung zwischen
MCDDbLocation und MCDDbLogicalLink gibt, pro MCDDbLocation aber nur ein
MCDDbProtocolParameterSet definiert sein kann.
MCDProtocolParameterSet, Spezialisierung einer MCDControlPrimitive

• Erstellbar an einem MCDLogicalLink.
• Enthält über die zugehörigen MCDRequestParameter initial die Werte des
MCDDbProtocolParameterSets, wobei am Logical Link überschriebene ComParams
die Werte der entsprechenden MCDRequestParameter gegenüber der Db-

Voreinstellung ändern können.
• Es kann mehrere MCDProtocolParameterSet-Instanzen an einem MCDLogicalLink
geben.
• Die Werte der MCDRequestParameter können geändert werden.
• Bei Ausführung eines MCDProtocolParameterSet über “executeSync” werden die
geänderten Werte an die D-PDU-API übermittelt und aktiviert, sofern möglich.
• Die für das VCI gerade gültigen Werte können über MCDProtocolParameter-
Set::fetchValuesFromInterface geholt und dann als Werte der
MCDRequestParameter erfragt werden.
Die an einem DIAG-SERVICE im ODX überschriebenen ComParams gelten nur für die
Ausführung des entsprechenden Dienstes. Sie werden mit der proprietären Methode
MCDDbService::getOverwrittenComParams_NSF, s.u., als MCDDbRequestParameter zur
Verfügung gestellt, deren Default-Werte dann die im ODX bedateten Werte darstellen. Diese
Werte können applikationsseitig nicht verändert werden.
Die Schnittstelle des MCD-Kernels, konkret die Klasse asam:: d::MCDDbService, wird um
folgende Methode erweitert:
/** Returns the collection of communication parameters (protocol parameters) that temporarily
* overwrite the values of the logical link specific communication parameters for execution
* of the corresponding runtime service, see ODX / DIAG-SERVICE / COMPARAM-REFs-
* The collection might be empty.
*/
virtual asam::d::MCDDbRequestParameters* getOverwrittenComParams_NSF()=0;
120 12. Systemanforderungen V14.0.0 / 31.10.2019
12 Systemanforderungen
12.1 Betriebssysteme
Der MCD-Kernel ist als 32-Bit Bibliothek sowohl auf Windows XP als auch Windows 7 32 /
64 Bit lauffähig.
Die 64-Bit Bibliothek des MCD-Kernels 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
l06 Debian 8 3.18.55 4.9.2 rpm4 i386, armhf, 32

„Jessie“ ppc
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
12.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
„Embedded“ Systeme:
• RAM (ohne ODX-Daten und Applikationen, inklusive JVM, PDU-API, Treiber und
Diagnoseprotokolle): < 64 MB
• Erforderliche Plattenkapazität bei Installation ohne Daten: < 64 MB
12.3 Daten- und applikationsgetriebene Restriktionen
12.3.1 Anzahl der Laufzeitdatenbanken
Die in VW-MCD vorgenommene Laufzeitdatenstrukturierung impliziert eine Beschränkung

der Fahrzeugprojekte auf eine gewisse Anzahl von Protokollen, Funktionalen Gruppen,
V14.0.0 / 31.10.2019 12. Systemanforderungen 121
Basisvarianten und Ecu-Varianten, Shared-Datas sowie VIT-, Flash-, ECU-Config- und

Function-Dictionary-Containern. Diese Daten werden in getrennten Laufzeitdatenbanken
gehalten, die jeweils aus einem Dateipaar besteht. Ein Datenzugriff zur Laufzeit erfordert das
Öffnen der entsprechenden Dateien, wobei aus Performanzgründen ein direktes Schließen
im Anschluss an das Laden der gerade benötigten Daten nicht sinnvoll ist. Durch das
Betriebssystem ist die maximale Anzahl der Datenströme auf 2048 beschränkt. Abzüglich
standardmäßig verwendeter Datenströme bedeutet dies, dass maximal 2044 Dateien, also
1022 Datenbanken gleichzeitig geöffnet werden können. Insbesondere bei Applikationen, die
die DB-Elemente eines Fahrzeugprojekts auslesen, kann die Grenze in der Praxis
tatsächlich erreicht werden.
Das Problem ist insofern entschärft worden, als man die Arbeitsweise des ODX-Converters
nun so konfigurieren kann, dass die Daten der Basisvarianten und zugehörigen ECU-
Varianten in einer Laufzeitdatenbank gehalten werden.
12.3.2 Volumen geladener DB-Objekte
Der für den MCD-Kernel-Prozess verfügbare Hauptspeicher ist in Abhängigkeit von der
Systemausstattung beschränkt. Wenn der Hauptspeicherbedarf diese Grenze im laufenden
Betrieb überschreitet, ist in der Regel ein weiterer ordnungsgemäßer Ablauf der Applikation
nicht mehr möglich. Kritisch sind vor allem solche Applikationen, die über die DB-
Schnittstelle des Kernels sehr große Teile der in den Laufzeitdatenbanken enthaltenen
Projektinformationen auslesen und die entsprechenden MCD-DB-Objekte halten. Man
beachte, dass die meisten MCD-DB-Objekte nicht explizit freigegeben werden können und
damit die Lebensdauer dieser Objekte grundsätzlich nur durch den Zeitraum beschränkt
wird, in dem das übergeordnete Projekt selektiert ist. Weitere Restriktionen und Freigaben
dieser Objekte beruhen nur auf Annahmen.
Bei Java-Applikationen wird die Lebensdauer der in der C++-Schicht des Kernels gehaltenen
Objekte an die Existenz entsprechender Java-Referenzen gekoppelt. Wenn einer Java-
Applikation ein sehr großer Speicherraum für die VM eingeräumt wird, kann es passieren,
dass der Java Garbage-Collector nicht aktiv wird, obwohl der weitaus größere
Speicherbedarf für C++ bereits an die Systemgrenzen stößt.
Java-Applikationen ohne eigene Objektverwaltung sollten daher ihrer VM nicht mehr als den
tatsächlich erforderlichen Speicher einräumen.
Der MCD-Kernel bietet Java-Applikationen die Möglichkeit, die maximale Anzahl der intern
gehaltenen MCD-DB-Objekte zu konfigurieren. Wird diese Zahl erreicht, so werden im
weiteren Verlauf die jeweils ältesten Objekte überschrieben, die bei Bedarf erneut geladen
werden müssen.
Ein allgemein gültiger optimaler Wert für die maximale Anzahl intern gehaltener MCD-DB-
Objekte kann nicht genannt werden, weil zum einen die Anzahl noch nichts über die Größe
der Objekte aussagt, zum anderen es noch keine Erfahrungswerte gibt, ab wann sich der
122 13. Lizenzierung V14.0.0 / 31.10.2019
erhöhte Hauptspeicherbedarf negativer auf die Laufzeit auswirkt als das wiederholte
Nachladen von Objekten.
12.3.3 Größe von Flashdateien
Die maximale Größe von Flashdateien ist durch die MCD-standardkonforme Verwendung
des Datentyps A_UINT32 für Segmentgrößen und Adressen auf 4 GB beschränkt.
12.4 C++ Entwicklungsumgebung
• Aktuell: Microsoft Visual Studio 7.1 (unterstützt bis Ende Q2, 2014)
• Umstieg auf Microsoft Visual Studio 2013 (Compiler VC12.0) bis Ende Q2, 2014
13 Lizenzierung
Die Lizenzierung des MCD-Kernels erfolgt über eine Applikationskopplung. Fällt die Prüfung
einer erfolgreichen Applikationskopplung negativ aus, kann die Applikation keine Instanz des
MCDSystem erstellen und somit den MCD-Kernel nicht verwenden.
13.1 Applikationskopplung
Über ein sogenanntes “Challenge and Response”-Verfahren wird eine Kopplung zwischen
einer Applikation und dem VW-MCD MCD-Kernel etabliert, die dafür sorgt, dass der MCD-
Kernel nur in Verbindung mit dieser Applikation betrieben werden kann.
Hierbei erfragt die Applikation eine Nachricht beim MCD-Kernel, berechnet aus der Nachricht
und einem geheimen Schlüssel über einen festgelegten Algorithmus einen Freischaltcode,
der an den MCD-Kernel zurückgeschickt wird.
Der MCD-Kernel berechnet nach demselben Algorithmus mit denselben Angaben seinerseits
einen Freischaltcode und vergleicht diesen mit dem von der Applikation gesetzten Wert. Nur
bei Gleichheit wird der MCD-Kernel zur weiteren Nutzung freigeschaltet.
Eine automatische Erkennung von freizuschaltenden Applikationen, ohne dass sich diese
aktiv über den beschriebenen Mechanismus registrieren, findet nicht statt.
V14.0.0 / 31.10.2019 13. Lizenzierung 123
Applikation
compute
Secret Key
sha-512
VW-MCD MCD-Kernel
sendMac_NSF
Security Access API
getSeedForMac_NSF
MCD-3D API
sha-512
compute
Secret
Key
Abbildung 1: Übersicht Applikationskopplung
13.1.1 Details
13.1.1.1 HMAC
HMAC ist ein keyed-hash message authentication code, eine Art Message Authentication
Code (MAC), der basierend auf einer kryptografischen Hash-Funktion berechnet wird. Eine
genauere Beschreibung kann unter http://de.wikipedia.org/wiki/Keyed-
Hash_Message_Authentication_Code gefunden werden. Für die Verschlüsselung wird hier
eine sha-512 Hash-Funktion verwendet.
13.1.1.2 Geheimnis
Die Applikation und der VW-MCD MCD-Kernel teilen sich ein Geheimnis, d.h. einen
geheimen Schlüssel, der auf beiden Seiten in die Berechnung des MAC einfließt, ohne
zwischen Applikation und MCD-Kernel direkt ausgetauscht zu werden. Eine Applikation, die
dieses Geheimnis nicht kennt, kann den MCD-Kernel nicht freischalten.
13.1.1.3 Freischaltung des VW-MCD MCD-Kernel

Zur Freischaltung des MCD-Kernels bietet die Schnittstellenklasse MCDSystem drei
zusätzliche statische Methoden an:
• getSeedForMac_NSF
• sendMac_NSF
• isAuthorized_NSF
124 13. Lizenzierung V14.0.0 / 31.10.2019
Diese Methoden müssen aufgerufen werden, bevor das MCDSystem-Objekt erstellt wird.
13.1.1.3.1 Schritt 1: Nachricht erfragen

Mit der Methode getSeedForMac_NSF kann ein Bytefield vom MCD-Kernel angefragt
werden. Dieses Bytefield besteht aus 64 Zeichen und wird bei jeder Anfrage erneut zufällig
generiert.
Aus dieser Nachricht und einem geheimen Schlüssel, siehe Kapitel 13.1.1.2, erzeugt die
Applikation einen über den sha-512-Algorithmus einen MAC, siehe Kapitel 13.1.1.1, der an
die SecurityAccess-Schnittstelle zurückgeschickt wird.
static MCDSystem::getSeedForMac_NSF(asam::A_ASCIISTRING appID) :

asam::A_BYTEFIELD
Returns a byte field to be used as seed by an MVCI server application.
The application has to create a key from this seed using a procedure and a certain secret
known to the MVCI server. The key will be returned to the MVCI server and can be checked
whenever it is necessary. See MCDSystem::sendMac_NSF.
Precondition:
The MCDSystem instance is not created.
Postcondition:
- the MCDSystem instance already exists
(MCDProgramViolationException, eRT_INTERNAL_ERROR)
- the key file cannot be found
(std::runtime_error with suitable error message)
- the input appID cannot be found in the key file
- the decryption of the key file entries failed
13.1.1.3.2 Schritt 2: MAC berechnen

Aus der Nachricht und dem geheimen Schlüssel berechnet die Applikation einen MAC mit
dem „sha-512“ Verschlüsselungsverfahren. Dieses Verfahren ist standardisiert und somit
unabhängig von der gewählten Implementierung.
Sowohl der MCD-Kernel als auch die Applikation müssen diesen Schritt durchführen, damit
der MCD-Kernel prüfen kann, ob die Applikation einen gültigen Freischaltcode berechnet hat.
V14.0.0 / 31.10.2019 14. Installation für Windows 125
13.1.1.3.3 Schritt 3: MAC senden

Die Applikation schickt den im vorigen Schritt berechneten MAC an den MCD-Kernel und
erwirkt damit die Freischaltung, sofern der MAC akzeptiert wird. Wird ein ungültiger MAC
geschickt, so wird der MCD-Kernel gesperrt. Für einen neuen Versuch muss der Prozess
neu gestartet werden.
static MCDSystem::sendMac_NSF (asam::A_BYTEFIELD)
Sends a byte field to be interpreted as MAC for unlocking the MVCI server. An application
should have created the MAC from a seed requested from the MVCI server using
MCDSystem::getSeedForMac_NSF(). The MAC creation procedure and a certain secret has
to be known to both, the MVCI server and the application.
Precondition:
The MCDSystem instance is not created.
Postcondition:
- the MCDSystem instance already exists
(MCDProgramViolationException, eRT_INTERNAL_ERROR)
13.1.1.3.4 Schritt 4: Freischaltung überprüfen

static MCDSystem::isAuthorized_NSF(): asam::A_BOOLEAN
Returns true if the current application is authorized for MVCI server usage, otherwise false.
Eine Applikation sollte die Methode nutzen, um sich vor der Instanziierung des MCD-Kernels
über den Status zu informieren; der MCD-Kernel muss dies tun.
13.1.2 Randbedingungen
Für jede VW-MCD MCD-Kernel Applikation wird ein spezieller geheimer Schlüssel
verwendet, der mit der Applikations-ID verbunden ist.
Der Austausch des geheimen Schlüssels erfolgt nicht programmatisch.
Die Applikation muss in Abhängigkeit der Programmiersprache über eine gültige

Implementierung des sha-512-Algorithmus verfügen.
14 Installation für Windows
Der MCD-Kernel wird durch Aufruf des Setups

126 14. Installation für Windows V14.0.0 / 31.10.2019
SetupVWMCD_32_Kernel_V<version>.exe
als 32 Bit Applikation oder durch Aufruf des Setups
SetupVWMCD_64_Kernel_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.
Grundsätzlich wird davon abgeraten, ein Setup des MCD-Kernels über bestehende
Installationen, d.h. in dasselbe Verzeichnis zu installieren, ohne die bestehende Version
deinstalliert zu haben.
Wird dennoch eine solche Aktualisierung vorgenommen, so wird der Anwender im GUI-
Modus gefragt, wie mit bestehenden Konfigurationsdateien umgegangen werden soll. Bei
jeder Konfigurationsdatei hat der die Möglichkeit zu entscheiden, ob die Datei überschrieben
oder beibehalten werden soll.
Alle anderen Dateien werden ohne Nachfrage überschrieben, um inkonsistente Installationen

zu verhindern.
Zur Integration in übergeordnete Setups ist für das Einzelsetup auch ein sogenannter
„silent“-Modus wählbar:
SetupVWMCD_Kernel_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
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.
Die zu verwendende Sprache für das Setup kann durch Angabe des Parameters
/lang=english
auf Englisch oder durch
/lang=german
auf Deutsch gesetzt werden. Wenn die Sprache als Parameter angegeben wird entfällt im
Setup die Auswahl der zu verwendenden Sprache.
Eine Vorgabe der Startmenügruppe kann über den Parameter
/group=<Gruppenname>
übergeben werden. Wenn ein Gruppenname übergeben wird, entfällt im Setup die Auswahl
des zu verwendenden Gruppennamens.
Ein Rückgabewert ungleich 0 bezeichnet einen Fehler bei der Installation.
Mögliche Fehlerwerte sind zurzeit 1 bis 8, die auf Fehler in den unterschiedlichen Phasen
der Installation hinweisen.
(1) Die Setup-Initialisierung ist fehlgeschlagen.
(2) Der Anwender hat die Installation im GUI-Modus durch „Abbrechen“ oder „Nein“
abgebrochen, bevor die eigentliche Installation der Software gestartet ist.
128 14. Installation für Windows V14.0.0 / 31.10.2019
(3) Fataler Fehler im Installationsprozess bei der Vorbereitung der nächsten

Installationsphase, z.B. wenn zu wenig Speicher oder sonstige Windows-Ressourcen
zur Verfügung stehen.
(4) Fataler Fehler während des tatsächlichen Installationsprozesses.
(5) Der Anwender hat die Installation im GUI-Modus während der tatsächlichen
Installation durch „Abbrechen“ oder „Abbrechen und Wiederholen“ abgebrochen.
(6) --- (Kann nur bei der Setup-Entwicklung auftreten.)
(7) Fehler bei der Vorbereitung der tatsächlichen Installation.
(8) Fehler bei der Vorbereitung der tatsächlichen Installation, kann nur durch System-
Neustart behoben werden.
Die Deinstallation der MCD-Kernel Software erfolgt durch Aufruf des entsprechenden
Uninstallers aus dem Startmenü heraus:
Uninstall VW-MCD Kernel <version> Installation
Alternativ kann das Programm Uninstall VW-MCD Kernel <version> Installation.exe auch
direkt aufgerufen werden. Es befindet sich neben dem Installationsverzeichnis.
Eine Verwendung im „silent“-Modus ist ebenso möglich:
Uninstall VW-MCD Kernel <version> Installation.exe /verysilent /suppressmsgboxes
Ein Rückgabewert ungleich 0 bezeichnet einen Fehler bei der Deinstallation.
14.1 Windows 7 Unterstützung
Die Konfigurationsdateien (MCD3D_SERVER.INI, MCD3D_PROJECTS.INI, TESTERID.INI)

werden bei einer Installation unter Windows 7 standardmäßig nicht mehr in das MCD-Kernel
Verzeichnis der Installation gelegt, da auf diesem in der Regel keine Schreibrechte für
Benutzer ohne Administratorrechte existieren.
Als Voreinstellung wird entsprechend den Windows Richtlinien das benutzerübergreifende

Verzeichnis
<Laufwerk>:\Users\Public\Volkswagen\VW-MCD\config
gewählt.
In älteren Versionen hat das Laufzeitsystem, der MCD-Kernel, seine Konfigurationen bislang
über die Umgebungsvariable VW_MCD_HOME gefunden, die bei Ausführung des VW-MCD-
Setup auf das MCD-Kernel-Verzeichnis der Installation gesetzt wurde.
Darüber hinaus wurde eine Java-System-Property VW_MCD_HOME interpretiert, die von

einer Java-Applikation gesetzt werden konnte, um dem Java-Layer des DLS mitzuteilen, wo
die zum MCD-Kernel gehörenden DLLs zu finden sind. Der Java-Layer des Laufzeitsystems
muss diese DLLs selbständig laden. Das Setzen dieser Property erlaubt einer Applikation,
zwischen verschiedenen MCD-Kernel-Installationen umzuschalten.
In der aktuellen Version wird bei einer Installation unter Windows 7 neben der
Umgebungsvariablen VW_MCD_HOME zusätzlich die Umgebungsvariable
VW_MCD_CONFIG berücksichtigt. Letztere bezeichnet das Verzeichnis der
Konfigurationsdateien und wird bei Ausführen des VW.MCD-Setup auf das bereits erwähnte
Verzeichnis
<Laufwerk>:\Users\Public\Volkswagen\VW-MCD\config
gesetzt.
Die Java-System-Property VW_MCD_HOME wird weiterhin im Java-Layer des MCD-Kernels

interpretiert. Zusätzlich wird eine weitere Java-System-Property VW_MCD_CONFIG im
Java-Layer des MCD-Kernels interpretiert, die dieselbe Bedeutung hat wie die gleichnamige
Umgebungsvariable, diese aber gegebenenfalls überschreibt. Eine Java-Applikation hat
somit die Möglichkeit, bei mehreren DLS-Installationen zwischen den jeweiligen
Konfigurationsdaten umzuschalten.
Die Konfigurationsdatei MCD3D_PROJECTS.INI enthält den Pfad auf das

Projektwurzelverzeichnis, standardmäßig lautet der Pfad "./../Projects", wobei sich diese
relative Angabe bislang auf VW_MCD_HOME, also das MCD-Kernel-Verzeichnis der
Installation bezogen hat. Nach Ausführen des VW-MCD-Setup wurde in älteren Versionen
das passende leere Verzeichnis "Projects" parallel zu MCD-Kernel angelegt.
Bei einer Installation unter Windows 7 bezieht sich der relative Pfad des
Projektwurzelverzeichnisses auf VW_MCD_CONFIG, und das Setup erzeugt ein leeres
Verzeichnis
<Laufwerk>:\ Users\Public\Volkswagen\VW-MCD\config
Für eine Installation unter Windows XP wird das alte Verhalten beibehalten.
Zur Verwendung des MCD-Kernels in einer Java-Applikation unter Windows 7 müssen

unterschiedliche Einstellungen vorgenommen werden, abhängig davon, ob die Applikation
die oben genannten Java-System-Properties setzt oder nicht.
a) Die Applikation setzt beide Java-System-Properties.
Die Java-System-Property VW_MCD_HOME muss auf das Verzeichnis zeigen, in dem

die MCD-Kernel-DLLs liegen. Darüber kann der MCD-Kernel geladen werden.
Die Java-System-Property VW_MCD_CONFIG muss auf das Verzeichnis zeigen, in dem

die Konfigurationsdateien liegen. Darüber findet der geladene MCD-Kernel seine
Einstellungen.
Die bei der Installation gesetzten Umgebungsvariablen VW_MCD_HOME und

VW_MCD_CONFIG werden nicht mehr betrachtet.
130 15. Hinweis auf Fremdkomponenten V14.0.0 / 31.10.2019
(Ausnahme: Das Ermitteln der Tester-ID als Wert für einen entsprechenden
Systemparameter erfolgt zurzeit noch unter Auswertung der Umgebungsvariablen
VW_MCD_CONFIG zum Auffinden der Konfigurationsdatei TESTERID.INI. Eine
Anpassung folgt in Kürze.)
b) Die Applikation setzt keine Java-System-Properties.
Die DLLs des MCD-Kernels werden zunächst mit der allgemeinen Java-System-Property
„user.dir“ gesucht. Sind sie nicht in diesem Verzeichnis abgelegt – bei gängigen
Installationen der Normalfall -, werden sie über gängige Windows-Mechanismen zum
Laden von Bibliotheken geladen. Dies bedeutet, dass der Suchpfad (%PATH%) um das
Verzeichnis der MCD-Kernel-DLLs erweitert werden muss.
Ist der MCD-Kernel erfolgreich geladen, werden die Konfigurationsdateien unter

Auswertung der Umgebungsvariablen VW_MCD_CONFIG gesucht. Ist diese
Umgebungsvariable nicht gesetzt, erfolgt die Suche unter VW_MCD_HOME, sofern
gesetzt, sonst im aktuellen Arbeitsverzeichnis.
c) Die Applikation setzt nur die Java-System-Property VW_MCD_HOME.
Die Java-System-Property VW_MCD_HOME muss auf das Verzeichnis zeigen, in dem

die MCD-Kernel-DLLs liegen. Darüber kann der MCD-Kernel geladen werden.
Ist der MCD-Kernel erfolgreich geladen, werden die Konfigurationsdateien im selben

Verzeichnis gesucht, in dem die MCD-Kernel-DLLs liegen. Bei einer Installation über das
VW-MCD-Setup werden sie dort jedoch nicht abgelegt, siehe oben. Daher wird von
dieser Einstellung abgeraten. Eine Applikation, die diese Einstellung explizit wählt, muss
sicherstellen, dass die Installation von VW-MCD geeignet erfolgt ist.
d) Die Applikation setzt nur die Java-System-Property VW_MCD_CONFIG.
Die DLLs des MCD-Kernels werden zunächst mit der allgemeinen Java-System-Property
„user.dir“ gesucht. Sind sie nicht in diesem Verzeichnis abgelegt – bei gängigen
Installationen der Normalfall -, werden sie über gängige Windows-Mechanismen zum
Laden von Bibliotheken geladen. Dies bedeutet, dass der Suchpfad (%PATH%) um das
Verzeichnis der MCD-Kernel-DLLs erweitert werden muss.
Die Java-System-Property VW_MCD_CONFIG muss auf das Verzeichnis zeigen, in dem

die Konfigurationsdateien liegen. Darüber findet der erfolgreich geladene MCD-Kernel
seine Einstellungen.
Es wird empfohlen, wie unter a) beschrieben beide Java-System-Properties in der

Applikation zu setzen.
15 Hinweis auf Fremdkomponenten
Der MCD-Kernel und VWMCD Client nutzen folgende OSS-Komponenten:

V14.0.0 / 31.10.2019 16. Sonstige Hinweise 131
• 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
• WndResizer; 20. Oct 2014
Der MCD-Kernel nutzt folgende Fremd-Komponente:
• ZipArchive; V 4.1.2
16 Sonstige Hinweise
Man beachte, dass die VWMCD COM-API technologiebedingt nicht in der Lage ist, einen
Wert MAX_UINT32 bei einem MCD-Datentyp A_UINT32 zu liefern, da der MCD-Typ gemäß
Standard auf den COM Typ LONG abgebildet wird – mit entsprechendem Datenverlust bei
Werten größer MAX_INT32.
Analoge Restriktionen bestehen in allen Fällen, bei denen „unsigned“ Datentypen auf
„signed“ COM-Datentypen abgebildet werden müssen, siehe Table 2 in
ASAM_AE_MCD-3D_BS_3_4_COM-IDL-Technology-Reference-Mapping-Rules_V3-0-0.pdf.

VW-MCD MCDKernel

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

VW-MCD MCDKernel

Hochgeladen von

Copyright:

Verfügbare Formate

V 14.0.0 - Stand: 31.10.

Implementierung des Standards ASAM MCD-3D 3.0.0

Installation, Konfiguration, Betrieb

Druckdatum: 31.10.19 File: VW-MCD_MCDKernel.doc

1 Übersicht VW-MCD ....................................................................................... 7

2 Übersicht MCD-Kernel ................................................................................ 10

3.1 MCD3D_SERVER.INI ............................................................................................. 11

3.2 MCD3D_PROJECTS.INI ........................................................................................ 17

3.4 TESTERID.INI ........................................................................................................ 19

4.1 Problemstellung ...................................................................................................... 20

4.2 Möglichkeit zur Konfiguration des MCD-Kernels bezüglich Job-Ausführung .......... 20

4.2.1 Inhalt der Konfigurationsdateien .................................................................... 20

5.1 Late-bound-Mechanismus ...................................................................................... 26

5.2 Umsetzung im MCD-Kernel .................................................................................... 27

5.2.1 Gundsätzlicher Algorithmus zum Auffinden von Flashdaten ....................... 27

5.2.2 Spezialitäten hinsichtlich Latebound-Dateien................................................ 29

5.3 Flashdatenablage ................................................................................................... 32

5.3.1 Das Flashdatenunterverzeichnis..................................................................... 32

5.3.2 Ablagemöglichkeiten ....................................................................................... 32

5.5 Alternatives Flashprojektverzeichnis ....................................................................... 33

7 Logging und Tracing .................................................................................. 36

8.1 Standardisierte Fehlertexte ..................................................................................... 39

8.2 Herstellerspezifische Fehlertexte ............................................................................ 42

9.1 Default-VIT ............................................................................................................. 56

9.1.1 Motivation ......................................................................................................... 56

9.1.2 Voraussetzungen ............................................................................................. 56

9.1.3 Vorgehensweise ............................................................................................... 61

9.2 Smart-VIT ............................................................................................................... 61

9.2.1 Motivation ......................................................................................................... 61

9.2.2 Voraussetzungen ............................................................................................. 62

9.2.3 Vorgehensweise ............................................................................................... 62

10.1 C++ ........................................................................................................................ 64

10.2 Java ........................................................................................................................ 64

10.3 DCOM .................................................................................................................... 64

11 Abweichungen von ASAM MCD-3D 3.0.0 .................................................. 65

11.1 Nicht vollständig standardkonform implementierbare Funktionalitäten .................... 65

11.2 Bewusst abweichend vom Standard implementierte Funktionalitäten ..................... 66

11.3 Nicht oder nicht vollständig implementierte Funktionalitäten ................................... 70

11.3.1 Überschreiben komplexer Kommunikationsparameter ................................. 70

11.3.2 Festlegung des PROT-STACKs ....................................................................... 71

11.3.3 Nutzung der C++ Schnittstelle ........................................................................ 71

11.4 Proprietäre Erweiterungen ...................................................................................... 73

11.4.1 Iteration über Flashdaten................................................................................. 73

11.4.2 Late-bound-Flashdaten .................................................................................... 74

11.4.3 Zugriff auf Flash-Securities ............................................................................. 75

11.4.4 Zugriff auf Flash-Job........................................................................................ 75

11.4.5 Erzeugen eines MCDValue-Elements ............................................................. 76

11.4.6 Zugriff auf Semantic-Attribute an SubComponents ...................................... 77

11.4.7 PDU-Timestamps ............................................................................................. 77

11.4.8 Abfrage des Text-Table-Elements am MCDParameter .................................. 78

11.4.9 Abfrage des Compu-Default-Value ................................................................. 78

11.4.10 Laden und Löschen von Teilprojekten im laufenden Betrieb ....................... 79

11.4.11 System-Properties ........................................................................................... 83

11.4.12 Abfrage installierter PDU-APIs ........................................................................ 85

11.4.13 Verhalten der addMuxBranch(...)-Methoden................................................... 86

11.4.14 „Suppress Positive Response“ für ODX 2.0.1 basierte Datenprojekte......... 86

11.4.15 MCDInterface::getModuleTypeName_NSF ..................................................... 87

11.4.16 MCDDbODXFile, MCDDbODXFiles .................................................................. 87

11.4.17 Unterstützung komplexer Kommunikationsparameter ................................. 88

11.4.18 MCDParameter::getUnitTextID_NSF ............................................................... 90

11.4.19 MCDDiagComPrimitive::cancel ....................................................................... 90

11.4.20 Simulationsmodus ........................................................................................... 90

11.4.21 Laden von MCD-Kernel DLLs .......................................................................... 95