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

zurück

.

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.

CPR_001 Im Programmiervorgang "ECUProgrammingSession" ist es möglich, Daten in die Fahrzeugeinheit einzugeben. Bei der Eingabe von Kalibrierungsdaten (Anforderungen 097 und 098) 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 "Datensatzformate" 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 FE auf jede Prüfgerätadresse richtig antworten. Die physische Adresse der FE ist 0xEE.

2. Begriffe, Begriffsbestimmungen und Referenzdokumente

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 FE verwendete Gerät.

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

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

Referenzdokumente:

3. Diensteübersicht

3.1. Verfügbare Dienste

Die folgende Tabelle gibt einen Überblick über die in dieser Anlage beschriebenen Dienste, die im Kontrollgerät 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 FE 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 FE zu gestatten.
• Spalte 6 gibt die Dienste des Programmiervorgangs "ECUProgrammingSession" (ECUPS) an, die implementiert sein müssen, um die Programmierung von Parametern in der FE zu ermöglichen.

Tabelle 1 Übersicht über die SID-Werte

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 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 FE, 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 FE 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) FE die Anforderung StartCommunication (z.B. aufgrund Wiederanlauf des Prüfgeräts nach einer Fehlerbedingung), muss die Anforderung angenommen und die FE neu initialisiert werden.

CPR_009 Falls sich die Kommunikationsverbindung aus irgendeinem Grund nicht initialisieren lässt, setzt die FE 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 FE für Dienste erfolgt mit Hilfe 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 FE enthalten.

CPR_012 Nach Beendigung der Initialisierung:

• Alle Kommunikationsparameter werden entsprechend der Schlüssel-Bytes auf die Werte in Tabelle 5 gesetzt.
• Die FE wartet auf die erste Anforderung vom Prüfgerät.
• Die FE 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 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, T_Ruhe= 300 ms.
• Nach Abschluss eines Dienstes StopCommunication, T_Ruhe= P3 Minimum
• Nach Beendigung der Kommunikation durch Zeitüberschreitung (Time-Out)
  P3 Maximum, T_Ruhe= 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 Anforderungsnachricht für StartCommunication

Tabelle 6 Nachricht Positive Response auf StartCommunication

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 FE, 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 FE, ob die derzeitigen Bedingungen die Beendigung dieser Kommunikation gestatten. Ist dies der Fall, so führt die FE alle erforderlichen Maßnahmen zur Beendigung dieser Kommunikation durch.

CPR_021 Ist die Beendigung der Kommunikation möglich, gibt die FE 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 FE ein StopCommunication-Antwort-Primitiv mit den gewählten Parametern für Negative Response aus.

CPR_023 Wird von der FE 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 Anforderungsnachricht für StopCommunication

Tabelle 8 Nachricht Positive Response auf StopCommunication

Tabelle 9 Nachricht Negative Response auf StopCommunication

4.2.3. Parameterdefinition

Dieser Dienst erfordert keine Parameterdefinition.

4.3. Der Dienst TesterPresent

4.3.1. Beschreibung der Nachricht

Mit Hilfe 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 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 Anforderungsnachricht TesterPresent

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

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 FE aktiv.
• Die FE startet die "StandardDiagnosticSession" bei jedem Einschaltvorgang. Wird kein anderer Diagnosevorgang gestartet, so läuft die "StandardDiagnosticSession" so lange wie die FE eingeschaltet ist.
• Wird vom Prüfgerät ein bereits laufender Diagnosevorgang angefordert, sendet die FE eine positive Antwortnachricht (Positive Response).
• Fordert das Prüfgerät einen neuen Diagnosevorgang an, sendet die FE zuerst eine positive Antwortnachricht auf "StartDiagnosticSession", bevor der neue Diagnosevorgang in der FE aktiviert wird. Kann die FE 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 FE 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 Anforderungsnachricht StartDiagnosticSession

Tabelle 15 Nachricht Positive Response auf StartDiagnosticSession

