PROTOKOLLE ZUM HERUNTERLADEN DER DATEN

INHALTSVERZEICHNIS

1. EINLEITUNG 1.1. Geltungsbereich 1.2. Akronyme und Notationen 2. HERUNTERLADEN VON DATEN VON DER FAHRZEUGEINHEIT 2.1. Download-Verfahren 2.2. Datendownload-Protokoll 2.2.1 Nachrichtenstruktur 2.2.2 Nachrichtentypen 2.2.2.1 Start Communication Request (SID 81) 2.2.2.2 Positive Response Start Communication (SID C1) 2.2.2.3 Start Diagnostic Session Request (SID 10) 2.2.2.4 Positive Response Start Diagnostic (SID 50) 2.2.2.5 Link Control Service (SID 87) 2.2.2.6 Link Control Positive Response (SID C7) 2.2.2.7 Request Upload (SID 35) 2.2.2.8 Positive Response Request Upload (SID 75) 2.2.2.9 Transfer Data Request (SID 36) 2.2.2.10 Positive Response Transfer Data (SID 76) 2.2.2.11 Request Transfer Exit (SID 37) 2.2.2.12 Positive Response Request Transfer Exit (SID 77) 2.2.2.13 Stop Communication Request (SID 82) 2.2.2.14 Positive Response Stop Communication (SID C2) 2.2.2.15 Acknowledge Sub Message (SID 83) 2.2.2.16 Negative Response (SID 7F) 2.2.3 Nachrichtenfluss 2.2.4 Timing 2.2.5 Fehlerbehandlung 2.2.5.1 Start Communication-Phase 2.2.5.2 Communication-Phase 2.2.6 Inhalt der Antwortnachricht 2.2.6.1 Positive Response Transfer Data Download Interface Version (Positive Antwort Datenübertragung, Version der Download-Schnittstelle) 2.2.6.2 Positive Response Transfer Data Overview (Positive Antwort Datenübertragung, Überblick) 2.2.6.3 Positive Response Transfer Data Activities (Positive Antwort Datenübertragung, Tätigkeiten) 2.2.6.4 Positive Response Transfer Data Events and Faults (Positive Antwort Datenübertragung, Ereignisse und Störungen) 2.2.6.5 Positive Response Transfer Data Detailed Speed (Positive Antwort Datenübertragung, genaue Geschwindigkeitsangaben) 2.2.6.6 Positive Response Transfer Data Technical Data (Positive Antwort Datenübertragung, Technische Daten) 2.3. ESM-Datenspeicherung 3. PROTOKOLL FÜR DAS HERUNTERLADEN VON DATEN VON FAHRTENSCHREIBERKARTEN 3.1. Geltungsbereich 3.2. Begriffsbestimmungen 3.3. Herunterladen von der Karte 3.3.1 Initialisierungssequenz 3.3.2 Sequenz für unsignierte Dateien 3.3.3 Sequenz für signierte Dateien 3.3.4 Sequenz für das Zurücksetzen des Kalibrierungszählers 3.4. Datenspeicherungsformat 3.4.1 Einleitung 3.4.2 Dateiformat 4. HERUNTERLADEN VON DER FAHRTENSCHREIBERKARTE ÜBER EINE FAHRZEUGEINHEIT

1.

EINLEITUNG

Diese Anlage enthält die Spezifizierung der Verfahren für die verschiedenen Arten der Übertragung der Daten von der Karte auf ein externes Speichermedium (ESM) sowie die Protokolle, die zur Sicherung der korrekten Datenübertragung und der vollständigen Kompatibilität des heruntergeladenen Datenformats zu implementieren sind, damit ein Kontrolleur diese Daten inspizieren und vor ihrer Analyse ihre Echtheit und Integrität kontrollieren kann.

1.1.

Geltungsbereich

Das Herunterladen von Daten auf ein ESM kann erfolgen:

—

von einer Fahrzeugeinheit (Vehicle Unit, VU) durch ein an die VU angeschlossenes Intelligent Dedicated Equipment (IDE),

—

von einer Fahrtenschreiberkarte durch ein mit einem Kartenschnittstellengerät (IFD) ausgestattetes IDE,

—

von einer Fahrtenschreiberkarte über eine Fahrzeugeinheit durch ein an die VU angeschlossenes IDE.

Um eine Prüfung der Echtheit und Integrität der auf einem ESM gespeicherten heruntergeladenen Daten zu ermöglichen, werden die Daten mit einer gemäß Anlage 11 (Gemeinsame Sicherheitsmechanismen) angefügten Signatur heruntergeladen. Ebenfalls heruntergeladen werden die Kennung des Ursprungsgeräts (VU oder Karte) und dessen Sicherheitszertifikate (Mitgliedstaatszertifikat und Gerätezertifikat). Der Prüfer der Daten muss einen zuverlässigen europäischen öffentlichen Schlüssel besitzen. Daten, die von einer VU heruntergeladen werden, werden gemäß Anlage 11 (Gemeinsame Sicherheitsmechanismen Teil B, Fahrtenschreibersystem der 2. Generation) unterzeichnet, außer wenn Fahrer von einer Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation kontrolliert werden; in diesem Fall werden die Daten im Einklang mit Anlage 15 (Migration) Randnummer MIG_015 gemäß Anlage 11 (Gemeinsame Sicherheitsmechanismen Teil A, Fahrtenschreibersystem der 1. Generation) unterzeichnet. In dieser Anlage werden daher zwei Arten des Datendownloads von VU spezifiziert:

—

VU-Datendownload der 2. Generation mit Datenstruktur der 2. Generation und Unterzeichnung gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil B,

—

VU-Datendownload der 1. Generation mit Datenstruktur der 1. Generation und Unterzeichnung gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil A.

Ebenso gibt es, wie in den Abschnitten 3 und 4 dieser Anlage ausgeführt, zwei Arten von Datendownloads von in VU eingesetzten Fahrerkarten der 2. Generation.

1.2.

Akronyme und Notationen

In dieser Anlage werden folgende Akronyme verwendet:

AID

Application Identifier (Anwendungskennung)

ATR

Answer To Reset (Antwort auf Zurücksetzen)

CS

Checksum Byte (Prüfsummenbyte)

DF

Dedicated File (Verzeichnis)

DS_

Diagnostic Session (Diagnosevorgang)

EF

Elementary File (Elementardatei)

ESM

External Storage Medium (externes Speichermedium)

FID

File Identifier (File ID, Dateikennung)

FMT

Formatbyte (erstes Byte eines Nachrichtenkopfes)

ICC

Integrated Circuit Card (Chipkarte)

IDE

Intelligent Dedicated Equipment: Gerät, das zum Herunterladen von Daten auf das ESM verwendet wird (z. B. Personalcomputer)

IFD

Interface Device (Schnittstellengerät, Kartenterminal)

KWP

Keyword Protocol 2000

LEN

Length Byte (Längenbyte, letztes Byte eines Nachrichtenkopfes)

PPS

Protocol Parameter Selection (Auswahl der Protokollparameter)

PSO

Perform Security Operation (Sicherheitsoperation ausführen)

SID

Service Identifier (Dienstkennung)

SRC

Source Byte (Quellbyte)

TGT

Target Byte (Zielbyte)

TLV

Tag Length Value (Taglängenwert)

TREP

Transfer Response Parameter (Antwortübertragungsparameter)

TRTP

Transfer Request Parameter (Anfrageübertragungsparameter)

VU

Fahrzeugeinheit (Vehicle Unit)

2.

HERUNTERLADEN VON DATEN VON DER FAHRZEUGEINHEIT

2.1.

Download-Verfahren

Zur Durchführung eines VU-Datendownloads muss der Bediener folgende Arbeitsschritte ausführen:

