zurück

3.5.7 PSO: VERIFY CERTIFICATE

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8, seine Verwendung ist jedoch im Vergleich zu dem in der Norm definierten Befehl eingeschränkt.

Der Befehl VERIFY CERTIFICATE wird von der Karte zur Einholung eines öffentlichen Schlüssels von außen und zur Prüfung seiner Gültigkeit verwendet.

3.5.7.1 Befehl-Antwort-Paar der 1. Generation

TCS_81 Diese Befehlsvariante wird lediglich durch eine Fahrtenschreiberanwendung der 1. Generation unterstützt.

TCS_82 Ist der Befehl VERIFY CERTIFICATE erfolgreich, wird der öffentliche Schlüssel zur künftigen Verwendung in der Sicherheitsumgebung gespeichert. Dieser Schlüssel wird explizit zur Verwendung in sicherheitsbezogenen Befehlen (INTERNAL AUTHENTICATE, EXTERNAL AUTHENTICATE oder VERIFY CERTIFICATE) durch den Befehl MSE (siehe Abschnitt 3.5.11) unter Verwendung seines Schlüsselbezeichners gesetzt.

TCS_83 Auf jeden Fall verwendet der Befehl VERIFY CERTIFICATE den zuvor vom Befehl MSE zur Eröffnung des Zertifikats ausgewählten öffentlichen Schlüssel. Dabei muss es sich um den öffentlichen Schlüssel eines Mitgliedstaates oder Europas handeln.

TCS_84 Befehlsnachricht

TCS_85 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Schlägt die Zertifikatsverifizierung fehl, lautet der zurückgesendete Verarbeitungsstatus '6688'. Das Prüfungs- und Entpackungsverfahren für das Zertifikat wird für G1 und G2 in Anlage 11 beschrieben.
• Ist kein öffentlicher Schlüssel in der Sicherheitsumgebung vorhanden, wird '6A88' zurückgesendet.
• Wird der (zum Entpacken des Zertifikats verwendete) ausgewählte öffentliche Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.
• Nur 1. Generation: Weist der (zum Entpacken des Zertifikats verwendete) öffentliche Schlüssel ein CHA.LSB (CertificateHolderAuthorisation.equipmentType) mit einem anderen Wert als '00' auf (d. h., es ist der Schlüssel eines Mitgliedstaates oder Europas), so lautet der zurückgesendete Verarbeitungsstatus '6985'.

3.5.7.2 Befehl-Antwort-Paar der 2. Generation

Je nach Kurvengröße können ECC-Zertifikate so lang sein, dass sie sich nicht in einem einzigen APDU übermitteln lassen. In einem solchen Fall muss eine Befehlsverkettung gemäß ISO/IEC 7816-4 erfolgen und das Zertifikat in zwei aufeinander folgenden PSO: Verify Certificate APDU-Befehlen übermittelt werden.

Zertifikatstruktur und Domänenparameter werden in Anlage 11 definiert.

TCS_86 Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_87 Befehlsnachricht

TCS_88 Für APDU mit kurzen Längenfeldern gilt Folgendes: Das IFD verwendet die Mindestanzahl an APDU, die erforderlich sind, um die Befehlsdaten zu übermitteln und die Höchstzahl an Bytes im ersten APDU-Befehl zu übermitteln. Es muss jedoch jeder Wert "Lc" bis zu 255 Bytes von der Karte unterstützt werden.

TCS_89 Für APDU mit erweiterten Längenfeldern gilt Folgendes: Passt das Zertifikat nicht in eine einzige APDU, so unterstützt die Karte die Befehlsverkettung. Das IFD verwendet die Mindestanzahl an APDU, die erforderlich sind, um die Befehlsdaten zu übermitteln und die Höchstzahl an Bytes im ersten APDU-Befehl zu übermitteln. Ist eine Verkettung erforderlich, so muss der Wert "Lc" bis zur angegebenen maximalen erweiterten Länge von der Karte unterstützt werden.

Hinweis: Gemäß Anlage 11 speichert die Karte das Zertifikat oder die relevanten Inhalte des Zertifikats und aktualisiert ihren Wert currentAuthenticatedTime.

Struktur und Statusbytes der Antwortnachricht entsprechen der Definition in TCS_85.

TCS_90 Zusätzlich zu den in TCS_85 aufgeführten Fehlercodes kann die Karte die folgenden Fehlercodes zurücksenden:

• Weist der (zum Entpacken des Zertifikats verwendete) ausgewählte öffentliche Schlüssel einen CHA.LSB (Certificate Holder Authorisation.equipment Type) auf, der nicht für die Verifizierung des Zertifikats gemäß Anlage 11 geeignet ist, lautet der zurückgesendete Verarbeitungsstatus '6985'.
• Weist der Wert current AuthenticatedTime der Karte einen späteren Zeitpunkt als das Ablaufdatum des Zertifikats auf, lautet der zurückgesendete Verarbeitungsstatus '6985'.
• Wird der letzte Befehl der Kette erwartet, sendet die Karte '6883' zurück.
• Werden im Befehlsdatenfeld falsche Parameter gesendet, sendet die Karte '6A80' zurück (wird auch verwendet, wenn die Datenobjekte nicht in der festgelegten Reihenfolge gesendet werden).

3.5.8 INTERNAL AUTHENTICATE ¹⁸

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4.

TCS_91 Alle Fahrtenschreiberkarten müssen diesen Befehl in DF Tachograph der 1. Generation verwenden. Der Befehl kann in MF und/oder DF Tachograph_G2 gegebenenfalls zur Verfügung stehen. In einem solchen Fall muss der Befehl mit einem geeigneten Fehlercode enden, da der private Schlüssel der Karte (Card.SK) für das Authentisierungsprotokoll der 1. Generation nur in DF_Tachograph der 1. Generation zugreifbar ist.

Mit Hilfe des Befehls INTERNAL AUTHENTICATE kann das IFD die Karte authentisieren. Der Authentisierungsvorgang wird in Anlage 11 beschrieben. Er beinhaltet folgende Aussagen:

TCS_92 Der Befehl INTERNAL AUTHENTICATE verwendet den (implizit ausgewählten) privaten Kartenschlüssel zum Signieren von Authentisierungsdaten einschließlich K1 (erstes Element für die Sitzungsschlüsselvereinbarung) und RND1 und verwendet den aktuell (durch den letzten MSE-Befehl) ausgewählten öffentlichen Schlüssel zur Verschlüsselung der Signatur und zur Bildung des Authentisierungstokens (nähere Angaben in Anlage 11).

TCS_93 Befehlsnachricht

TCS_94 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Ist in der Sicherheitsumgebung kein öffentlicher Schlüssel vorhanden, lautet der zurückgesendete Verarbeitungsstatus '6A88'.
• Ist in der Sicherheitsumgebung kein privater Schlüssel vorhanden, lautet der zurückgesendete Verarbeitungsstatus '6A88'.
• Stimmt VU.CHR nicht mit dem aktuellen Bezeichner des öffentlichen Schlüssels überein, lautet der zurückgesendete Verarbeitungsstatus '6A88'.
• Wird der ausgewählte private Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.

TCS_95 Ist der Befehl INTERNAL AUTHENTICATE erfolgreich, wird der aktuelle Sitzungsschlüssel der 1. Generation, sofern vorhanden, gelöscht und ist nicht mehr verfügbar. Um einen neuen Sitzungsschlüssel der 1. Generation zur Verfügung zu haben, muss der Befehl EXTERNAL AUTHENTICATE für den Authentisierungsmechanismus der 1. Generation erfolgreich ausgeführt werden.

Hinweis: Für Sitzungsschlüssel der 2. Generation siehe Anlage 11 CSM_193 und CSM_195. Werden Sitzungsschlüssel der 2. Generation erstellt und erhält die Fahrtenschreiberkarte den APDU-Klartextbefehl INTERNAL AUTHENTICATE, bricht sie die Secure-Messaging-Sitzung der 2. Generation ab und vernichtet die Sitzungsschlüssel der 2. Generation.

3.5.9 EXTERNAL AUTHENTICATE ¹⁸

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4.

Mit Hilfe des Befehls EXTERNAL AUTHENTICATE kann die Karte das IFD authentisieren. Das Authentisierungsverfahren wird in Anlage 11 für die Fahrtenschreiber der 1. und 2. Generation beschrieben (VU-Authentisierung).

TCS_96 Die Befehlsvariante für den Mechanismus zur gegenseitigen Authentisierung der 1. Generation wird nur von einer Fahrtenschreiberanwendung der 1. Generation unterstützt.

TCS_97 Die Befehlsvariante für die gegenseitige VU-Karten-Authentisierung der 2. Generation kann in MF, DF Tachograph und DF Tachograph_G2 erfolgen (siehe auch TCS_34). Ist der Befehl EXTERNAL AUTHENTICATE der 2. Generation erfolgreich, wird der aktuelle Sitzungsschlüssel der 1. Generation, sofern vorhanden, gelöscht und ist nicht mehr verfügbar.

Hinweis: Für Sitzungsschlüssel der 2. Generation siehe Anlage 11 CSM_193 und CSM_195. Werden Sitzungsschlüssel der 2. Generation erstellt und erhält die Fahrtenschreiberkarte den APDU-Klartextbefehl EXTERNAL AUTHENTICATE, bricht sie die Secure-Messaging-Sitzung der 2. Generation ab und vernichtet die Sitzungsschlüssel der 2. Generation.

TCS_98 Befehlsnachricht

TCS_99 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Ist die CHA des derzeit gesetzten Schlüssels nicht die Verkettung der AID der Fahrtenschreiberanwendung und eines VU-Gerätetyps, lautet der zurückgesendete Verarbeitungsstatus '6F00'.
• Geht dem Befehl nicht unmittelbar ein GET CHALLENGE-Befehl voraus, lautet der zurückgesendete Verarbeitungsstatus '6985'.

Die Fahrtenschreiberanwendung der 1. Generation kann gegebenenfalls die folgenden Fehlercodes zurücksenden:

• Ist kein öffentlicher Schlüssel in der Sicherheitsumgebung vorhanden, wird '6A88' zurückgesendet.
• Ist in der Sicherheitsumgebung kein privater Schlüssel vorhanden, lautet der zurückgesendete Verarbeitungsstatus '6A88'.
• Schlägt die Prüfung des Kryptogramms fehl, lautet der zurückgesendete Verarbeitungsstatus '6688'.
• Wird der ausgewählte private Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.

Die Befehlsvariante für die Authentisierung der 2. Generation kann gegebenenfalls die folgenden Fehlercodes zurücksenden:

• Schlägt die Verifizierung der Signatur fehl, sendet die Karte '6300' zurück.

3.5.10 GENERAL AUTHENTICATE ¹⁸

Dieser Befehl wird für das Chip-Authentisierungsprotokoll der 2. Generation gemäß Anlage 11 Teil B verwendet und entspricht den Festlegungen von ISO/IEC 7816-4.

TCS_100 Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_101 Befehlsnachricht

TCS_102 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Bei falschen Parametern im Datenfeld sendet die Karte '6A80' zurück.
• Wurde der Befehl External Authenticate nicht erfolgreich ausgeführt, sendet die Karte '6982' zurück.

Das Datenobjekt Dynamic Authentication - 7Chv

• muss bei erfolgreicher Ausführung vorhanden sein, d. h. die Statusbytes lauten '9000',
• muss bei einem Ausführungs- oder Prüffehler fehlen, d. h. wenn die Statusbytes im Bereich '6400' - '6FFF' liegen, und
• muss bei einer Warnung fehlen, d. h. wenn die Statusbytes im Bereich '6200' - '63FF' liegen.

