{
  "url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-14",
  "json_url": "https://openlegislation.uk/eu-regulation-2016-799/annex-1/appendix-14.json",
  "legislation": "eur/2016/799",
  "legislation_title": "Commission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)",
  "legislation_url": "https://openlegislation.uk/eu-regulation-2016-799",
  "path": "annex/1/appendix/14",
  "kind": "appendix",
  "number": "14",
  "heading": null,
  "text": "REMOTE COMMUNICATION FUNCTION\n1.\nINTRODUCTION\nThis Appendix specifies the design and the procedures to follow in order to perform the remote communication function (the Communication) as required in Article 9 of Regulation (EU) No 165/2014 (the Regulation).\nDSC_1\nRegulation (EU) No 165/2014 determines that the tachograph shall be equipped with a remote communication functionality that shall enable agents of the competent control authorities to read tachograph information from passing vehicles by using remote interrogation equipment (the Remote early detection communication reader [REDCR]), specifically, interrogation equipment connecting wirelessly using CEN 5.8 GHz Dedicated Short Range Communication (DSRC) interfaces.\nIt is important to comprehend that this functionality is intended to serve only as a pre-filter in order to select vehicles for closer inspection, and it does not replace the formal inspection process as determined in the provisions of Regulation (EU) No 165/2014. See recital 9 in the preamble of this regulation, stating that remote communication between the tachograph and control authorities for roadside control purposes facilitates targeted roadside checks.\nDSC_2\nThe Data shall be exchanged using the Communication which shall be a wireless intercourse using 5.8 GHz DSRC wireless communications consistent with this Appendix and tested against the appropriate parameters of EN 300 674-1, {Electromagnetic compatibility and Radio spectrum Matters (ERM); Road Transport and Traffic Telematics (RTTT); Dedicated Short Range Communication (DSRC) transmission equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Industrial, Scientific and Medical (ISM) band; Part 1: General characteristics and test methods for Road Side Units (RSU) and On -Board Units (OBU)}.\nDSC_3\nThe Communication shall be established with the communications equipment only when so requested by the equipment of the competent control authority using compliant radio-communication means (the Remote early detection communication reader (REDCR)).\nDSC_4\nThe Data shall be secured to ensure integrity.\nDSC_5\nAccess to the Data communicated shall be restricted to competent control authorities authorised to check infringements of Regulation (EC) No 561/2006 and of Regulation (EU) No 165/2014 and to workshops in so far as it is necessary to verify the correct functioning of the tachograph.\nDSC_6\nThe Data exchanged during the Communication shall be limited to the data necessary for the purpose of targeting roadside checks of vehicles with a potentially manipulated or misused tachograph.\nDSC_7\nData integrity and security shall be obtained by securing the Data within the Vehicle Unit (VU) and by passing only the secured payload data and security related data (see 5.4.4) across the wireless 5.8 GHz DSRC remote communication medium, meaning that only authorised persons of competent control authorities have the means to understand the data passed across the Communication and to verify its authenticity. See Appendix 11 Common Security Mechanisms.\nDSC_8\nThe Data shall contain a timestamp for the time of its last update.\nDSC_9\nThe content of the security data shall be known only to and within the control of the competent control authorities, and those parties with whom they share this information and is outwith the provisions of the Communication that is the subject of this Appendix, save that the Communication makes provision to transfer a packet of security data with every packet of payload data.\nDSC_10\nThe same architecture and equipment shall be capable be used to acquire other data concepts (such as weigh–on-board) using the architecture specified herein.\nDSC_11\nFor clarification, in accordance with the provisions of Regulation (EU) No 165/2014 (Article 7), data concerning the identity of the driver shall not be communicated across the Communication.\n2.\nSCOPE\nThe scope of this Appendix is to specify how agents of the competent control authorities use a specified 5.8 GHz DSRC wireless communication to remotely obtain data (the Data) from a targeted vehicle that identifies that the targeted vehicle is in potential violation of Regulation (EU) No 165/2014 and should be targeted for consideration to be stopped for further investigation.\nRegulation (EU) No 165/2014 requires that the Data collected shall be limited to data or pertaining to data that identifies a potential infringement, as defined in Article 9 of Regulation (EU) No 165/2014.\nIn this scenario, the time available for communication is limited, because the Communication is targeted and of a short- range design. Further, the same communication means for remote tachograph monitoring (RTM) may also be used by the competent control authorities for other applications (such as the maximal weights and dimensions for heavy goods vehicles defined in Directive (EU) 2015/719) and such operations may be separate or sequential at the discretion of the competent control authorities.\nThis Appendix specifies:\nThe communications equipment, procedures and protocols to be used for the Communication\nThe Standards and Regulations to which the radio equipment shall comply\nThe presentation of the Data to the Communication equipment\nThe enquiry and download procedures and sequence of operations\nThe Data to be transferred\nPotential interpretation of the Data transferred across the Communication\nThe provisions for security data relating to the Communication\nThe availability of the Data to the competent control authorities\nHow the Remote early detection communication reader can request different freight and fleet data concepts\nFor clarification, this Appendix does not specify:\nthe collection of the Data operation and management within the VU (which shall be a function of product design unless specified elsewhere within Regulation (EU) No 165/2014)\nthe form of presentation of collected data to the agent of the competent control authorities, nor the criteria which shall be used by the competent control authorities to decide which vehicles to stop (which shall be a function of product design unless specified elsewhere within Regulation (EU) No 165/2014 or a policy decision of the competent control authorities). For clarification: the Communication only makes the Data available to the competent control authorities in order that they may make informed decisions\nData security provisions (such as encryption) concerning the content of the Data (which shall be specified within Appendix 11 Common Security Mechanisms).\ndetail of any data concepts other than RTM which may be obtained using the same architecture and equipment\ndetail of the behaviour and management between VU's and the DSRC-VU, nor the behaviour within the DSRC-VU (other than to provide the Data when so requested by an REDCR).\n3.\nACRONYMS, DEFINITIONS AND NOTATIONS\nThe following acronyms and definitions specific to this Appendix are used in this appendix:\nthe Antennaelectrical device which converts electric power into radio waves, and vice versa used in combination with a radio transmitter or radio receiver. In operation, a radio transmitter supplies an electric current oscillating at radio frequency to the antenna's terminals, and the antenna radiates the energy from the current as electromagnetic waves (radio waves). In reception, an antenna intercepts some of the power of an electromagnetic wave in order to produce a tiny voltage at its terminals, that is applied to a receiver to be amplified\nthe Communicationexchange of information/data between a DSRC-REDCR and a DSRC-VU according to section 5 in a master-slave relationship to obtain the Data.\nthe Datasecured data of defined format (see 5.4.4) requested by the DSRC-REDCR and provided to the DSRC-REDCR by the DSRC-VU across a 5.8 GHz DSRC link as defined in 5 below\nRegulation (EC) No 165/2014Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on tachographs in road transport, repealing Council Regulation (EEC) No 3821/85 on recording equipment in road transport and amending Regulation (EC) No 561/2006 of the European Parliament and of the Council on the harmonisation of certain social legislation relating to road transport\nAIDApplication Identifier\nBLEBluetooth Low Energy\nBSTBeacon Service Table\nCIWDCard insertion while driving\nCRCcyclic redundancy check\nDSC (n)identifier of a requirement for a specific DSRC appendix\nDSRCDedicated Short Range Communication\nDSRC-REDCRDSRC — Remote Early Detection Communication Reader.\nDSRC-VUDSRC — Vehicle Unit. This is the ‘remote early detection facility’ defined in Annex 1C.\nDWVCDriving without valid card\nEIDElement Identifier\nLLCLogical Link Control\nLPDULLC Protocol Data Unit\nOWSOnboard Weighing System\nPDUProtocol Data Unit\nREDCRRemote early detection communication reader. This is the ‘remote early detection communication reader equipment’ defined in Annex 1C.\nRTMRemote Tachograph Monitoring\nSM-REDCRSecurity Module-Remote early detection communication reader\nTARVTelematics Applications for Regulated Vehicles (ISO 15638 series of Standards)\nVUVehicle Unit\nVUPMVehicle Unit Payload Memory\nVUSMVehicle Unit Security Module\nVSTVehicle Service Table\nWIMWeigh in motion\nWOBWeigh on board\nThe specification defined in this Appendix refers to and depends upon all or parts of the following regulations and standards. Within the clauses of this Appendix the relevant standards, or relevant clauses of standards, are specified. In the event of any contradiction the clauses of this Appendix shall take precedence. In the event of any contradiction where no specification is clearly determined in this Appendix, operating within ERC 70-03 (and tested against the appropriate parameters of EN 300 674-1) shall take precedence, followed in descending order of preference by EN 12795, EN 12253 EN 12834 and EN 13372, 6.2, 6.3, 6.4 and 7.1.\nRegulations and standards referenced in this Appendix are:\n[1]Regulation (EU) No 165/2014 of the European Parliament and of the Council of 4 February 2014 on tachographs in road transport, repealing Council Regulation (EEC) No 3821/85 on recording equipment in road transport and amending Regulation (EC) No 561/2006 of the European Parliament and of the Council on the harmonisation of certain social legislation relating to road transport.\n[2]Regulation (EC) No 561/2006 of the European Parliament and of the Council of 15 March 2006 on the harmonisation of certain social legislation relating to road transport and amending Council Regulations (EEC) No 3821/85 and (EC) No 2135/98 and repealing Council Regulation (EEC) No 3820/85 (Text with EEA relevance).\n[3]ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the Use of Short Range Devices (SRD)\n[4]ISO 15638 Intelligent transport systems — Framework for cooperative telematics applications for regulated commercial freight vehicles (TARV).\n[5]EN 300 674-1 Electromagnetic compatibility and Radio spectrum Matters (ERM); Road Transport and Traffic Telematics (RTTT); Dedicated Short Range Communication (DSRC) transmission equipment (500 kbit/s / 250 kbit/s) operating in the 5,8 GHz Industrial, Scientific and Medical (ISM) band; Part 1: General characteristics and test methods for Road Side Units (RSU) and On-Board Units (OBU).\n[6]EN 12253 Road transport and traffic telematics — Dedicated short-range communication — Physical layer using microwave at 5.8 GHz.\n[7]EN 12795 Road transport and traffic telematics — Dedicated short-range communication — Data link layer: medium access and logical link control.\n[8]EN 12834 Road transport and traffic telematics — Dedicated short-range communication — Application layer.\n[9]EN 13372 Road transport and traffic telematics — Dedicated short-range communication — Profiles for RTTT applications\n[10]ISO 14906 Electronic fee collection — Application interface definition for dedicated short- range communication\n4.\nOPERATIONAL SCENARIOS\n4.1\nOverview\nRegulation (EU) No 165/2014 provides specific and controlled scenarios within which the Communication is to be used.\nThe scenarios supported are:\n‘Communication Profile 1: Roadside inspection using a short range wireless communication Remote Early Detection Communication Reader instigating a physical roadside inspection (master-:-slave)\nReader Profile 1a: via a hand aimed or temporary roadside mounted and aimed Remote Early Detection Communication\nReader Profile 1b: via a vehicle mounted and directed Remote Early Detection Communication Reader’.\n4.1.1\nPreconditions to data transfer via 5,8 GHz DSRC interface\nNOTE: In order to understand the context of the preconditions the reader is referred to Figure 14.3 below.\n4.1.1.1\nData held in VU\nDSC_12\nThe VU shall be responsible to keep updated every 60 seconds and maintain the data to be stored in the VU, without any involvement of the DSRC communication function. The means by which this is achieved is internal to the VU, specified in Regulation (EU) No 165/2014, Annex 1 C, section 3.19 ‘Remote communication for targeted roadside checks’ and is not specified in this Appendix.\n4.1.1.2\nData provided to DSRC-VU Facility\nDSC_13\nThe VU shall be responsible to update the DSRC tachograph data (the Data) whenever the data stored in the VU is updated at the interval determined in 4.1.1.1 (DSC_12), without any involvement of the DSRC communication function.\nDSC_14\nThe VU data shall be used as a basis to populate and update the Data, the means by which this is achieved, is specified in Annex 1.C, section 3.19 ‘Remote communication for targeted roadside checks’ or if there is no such specification it is a function of product design and is not specified in this Appendix. For the design of the connection between DSRC-VU facility and the VU, please refer to section 5.6.\n4.1.1.3\nContent of the Data\nDSC_15\nThe content and format of the Data shall be such that, once decrypted, it shall be structured and made available in the form and format specified in 5.4.4 of this Appendix (Data structures).\n4.1.1.4\nData presentation\nDSC_16\nThe Data, having been kept frequently updated in accordance with the procedures determined in 4.1.1.1, shall be secured prior to presentation to the DSRC-VU, and presented as a secured data concept value, for temporary storage in the DSRC-VU as the current version of the Data. This data is transferred from the VUSM to the DSRC function VUPM. The VUSM and VUPM are functions and not necessarily physical entities. The form of physical instantiation to perform these functions shall be a matter of product design unless specified elsewhere in Regulation (EU) No 165/2014.\n4.1.1.5\nSecurity data\nDSC_17\nSecurity data (securityData), comprising the data required by the REDCR to complete its ability to decrypt the Data shall be supplied as defined in Appendix 11 Common Security Mechanisms and presented as a data concept value, for temporary storage in the DSRC-VU as the current version of securityData, in the form defined in this Appendix section 5.4.4.\n4.1.1.6\nVUPM data available for transfer across the DSRC interface\nDSC_18\nThe data concept which shall always be available in the DSRC function VUPM for immediate transfer upon request by the REDCR is defined in section 5.4.4 for full ASN.1 Module specifications.\nGeneral overview of communication Profile 1\nThis profile covers the use case where an agent of the competent control authorities, uses a short range remote communication Remote Early Detection Communication Reader (5.8 GHz DSRC interfaces operating within ERC 70-03, and tested against the appropriate parameters of EN 300 674-1 as described in section 5) (the REDCR) to remotely identify a vehicle which is potentially in violation of Regulation (EU) No 165/2014. Once identified, the agent of the competent control authorities who is controlling the interrogation decides whether the vehicle should be stopped.\n4.1.2\nProfile 1a: via a hand aimed or temporary roadside mounted and aimed Remote Early Detection Communication Reader\nIn this use case the agent of the competent control authorities is situated at the roadside, and aims a hand held, tripod mounted, or similar portable, REDCR from the roadside towards the centre of the windshield of the targeted vehicle. The interrogation is made using 5.8 GHz DSRC interfaces operating within ERC 70-03, and tested against the appropriate parameters of EN 300 674-1 as described in section 5. See Figure 14.1 (Use Case 1).\nFigure 14.1\nRoadside interrogation using 5,8 GHz DSRC\n4.1.3\nProfile 1b: via a vehicle mounted and directed Remote Early Detection Communication Reader (REDCR)\nIn this use case the agent of the competent control authorities is situated within a moving vehicle, and either aims a hand held, portable REDCR from the vehicle towards the centre of the windshield of the targeted vehicle, or the REDCR is mounted within or on the vehicle so as to point towards the centre of the windshield of the targeted vehicle when the Remote Early Detection Communication Reader's vehicle is in a particular position relevant to the targeted vehicle (for example directly ahead in a stream of traffic). The interrogation is made using 5.8 GHz DSRC interfaces operating within ERC 70-03, and tested against the appropriate parameters of EN 300 674-1 as described in section 5. See Figure 14.2. (Use Case 2).\nFigure 14.2\nVehicle based interrogation using 5,8 GHz DSRC\n4.2\nSecurity/Integrity\nTo give the possibility to verify the authenticity and integrity of downloaded data through the remote communication, the secured Data is verified and decrypted in accordance with Appendix 11 Common Security Mechanisms.\n5.\nREMOTE COMMUNICATION DESIGN AND PROTOCOLS\n5.1\nDesign\nThe design of the remote communication function in the Smart Tachograph is shown as described in Figure 14.3.\nFigure 14.3\nDesign of the remote communication function\nDSC_19\nThe following functions are located in the VU:\nSecurity Module (VUSM). This function present in the VU is responsible for securing the Data which is to be transmitted from the DSRC-VU to the agent of the competent control authorities via remote communication.\nThe secured data is stored in the VUSM memory. At intervals determined in 4.1.1.1 (DSC_12), the VU encrypts and replenishes the RTMdata concept (which comprises payload data and security data concept values determined below in this Appendix) held in the memory of the DSRC-VU. The operation of the security module is defined in Appendix 11 Common Security Mechanisms and outwith the scope of this Appendix, save that it shall be required to provide updates to the VU Communication facility each time the VUSM data changes.\nThe communication between the VU and the DSRC-VU may be a wired communication or a Bluetooth Low Energy (BLE) communication, and the physical location of the DSRC-VU may be integral with the antenna on the windshield of the vehicle, may be internal to the VU, or located somewhere between.\nThe DSRC-VU shall have a reliable source of power available at all times. The means by which it is provided with its power is a design decision.\nThe memory of the DSRC-VU shall be non-volatile in order to maintain the Data in the DSRC-VU even when the vehicle ignition is switched off.\nIf the communication between the VU and the DSRC-VU is made via BLE and the power source is a non-recharging battery, the power source of the DSRC-VU shall be replaced at every Periodic Inspection, and the manufacturer of the DSRC-VU equipment shall be responsible to ensure that the power supply is adequate to last from one Periodic Inspection to the next Periodic Inspection, maintaining normal access to the data by an REDCR throughout the period without failure or interruption.\nVU RTM ‘payload memory’ facility (VUPM). This function present in the VU is responsible for providing and updating the Data. The content of The Data. (‘TachographPayload’) is defined in 5.4.4/5.4.5 below and is updated at the interval determined in 4.1.1.1 (DSC_12).\nDSRC-VU. This is the function, within or connected to the antenna and in communication with the VU through a wired or wireless (BLE) connection, which holds the current data (VUPM-data) and manages the response to an interrogation across the 5.8 GHz DSRC medium. Disconnection of the DSRC facility or interference during normal vehicle operation with the functioning of the DSRC facility shall be construed as a violation of Regulation (EU) No 165/2014.\nSecurity module (REDCR) (SM-REDCR) is the function used to decrypt and check integrity of the data originating from the VU. The means by which this is achieved is determined in Appendix 11 Common Security Mechanisms, and is not defined in this Appendix.\nThe DSRC facility (REDCR) (DSRC-REDCR) function comprises a 5.8 GHz transceiver and associated firmware and software which manages the Communication with the DSRC-VU according to this Appendix.\nThe DSRC-REDCR interrogates the DSRC-VU of the targeted vehicle and obtains the Data (the targeted vehicle's current VUPM-data) via the DSRC link and processes and stores the received data in its SM-REDCR.\nThe DSRC-VU antenna shall be positioned at a location where it optimizes the DSRC communication between the vehicle and the roadside reader antenna, when the reader is installed 15 meters distance in front of the vehicle and 2 meters height, targeting the horizontal and vertical centre of the windscreen. For light vehicles an installation corresponding to the upper part of the windscreen is suitable. For all the other vehicles the DSRC antenna shall be installed either near the lower or near the upper part of the windscreen.\nDSC_20\nThe Antenna and The Communication shall operate within ERC 70-03, tested against the appropriate parameters of EN 300 674-1 as described in section 5. The Antenna and the Communication can implement mitigation techniques against the risk of wireless interference as described in ECC report 228 using e.g., filters in the CEN DSRC 5.8 GHz communication.\nDSC_21\nThe DSRC antenna shall be connected to the DSRC-VU facility either directly within the module mounted to or close to the windshield, or through a dedicated cable constructed in a manner to make illegal disconnection difficult. Disconnection of or interference with the functioning of Antenna shall be a violation of Regulation (EU) No 165/2014. Deliberate masking or otherwise detrimentally affecting the operational performance of the Antenna shall be construed as a violation of Regulation (EU) No 165/2014.\nDSC_22\nThe form factor of the antenna is not defined and shall be a commercial decision, so long as the fitted DSRC-VU meets the conformance requirements defined in section 5 below. The antenna shall be positioned as determined in DSC_19 and efficiently support the use cases described in in 4.1.2 and 4.1.3.\nFigure 14.4\nExample of positioning of the 5,8 GHz DSRC antenna in the windshield of regulated vehicles\nThe form factor of the REDCR and its antenna may vary according to the circumstances of the reader (tripod mounted, hand held, vehicle mounted, etc.) and the modus operandi employed by the agent of the competent control authorities.\nA display and/or notification function is used to present the results of the remote communication function to the agent of the competent control authorities. A display may be provided on a screen, as a printed output, an audio signal, or a combination of such notifications. The form of such display and/or notification is a matter of the requirements of the agents of the competent control authorities and equipment design and is not specified within this Appendix.\nDSC_23\nThe design and form factor of the REDCR shall be a function of commercial design, operating within ERC 70-03, and the design and performance specifications defined in this Appendix, (section 5.3.2), thus providing the marketplace maximum flexibility to design and provide equipment to cover the specific interrogation scenarios of any particular competent control authority.\nDSC_24\nThe design and form factor of the DSRC-VU and its positioning inside or outside the VU shall be a function of commercial design, operating within ERC 70-03 and the design and performance specifications defined in this Appendix (section 5.3.2) and within this Clause (5.1).\nDSC_25\nHowever, the DSRC-VU shall be reasonably capable to accept data concept values from other intelligent vehicle equipment by means of an open industry standard connection and protocols. (For example from weigh on board equipment), so long as such data concepts are identified by unique and known application identifiers/file names, and the instructions to operate such protocols shall be made available to the European Commission, and available without charge to manufacturers of relevant equipment.\n5.2\nWorkflow\n5.2.1\nOperations\nThe workflow of operations is represented in Figure 14.5.\nFigure 14.5\nWorkflow for remote communication function\nThe steps are described below:\na..Whenever the vehicle is in operation (ignition ON) the tachograph is providing data to the VU function. The VU function prepares the Data for the remote communication function (encrypted) and updates the VUPM held in the memory of the DSRC-VU (as defined in 4.1.1.1 — 4.1.1.2). The Data collected shall be formatted as determined in 5.4.4 — 5.4.5 below.\nb..On every occasion that the Data is updated, the timestamp defined in the security data concept shall be updated.\nc..The VUSM function secures the data in accordance with the procedures determined in Appendix 11.\nd..On every occasion that the Data is updated (see 4.1.1.1 — 4.1.1.2), the Data shall be transferred to the DSRC-VU, where it replaces any previous data, in order that updated current data (the Data) shall always be available to be provided in the event of an interrogation by an REDCR. When supplied by the VU to the DSRC-VU the Data shall be identifiable by the filename RTMData or by ApplicationID and Attribute identifiers.\ne..If an agent of the competent control authorities wishes to target a vehicle and collect the Data from the targeted vehicle, the agent of the competent control authorities shall first insert his/her smartcard in the REDCR to enable the Communication and to allow the SM-REDCR to verify its authenticity and decrypt the data.\nf..The agent of the competent control authority then targets a vehicle and requests the data through remote communication. The REDCR opens a 5.8 GHz DSRC interface session with the DSRC-VU of the targeted vehicle, and requests the Data. The Data is transferred to the REDCR through the wireless communication system as a DSRC Attribute using the Application service GET as defined in 5.4. The Attribute contains the encrypted payload data values and the DSRC security data.\ng..The data is analyzed by the REDCR equipment and provided to the agent of the competent control authority.\nh..The agent of the competent control authority uses the data to assist in a decision of whether or not to stop for a detailed inspection, or ask another agent of the competent control authority to stop the vehicle.\n5.2.2\nInterpretation of the Data received via the DSRC communication\nDSC_26\nData received across the 5.8 GHz interface shall carry the meaning and import defined in 5.4.4 and 5.4.5 below and only that meaning and import, and shall be understood within the objectives defined therein. In accordance with the provisions of Regulation (EU) No 165/2014, the Data shall be used only to provide relevant information to a competent control authority to assist them to determine which vehicle should be stopped for physical inspection, and shall be subsequently destroyed in accordance with Article 9 of Regulation (EU) No 165/2014.\n5.3\nDSRC Physical interface parameters for remote communication\n5.3.1\nLocation constraints\nDSC_27\nThe remote interrogation of vehicles using a 5.8GHz DSRC interface should not be used within 200 metres of an operational 5.8 GHz DSRC gantry.\n5.3.2\nDownlink and uplink parameters\nDSC_28\nThe equipment used for remote tachograph monitoring shall conform to and operate within ERC70-03 and the parameters defined in Tables 14.1 and 14.2 below.\nDSC_29\nFurther, to ensure compatibility with the operational parameters of other standardised 5.8 GHz DSRC systems, the equipment used for remote tachograph monitoring shall conform to parameters from EN 12253 and EN 13372.\nNamely:\nTable 14.1\nDownlink parameters\n– Downlink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1.\nItem No\nParameter\nValue(s)\nRemark\nD1\nDownlink Carrier Frequencies\nThere are four alternatives which may be used by an REDCR:\n5,7975 GHz\n5,8025 GHz\n5,8075 GHz\n5,8125 GHz\nWithin ERC 70-03.\nCarrier Frequencies may be selected by the implementer of the roadside system and need not be known in the DSRC-VU\n(Consistent with EN 12253, EN 13372)\nD1a\nTolerance of Carrier Frequencies\nwithin ± 5 ppm\n(Consistent with EN 12253)\nD2\nRSU (REDCR) Transmitter Spectrum Mask\nWithin ERC 70-03.\nREDCR shall be according to Class B,C as defined in EN 12253.\nNo other specific requirement within this Annex\nParameter used for controlling interference between interrogators in proximity (as defined in EN 12253 and EN 13372).\nD3\nOBU(DSRC-VU) Minimum Frequency Range\n5,795 — 5,815 GHz\n(Consistent with EN 12253)\nD4\nMaximum E.I.R.P.\nWithin ERC 70-03 (unlicensed) and within National Regulation\nMaximum + 33 dBm\n(Consistent with EN 12253)\nD4a\nAngular E.I.R.P. mask\nAccording to declared and published specification of interrogator designer\n(Consistent with EN 12253)\nD5\nPolarisation\nLeft hand circular\n(Consistent with EN 12253)\nD5a\nCross-Polarisation\nXPD:\nIn bore sight: (REDCR) RSU t ≥ 15 dB\n(DSRC-VU) OBU r ≥ 10 dB\nAt -3 dB area: (REDCR) RSU t ≥ 10 dB\n(DSRC-VU) OBU r ≥ 6 dB\n(Consistent with EN 12253)\nD6\nModulation\nTwo level amplitude modulation.\n(Consistent with EN 12253)\nD6a\nModulation Index\n0,5 ... 0,9\n(Consistent with EN 12253)\nD6b\nEye Pattern\n≥ 90 % (time) / ≥ 85 % (amplitude)\nD7\nData Coding\nFM0\n‘1’ bit has transitions only at the beginning and end of the bit interval. ‘0’ bit has an additional transition in the middle of the bit interval compared to the ‘1’ bit.\n(Consistent with EN 12253)\nD8\nBit rate\n500 kBit/s\n(Consistent with EN 12253)\nD8a\nTolerance of Bit Clock\nbetter than ± 100 ppm\n(Consistent with EN 12253)\nD9\nBit Error Rate (B.E.R.) for communication\n≤ 10– 6 when incident power at OBU (DSRC-VU) is in the range given by [D11a to D11b].\n(Consistent with EN 12253)\nD10\nWake-up trigger for OBU (DSRC-VU)\nOBU (DSRC-VU) shall wake up on receiving any frame with 11 or more octets (including preamble)\nNo special wake-up pattern is necessary.\nDSRC-VU may wake up on receiving a frame with less than 11 octets\n(Consistent with EN 12253)\nD10a\nMaximum Start Time\n≤ 5 ms\n(Consistent with EN 12253)\nD11\nCommunication zone\nSpatial region within which a B.E.R. according to D9a is achieved\n(Consistent with EN 12253)\nD11a\nPower Limit for communication (upper).\n– 24dBm\n(Consistent with EN 12253)\nD11b\nPower Limit for communication (lower).\nIncident power:\n– 43 dBm (boresight)\n– 41 dBm (within – 45° ± 45°Corresponding to the plane parallel to the road surface when the DSRC-VU later is installed in the vehicle (Azimuth))\n(Consistent with EN 12253)\nExtended requirement for horizontal angles up to ±45°, due to the use cases defined in this annex.\nD12\nCut-off power level of (DSRC-VU)\n– 60 dBm\n(Consistent with EN 12253)\nD13\nPreamble\nPreamble is mandatory.\n(Consistent with EN 12253)\nD13a\nPreamble Length and Pattern\n16 bits ± 1 bit of FM0 coded ‘1’ bits\n(Consistent with EN 12253)\nD13b\nPreamble Wave form\nAn alternating sequence of low level and high level with pulse duration of 2 μs.\nThe tolerance is given byD8a\n(Consistent with EN 12253)\nD13c\nTrailing Bits\nThe RSU (REDCR) is permitted to transmit a maximum of 8 bits after the end flag. An OBU (DSRC-VU) is not required to take these additional bits into account.\n(Consistent with EN 12253)\nTable 14.2\nUplink parameters\n– Uplink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1\nItem No.\nParameter\nValue(s)\nRemark\nU1\nSub-carrier Frequencies\nA OBU (DSRC-VU) shall support 1,5 MHz and 2,0 MHz\nAn RSU (REDCR) shall support 1,5 MHz or 2,0 MHz or both. U1-0: 1,5 MHz U1-1: 2,0 MHz\nSelection of sub-carrier frequency\n(1,5 MHz or 2,0 MHz) depends on the EN 13372 profile selected.\nU1a\nTolerance of Sub- carrier Frequencies\nwithin ± 0,1 %\n(Consistent with EN 12253)\nU1b\nUse of Side Bands\nSame data on both sides\n(Consistent with EN 12253)\nU2\nOBU (DSRC-VU) Transmitter Spectrum Mask\nAccording to EN12253\n1))Out band power:\nsee ETSI EN 300674-1\n2))In band power:\n[U4a] dBm in 500 kHz\n3))Emission in any other uplink channel:\nU2(3)-1 = – 35 dBm in 500 kHz\n(Consistent with EN 12253)\nU4a\nMaximum Single Side Band E.I.R.P. (boresight)\nTwo options:\nU4a-0: – 14 dBm\nU4a-1: – 21 dBm\nAccording to declared and published specification of equipment designer\nU4b\nMaximum Single Side Band E.I.R.P. (35°)\nTwo options:\nNot applicable\n– 17dBm\nAccording to declared and published specification of equipment designer\nU5\nPolarisation\nLeft hand circular\n(Consistent with EN 12253)\nU5a\nCross Polarisation\nXPD:\nIn bore sight: (REDCR) RSU r ≥ 15 dB\n(DSRC-VU) OBU t ≥ 10 dB\nAt – 3 dB: (REDCR) RSU r ≥ 10 dB\n(DSRC-VU) OBU t ≥ 6 dB\n(Consistent with EN 12253)\nU6\nSub-Carrier Modulation\n2-PSK\nEncoded data synchronised with sub-carrier: Transitions of encoded data coincide with transitions of sub- carrier.\n(Consistent with EN 12253)\nU6b\nDuty Cycle\nDuty Cycle:\n50 % ± α, α ≤ 5 %\n(Consistent with EN 12253)\nU6c\nModulation on Carrier\nMultiplication of modulated sub- carrier with carrier.\n(Consistent with EN 12253)\nU7\nData Coding\nNRZI (No transition at beginning of ‘1’ bit, transition at beginning of ‘0’ bit, no transition within bit)\n(Consistent with EN 12253)\nU8\nBit Rate\n250 kbit/s\n(Consistent with EN 12253)\nU8a\nTolerance of Bit Clock\nWithin ± 1 000 ppm\n(Consistent with EN 12253)\nU9\nBit Error Rate (B.E.R.) for communication\n≤10– 6\n(Consistent with EN 12253)\nU11\nCommunication Zone\nThe spatial region within which the DSRC-VU is situated such that its transmissions are received by the REDCR with a B.E.R. of less than that given by U9a.\n(Consistent with EN 12253)\nU12a\nConversion Gain (lower limit)\n1 dB for each side band Range of angle: Circularly symmetric between bore sight and ± 35°\nand\nwithin – 45° ± 45° Corresponding to the plane parallel to the road surface when the DSRC-VU later is installed in the vehicle (Azimuth)\nGreater that the specified value range for horizontal angles up to ± 45°, due to the use cases defined in this annex.\nU12b\nConversion Gain (upper limit)\n10 dB for each side band\nLess than the specified value range for each side band within a circular cone around boresight of ± 45° opening angle\nU13\nPreamble\nPreamble is mandatory.\n(Consistent with EN 12253)\nU13a\nPreamble\nLength and Pattern\n32 to 36 μs modulated with sub- carrier only, then 8 bits of NRZI coded ‘0’ bits.\n(Consistent with EN 12253)\nU13b\nTrailing Bits\nThe DSRC-VU is permitted to transmit a maximum of 8 bits after the end flag. A RSU (REDCR) is not required to take these additional bits into account.\n(Consistent with EN 12253)\n5.3.3\nAntenna design\n5.3.3.1\nREDCR antenna\nDSC_30\nThe design of the REDCR antenna shall be a function of commercial design, operating within the limits defined in 5.3.2 which is adapted to optimise the reading performance of the DSRC-REDCR for the specific purpose and read circumstances in which the REDCR has been designed to operate.\n5.3.3.2\nVU antenna\nDSC_31\nThe design of the DSRC-VU antenna shall be a function of commercial design, operating within the limits defined in 5.3.2 which is adapted to optimise the reading performance of the DSRC-REDCR for the specific purpose and read circumstances in which the REDCR has been designed to operate.\nDSC_32\nThe VU antenna shall be fixed to, or close to, the front windshield of the vehicle as specified in 5.1 above.\nDSC_33\nIn the test environment in a workshop (see section 6.3), a DSRC-VU antenna, affixed according to 5.1 above, shall successfully connect with a standard test communication and successfully provide an RTM transaction as defined within this Appendix, at a distance between 2 and 10 meters, better than 99 % of the time, averaged over 1 000 read interrogations.\n5.4\nDSRC Protocol requirements for RTM\n5.4.1\nOverview\nDSC_34\nThe transaction protocol to download the Data across the 5.8 GHz DSRC interface link shall be according to the following steps. This section describes a transaction flow under ideal conditions without retransmissions or communication interrupts.\nNOTE The purpose of the initialisation phase (Step 1) is to set up the communication between the REDCR and DSRC-VUs that have entered the 5.8 GHz DSRC (master-slave) transaction zone but have not yet established communication with the REDCR, and to notify the application processes.\n— Step 1 Initialisation. The REDCR sends a frame containing a ‘beacon service table’ (BST) that includes the application identifiers (AIDs) in the service list that it supports. In the RTM application this will simply be the service with the AID value = 2 (Freight&Fleet). The DSRC-VU evaluates the received BST, and shall respond (see below) with the list of the supported applications within the Freight&Fleet domain, or shall not respond if none are supported. If the REDCR does not offer AID=2, the DSRC-VU shall not answer to the REDCR.\n— Step 2 The DSRC-VU sends a frame containing a request for a private window allocation.\n— Step 3 The REDCR sends a frame containing a private window allocation.\n— Step 4 The DSRC-VU uses the allocated private window to send a frame containing its vehicle service table (VST). This VST includes a list of all the different application instantiations that this DSRC-VU supports in the framework of AID=2. The different instantiations shall be identified by means of uniquely generated EIDs, each associated with an Application Context Mark parameter value indicating the application and standard supported.\n— Step 5 Next the REDCR analyses the offered VST, and either terminates the connection (RELEASE) since it is not interested in anything the VST has to offer (i.e. it is receiving a VST from a DSRC-VU that is not supporting the RTM transaction), or, if it receives an appropriate VST it starts an app instantiation.\n— Step 6 To bring this about, the REDCR shall send a frame containing a command to retrieve the RTM data, identifying the RTM application instantiation by specifying the identifier corresponding to the RTM application instantiation (as specified by the DSRC-VU in the VST), and shall allocate a private window.\n— Step 7 The DSRC-VU uses the newly allocated private window to send a frame that contains the addressed identifier corresponding to the RTM application instantiation as provided in the VST, followed by the attribute RtmData (payload element + security element).\n— Step 8 If there are multiple services requested, the value ‘n’ is changed to the next service reference number and the process repeated.\n— Step 9 The REDCR confirms receipt of the data by sending a frame containing a RELEASE command to the DSRC-VU to terminate the session OR if it has failed to validate a successful receipt of the LDPU goes back to step 6.\nSee Figure 14.6 for a pictorial description of the transaction protocol.\nFigure 14.6\nRTM over 5,8 GHz DSRC process flow\n5.4.2\nCommands\nDSC_35\nThe following commands are the only functions used in an RTM transaction phase\n— INITIALISATION.request A command, issued from the REDCR in the form of a broadcast with definition of applications that the REDCR supports.\n— INITIALISATION.response An answer from the DSRC-VU confirming the connection and containing a list of supported application instances with characteristics and information how to address them (EID).\n— GET.request A command, issued from the REDCR to the DSRC-VU, that specifies the application instantiation to be addressed by means of a defined EID, as received in the VST, instructing the DSRC-VU to send the selected attribute(s) with the Data. The objective of the GET command is for the REDCR to obtain the Data from the DSRC-VU.\n— GET.response An answer from the DSRC-VU that contains the Data requested.\n— ACTION.request ECHO A command, instructing the DSRC-VU to send back data from the DSRC-VU to the REDCR. The objective of the ECHO command is to enable workshops or type approval test facilities to test that the DSRC link is working without needing access to security credentials.\n— ACTION.response ECHOAn answer from the DSRC VU on the ECHO command.\n— EVENT_REPORT.request RELEASEA command, instructing the DSRC-VU that the transaction is ended. The objective of the RELEASE command is to end the session with the DSRC-VU. On receipt of the RELEASE the DSRC-VU shall not respond to any further interrogations under the current connection. Note that according to EN 12834 a DSRC-VU will not connect twice to the same interrogator unless it has been out of the communication zone for 255 seconds or if the Beacon ID of the interrogator is changed.\n5.4.3\nInterrogation command sequence\nDSC_36\nFrom the perspective of the command and response sequence, the transaction is described as follows:\nSequence\nSender\nReceiver\nDescription\nAction\n1\nREDCR\n>\nDSRC-VU\nInitialisation of the communication link — Request\nREDCR broadcasts BST\n2\nDSRC-VU\n>\nREDCR\nInitialisation of the communication link — Response\nIf BST supports AID=2 then DSRC-VU Requests a private window\n3\nREDCR\n>\nDSRC-VU\nGrants a private window\nSends Frame containing private window allocation\n4\nDSRC-VU\n>\nREDCR\nSends VST\nSends Frame comprising VST\n5\nREDCR\n>\nDSRC-VU\nSends GET.request for data in Attribute for specific EID\n6\nDSRC-VU\n>\nREDCR\nSends GET.response with requested Attribute for specific EID\nSends Attribute (RTMData, OWSData….) with data for specific EID\n7\nREDCR\n>\nDSRC-VU\nSends GET.request for data of other Attribute (if appropriate)\n8\nDSRC-VU\n>\nREDCR\nSends GET.response with requested Attribute\nSends Attribute with data for specific EID\n9\nREDCR\n>\nDSRC-VU\nAcknowledges successful receipt of data\nSends RELEASE command which closes transaction\n10\nDSRC-VU\nCloses transaction\nAn example of the transaction sequence and contents of the exchanged frames is defined in clauses 5.4.7 and 5.4.8\n5.4.4\nData structures\nDSC_37\nThe semantic structure of the Data when passed across the 5.8 GHz DSRC interface shall be consistent with what described in this Appendix. The way these data are structured is specified in this clause.\nDSC_38\nThe payload (RTM data) consists of the concatenation of\n1..EncryptedTachographPayload data, which is the encryption of the TachographPayload defined in ASN.1 in section 5.4.5. The method of encryption is described in Appendix 11\n2..DSRCSecurityData, specified in Appendix 11.\nDSC_39\nThe RTM Data is being addressed as RTM Attribute=1 and is transferred in the RTM container = 10.\nDSC_40\nThe RTM Context Mark shall identify the supported standard part in the TARV series of standards (RTM corresponds to Part 9)\nThe ASN.1 module definition for the DSRC data within the RTM application is defined as follows:\n5.4.5\nElements of RtmData, actions performed and definitions\nDSC_41\nThe data values to be calculated by the VU and used to update the secured data in the DSRC-VU shall be calculated according to the rules defined in Table 14.3:\nTable 14.3\nElements of RtmData, actions performed and definitions\n(1) RTM Data Element\n(2) Action performed by the VU\n(3) ASN.1 definition of data\nRTM1\nVehicle Registration Plate\nThe VU shall set the value of the tp15638VehicleRegistrationPlate data element RTM1 from the recorded value of the data type VehicleRegistrationIdentification as defined in Appendix 1 VehicleRegistrationIdentification\nVehicle Registration Plate expressed as a string of characters\nRTM2\nSpeeding Event\nThe VU shall generate a boolean value for data element RTM2 tp15638SpeedingEvent.\nThe tp15638SpeedingEvent value shall be calculated by the VU from the number of Over Speeding Events recorded in the VU in the last 10 days of occurrence, as defined in Annex 1C.\nIf there is at least one tp15638SpeedingEvent in the last 10 days of occurrence, the tp15638SpeedingEvent value shall be set to TRUE.\nELSE if there are no events in the last 10 days of occurrence, the tp15638SpeedingEvent shall be set to FALSE.\n1 (TRUE) — Indicates irregularities in speed within last 10 days of occurrence\nRTM3\nDriving Without Valid Card\nThe VU shall generate a boolean value for data element RTM3 tp15638DrivingWithoutValidCard.\nThe VU shall assign a value of True to the tp15638DrivingWithoutValidCard variable if the VU data has recorded at least one event in the last 10 days of occurrence of type ‘Driving without an appropriate card’ event as defined in Annex 1C.\nELSE if there are no events in the last 10 days of occurrence, the tp15638DrivingWithoutValidCard variable shall be set to FALSE.\n1 (TRUE) = Indicates invalid card usage\nRTM4\nValid Driver Card\nThe VU shall generate a boolean value for data element RTM4\ntp15638DriverCard on the basis of the data stored in the VU and defined in Appendix 1.\nIf no valid driver card is present the VU shall set the variable to TRUE\nELSE if a valid driver card is present the VU shall set the variable to FALSE\n0 (FALSE) = Indicates a valid driver card\nRTM5\nCard Insertion while Driving\nThe VU shall generate a boolean value for data element RTM5.\nThe VU shall assign a value of TRUE to the tp15638CardInsertion variable if the VU data has recorded in the last 10 days of occurrence at least one event of type ‘Card insertion while driving.’ as defined in Annex 1C.\nELSE if there are no such events in the last 10 days of occurrence, the tp15638CardInsertion variable shall be set to FALSE.\n1 (TRUE) = Indicates card insertion while driving within last 10 days of occurrence\nRTM6\nMotion Data Error\nThe VU shall generate a boolean value for data element RTM6.\nThe VU shall assign a value of TRUE to the tp15638MotionDataError variable if the VU data has in the last 10 days of occurrence recorded at least one event of type ‘Motion data error’ as defined in Annex 1C.\nELSE if there are no such events in the last 10 days of occurrence, the tp15638MotionDataError variable shall be set to FALSE.\n1 (TRUE) = Indicates motion data error within last 10 days of occurrence\nRTM7\nVehicle Motion Conflict\nThe VU shall generate a boolean value for data element RTM7.\nThe VU shall assign a value of TRUE to the tp15638vehicleMotionConflict variable if the VU data has in the last 10 days recorded at least one event of type Vehicle Motion Conflict (value ‘0A’H ).\nELSE if there are no events in the last 10 days of occurrence, the tp15638vehicleMotionConflict variable shall be set to FALSE.\n1 (TRUE) = Indicates motion conflict within last 10 days of occurrence\nRTM8\n2nd Driver Card\nThe VU shall generate a boolean value for data element RTM8 on the basis of Annex 1C (‘Driver Activity Data’ CREW and CO-DRIVER).\nIf a 2nd valid driver card is present the VU shall set the variable to TRUE\nELSE if a 2nd valid driver card is not present the VU shall set the variable to FALSE\n1 (TRUE) = Indicates a second driver card inserted\nRTM9\nCurrent Activity\nThe VU shall generate a boolean value for data element RTM9.\nIf the current activity is recorded in the VU as any activity other than ‘DRIVING’ as defined in Annex 1C the VU shall set the variable to TRUE\nELSE if the current activity is recorded in the VU as ‘DRIVING’ the VU shall set the variable to FALSE\n1 (TRUE) = other activity selected;\n0 (FALSE) = driving selected\nRTM10\nLast Session Closed\nThe VU shall generate a boolean value for data element RTM10.\nIf the last card session was not properly closed as defined in Annex 1C the VU shall set the variable to TRUE.\nELSE if the last card session was properly closed the VU shall set the variable to FALSE\n1 (TRUE) = improperly closed\n0 (FALSE) = properly closed\nRTM11\nPower Supply Interruption\nThe VU shall generate an integer value for data element RTM11.\nThe VU shall assign a value for the tp15638PowerSupplyInterruption variable equal to the longest power supply interruption according to Article 9, Reg (EU) 165/2014 of type ‘Power supply interruption’ as defined in Annex 1C.\nELSE if in the last 10 days of occurrence there are have been no Power supply interruption events the value of the integer shall be set to 0.\n—\nNumber of power supply interruptions in last 10 days of occurrence\nRTM12\nSensor Fault\nThe VU shall generate an integer value for data element RTM12.\nThe VU shall assign to the variable sensorFault a value of:\n1 if an event of type ‘35H’ Sensor fault has been recorded in the last 10 days,\n2 if an event of type GNSS receiver fault (either internal or external with enum values ‘36’H or ‘37’ H) has been recorded in the last 10 days.\n3 if an event of type ‘0E’H Communication error with the external GNSS facility event has been recorded in the last 10 days.\n4 If both Sensor Fault and GNSS receiver faults have been recorded in the last 10 days\n5 If both Sensor Fault and Communication error with the external GNSS facility event have been recorded in the last 10 days\n6 If both GNSS receiver fault and Communication error with the external GNSS facility event have been recorded in the last 10 days\n7 If all three sensor faults, have been recorded in the last 10 days ELSE it shall assign a value of 0 if no events have been recorded in the last 10 days\n– sensor fault one octet as per data dictionary\nRTM13\nTime Adjustment\nThe VU shall generate an integer value (timeReal from Appendix 1) for data element RTM13 on the basis of the presence of Time Adjustment data as defined in Annex 1C.\nThe VU shall assign the value of time at which the last time adjustment data event has occurred.\nELSE if no ‘Time Adjustment’ event. as defined in Annex 1C is present in the VU data it shall set a value of 0\nTime of the last time adjustment\nRTM14\nSecurity Breach Attempt\nThe VU shall generate an integer value (timeReal from Appendix 1) for data element RTM14 on the basis of the presence of a Security breach attempt event as defined in Annex 1C.\nThe VU shall set the value of the time of the latest security breach attempt event recorded by the VU.\nELSE if no ‘security breach attempt’ event as defined in Annex 1C is present in the VU data it shall set a value of 0x00FF.\nTime of last breach attempt\n—\nDefault value =0x00FF\nRTM15\nLast Calibration\nThe VU shall generate an integer value (timeReal from Appendix 1) for data element RTM15 on the basis of the presence of Last Calibration data as defined in Annex 1C.\nThe VU shall set the value of time of the latest two calibrations (RTM15 and RTM16), which are set in VuCalibrationData defined in Appendix 1.\nThe VU shall set the value for RTM15 to the timeReal of the latest calibration record.\nTime of last calibration data\nRTM16\nPrevious Calibration\nThe VU shall generate an integer value (timeReal from Appendix 1) for data element RTM16 of the calibration record preceding that of the last calibration\nELSE if there has been no previous calibration the VU shall set the value of RTM16 to 0.\nTime of previous calibration data\nRTM17\nDate Tachograph Connected\nFor data element RTM17 the VU shall generate an integer value (timeReal from Appendix 1).\nThe VU shall set the value of the time of the initial installation of the VU.\nThe VU shall extract this data from the VuCalibrationData (Appendix 1) from the vuCalibrationRecords with CalibrationPurpose equal to: ‘03’H\nDate tachograph connected\nRTM18\nCurrent Speed\nThe VU shall generate an integer value for data element RTM18.\nThe VU shall set the value for RTM16 to the last current recorded speed at the time of the latest update of the RtmData.\nLast current recorded speed\nRTM19\nTimestamp\nFor data element RTM19 the VU shall generate an integer value (timeReal from Appendix 1).\nThe VU shall set the value for RTM19 to the time of the latest update of the RtmData.\nTimestamp of current\nTachographPayload record\n5.4.6\nData transfer mechanism\nDSC_42\nPayload data defined previously are requested by the REDCR after initialisation phase, and consequently transmitted by the DSRC-VU in the allocated window. The command GET is used by the REDCR to retrieve data.\nDSC_43\nFor all DSRC exchanges, data shall be encoded using PER (Packed Encoding Rules) UNALIGNED, apart from and , which shall be encoded using OER (Octet Encoding Rules) defined in ISO/IEC 8825-7, Rec. ITU-T X.696.\n5.4.7\nDetailed DSRC transaction description\nDSC_44\nInitialisation is performed according to DSC_44 — DSC_48 and Tables 14.4 — 14.9. In the initialisation phase, the REDCR starts sending a frame containing a BST (Beacon Service Table) according to EN 12834 and EN 13372, 6.2, 6.3, 6.4 and 7.1 with settings as specified in the following Table 14.4.\nTable 14.4\nInitialisation — BST frame settings\nField\nSettings\nLink Identifier\nBroadcast address\nBeaconId\nAs per EN 12834\nTime\nAs per EN 12834\nProfile\nNo extension, 0 or 1 to be used\nMandApplications\nNo extension, EID not present, Parameter not present, AID= 2 Freight&Fleet\nNonMandApplications\nNot present\nProfileList\nNo extension, number of profiles in list = 0\nFragmentation header\nNo fragmentation\nLayer 2 settings\nCommand PDU, UI command\nA practical example of the settings specified in Table 14.4, with an indication of bit encodings, is given in the following Table 14.5.\nTable 14.5\nInitialisation — BST frame contents example\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nBroadcast ID\nBroadcast address\n3\nMAC Control Field\nCommand PDU\n4\nLLC Control field\nUI command\n5\nFragmentation header\nNo fragmentation\n6\nBST\nInitialisation request\nSEQUENCE {\nOPTION indicator\nBeaconID\nSEQUENCE {\nManufacturerId\nINTEGER (0..65535)\nNonMand applications not present\nManufacturer Identifier\n7\n8\nIndividualID\nINTEGER (0..134217727)\n}\n27 bit ID available for manufacturer\n9\n10\n11\n12\nTime\nINTEGER (0..4294967295)\n32 bit UNIX real time\n13\n14\n15\n16\nProfile\nINTEGER (0..127,...)\nNo extension. Example profile 0\n17\nMandApplications\nSEQUENCE (SIZE(0..127,...)) OF {\nNo extension, Number of mandApplications = 1\n18\nSEQUENCE {\nOPTION indicator\nEID not present\nOPTION indicator\nParameter not present\nAID\nDSRCApplicationEntityID } }\nNo extension. AID= 2 Freight&Fleet\n19\nProfileList\nSEQUENCE (0..127,...) OF Profile }\nNo extension, number of profiles in list = 0\n20\nFCS\nFrame check sequence\n21\n22\nFlag\nEnd Flag\nDSC_45\nA DSRC-VU, when receiving a BST, requires the allocation of a private window, as specified by EN 12795 and EN 13372, 7.1.1, with no specific RTM settings. Table 14.6 provides an example of bit encoding.\nTable 14.6\nInitialisation — Private window allocation request frame contents\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nPrivate window request\n7\nFCS\nFrame check sequence\n8\n9\nFlag\nEnd Flag\nDSC_46\nThe REDCR then answers by allocating a private window, as specified by EN 12795 and EN 13372, 7.1.1 with no specific RTM settings.\nTable 14.7 provides an example of bit encoding.\nTable 14.7\nInitialisation — Private window allocation frame contents\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nPrivate window allocation\n7\nFCS\nFrame check sequence\n8\n9\nFlag\nEnd Flag\nDSC_47\nThe DSRC-VU, when receiving the private window allocation, sends its VST (Vehicle Service Table) as defined in EN 12834 and EN 13372, 6.2, 6.3, 6.4 and 7.1 with settings as specified Table 14.8, using the allocated transmission window.\nTable 14.8\nInitialisation — VST frame settings\nField\nSettings\nPrivate LID\nAs per EN 12834\nVST parameters\nFill=0, then for each supported application: EID present, parameter present, AID=2, EID as generated by the OBU\nParameter\nNo extension, Contains the RTM Context Mark\nObeConfiguration\nThe optional ObeStatus field may be present, but shall not be used by the REDCR\nFragmentation header\nNo fragmentation\nLayer 2 settings\nCommand PDU, UI command\nDSC_48\nThe DSRC-VU shall support the ‘Freight and Fleet’ application, identified by the Application Identifier ‘2’. Other Application Identifiers may be supported, but shall not be present in this VST, as the BST only requires AID=2. The ‘Applications’ field contains a list of the supported application instances in the DSRC-VU. For each supported application instantiation, a reference to the appropriate standard is given, made of an Rtm Context mark, which is composed of an OBJECT IDENTIFIER representing the related standard, its part (9 for RTM) and possibly its version, plus an EID that is generated by the DSRC-VU, and associated to that application instance.\nA practical example of the settings specified in Table 14.8, with an indication of bit encodings, is given in Table 14.9.\nTable 14.9\nInitialisation — VST frame contents example\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nCommand PDU\n7\nLLC Control field\nUI command\n8\nFragmentation header\nNo fragmentation\n9\nVST\nSEQUENCE {\nInitialisation response\nFill\nBIT STRING (SIZE(4))\nUnused and set to 0\n10\nProfile\nINTEGER (0..127,...)\nApplications\nSEQUENCE OF {\nNo extension. Example profile 0\n11\nNo extension, 1 application\n12\nSEQUENCE {\nOPTION indicator\nEID present\nOPTION indicator\nParameter present\nAID\nDSRCApplicationEntityID\nNo extension. AID= 2 Freight&Fleet\n13\nEID Dsrc-EID\nDefined within the OBU and identifying the application instance.\n14\nParameter Container {\nNo extension, Container Choice = 02, Octet string\n15\nNo extension, Rtm Context Mark length = 8\n16\nRtm-ContextMark::= SEQUENCE {\nStandardIdentifier\nstandardIdentifier\nObject Identifier of the supported standard, part, and version. Example: ISO (1) Standard (0) TARV (15638) part9 (9) Version1 (1).\nFirst octet is 06H, which is the Object Identifier. Second octet is 06H, which is its length. Subsequent 6 octets encode the example Object Identifier.\n17\n18\n19\n20\n21\n22\n23\n24\nObeConfiguration Sequence {\nOPTION indicator\nObeStatus not present\nEquipmentClass\nINTEGER (0..32767)\n25\n26\nManufacturerId\nINTEGER (0..65535)\nManufacturer identifier for the DSRC-VU as described in ISO 14816 Register\n27\n28\nFCS\nFrame check sequence\n29\n30\nFlag\nEnd Flag\nDCS_49\nThe REDCR then reads the data by issuing a GET command, conforming to the GET command defined in EN 13372, 6.2, 6.3, 6.4 and EN 12834, with settings as specified in Table 14.10.\nTable 14.10\nPresentation — GET request frame settings\nField\nSettings\nInvoker Identifier (IID)\nNot present\nLink Identifier (LID)\nLink address of the specific DSRC-VU\nChaining\nNo\nElement Identifier (EID)\nAs specified in the VST. No extension\nAccess Credentials\nNo\nAttributeIdList\nNo extension, 1 attribute, AttributeID = 1 (RtmData)\nFragmentation\nNo\nLayer2 settings\nCommand PDU, Polled ACn command\nTable 14.11 shows an example of reading the RTM data.\nTable 14.11\nPresentation — Get Request frame example\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nCommand PDU\n7\nLLC Control field\nPolled ACn command, n bit\n8\nFragmentation header\nNo fragmentation\n9\nGet.request\nSEQUENCE {\nGet request\nOPTION indicator\nAccess Credentials not present\nOPTION indicator\nIID not present\nOPTION indicator\nAttributeIdList present\nFill\nBIT STRING(SIZE(1))\nSet to 0.\n10\nEID INTEGER(0..127,…)\nThe EID of the RTM application instance, as specified in the VST. No extension\n11\nAttributeIdList SEQUENCE OF {\nAttributeId }}\nNo extension, number of attributes = 1\n12\nAttributeId=1, RtmData. No extension\n13\nFCS\nFrame check sequence\n14\n15\nFlag\nEnd Flag\nDSC_50\nThe DSRC-VU, when receiving the GET request, sends a GET response with the requested data conforming to the GET response defined in EN 13372, 6.2, 6.3, 6.4 and EN 12834, with settings as specified in Table 14.12.\nTable 14.12\nPresentation — GET response frame settings\nField\nSettings\nInvoker Identifier (IID)\nNot present\nLink Identifier (LID)\nAs per EN 12834\nChaining\nNo\nElement Identifier (EID)\nAs specified in the VST.\nAccess Credentials\nNo\nFragmentation\nNo\nLayer2 settings\nResponse PDU, Response available and command accepted, ACn command\nTable 14.13 shows an example of reading the RTM data.\nTable 14.13\nPresentation — Response frame contents example\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nResponse PDU\n7\nLLC Control field\nResponse available, ACn command n bit\n8\nLLC Status field\nResponse available and command accepted\n9\nFragmentation header\nNo fragmentation\n10\nGet.response\nSEQUENCE {\nGet response\nOPTION indicator\nIID not present\nOPTION indicator\nAttribute List present\nOPTION indicator\nReturn status not present\nFill\nBIT STRING(SIZE(1))\nNot used\n11\nEID\nINTEGER(0..127,…)\nResponding from the RTM application\nInstance. No extension,\n12\nAttributeList\nSEQUENCE OF {\nNo extension, number of attributes = 1\n13\nAttributes\nSEQUENCE {\nAttributeId\nNo extension, AttributeId=1 (RtmData)\n14\nAttributeValue\nCONTAINER {\nNo extension, Container Choice = 1010.\n15\nRtmData\n16\n17\n…\n…\nn\n}}}}\nn+1\nFCS\nFrame check sequence\nn+2\nn+3\nFlag\nEnd Flag\nDSC_51\nThe REDCR then closes the connection by issuing a EVENT_REPORT, RELEASE command conforming to EN 13372, 6.2, 6.3, 6.4 and EN 12834,7.3.8, with no specific RTM settings. Table 14.14 shows a bit encoding example of the RELEASE command.\nTable 14.14\nTermination. EVENT_REPORT Release frame contents\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nThe frame contains a command LPDU\n7\nLLC Control field\nUI command\n8\nFragmentation header\nNo fragmentation\n9\nEVENT_REPORT.request\nSEQUENCE {\nEVENT_REPORT (Release)\nOPTION indicator\nAccess Credentials not present\nOPTION indicator\nEvent parameter not present\nOPTION indicator\nIID not present\nMode\nBOOLEAN\nNo response expected\n10\nEID\nINTEGER (0..127,…)\nNo extension, EID = 0 (System)\n11\nEventType\nINTEGER (0..127,…) }\nEvent type 0 = Release\n12\nFCS\nFrame check sequence\n13\n14\nFlag\nEnd Flag\nDSC_52\nThe DSRC-VU is not expected to answer to the Release command. The communication is then closed.\n5.4.8\nDSRC Test transaction description\nDSC_53\nFull tests that include securing the data, need to be carried out as defined in Appendix 11 Common Security Mechanisms, by authorised persons with access to security procedures, using the normal GET command as defined above.\nDSC_54\nCommissioning and periodic inspection tests that require decrypting and comprehension of the decrypted data content shall be undertaken as specified in Appendix 11 Common Security Mechanisms and Appendix 9, Type Approval List of Minimum required tests.\nHowever, the basic DSRC communication can be tested by the command ECHO. Such tests may be required on commissioning, at periodic inspection, or otherwise to the requirement of the competent control authority or Regulation (EU) No 165/2014 (See 6 below)\nDSC_55\nIn order to effect this basic communication test, the ECHO command is issued by the REDCR during a session, i.e., after an initialisation phase has been completed successfully. The sequence of interactions is thus similar to that of an interrogation:\n— Step 1The REDCR sends a ‘beacon service table’ (BST) that includes the application identifiers (AIDs) in the service list that it supports. In the RTM applications this will simply be the service with the AID value = 2.\nThe DSRC-VU evaluates the received BST, and where it identifies that the BST is requesting Freight&Fleet (AID = 2), the DSRC-VU shall respond. If the REDCR does not offer AID=2, the DSRC-VU shall shut down its transaction with the REDCR.\n— Step 2The DSRC-VU sends a request for a private window allocation.\n— Step 3The REDCR sends a private window allocation.\n— Step 4The DSRC-VU uses the allocated private window to send its vehicle service table (VST). This VST includes a list of all the different application instantiations that this DSRC-VU supports in the framework of AID=2. The different instantiations shall be identified by means of uniquely EIDs, each associated with a parameter value indicating the instance of the application that is supported.\n— Step 5Next the REDCR analyses the offered VST, and either terminates the connection (RELEASE) since it is not interested in anything the VST has to offer (i.e., it is receiving a VST from a DSRC-VU that is not an RTM VU, or, if it receives an appropriate VST it starts an app instantiation.\n— Step 6The REDCR shall issue a command (ECHO) to the specific DSRC-VU, and allocates a private window.\n— Step 7The DSRC-VU uses the newly allocated private window to send an ECHO response frame.\nThe following tables give a practical example of an ECHO exchange session.\nDSC_56\nInitialisation is performed according to 5.4.7 (DSC_44 — DSC_48) and Tables 14.4 — 14.9\nDSC_57\nThe REDCR then issues an ACTION, ECHO command conforming to ISO 14906, containing 100 octets of data and with no specific settings for RTM. Table 14.15 shows the contents of the frame sent by the REDCR.\nTable 14.15\nACTION, ECHO request frame example\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific DSRC-VU\n3\n4\n5\n6\nMAC Control field\nCommand PDU\n7\nLLC Control field\nPolled ACn command, n bit\n8\nFragmentation header\nNo fragmentation\n9\nACTION.request\nSEQUENCE {\nAction request (ECHO)\nOPTION indicator\nAccess Credentials not present\nOPTION indicator\nAction parameter present\nOPTION indicator\nIID not present\nMode\nBOOLEAN\nResponse expected\n10\nEID\nINTEGER (0..127,…)\nNo extension, EID = 0 (System)\n11\nActionType\nINTEGER (0..127,…)\nNo extension, Action type ECHO request\n12\nActionParameter\nCONTAINER {\nNo extension, Container Choice = 2\n13\nNo extension. String length = 100 octets\n14\nData to be echoed\n…\n…\n113\n}}\n114\nFCS\nFrame check sequence\n115\n116\nFlag\nEnd Flag\nDSC_58\nThe DSRC-VU, when receiving the ECHO request, sends an ECHO response of 100 octets of data by reflecting the received command, according to ISO 14906, with no specific settings for RTM. Table 14.16 shows a bit level encoding example.\nTable 14.16\nACTION, ECHO response frame example\nOctet #\nAttribute/Field\nBits in octet\nDescription\n1\nFLAG\nStart flag\n2\nPrivate LID\nLink address of the specific VU\n3\n4\n5\n6\nMAC Control field\nResponse PDU\n7\nLLC Control field\nACn command n bit\n8\nLLC status field\nResponse available\n9\nFragmentation header\nNo fragmentation\n10\nACTION.response\nSEQUENCE {\nACTION response (ECHO)\nOPTION indicator\nIID not present\nOPTION indicator\nResponse parameter present\nOPTION indicator\nReturn status not present\nFill\nBIT STRING (SIZE (1))\nNot used\n11\nEID\nINTEGER (0..127,…)\nNo extension, EID = 0 (System)\n12\nResponseParameter\nCONTAINER {\nNo extension, Container Choice = 2\n13\nNo extension. String length = 100 octets\n14\nEchoed data\n…\n…\n113\n}}\n114\nFCS\nFrame check sequence\n115\n116\nFlag\nEnd Flag\n5.5\nSupport for Directive (EU) 2015/719\n5.5.1\nOverview\nDSC_59\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.5.2\nCommands\nDSC_60\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.5.3\nInterrogation command sequence\nDSC_61\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.5.4\nData structures\nDSC_62\nThe payload (OWS data) consists of the concatenation of\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.5.5\nASN.1 module for the OWS DSRC transaction\nDSC_63.\nThe ASN.1 module definition for the DSRC data within the RTM application is defined as follows:\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.5.6\nElements of OwsData, actions performed and definitions\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.5.7\nData transfer mechanisms\nDSC_64\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\nDSC_65\n. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .\n5.6\nData transfer between the DSRC-VU and VU\n5.6.1\nPhysical Connection and interfaces\nDSC_66\nThe connection between the VU and the DSRC-VU can be either by physical cable or short range wireless communication based on Bluetooth v4.0 BLE.\nDSC_67\nRegardless of the choice of the physical connection and interface, the following requirements shall be satisfied:\nDSC_68\na)\nIn order that different suppliers may be contracted to supply the VU and the DSRC-VU, and indeed different batches of DSRC-VU, the connection between the VU and the DSRC-VU not internal to the VU shall be an open standard connection. The VU shall connect with the DSRC-VU either\ni))using fixed cable of at least 2 meters, using a Straight DIN 41612 H11 Connector — 11 pin approved male connector from the DSRC-VU to match a similar DIN/ISO approved female connector from the VU device,\nii))using Bluetooth Low Energy (BLE)\niii))using a standard ISO 11898 or SAE J1939 connection\nDSC_69\nb)\nthe definition of the interfaces and connection between the VU and DSRC-VU must support the application protocol commands defined in 5.6.2. and\nDSC_70\nc)\nthe VU and DSRC-VU must support the operation of the data transfer via the connection in regard to performance and power supply.\n5.6.2\nApplication Protocol\nDSC_71\nThe application protocol between the VU Remote Communication facility and DSRC-VU is responsible for periodically transferring the remote communication data from the VU to the DSRC.\nDSC_72\nThe following main commands are identified:\n1..Initialisation of the communication link — Request\n2..Initialisation of the communication link — Response\n3..Send Data with Identifier of the RTM application and Payload defined by RTM Data\n4..Acknowledgment of the data\n5..Termination of the communication link — Request\n6..Termination of the communication link — Response\nDSC_73\nIn ASN1.0, the previous commands may be defined as:\nDSC_74\nThe description of the commands and parameters is following:\nis used to initialize the communication link. The command is sent by the VU to the DSRC-VU. The LinkIdentifier is set by the VU and communicated to the DSRC-VU to track a specific communication link.\n(Note: this is to support future links and other application/modules like Weighing on board).\nis used by the DSRC-VU to provide the response of the request to initialize the communication link. The command is sent by the DSRC-VU to the VU. The command provides the result of the initialisation as answer = 1 (Success) or =0 (Failure).\nDSC_75\nThe initialization of the communication link shall be done only after installation, calibration, and start of the engine/VU is switched on.\nis used to by the VU to send the signed RCDTData (i.e., the remote communication Data) to the DSRC-VU. The data will be sent every 60 seconds. The DataTransactionId parameter identifies the specific transmission of data. The LinkIdentifier is also used to ensure that the appropriate link is correct.\nis sent by the DSRC-VU to provide the feedback to the VU on the reception of the data from a command identified by the DataTransactionId parameter. The Answer parameter is 1 (Success) or =0 (Failure). If a VU receives more than three answers equal to 0 or if the VU does not receive a RCDT Data Acknowledgment for a specific previously sent RCDT- Send Data with a specific DataTransactionId, the VU will generate and record an event.\nis sent by the VU to DSRC-VU to terminate a link for a specific LinkIdentifier.\nDSC_76\nAt the restart of the DSRC-VU or a VU, all the existing Communication Links should be removed as there could be ‘dangling’ Links due to the sudden shutdown of a VU.\nis sent by the DSRC-VU to the VU to confirm the request of termination of the link by the VU for the specific LinkIdentifier.\n5.7\nError handling\n5.7.1\nRecording and communication of the Data in the DSRC-VU\nDSC_77\nThe Data shall be provided, already secure d, b y the VUSM function to the DSRC-VU . The VUSM shall verify that data recorded in the DSRC-VU has been recorded correctly. The recording and reporting of any errors in the transfer of data from the VU to the memory of the DSRC-VU shall be recorded with type EventFaultType and enum value set to ‘0C’H Communication error with the remote communication facility event together with the timestamp.\nDSC_78\nThe VU shall maintain a file identified by a unique name that is easily identifiable by inspectors for the purpose of recording ‘VU internal communication failures’.\nDSC_79\nIf the VUPM attempts to obtain VU data from the security module (to pass to the VU-DSRC), but fails to do so, it shall record that failure with type EventFaultType and enum value set to ‘62’H Remote Communication Facility' communication fault together with the timestamp. The failure of the communication is detected when a message is not received for the related (i.e., with the same DataTransactionId messages) for more than three consecutive times.\n5.7.2\nWireless Communication errors\nDSC_80\nCommunication error handling shall be consistent with the related DSRC standards, namely EN 300 674-1, EN 12253, EN 12795, EN 12834 and the appropriate parameters of EN 13372.\n5.7.2.1\nEncryption and signature errors\nDSC_81\nEncryption and signature errors shall be handled as defined in Appendix 11 Common Security Mechanisms and are not present in any error messages associated with the DSRC transfer of data.\n5.7.2.2\nRecording of errors\nThe DSRC medium is a dynamic wireless communication in an environment of uncertain atmospheric and interference conditions, particularly in the ‘portable REDCR’ and ‘moving vehicle’ combinations involved in this application. It is therefore necessary to ascertain the difference between a ‘read failure’ and an ‘error’ condition. In a transaction across a wireless interface, read failure is common and the consequence is usually to retry, i.e. rebroadcast the BST and reattempt the sequence, which will in most circumstances lead to a successful communication connection and transfer of data, unless the target vehicle moves out of range during the time required to retransmit. (A ‘successful’ instance of a ‘read’ may have involved several attempts and retries).\nRead failure may be because the antennas were not paired properly (failure of ‘aiming’); because one of the antennas is shielded — this may be deliberate, but also can be caused by the physical presence of another vehicle; radio interference, especially from circa 5.8 GHz WIFI or other public access wireless communications, or may be caused by radar interference, or difficult atmospheric conditions (e.g. during a thunderstorm); or simply by moving out of the range of the DSRC communication. Individual instances of read failures, by their nature, cannot be recorded, simply because the communication simply did not occur.\nHowever, if the agent of the competent control authority targets a vehicle and attempts to interrogate its DSRC-VU, but no successful transfer of data ensues, this failure could have occurred because of deliberate tampering, and therefore the agent of the competent control authority needs a means to log the failure, and alert colleagues downstream that there may be a violation. The colleagues can then stop the vehicle and carry out a physical inspection. However, as no successful communication has taken place, the DSRC-VU cannot provide data concerning the failure. Such reporting shall therefore be a function of REDCR equipment design.\n‘Failure to read’ is technically different to an ‘error’. In this context an ‘error’ is the acquisition of a wrong value.\nData transferred to the DSRC-VU is supplied already secured, therefore must be verified by the supplier of the data (see 5.4).\nData subsequently transferred across the air interface is checked by cyclic redundancy checks at the communications level. If the CRC validates, then the data is correct. If the CRC does not validate, the data is retransmitted. The probability that data could successfully pass through a CRC incorrectly is statistically so highly improbable that it may be discounted.\nIf the CRC does not validate and there is no time to retransmit and receive the correct data, then the result will not be an error, but an instantiation of a specific type of read failure.\nThe only meaningful ‘failure’ data that can be recorded is that of the number of successful initiations of transactions that occur, that do not result in a successful transfer of data to the REDCR.\nDSC_82\nThe REDCR shall therefore record, time-stamped, the number of occasions where the ‘initialisation’ phase of a DSRC interrogation is successful, but the transaction terminated before the Data was successfully retrieved by the REDCR. This data shall be available to agent of the competent control authority and shall be stored in the memory of the REDCR equipment. The means by which this is achieved shall be a matter of product design or the specification of a competent control authority.\nThe only meaningful ‘error’ data that can be recorded is the number of occasions where the REDCR fails to decrypt the Data received. However, it should be noted that this will only relate to the efficiency of the REDCR software. Data may be technically decrypted, but make no semantic sense.\nDSC_83\nThe REDCR shall therefore record, time-stamped, the number of occasions where it has attempted but failed to decipher data received across the DSRC interface.\n6.\nCOMMISSIONING AND PERIODIC INSPECTION TESTS FOR THE REMOTE COMMUNICATION FUNCTION\n6.1\nGeneral\nDSC_84\nTwo type of tests are foreseen for the remote communication function:\n1))An ECHO test to validate the DSRC-REDCR >>-:-<DSRC-VU wireless communication channel.\n2))A End-to-end security test to ensure that a workshop card is able to access the encrypted and signed data content created by the VU and transmitted over the wireless communication channel.\n6.2\nECHO\nThis clause contains provisions specifically made to test only that the DSRC-REDCR >>-:-<DSRC-VU is functionally active.\nThe objective of the ECHO command is to enable workshops or type approval test facilities to test that the DSRC link is working without needing access to security credentials. The tester's equipment therefore only needs to be able to initialise a DSRC communication (sending a BST with AID=2) and then send the ECHO command, and, assuming the DSRC is working, will receive the ECHO response. See 5.4.8 for details. Assuming it receives this response correctly, the DSRC link (DSRC-REDCR >>-:-<DSRC-VU) may be validated as functioning correctly.\n6.3\nTests to validate the secure data content\nDSC_85\nThis test is execute to validate the end-to-end security flow of data. A DSRC test reader is needed for such test. The DSRC test reader performs the same functionality and it is implemented with the same specifications of the reader used by the law enforcers, with the difference that a workshop card shall be used to authenticate the user of the DSRC test reader rather than a control card. The test can be executed after the initial activation of a Smart Tachograph or at the end of the calibration procedure. After the activation, the vehicle unit shall generate and communicate to the DSRC-VU the secured early detection data.\nDSC_86\nThe workshop personnel must position the DSRC test reader at a distance between 2 and 10 metres in front of the vehicle.\nDSC_87\nThen the workshop personnel will insert a workshop card in the DSRC test reader to request the interrogation of the early detection data to the vehicle unit. After a successful interrogation, the workshop personnel will access the received data to ensure that it has been successfully validated for integrity and decrypted.",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "Substituted by Commission Implementing Regulation (EU) 2018/502 of 28 February 2018 amending Implementing Regulation (EU) 2016/799 laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)."
    },
    {
      "type": "F",
      "label": "F2",
      "text": "Deleted by Commission Implementing Regulation (EU) 2020/158 of 5 February 2020 amending Implementing Regulation (EU) 2016/799 for the purpose of on-board weighing equipment (Text with EEA relevance)."
    },
    {
      "type": "footnote",
      "label": "f1",
      "text": "– Downlink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1."
    },
    {
      "type": "footnote",
      "label": "f2",
      "text": "– Uplink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1"
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/2016/799/annex/1/appendix/14",
    "retrieved_at": "2026-11-01T14:45:49.686558+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."
}