—

Einführen seiner Kontrollgerätkarte in einen Steckplatz der VU^(*);

—

Anschließen des IDE an den VU-Anschluss zum Herunterladen;

—

Herstellen der Verbindung zwischen IDE und VU;

—

Auswählen der herunterzuladenden Daten auf dem IDE und Senden der Anforderung an die VU;

—

Beenden des Download-Vorgangs.

2.2.

Datendownload-Protokoll

Das Protokoll ist auf Master/Slave-Basis aufgebaut, wobei das IDE den Master und die VU den Slave bildet. Nachrichtenstruktur, -typ und -fluss beruhen prinzipiell auf dem Keyword Protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Diagnostic systems — Keyword protocol 2000 — Part2: Data link layer). (Straßenfahrzeuge — Diagnosesysteme — Schlüsselwort 2000 — Teil 2: Sicherungsschicht). Die Anwendungsschicht beruht grundsätzlich auf dem aktuellen Normentwurf ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic services (Straßenfahrzeuge — Diagnosesysteme — Teil 1: Diagnosedienste), Version 6 vom 22. Februar 2001).

2.2.1

Nachrichtenstruktur

DDP_002

Alle zwischen dem IDE und der VU ausgetauschten Nachrichten sind mit einer dreiteiligen Struktur formatiert, die sich zusammensetzt aus

—

dem Kopf, bestehend aus einem Formatbyte (FMT), einem Zielbyte (TGT), einem Quellbyte (SRC) und möglicherweise einem Längenbyte (LEN),

—

dem Datenfeld, bestehend aus einem Service-Identifier-Byte (SID) und einer variablen Anzahl von Datenbytes, z. B. ein optionales Diagnostic-Session-Byte (DS_) oder ein optionales Transfer-Parameter-Byte (TRTP oder TREP),

—

der Prüfsumme, bestehend aus einem Prüfsummenbyte (CS).

Kopf				Datenfeld					Prüfsumme
FMT	TGT	SRC	LEN	SID	DATA	…	…	…	CS
4 Bytes				Max. 255 Bytes					1 Byte

TGT- und SRC-Byte stellen die physische Adresse des Empfängers und des Absenders der Nachricht dar. Die Werte sind F0 Hex für das IDE und EE Hex für die VU.

Das LEN-Byte ist die Länge des Datenfeldteils.

Das Prüfsummenbyte ist die 8-Bit-Summenreihe modulo 256 aller Bytes der Nachricht außer CS selbst.

Die Bytes FMT, SID, DS_, TRTP und TREP werden an anderer Stelle dieses Dokuments definiert.

DDP_003

Sind die von der Nachricht aufzunehmenden Daten länger als der im Datenfeldteil zur Verfügung stehende Platz, wird die Nachricht in mehreren Teilnachrichten gesendet. Jede Teilnachricht hat einen Kopf, die gleiche SID, TREP sowie einen 2-Byte-Teilnachrichtenzähler, der die Teilnachrichtnummer innerhalb der Gesamtnachricht angibt. Damit Fehlerprüfung und Abbruch möglich sind, bestätigt das IDE jede Teilnachricht. Das IDE kann die Teilnachricht annehmen, ihre erneute Übertragung anfordern sowie die VU zum Neubeginn oder zum Abbruch der Übertragung auffordern.

DDP_004

Enthält die letzte Teilnachricht genau 255 Bytes im Datenfeld, muss eine abschließende Teilnachricht mit leerem Datenfeld (außer SID, TREP und Teilnachrichtenzähler) angefügt werden, die das Ende der Nachricht anzeigt.

Beispiel:

Kopf	SID	TREP	Nachricht	CS
4 Bytes	Länger als 255 Bytes

wird übertragen als:

Kopf	SID	TREP	00	01	Teilnachricht 1	CS
4 Bytes	255 Bytes

Kopf	SID	TREP	00	02	Teilnachricht 2	CS
4 Bytes	255 Bytes

…

Kopf	SID	TREP	xx	yy	Teilnachricht n	CS
4 Bytes	Weniger als 255 Bytes

oder als:

Kopf	SID	TREP	00	01	Teilnachricht 1	CS
4 Bytes	255 Bytes

Kopf	SID	TREP	00	02	Teilnachricht 2	CS
4 Bytes	255 Bytes

…

Kopf	SID	TREP	xx	yy	Teilnachricht n	CS
4 Bytes	255 Bytes

Kopf	SID	TREP	xx	yy + 1	CS
4 Bytes	4 Bytes

2.2.2

Nachrichtentypen

Das Kommunikationsprotokoll für das Herunterladen von Daten zwischen der VU und dem IDE verlangt den Austausch von 8 verschiedenen Nachrichtentypen. In der folgenden Tabelle sind diese Nachrichten zusammengefasst.

Nachrichtenstruktur		Max. 4 Bytes				Max. 255 Bytes			1 Byte
		Kopf				Daten			Prüfsumme
IDE ->	<-VU	FMT	TGT	SRC	LEN	SID	DS_ / TRTP	DATA	CS
Anforderung Beginn Kommunikation		81	EE	F0		81			E0
Positive Antwort Beginn Kommunikation		80	F0	EE	03	C1		EA, 8F	9B
Anforderung Beginn Diagnosevorgang		80	EE	F0	02	10	81		F1
Positive Antwort Beginn Diagnose		80	F0	EE	02	50	81		31
Verbindungssteuerungsdienst
Baud-Rate überprüfen (Stufe 1)
9600 Baud		80	EE	F0	04	87	01	01,01	EC
19200 Baud		80	EE	F0	04	87	01	01,02	ED
38400 Baud		80	EE	F0	04	87	01	01,03	EE
57600 Baud		80	EE	F0	04	87	01	01,04	EF
115200 Baud		80	EE	F0	04	87	01	01,05	F0
Positive Antwort Baud-Rate überprüfen		80	F0	EE	02	C7	01		28
Übergang Baud-Rate (Stufe 2)		80	EE	F0	03	87	02	03	ED
Anforderung Upload		80	EE	F0	0A	35		00,00,00,00,00,FF,FF, FF,FF	99
Positive Antwort Anforderung Upload		80	F0	EE	03	75		00,FF	D5
Anforderung Datenübertragung
Download-Schnittstellenversion		80	EE	F0	02	36	00		96
Überblick		80	EE	F0	02	36	01, 21 oder 31		CS
Tätigkeiten		80	EE	F0	06	36	02, 22 oder 32	Datum	CS
Ereignisse & Störungen		80	EE	F0	02	36	03, 23 oder 33	Datum	CS
Genaue Geschwindigkeitsangaben		80	EE	F0	02	36	04 oder 24	Datum	CS
Technische Daten		80	EE	F0	02	36	05, 25 oder 35	Datum	CS
Download von der Karte		80	EE	F0	02 oder 03	36	06	Steckplatz	CS
Positive Antwort Datenübertragung		80	F0	EE	Len	76	TREP	Daten	CS
Anforderung Übertragung beenden		80	EE	F0	01	37			96
Positive Antwort Anforderung Übertragung beenden		80	F0	EE	01	77			D6
Anforderung Kommunikation beenden		80	EE	F0	01	82			E1
Positive Antwort Kommunikation beenden		80	F0	EE	01	C2			21
Teilnachricht bestätigen		80	EE	F0	Len	83		Daten	CS
Negative Antworten
Aktion nicht möglich		80	F0	EE	03	7F	Sid Req	10	CS
Dienst wird nicht unterstützt		80	F0	EE	03	7F	Sid Req	11	CS
Untervariable wird nicht unterstützt		80	F0	EE	03	7F	Sid Req	12	CS
Länge der Nachricht nicht korrekt		80	F0	EE	03	7F	Sid Req	13	CS
Bedingungen nicht korrekt oder Sequenzfehler in der Anforderung		80	F0	EE	03	7F	Sid Req	22	CS
Anforderung außerhalb des Bereichs		80	F0	EE	03	7F	Sid Req	31	CS
Upload nicht akzeptiert		80	F0	EE	03	7F	Sid Req	50	CS
Aktion nicht abgeschlossen		80	F0	EE	03	7F	Sid Req	78	CS
Daten nicht verfügbar		80	F0	EE	03	7F	Sid Req	FA	CS