3.5.11 MANAGE SECURITY ENVIRONMENT

Dieser Befehl wird zum Setzen eines öffentlichen Schlüssels zu Authentisierungszwecken verwendet.

3.5.11.1 Befehl-Antwort-Paar der 1. Generation

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-4. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.

TCS_103 Dieser Befehl wird lediglich durch eine Fahrtenschreiberanwendung der 1. Generation unterstützt.

TCS_104 Der Schlüssel, auf den im MSE-Datenfeld verwiesen wird, bleibt der aktuelle öffentliche Schlüssel, bis der nächste korrekte MSE-Befehl eingeht, ein DF ausgewählt wird oder die Karte zurückgesetzt wird.

TCS_105 Ist der Schlüssel, auf den verwiesen wird, (noch) nicht in der Karte vorhanden, bleibt die Sicherheitsumgebung unverändert.

TCS_106 Befehlsnachricht

TCS_107 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Ist der Schlüssel, auf den verwiesen wird, auf der Karte nicht vorhanden, lautet der zurückgesendete Verarbeitungsstatus '6A88'.
• Fehlen einige erwartete Datenobjekte im Secure-Messaging-Format, wird '6987' zurückgesendet. Dies kann der Fall sein, wenn der Tag '83h' fehlt.
• Sind einige Datenobjekte inkorrekt, lautet der zurückgesendete Verarbeitungsstatus '6988'. Dies kann der Fall sein, wenn der Schlüsselbezeichner nicht '08h' ist.
• Wird der ausgewählte Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.

3.5.11.2 Befehl-Antwort-Paare der 2. Generation

Für die Authentisierung der 2. Generation unterstützt die Fahrtenschreiberkarte folgenden MSE: Befehlsvarianten zum Setzen, die den Festlegungen von ISO/IEC 7816-4 entsprechen. Diese Befehlsvarianten werden bei der Authentisierung der 1. Generation nicht unterstützt.

3.5.11.2.1 MSE:SET AT für die Chip-Authentisierung

Mit Hilfe des folgenden Befehls MSE:SET AT werden die Parameter für die Chip-Authentisierung ausgewählt, die durch einen nachfolgenden Befehl General Authenticate durchgeführt wird.

TCS_108 Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_109 MSE:SET AT Befehlsnachricht für die Chip-Authentisierung

3.5.11.2.2 MSE:SET AT für die VU-Authentisierung

Mit Hilfe des folgenden Befehls MSE:SET AT werden die Parameter und Schlüssel für die VU-Authentisierung ausgewählt, die durch einen nachfolgenden Befehl External Authenticate durchgeführt wird.

TCS_110 Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_34.

TCS_111 MSE:SET AT Befehlsnachricht für die VU-Authentisierung

3.5.11.2.3 MSE:SET DST ¹⁸

Der folgende Befehls MSE:SET AT wird verwendet, um einen öffentlichen Schlüssel entweder

• zur Verifizierung einer Signatur, die in einem nachfolgenden Befehl PSO: Verify Digital Signature bereitgestellt wird, oder
• zur Verifizierung der Signatur eines Zertifikats, das in einem nachfolgenden Befehl PSO: Verify Certificate bereitgestellt wird, zu setzen.

TCS_112 Der Befehl kann in MF, DF Tachograph und DF Tachograph_G2 ausgeführt werden, siehe auch TCS_33.

TCS_113 MSE:SET DST Befehlsnachricht

Für sämtliche Befehlsversionen werden Struktur und Statusbytes der Antwortnachricht bereitgestellt durch:

TCS_114 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück. Das Protokoll wurde ausgewählt und initialisiert.
• '6A80' kennzeichnet fehlerhafte Parameter im Befehlsdatenfeld.
• '6A88' gibt an, dass Daten, auf die verwiesen wird (d. h. ein Schlüssel, auf den verwiesen wird), nicht verfügbar sind.
• Weist der Wert current AuthenticatedTime der Karte einen späteren Zeitpunkt als das Ablaufdatum des ausgewählten öffentlichen Schlüssels auf, lautet der zurückgesendete Verarbeitungsstatus '6A88'.

Hinweis: Im Fall eines Befehls MSE:SET AT für die VU-Authentisierung ist der Schlüssel, auf den verwiesen wird, ein öffentlicher VU_MA-Schlüssel. Die Karte legt, falls in ihrem Speicher vorhanden, den öffentlichen VU_MA-Schlüssel für die Nutzung fest, der der im Befehlsdatenfeld angegebenen Referenz des Zertifikatinhabers (Certificate Holder Reference, CHR) entspricht (die Karte kann öffentliche VU_MA-Schlüssel anhand des CHA-Felds des Zertifikats identifizieren). Die Karte sendet '6A 88' auf diesen Befehl zurück, falls nur der öffentliche Schlüssel VU_Sign oder kein öffentlicher Schlüssel der Fahrzeugeinheit verfügbar ist. Siehe die Definition des CHA-Felds in Anlage 11 sowie des Datentyps EquipmentType in Anlage 1.

Ebenso ist der Schlüssel, auf den verwiesen wird, immer ein EQT_Sign-Schlüssel, der für die Verifizierung einer digitalen Signatur zu verwenden ist, wenn ein Befehl MSE: SET DST, der auf ein Gerät (EQT) (d. h. auf eine Fahrzeugeinheit oder Karte) verweist, an eine Kontrollkarte gesendet wird. Nach Anlage 11 Abbildung 13 hat die Kontrollkarte den relevanten öffentlichen Schlüssel EQT_Sign immer gespeichert. In manchen Fällen kann die Kontrollkarte auch den entsprechenden öffentlichen Schlüssel EQT_MA gespeichert haben. Die Kontrollkarte muss den zu verwendenden öffentlichen Schlüssel EQT_Sign immer festlegen, wenn sie einen Befehl MSE: SET DST erhält.

3.5.12 PSO: HASH

Dieser Befehl dient dazu, Ergebnisse der Hashwertberechnung für bestimmte Daten an die Karte zu übertragen. Dieser Befehl wird zur Verifizierung digitaler Signaturen verwendet. Der Hashwert wird temporär gespeichert für den folgenden Befehl PSO: Verify Digital Signature

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.

Nur die Kontrollkarte wird benötigt, um diesen Befehl in DF Tachograph und DF Tachograph_G2 zu unterstützen.

Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Der Befehl kann in MF gegebenenfalls zur Verfügung stehen.

Die Kontrollkartenanwendung der 1. Generation unterstützt nur SHA-1.

TCS_115 Der vorübergehend gespeicherte Hashwert ist zu löschen, wenn mithilfe des Befehls PSO: HASH ein neuer Hashwert berechnet wird, wenn ein DF ausgewählt wird und wenn die Fahrtenschreiberkarte zurückgesetzt wird.

TCS_116 Befehlsnachricht

TCS_117 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Fehlen einige der erwarteten Datenobjekte (siehe oben), wird der Verarbeitungsstatus '6987' zurückgesendet. Dies kann der Fall sein, wenn der Tag '90h' fehlt.
• Sind einige Datenobjekte inkorrekt, lautet der zurückgesendete Verarbeitungsstatus '6988'. Dieser Fehler tritt auf, wenn der erforderliche Tag zwar vorhanden ist, aber eine andere Länge als '14h' für SHA-1, '20h' für SHA-256, '30h' für SHA-384, '40h' für SHA-512 (Anwendung der 2. Generation) aufweist.

3.5.13 PERFORM HASH of FILE ¹⁸

Dieser Befehl entspricht nicht den Festlegungen von ISO/IEC 7816-8. Das CLA-Byte dieses Befehls gibt daher an, dass eine proprietäre Verwendung von PERFORM SECURITY OPERATION/HASH erfolgt.

Nur die Fahrer- und die Werkstattkarte müssen diesen Befehl in DF Tachograph und DF Tachograph_G2 unterstützen.

Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Wenn eine Unternehmens- oder Kontrollkarte diesen Befehl implementiert, muss dies gemäß den Angaben dieses Kapitels erfolgen.

Der Befehl kann in der MF gegebenenfalls zur Verfügung stehen. Wenn ja, muss er gemäß den Angaben dieses Kapitels implementiert werden, d. h. der Befehl darf nicht die Berechnung eines Hashwerts zulassen, sondern muss mit einem geeigneten Fehlercode abschließen.

TCS_118 Der Befehl PERFORM HASH of FILE wird zur Hashwertberechnung des Datenbereichs der zu dem entsprechenden Zeitpunkt ausgewählten transparenten EF verwendet.

TCS_119 Eine Fahrtenschreiberkarte darf diesen Befehl nur für die im Kapitel 4 aufgeführten EF im Rahmen von DF_Tachograph und DF_Tachograph_G2 unterstützen, mit folgender Ausnahme. Eine Fahrtenschreiberkarte darf den Befehl nicht für den EF Sensor_Installation_Data von DF Tachograph_G2 unterstützen.

TCS_120 Das Ergebnis der Hash-Operation wird auf der Karte temporär gespeichert. Es kann dann zur Einholung einer digitalen Signatur der Datei mit Hilfe des Befehls PSO: COMPUTE DIGITAL SIGNATURE verwendet werden.

TCS_121 Der temporär gespeicherte 'hash of file'-Wert ist zu löschen, wenn mithilfe des Befehls PERFORM HASH of FILE ein neuer Hashwert berechnet wird, wenn ein DF ausgewählt wird und wenn die Fahrtenschreiberkarte zurückgesetzt wird.

TCS_122 Die Fahrtenschreiberanwendung der 1. Generation muss SHA-1 unterstützen.

TCS_123 Die Fahrtenschreiberanwendung der 2. Generation muss den Algorithmus SHA-2, SHA-256, SHA-384 oder SHA-512 unterstützen, der durch die Cipher Suite in Anlage 11 Teil B für den Kartensignaturschlüssel Card_Sign spezifiziert wird.

TCS_124 Befehlsnachricht

TCS_125 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Lässt die aktuelle EF diesen Befehl (EF Sensor_Installation_Data in DF Tachograph_G2) nicht zu, wird der Verarbeitungsstatus '6985' zurückgesendet.
• Wird die ausgewählte EF als verfälscht betrachtet (wegen Integritätsfehlern in den Dateiattributen oder den gespeicherten Daten), lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.
• Ist die ausgewählte Datei keine transparente Datei oder gibt es keine aktuelle EF, wird der Verarbeitungsstatus '6986' zurückgesendet.

3.5.14 PSO: COMPUTE DIGITAL SIGNATURE ¹⁸

Dieser Befehl wird zur Berechnung der digitalen Signatur des zuvor berechneten Hashcodes (siehe PERFORM HASH of FILE, Abschnitt 3.5.13) verwendet.

Nur die Fahrer- und die Werkstattkarte müssen diesen Befehl in DF Tachograph und DF Tachograph_G2 unterstützen.

Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Im Falle einer Fahrtenschreiberanwendung der 2. Generation haben nur die Fahrerkarte und die Werkstattkarte einen Signaturschlüssel der 2. Generation, während andere Karten den Befehl nicht erfolgreich ausführen können und mit einem geeigneten Fehlercode abschließen.

Der Befehl kann in MF gegebenenfalls zur Verfügung stehen. Steht der Befehl in MF nicht zur Verfügung, schließt er mit einem geeigneten Fehlercode ab.

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.

TCS_126 Dieser Befehl darf keine digitale Signatur eines zuvor mit dem Befehl PSO: HASH berechneten Hashcodes verarbeiten.

TCS_127 Zur Berechnung der digitalen Signatur wird der private Schlüssel der Karte, der der Karte implizit bekannt ist, herangezogen.