Tabelle 16 Nachricht Negative Response auf StartDiagnosticSession

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

5.2. Der Dienst SecurityAccess

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

Der Dienst SecurityAccess stellt die Möglichkeit zur PIN-Eingabe bereit und zeigt dem Prüfgerät an, ob sich die FE 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 Anforderung requestSeed, der möglicherweise eine Nachricht sendKey folgt. Der Dienst SecurityAccess muss nach dem Dienst StartDiagnosticSession ausgeführt werden.

CPR_033 Mit der SecurityAccess-Anforderung 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 mit Hilfe 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, mit Hilfe 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 SecurityAccess-Nachricht sendKey, um eine PIN an die Fahrzeugeinheit zu übergeben. Um ausreichend Zeit für den Prozess der Kartenauthentisierung zu gewähren, sendet die FE den negativen Antwortcode "requestCorrectlyReceived-ResponsePending", mit dem die Antwortzeit verlängert wird. Die längstmögliche Wartezeit darf jedoch 5 Minuten nicht überschreiten. Sobald der angeforderte Dienst abgeschlossen ist, sendet die FE eine positive oder negative Antwortnachricht mit einem anderen Antwortcode als diesem. Der negative Antwortcode "requestCorrectlyReceived-ResponsePending" kann so oft von der FE 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 Anforderungsnachricht SecurityAccess

Tabelle 19 Nachricht Positive Response auf SecurityAccess requestSeed

Tabelle 20 Nachricht Negative Response auf SecurityAccess

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

Tabelle 22 Nachricht Positive Response auf SecurityAccess - sendKey

Tabelle 23 Nachricht Negative Response auf SecurityAccess

6. Datenübertragungsdienste

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

Tabelle 24 Datenübertragungsdienste

6.1. Der 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 mit 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 Anforderungsnachricht ReadDataByIdentifier

Tabelle 26 Nachricht Positive Response auf ReadDataByIdentifier

Tabelle 27 Nachricht Negative Response auf ReadDataByIdentifier

6.1.3. Parameterdefinition

CPR_052 Der Parameter recordDataIdentifier (RDI_) in der Anforderungsnachricht Read-DataByIdentifier kennzeichnet einen Datensatz.

CPR_053 Die hier definierten Werte für recordDataIdentifier sind der folgenden Tabelle aufgeführt.

Die Tabelle recordDataIdentifier enthält 4 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 (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. FE-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 Daten sind durch einen recordDataIdentifier gekennzeichnet. 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 FE 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 Anforderungsnachricht WriteDataByIdentifier

Tabelle 30 Nachricht Positive Response auf WriteDataByIdentifier

Tabelle 31 Nachricht Negative Response auf WriteDataByIdentifier

6.2.3. Parameterdefinition

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

Der Parameter dataRecord (DREC_) dient der Aufforderungsnachricht WriteDataByIdentifier dazu, dem Server (FE) 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,
• speedSignalInput: über die Kalibrierungs-E/A-Signalleitung wird ein Geschwindigkeitssignal (Testsignal) eingegeben, das das Geschwindigkeitssignal des Weg- und Geschwindigkeitsgebers ersetzt,
• realTimeSpeedSignalOutputSensor: über die Kalibrierungs-E/A-Signalleitung wird das Geschwindigkeitssignal des Weg- und Geschwindigkeitsgebers ausgegeben,
• RTCOutput: über die Kalibrierungs-E/A-Signalleitung wird das UTC-Zeitsignal ausgegeben.

CPR_059 Um den Leitungsstatus zu konfigurieren, muss sich die Fahrzeugeinheit in einem Einstellvorgang befinden und in die Betriebsart KALIBRIERUNG gesetzt sein. Bei Verlassen des Einstellvorgangs bzw. der Betriebsart KALIBRIERUNG 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 FE 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 (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 Anforderungsnachricht InputOutputControlByIdentifier

Tabelle 34 Nachricht Positive Response auf InputOutputControlByIdentifier

weiter .