Hinweise:

—

Sid Req = Sid der entsprechenden Anforderung.

—

TREP = der TRTP der entsprechenden Anforderung.

—

Geschwärzte Felder zeigen an, dass nichts übertragen wird.

—

Der Ausdruck „Upload” (von der IDE aus gesehen) wird in Anlehnung an die ISO 14229 verwendet. Er bedeutet dasselbe wie „Download” (von der VU aus gesehen).

—

Mögliche 2-Byte-Teilnachrichtenzähler sind in dieser Tabelle nicht aufgeführt.

—

„Steckplatz” bezeichnet die Steckplatznummer, entweder „1” (Karte im Steckplatz Fahrer) oder „2” (Karte im Steckplatz Beifahrer).

—

Falls der Steckplatz nicht angegeben ist, muss die VU Steckplatz 1 auswählen, wenn in diesen Steckplatz eine Karte eingesteckt wird, und Steckplatz 2 nur dann, wenn dies vom Benutzer ausdrücklich ausgewählt wird.

—

TRTP 24 wird für VU-Datendownload-Anforderungen der 2. Generation, Version 1 und Version 2, verwendet.

—

TRTP 00, 31, 32, 33 und 35 werden für VU-Datendownload-Anforderungen der 2. Generation, Version 2, verwendet.

—

TRTP 21, 22, 23 und 25 werden für VU-Datendownload-Anforderungen der 2. Generation, Version 1, verwendet.

—

TRTP 01 bis 05 werden für VU-Datendownload-Anforderungen der 1. Generation verwendet. Sie können optional von VU der 2. Generation akzeptiert werden, jedoch nur, wenn Fahrer von einer Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation kontrolliert werden.

—

TRTP 11 bis 1F sind für herstellerspezifische Download-Anforderungen reserviert.

2.2.2.1

Start Communication Request (SID 81)

DDP_005

Diese Nachricht wird vom IDE zum Aufbau der Kommunikationsverbindung mit der VU ausgegeben. Der Verbindungsaufbau und die Kommunikation erfolgt anfangs stets mit einer Datenrate von 9600 Baud (solange die Übertragungsgeschwindigkeit nicht durch einen Link Control Service (Verbindungssteuerungsdienst) geändert wird).

2.2.2.2

Positive Response Start Communication (SID C1)

DDP_006

Diese Nachricht wird von der VU als positive Antwort auf einen Start Communication Request ausgegeben. Sie enthält die beiden Schlüsselbytes „EA” „8F” als Hinweis darauf, dass die Einheit das Protokoll mit Kopf einschließlich Ziel-, Quell- und Längeninformation unterstützt.

2.2.2.3

Start Diagnostic Session Request (SID 10)

DDP_007

Die Nachricht Start Diagnostic Session Request wird vom IDE ausgegeben, um einen neuen Diagnosevorgang mit der VU zu beginnen. Die Untervariable „default session” (81 Hex) zeigt an, dass ein Standard-Diagnosevorgang eingeleitet werden soll.

2.2.2.4

Positive Response Start Diagnostic (SID 50)

DDP_008

Die Nachricht Positive Response Start Diagnostic wird von der VU als positive Antwort auf einen Diagnostic Session Request gesendet.

2.2.2.5

Link Control Service (SID 87)

DDP_052

Mit Hilfe des Link Control Service (Verbindungssteuerungsdienst) leitet die IDE einen Wechsel der Übertragungsgeschwindigkeit (Baudrate) ein. Dies erfolgt in zwei Schritten. Zunächst schlägt die IDE einen Wechsel vor und gibt dazu die neue Baudrate an. Nach einer positiven Antwort der VU sendet die IDE dann im zweiten Schritt eine Bestätigung des Geschwindigkeitswechsels an die VU und geht danach zur neuen Baudrate über. Nach Erhalt der Bestätigung geht auch die VU zur neuen Baudrate über.

2.2.2.6

Link Control Positive Response (SID C7)

DDP_053

Die Nachricht Link Control Positive Response wird von der VU als positive Antwort auf einen Link Control Service Request (Schritt 1) gesendet. Die Bestätigungsmeldung (Schritt 2) wird dagegen nicht beantwortet.

2.2.2.7

Request Upload (SID 35)

DDP_009

Die Nachricht Request Upload wird vom IDE als Mitteilung an die VU ausgegeben, dass eine Download-Operation angefordert wird. In Übereinstimmung mit der ISO 14229 umfasst diese Anforderung stets Angaben zu Adresse, Größe und Format der angeforderten Daten. Da diese Angaben der IDE jedoch vor dem Herunterladen nicht bekannt sind, wird die Speicheradresse auf „0” , das Format auf „verschlüsselt und unkomprimiert” und die Speichergröße auf den Höchstwert gesetzt.

2.2.2.8

Positive Response Request Upload (SID 75)

DDP_010

Die Nachricht Positive Response Request Upload wird von der VU gesendet, um dem IDE anzuzeigen, dass die VU zum Herunterladen der Daten bereit ist. In Übereinstimmung mit der ISO 14229 enthält diese Positive-Response-Nachricht auch Daten, mit denen der IDE mitgeteilt wird, dass spätere Nachrichten Positive Response Transfer Data höchstens 00FF Hex Bytes umfassen werden.

2.2.2.9

Transfer Data Request (SID 36)

DDP_011

Die Nachricht Transfer Data Request wird vom IDE gesendet und spezifiziert der VU den herunterzuladenden Datentyp. Mit dem Byte Transfer Request Parameter (TRTP) wird die Übertragungsart angegeben.

Es gibt sieben Arten der Datenübertragung. Beim VU-Datendownload können für jede Übertragungsart zwei unterschiedliche TRTP-Werte verwendet werden:

Datenübertragungsart	TRTP-Wert für VU-Datendownloads der 1. Generation	TRTP-Wert für VU-Datendownloads der 2. Generation, Version 1	TRTP-Wert für VU-Datendownloads der 2. Generation, Version 2
Download-Schnittstellenversion	Nicht verwendet	Nicht verwendet	00
Überblick	01	21	31
Tätigkeiten eines bestimmten Tages	02	22	32
Ereignisse und Störungen	03	23	33
Genaue Geschwindigkeitsangaben	04	24	24
Technische Daten	05	25	35

Datenübertragungsart	TRTP-Wert
Kartendownload	06

DDP_054

Die IDE muss beim Herunterladen eine Überblicks-Datenübertragung (TRTP 01, 21 oder 31) anfordern, da nur so die VU-Zertifikate in der heruntergeladenen Datei gespeichert werden (und die digitale Signatur geprüft werden kann).

Im dritten Fall (TRTP 02, 22 oder 32) schließt die Nachricht Transfer Data Request die Angabe des herunterzuladenden Kalendertags (Format TimeReal) ein.

2.2.2.10

Positive Response Transfer Data (SID 76)

DDP_012

Die Nachricht Positive Response Transfer Data wird von der VU als Antwort auf die Transfer Data Request gesendet. Sie enthält die angeforderten Daten, wobei die Transfer Response Parameter (TREP) der TRTP der Anforderung entspricht.