TCS_128 Die Fahrtenschreiberanwendung der 1. Generation führt eine digitale Signatur mit Hilfe einer Auffüllmethode gemäß PKCS1 aus (Einzelheiten siehe Anlage 11).

TCS_129 Die Fahrtenschreiberanwendung der 2. Generation berechnet eine auf elliptischen Kurven basierende digitale Signatur (Einzelheiten siehe Anlage 11).

TCS_130 Befehlsnachricht

TCS_131 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Wird der implizit ausgewählte private Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.
• Ist der in einem vorherigen "Perform Hash of File"-Befehl berechnete Hash nicht verfügbar, wird der Verarbeitungsstatus '6985' zurückgesendet.

3.5.15 PSO: VERIFY DIGITAL SIGNATURE ¹⁸

Dieser Befehl wird zur Verifizierung der als Eingabe bereitgestellten digitalen Signatur verwendet, deren Hash der Karte bekannt ist. Der Signaturalgorithmus ist der Karte implizit bekannt.

Dieser Befehl entspricht den Festlegungen von ISO/IEC 7816-8. Die Verwendung des Befehls ist jedoch im Vergleich zur entsprechenden Norm eingeschränkt.

Nur die Kontrollkarte wird benötigt, um diesen Befehl in DF Tachograph und DF Tachograph_G2 zu unterstützen.

Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren. Der Befehl kann in MF gegebenenfalls zur Verfügung stehen.

TCS_132 Der Befehl VERIFY DIGITAL SIGNATURE verwendet stets den vom vorhergehenden Befehl Manage Security Environment MSE: Set DST ausgewählten öffentlichen Schlüssel sowie den von einem PSO: HASH- Befehl eingegebenen Hashcode.

TCS_133 Befehlsnachricht

TCS_134 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• Schlägt die Verifizierung der Signatur fehl, lautet der zurückgesendete Verarbeitungsstatus '6688'. Der Verifizierungsvorgang wird in Anlage 11 beschrieben.
• Ist kein öffentlicher Schlüssel ausgewählt, lautet der zurückgesendete Verarbeitungsstatus '6A88'.
• Fehlen einige der erwarteten Datenobjekte (siehe oben), wird der Verarbeitungsstatus '6987' zurückgesendet. Das kann der Fall sein, wenn der erforderliche Tag fehlt.
• Ist kein Hash-Code zur Verarbeitung des Befehls verfügbar (im Ergebnis eines PSO: Hash-Befehls), lautet der zurückgesendete Verarbeitungsstatus '6985'.
• Sind einige Datenobjekte inkorrekt, lautet der zurückgesendete Verarbeitungsstatus '6988'. Dies kann der Fall sein, wenn eine Länge der erforderlichen Datenobjekte inkorrekt ist.
• Wird der ausgewählte öffentliche Schlüssel als verfälscht betrachtet, lautet der zurückgesendete Verarbeitungsstatus '6400' oder '6581'.
• Weist der (zur Verifizierung der digitalen Signatur verwendete) ausgewählte öffentliche Schlüssel einen CHA.LSB (Certificate Holder Authorisation.equipment Type) auf, der nicht für die Verifizierung der digitalen Signatur gemäß Anlage 11 geeignet ist, lautet der zurückgesendete Verarbeitungsstatus '6985'.

3.5.16 PROCESS DSRC MESSAGE ¹⁸

Dieser Befehl wird verwendet, um die Integrität und Authentizität der DSRC-Nachricht zu verifizieren und um die von einer VU per DSRC-Link an eine Kontrollbehörde oder eine Werkstatt gesendeten Daten zu entschlüsseln. Die Karte leitet den zur Sicherung der DSRC-Nachricht gemäß Anlage 11 Teil B Kapitel 13 verwendeten Kodierungsschlüssel samt MAC-Schlüssel ab.

Nur die Kontroll- und die Werkstattkarte müssen diesen Befehl in DF Tachograph_G2 unterstützen.

Andere Arten von Fahrtenschreiberkarten können diesen Befehl gegebenenfalls implementieren, dürfen aber nicht über einen DSRC-Hauptschlüssel verfügen. Aus diesem Grund können diese Karten den Befehl nicht erfolgreich ausführen, sondern schließen mit einem geeigneten Fehlercode ab.

Der Befehl kann in MF und/oder DF Tachograph gegebenenfalls zur Verfügung stehen. Wenn ja, muss der Befehl mit einem geeigneten Fehlercode abschließen.

TCS_135 Der DSRC-Hauptschlüssel ist nur in DF Tachograph_G2 zugreifbar, d. h. Kontroll- und Werkstattkarte unterstützen die erfolgreiche Ausführung des Befehls lediglich in DF Tachograph_G2.

TCS_136 Der Befehl darf lediglich die DSRC-Daten entschlüsseln und die kryptografische Prüfsumme verifizieren, nicht aber die Eingabedaten interpretieren.

TCS_137 Die Reihenfolge der Datenobjekte im Befehlsdatenfeld ist durch diese Spezifikation festgelegt.

TCS_138 Befehlsnachricht

TCS_139 Antwortnachricht

• Ist der Befehl erfolgreich, sendet die Karte '9000' zurück.
• '6A80' gibt fehlerhafte Parameter im Befehlsdatenfeld an (auch verwendet, wenn die Datenobjekte nicht in der angegebenen Reihenfolge gesendet werden).
• '6A88' gibt an, dass Daten, auf die verwiesen wird, nicht verfügbar sind (d. h. der DSRC-Hauptschlüssel, auf den verwiesen wird, ist nicht verfügbar).
• '6900' gibt an, dass die Verifizierung der kryptografischen Prüfsumme oder die Entschlüsselung der Daten fehlgeschlagen ist.
• '6985' gibt an, dass der 4-Byte-Zeitstempel im Befehlsdatenfeld vor dem Zeitpunkt cardValidityBegin oder nach dem cardExpiryDate liegt.

4. Struktur der Fahrtenschreiberkarten

In diesem Abschnitt werden die Dateistrukturen, die auf den Fahrtenschreiberkarten der Speicherung zugänglicher Daten dienen, spezifiziert.

Nicht spezifiziert werden vom Kartenhersteller abhängige interne Strukturen, wie z.B. Dateianfangskennsätze oder die Speicherung und Verarbeitung von Datenelementen, die nur für den internen Gebrauch benötigt werden, z.B.

TCS_140 Eine Fahrtenschreiberkarte der 2. Generation muss das Wurzelverzeichnis (MF) und eine Fahrtenschreiberanwendung gleichen Typs der 1. und 2. Generation aufnehmen (z.B. Fahrerkartenanwendungen).

TCS_141 Eine Fahrtenschreiberkarte muss zumindest die Mindestzahl der für die entsprechenden Anwendungen angegebenen Datensätze unterstützen und darf nicht mehr als die Höchstzahl der für die entsprechenden Anwendungen angegebenen Datensätze unterstützen.

Die Höchst- und die Mindestzahl an Datensätzen sind in diesem Kapitel für die unterschiedlichen Anwendungen angegeben. In Version 2 von Fahrer- und Werkstattkarten der 2. Generation muss die Anwendung der 1. Generation die Höchstzahl der Datensätze gemäß TCS_150 und TCS_158 unterstützen.

Zu den Sicherheitsbedingungen, die in den in diesem Kapitel verwendeten Zugriffsregeln verwendet werden, siehe Kapitel 3.3. Generell bezeichnet der Zugriffsmodus "Lesen" den Befehl READ BINARY mit geradem und bei entsprechender Unterstützung mit ungeradem INS-Byte, ausgenommen die EF Sensor_Installation_Data auf der Werkstattkarte, siehe TCS_156 und TCS_160. Der Zugriffsmodus "Aktualisieren" bezeichnet den Befehl Update Binary mit geraden und bei entsprechender Unterstützung mit ungeradem INS-Byte und der Zugriffsmodus "Auswählen" den Befehl SELECT.

4.1. Wurzelverzeichnis (MF)

TCS_142 Nach der Personalisierung weist das Wurzelverzeichnis (MF) folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweis: Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.

In dieser Tabelle wird die folgende Abkürzung für die Sicherheitsbedingung verwendet:

SC1 ALW ODER SM-MAC-G2

TCS_143 Die Strukturen aller EF sind transparent.

TCS_144 Das Wurzelverzeichnis (MF) hat folgende Datenstruktur:

TCS_145 Die Elementardatei EF DIR muss die folgenden anwendungsbezogenen Datenobjekte enthalten: '61 08 4F 06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54'

TCS_146 Die Elementardatei EF ATR/INFO muss vorhanden sein, wenn die Fahrtenschreiberkarte in ihrer ATR angibt, dass sie erweiterte Längenfelder unterstützt. In diesem Fall muss EF ATR/INFO das Datenobjekt mit der erweiterten Längenangabe (DO'7F66') gemäß ISO/IEC 7816-4:2013 Punkt 12.7.1 enthalten.

TCS_147 Die Elementardatei EF Extended_Length muss vorhanden sein, wenn die Fahrtenschreiberkarte in ihrer ATR angibt, dass sie erweiterte Längenfelder unterstützt. In diesem Fall muss die Elementardatei das folgende Datenobjekt enthalten: '02 01 xx', wobei der Wert 'xx' angibt, ob erweiterte Längenfelder für das Protokoll T = 1 und/oder T = 0 unterstützt werden.

Der Wert '01' zeigt die Unterstützung erweiterter Längenfelder für das Protokoll T = 1 an.

Der Wert '10' zeigt die Unterstützung erweiterter Längenfelder für das Protokoll T = 0 an.

Der Wert '11' zeigt die Unterstützung erweiterter Längenfelder für das Protokoll T = 1 und T = 0 an.

4.2. Fahrerkartenanwendungen

4.2.1 Fahrerkartenanwendung der 1. Generation

TCS_148 Nach der Personalisierung weist die Fahrerkartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1 ALW ODER SM-MAC-G2

SC2 ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3 SM-MAC-G1 ODER SM-MAC-G2

TCS_149 Die Strukturen aller EF sind transparent.

TCS_150 Die Fahrerkartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_151 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Fahrerkarte für eine Anwendung der 1. Generation verwenden muss:

4.2.2 Fahrerkartenanwendung der 2. Generation ¹⁸

TCS_152 Nach der Personalisierung weist die Fahrerkartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweise:

• Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.
• EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration und EF Load_Type_Entries sind nur in Version 2 der Fahrerkarte der 2. Generation vorhanden.
• cardStructureVersion in EF Application_Identification ist für Version 2 der Fahrerkarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Fahrerkarte der 2. Generation gleich {01 00} war.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

TCS_153 Die Strukturen aller EF sind transparent.

TCS_154 Die Fahrerkartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_155 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Fahrerkarte für eine Anwendung der 2. Generation verwenden muss:

4.3. Werkstattkartenanwendungen

4.3.1 Werkstattkartenanwendung der 1. Generation ¹⁸

TCS_156 Nach der Personalisierung weist die Werkstattkartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

TCS_157 Die Strukturen aller EF sind transparent.

TCS_158 Die Werkstattkartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_159 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Werkstattkarte für eine Anwendung der 1. Generation verwenden muss:

4.3.2 Werkstattkartenanwendung der 2. Generation ¹⁸

TCS_160 Nach der Personalisierung weist die Werkstattkartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweise:

• Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.
• EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration und EF Calibration_Add_Data sind nur in Version 2 der Werkstattkarte der 2. Generation vorhanden.
• cardStructureVersion in EF Application_Identification ist für Version 2 der Werkstattkarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Werkstattkarte der 2. Generation gleich {01 00} ist.

