Anlage 8 VO (EU) 2016/799
KALIBRIERUNGSPROTOKOLL
INHALTSVERZEICHNIS
-
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.
| Diagnosevorgänge | |||||
|---|---|---|---|---|---|
| Name des Diagnosedienstes | Abschnitt Nr. | Wert SId Req. | SD | ECUAS | ECUPS |
| StartCommunication | 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 |  |  | |
- 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:| Name des Dienstes | Beschreibung |
|---|---|
| StartCommunication | Client fordert Beginn eines Kommunikationsvorgangs mit einem (mehreren) Server(n) an |
| StopCommunication | Client fordert Beendigung des laufenden Kommunikationsvorgangs an |
| TesterPresent | Client teilt dem Server mit, dass die Verbindung noch aktiv ist |
- CPR_005
- Der Dienst StartCommunication 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 StartCommunication
- CPR_006
- Bei Erhalt eines StartCommunication-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 StartCommunication-Antwort-Primitiv mit den gewählten Positive Response-Parametern.
- CPR_008
- Erhält eine bereits initialisierte (und in eine Diagnosesitzung eingetretene) VU die Anforderung StartCommunication (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 StartCommunication 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 10400 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 StartCommunication 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
Parameter Min. Max. TInil 25 ± 1 ms 24 ms 26 ms TWup 50 ± 1 ms 49 ms 51 ms Tabelle 4
Taktwerte für die Kommunikation
Takt-Parameter Beschreibung der Parameter Untere Grenzwerte [in ms] Obere Grenzwerte [in ms] Min. Max. P1 Byte-Taktabstand für die VU-Antwort 0 20 P2 Zeit zwischen Prüfgerätanforderung und VU-Antwort bzw. zwei VU-Antworten 25 250 P3 Zeit zwischen Ende der VU-Antworten und Beginn einer neuen Prüfgerätanforderung 55 5000 P4 Byte-Taktabstand für die Prüfgerätantwort 5 20
- CPR_018
- Das Nachrichtenformat für die Schnellinitialisierung ist in den nachstehenden Tabellen spezifiziert.
Tabelle 5
Nachricht StartCommunication Request
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 81 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 StartCommunication Request Service Id 81 SCR #5 Prüfsumme 00-FF CS Tabelle 6
Nachricht StartCommunication Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 StartCommunication Positive Response Service C1 SCRPR #6 Schlüsselbyte 1 EA KB1 #7 Schlüsselbyte 2 8F KB2 #8 Prüfsumme 00-FF CS
- CPR_019
- Eine negative Antwort (Negative Response) auf die Anforderungsnachricht StartCommunication 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte 01 LEN #5 StopCommunication Request Service 82 SPR #6 Prüfsumme 00-FF CS Tabelle 8
Nachricht StopCommunication Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 01 LEN #5 StopCommunication Positive Response Service Id C2 SPRPR #6 Prüfsumme 00-FF CS Tabelle 9
Nachricht StopCommunication Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 StopCommunication Request Service Identification 82 SPR #7 responseCode = generalReject 10 RC_GR #8 Prüfsumme 00-FF CS
- 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte 02 LEN #5 TesterPresent Request Service Id 3E TP #6 Sub Function = responseRequired = [ yes 01 RESPREQ_Y no ] 02 RESPREQ_NO #7 Prüfsumme 00-FF CS
- CPR_080
- Ist der Parameter responseRequired 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 01 LEN #5 TesterPresent Positive Response Service Id 7E TPPR #6 Prüfsumme 00-FF CS
- CPR_081
- Der Dienst verwendet die folgenden negativen Antwort-Codes:
Tabelle 12
Nachricht TesterPresent Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 TesterPresent Request Service Identification 3E TP #7 responseCode = [SubFunctionNotSupported-InvalidFormat 12 RC_SFNS_IF incorrectMessageLength] 13 RC_IML #8 Prüfsumme 00-FF CS
- 5.
- VERWALTUNGSDIENSTE
Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle aufgeführt:| Name des Dienstes | Beschreibung |
|---|---|
| StartDiagnosticSession | Client fordert Beginn eines Diagnosevorgangs mit einer VU an |
| SecurityAccess | Client ruft Funktionen auf, auf die nur berechtigte Benutzer Zugriff haben. |
- 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 diagnosticSession in der Anforderungsnachricht auf „StandardSession” 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte 02 LEN #5 StartDiagnosticSession Request Service Id 10 STDS #6 diagnosticSession = [ein Wert aus Tabelle 17] xx DS_… #7 Prüfsumme 00-FF CS Tabelle 15
Nachricht StartDiagnosticSession Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 02 LEN #5 StartDiagnosticSession Positive Response Service Id 50 STDSPR #6 diagnosticSession = [gleicher Wert wie Byte Nr. 6 in Tabelle 14] xx DS_… #7 Prüfsumme 00-FF CS Tabelle 16
Nachricht StartDiagnosticSession Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 StartDiagnosticSession Request Service Id 10 STDS #7 ResponseCode = [subFunctionNotSupported(*) 12 RC_SFNS incorrectMessageLength(**) 13 RC_IML conditionsNotCorrect(***) 22 RC_CNC #8 Prüfsumme 00-FF CS
- 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 diagnosticSession
Hex Beschreibung Symbolform 81 StandardDiagnosticSession
Dieser Diagnosevorgang aktiviert alle Dienste, die in Spalte 4 „SD” von Tabelle 1 angegeben sind. Diese Dienste ermöglichen das Auslesen der Daten von einem Server (VU). Dieser Diagnosevorgang ist aktiv, nachdem die Initialisierung zwischen Client (Prüfgerät) und Server (VU) erfolgreich abgeschlossen wurde. Dieser Diagnosevorgang kann durch andere in diesem Abschnitt genannte Diagnosevorgänge überschrieben werden.SD 85 ECUProgrammingSession
Dieser Diagnosevorgang aktiviert alle Dienste, die in Spalte 6 „ECUPS” von Tabelle 1 angegeben sind. Diese Dienste unterstützen die Speicherprogrammierung eines Servers (VU). Dieser Diagnosevorgang kann durch andere in diesem Abschnitt genannte Diagnosevorgänge überschrieben werden.ECUPS 87 ECUAdjustmentSession
Dieser Diagnosevorgang aktiviert alle Dienste, die in Spalte 5 „ECUAS” von Tabelle 1 angegeben sind. Diese Dienste unterstützen die Eingabe/Ausgabe-Steuerung eines Servers (VU). Dieser Diagnosevorgang kann durch andere in diesem Abschnitt genannte Diagnosevorgänge überschrieben werden.ECUAS
- 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 „requestSeed” , 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 „requestSeed” 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:
- —
subFunctionNotsupported: ungültiges Format für den Parameter der Unterfunktion (accessType),
- —
conditionsNotCorrectOrRequestSequenceError: 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 — requestSeed
- CPR_040
- Die Nachrichtenformate für die SecurityAccess „requestSeed” -Primitive sind in den folgenden Tabellen spezifiziert.
Tabelle 18
Nachricht SecurityAccess Request — requestSeed
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte 02 LEN #5 SecurityAccess Request Service Id 27 SA #6 accessType — requestSeed 7D AT_RSD #7 Prüfsumme 00-FF CS Tabelle 19
Nachricht SecurityAccess — requestSeed Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 04 LEN #5 SecurityAccess Positive Response Service ID 67 SAPR #6 accessType — requestSeed 7D AT_RSD #7 Seed High 00-FF SEEDH #8 Seed Low 00-FF SEEDL #9 Prüfsumme 00-FF CS Tabelle 20
Nachricht SecurityAccess Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 SecurityAccess Request Service Id 27 SA #7 responseCode = [conditionsNotCorrectOrRequestSequenceError 22 RC_CNC incorrectMessageLength] 13 RC_IML #8 Prüfsumme 00-FF CS
- 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte m+2 LEN #5 SecurityAccess Request Service Id 27 SA #6 accessType — sendKey 7E AT_SK #7 bis #m+6 Schlüssel #1 (H) xx KEY … … Schlüssel #m (N, m muss mindestens 4 und darf höchstens 8 betragen) xx #m+7 Prüfsumme 00-FF CS Tabelle 22
Nachricht SecurityAccess — sendKey Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 02 LEN #5 SecurityAccess Positive Response Service Id 67 SAPR #6 accessType — sendKey 7E AT_SK #7 Prüfsumme 00-FF CS Tabelle 23
Nachricht SecurityAccess Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 SecurityAccess Request Service Id 27 SA #7 ResponseCode = [generalReject 10 RC_GR subFunctionNotSupported 12 RC_SFNS incorrectMessageLength 13 RC_IML conditionsNotCorrectOrRequestSequenceError 22 RC_CNC invalidKey 35 RC_IK exceededNumberOfAttempts 36 RC_ENA requestCorrectlyReceived-ResponsePending] 78 RC_RCR_RP #8 Prüfsumme 00-FF CS
- 6.
- DATENÜBERTRAGUNGSDIENSTE
Die zur Verfügung stehenden Dienste sind in nachstehender Tabelle aufgeführt:| Name des Dienstes | Beschreibung |
|---|---|
| ReadDataByIdentifier | Client fordert an, dass der aktuelle Wert eines Datensatzes durch Zugriff von recordDataIdentifier übertragen wird. |
| WriteDataByIdentifier | Client fordert an, dass ein Datensatz von recordDataIdentifier geschrieben wird. |
- 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte 03 LEN #5 ReadDataByIdentifier Request Service Id 22 RDBI #6 bis #7 recordDataIdentifier = [ein Wert aus Tabelle 28] xxxx RDI_… #8 Prüfsumme 00-FF CS Tabelle 26
Nachricht ReadDataByIdentifier Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte m+3 LEN #5 ReadDataByIdentifier Positive Response Service Id 62 RDBIPR #6 und #7 recordDataIdentifier = [gleicher Wert wie Bytes 6 und 7 in Tabelle 25] xxxx RDI_... #8 bis #m+7 dataRecord[] = [data#1 xx DREC_DATA1 : : : data#m] xx DREC_DATAm #m+8 Prüfsumme 00-FF CS Tabelle 27
Nachricht ReadDataByIdentifier Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 ReadDataByIdentifier Request Service Id 22 RDBI #7 ResponseCode= [requestOutOfRange 31 RC_ROOR incorrectMessageLength 13 RC_IML conditionsNotCorrect] 22 RC_CNC #8 Prüfsumme 00-FF CS
- 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
Hex Datenelement recordDataIdentifier-Name
(siehe Format in Abschnitt 8.2)
Zugriffsrechte
(Read/Write)
Symbolform F90B CurrentDateTime TimeDate R/W RDI_TD F912 HighResOdometer HighResolutionTotalVehicleDistance R/W RDI_HRTVD F918 K-ConstantOfRecordingEquipment Kfactor R/W RDI_KF F91C L-TyreCircumference LfactorTyreCircumference R/W RDI_LF F91D W-VehicleCharacteristicConstant WvehicleCharacteristicFactor R/W RDI_WVCF F921 TyreSize TyreSize R/W RDI_TS F922 nextCalibrationDate NextCalibrationDate R/W RDI_NCD F92C SpeedAuthorised SpeedAuthorised R/W RDI_SA F97D vehicleRegistrationNation RegisteringMemberState R/W RDI_RMS F97E VehicleRegistrationNumber VehicleRegistrationNumber R/W RDI_ VRN F190 VehicleIdentificationNumber VIN R/W RDI_ VIN F9D0 SensorSerialNumber MotionSensorSerialNumber R RDI_SSN F9D1 RemoteCommunicationModuleSerialNumber RemoteCommunicationFacilitySerialNumber R RDI_RCSN F9D2 SensorGNSSSerialNumber ExternalGNSSFacilitySerialNumber R RDI_GSSN F9D3 SealDataVu SmartTachographSealsSerialNumber R/W RDI_SDV F9D4 VuSerialNumber VuSerialNumber R RDI_VSN F9D5 ByDefaultLoadType ByDefaultLoadType R/W RDI_BDLT F9D6 TachographCardsGen1Suppression TachographCardsGen1Suppression R/W RDI_TCG1S F9D7 VehiclePosition VehiclePosition R RDI_VP F9D8 LastCalibrationCountry CalibrationCountry R RDI_CC
- 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte m+3 LEN #5 WriteDataByIdentifier Request Service Id 2E WDBI #6 bis #7 recordDataIdentifier = [ein Wert aus Tabelle 28] xxxx RDI_… #8 bis m+7 dataRecord[] = [data#1 xx DREC_DATA1 : : : data#m] xx DREC_DATAm #m+8 Prüfsumme 00-FF CS Tabelle 30
Nachricht WriteDataByIdentifier Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 WriteDataByIdentifier Positive Response Service Id 6E WDBIPR #6 bis #7 recordDataIdentifier = [gleicher Wert wie Bytes 6 und 7 in Tabelle 29] xxxx RDI_… #8 Prüfsumme 00-FF CS Tabelle 31
Nachricht WriteDataByIdentifier Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 WriteDataByIdentifier Request Service Id 2E WDBI #7 ResponseCode= [requestOutOfRange 31 RC_ROOR incorrectMessageLength 13 RC_IML conditionsNotCorrect] 22 RC_CNC #8 Prüfsumme 00-FF CS
- 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:| Name des Dienstes | Beschreibung |
|---|---|
| InputOutputControlByIdentifier | Der Client fordert die Steuerung einer speziellen Eingabe/Ausgabe für den Server an. |
- 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,
- —
speedSignalInput: ü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,
- —
realTimeSpeedSignalOutputSensor: ü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, speedSignalInput, realTimeSpeedSignalOutputSensor, RTCOutput). Wenn sich die VU in der Betriebsart KONTROLLE befindet, stehen nur zwei Leitungsstati zur Verfügung (deaktiviert, realTimeSpeedOutputSensor). 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 StartCommunication
- —
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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte xx LEN #5 InputOutputControlByIdentifier Request SId 2F IOCBI #6 und #7 InputOutputIdentifier = [CalibrationInputOutput] F960 IOI_CIO #8 oder
#8 bis #9
ControlOptionRecord = [ COR_… inputOutputControlParameter — ein Wert aus Tabelle 36 xx IOCP_… controlState — ein Wert aus Tabelle 37 (siehe Hinweis unten)] xx CS_… #9 oder #10 Prüfsumme 00-FF CS Hinweis: Der Parameter controlState liegt nur in bestimmten Fällen vor (siehe 7.1.3).
Tabelle 34
Nachricht InputOutputControlByIdentifier Positive Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte xx LEN #5 InputOutputControlByIdentifier Positive Response SId 6F IOCBIPR #6 und #7 inputOutputIdentifier = [CalibrationInputOutput] F960 IOI_CIO #8 oder
#8 bis #9
controlStatusRecord = [ CSR_ inputOutputControlParameter (gleicher Wert wie Byte 8 in Tabelle 33) xx IOCP_… controlState (gleicher Wert wie Byte 9 in Tabelle 33)] (falls zutreffend) xx CS_… #9 oder #10 Prüfsumme 00-FF CS Tabelle 35
Nachricht InputOutputControlByIdentifier Negative Response
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte — physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 Negative Response Service Id 7F NR #6 inputOutputControlByIdentifier Request SId 2F IOCBI #7 responseCode=[ incorrectMessageLength 13 RC_IML conditionsNotCorrect 22 RC_CNC requestOutOfRange 31 RC_ROOR deviceControlLimitsExceeded] 7A RC_DCLE #8 Prüfsumme 00-FF CS
- 7.1.3
- Parameterdefinition
- CPR_064
- Der Parameter inputOutputControlParameter (IOCP_) ist in folgender Tabelle beschrieben.
Tabelle 36
Definition der Werte für inputOutputControlParameter
Hex Beschreibung Symbolform 00 ReturnControlToECU
Dieser Wert zeigt dem Server (VU) an, dass das Prüfgerät die Steuerung der Kalibrierungs-E/A-Signalleitung beendet hat.RCTECU 01 ResetToDefault
Dieser Wert zeigt dem Server (VU) die Anforderung an, die Kalibrierungs-E/A-Signalleitung in den Standardstatus zurückzusetzen.RTD 03 ShortTermAdjustment
Dieser Wert zeigt dem Server (VU) die Anforderung an, die Kalibrierungs-E/A-Signalleitung auf den im Parameter controlState enthaltenen Wert einzustellen.STA
- 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
Betriebsart Hex-Wert Beschreibung Deaktiviert 00 E/A-Leitung deaktiviert (Ausgangszustand) Aktiviert 01 Kalibrierungs-E/A-Leitung als speedSignalInput aktiviert Aktiviert 02 Kalibrierungs-E/A-Leitung als realTimeSpeedSignalOutputSensor aktiviert Aktiviert 03 Kalibrierungs-E/A-Leitung als RTCOutput aktiviert
- 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
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte – physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte xx LEN #5 RoutineControl Request Sid (Dienstkennung für Anforderung RoutineControl) 31 RC #6 routineControlType = [startRoutine] 01 RCTP_STR #7 und #8 routineIdentifier = [TimeAdjustment] 0100 RI_TA #9 Prüfsumme 00-FF CS Tabelle 37b
RoutineControl, Routine (TimeAdjustment), Unterfunktion startRoutine, Positive Antwortnachricht
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte – physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte xx LEN #5 RoutineControl Positive Response Sid (Dienstkennung für positive Antwort für RoutineControl) 71 RCPR #6 routineControlType = [startRoutine] 01 RCTP_STR #7 und #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA #9 Prüfsumme 00-FF CS Tabelle 37c
RoutineControl, Anforderungsnachricht Routine (TimeAdjustment), Unterfunktion requestRoutineResults
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte – physische Adressierung 80 FMT #2 Zieladress-Byte EE TGT #3 Quelladress-Byte tt SRC #4 Zusatzlängen-Byte xx LEN #5 RoutineControl Request Sid (Dienstkennung für Anforderung RoutineControl) 31 RC #6 routineControlType = [requestRoutineResults] 03 RCTP_RRR #7 und #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA #9 Prüfsumme 00-FF CS Tabelle 37d
RoutineControl, Routine (TimeAdjustment), Unterfunktion requestRoutineResults, Positive Antwortnachricht
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte – physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte xx LEN #5 RoutineControl Positive Response Sid (Dienstkennung für positive Antwort für RoutineControl) 71 RCPR #6 routineControlType = [requestRoutineResults] 03 RCTP_RRR #7 und #8 routineIdentifier= [TimeAdjustment] 0100 RI_TA #9 routineInfo (siehe Tabelle 37f) XX RINF_TA #10 routineStatusRecord[] = routineStatus#1 (siehe Tabelle 37g) XX RS_TA #11 Prüfsumme 00-FF CS Tabelle 37e
RoutineControl, Routine (TimeAdjustment), Negative Antwortnachricht
Byte-Nr. Parameterbezeichnung Hex-Wert Symbolform #1 Format-Byte – physische Adressierung 80 FMT #2 Zieladress-Byte tt TGT #3 Quelladress-Byte EE SRC #4 Zusatzlängen-Byte 03 LEN #5 negativeResponse Service Id (Dienstkennung für negative Antwort) 7F NR #6 inputOutputControlByIdentifier Request SId 31 RC #7 responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
12
13
22
31
SFNS
IMLOIF
CNC
ROOR
#8 Prüfsumme 00-FF CS Tabelle 37f
RoutineControl, Routine (TimeAdjustment), routineInfo
routineInfo Hex-Wert Beschreibung NormalExitWithResultAvailable 61 Die Routine wurde vollständig ausgeführt; zusätzliche Ergebnisse der Routine sind verfügbar. RoutineExecutionOngoing 78 Die Ausführung der Routine läuft noch. Tabelle 37g
RoutineControl, Routine (TimeAdjustment), routineStatus
Hex-Wert Prüfergebnis Beschreibung 01 positiv Die Zeiteinstellung wurde erfolgreich abgeschlossen. 02..0F RFU 10 negativ Kein GNSS-Signalempfang. 11..7F RFU 80..FF Herstellerspezifisch
- 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
Wertebereichsname 1 Byte
(Hex-Wert)
2 Bytes
(Hex-Wert)
4 Bytes
(Hex-Wert)
ASCII Gültiges Signal 00 bis FA 0000 bis FAFF 00000000 bis FAFFFFFF 1 bis 254 Parameterspezifischer Indikator FB FB00 bis FBFF FB000000 bis FBFFFFFF keiner Reserviert für zukünftige Indikatorbits FC bis FD FC00 bis FDFF FC000000 bis FDFFFFFF keiner Fehlerindikator FE FE00 bis FEFF FE000000 bis FEFFFFFF 0 Nicht verfügbar oder nicht angefordert FF FF00 bis FFFF FF000000 bis FFFFFFFF FF - 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
Parameterbezeichnung Datenlänge (Bytes) Auflösung Betriebsbereich TimeDate 8 siehe Tabelle 40 HighResolutionTotalVehicleDistance 4 Zuwachs 5 m/Bit, Ausgangswert 0 m 0 bis +21055406 km Kfactor 2 Zuwachs 0,001 Impulse/m/Bit, Ausgangswert 0 0 bis 64,255 Impulse/m LfactorTyreCircumference 2 Zuwachs 0,125 10-3 m/Bit, Ausgangswert 0 0 bis 8,031 m WvehicleCharacteristicFactor 2 Zuwachs 0,001 Impulse/m/Bit, Ausgangswert 0 0 bis 64,255 Impulse/m TyreSize 15 ASCII ASCII NextCalibrationDate 3 siehe Tabelle 41 SpeedAuthorised 2 Zuwachs 1/256 km/h/Bit, Ausgangswert 0 0 bis 250,996 km/h RegisteringMemberState 3 ASCII ASCII VehicleRegistrationNumber 14 siehe Tabelle 42 VIN 17 ASCII ASCII SealDataVu 55 siehe Tabelle 43 ByDefaultLoadType 1 siehe Tabelle 44 VuSerialNumber 8 siehe Tabelle 45 SensorSerialNumber 8 siehe Tabelle 45 SensorGNSSSerialNumber 8 siehe Tabelle 45 RemoteCommunicationModuleSerialNumber 8 siehe Tabelle 45 TachographCardsGen1Suppression 2 siehe Tabelle 46 VehiclePosition 14 siehe Tabelle 47 CalibrationCountry 3 ASCII NationAlpha entsprechend Anlage 1 - 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 Sekunden Zuwachs 0,25 s/Bit, Ausgangswert 0 s 0 bis 59,75 s 2 Minuten Zuwachs 1 min/Bit, Ausgangswert 0 min 0 bis 59 min 3 Stunden Zuwachs 1 h/Bit, Ausgangswert 0 h 0 bis 23 h 4 Monat Zuwachs 1 Monat/Bit, Ausgangswert 0 Monate 1 bis 12 Monate 5 Tag Zuwachs 0,25 Tag/Bit, Ausgangswert 0 Tage (siehe HINWEIS unter Tabelle 41) 0,25 bis 31,75 Tage 6 Jahr Zuwachs 1 Jahr/Bit, Ausgangswert +1985 Jahre
(siehe HINWEIS unter Tabelle 41)
1985 bis 2235 Jahre 7 Lokaler Ausgangswert Minuten Zuwachs 1 min/Bit, Ausgangswert -125 min -59 bis +59 min 8 Lokaler Ausgangswert Stunden Zuwachs 1 h/Bit, Ausgangswert –125 h –23 bis +23 h - 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 Monat Zuwachs 1 Monat/Bit, Ausgangswert 0 Monate 1 bis 12 Monate 2 Tag Zuwachs 0,25 Tage/Bit, Ausgangswert 0 Tage (siehe HINWEIS unten) 0,25 bis 31,75 Tage 3 Jahr Zuwachs 1 Jahr/Bit, Ausgangswert +1985 Jahre
(siehe Hinweis unten)
1985 bis 2235 Jahre 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 Codeseite (entsprechend Anlage 1) Nicht anwendbar VehicleRegistrationNumber 2 bis 14 Amtliches Kennzeichen (entsprechend Anlage 1) Nicht anwendbar VehicleRegistrationNumber - 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 bis 11 sealRecord1. Format SealRecord entsprechend Anlage 1. Nicht anwendbar SealRecord 12 bis 22 sealRecord2. Format SealRecord entsprechend Anlage 1. Nicht anwendbar SealRecord 23 bis 33 sealRecord3. Format SealRecord entsprechend Anlage 1. Nicht anwendbar SealRecord 34 bis 44 sealRecord4. Format SealRecord entsprechend Anlage 1. Nicht anwendbar SealRecord 45 bis 55 sealRecord5. Format SealRecord entsprechend Anlage 1. Nicht anwendbar SealRecord 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 loadType
'00'H: Art der Ladung nicht definiert
'01'H: Güter
'02'H: Personen
Nicht anwendbar '00'H bis '02'H - 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber und RemoteCommunicationModuleSerialNumber:
Format ExtendedSerialNumber entsprechend Anlage 1
Nicht anwendbar ExtendedSerialNumber - 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 bis 2 TachographCardsGen1Suppression. Format TachographCardsGen1Suppression entsprechend Anlage 1. Nicht anwendbar '0000'H, 'A5E3'H - 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)
Byte Parameterdefinition Auflösung Betriebsbereich 1 bis 4 Zeitstempel der Bestimmung der Position des Fahrzeugs. Nicht anwendbar TimeReal 5 GNSS-Genauigkeit Nicht anwendbar GNSSAccuracy 6 bis 11 Fahrzeugposition Nicht anwendbar GeoCoordinates 12 Authentisierungsstatus Nicht anwendbar PositionAuthenticationStatus 13 Derzeitiges Land Nicht anwendbar NationNumeric 14 Derzeitige Region Nicht anwendbar RegionNumeric Hinweis: Nach einer Aktualisierung der Fahrzeugposition kann sich die Aktualisierung des derzeitigen Landes und der derzeitigen Region verzögern.
Fußnote(n):
- (*)
— Der in Byte Nr. 6 der Anforderungsnachricht eingetragene Wert wird nicht unterstützt, d. h., er ist nicht in Tabelle 17 definiert.
- (**)
— Die Nachricht hat eine falsche Länge.
- (***)
— Die Bedingungen für die angeforderte StartDiagnosticSession sind nicht erfüllt.
© Europäische Union 1998-2021
Tipp: Verwenden Sie die Pfeiltasten der Tastatur zur Navigation zwischen Normen.