DDP_055

Im ersten Fall (TREP 01, 21 oder 31) sendet die VU Daten, die es dem IDE-Bediener erleichtern, die von ihm herunterzuladenden Daten auszuwählen. Diese Nachricht enthält folgende Informationen:

—

Sicherheitszertifikate,

—

Fahrzeugkennung,

—

aktuelles Datum und Uhrzeit der VU,

—

min. und max. herunterladbares Datum (VU-Daten),

—

Angabe der in die VU eingesteckten Karten,

—

der vorherige Download an ein Unternehmen,

—

Unternehmenssperren,

—

bisherige Kontrollen.

2.2.2.11

Request Transfer Exit (SID 37)

DDP_013

Mit der Nachricht Request Transfer Exit teilt das IDE der VU mit, dass der Download-Vorgang beendet ist.

2.2.2.12

Positive Response Request Transfer Exit (SID 77)

DDP_014

Die Nachricht Positive Response Request Transfer Exit wird von der VU zur Quittierung der Request Transfer Exit gesendet.

2.2.2.13

Stop Communication Request (SID 82)

DDP_015

Die Nachricht Stop Communication Request wird vom IDE gesendet, um die Kommunikationsverbindung mit der VU zu trennen.

2.2.2.14

Positive Response Stop Communication (SID C2)

DDP_016

Mit der Nachricht Positive Response Stop Communication quittiert die VU die Nachricht Stop Communication Request.

2.2.2.15

Acknowledge Sub Message (SID 83)

DDP_017

Mit der Nachricht Acknowledge Sub Message bestätigt das IDE den Empfang der einzelnen Teile einer Nachricht, die in mehreren Teilnachrichten gesendet wird. Das Datenfeld enthält die von der VU empfangene SID sowie einen 2-Byte-Code wie folgt:

—

MsgC + 1 quittiert den korrekten Empfang der Teilnachricht Nummer MsgC.

Anforderung vom IDE an die VU zur Sendung der nächsten Teilnachricht.

—

MsgC zeigt ein Problem beim Empfang der Teilnachricht Nummer MsgC an.

Anforderung von IDE an die VU zur erneuten Sendung der Teilnachricht.

—

FFFF fordert zur Beendigung der Nachricht auf.

Kann vom IDE zur Beendigung der Übertragung der VU-Nachricht aus irgendeinem Grund verwendet werden.

Die letzte Teilnachricht einer Nachricht (LEN-Byte < 255) kann unter Verwendung eines dieser Codes oder gar nicht quittiert werden.

Folgende VU-Antwort besteht aus mehreren Teilnachrichten:

—

Positive Response Transfer Data (SID 76)

2.2.2.16

Negative Response (SID 7F)

DDP_018

Die Nachricht Negative Response wird von der VU als Antwort auf die oben genannten Anforderungsnachrichten gesendet, wenn sie die Anforderung nicht erfüllen kann. Die Datenfelder der Nachricht enthalten die SID der Antwort (7F), die SID der Anforderung sowie einen Code zur Angabe des Grundes der negativen Antwort. Folgende Codes stehen zur Verfügung:

—

10 general reject

Aktion kann aus einem im Folgenden nicht aufgeführten Grund nicht ausgeführt werden.

—

11 service not supported

Die SID der Anforderung wird nicht verstanden.

—

12 sub function not supported

Die DS_ oder TRTP der Anforderung wird nicht verstanden, oder es sind keine weiteren Teilnachrichten zu übertragen.

—

13 incorrect message length

Die Länge der erhaltenen Nachricht ist nicht korrekt.

—

22 conditions not correct or request sequence error

Der angeforderte Dienst ist nicht aktiv oder die Reihenfolge der Anforderungsnachrichten ist nicht korrekt.

—

31 Request out of range

Der Parameterdatensatz der Anforderung (Datenfeld) ist ungültig.

—

50 upload not accepted

Die Anforderung kann nicht ausgeführt werden (VU in einem nicht geeigneten Modus oder interne Störung der VU).

—

78 response pending

Die angeforderte Aktion kann nicht rechtzeitig abgeschlossen werden, und die VU ist nicht bereit, eine weitere Anforderung anzunehmen.

—

FA data not available

Das Datenobjekt einer Datenübertragungsanforderung ist in der VU nicht verfügbar (z. B. keine Karte eingesetzt, VU-Datendownload-Anforderung der 1. Generation außerhalb des Rahmens von Fahrerkontrollen durch eine Nicht-EU-Kontrollbehörde, …).

2.2.3

Nachrichtenfluss

Ein typischer Nachrichtenfluss während einer normalen Datendownload-Prozedur sieht folgendermaßen aus:

IDE		VU
Start Communication Request	⇨
	⇦	Positive Response
Start Diagnostic Service Request	⇨
	⇦	Positive Response
Request Upload	⇨
	⇦	Positive Response
Transfer Data Request Overview	⇨
	⇦	Positive Response
Transfer Data Request #2	⇨
	⇦	Positive Response #1
Acknowledge Sub Message #1	⇨
	⇦	Positive Response #2
Acknowledge Sub Message #2	⇨
	⇦	Positive Response #m
Acknowledge Sub Message #m	⇨
	⇦	Positive Response (Data Field < 255 Bytes)
Acknowledge Sub Message (optional)	⇨
…
Transfer Data Request #n	⇨
	⇦	Positive Response
Request Transfer Exit	⇨
	⇦	Positive Response
Stop Communication Request	⇨
	⇦	Positive Response

2.2.4

Timing

DDP_019

Während des normalen Betriebs sind die in der folgenden Abbildung dargestellten Timing-Parameter relevant:

Abbildung 1

Hierbei sind:

P1=

Zeit zwischen den Bytes bei VU-Antwort.

P2=

Zeit zwischen dem Ende der IDE-Anforderung und dem Beginn der VU-Antwort bzw. zwischen dem Ende der IDE-Quittung und dem Beginn der nächsten VU-Antwort.

P3=

Zeit zwischen dem Ende der VU-Antwort und dem Beginn der neuen IDE-Anforderung bzw. zwischen dem Ende der VU-Antwort und dem Beginn der IDE-Quittung bzw. zwischen dem Ende der IDE-Anforderung und dem Beginn der neuen IDE-Anforderung, wenn VU nicht antwortet.

P4=

Zeit zwischen den Bytes bei IDE-Anforderung.

P5=

Erweiterter Wert von P3 für das Herunterladen der Karte.

Die zulässigen Werte für die Timing-Parameter sind in der folgenden Tabelle aufgeführt (KWP — erweiterter Timing-Parametersatz, verwendet bei physischer Adressierung zwecks schnellerer Kommunikation).

Timing-Parameter	Unterer Grenzwert (ms)	Oberer Grenzwert (ms)
P1	0	20
P2	20	1000 (**)
P3	10	5000
P4	5	20
P5	10	20 Minuten

2.2.5

Fehlerbehandlung

Tritt während des Nachrichtenaustauschs ein Fehler auf, erfolgt eine Modifizierung des Nachrichtenflusses in Abhängigkeit von dem Gerät, das den Fehler erkannt hat, sowie von der Nachricht, die den Fehler hervorgerufen hat. In Abbildung 2 und 3 sind die Fehlerbehandlungsprozeduren für die VU bzw. für das IDE dargestellt.

2.2.5.1

Start Communication-Phase

DDP_020

Erkennt das IDE einen Fehler während der Start Communication-Phase entweder durch Timing oder durch den Bitstrom, wartet es P3min bis zur erneuten Ausgabe der Anforderung.

DDP_021