d dieser Wert für Version 1 der Werkstattkarte der 2. Generation gleich {01 00} ist.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

TCS_161 Die Strukturen aller EF sind transparent.

TCS_162 Die Werkstattkartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_163 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Werkstattkarte für eine Anwendung der 2. Generation verwenden muss:

4.4. Kontrollkartenanwendungen

4.4.1 Kontrollkartenanwendung der 1. Generation

TCS_164 Nach der Personalisierung weist die Kontrollkartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1 ALW ODER SM-MAC-G2

SC2 ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3 SM-MAC-G1 ODER SM-MAC-G2

SC6 EXT-AUT-G1 ODER SM-MAC-G1 ODER SM-MAC-G2

TCS_165 Die Strukturen aller EF sind transparent.

TCS_166 Die Kontrollkartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_167 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Kontrollkarte für eine Anwendung der 1. Generation verwenden muss:

4.4.2 Kontrollkartenanwendung der 2. Generation

TCS_168 Nach der Personalisierung weist die Kontrollkartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf.

Hinweise:

• Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.
• EF Application_Identification_V2 und EF VU_Configuration sind nur in Version 2 der Kontrollkarte der 2. Generation vorhanden.
• cardStructureVersion in EF Application_Identification ist für Version 2 der Kontrollkarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Kontrollkarte der 2. Generation gleich {01 00} war.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

TCS_169 Die Strukturen aller EF sind transparent.

TCS_170 Die Kontrollkartenanwendung der 2. Generation hat folgende Datenstruktur:

"

TCS_171 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Kontrollkarte für eine Anwendung der 2. Generation verwenden muss:

4.5. Unternehmenskartenanwendungen

4.5.1 Unternehmenskartenanwendung der 1. Generation

TCS_172 Nach der Personalisierung weist die Unternehmenskartenanwendung der 1. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

SC1 ALW ODER SM-MAC-G2

SC2 ALW ODER SM-MAC-G1 ODER SM-MAC-G2

SC3 SM-MAC-G1 ODER SM-MAC-G2

SC6 EXT-AUT-G1 ODER SM-MAC-G1 ODER SM-MAC-G2

TCS_173 Die Strukturen aller EF sind transparent.

TCS_174 Die Unternehmenskartenanwendung der 1. Generation hat folgende Datenstruktur:

TCS_175 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Unternehmenskarte für eine Anwendung der 1. Generation verwenden muss:

4.5.2 Unternehmenskartenanwendung der 2. Generation

TCS_176 Nach der Personalisierung weist die Unternehmenskartenanwendung der 2. Generation folgende permanente Dateistruktur und Dateizugriffsregeln auf:

Hinweise:

• Die Kurz-Elementardateikennung SFID wird als Dezimalzahl ausgedrückt; beispielsweise entspricht der Wert 30 dem Binärwert 11110.
• EF Application_Identification_V2 und EF VU_Configuration sind nur in Version 2 der Unternehmenskarte der 2. Generation vorhanden.
• cardStructureVersion in EF Application_Identification ist für Version 2 der Unternehmenskarte der 2. Generation gleich {01 01}, während dieser Wert für Version 1 der Unternehmenskarte der 2. Generation gleich {01 00} war.

In dieser Tabelle werden die folgenden Abkürzungen für die Sicherheitsbedingung verwendet:

TCS_177 Die Strukturen aller EF sind transparent.

TCS_178 Die Unternehmenskartenanwendung der 2. Generation hat folgende Datenstruktur:

TCS_179 Die folgenden, in der vorstehenden Tabelle zur Größenangabe herangezogenen Werte sind die Mindest- und die Höchstwerte für die Anzahl der Datensätze, die die Datenstruktur der Unternehmenskarte für eine Anwendung der 2. Generation verwenden muss:

.

PIC_001 Vom Fahrtenschreiber können fakultativ folgende Piktogramme und Piktogrammkombinationen (oder Piktogramme und Kombinationen, die hinreichend ähnlich sind, um eindeutig als diese erkannt zu werden) verwendet werden:

1. Einzelpiktogramme

2. Piktogrammkombinationen ¹⁸

Anmerkung: Weitere Piktogrammkombinationen als Block- oder Datensatzbezeichner auf Ausdrucken sind in Anlage 4 festgelegt.

.

1. Allgemeines

Jeder Ausdruck besteht aus einer Aneinanderreihung verschiedener Datenblöcke, die durch einen Blockbezeichner ausgewiesen werden können.

Ein Datenblock enthält einen oder mehrere Datensätze, die durch einen Datensatzbezeichner ausgewiesen werden können.

PRT_001 Steht ein Blockbezeichner unmittelbar vor einem Datensatzbezeichner, wird der Datensatzbezeichner nicht gedruckt.

PRT_002 Ist eine Datenangabe unbekannt oder darf aus datenzugriffsrechtlichen Gründen nicht gedruckt werden, werden stattdessen Leerzeichen ausgedruckt.

PRT_003 Ist der Inhalt einer ganzen Zeile unbekannt oder braucht nicht gedruckt zu werden, wird die gesamte Zeile weggelassen.

PRT_004 Nummerische Datenfelder werden rechtsbündig, mit einer Leerstelle zur Abtrennung von Tausendern und Millionen und ohne Führungsnullen gedruckt.

PRT_005 Datenfelder mit Zeichenfolgen werden linksbündig gedruckt und nach Bedarf bis zur Datenelementlänge mit Leerzeichen aufgefüllt oder auf Datenelementlänge abgeschnitten. Namen und Anschriften können in zwei Zeilen gedruckt werden.

PRT_006 Bei einem Zeilenumbruch aufgrund eines langen Textes muss die neue Zeile mit einem Sonderzeichen (Punkt auf Mitte der Zeilenhöhe, "•") beginnen.

2. Spezifikation der Datenblöcke ¹⁸

In diesem Kapitel wurden folgende Konventionen für die Notation verwendet:

• Zeichen in Fettdruck stehen für zu druckenden Klartext (im Ausdruck erscheinen die Zeichen unformatiert).
• Unformatierte Zeichen stehen für Variablen (Piktogramme oder Daten), die beim Ausdrucken durch ihre Werte ersetzt werden.
• Bezeichnungen von Variablen wurden mit Unterstrichen ergänzt, um die für die Variable verfügbare Datenelementlänge sichtbar zu machen.
• Datumsangaben sind im Format "TT/MM/JJJJ" (Tag, Monat, Jahr) spezifiziert. Verwendet werden kann auch das Format "TT.MM.JJJJ".
• Die "Kartenkennung" setzt sich aus folgenden Elementen zusammen: Angabe der Kartenart durch entsprechende Piktogrammkombination, Code des ausstellenden Mitgliedstaates, Schrägstrich und Kartennummer mit durch Leerstelle abgetrenntem Ersatzindex und Erneuerungsindex:

• In einem Datenblock bezieht sich der Text nach "pi ="auf das entsprechende Piktogramm oder die entsprechende Piktogrammkombination gemäß Anlage 3.
• Wenn das Piktogramm nach dem Längen- und Breitengrad einer aufgezeichneten Position oder nach dem Zeitstempel des Zeitpunkts der Positionsbestimmung gedruckt wurde, gibt dieses Piktogramm an, dass diese Position aus authentisierten Navigationsmeldungen berechnet wurde.
• * Daten nur in GEN2-Fahrtenschreibern verfügbar (alle Versionen),
• ** Daten nur in GEN2-Fahrtenschreibern Version 2 verfügbar.

PRT_007 Ausdrucke verwenden die folgenden Datenblöcke und/oder Datensätze in der jeweiligen Bedeutung und Form:

3. Spezifikation der Ausdrucke

In diesem Kapitel werden die folgenden Konventionen für die Notation verwendet:

3.1. Tagesausdruck Fahrertätigkeiten von der Karte ¹⁸

PRT_008 Der tägliche Ausdruck Fahrertätigkeiten von der Karte hat folgendes Format:

3.2. Tagesausdruck Fahrertätigkeiten von der Fahrzeugeinheit (VU) ¹⁸

PRT_009 Der Tagesausdruck Fahrertätigkeiten von der VU hat folgendes Format:

3.3. Ausdruck Ereignisse und Störungen von der Karte

PRT_010 Der Ausdruck Ereignisse und Störungen von der Karte hat folgendes Format:

3.4. Ausdruck Ereignisse und Störungen von der VU

PRT_011 Der Ausdruck Ereignisse und Störungen von der VU hat folgendes Format:

3.5. Ausdruck Technische Daten

PRT_012 Der Ausdruck Technische Daten hat folgendes Format:

3.6. Ausdruck Geschwindigkeitsüberschreitung

PRT_013 Der Ausdruck Geschwindigkeitsüberschreitung hat folgendes Format:

3.7. Historie der eingesteckten Karten ¹⁸

PRT_014 Der Ausdruck Historie der eingesteckten Karten 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 den Fahrtenschreiber erfolgt in folgendem Format:

.

1. Hardware

1.1. Steckanschluss

INT_001 Das Herunterladen/Kalibrieren erfolgt über eine sechspolige Steckverbindung, die an der Frontplatte zugänglich ist, ohne dass ein Teil des Fahrtenschreibers 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, Erste Ausgabe: 1999.

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

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

.

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.

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 Notationen

In dieser Anlage werden folgende Akronyme verwendet:

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

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:

wird übertragen als:

...

oder als:

...

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.

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 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 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:

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:

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:

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

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.

Abbildung 2 Fehlerbehandlung durch die VU

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.

Abbildung 3 Fehlerbehandlung durch das DIE

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 "... Record Array" (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)

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)

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

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

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)

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

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

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)

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

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

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)

Datenstruktur der 2. Generation (TREP 24 Hex)

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)

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

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

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

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:

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:

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:

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 NoOfCalibrationsSinceDownload in der EF Card_Download auf einer Werkstattkarte lautet folgendermaßen:

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.

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

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 Control_Activity_Data oder Card_Download der Fahrerkarte.

______
*) Die eingesetzte Karte löst die erforderlichen Zugriffsrechte für die Herunterladefunktion und die Daten aus. Das Herunterladen von Daten von einer in einen der Steckplätze der VU eingeführten Fahrerkarte ist auch möglich, wenn in den anderen Steckplatz kein anderer Kartentyp eingeführt ist.

.

1. Einleitung

In dieser Anlage wird der Datenaustausch zwischen einer Fahrzeugeinheit und einem Prüfgerät über die K-Leitung, die Teil der in Anlage 6 beschriebenen Kalibrierungsschnittstelle ist, beschrieben. Außerdem enthält sie eine Beschreibung der Steuerung der Eingangs-/Ausgangssignalleitung am Kalibrierungsanschluss.

Das Aufbauen der K-Leitungskommunikation wird im Abschnitt 4 "Kommunikationsdienste" beschrieben.

In dieser Anlage ist vom Konzept der Diagnosevorgänge die Rede, mit dem der Umfang der K-Leitungssteuerung unter verschiedenen Bedingungen festgelegt wird. Der Standardvorgang ist dabei die "StandardDiagnosticSession", bei der aus einer Fahrzeugeinheit alle Daten ausgelesen, jedoch keine Daten in die Fahrzeugeinheit geschrieben werden können.

Die Auswahl des Diagnosevorgangs wird im Abschnitt 5 "Verwaltungsdienste" beschrieben.

Dieser Anhang gilt als relevant für beide Generationen von VU- und Werkstattkarten gemäß den in dieser Verordnung beschriebenen Interoperabilitätsanforderungen.

