umwelt-online: Archivdatei - VO (EWG) Nr. 3821/85 über das Kontrollgerät im Straßenverkehr (7)

zurück

3.6. Ausdruck Geschwindigkeitsüberschreitung

PRT_012 Der Ausdruck Geschwindigkeitsüberschreitung hat folgendes Format:

.

In dieser Anlage werden folgende Konventionen für die Notation verwendet:

• Zeichen in Fettdruck stehen für anzuzeigenden Klartext (in der Anzeige erscheinen die Zeichen unformatiert).
• Unformatierte Zeichen stehen für Variablen (Piktogramme oder Daten), die in der Anzeige durch ihre Werte ersetzt werden:

  TT MM JJJJ:	Tag, Monat, Jahr,
  hh:	Stunden,
  mm:	Minuten,
  D:	Piktogramm Dauer,
  EF:	Piktogrammkombination Ereignis oder Störung,
  O:	Piktogramm Betriebsart.

DIS_001 Die Anzeige von Daten durch das Kontrollgerät erfolgt in folgendem Format:

Daten	Format
Standardanzeige
Ortszeit	hh:mm
Betriebsart	O
Information zum Fahrer	1Dhhhmm hhhmm
Information zum 2. Fahrer	2Dhhhmm
Betriebsart "Kontrollgerät nicht erforderlich" eingeschaltet	OUT
Warnanzeige
Überschreitung der ununterbrochenen Lenkzeit	1hhhmm hhhmm
Ereignis oder Störung	EF
Sonstige Anzeigen
UTC-Datum Uhrzeit	UTC TT/MM/JJJJ oder UTC TT.MM.JJJJ hh:mm
Ununterbrochene Lenkzeit und kumulative Pausenzeit des Fahrers	1hhhmm hhhmm
Ununterbrochene Lenkzeit und kumulative Pausenzeit des 2. Fahrers	2 hhhmm hhhmm
Kumulierte Lenkzeit des Fahrers für die Vorwoche und die laufende Woche	1hhhhmm
Kumulierte Lenkzeit des 2. Fahrers für die Vorwoche und die laufende Woche	2hhhhmm

.

1. Hardware

1.1. Steckverbinder

INT_001 Das Herunterladen/Kalibrieren erfolgt über eine sechspolige Steckverbindung, die an der Frontplatte zugänglich ist, ohne dass ein Teil des Kontrollgeräts abgetrennt werden muss. Sie ist entsprechend der folgenden Abbildung auszulegen (sämtliche Maßangaben in mm):

Die folgende Abbildung zeigt einen typischen sechspoligen Stecker:

1.2. Belegung der Kontakte

INT_002 Die Kontakte sind entsprechend der nachstehenden Tabelle zu belegen:

1.3. Blockschaltbild

INT_003 Folgendes Blockschaltbild ist vorgegeben:

2. Schnittstelle zum Herunterladen

INT_004 Die Schnittstelle zum Herunterladen entspricht den RS232-Spezifikationen.

INT_005 Die Schnittstelle zum Herunterladen verwendet ein Startbit, 8 Datenbits mit dem niedrigstwertigen Bit an erster Stelle, ein Bit geradzahliger Parität und 1 Stoppbit.

Aufbau der Datenbytes

Bei der Übermittlung nummerischer Daten, die aus mehr als einem Byte bestehen, wird das höchstwertige Byte an erster Stelle und das niedrigstwertige Byte an letzter Stelle übertragen.

INT_006 Die Baudrate bei der Übertragung ist zwischen 9.600 und 115.200 bit/s einstellbar. Die Übertragung hat mit der höchstmöglichen Übertragungsgeschwindigkeit zu erfolgen, wobei die anfängliche Bitgeschwindigkeit nach dem Aufbau der Verbindung auf 9.600 bit/s gesetzt wird.

3. Kalibrierungsschnittstelle

INT_007 Die Datenkommunikation erfolgt nach ISO 14230-1 Straßenfahrzeuge - Diagnosesysteme - Schlüsselwort 2000 - Teil 1: Bitübertragungsschicht, 1999.

INT_008 Das Eingabe-/Ausgabesignal entspricht den folgenden elektrischen Spezifikationen:

INT_009 Für das Eingabe-/Ausgabesignal gelten die folgenden Zeitdiagramme:

Sensorsignal (abgehend)
Testsignal (ankommend)
UTC-Taktsignal (abgehend)