Erkennt die VU einen Fehler in der vom IDE eingehenden Folge, sendet sie keine Antwort und wartet innerhalb des Zeitraums P3max auf eine weitere Nachricht Start Communication Request.

2.2.5.2

Communication-Phase

Es lassen sich zwei verschiedene Fehlerbehandlungsbereiche definieren:

1.

Die VU erkennt einen IDE-Übertragungsfehler.

DDP_022

Die VU prüft jede empfangene Nachricht auf Timing-Fehler, Byteformatfehler (z. B. Start- und Stoppbitverletzungen) sowie Datenpaketfehler (falsche Byteanzahl empfangen, falsches Prüfsummenbyte).

DDP_023

Erkennt die VU einen der vorstehend genannten Fehler, sendet sie keine Antwort und ignoriert die empfangene Nachricht.

DDP_024

Die VU kann andere Fehler im Format oder Inhalt der empfangenen Nachricht (z. B. Nachricht nicht unterstützt) feststellen, selbst wenn die Nachricht die erforderlichen Längen und Prüfsummen einhält; in diesem Fall antwortet die VU dem IDE mit einer Negative Response-Nachricht unter Angabe der Fehlerart.

2.

Das IDE erkennt einen VU-Übertragungsfehler.

DDP_025

Das IDE prüft jede empfangene Nachricht auf Timing-Fehler, Byteformatfehler (z. B. Start- und Stoppbitverletzungen) sowie Datenpaketfehler (falsche Byteanzahl empfangen, falsches Prüfsummenbyte).

DDP_026

Das IDE erkennt Sequenzfehler, z. B. die inkorrekte Erhöhung des Teilnachrichtenzählers bei nacheinander empfangenen Nachrichten.

DDP_027

Erkennt das IDE einen Fehler oder ist innerhalb des Zeitraums P2max keine Antwort von der VU erfolgt, wird die Anforderungsnachricht für insgesamt maximal drei Übertragungen erneut gesendet. Zum Zwecke dieser Fehlererkennung wird eine Teilnachrichtquittung als Anforderung an die VU betrachtet.

DDP_028

Vor dem Beginn jeder Sendung wartet das IDE mindestens P3min; die Wartezeit wird vom letzten errechneten Auftreten eines Stoppbits nach der Fehlererkennung an gemessen.

2.2.6

Inhalt der Antwortnachricht

In diesem Abschnitt wird der Inhalt der Datenfelder der verschiedenen positiven Antwortnachrichten spezifiziert. Die Datenelemente sind in Anlage 1, Datenglossar, definiert.

Hinweis: Bei Downloads der 2. Generation wird jedes oberste Datenelement durch ein Datensatz-Array repräsentiert, auch wenn dieser lediglich einen Datensatz umfasst. Ein Datensatz-Array beginnt mit dem Kopf; dieser Kopf enthält Datensatztyp, Datensatzgröße und die Anzahl an Datensätzen. Die Datensatz-Arrays sind in den folgenden Tabellen durch „… RecordArray” (mit Kopf) gekennzeichnet.

2.2.6.1

Positive Response Transfer Data Download Interface Version (Positive Antwort Datenübertragung, Version der Download-Schnittstelle)

DDP_028a

Das Datenfeld der Nachricht „Positive Response Transfer Data Download Interface Version” liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 00 Hex:

Datenstruktur der 2. Generation, Version 2 (TREP 00 Hex)

Datenelement		Bemerkung
DownloadInterfaceVersion		Generation und Version der VU: 02,02 Hex für 2. Generation, Version 2 Nicht unterstützt von VU 1. Generation und 2. Generation, Version 1, die negativ antworten (Unterfunktion nicht unterstützt, siehe DDP_018)

2.2.6.2

Positive Response Transfer Data Overview (Positive Antwort Datenübertragung, Überblick)

DDP_029

Das Datenfeld der Nachricht „Positive Response Transfer Data Overview” liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 01, 21 oder 31 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

Datenstruktur der 1. Generation (TREP 01 Hex)

Datenelement		Bemerkung
MemberStateCertificate		VU-Sicherheitszertifikate
VUCertificate
VehicleIdentificationNumber		Fahrzeugkennung
VehicleRegistrationIdentification
CurrentDateTime		Aktuelle(s) Datum und Uhrzeit der VU
VuDownloadablePeriod		Herunterladbarer Zeitraum
CardSlotsStatus		Art der in die VU eingesteckten Karten
VuDownloadActivityData		Vorhergehender VU-Download
VuCompanyLocksData		Alle gespeicherten Unternehmenssperren. Ist der Abschnitt leer, wird lediglich noOfLocks = 0 gesendet.
VuControlActivityData		Alle in der VU gespeicherten Kontrolldatensätze. Ist der Abschnitt leer, wird lediglich noOfControls = 0 gesendet.
Signature		RSA-Signatur aller Daten (außer Zertifikate), beginnend mit VehicleIdentificationNumber bis hin zum letzten Byte des letzten VuControlActivityData.

Datenstruktur der 2. Generation, Version 1 (TREP 21 Hex)

Datenelement		Bemerkung
MemberStateCertificateRecordArray		Zertifikat des Mitgliedstaates
VUCertificateRecordArray		VU-Zertifikat
VehicleIdentificationNumberRecordArray		Fahrzeugkennung
VehicleRegistrationIdentificationRecordArray		Amtliches Kennzeichen des Fahrzeugs
CurrentDateTimeRecordArray		Aktuelle(s) Datum und Uhrzeit der VU
VuDownloadablePeriodRecordArray		Herunterladbarer Zeitraum
CardSlotsStatusRecordArray		Art der in die VU eingesteckten Karten
VuDownloadActivityDataRecordArray		Vorhergehender VU-Download
VuCompanyLocksRecordArray		Alle gespeicherten Unternehmenssperren. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuControlActivityRecordArray		Alle in der VU gespeicherten Kontrolldatensätze. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten mit Ausnahme der Zertifikate.

Datenstruktur der 2. Generation, Version 2 (TREP 31 Hex)

Datenelement		Bemerkung
MemberStateCertificateRecordArray		Zertifikat des Mitgliedstaates
VUCertificateRecordArray		VU-Zertifikat
VehicleIdentificationNumberRecordArray		Fahrzeugkennung
VehicleRegistrationNumberRecordArray		Amtliches Kennzeichen des Fahrzeugs
CurrentDateTimeRecordArray		Aktuelle(s) Datum und Uhrzeit der VU
VuDownloadablePeriodRecordArray		Herunterladbarer Zeitraum
CardSlotsStatusRecordArray		Art der in die VU eingesteckten Karten
VuDownloadActivityDataRecordArray		Vorhergehender VU-Download
VuCompanyLocksRecordArray		Alle gespeicherten Unternehmenssperren. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuControlActivityRecordArray		Alle in der VU gespeicherten Kontrolldatensätze. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten mit Ausnahme der Zertifikate.

2.2.6.3

Positive Response Transfer Data Activities (Positive Antwort Datenübertragung, Tätigkeiten)

DDP_030

Das Datenfeld der Nachricht „Positive Response Transfer Data Activities” liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 02, 22 oder 32 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

Datenstruktur der 1. Generation (TREP 02 Hex)