CPR_001 Im Programmiervorgang "ECUProgrammingSession" ist es möglich, Daten in die Fahrzeugeinheit einzugeben. Bei der Eingabe von Kalibrierungsdaten muss sich die Fahrzeugeinheit außerdem in der Betriebsart KALIBRIERUNG befinden.

Die Datenübertragung über die K-Leitung wird im Abschnitt 6 "Datenübertragungsdienste" beschrieben. Die Formate der übertragenen Daten werden in Abschnitt 8 "dataRecords-Formate" erläutert.

CPR_002 Der Einstellvorgang "ECUAdjustmentSession" ermöglicht die Auswahl der E/A-Betriebsart der Kalibrierungs-E/A-Signalleitung über die Schnittstelle der K-Leitung. Die Steuerung der Kalibrierungs-E/A-Signalleitung wird in Abschnitt 7 "Prüfimpulssteuerung - Funktionseinheit Eingabe/Ausgabe-Steuerung" beschrieben.

CPR_003 Im vorliegenden Dokument wird als Adresse für das Prüfgerät durchgängig 'tt' verwendet. Ungeachtet dessen, dass für Prüfgeräte bevorzugte Adressen verwendet werden können, muss die VU auf jede Prüfgerätadresse richtig antworten. Die physische Adresse der VU ist 0xEE.

2. Begriffe, Begriffsbestimmungen und Referenzdokumente ¹⁸

Die Protokolle, Nachrichten und Fehlercodes beruhen grundsätzlich auf einem Normentwurf von ISO 14229-1 (Road vehicles - Diagnostic systems - Part 1: Diagnostic services, Version 6 vom 22. Februar 2001).

Für die Service Identifier (SID), die Bedienanforderungen und -antworten sowie die Standardparameter werden Byte-Codierungen und hexadezimale Werte verwendet.

Der Begriff "Prüfgerät" bezeichnet das zur Eingabe der Programmierungs-/Kalibrierungsdaten in die VU verwendete Gerät.

Die Begriffe "Client" und "Server" beziehen sich auf das Prüfgerät bzw. die VU.

Der Begriff "ECU" bedeutet "elektronische Steuereinheit" und bezieht sich auf die VU.

Referenzdokumente:

ISO 14230-2: Road Vehicles - Diagnostic Systems - Keyword Protocol 2000 - Part 2: Data Link Layer.

First edition: 1999.

3. Diensteübersicht

3.1. Verfügbare Dienste

Die folgende Tabelle gibt einen Überblick über die in dieser Anlage beschriebenen Dienste, die im Fahrtenschreiber verfügbar sein werden.

CPR_004 In der Tabelle sind die Dienste aufgeführt, die bei aktiviertem Diagnosevorgang verfügbar sind.

• Spalte 1 enthält die verfügbaren Dienste.
• Spalte 2 nennt den Abschnitt in der vorliegenden Anlage, in der der Dienst näher beschrieben wird.
• Spalte 3 ordnet die Service-Identifier-Werte bei Anforderungsnachrichten zu.
• Spalte 4 gibt die Dienste des Standardvorgangs"StandardDiagnosticSession" (SD) an, die in jeder VU implementiert sein müssen.
• Spalte 5 gibt die Dienste des Einstellvorgangs "ECUAdjustmentSession" (ECUAS) an, die implementiert sein müssen, um die Steuerung der E/A-Signalleitung der für die Kalibrierung vorgesehenen Steckverbindung an der Frontplatte der VU zu gestatten.
• Spalte 6 gibt die Dienste des Programmiervorgangs "ECUProgrammingSession" (ECUPS) an, die implementiert sein müssen, um die Programmierung von Parametern in der VU zu ermöglichen.

Tabelle 1 Übersicht über die SId-Werte

			Diagnosevorgänge
Name des Diagnosedienstes	Abschnitt Nr.	Wert SId Req.	SD	ECUAS	ECUPS
Start Communication	4.1	81
StopCommunication	4.2	82
TesterPresent	4.3	3E
StartDiagnosticSession	5.1	10
SecurityAccess	5.2	27
ReadDataByIdentifier	6.1	22
WriteDataByIdentifier	6.2	2E
InputOutputControlByIdentifier	7.1	2F
RoutineControl	8	31
Dieses Symbol zeigt an, dass der betreffende Dienst bei diesem Diagnosevorgang obligatorisch ist. Ein Feld ohne Symbol bedeutet, dass der betreffende Dienst bei diesem Diagnosevorgang nicht zugelassen ist.

3.2. Antwortcodes

Für jeden Dienst sind Antwortcodes festgelegt.

4. Kommunikationsdienste

Um die Kommunikation aufzubauen und aufrecht zu erhalten, sind einige Dienste erforderlich, die nicht auf der Anwendungsschicht liegen. Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle aufgeführt:

Tabelle 2: Kommunikationsdienste

CPR_005 Der Dienst Start Communication wird genutzt, um eine Kommunikation einzuleiten. Für die Ausführung eines Dienstes ist es immer erforderlich, dass die Kommunikation initialisiert und die für die gewünschte Betriebsart geeigneten Kommunikationsparameter verwendet werden.

4.1. Der Dienst Start Communication

CPR_006 Bei Erhalt eines Start Communication-Primitivs prüft die VU, ob die angeforderte Kommunikationsverbindung unter den gegebenen Bedingungen initialisiert werden kann. Gültige Bedingungen für die Initialisierung einer Kommunikationsverbindung sind im Dokument ISO 14230-2 beschrieben.

CPR_007 Die VU führt daraufhin alle erforderlichen Maßnahmen zur Initialisierung der Kommunikationsverbindung aus und versendet ein Start Communication-Antwort-Primitiv mit den gewählten Positive Response-Parametern.

CPR_008 Erhält eine bereits initialisierte (und in eine Diagnosesitzung eingetretene) VU die Anforderung Start Communication (z.B. aufgrund Wiederanlauf des Prüfgeräts nach einer Fehlerbedingung), muss die Anforderung angenommen und die VU neu initialisiert werden.

CPR_009 Falls sich die Kommunikationsverbindung aus irgendeinem Grund nicht initialisieren lässt, setzt die VU den Betrieb in der gleichen Weise wie unmittelbar vor dem Versuch zur Initialisierung der Kommunikationsverbindung fort.

CPR_010 Die Anforderungsnachricht Start Communication muss an eine physische Adresse erfolgen.

CPR_011 Die Initialisierung der VU für Dienste erfolgt mithilfe einer "Schnellinitialisierung":

• Jeder Aktivität geht ein Bus-Ruhezustandstakt voraus.
• Das Prüfgerät überträgt anschließend eine Initialisierungssequenz.
• Alle zum Aufbau der Kommunikation benötigten Informationen sind in der Antwort der VU enthalten.

CPR_012 Nach Beendigung der Initialisierung:

• Alle Kommunikationsparameter werden entsprechend den Schlüssel-Bytes auf die Werte in Tabelle 4 gesetzt.
• Die VU wartet auf die erste Anforderung vom Prüfgerät.
• Die VU befindet sich in der Standarddiagnosebetriebsart, d. h. der "StandardDiagnosticSession".
• Die Kalibrierungs-E/A-Signalleitung befindet sich im Standardzustand, d. h. im deaktivierten Zustand.

CPR_014 Die Übertragungsgeschwindigkeit (Baudrate) auf der K-Leitung beträgt 10.400 Baud.

CPR_016 Die Schnellinitialisierung wird ausgelöst, indem das Prüfgerät eine Wake-Up-Sequenz (Wup) auf der K-Leitung überträgt. Diese beginnt nach dem Ruhezustandstakt auf der K-Leitung mit einem L-Takt TInil. Das Prüfgerät sendet das erste Bit des Dienstes Start Communication im Anschluss an einen TWup-Takt, der nach der ersten fallenden Flanke beginnt.

CPR_017 Die Taktwerte für die Schnellinitialisierung sowie für die Kommunikation generell sind in den nachstehenden Tabellen im Einzelnen aufgeführt. Für den Ruhezustandstakt existieren mehrere Möglichkeiten:

• Erste Übertragung nach Einschalten, Tidle = 300 ms.
• Nach Abschluss eines Dienstes StopCommunication, Tidle = P3 Minimum
• Nach Beendigung der Kommunikation durch Zeitüberschreitung (Time-Out) P3 Maximum, Tidle = 0.

Tabelle 3: Taktwerte zur Schnellinitialisierung

Tabelle 4: Taktwerte für die Kommunikation

CPR_018 Das Nachrichtenformat für die Schnellinitialisierung ist in den nachstehenden Tabellen spezifiziert.

Tabelle 5: Nachricht Start Communication Request

Tabelle 6: Nachricht Start Communication Positive Response

CPR_019 Eine negative Antwort (Negative Response) auf die Anforderungsnachricht Start Communication gibt es nicht. Kann keine positive Nachricht (Positive Response) gegeben werden, so erfolgt keine Initialisierung der VU, und diese verbleibt in ihrer normalen Betriebsart.

4.2. Der Dienst StopCommunication

4.2.1 Beschreibung der Nachricht

Dieser Dienst der Kommunikationssteuerungsschicht hat zum Zweck, einen Kommunikationsvorgang zu beenden.

CPR_020 Bei Erhalt eines StopCommunication-Primitivs prüft die VU, ob die derzeitigen Bedingungen die Beendigung dieser Kommunikation gestatten. Ist dies der Fall, so führt die VU alle erforderlichen Maßnahmen zur Beendigung dieser Kommunikation durch.

CPR_021 Ist die Beendigung der Kommunikation möglich, gibt die VU vor der Beendigung der Kommunikation ein StopCommunication-Antwort-Primitiv mit den gewählten Positive Response-Parametern aus.

CPR_022 Falls sich die Kommunikation aus irgendeinem Grund nicht beenden lässt, gibt die VU ein StopCommunication-Antwort-Primitiv mit den gewählten Parametern für Negative Response aus.

CPR_023 Wird von der VU eine Zeitüberschreitung aufgrund P3max erkannt, muss die Kommunikation ohne Ausgabe eines Antwortelements beendet werden.

4.2.2 Nachrichtenformat

CPR_024 Die Nachrichtenformate für die StopCommunication-Primitive sind in den folgenden Tabellen aufgeführt.

Tabelle 7: Nachricht StopCommunication Request

Tabelle 8: Nachricht StopCommunication Positive Response

Tabelle 9: Nachricht StopCommunication Negative Response

4.2.3 Parameterdefinition

Dieser Dienst erfordert keine Parameterdefinition.

4.3. Der Dienst TesterPresent

4.3.1 Beschreibung der Nachricht

Mithilfe des Dienstes TesterPresent teilt das Prüfgerät dem Server mit, dass es sich noch immer in einer aktiven Verbindung mit ihm befindet, um zu verhindern, dass der Server automatisch in die normale Betriebsart zurückkehrt und dadurch möglicherweise die Verbindung beendet. Dieser Dienst sorgt durch regelmäßiges Aussenden einer Anforderung dafür, dass die Diagnosesitzung oder Verbindung aktiv bleibt, indem der P3-Zeitgeber bei jedem Erhalt einer Anforderung für diesen Dienst zurückgesetzt wird.

4.3.2 Nachrichtenformat

CPR_079 Die Nachrichtenformate für die TesterPresent-Primitive sind in den folgenden Tabellen aufgeführt.

Tabelle 10: Nachricht TesterPresent Request

CPR_080 Ist der Parameter response Required auf "yes" gesetzt, so antwortet der Server mit folgenden positiven Antwortnachrichten. Ist der Parameter auf "no" gesetzt, sendet der Server keine Antwort.

