{
  "url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-8",
  "json_url": "https://openlegislation.uk/eu-regulation-1985-3821/annex-2/appendix-8.json",
  "legislation": "eur/1985/3821",
  "legislation_title": "Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport",
  "legislation_url": "https://openlegislation.uk/eu-regulation-1985-3821",
  "path": "annex/2/appendix/8",
  "kind": "appendix",
  "number": "8",
  "heading": "CALIBRATION PROTOCOL",
  "text": "1.\nINTRODUCTION\nThis appendix describes how data is exchanged between a vehicle unit and a tester via the K-line which forms part of the calibration interface described in Appendix 6. It also describes control of the input/output signal line on the calibration connector.\nEstablishing K-line communications is described in Section 4 ‘ Communication Services ’ .\nThis appendix uses the idea of diagnostic ‘ sessions ’ to determine the scope of K-line control under different conditions. The default session is the ‘ StandardDiagnosticSession ’ where all data can be read from a vehicle unit but no data can be written to a vehicle unit.\nSelection of the diagnostic session is described in Section 5 ‘ Management Services ’ .\nCPR_001 The ‘ ECUProgrammingSession ’ allows data entry into the vehicle unit. In the case of entry of calibration data (requirements 097 and 098), the vehicle unit must, in addition be in the CALIBRATION mode of operation.\nData transfer via K-line is described in Section 6 ‘ Data Transmission Services ’ . Formats of data transferred are detailed in Section 8 ‘ dataRecords formats ’ .\nCPR_002 The ‘ ECUAdjustmentSession ’ allows the selection of the I/O mode of the calibration I/O signal line via the K-line interface. Control of the calibration I/O signal line is described in section 7 ‘ Control of Test Pulses — Input/Output Control functional unit ’ .\nCPR_003 Throughout this document the address of the tester is referred to as ′tt′. Although there may be preferred addresses for testers, the VU shall respond correctly to any tester address. The physical address of the VU is 0xEE.\n2.\nTERMS, DEFINITIONS AND REFERENCES\nThe protocols, messages and error codes are principally based on the current draft to date of ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic services, version 6 of 22 February 2001 ).\nByte encoding and hexadecimal values are used for the service identifiers, the service requests and responses, and the standard parameters.\nThe term ‘ tester ’ refers to the equipment used to enter programming/calibration data into the VU.\nThe terms ‘ client ’ and ‘ server ’ refer to the tester and the VU respectively.\nThe term ECU means ‘ Electronic Control Unit ’ and refers to the VU.\nReferences:\nISO 14230-2 Road Vehicles — Diagnostic Systems — Keyword Protocol 2000- Part 2: Data Link Layer. First edition: 1999. Vehicles — Diagnostic Systems.\n3.\nOVERVIEW OF SERVICES\n3.1.\nServices available\nThe following table provides an overview of the services that will be available in the recording equipment and are defined in this document.\nCPR_004 The table indicates the services that are available in an enabled diagnostic session.\nThe first column lists the services that are available,\nthe second column includes the section number in this appendix where of service is further defined,\nthe third column assigns the assigns the service identifier values for request messages,\nthe fourth column specifies the services of the ‘ StandardDiagnosticSession ’ (SD) which must be implemented in each VU,\nthe fifth column specifies the services of the ‘ ECUAdjustmentSession ’ (ECUAS) which must be implemented to allow control of the I/O signal line in the front panel calibration connector of the VU,\nthe sixth column specifies the services of the ‘ ECUProgrammingSession ’ (ECUPS) which must be implemented to allow for programming of parameters in the VU.\nTable 1\nService Identifier value summary table\n■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session.\nDiagnostic Service Name\nSection No\nSId Req.Value\nDiagnostic Sessions\nSD\nECUAS\nECUPS\nStartCommunication\n4.1\n81\nStopCommunication\n4.2\n82\nTesterPresent\n4.3\n3E\nStartDiagnosticSession\n5.1\n10\nSecurityAccess\n5.2\n27\nReadDataByIdentifier\n6.1\n22\nWriteDataByIdentifier\n6.2\n2E\nInputOutputControlByIdentifier\n7.1\n2F\n3.2.\nResponse codes\nResponse codes are defined for each service.\n4.\nCOMMUNICATION SERVICES\nSome services are necessary to establish and maintain communication. They do not appear on the application layer. The services available are detailed in the following table:\nTable 2\nCommunication services\nService name\nDescription\nStartCommunication\nThe client requests to start a communication session with a server(s)\nStopCommunication\nThe client requests to stop the current communication session\nTesterPresent\nThe client indicates to the server that it is still present\nCPR_005 The StartCommunication Service is used for starting a communication. In order to perform any service, communication must be initialised and the communication parameters need to be appropriate for the desired mode.\n4.1.\nStartCommunication Service\nCPR_006 Upon receiving a StartCommunication indication primitive, the VU shall check if the requested communication link can be initialised under the present conditions. Valid conditions for the initialisation of a communication link are described in document ISO 14230-2.\nCPR_007 Then the VU shall perform all actions necessary to initialise the communication link and send a StartCommunication response primitive with the positive response parameters selected.\nCPR_008 If a VU that is already initialised (and has entered any diagnostic session) receives a new StartCommunication request (e.g. due to error recovery in the tester) the request shall be accepted and the VU shall be re-initialised.\nCPR_009 If the communication link cannot be initialised for any reason, the VU shall continue operating as it was immediately prior to the attempt to initialise the communication link.\nCPR_010 The StartCommunication Request message must be physically addressed.\nCPR_011 Initialising the VU for services is performed through a ‘ fast initialisation ’ method,\nthere is a bus-idle time prior to any activity,\nthe tester then sends an initialisation pattern,\nall information which is necessary to establish communication is contained in the response of the VU.\nCPR_012 After completion of the initialisation,\nall communication parameters are set to values defined in Table 4 according to the key bytes,\nthe VU is waiting for the first request of the tester,\nthe VU is in the default diagnostic mode, i.e. StandardDiagnosticSession,\nthe calibration I/O signal line is in the default state, i.e. disabled state.\nCPR_014 The data rate on the K-line shall be 10 400 Baud.\nCPR_016 The fast initialisation is started by the tester transmitting a wake-up pattern (Wup) on the K-line. The pattern begins after the idle time on K-line with a low time of Tinil. The tester transmits the first bit of the StartCommunication Service after a time of Twup following the first falling edge.\nCPR_017 The timing values for the fast initialisation and communications in general are detailed in the tables below. There are different possibilities for the idle time:\nfirst transmission after power on, T idle = 300 ms.\nafter completion of a StopCommunication Service, T idle = P3 min.\nAfter stopping communication by time-out P3 max, T idle = 0.\nTable 3\nTiming values for fast initialisation\nParameter\nminimum value\nmaximum value\nTinil\n25 ± 1 ms\n24 ms\n26 ms\nTwup\n50 ± 1 ms\n49 ms\n51 ms\nTable 4\nCommunication timing values\nTiming parameter\nParameter description\nLower limit values (ms)\nUpper limit values (ms)\nminimum\nmaximum\nP1\nInter byte time for VU response\n0\n20\nP2\nTime between tester request and VU response or two VU responses\n25\n250\nP3\nTime between end of VU responses and start of new tester request\n55\n5 000\nP4\nInter byte time for tester request\n5\n20\nCPR_018 The message format for fast initialisation is detailed in the following tables:\nTable 5\nStartCommunication request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n81\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nStartCommunication Request Service\n81\nSCR\n#5\nChecksum\n00-FF\nCS\nTable 6\nStartCommunication positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nStartCommunication Positive Response Service Id\nC1\nSCRPR\n#6\nKey byte 1\nEA\nKB1\n#7\nKey byte 2\n8F\nKB2\n#8\nChecksum\n00-FF\nCS\nCPR_019 There is no negative response to the StartCommunication Request message, if there is no positive response message to be transmitted then the VU is not initialised, nothing is transmitted and it remains in its normal operation.\n4.2.\nStopCommunication service\n4.2.1.\nMessage description\nThe purpose of this communication layer service is to terminate a communication session.\nCPR_020 Upon receiving a StopCommunication indication primitive, the VU shall check if the current conditions allow to terminate this communication. In this case the VU shall perform all actions necessary to terminate this communication.\nCPR_021 If it is possible to terminate the communication, the VU shall issue a StopCommunication response primitive with the Positive Response parameters selected, before the communication is terminated.\nCPR_022 If the communication cannot be terminated by any reason, the VU shall issue a StopCommunication response primitive with the Negative Response parameter selected.\nCPR_023 If time -out of P3max is detected by the VU, the communication shall be terminated without any response primitive being issued.\n4.2.2.\nMessage format\nCPR_024 The message formats for the StopCommunication primitives are detailed in the following tables:\nTable 7\nStopCommunication request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n01\nLEN\n#5\nStopCommunication Request Service Id\n82\nSPR\n#6\nChecksum\n00-FF\nCS\nTable 8\nStopCommunication positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n01\nLEN\n#5\nStopCommunication Positive Response Service\nC2\nSPRPR\n#6\nChecksum\n00-FF\nCS\nTable 9\nStopCommunication negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegative Response Service Id\n7F\nNR\n#6\nStopCommunication Request Service Identification\n82\nSPR\n#7\nresponseCode = generalReject\n10\nRC_GR\n#8\nChecksum\n00-FF\nCS\n4.2.3.\nParameter definition\nThis service does not require any parameter definition.\n4.3.\nTesterPresent service\n4.3.1.\nMessage description\nThe TesterPresent service is used by the tester to indicate to the server that it is still present, in order to prevent the server from automatically returning to normal operation and possibly stopping the communication. This service, sent periodically, keeps the diagnostic session/communication active by resetting the P3 timer each time a request for this service is received.\n4.3.2.\nMessage format\nCPR_079 The message formats for the TesterPresent primitives are detailed in the following tables.\nTable 10\nTesterPresent request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nTesterPresent Request Service Id\n3E\nTP\n#6\nSub Function = responseRequired = [yes\nno]\n01\n02\nRESPREQ_Y\nRESPREQ_NO\n#7\nChecksum\n00-FF\nCS\nCPR_080 If the responseRequired parameter is set to ‘ yes ’ , then the server shall respond with the following positive response message. If set to ‘ no ’ , then no response is sent by the server.\nTable 11\nTesterPresent positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n01\nLEN\n#5\nTesterPresent Positive Response Service Id\n7E\nTPPR\n#6\nChecksum\n00-FF\nCS\nCPR_081 The service shall support the following negative responses codes:\nTable 12\nTesterPresent negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegative Response Service Id\n7F\nNR\n#6\nTesterPresent Request Service Identification\n3E\nTP\n#7\nresponseCode = [SubFunctionNotSupported-InvalidFormat\nincorrectMessageLength]\n12\n13\nRC_SFNS_IF\nRC_IML\n#8\nChecksum\n00-FF\nCS\n5.\nMANAGEMENT SERVICES\nThe services available are detailed in the following table:\nTable 13\nManagement services\nService name\nDescription\nStartDiagnosticSession\nThe client requests to start a diagnostic session with a VU\nSecurityAccess\nThe client requests access to functions restricted to authorised users\n5.1.\nStartDiagnosticSession service\n5.1.1.\nMessage description\nCPR_025 The service StartDiagnosticSession is used to enable different diagnostic sessions in the server. A diagnostic session enables a specific set of services according to Table 17. A session can enable vehicle manufacturer specific services which are not part of this document. Implementation rules shall conform to the following requirements:\nthere shall be always exactly one diagnostic session active in the VU,\nthe VU shall always start the StandardDiagnosticSession when powered up. If no other diagnostic session is started, then the StandardDiagnosticSession shall be running as long as the VU is powered,\nif a diagnostic session which is already running has been requested by the tester, then the VU shall send a positive response message,\nwhenever the tester requests a new diagnostic session, the VU shall first send a StartDiagnosticSession positive response message before the new session becomes active in the VU. If the VU is not able to start the requested new diagnostic session, then it shall respond with a StartDiagnosticSession negative response message, and the current session shall continue.\nCPR_026 The diagnostic session shall only be started if communication has been established between the client and the VU.\nCPR_027 The timing parameters defined in Table 4 shall be active after a successful StartDiagnosticSession with the diagnosticSession parameter set to ‘ StandardDiagnosticSession ’ in the request message if another diagnostic session was previously active.\n5.1.2.\nMessage format\nCPR_028 The message formats for the StartDiagnosticSession primitives are detailed in the following tables:\nTable 14\nStartDiagnosticSession request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nStartDiagnosticSession request service Id\n10\nSTDS\n#6\ndiagnosticSession = (one value from Table 17)\nxx\nDS_ …\n#7\nChecksum\n00-FF\nCS\nTable 15\nStartDiagnosticSession positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nStartDiagnosticSession Positive Response Service Id\n50\nSTDSPR\n#6\nDiagnosticSession = (same value as in byte #6 Table 14)\nxx\nDS_ …\n#7\nChecksum\n00-FF\nCS\nTable 16\nStartDiagnosticSession negative response message\nThe value inserted in byte #6 of the request message is not supported, i.e. not in Table 17.\nThe length of the message is wrong.\nThe criteria for the request StartDiagnosticSession are not met.\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegative response service Id\n7F\nNR\n#6\nStartDiagnosticSession request service Id\n10\nSTDS\n#7\nResponseCode = (subFunctionNotSupported\nincorrectMessageLength\n12\n13\nRC_SFNS\nRC_IML\nconditionsNotCorrect )\n22\nRC_CNC\n#8\nChecksum\n00-FF\nCS\n5.1.3.\nParameter definition\nCPR_029 The parameter diagnosticSession (DS_) is used by the StartDiagnosticSession service to select the specific behaviour of the server(s). The following diagnostic sessions are specified in this document:\nTable 17\nDefinition of diagnosticSession values\nHex\nDescription\nMnemonic\n81\nStandardDiagnosticSession\nThis diagnostic session enables all services specified in Table 1 column 4 ‘ SD ’ . These services allow reading of data from a server (VU). This diagnostic Session is active after the initialisation has been successfully completed between client (tester) and server (VU). This diagnostic session may be overwritten by other diagnostic sessions specified in this section.\nSD\n85\nECUProgrammingSession\nThis diagnostic session enables all services specified in Table 1 column 6 ‘ ECUPS ’ . These services support the memory programming of a server (VU) This diagnostic session may be overwritten by other diagnostic sessions specified in this section.\nECUPS\n87\nECUAdjustmentSession\nThis diagnostic session enables all services specified in Table 1 column 5 ‘ ECUAS ’ . These services support the input/output control of a server (VU). This diagnostic session may be overwritten by other diagnostic sessions specified in this section.\nECUAS\n5.2.\nSecurityAccess service\nWriting of calibration data or access to the calibration input/output line is not possible unless the VU is in CALIBRATION mode. In addition to insertion of a valid workshop card into the VU, it is necessary to enter the appropriate PIN into the VU before access to the CALIBRATION mode is granted.\nThe SecurityAccess service provides a means to enter the PIN and to indicate to the tester whether or not the VU is in CALIBRATION mode.\nIt is acceptable that the PIN may be entered through alternative methods.\n5.2.1.\nMessage description\nThe SecurityAccess service consists of a SecurityAccess ‘ requestSeed ’ message, eventually followed by a SecurityAccess ‘ sendKey ’ message. The SecurityAccess service must be carried out after the StartDiagnosticSession service.\nCPR_033 The tester shall use the SecurityAccess \"requestSeed\" message to check if the vehicle unit is ready to accept a PIN.\nCPR_034 If the vehicle unit is already in CALIBRATION mode, it shall answer the request by sending a ‘ seed ’ of 0x0000 using the service SecurityAccess Positive Response.\nCPR_035 If the vehicle unit is ready to accept a PIN for verification by a workshop card, it shall answer the request by sending a ‘ seed ’ greater than 0x0000 using the service SecurityAccess positive response.\nCPR_036 If the vehicle unit is not ready to accept a PIN from the tester, either because the workshop card inserted is not valid, or because no workshop card has been inserted, or because the vehicle unit expects the PIN from another method, it shall answer the request with a negative response with a response code set to conditionsNotCorrectOrRequestSequenceError.\nCPR_037 The tester shall then, eventually, use the SecurityAccess ‘ sendKey ’ message to forward a PIN to the Vehicle Unit. To allow time for the card authentication process to take place, the VU shall use the negative response code requestCorrectlyReceived-ResponsePending to extend the time to respond. However, the maximum time to respond shall not exceed five minutes. As soon as the requested service has been completed, the VU shall send a positive response message or negative response message with a response code different from this one. The negative response code requestCorrectlyReceived-ResponsePending may be repeated by the VU until the requested service is completed and the final response message is sent.\nCPR_038 The vehicle unit shall answer to this request using the service SecurityAccess Positive Response only when in CALIBRATION mode.\nCPR_039 In the following cases, the vehicle unit shall answer to this request with a Negative Response with a response code set to:\nsubFunctionNot supported: invalid format for the subfunction parameter (accessType),\nconditionsNotCorrectOrRequestSequenceError: vehicle unit not ready to accept a PIN entry,\ninvalidKey: PIN not valid and number of PIN checks attempts not exceeded,\nexceededNumberOfAttempts: PIN not valid and number of PIN checks attempts exceeded,\ngeneralReject: Correct PIN but mutual authentication with workshop card failed.\n5.2.2.\nMessage format — SecurityAccess — requestSeed\nCPR_040 The message formats for the SecurityAccess ‘ requestSeed ’ primitives are detailed in the following tables:\nTable 18\nSecurityAccess request — requestSeed message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nSecurityAccess request service Id\n27\nSA\n#6\naccessType — requestSeed\n7D\nAT_RSD\n#7\nChecksum\n00-FF\nCS\nTable 19\nSecurityAccess — requestSeed positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n04\nLEN\n#5\nSecurityAccess positive response service Id\n67\nSAPR\n#6\naccessType — requestSeed\n7D\nAT_RSD\n#7\nSeed High\n00-FF\nSEEDH\n#8\nSeed Low\n00-FF\nSEEDL\n#9\nChecksum\n00-FF\nCS\nTable 20\nSecurityAccess negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegativeResponse Service Id\n7F\nNR\n#6\nSecurityAccess request service Id\n27\nSA\n#7\nresponseCode = (conditionsNotCorrectOrRequestSequenceError\nincorrectMessageLength)\n22\n13\nRC_CNC\nRC_IML\n#8\nChecksum\n00-FF\nCS\n5.2.3.\nMessage format — SecurityAccess — sendKey\nCPR_041 The message formats for the SecurityAccess ‘ sendKey ’ primitives are detailed in the following tables:\nTable 21\nSecurityAccess request — sendKey message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\nm+2\nLEN\n#5\nSecurityAccess Request Service Id\n27\nSA\n#6\naccessType — sendKey\n7E\nAT_SK\n#7 to #m+6\nKey #1 (High)\nxx\nKEY\n…\n…\nKey #m (low, m must be a minimum of 4, and a maximum of 8)\nxx\n#m+7\nChecksum\n00-FF\nCS\nTable 22\nSecurityAccess — sendKey positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nSecurityAccess positive response service Id\n67\nSAPR\n#6\naccessType — sendKey\n7E\nAT_SK\n#7\nChecksum\n00-FF\nCS\nTable 23\nSecurityAccess negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegativeResponse Service Id\n7F\nNR\n#6\nSecurityAccess request service Id\n27\nSA\n#7\nResponseCode = (generalReject\nsubFunctionNotSupported\n10\n12\nRC_GR\nRC_SFNS\nincorrectMessageLength\n13\nRC_IML\nconditionsNotCorrectOrRequestSequenceError\n22\nRC_CNC\ninvalidKey\n35\nRC_IK\nexceededNumberOfAttempts\n36\nRC_ENA\nrequestCorrectlyReceived-ResponsePending)\n78\nRC_RCR_RP\n#8\nChecksum\n00-FF\nCS\n6.\nDATA TRANSMISSION SERVICES\nThe services available are detailed in the following table:\nTable 24\nData transmission services\nService name\nDescription\nReadDataByIdentifier\nThe client requests the transmission of the current value of a record with access by recordDataIdentifier\nWriteDataByIdentifier\nThe client requests to write a record accessed by recordDataIdentifier\n6.1.\nReadDataByIdentifier service\n6.1.1.\nMessage description\nCPR_050 The ReadDataByIdentifier service is used by the client to request data record values from a server. The data are identified by a recordDataIdentifier. It is the VU manufacturer's responsibility that the server conditions are met when performing this service.\n6.1.2.\nMessage format\nCPR_051 The message formats for the ReadDataByIdentifier primitives are detailed in the following tables:\nTable 25\nReadDataByIdentifier request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nReadDataByIdentifier Request Service Id\n22\nRDBI\n#6 and #7\nrecordDataIdentifier = (a value from Table 8)\nxxxx\nRDI_ …\n#8\nChecksum\n00-FF\nCS\nTable 26\nReadDataByIdentifier positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\nm+3\nLEN\n#5\nReadDataByIdentifier Positive Response Service Id\n62\nRDBIPR\n#6 and #7\nrecordDataIdentifier = (the same value as bytes #6 and #7 Table 25)\nxxxx\nRDI_ …\n#8 to #m+7\ndataRecord() = (data#1\n:\ndata#m)\nxx\n:\nxx\nDREC_DATA1\n:\nDREC_DATAm\n#m+8\nChecksum\n00-FF\nCS\nTable 27\nReadDataByIdentifier negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegativeResponse Service Id\n7F\nNR\n#6\nReadDataByIdentifier Request Service Id\n22\nRDBI\n#7\nResponseCode = (requestOutOfRange\nincorrectMessageLength\n31\n13\nRC_ROOR\nRC_IML\nconditionsNotCorrect)\n22\nRC_CNC\n#8\nChecksum\n00-FF\nCS\n6.1.3.\nParameter definition\nCPR_052 The parameter recordDataIdentifier (RDI_) in the ReadDataByIdentifier request message identifies a data record.\nCPR_053 recordDataIdentifier values defined by this document are shown in the table below.\nThe recordDataIdentifier table consists of four columns and multiple lines.\nThe first column (Hex) includes the ‘ hex value ’ assigned to the recordDataIdentifier specified in the third column.\nThe second column (Data element) specifies the data element of Appendix 1 on which the recordDataIdentifier is based (transcoding is sometimes necessary).\nThe third column (Description) specifies the corresponding recordDataIdentifier name.\nThe fourth column (Mnemonic) specifies the mnemonic of this recordDataIdentifier.\nTable 28\nDefinition of recordDataIdentifier values\nHex\nData element\nrecordDataIdentifier Name (see format in Section 8.2)\nMnemonic\nF90B\nCurrentDateTime\nTimeDate\nRDI_TD\nF912\nHighResOdometer\nHighResolutionTotalVehicleDistance\nRDI_HRTVD\nF918\nK-ConstantOfRecordingEquipment\nKfactor\nRDI_KF\nF91C\nL-TyreCircumference\nLfactorTyreCircumference\nRDI_LF\nF91D\nW-VehicleCharacteristicConstant\nWvehicleCharacteristicFactor\nRDI_WVCF\nF921\nTyreSize\nTyreSize\nRDI_TS\nF922\nnextCalibrationDate\nNextCalibrationDate\nRDI_NCD\nF92C\nSpeedAuthorised\nSpeedAuthorised\nRDI_SA\nF97D\nvehicleRegistrationNation\nRegisteringMemberState\nRDI_RMS\nF97E\nVehicleRegistrationNumber\nVehicleRegistrationNumber\nRDI_VRN\nF190\nVehicleIdentificationNumber\nVIN\nRDI_VIN\nCPR_054 The parameter dataRecord (DREC_) is used by the ReadDataByIdentifier positive response message to provide the data record value identified by the recordDataIdentifier to the client (tester). Data formats are specified in Section 8. Additional user optional dataRecords including VU specific input, internal and output data may be implemented, but are not defined in this document.\n6.2.\nWriteDataByIdentifier service\n6.2.1.\nMessage description\nCPR_056 The WriteDataByIdentifier service is used by the client to write data record values to a server. The data are identified by a recordDataIdentifier. It is the VU manufacturer's responsibility that the server conditions are met when performing this service. To update the parameters listed in Table 28 the VU must be in CALIBRATION mode.\n6.2.2.\nMessage format\nCPR_057 The message formats for the WriteDataByIdentifier primitives are detailed in the following tables:\nTable 29\nWriteDataByIdentifier request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\nm+3\nLEN\n#5\nWriteDataByIdentifier request service Id\n2E\nWDBI\n#6 and #7\nrecordDataIdentifier = (a value from Table 28)\nxxxx\nRDI_ …\n#8 to #m+7\ndataRecord() = (data#1\n:\ndata#m)\nxx\n:\nxx\nDREC_DATA1\n:\nDREC_DATAm\n#m+8\nChecksum\n00-FF\nCS\nTable 30\nWriteDataByIdentifier positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nWriteDataByIdentifier positive response service Id\n6E\nWDBIPR\n#6 and #7\nrecordDataIdentifier = (the same value as bytes #6 and #7 Table 29)\nxxxx\nRDI_ …\n#8\nChecksum\n00-FF\nCS\nTable 31\nWriteDataByIdentifier negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegativeResponse Service Id\n7F\nNR\n#6\nWriteDataByIdentifier request service Id\n2E\nWDBI\n#7\nResponseCode = (requestOutOfRange\nincorrectMessageLength\n31\n13\nRC_ROOR\nRC_IML\nconditionsNotCorrect)\n22\nRC_CNC\n#8\nChecksum\n00-FF\nCS\n6.2.3.\nParameter definition\nThe parameter recordDataIdentifier (RDI_) is defined in Table 28.\nThe parameter dataRecord (DREC_) is used by the WriteDataByIdentifier request message to provide the data record values identified by the recordDataIdentifier to the server (VU). Data formats are specified in Section 8.\n7.\nCONTROL OF TEST PULSES — INPUT/OUTPUT CONTROL FUNCTIONAL UNIT\nThe services available are detailed in the following table:\nTable 32\nInput/Output control functional unit\nService name\nDescription\nInputOutputControlByIdentifier\nThe client requests the control of an input/output specific to the server\n7.1.\nMessage description\n7.1.1.\nMessage description\nThere is a connection via the front connector which allows test pulses to be controlled or monitored using a suitable tester.\nCPR_058 This calibration I/O signal line can be configured by K-line command using the InputOutputControlByIdentifier service to select the required input or output function for the line. The available states of the line are:\ndisabled,\nspeedSignalInput, where the calibration I/O signal line is used to input a speed signal (test signal) replacing the motion sensor speed signal,\nrealTimeSpeedSignalOutputSensor, where the calibration I/O signal line is used to output the speed signal of the motion sensor,\nRTCOutput, where the calibration I/O signal line is used to output the UTC clock signal.\nCPR_059 The vehicle unit must have entered an adjustment session and must be in CALIBRATION mode to configure the state of the line. On exit of the adjustment session or of the CALIBRATION mode the vehicle unit must ensure the calibration I/O signal line is returned to the ‘ disabled ’ (default) state.\nCPR_060 If speed pulses are received at the real time speed signal input line of the VU while the calibration I/O signal line is set to input then the calibration I/O signal line shall be set to output or returned to the disabled state.\nCPR_061 The sequence shall be:\nestablish communications by StartCommunication Service\nenter an adjustment session by StartDiagnosticSession Service and be in CALIBRATION mode of operation (the order of these two operations is not important).\nchange the state of the output by InputOutputControlByIdentifier Service.\n7.1.2.\nMessage format\nCPR_062 The message formats for the InputOutputControlByIdentifier primitives are detailed in the following tables:\nTable 33\nInputOutputControlByIdentifier request message\nNote: The controlState parameter is present only in some cases (see 7.1.3).\nByte #\nParameter name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\nxx\nLEN\n#5\nInputOutputControlByIdentifier request Sid\n2F\nIOCBI\n#6 and #7\nInputOutputIdentifier = (CalibrationInputOutput)\nF960\nIOI_CIO\n#8 or #8 to #9\nControlOptionRecord = (\ninputOutputControlParameter — one value from Table 36\nxx\nCOR_ …\nIOCP_ …\ncontrolState — one value from Table 38 (see note below))\nxx\nCS_ …\n#9 or #10\nChecksum\n00-FF\nCS\nTable 34\nInputOutputControlByIdentifier positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\nxx\nLEN\n#5\ninputOutputControlByIdentifier positive response SId\n6F\nIOCBIPR\n#6 and #7\ninputOutputIdentifier = (CalibrationInputOutput)\nF960\nIOI_CIO\n#8 or #8 to #9\ncontrolStatusRecord = (\ninputOutputControlParameter (same value as byte #8 Table 33)\nxx\nCSR_\nIOCP_ …\ncontrolState (same value as byte #9 Table 33)) (if applicable)\nxx\nCS_ …\n#9 or #10\nChecksum\n00-FF\nCS\nTable 35\nInputOutputControlByIdentifier negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegativeResponse Service Id\n7F\nNR\n#6\ninputOutputControlByIdentifier request SId\n2F\nIOCBI\n#7\nresponseCode = (\nincorrectMessageLength\n13\nRC_IML\nconditionsNotCorrect\n22\nRC_CNC\nrequestOutOfRange\n31\nRC_ROOR\ndeviceControlLimitsExceeded)\n7A\nRC_DCLE\n#8\nChecksum\n00-FF\nCS\n7.1.3.\nParameter definition\nCPR_064 The parameter inputOutputControlParameter (IOCP_) is defined in the following table:\nTable 36\nDefinition of inputOutputControlParameter values\nHex\nDescription\nMnemonic\n00\nReturnControlToECU\nThis value shall indicate to the server (VU) that the tester does no longer have control about the calibration I/O signal line.\nRCTECU\n01\nResetToDefault\nThis value shall indicate to the server (VU) that it is requested to reset the calibration I/O signal line to its default state.\nRTD\n03\nShortTermAdjustment\nThis value shall indicate to the server (VU) that it is requested to adjust the calibration I/O signal line to the value included in the controlState parameter.\nSTA\nCPR_065 The parameter controlState is present only when the inputOutputControlParameter is set to ShortTermAdjustment and is defined in the following table:\nTable 37\nDefinition of controlState values\nMode\nHex value\nDescription\nDisable\n00\nI/O line is disabled (default state)\nEnable\n01\nEnable calibration I/O line as speedSignalInput\nEnable\n02\nEnable calibration I/O line as realTimeSpeedSignalOutputSensor\nEnable\n03\nEnable calibration I/O line as RTCOutput\n8.\nDATARECORDS FORMATS\nThis section details:\ngeneral rules that shall be applied to ranges of parameters transmitted by the vehicle unit to the tester,\nformats that shall be used for data transferred via the Data Transmission Services described in Section 6.\nCPR_067 All parameters identified shall be supported by the VU.\nCPR_068 Data transmitted by the VU to the tester in response to a request message shall be of the measured type (i.e. current value of the requested parameter as measured or observed by the VU).\n8.1.\nTransmitted parameter ranges\nCPR_069 Table 38 defines the ranges used to determine the validity of a transmitted parameter.\nCPR_070 The values in the range ‘ error indicator ’ provide a means for the vehicle unit to immediately indicate that valid parametric data is not currently available due to some type of error in the recording equipment.\nCPR_071 The values in the range ‘ not available ’ provide a means for the vehicle unit to transmit a message which contains a parameter that is not available or not supported in that module. The values in the range ‘ not requested ’ provide a means for a device to transmit a command message and identify those parameters where no response is expected from the receiving device.\nCPR_072 If a component failure prevents the transmission of valid data for a parameter, the error indicator as described in Table 38 should be used in place of that parameter's data. However, if the measured or calculated data has yielded a value that is valid yet exceeds the defined parameter range, the error indicator should not be used. The data should be transmitted using the appropriate minimum or maximum parameter value.\nTable 38\ndataRecords ranges\nRange Name\n1 byte (Hex value)\n2 bytes (Hex value)\n4 bytes (Hex value)\nASCII\nValid signal\n00 to FA\n0000 to FAFF\n00000000 to FAFFFFFF\n1 to 254\nParameter specific indicator\nFB\nFB00 to FBFF\nFB000000 to FBFFFFFF\nnone\nReserved range for future indicator bits\nFC to FD\nFC00 to FDFF\nFC000000 to FDFFFFFF\nnone\nError indicator\nFE\nFE00 to FEFF\nFE000000 to FEFFFFFF\n0\nNot available or not requested\nFF\nFF00 to FFFF\nFF000000 to FFFFFFFF\nFF\nCPR_073 For parameters coded in ASCII, the ASCII character ‘ * ’ is reserved as a delimiter.\n8.2.\ndataRecords formats\nTables 39 to 42 below detail the formats that shall be used via the ReadDataByIdentifier and WriteDataByIdentifier Services.\nCPR_074 Table 39 provides the length, resolution and operating range for each parameter identified by its recordDataIdentifier\nTable 39\nFormat of dataRecords\nParameter Name\nData length (bytes)\nResolution\nOperating range\nTimeDate\n8\nSee details in Table 40\nHighResolutionTotalVehicleDistance\n4\n5 m/bit gain, 0 m offset\n0 to + 21 055 406 km\nKfactor\n2\n0,001 pulse/m/bit gain, offset 0\n0 to 64,255 pulse/m\nLfactorTyreCircumference\n2\n0,125 10 -3 /bit gain, 0 offset\n0 to 8,031 m\nWvehicleCharacteristicFactor\n2\n0,001 pulse/m/bit gain, 0 offset\n0 to 64,255 pulse/m\nTyreSize\n15\nASCII\nASCII\nNextCalibrationDate\n3\nSee details in Table 41\nSpeedAuthorised\n2\n1/256 km/h/bit gain, 0 offset\n0 to 250,996 km/h\nRegisteringMemberState\n3\nASCII\nASCII\nVehicleRegistrationNumber\n14\nSee details in Table 42\nVIN\n17\nASCII\nASCII\nCPR_075 Table 40 details the formats of the different bytes of the TimeDate parameter:\nTable 40\nDetailed format of TimeDate ( recordDataIdentifier value # F90B )\nByte\nParameter definition\nResolution\nOperating range\n1\nSeconds\n0,25 s/bit gain, 0 s offset\n0 to 59,75 s\n2\nMinutes\n1 min/bit gain, 0 min offset\n0 to 59 min\n3\nHours\n1 h/bit gain, 0 h offset\n0 to 23 h\n4\nMonth\n1 month/bit gain, 0 month offset\n1 to 12 month\n5\nDay\n0,25 day/bit gain, 0 day offset (see Note below Table 41)\n0,25 to 31,75 day\n6\nYear\n1 year/bit gain, +1985 year offset (see Note below Table 41)\n1985 to 2235 year\n7\nLocal Minute Offset\n1 min/bit gain, - 125 min offset\n-59 to +59 min\n8\nLocal Hour Offset\n1 h/bit gain, - 125 h offset\n- 23 to + 23 h\nCPR_076 Table 41 details the formats of the different bytes of the NextCalibrationDate parameter:\nTable 41\nDetailed format of NextCalibrationDate ( recordDataIdentifier value # F922 )\nNote conerning the use of the ‘ Day ’ parameter:\n1.. A value of 0 for the date is null. The values 1, 2, 3, and 4 are used to identify the first day of the month; 5, 6, 7, and 8 identify the second day of the month; etc.\n2.. This parameter does not influence or change the hours parameter above.\nNote concerning the use of byte ‘ Year ’ parameter:\nA value of 0 for the year identifies the year 1985; a value of 1 identifies 1986; etc.\nByte\nParameter definition\nResolution\nOperating range\n1\nMonth\n1 month/bit gain, 0 month offset\n1 to 12 month\n2\nDay\n0,25 day/bit gain, 0 day offset (see Note below)\n0,25 to 31,75 day\n3\nYear\n1 Year/bit gain, +1985 year offset (see Note below)\n1985 to 2235 year\nCPR_078 Table 42 details the formats of the different bytes of the VehicleRegistrationNumber parameter:\nTable 42\nDetailed format of VehicleRegistrationNumber ( recordDataIdentifier value # F97E )\nByte\nParameter definition\nResolution\nOperating range\n1\nCode Page (as defined in Appendix 1)\nASCII\n01 to 0A\n2 to 14\nVehicle Registration Number (as defined in Appendix 1)\nASCII\nASCII",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "Inserted by Council Regulation (EC) No 2135/98 of 24 September 1998 amending Regulation (EEC) No 3821/85 on recording equipment in road transport and Directive 88/599/EEC concerning the application of Regulations (EEC) No 3820/85 and (EEC) No 3821/85."
    },
    {
      "type": "F",
      "label": "F2",
      "text": "Substituted by Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "F",
      "label": "F3",
      "text": "Substituted by Commission Regulation (EC) No 432/2004 of 5 March 2004 adapting for the eighth time to technical progress Council Regulation (EEC) No 3821/85 of 20 December 1985 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "X",
      "label": "X1",
      "text": "Substituted by Corrigendum to Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Official Journal of the European Communities L 207 of 5 August 2002)."
    },
    {
      "type": "footnote",
      "label": "f1",
      "text": "■ This symbol indicates that the service is mandatory in this diagnostic session. No symbol indicates that this service is not allowed in this diagnostic session."
    },
    {
      "type": "footnote",
      "label": "f2",
      "text": "The value inserted in byte #6 of the request message is not supported, i.e. not in Table 17."
    },
    {
      "type": "footnote",
      "label": "f3",
      "text": "The length of the message is wrong."
    },
    {
      "type": "footnote",
      "label": "f4",
      "text": "The criteria for the request StartDiagnosticSession are not met."
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/1985/3821/annex/2/appendix/8",
    "retrieved_at": "2026-11-01T15:05:16.849228+00:00"
  },
  "licence": "Open Government Licence v3.0",
  "licence_url": "https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/",
  "attribution": "Contains public sector information licensed under the Open Government Licence v3.0. Source: legislation.gov.uk, The National Archives."
}