Datenelement		Bemerkung
TimeReal		Datum des heruntergeladenen Tages
OdometerValueMidnight		Kilometerstand am Ende des heruntergeladenen Tages
VuCardIWData		Daten zu den Einsteck-/Entnahmevorgängen dieser Karte. — Enthält dieser Abschnitt keine verfügbaren Daten, wird lediglich noOfVuCardIWRecords = 0 gesendet. — Geht ein VuCardIWRecord über 00.00 Uhr (Einstecken der Karte am Vortag) oder 24.00 Uhr (Kartenentnahme am Folgetag) hinaus, erscheint er vollständig für beide Tage.
VuActivityDailyData		Steckplatzstatus um 00.00 Uhr und aufgezeichnete Tätigkeitsänderungen für den heruntergeladenen Tag.
VuPlaceDailyWorkPeriodData		Aufgezeichnete Ortsdaten für den heruntergeladenen Tag. Ist der Abschnitt leer, wird lediglich noOfPlaceRecords = 0 gesendet.
VuSpecificConditionData		Aufgezeichnete spezifische Bedingungen für den heruntergeladenen Tag. Ist der Abschnitt leer, wird lediglich noOfSpecificConditionRecords = 0 gesendet.
Signature		RSA-Signatur aller Daten, beginnend mit TimeReal bis hin zum letzten Byte des letzten Datensatzes einer spezifischen Bedingung.

Datenstruktur der 2. Generation, Version 1 (TREP 22 Hex)

Datenelement		Bemerkung
DateOfDayDownloadedRecordArray		Datum des heruntergeladenen Tages
OdometerValueMidnightRecordArray		Kilometerstand am Ende des heruntergeladenen Tages
VuCardIWRecordArray		Daten zu den Einsteck-/Entnahmevorgängen dieser Karte. — Enthält dieser Abschnitt keine verfügbaren Daten, wird lediglich ein Array-Kopf mit noOfRecords = 0 gesendet. — Geht ein VuCardIWRecord über 00.00 Uhr (Einstecken der Karte am Vortag) oder 24.00 Uhr (Kartenentnahme am Folgetag) hinaus, erscheint er vollständig für beide Tage.
VuActivityDailyRecordArray		Steckplatzstatus um 00.00 Uhr und aufgezeichnete Tätigkeitsänderungen für den heruntergeladenen Tag.
VuPlaceDailyWorkPeriodRecordArray		Aufgezeichnete Ortsdaten für den heruntergeladenen Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuGNSSADRecordArray		GNSS-Position des Fahrzeugs, wenn die kumulierte Lenkzeit des Fahrzeugs ein Vielfaches von drei Stunden erreicht. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuSpecificConditionRecordArray		Aufgezeichnete spezifische Bedingungen für den heruntergeladenen Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

Datenstruktur der 2. Generation, Version 2 (TREP 32 Hex)

Datenelement		Bemerkung
DateOfDayDownloadedRecordArray		Datum des heruntergeladenen Tages
OdometerValueMidnightRecordArray		Kilometerstand am Ende des heruntergeladenen Tages
VuCardIWRecordArray		Daten zu den Einsteck-/Entnahmevorgängen dieser Karte. — Enthält dieser Abschnitt keine verfügbaren Daten, wird lediglich ein Array-Kopf mit noOfRecords = 0 gesendet. — Geht ein VuCardIWRecord über 00.00 Uhr (Einstecken der Karte am Vortag) oder 24.00 Uhr (Kartenentnahme am Folgetag) hinaus, erscheint er vollständig für beide Tage.
VuActivityDailyRecordArray		Steckplatzstatus um 00.00 Uhr und aufgezeichnete Tätigkeitsänderungen für den heruntergeladenen Tag.
VuPlaceDailyWorkPeriodRecordArray		Aufgezeichnete Ortsdaten für den heruntergeladenen Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuGNSSADRecordArray		GNSS-Position des Fahrzeugs, wenn die kumulierte Lenkzeit des Fahrzeugs ein Vielfaches von drei Stunden erreicht. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuSpecificConditionRecordArray		Aufgezeichnete spezifische Bedingungen für den heruntergeladenen Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuBorderCrossingRecordArray		Grenzüberschreitungen für den heruntergeladenen Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuLoadUnloadRecordArray		Be-/Entladevorgänge für den heruntergeladenen Tag. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

2.2.6.4

Positive Response Transfer Data Events and Faults (Positive Antwort Datenübertragung, Ereignisse und Störungen)

DDP_031

Das Datenfeld der Nachricht „Positive Response Transfer Data Events and Faults” liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 03, 23 oder 33 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

Datenstruktur der 1. Generation (TREP 03 Hex)

Datenelement		Bemerkung
VuFaultData		Alle in der VU gespeicherten oder andauernden Störungen. Ist der Abschnitt leer, wird lediglich noOfVuFaults = 0 gesendet.
VuEventData		Alle in der VU gespeicherten oder andauernden Ereignisse (außer Geschwindigkeitsüberschreitung). Ist der Abschnitt leer, wird lediglich noOfVuEvents = 0 gesendet.
VuOverSpeedingControlData		Daten zur letzten Kontrolle Geschwindigkeitsüberschreitung (Standardwert, wenn keine Daten vorhanden).
VuOverSpeedingEventData		Alle in der VU gespeicherten Ereignisse Geschwindigkeitsüberschreitung. Ist der Abschnitt leer, wird lediglich noOfVuOverSpeedingEvents = 0 gesendet.
VuTimeAdjustmentData		Alle in der VU gespeicherten Zeiteinstellungsereignisse (außerhalb des Rahmens einer vollständigen Kalibrierung). Ist der Abschnitt leer, wird lediglich noOfVuTimeAdjRecords = 0 gesendet.
Signature		RSA-Signatur aller Daten, beginnend mit noOfVuFaults bis hin zum letzten Byte des letzten Zeiteinstellungsdatensatzes.

Datenstruktur der 2. Generation, Version 1 (TREP 23 Hex)

Datenelement		Bemerkung
VuFaultRecordArray		Alle in der VU gespeicherten oder andauernden Störungen. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuEventRecordArray		Alle in der VU gespeicherten oder andauernden Ereignisse (außer Geschwindigkeitsüberschreitung). Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuOverSpeedingControlDataRecordArray		Daten zur letzten Kontrolle Geschwindigkeitsüberschreitung (Standardwert, wenn keine Daten vorhanden).
VuOverSpeedingEventRecordArray		Alle in der VU gespeicherten Ereignisse Geschwindigkeitsüberschreitung. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuTimeAdjustmentRecordArray		Alle in der VU gespeicherten Zeiteinstellungsereignisse (außerhalb des Rahmens einer vollständigen Kalibrierung). Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

Datenstruktur der 2. Generation, Version 2 (TREP 33 Hex)

Datenelement		Bemerkung
VuFaultRecordArray		Alle in der VU gespeicherten oder andauernden Störungen. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuEventRecordArray		Alle in der VU gespeicherten oder andauernden Ereignisse (außer Geschwindigkeitsüberschreitung). Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuOverSpeedingControlDataRecordArray		Daten zur letzten Kontrolle Geschwindigkeitsüberschreitung (Standardwert, wenn keine Daten vorhanden).
VuOverSpeedingEventRecordArray		Alle in der VU gespeicherten Ereignisse Geschwindigkeitsüberschreitung. Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
VuTimeAdjustmentRecordArray		Alle in der VU gespeicherten Zeiteinstellungsereignisse (außerhalb des Rahmens einer vollständigen Kalibrierung). Ist der Abschnitt leer, wird ein Array-Kopf mit noOfRecords = 0 gesendet.
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

2.2.6.5

Positive Response Transfer Data Detailed Speed (Positive Antwort Datenübertragung, genaue Geschwindigkeitsangaben)

DDP_032

Das Datenfeld der Nachricht „Positive Response Transfer Data Detailed Speed” liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 04 oder 24 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

Datenstruktur der 1. Generation (TREP 04 Hex)

Datenelement		Bemerkung
VuDetailedSpeedData		Alle in der VU gespeicherten detaillierten Geschwindigkeitsdaten (ein Geschwindigkeitsblock pro Minute, in der sich das Fahrzeug bewegt hat). 60 Geschwindigkeitswerte pro Minute (ein Wert pro Sekunde).
Signature		RSA-Signatur aller Daten, beginnend mit noOfSpeedBlocks bis hin zum letzten Byte des letzten Geschwindigkeitsblocks.