.

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 (FE) durch ein an die FE angeschlossenes Intelligent Dedicated Equipment (IDE),
• von einer Kontrollgerätkarte durch ein mit einem Kartenschnittstellengerät (IFD) ausgestattetes IDE,
• von einer Kontrollgerätkarte über eine Fahrzeugeinheit durch ein an die FE 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 (FE oder Karte) und dessen Sicherheitszertifikate (Mitgliedstaatszertifikat und Gerätezertifikat). Der Prüfer der Daten muss einen zuverlässigen europäischen öffentlichen Schlüssel besitzen.

DDP_001 Die während eines Download-Vorgangs heruntergeladenen Daten müssen auf dem ESM in einer einzigen Datei gespeichert werden.

1.2. Akronyme und Notation

In dieser Anlage werden folgende Akronyme verwendet:

2. Herunterladen von Daten von der Fahrzeugeinheit

2.1. Download-Verfahren

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

• Einführen seiner Kontrollgerätkarte in einen Steckplatz der FE ¹;
• Anschließen des IDE an den FE-Anschluss zum Herunterladen;
• Herstellen der Verbindung zwischen IDE und FE;
• Auswählen der herunterzuladenden Daten auf dem IDE und Senden der Anforderung an die FE;
• Beenden des Download-Vorgangs.

2.2. Datendownload-Protokoll

Das Protokoll ist auf Master/Slave-Basis aufgebaut, wobei das IDE den Master und die FE den Slave bildet.

Nachrichtenstruktur, -typ und -fluss beruhen prinzipiell auf dem Keyword Protocol 2000 (KWP) (ISO 14230-2 Straßenfahrzeuge - Diagnosesysteme - Schlüsselwort 2000 - Teil 2: Sicherungsschicht).

Die Anwendungsschicht beruht grundsätzlich auf dem aktuellen Normentwurf ISO 14229-1 (Straßenfahrzeuge - Diagnosesysteme - Teil 1: Diagnosedienste, Version 6 vom 22. Februar 2001).

2.2.1. Nachrichtenstruktur

DDP_002 Alle zwischen dem IDE und der FE 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).

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 FE.

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 Datenfeld-teil 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 FE 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:

wird übertragen als:

...

oder als:

...

2.2.2. Nachrichtentypen

Das Kommunikationsprotokoll für das Herunterladen von Daten zwischen der FE und dem IDE verlangt den Austausch von 8 verschiedenen Nachrichtentypen.

In der folgenden Tabelle sind diese Nachrichten zusammengefasst.

2.2.2.1. Start Communication Request (SID 81)

DDP_005 Diese Nachricht wird vom IDE zum Aufbau der Kommunikationsverbindung mit der FE ausgegeben. Der Verbindungsaufbau und die Kommunikation erfolgt anfangs stets mit einer Datenrate von 9.600 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 FE 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 FE 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 FE 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 FE sendet die die IDE dann im zweiten Schritt eine Bestätigung des Geschwindigkeitswechsels an die FE und geht danach zur neuen Baudrate über. Nach Erhalt der Bestätigung geht auch die FE 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 FE 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 FE 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 FE gesendet, um dem IDE anzuzeigen, dass die FE 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 die 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 FE den herunterzuladenden Datentyp. Mit dem Byte Transfer Request Parameter (TRTP) wird die Übertragungsart angegeben.

Es gibt sechs Arten der Datenübertragung:

• Überblick (TRTP 01),
• Tätigkeiten eines bestimmten Tages (TRTP 02),
• Ereignisse und Störungen (TRTP 03),
• Genaue Geschwindigkeitsangaben (TRTP 04),
• Technische Daten (TRTP 05),
• Kartendownload (TRTP 06).

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

Im zweiten Fall (TRTP 02) 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 FE als Antwort auf die Transfer Data Request gesendet. Sie enthält die angeforderten Daten, wobei die Transfer Response Parameter (TREP) den TRTP der Anforderung entspricht.

DDP_055 Im ersten Fall (TREP 01), sendet die FE 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 FE,
• min. und max. herunterladbares Datum (FE-Daten),
• Angabe der in die FE 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 FE 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 FE 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 FE zu trennen.

2.2.2.14. Positive Response Stop Communication (SID C2)

DDP_016 Mit der Nachricht Positive Response Stop Communication quittiert die FE 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 FE empfangene SID sowie einen 2-Byte-Code wie folgt:

• MsgC + 1 quittiert den korrekten Empfang der Teilnachricht Nummer MsgC.
  Anforderung vom IDE an die FE zur Sendung der nächsten Teilnachricht.