Tabelle 11: Nachricht TesterPresent Positive Response

CPR_081 Der Dienst verwendet die folgenden negativen Antwort-Codes:

Tabelle 12: Nachricht TesterPresent Negative Response

5. Verwaltungsdienste

Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle aufgeführt:

Tabelle 13: Verwaltungsdienste

5.1. Der Dienst StartDiagnosticSession

5.1.1 Beschreibung der Nachricht

CPR_025 Der Dienst StartDiagnosticSession dient dazu, verschiedene Diagnosevorgänge im Server zu aktivieren. Ein Diagnosevorgang aktiviert bestimmte Dienste nach Maßgabe von Tabelle 17. Mit einem solchen Vorgang kann der Fahrzeughersteller bestimmte Dienste aktivieren, die hier nicht beschrieben werden. Die Implementierungsregeln haben folgenden Festlegungen zu entsprechen:

• Es ist stets genau ein Diagnosevorgang in der VU aktiv.
• Die VU startet die "StandardDiagnosticSession" bei jedem Einschaltvorgang. Wird kein anderer Diagnosevorgang gestartet, so läuft die "StandardDiagnosticSession" so lange, wie die VU eingeschaltet ist.
• Wird vom Prüfgerät ein bereits laufender Diagnosevorgang angefordert, sendet die VU eine positive Antwortnachricht (Positive Response).
• Fordert das Prüfgerät einen neuen Diagnosevorgang an, sendet die VU zuerst eine positive Antwortnachricht auf "StartDiagnosticSession", bevor der neue Diagnosevorgang in der VU aktiviert wird. Kann die VU den angeforderten neuen Diagnosevorgang nicht starten, antwortet sie mit einer negativen Antwortnachricht auf StartDiagnosticSession und setzt den laufenden Diagnosevorgang fort.

CPR_026 Ein Diagnosevorgang darf erst begonnen werden, wenn die Nachrichtenverbindung zwischen dem Client und der VU errichtet wurde.

CPR_027 Nach einer erfolgreichen Anforderung StartDiagnosticSession sind die in Tabelle 4 aufgeführten Taktparameter aktiv, wobei der Parameter diagnostic Session in der Anforderungsnachricht auf "Standard Session" gesetzt ist, wenn zuvor ein anderer Diagnosevorgang aktiv war.

5.1.2 Nachrichtenformat

CPR_028 Die Nachrichtenformate für die StartDiagnosticSession-Primitive sind in den folgenden Tabellen spezifiziert.

Tabelle 14: Nachricht StartDiagnosticSession Request

Tabelle 15: Nachricht StartDiagnosticSession Positive Response

Tabelle 16: Nachricht StartDiagnosticSession Negative Response

5.1.3 Parameterdefinition

CPR_029 Der Parameter diagnosticSession (DS_) dient dem Dienst StartDiagnosticSession dazu, das spezielle Verhalten des Servers bzw. der Server zu wählen. Im vorliegenden Dokument sind folgende Diagnosevorgänge spezifiziert:

Tabelle 17: Definition der Werte für diagnostic Session

5.2. Der Dienst SecurityAccess

Das Schreiben von Kalibrierungsdaten ist nur dann möglich, wenn sich die VU in der Betriebsart KALIBRIERUNG befindet. Der Zugriff auf die Betriebsart KALIBRIERUNG wird erst gewährt, nachdem eine gültige Werkstattkarte in die VU eingesteckt und zusätzlich die richtige persönliche Geheimzahl (PIN) in die VU eingegeben wurde.

Wenn sich die VU in der Betriebsart KALIBRIERUNG oder KONTROLLE befindet, ist der Zugriff auf die Eingabe/Ausgabe-Leitung für die Kalibrierung auch möglich.

Der Dienst SecurityAccess stellt die Möglichkeit zur PIN-Eingabe bereit und zeigt dem Prüfgerät an, ob sich die VU in der Betriebsart KALIBRIERUNG befindet.

Eine PIN-Eingabe durch alternative Methoden ist zulässig.

5.2.1 Beschreibung der Nachricht

Der Dienst SecurityAccess besteht aus der Nachricht SecurityAccess "request Seed", der möglicherweise eine Nachricht SecurityAccess "sendKey" folgt. Der Dienst SecurityAccess muss nach dem Dienst StartDiagnosticSession ausgeführt werden.

CPR_033 Mit der Nachricht SecurityAccess "request Seed" stellt das Prüfgerät fest, ob die Fahrzeugeinheit zur Annahme einer PIN bereit ist.

CPR_034 Befindet sich die Fahrzeugeinheit bereits in der Betriebsart KALIBRIERUNG, beantwortet sie die Anforderung durch Versenden eines Seed 0x0000 mithilfe des Dienstes auf SecurityAccess Positive Response.

CPR_035 Ist die Fahrzeugeinheit zur Annahme einer PIN zur Verifizierung einer Werkstattkarte bereit, beantwortet sie die Anforderung durch Versenden eines Seed, der größer als 0x0000 ist, mithilfe des Dienstes SecurityAccess Positive Response.

CPR_036 Ist die Fahrzeugeinheit zur Annahme einer PIN vom Prüfgerät nicht bereit, weil entweder die eingesteckte Werkstattkarte ungültig ist, keine Werkstattkarte eingesteckt wurde oder die Fahrzeugeinheit eine andere Methode der PIN-Eingabe erwartet, beantwortet sie die Anforderung mit einer Negative Response, wobei der Antwortcode "conditionsNotCorrectOrRequestSequenceError" lautet.

CPR_037 Das Prüfgerät sendet dann gegebenenfalls eine Nachricht SecurityAccess "sendKey", um eine PIN an die Fahrzeugeinheit zu übergeben. Um ausreichend Zeit für den Prozess der Kartenauthentisierung zu gewähren, sendet die VU den negativen Antwortcode "requestCorrectlyReceived-ResponsePending", mit dem die Antwortzeit verlängert wird. Die längst mögliche Wartezeit darf jedoch 5 Minuten nicht überschreiten. Sobald der angeforderte Dienst abgeschlossen ist, sendet die VU eine positive oder negative Antwortnachricht mit einem anderen Antwortcode als diesem. Der negative Antwortcode "requestCorrectlyReceived-ResponsePending" kann so oft von der VU wiederholt werden, bis der angeforderte Dienst abgeschlossen ist und die abschließende Antwortnachricht gesandt wurde.

CPR_038 Die Fahrzeugeinheit darf diese Anforderung nur dann mit dem Dienst SecurityAccess Positive Response beantworten, wenn sie sich in der Betriebsart KALIBRIERUNG befindet.

CPR_039 In den nachstehenden Fällen muss die Fahrzeugeinheit diese Anforderung mit einer Negative Response bei folgendermaßen gesetzten Antwortcodes quittieren:

• subFunction Notsupported: ungültiges Format für den Parameter der Unterfunktion (access Type),
• conditions NotCorrectOrRequestSequenceError: Fahrzeugeinheit ist zur Annahme einer PIN-Eingabe nicht bereit,
• invalidKey: ungültige PIN, Zahl der zulässigen PIN-Prüfversuche jedoch nicht überschritten,
• exceededNumberOfAttempts: ungültige PIN und Zahl der zulässigen PIN-Prüfversuche überschritten,
• generalReject: richtige PIN, gegenseitige Authentisierung mit Werkstattkarte ist jedoch fehlgeschlagen.

5.2.2 Nachrichtenformat - SecurityAccess - request Seed

CPR_040 Die Nachrichtenformate für die SecurityAccess "request Seed"-Primitive sind in den folgenden Tabellen spezifiziert.

Tabelle 18: Nachricht SecurityAccess Request - request Seed

Tabelle 19: Nachricht SecurityAccess - request Seed Positive Response

Tabelle 20: Nachricht SecurityAccess Negative Response

5.2.3 Nachrichtenformat - SecurityAccess - sendKey

CPR_041 Die Nachrichtenformate für die SecurityAccess "sendKey"-Primitive sind in den folgenden Tabellen spezifiziert.

Tabelle 21: Nachricht SecurityAccess Request - sendKey

Tabelle 22: Nachricht SecurityAccess - sendKey Positive Response

Tabelle 23: Nachricht SecurityAccess Negative Response

6. Datenübertragungsdienste

Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle aufgeführt:

Tabelle 24: Datenübertragungsdienste

6.1. Dienst ReadDataByIdentifier

6.1.1 Beschreibung der Nachricht

CPR_050 Mit dem Dienst ReadDataByIdentifier fordert der Client vom Server die Übertragung von Datensatzwerten an, die durch einen recordDataIdentifier gekennzeichnet sind. Der Fahrzeughersteller muss dafür sorgen, dass die Serverbedingungen zur Abwicklung dieses Dienstes erfüllt sind.

6.1.2 Nachrichtenformat

CPR_051 Die Nachrichtenformate für die ReadDataByIdentifier-Primitive sind in den folgenden Tabellen aufgeführt.

Tabelle 25: Nachricht ReadDataByIdentifier Request

Tabelle 26: Nachricht ReadDataByIdentifier Positive Response

Tabelle 27: Nachricht ReadDataByIdentifier Negative Response

6.1.3 Parameterdefinition

CPR_052 Der Parameter recordDataIdentifier (RDI_) in der Anforderungsnachricht ReadDataByIdentifier kennzeichnet einen Datensatz.

CPR_053 Die hier definierten Werte für recordDataIdentifier sind in der folgenden Tabelle aufgeführt.
Die Tabelle recordDataIdentifier enthält fünf Spalten mit mehreren Zeilen.

• Die 1. Spalte (Hex) enthält jeweils den hexadezimalen Wert für die in der 3. Spalte angeführte Anforderungsnachricht recordDataIdentifier.
• Die 2. Spalte (Datenelement) gibt zum jeweiligen recordDataIdentifier das Datenelement gemäß Anlage 1 an (ggf. Umkodierung erforderlich).
• Die 3. Spalte (Beschreibung) enthält den dazugehörigen Namen des recordDataIdentifier.
• Die 4. Spalte (Zugriffsrechte) gibt die Zugriffsrechte des jeweiligen recordDataIdentifier an.
• Die 5. Spalte (Symbolform) gibt die Symbolschreibweise des jeweiligen recordDataIdentifier an.

Tabelle 28: Definition der Werte für recordDataIdentifier

CPR_054 Der Parameter dataRecord (DREC_) dient der Nachricht Positive Response auf ReadDataByIdentifier dazu, dem Client (Prüfgerät) den durch die recordDataIdentifier gekennzeichneten Datensatz bereitzustellen. Die Datensatzformate werden in Abschnitt 8 definiert. Es können zusätzliche, vom Benutzer wählbare dataRecord-Werte, z.B. VU-abhängige Eingabedaten, interne Daten und Ausgabedaten integriert werden, diese werden jedoch hier nicht definiert.

6.2. Der Dienst WriteDataByIdentifier

6.2.1 Beschreibung der Nachricht

CPR_056 Der Dienst WriteDataByIdentifier dient dem Client dazu, Datensatzwerte auf einen Server zu schreiben, die durch einen recordDataIdentifier gekennzeichnet sind. Der Fahrzeughersteller muss dafür sorgen, dass die Serverbedingungen zur Abwicklung dieses Dienstes erfüllt sind. Zur Aktualisierung der in Tabelle 28 aufgeführten Parameter muss sich die VU in der Betriebsart KALIBRIERUNG befinden.

6.2.2 Nachrichtenformat

CPR_057 Die Nachrichtenformate für die WriteDataByIdentifier-Primitive sind in den folgenden Tabellen aufgeführt.