Datenstruktur der 2. Generation (TREP 24 Hex)

Datenelement		Bemerkung
VuDetailedSpeedBlockRecordArray		Alle in der VU gespeicherten detaillierten Geschwindigkeitsdaten (ein Geschwindigkeitsblock pro Minute, in der sich das Fahrzeug bewegt hat). 60 Geschwindigkeitswerte pro Minute (ein Wert pro Sekunde).
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

2.2.6.6

Positive Response Transfer Data Technical Data (Positive Antwort Datenübertragung, Technische Daten)

DDP_033

Das Datenfeld der Nachricht „Positive Response Transfer Data Technical Data” liefert folgende Daten in folgender Reihenfolge unter SID 76 Hex und TREP 05, 25 oder 35 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

Datenstruktur der 1. Generation (TREP 05 Hex)

Datenelement		Bemerkung
VuIdentification
SensorPaired
VuCalibrationData		Alle in der VU gespeicherten Kalibrierungsdatensätze.
Signature		RSA-Signatur aller Daten, beginnend mit vuManufacturerName bis hin zum letzten Byte des letzten VuCalibrationRecord.

Datenstruktur der 2. Generation, Version 1 (TREP 25 Hex)

Datenelement		Bemerkung
VuIdentificationRecordArray
VuSensorPairedRecordArray		Alle in der VU gespeicherten MS-Kopplungen.
VuSensorExternalGNSSCoupledRecordArray		Alle in der VU gespeicherten Kopplungen externer GNSS-Ausrüstung.
VuCalibrationRecordArray		Alle in der VU gespeicherten Kalibrierungsdatensätze.
VuCardRecordArray		Alle in der VU gespeicherten Karteneinsteckdaten.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

Datenstruktur der 2. Generation, Version 2 (TREP 35 Hex)

Datenelement		Bemerkung
VuIdentificationRecordArray
VuSensorPairedRecordArray		Alle in der VU gespeicherten MS-Kopplungen.
VuSensorExternalGNSSCoupledRecordArray		Alle in der VU gespeicherten Kopplungen externer GNSS-Ausrüstung.
VuCalibrationRecordArray		Alle in der VU gespeicherten Kalibrierungsdatensätze.
VuCardRecordArray		Alle in der VU gespeicherten Karteneinsteckdaten.
VuITSConsentRecordArray
VuPowerSupplyInterruptionRecordArray
SignatureRecordArray		ECC-Signatur aller vorhergehenden Daten.

2.3.

ESM-Datenspeicherung

DDP_034

War eine VU-Datenübertragung Bestandteil eines Download-Vorgangs, speichert das IDE in einer einzigen physischen Datei alle Daten, die während des Download-Vorgangs von der VU in Positive Response Transfer Data-Nachrichten empfangen wurden. Dabei nicht gespeichert werden Nachrichtenköpfe, Teilnachrichtenzähler, leere Teilnachrichten und Prüfsummen, gespeichert werden jedoch SID und TREP (nur der ersten Teilnachricht bei mehreren Teilnachrichten).

3.

PROTOKOLL FÜR DAS HERUNTERLADEN VON DATEN VON FAHRTENSCHREIBERKARTEN

3.1.

Geltungsbereich

Dieser Abschnitt beschreibt das direkte Herunterladen der Kartendaten einer Kontrollgerätkarte auf ein IDE. Da das IDE nicht Bestandteil der Sicherheitsumgebung ist, erfolgt keine Authentisierung zwischen der Karte und dem IDE.

3.2.

Begriffsbestimmungen

Download-Vorgang :

Die Ausführung eines Download der Chipkartendaten. Der Vorgang umfasst die gesamte Prozedur vom Zurücksetzen der Chipkarte durch ein IFD bis zur Deaktivierung der Chipkarte (Entnahme der Karte oder nächstes Zurücksetzen).

Signierte Datei :

Eine Datei von der Chipkarte. Die Datei wird in Klartext zum IFD übertragen. Auf der Chipkarte erfolgt eine Hash-Code-Anwendung für die Datei, sie wird signiert, und die Signatur wird an das IFD übertragen.

3.3.

Herunterladen von der Karte

DDP_035

Das Herunterladen einer Fahrtenschreiberkarte beinhaltet die folgenden Schritte:

—

Herunterladen der gemeinsamen Informationen der Karte in den EF ICC und IC. Diese Informationen sind fakultativ und werden nicht mit einer digitalen Signatur gesichert.

—

Für Fahrtenschreiberkarten der 1. und 2. Generation:

—

Herunterladen der EF innerhalb der Tachograph DF

—

Herunterladen der EF Card_Certificate und CA_Certificate. Diese Informationen werden nicht mit einer digitalen Signatur gesichert.

Das Herunterladen dieser Dateien ist bei jedem Download-Vorgang obligatorisch.

—

Herunterladen der anderen Anwendungsdaten-EF (innerhalb der Tachograph DF) außer EF Card_Download. Diese Informationen werden mit einer digitalen Signatur gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil A gesichert.

—

Bei jedem Herunterladen ist zumindest das Herunterladen der EF Application_Identification und Identification obligatorisch.

—

Beim Herunterladen einer Fahrerkarte ist zudem der Download folgender EF obligatorisch:

Events_Data

Faults_Data

Driver_Activity_Data

Vehicles_Used

Places

Control_Activity_Data

Specific_Conditions.

—

Nur für Fahrtenschreiberkarten der 2. Generation:

—

Herunterladen der EF innerhalb der DF Tachograph_G2, außer im Fall von Datendownloads einer in eine VU eingesteckten Fahrerkarte bei Kontrollen durch eine Nicht-EU-Kontrollbehörde mit einer Kontrollkarte der 1. Generation:

—

Herunterladen der EF CardSignCertificate, CA_Certificate und Link_Certificate. Diese Informationen werden nicht mit einer digitalen Signatur gesichert.

—

Das Herunterladen dieser Dateien ist bei jedem Download-Vorgang obligatorisch.

—

Herunterladen der anderen Anwendungsdaten-EF (innerhalb der DF Tachograph_G2) außer EF Card_Download. Diese Informationen werden mit einer digitalen Signatur gemäß Anlage 11 Gemeinsame Sicherheitsmechanismen Teil B gesichert.

—

Bei jedem Herunterladen ist zumindest das Herunterladen der EF Application_Identification, Application_Identification_V2 (wenn vorhanden) und Identification obligatorisch.

—

Beim Herunterladen einer Fahrerkarte ist zudem der Download folgender EF obligatorisch:

Events_Data

Faults_Data

Driver_Activity_Data

Vehicles_Used

Places

Control_Activity_Data

Specific_Conditions

VehicleUnits_Used

GNSS_Places

Places_Authentication, wenn vorhanden

GNSS_Places_Authentication, wenn vorhanden

Border_Crossings, wenn vorhanden

Load_Unload_Operations, wenn vorhanden

Load_Type_Entries, wenn vorhanden

—

Beim Herunterladen einer Fahrerkarte wird das Datum LastCardDownload in der EF Card_Download, in der DF Tachograph und gegebenenfalls in der DF Tachograph_G2 aktualisiert.

—

Beim Herunterladen einer Werkstattkarte ist der Kalibrierungszähler in der EF CardDownload in der DF Tachograph und gegebenenfalls in der DF Tachograph_G2 zurückzusetzen.

—

Beim Herunterladen einer Werkstattkarte ist EF Sensor_Installation_Data in der DF Tachograph und gegebenenfalls in der DF Tachograph_G2 nicht herunterzuladen.