• MsgC zeigt ein Problem beim Empfang der Teilnachricht Nummer MsgC an.
  Anforderung von IDE an die FE zur erneuten Sendung der Teilnachricht.
• FFFF fordert zur Beendigung der Nachricht auf.
  Kann vom IDE zur Beendigung der Übertragung der FE-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 FE-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 FE als Antwort auf die obengenannten 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 (FE in einem nicht geeigneten Modus oder interne Störung der FE).
• 78 response pending
  Die angeforderte Aktion kann nicht rechtzeitig abgeschlossen werden, und die FE ist nicht bereit, eine weitere Anforderung anzunehmen.
• Fa data not available
  Das Datenobjekt einer Datenübertragungsanforderung ist in der FE nicht verfügbar (z.B. keine Karte eingesetzt, ...).

2.2.3. Nachrichtenfluss

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

2.2.4. Timing

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

Abbildung 1 Nachrichtenfluss, Timing

Hierbei sind:

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 FE 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 FE 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 FE erkennt einen IDE-Übertragungsfehler.

DDP_022 Die FE 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 FE einen der vorstehend genannten Fehler, sendet sie keine Antwort und ignoriert die empfangene Nachricht.

DDP_024 Die FE 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 FE dem IDE mit einer Negative Response-Nachricht unter Angabe der Fehlerart.

Abbildung 2 Fehlerbehandlung durch die FE

2. Das IDE erkennt einen FE-Ü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 T2max keine Antwort von der FE erfolgt, wird die Anforderungsnachricht für insgesamt maximal drei Übertragungen erneut gesendet. Zum Zwecke dieser Fehlererkennung wird eine Teilnachrichtquittung als Anforderung an die FE betrachtet.

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

Abbildung 3 Fehlerbehandlung durch das IDE

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.

2.2.6.1. Positive Response Transfer Data Overview

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

2.2.6.2. Positive Response Transfer Data Activities

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

2.2.6.3. Positive Response Transfer Data Events and Faults

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 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

2.2.6.4. Positive Response Transfer Data Detailed Speed

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 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

2.2.6.5. Positive Response Transfer Data Technical Data

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 Hex. Es muss eine geeignete Aufteilung und Zählung der Teilnachrichten erfolgen:

2.3. ESM-Datenspeicherung

DDP_034 War eine FE-Datenübertragung Bestandteil eines Download-Vorgangs, speichert das IDE in einer einzigen physischen Datei alle Daten, die während des Download-Vorgangs von der FE 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 Kontrollgerätkarten

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 Kontrollgerätkarte 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.
• Herunterladen der EF Card_Certificate und CA_Certificate. Diese Informationen sind nicht mit einer digitalen Signatur gesichert. Das Herunterladen dieser Dateien ist bei jedem Download-Vorgang obligatorisch.
• Herunterladen der anderen Anwendungsdaten-EF (innerhalb des DF Tachograph) außer EF Card_Download. Diese Informationen sind mit einer digitalen Signatur gesichert.
  • Bei jedem Download-Vorgang ist zumindest das Herunterladen der EF Application_Identification und ID 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.
• Beim Herunterladen einer Fahrerkarte, wird das Datum LastCard_Download in EF Card_Download aktualisiert.
• Beim Herunterladen einer Werkstattkarte ist der Kalibrierungszähler in der EF Card_Download zurückzusetzen.

3.3.1. Initialisierungssequenz

DDP_036 Das IDE leitet folgende Sequenz ein:

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 und CA_Certificate lautet folgendermaßen:

Anmerkung: Vor Auswahl der EF Card_Certificate muss die Kontrollgerätanwendung ausgewählt werden (Auswahl durch AID).

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:

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

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

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 muss 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.

4. Herunterladen von der Kontrollgerätkarte über eine Fahrzeugeinheit

DDP_047 Die FE 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 FE (siehe 2.2.2.9).

DDP_049 Daraufhin lädt die FE 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 FE gegebenenfalls die Dateien ControlActivityData oder Card_Download der Fahrerkarte.

_________

1) Die eingeführte Karte verschafft die erforderlichen Zugriffsrechte für die Herunterladefunktion und die Daten. Das Herunterladen von Daten von einer in einen der Steckplätze der FE eingeführten Fahrerkarte ist auch möglich, wenn in den anderen Steckplatz keine andere Karte eingeführt ist.

weiter .