Tabelle 29: Nachricht WriteDataByIdentifier Request

Tabelle 30: Nachricht WriteDataByIdentifier Positive Response

Tabelle 31: Nachricht WriteDataByIdentifier Negative Response

6.2.3 Parameterdefinition

Der Parameter recordDataIdentifier (RDI_) ist in Tabelle 28 definiert.

Der Parameter dataRecord (DREC_) dient der Anforderungsnachricht WriteDataByIdentifier dazu, dem Server (VU) den durch die recordDataIdentifier gekennzeichneten Datensatzwerte bereitzustellen. Die Datensatzformate werden in Abschnitt 8 definiert.

7. Prüfimpulssteuerung - Funktionseinheit Eingabe/Ausgabe-Steuerung

Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle aufgeführt:

Tabelle 32: Funktionseinheit Eingabe/Ausgabe-Steuerung

7.1. Der Dienst InputOutputControlByIdentifier

7.1.1 Beschreibung der Nachricht

Über einen der Steckanschlüsse an der Vorderseite ist es möglich, Prüfimpulse mit einem geeigneten Prüfgerät zu steuern bzw. zu überwachen.

CPR_058 Diese Kalibrierungs-E/A-Signalleitung ist mit einem K-Leitungsbefehl konfigurierbar, wobei mit dem Dienst InputOutputControlByIdentifier die für die Leitung gewünschte Eingabe- bzw. Ausgabefunktion gewählt wird. Es gibt folgende Leitungszustände:

• deaktiviert,
• speed SignalInput: über die Kalibrierungs-E/A-Signalleitung wird ein Geschwindigkeitssignal (Testsignal) eingegeben, das das Geschwindigkeitssignal des Bewegungssensors ersetzt, diese Funktion ist in der Betriebsart KONTROLLE nicht verfügbar,
• real TimeSpeed SignalOutput Sensor: über die Kalibrierungs-E/A-Signalleitung wird das Geschwindigkeitssignal des Bewegungssensors ausgegeben,
• RTCOutput: über die Kalibrierungs-E/A-Signalleitung wird das UTC-Zeitsignal ausgegeben, diese Funktion ist in der Betriebsart KONTROLLE nicht verfügbar.

CPR_059 Um den Leitungsstatus zu konfigurieren, muss sich die Fahrzeugeinheit in einem Einstellvorgang befinden und in die Betriebsart KALIBRIERUNG oder KONTROLLE gesetzt sein. Wenn sich die VU in der Betriebsart KALIBRIERUNG befindet, stehen die vier Leitungsstati zur Verfügung (deaktiviert, speed SignalInput, real TimeSpeed SignalOutput Sensor, RTCOutput). Wenn sich die VU in der Betriebsart KONTROLLE befindet, stehen nur zwei Leitungsstati zur Verfügung (deaktiviert, real TimeSpeed OutputSensor). Bei Verlassen des Einstellvorgangs bzw. der Betriebsart KALIBRIERUNG oder KONTROLLE muss die Fahrzeugeinheit die Rückkehr der E/A-Signalleitung in den Status "deaktiviert" (Standardzustand) gewährleisten.

CPR_060 Treffen an der Echtzeit-Eingabeleitung für Geschwindigkeitssignale der VU Geschwindigkeitsimpulse ein, während die E/A-Signalleitung auf Eingabe gesetzt ist, muss die E/A-Signalleitung auf Ausgabe gesetzt werden oder in den deaktivierten Zustand zurückkehren.

CPR_061 Der Ablauf muss wie folgt sein:

• Aufbau der Verbindung durch den Dienst Start Communication
• Einleiten eines Einstellvorgangs durch den Dienst StartDiagnosticSession und Eintritt in die Betriebsart KALIBRIERUNG oder KONTROLLE (die Reihenfolge dieser beiden Vorgänge ist nicht von Bedeutung).
• Änderung des Ausgabestatus durch den Dienst InputOutputControlByIdentifier.

7.1.2 Nachrichtenformat

CPR_062 Die Nachrichtenformate für die InputOutputControlByIdentifier-Primitive sind in den folgenden Tabellen spezifiziert.

Tabelle 33: Nachricht InputOutputControlByIdentifier Request

Hinweis: Der Parameter controlState liegt nur in bestimmten Fällen vor (siehe 7.1.3).

Tabelle 34: Nachricht InputOutputControlByIdentifier Positive Response

Tabelle 35: Nachricht InputOutputControlByIdentifier Negative Response

7.1.3 Parameterdefinition

CPR_064 Der Parameter inputOutputControlParameter (IOCP_) ist in folgender Tabelle beschrieben.

Tabelle 36: Definition der Werte für inputOutputControlParameter

CPR_065 Der Parameter controlState liegt nur vor, wenn der inputOutputControlParameter auf ShortTermAdjustment gesetzt ist; folgende Werte sind möglich:

Tabelle 37: Definition der Werte für controlState

8. Der Dienst Routinecontrol (Zeiteinstellung)

8.1. Beschreibung der Nachricht

CPR_065a Der Dienst RoutineControl (TimeAdjustment) ermöglicht es, eine Anpassung der Systemuhr der Fahrzeugeinheit an die vom GNSS-Empfänger bereitgestellte Zeit auszulösen.

Die Fahrzeugeinheit muss sich im Modus KALIBRIERUNG befinden, damit der Dienst RoutineControl (TimeAdjustment) ausgeführt werden kann.

Voraussetzung: Es ist sichergestellt, dass die Fahrzeugeinheit authentisierte Positionsnachrichten vom GNSS-Empfänger empfangen kann.

Während die Zeiteinstellung läuft, antwortet die Fahrzeugeinheit auf die Anforderung RoutineControl, Unterfunktion requestRoutineResults mit routineInfo = 0x78.

Hinweis: Die Zeiteinstellung kann einige Zeit in Anspruch nehmen. Das Diagnoseprüfgerät fordert den Zeiteinstellungsstatus unter Verwendung der Unterfunktion requestRoutineResults an.

8.2. Nachrichtenformat

CPR_065b Die Nachrichtenformate für den Dienst RoutineControl (TimeAdjustment) und seine Primitiven sind in den folgenden Tabellen aufgeführt.

Tabelle 37a: RoutineControl, Nachrichtenanforderung Routine (TimeAdjustment), Unterfunktion startRoutine

Tabelle 37b: RoutineControl, Routine (TimeAdjustment), Unterfunktion startRoutine, Positive Antwortnachricht

Tabelle 37c: RoutineControl, Anforderungsnachricht Routine (TimeAdjustment), Unterfunktion requestRoutineResults

Tabelle 37d: RoutineControl, Routine (TimeAdjustment), Unterfunktion requestRoutineResults, Positive Antwortnachricht

Tabelle 37e: RoutineControl, Routine (TimeAdjustment), Negative Antwortnachricht

Tabelle 37f: RoutineControl, Routine (TimeAdjustment), routineInfo

Tabelle 37g: RoutineControl, Routine (TimeAdjustment), routineStatus

9. Datarecords-Formate

Dieser Abschnitt enthält:

• allgemeine Regeln für die Parameter, die von der Fahrzeugeinheit zum Prüfgerät übertragen werden,
• die Beschreibung der Formate für die in Abschnitt 6 erläuterten Datenübertragungsdienste.

CPR_067 Alle hier angegebenen Parameter müssen von der Fahrzeugeinheit unterstützt werden.

CPR_068 Von der Fahrzeugeinheit an das Prüfgerät aufgrund einer Anforderungsnachricht übertragene Daten müssen dem jeweiligen Messtyp entsprechen (d. h. dem aktuellen Wert des angeforderten Parameters, wie ihn die Fahrzeugeinheit gemessen oder vorgegeben hat).

9.1. Wertebereiche der übertragenen Parameter

CPR_069 Tabelle 38 enthält die Wertebereiche, mit deren Hilfe die Gültigkeit der übermittelten Parameter festgestellt wird.

CPR_070 Mit den Werten im Bereich "Fehlerindikator" kann die Fahrzeugeinheit sofort mitteilen, dass aufgrund eines Fehlers im Fahrtenschreiber derzeit keine gültigen Werte vorhanden sind.

CPR_071 Mit den Werten im Bereich "Nicht verfügbar" kann die Fahrzeugeinheit eine Nachricht übermitteln, die einen in diesem Modul nicht verfügbaren oder nicht unterstützten Parameter enthält. Mit den Werten im Bereich "Nicht angefordert" kann die Fahrzeugeinheit eine Befehlsnachricht übermitteln und die Parameter angeben, für die es vom anderen Gerät keine Antwort erwartet.

CPR_072 Können wegen eines defekten Bauteils keine gültigen Daten für einen Parameter übermittelt werden, sollte mit dem in Tabelle 38 angegebenen Fehlerindikator anstelle von Daten für den angeforderten Parameter geantwortet werden. Wenn die gemessenen oder errechneten Daten Werte annehmen, die zwar gültig sind, aber außerhalb des festgelegten Wertebereichs für diesen Parameter liegen, ist der Fehlerindikator jedoch nicht zu verwenden. In diesem Fall sollte der jeweilige Mindest- oder Höchstwert für diesen Parameter übertragen werden.

Tabelle 38: Wertebereiche der dataRecords

CPR_073 Bei den in ASCII dargestellten Parametern ist der Stern "*" als Trennzeichen reserviert.

9.2. dataRecords-Formate

In Tabelle 39 bis Tabelle 42 sind die Datensatzformate für die Dienste ReadDataByIdentifier und WriteDataByIdentifier angegeben.

CPR_074 In Tabelle 39 sind Länge, Auflösung und Betriebsbereich für jeden durch seinen recordDataIdentifier gekennzeichneten Parameter angegeben:

Tabelle 39: dataRecords-Formate

CPR_075 Tabelle 40 enthält die Formate der verschiedenen Bytes für den Parameter TimeDate:

Tabelle 40: Ausführliches Format des Parameters TimeDate (recordDataIdentifier-Wert F90B)

CPR_076 Tabelle 41 enthält die Formate der verschiedenen Bytes für den Parameter NextCalibrationDate:

Tabelle 41: Ausführliches Format des Parameters NextCalibrationDate (recordDataIdentifier-Wert F922)

HINWEIS zur Verwendung des Tag-Parameters:

1) Der Datumswert 0 ist ungültig. Die Werte 1, 2, 3 und 4 kennzeichnen den ersten Tag des Monats; die Werte 5, 6, 7 und 8 kennzeichnen den zweiten Tag des Monats usw. 2) Dieser Parameter hat keinen Einfluss auf den Stundenparameter oben.

HINWEIS zur Verwendung des Jahr-Parameters:

Der Wert 0 für das Jahr kennzeichnet das Jahr 1985; der Wert 1 das Jahr 1986 usw.

CPR_078 Tabelle 42 enthält die Formate der verschiedenen Bytes für den Parameter VehicleRegistrationNumber:

Tabelle 42: Ausführliches Format des Parameters VehicleRegistrationNumber (recordDataIdentifier-Wert F97E)

CPR_090 Tabelle 43 enthält die Formate der verschiedenen Bytes für den Parameter SealDataVu:

Tabelle 43: Ausführliches Format des Parameters SealDataVu (recordDataIdentifier-Wert F9D3)

HINWEIS: Sind weniger als 5 Plomben verfügbar, wird der Wert EquipmentType in allen unbenutzten sealRecords auf 15, d. h. unbenutzt, gesetzt.

CPR_091 Tabelle 44 enthält die Formate der verschiedenen Bytes für den Parameter ByDefaultLoadType:

Tabelle 44: Ausführliches Format des Parameters ByDefaultLoadType (recordDataIdentifier-Wert F9D5)

CPR_092 Tabelle 45 enthält die Formate der verschiedenen Bytes für die Parameter VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber und RemoteCommunicationModuleSerialNumber:

Tabelle 45: Ausführliches Format der Parameter VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber und RemoteCommunicationModuleSerialNumber (recordDataIdentifier-Werte F9D4, F9D0, F9D2, F9D1)

CPR_093 Tabelle 46 enthält die Formate der verschiedenen Bytes für den Parameter TachographCardsGen1Suppression:

Tabelle 46: Ausführliches Format des Parameters TachographCardsGen1Suppression (recordDataIdentifier-Wert F9D6)

CPR_094 Tabelle 47 enthält die Formate der verschiedenen Bytes für den Parameter VehiclePosition.

Tabelle 47: Ausführliches Format des Parameters VehiclePosition (recordDataIdentifier-Wert F9D7)

Hinweis: Nach einer Aktualisierung der Fahrzeugposition kann sich die Aktualisierung des derzeitigen Landes und der derzeitigen Region verzögern.

.

1. Einleitung

1.1. Typgenehmigung ¹⁸

Die EG-Typgenehmigung von Kontrollgeräten (oder deren Komponenten) oder einer Fahrtenschreiberkarte beruht auf:

• einer Sicherheitszertifizierung auf Grundlage der Spezifizierung Allgemeiner Kriterien anhand einer Sicherheitsvorgabe in völliger Übereinstimmung mit Anlage 10 dieses Anhangs,
• einer Funktionszertifizierung durch die Behörde eines Mitgliedstaates, mit der bestätigt wird, dass das geprüfte Teil hinsichtlich der ausgeführten Funktionen, der Messgenauigkeit und der Umwelteigenschaften die Anforderungen dieses Anhangs erfüllt,
• einer Interoperabilitätszertifizierung durch die zuständige Stelle, mit der bestätigt wird, dass das Kontrollgerät (oder die Fahrtenschreiberkarte) mit dem erforderlichen Muster der Fahrtenschreiberkarte (bzw. des Kontrollgeräts) (siehe Kapitel 8 in diesem Anhang) uneingeschränkt interoperabel ist.

In dieser Anlage ist in Form von Mindestanforderungen festgelegt, welche Prüfungen eine Behörde der Mitgliedstaaten während der Funktionsprüfungen und welche Prüfungen eine zuständige Stelle während der Interoperabilitätsprüfungen durchführen muss. Die Verfahren zur Durchführung der Prüfungen bzw. die Art der Prüfungen werden nicht weiter spezifiziert.

Die Aspekte der Sicherheitszertifizierung sind in dieser Anlage nicht enthalten. Werden bestimmte Prüfungen bereits für die Typgenehmigung im Rahmen des Verfahrens zur Sicherheitsbewertung und -zertifizierung durchgeführt, so brauchen diese Prüfungen nicht wiederholt zu werden. In diesem Fall sind lediglich die Ergebnisse dieser Sicherheitsprüfungen nachzuprüfen. Zu Informationszwecken sind in dieser Anlage Anforderungen, bei denen während der Sicherheitszertifizierung die Durchführung einer Prüfung erwartet wird (oder die mit durchzuführenden Prüfungen in einem engen Verhältnis stehen), mit einem "*" gekennzeichnet.

Die nummerierten Randnummern beziehen sich auf den Hauptteil des Anhangs, während sich die übrigen Anforderungen auf die übrigen Anlagen beziehen (Beispiel: PIC_001 bezieht sich auf Anforderung PIC_001 von Anlage 3 Piktogramme).

In dieser Anlage werden die Typgenehmigungen für den Bewegungssensor, für die Fahrzeugeinheit und für die externe GNSS-Ausrüstung getrennt betrachtet, da es sich dabei um Komponenten des Kontrollgeräts handelt. Jede Komponente enthält eine eigene Typgenehmigung, in der die anderen kompatiblen Komponenten angegeben werden. Die Funktionsprüfung des Bewegungssensors (bzw. der externen GNSS-Ausrüstung) erfolgt zusammen mit der Fahrzeugeinheit und umgekehrt.

Eine Interoperabilität zwischen sämtlichen Bewegungssensormodellen (bzw. externen GNSS-Ausrüstungen) und sämtlichen Fahrzeugeinheitmodellen ist nicht erforderlich. In einem solchen Fall kann die Typgenehmigung für einen Bewegungssensor (bzw. externe GNSS-Ausrüstung) nur in Kombination mit der Typgenehmigung für die relevante Fahrzeugeinheit bzw. umgekehrt erteilt werden.

Die Behörde der Mitgliedstaaten, die für die Funktionsprüfungen einer Fahrzeugeinheit oder einer externen GNSS-Ausrüstung zuständig ist, muss sicherstellen, dass der integrierte GNSS-Empfänger die in dieser Anlage festgelegten OSNMA-Prüfungen erfolgreich bestanden hat. Diese Prüfungen gelten als Teil der Funktionsprüfungen der Fahrzeugeinheit oder der externen GNSS-Ausrüstung.

1.2. Referenzdokumente

In dieser Anlage werden folgende Referenzdokumente herangezogen:

IEC 60068-2-1: Environmental testing - Part 2-1: Tests - Test A: Cold (Umgebungseinflüsse - Teil 2-1: Prüfverfahren - Prüfung A: Kälte)

IEC 60068-2-2: Basic environmental testing procedures; part 2: tests; tests B: dry heat (Umgebungseinflüsse - Teil 2-2: Prüfverfahren - Prüfung B: Trockene Wärme) (sinusförmig).

IEC 60068-2-6: Environmental testing - Part 2: Tests - Test Fc: Vibration (sinusoidal) (Umgebungseinflüsse - Teil 2-6: Prüfverfahren - Prüfung Fc: Schwingen (sinusförmig)

IEC 60068-2-14: Environmental testing; Part 2-14: Tests; Test N: Change of temperature (Umgebungseinflüsse - Teil 2-14: Prüfverfahren - Prüfung N: Temperaturwechsel)

IEC 60068-2-27: Environmental testing. Part 2: Tests. Test Ea and guidance: Shock (Umgebungseinflüsse; Teil 2-27: Prüfverfahren - Prüfung Ea und Leitfaden: Schocken)

IEC 60068-2-30: Environmental testing - Part 2-30: Tests - Test Db: Damp heat, cyclic (12 h + 12 h cycle) (Umgebungseinflüsse - Teil 2-30: Prüfverfahren - Prüfung Db: Feuchte Wärme, zyklisch (12 + 12 Stunden))

IEC 60068-2-64: Environmental testing - Part 2-64: Tests - Test Fh: Vibration, broadband random and guidance (Umgebungseinflüsse - Teil 2-64: Prüfverfahren - Prüfung Fh: Schwingen, Breitbandrauschen (digital geregelt) und Leitfaden)

IEC 60068-2-78 Environmental testing - Part 2-78: Tests - Test Cab: Damp heat, steady state (Umgebungseinflüsse - Teil 2-78: Prüfverfahren - Prüfung Cab: Feuchte Wärme, konstant)

ISO 16750-3 - Mechanical loads (2012-12) (Mechanische Beanspruchungen)

ISO 16750-4 - Climatic loads (2010-04) (Klimatische Beanspruchungen).

ISO 20653: Road vehicles - Degree of protection (IP code) - Protection of electrical equipment against foreign objects, water and access (Straßenfahrzeuge - Schutzarten (IP-Code) - Schutz gegen fremde Objekte, Wasser und Kontakt - Elektrische Ausrüstungen)

ISO 10605:2008 + Technical Corrigendum:2010 + AMD1:2014 Road vehicles - Test methods for electrical disturbances from electrostatic discharge (Straßenfahrzeuge - Prüfverfahren für elektrische Störungen durch elektrostatische Entladungen)

ISO 7637-1:2002 + AMD1: 2008 Road vehicles - Electrical disturbances from conduction and coupling - Part 1: Definitions and general considerations (Straßenfahrzeuge; Elektrische Störungen durch Leitung und Kopplung - Teil 1: Allgemeines und Definitionen).

ISO 7637-2 Road vehicles - Electrical disturbances from conduction and coupling - Part 2: Electrical transient conduction along supply lines only (Straßenfahrzeuge - Elektrische Störungen durch Leitung und Kopplung - Teil 2: Elektrische, leitungsgeführte Störungen auf Versorgungsleitungen).

ISO 7637-3 Road vehicles - Electrical disturbances from conduction and coupling - Part 3: Electrical transient transmission by capacitive and inductive coupling via lines other than supply lines (Straßenfahrzeuge - Elektrische Störungen durch Leitung und Kopplung - Kapazitiv und induktiv gekoppelte Störungen auf andere als Versorgungsleitungen).

ISO/IEC 7816-1 Identification cards - Integrated circuit(s) cards with contacts - Part 1: Physical characteristics (Identifikationskarten - Chipkarten mit Kontakten - Teil 1: Physikalische Eigenschaften).

ISO/IEC 7816-2 Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 2: Dimensions and location of the contacts (Identifikationskarten - Chipkarten - Karten mit Kontakten - Teil 2: Maße und Anordnung der Kontakte).

ISO/IEC 7816-3 Information technology - Identification cards - Integrated circuit(s) cards with contacts - Part 3: Electronic signals and transmission protocol (Chipkarten mit Kontakten - Teil 3: Elektronische Eigenschaften und Übertragungsprotokolle).

ISO/IEC 10373-1:2006 + AMD1:2012 Identification cards - Test methods - Part 1: General characteristics (Identifikationskarten - Prüfverfahren - Teil 1: Generelle Eigenschaften).

ISO/IEC 10373-3:2010 + Technical Corrigendum:2013 Identification cards - Test methods - Part 3: Integrated circuit cards with contacts and related interface devices (Identifikationskarten - Prüfverfahren - Teil 3: Chipkarten mit Kontakten und zugehörige Schnittstellen-Geräte)

ISO 16844-3:2004, Cor 1:2006 Road vehicles - Tachograph systems - Part 3: Motion sensor interface (with vehicle units) (Straßenfahrzeuge - Fahrtschreiber (Kontrollgeräte) - Teil 3: Schnittstelle Bewegungssensor).

ISO 16844-4 Road vehicles - Tachograph systems - Part 4: CAN interface (Straßenfahrzeuge - Fahrtschreiber (Kontrollgeräte) - Teil 4: CAN-Schnittstelle).

ISO 16844-6 Road vehicles - Tachograph systems - Part 6: Diagnostics (Straßenfahrzeuge - Fahrtschreiber (Kontrollgeräte) - Teil 6: Diagnose) ISO 16844-7 Road vehicles - Tachograph systems - Part 7: Parameter

ISO 534 Paper and board - Determination of thickness, density and specific volume (Papier und Pappe - Bestimmung der Dicke, der Dichte und des spezifischen Volumens)

UN ECE R10 Uniform provisions concerning the approval of vehicles with regard to electromagnetic compatibility (United Nation Economic Commission for Europe) (Regelung der Wirtschaftskommission für Europa bei den Vereinten Nationen über einheitliche technische Bedingungen für die Genehmigung von Fahrzeugen hinsichtlich der elektromagnetischen Verträglichkeit

RGODP Technischer Bericht der JRC - Receiver guidelines for OSNMA data processing (Leitlinien für Empfänger hinsichtlich der OSNMA-Datenverarbeitung)

2. Funktionsprüfungen an der Fahrzeugeinheit ¹⁸