3.3.1

Initialisierungssequenz

DDP_036

Das IDE leitet die folgende Sequenz ein:

Karte	Richtung	IDE/IFD	Bedeutung/Bemerkungen
	⇦	Hardware zurücksetzen
ATR	⇨

Mit PPS kann auf eine höhere Baudrate gewechselt werden, sofern die Chipkarte diese Baudrate unterstützt.

3.3.2

Sequenz für unsignierte Dateien

DDP_037

Die Sequenz für das Herunterladen der EF ICC, IC, Card_Certificate (oder CardSignCertificate für DF Tachograph_G2), CA_Certificate und Link_Certificate (nur für DF Tachograph_G2) lautet folgendermaßen:

Karte	Richtung	IDE/IFD	Bedeutung/Bemerkungen
	⇦	Select File	Auswahl nach Dateikennung
OK	⇨
	⇦	Read Binary	Enthält die Datei mehr Daten, als der Puffer des Lesers oder der Karte fassen kann, ist der Befehl so lange zu wiederholen, bis die gesamte Datei ausgelesen ist.
File Data OK	⇨	Daten auf ESM speichern	gemäß 3.4 Data storage format

Hinweis 1: Vor Auswahl der EF Card_Certificate (CardSignCertificate) muss die Fahrtenschreiberanwendung ausgewählt werden (Auswahl durch AID).

Hinweis 2: Das Auswählen und Auslesen einer Datei kann mithilfe des Befehls Read Binary mit Kurz-Elementardateikennung in einem Schritt erfolgen.

3.3.3

Sequenz für signierte Dateien

DDP_038

Die folgende Sequenz wird für die folgenden Dateien verwendet, die jeweils mit ihrer Signatur herunterzuladen sind:

Karte	Richtung	IDE/IFD	Bedeutung/Bemerkungen
		Select File
OK
		Perform Hash of File	— Berechnet den Hashwert über dem Dateninhalt der ausgewählten Datei mithilfe des vorgeschriebenen Hash-Algorithmus gemäß Anlage 11 Teil A oder B. Dieser Befehl ist kein ISO-Befehl.
Hash of File berechnen und Hashwert temporär speichern
OK
		Read Binary	Enthält die Datei mehr Daten, als der Puffer des Lesers oder der Karte fassen kann, ist der Befehl so lange zu wiederholen, bis die gesamte Datei ausgelesen ist.
File Data OK		Empfangene Daten auf ESM speichern	gemäß 3.4 Data storage format
		PSO: Compute Digital Signature
Perform Security Operation ‚Compute Digital Signature‘ mithilfe des temporär gespeicherten Hashwerts
Signature OK		Daten an die zuvor auf dem ESM gespeicherten Daten anfügen	gemäß 3.4 Data storage format

Hinweis: Das Auswählen und Auslesen einer Datei kann mithilfe des Befehls Read Binary mit Kurz-Elementardateikennung in einem Schritt erfolgen. In diesem Fall kann die EF ausgewählt und ausgelesen werden, bevor der Befehl Perform Hash of File angewendet wird.

3.3.4

Sequenz für das Zurücksetzen des Kalibrierungszählers

DDP_039

Die Sequenz für das Zurücksetzen des Zählers in der EF auf einer Werkstattkarte lautet folgendermaßen:

Karte	Richtung	IDE/IFD	Bedeutung/Bemerkungen
	⇦	Select File EF Card_Download	Auswahl nach Dateikennung
OK	⇨
	⇦	Update Binary NoOfCalibrationsSinceDownload = „00 00”
setzt Kartendownload zurück
OK	⇨

Hinweis: Das Auswählen und Aktualisieren einer Datei kann mithilfe des Befehls Update Binary mit Kurz-Elementardateikennung in einem Schritt erfolgen.

3.4.

Datenspeicherungsformat

3.4.1

Einleitung

DDP_040

Die heruntergeladenen Daten sind nach folgenden Bedingungen zu speichern:

—

Die Daten sind transparent zu speichern, d. h. die Reihenfolge der von der Karte übertragenen Bytes sowie die Reihenfolge der in ihnen enthaltenen Bits müssen während der Speicherung erhalten bleiben.

—

Alle im Rahmen eines Download-Vorgangs heruntergeladenen Dateien der Karte werden in einer einzigen Datei auf dem ESM gespeichert

3.4.2

Dateiformat

DDP_041

Das Dateiformat ist eine Verkettung mehrerer TLV-Objekte.

DDP_042

Der Tag für eine EF ist die FID sowie der Zusatz „00” .

DDP_043

Der Tag der Signatur einer EF ist die FID der Datei sowie der Zusatz „01” .

DDP_044

Die Länge ist ein 2-Byte-Wert. Der Wert legt die Anzahl der Bytes im Wertfeld fest. Der Wert „FF FF” im Längenfeld ist für eine künftige Verwendung reserviert.

DDP_045

Wird eine Datei nicht heruntergeladen, ist auch nichts zu speichern, was mit der Datei im Zusammenhang steht (also kein Tag und keine Nulllänge).

DDP_046

Eine Signatur wird als nächstes TLV-Objekt unmittelbar nach dem Objekt, das die Daten der Datei enthält, gespeichert.

Definition	Bedeutung	Länge
FID (2 Bytes) || ‚00‘	Tag für EF (FID) in oder für gemeinsame Informationen der Karte	3 Bytes
FID (2 Bytes) || ‚01‘	Tag für Signatur der EF (FID) in DF	3 Bytes
FID (2 Bytes) || ‚02‘	Tag für Signatur der EF (FID) in DF	3 Bytes
FID (2 Bytes) || ‚03‘	Tag für Signatur der EF (FID) in DF	3 Bytes
xx xx	Länge des Wertfelds	2 Bytes

Beispiel für Daten in einer Download-Datei auf einem ESM:

Tag	Länge	Wert
		— Daten von EF ICC
		— Daten von EF Card_Certificate
		— ...
		Daten von EF (in DF )
		Signatur von EF (in DF )
		Daten von EF in DF
		Signatur von EF in DF

4.

HERUNTERLADEN VON DER FAHRTENSCHREIBERKARTE ÜBER EINE FAHRZEUGEINHEIT

DDP_047

Die VU muss das Herunterladen des Inhalts einer eingesteckten und an ein IDE angeschlossenen Fahrerkarte zulassen.

DDP_048

Zum Starten dieses Modus sendet das IDE die Nachricht Transfer Data Request Card Download an die VU (siehe 2.2.2.9).

DDP_049

Fahrerkarten der 1. Generation: Für den Datendownload wird das Datendownload-Protokoll der 1. Generation verwendet, und die heruntergeladenen Daten haben das gleiche Format wie die von einer Fahrzeugeinheit der 1. Generation heruntergeladenen Daten.

Fahrerkarten der 2. Generation: Daraufhin lädt die VU die gesamte Karte dateiweise in Übereinstimmung mit dem in Abschnitt 3 definierten Download-Protokoll herunter und leitet alle von der Karte empfangenen Daten im entsprechenden TLV-Dateiformat (siehe 3.4.2) sowie eingekapselt in eine „Positive Response Transfer Data” -Nachricht an das IDE weiter.

DDP_050

Das IDE ruft die Kartendaten aus der Nachricht Positive Response Transfer Data ab (unter Fortlassung aller Köpfe, SID, TREP, Teilnachrichtenzähler und Prüfsummen) und speichert sie innerhalb einer in Abschnitt 2.3 beschriebenen physischen Datei.

DDP_051

Danach aktualisiert die VU gegebenenfalls die Dateien oder der Fahrerkarte.