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)

• (d) In point 4.4.1, paragraph GNS_28 is replaced by the following:

• ‘GNS_28 If the VU does not manage to communicate to the coupled external GNSS facility for more than 20 continuous minutes, the VU shall generate and record in the VU an event of type EventFaultType with the value of enum ‘0E’H Communication error with the external GNSS facility and with the timestamp set to the current time. The event will be generated only if the following two conditions are satisfied: (a) the Smart Tachograph is not in calibration mode and (b) the vehicle is moving. In this context, a communication error is triggered when the VU Secure Transceiver does not receive a response message after a request message as described in 4.2.’;

• (e) in point 4.4.2, paragraph GNS_29 is replaced by the following:

• ‘GNS_29 If the external GNSS facility has been breached, the GNSS Secure Transceiver shall erase all its memory including cryptographic material. As described in GNS_25 and GNS_26, the VU shall detect tampering if the Response has status ‘6690’. The VU shall then generate an event of type EventFaultType enum ‘19’H Tamper detection of GNSS. Alternately, the external GNSS facility may not respond to any external request anymore.’;

• (f) in point 4.4.3, paragraph GNS_30 is replaced by the following:

• ‘GNS_30 If the GNSS Secure Transceiver does not receive data from the GNSS receiver for more than 3 continuous hours, the GNSS Secure Transceiver shall generate a response message to the READ RECORD command with RECORD number equal to ‘01’ with a Data Field of 12 bytes all set to 0xFF. Upon reception of the Response message with this value of the data field, the VU shall generate and record an event of type EventFaultType enum ‘0D’H Absence of position information from GNSS receiver event with a timestamp equal to the current value of time only if the following two conditions are satisfied: a) the Smart Tachograph is not in calibration mode and b) the vehicle is moving.’;

• (g) in point 4.4.4, the text in paragraph GNS_31 until Figure 4, is replaced by the following:

‘If the VU detects that the EGF certificate used for mutual authentication is not valid any longer, the VU shall generate and record a recording equipment event of type EventFaultType enum ‘ 1B’H External GNSS facility certificate expired with a timestamp equal to the current value of time. The VU shall still use the received GNSS position data.’;

• (h) in point 5.2.1, paragraph GNS_34 is replaced by the following:

• ‘GNS_34 If the VU does not receive data from the GNSS receiver for more than 3 continous hours, the VU shall generate and record an event of type EventFaultType enum ‘0D’H Absence of position information from GNSS receiver event with a timestamp equal to the current value of time only if the following two conditions are satisfied: (a) the Smart Tachograph is not in calibration mode and (b) the vehicle is moving.’;

• (i) point 6 is replaced by the following:

‘6.   GNSS TIME CONFLICT

If the VU detects a discrepancy of more than 1 minute between the time of the vehicle unit's time measurement function and the time originating from the GNSS receiver, the VU will record an event of type EventFaultType enum ‘ 0B’H Time conflict (GNSS versus VU internal clock). After a time conflict event has been triggered, the VU will not check the time discrepancy for the next 12 hours. This event shall not be triggered in cases no valid GNSS signal was detectable by the GNSS receiver within the last 30 days.’;

• (38) Appendix 13 is amended as follows:

• (a) in point 2, the fourth paragraph is replaced by the following:

‘For clarification, this Appendix does not specify:

— The collection of the Data operation and management within the VU (which shall be specified elsewhere within the Regulation or otherwise shall be a function of product design).

— The form of presentation of collected data to application hosted on the external device.

— Data security provisions above what provides Bluetooth® (such as encryption) concerning the content of the Data (which shall be specified elsewhere within the Regulation [Appendix 11 Common Security Mechanisms]).

— The Bluetooth® protocols used by the ITS interface’;

• (b) in point 4.2, the third paragraph is replaced by the following:

‘When an external device comes within range of the VU for the first time, the Bluetooth® pairing process can be initiated (see also annex 2). The devices share their addresses, names, and profiles and common secret key, which allows them to bond whenever they are together in the future. Once this step is completed, the external device is trusted and is in state to initiate requests to download data from the tachograph. It is not foreseen to add encryption mechanisms beyond what Bluetooth® provides. However, if additional security mechanisms are needed, this will be done in accordance with Appendix 11 Common Security Mechanisms.’;

• (c) point 4.3 is amended as follows:

• (i) the first paragraph is replaced by the following:

‘For security reasons, the VU will require a PIN code authorization system separated from the Bluetooth pairing. Each VU shall be able to generate PIN codes for authentication purposes composed of at least 4 digits. Every time an external device pairs with the VU, it must provide the correct PIN code before receiving any data.’;

• (ii) the third paragraph after Table 1 is replaced by the following:

‘While the manufacturer may offer an option to change the PIN code directly through the VU, the PUC code shall not be alterable. Modifying the PIN code, if possible, shall require to enter the current PIN code directly in the VU.’;

• (d) in point 4.4, the second paragraph after the heading "Data Field" is replaced by the following:

‘If the data to be handled is larger than the available space in one message, it will be split in several submessages. Each submessage shall have the same Header and SID, but will contain a 2-bytes counter, Counter Current (CC) and Counter Max (CM), to indicate the submessage number. To enable error checking and abort the receiving device acknowledges every submessage. The receiving device can accept the submessage, ask for it to be re-transmitted, request the sending device to start again or abort the transmission.’;

• (e) Annex 1 is amended as follows:

• (i) the heading is replaced by the following:

‘(1)   LIST OF AVAILABLE DATA THROUGH THE ITS INTERFACE’;

• (ii) the following item is inserted in the table in point (3), after the item ‘Absence of position information from GNSS receiver’:

‘Communication error with the external GNSS facility	— the longest event for each of the 10 last days of occurrence, — the 5 longest events over the last 365 days.	— date and time of beginning of event, — date and time of end of event, — card(s) type, number, issuing Member State and generation of any card inserted at beginning and/or end of the event, — number of similar events that day.’

• (iii) in point (5), the following dash is added:

• ‘— ITS interface fault (if applicable)’;

• (f) the ASN.1 specifications in Annex 3 are amended as follows:

• (i) the following lines 206a to 206e are inserted after line 206:

‘

Text of image

’206a

206b

DriverID ::= SEQUENCE{

206c

issuingMemberState OCTET STRING (SIZE(3)),

206d

cardNumber OCTET STRING (SIZE(16))

206e }’;

’

• (ii) lines 262 to 264 are replaced by the following:

‘

Text of image

‘262

driveRecognize BIT STRING ('00'B UNION '01'B),

263

driverCardDriver1 BIT STRING ('00'B UNION '01'B),

264

driverCardDriver2 BIT STRING ('00'B UNION '01'B), ’;

’

• (iii) line 275 is replaced by the following:

‘

Text of image

‘275

outOfScopeCondition BIT STRING ('00'B UNION '01'B),‘;

’

• (iv) lines 288 to 310 are replaced by the following:

‘

Text of image

‘288

driver1WorkingState BIT STRING ('000'B UNION '001'B UNION '010'B UNION

289

'011'B UNION '100'B UNION '101'B …),

290

driver2WorkingState BIT STRING ('000'B UNION '001'B UNION '010'B UNION

291

'011'B UNION '100'B UNION '101'B …),

292

293

driver1TimeRelatedStates BIT STRING ('0000'B UNION '0001'B

294

UNION '0010'B UNION '0011'B UNION '0100'B UNION '0101'B UNION

295

'0110'B UNION '0111'B UNION '1000'B UNION '1001'B UNION '1010'B

296

UNION '1011'B UNION '1100'B UNION '1101'B …),

297

298

299

driver2TimeRelatedStates BIT STRING ('0000'B UNION '0001'B

300

UNION '0010'B UNION '0011'B UNION '0100'B UNION '0101'B UNION

301

'0110'B UNION '0111'B UNION '1000'B UNION '1001'B UNION '1010'B

302

UNION '1011'B UNION '1100'B UNION '1101'B …),

303

304

305

306

overSpeed BIT STRING ('00 'B UNION '01 'B),

307

driver1Identification DriverID,

308

driver2Identification DriverID,

309

310’

’

• (v) lines 362 and 363 are replaced by the following:

‘

Text of image

‘362

driver1MaximumDailyDrivingTime BIT STRING (SIZE(4)),

363

driver2MaximumDailyDrivingTime BIT STRING (SIZE(4)),’;

’

• (vi) the following lines 410a and 410b are inserted after line 410:

‘

Text of image

‘410a

comErrorWithExternalGNSSFacility

410b

CommunicationErrorWithTheExternalGNSSFacility,’;

’

• (vii) the following lines 539a to 539j are inserted after line 539:

‘

Text of image

‘539a

CommunicationErrorWithTheExternalGNSSFacility ::= SEQUENCE{

539b

beginDate GeneralizedTime,

539c

endDate GeneralizedTime,

539d

cardsType SEQUENCE OF UTF8String,

539e

cardsNumber SEQUENCE OF INTEGER,

539f

issuingMemberState SEQUENCE OF NationAlpha,

539g

cardsGeneration SEQUENCE OF INTEGER,

539h

numberOfSimilarEvent INTEGER

539i

}

539j’;

’

• (39) Appendix 14 is amended as follows:

• (a) item 5.5 in the Table of Contents is replaced by the following:

‘5.5   Support for Directive (EU) 2015/719 … 490’;

• (b) in point 2, the third paragraph is replaced by the following:

‘In 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.’;

• (c) point 5.1 is amended as follows:

• (i) in paragraph DSC_19, the twelfth dash is replaced by the following:

• ‘— The 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.’;

• (ii) in paragraph DSC_22, the first sub-paragraph is replaced by the following:

‘The 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.’;

• (d) in point 5.4.3, sequence 7 is replaced by the following:

‘7	REDCR	>	DSRC-VU	Sends GET.request for data of other Attribute (if appropriate)’

• (e) in point 5.4.4, the ASN.1 module definition in paragraph DCS_40 is amended as follows:

• (i) the first line of the sequence for

Image omitted; see official source

is replaced by the following: ‘

Text of image

‘tp15638VehicleRegistrationPlate LPN – Vehicle Registration Plate as per EN 15509¹’

’

• (ii) the following footnote 1 is added:

• ‘1. if a LPN contains an AlphabetIndicator LatinAlphabetNo2 or latinCyrillicAlphabet, the special characters are remapped at the road interrogator unit applying special rules according to Annex E of ISO/DIS 14 906,2’;

• (iii) the superscript 2 is removed from the line where the Timestamp of current record is defined;

• (iv) the ASN.1 module definition for

Image omitted; see official source

is replaced by the following: ‘

Text of image

‘RtmTransferAck ::= INTEGER {

Ok (1),

NoK (2)

} (1..255)’;

’

• (f) in point 5.4.5, item RTM12 in table 14.3 is replaced by the following:

‘RTM12 Sensor Fault	The VU shall generate an integer value for data element RTM12. The VU shall assign to the variable sensorFault a value of: — 1 if an event of type ‘35H’ Sensor fault has been recorded in the last 10 days, — 2 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. — 3 if an event of type ‘0E’H Communication error with the external GNSS facility event has been recorded in the last 10 days. — 4 If both Sensor Fault and GNSS receiver faults have been recorded in the last 10 days — 5 If both Sensor Fault and Communication error with the external GNSS facility event have been recorded in the last 10 days — 6 If both GNSS receiver fault and Communication error with the external GNSS facility event have been recorded in the last 10 days — 7 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	– sensor fault one octet as per data dictionary	Image omitted; see official source’

• (g) in point 5.4.6, DSC_43 is replaced by the following:

• ‘DSC_43 For all DSRC exchanges, data shall be encoded using PER (Packed Encoding Rules) UNALIGNED, apart from Image omitted; see official source and Image omitted; see official source , which shall be encoded using OER (Octet Encoding Rules) defined in ISO/IEC 8825-7, Rec. ITU-T X.696.’;

• (h) in point 5.4.7, in the Fourth column of Table 14.9, the text in the cell describing

Image omitted; see official source

is replaced by the following:

‘Object Identifier of the supported standard, part, and version. Example: ISO (1) Standard (0) TARV (15638) part9 (9) Version1 (1).

First octet is 06H, which is the Object Identifier. Second octet is 06H, which is its length. Subsequent 6 octets encode the example Object Identifier.’;

• (i) points 5.5 and 5.5.1 are replaced by the following:

‘5.5.   Support for Directive (EU) 2015/719

5.5.1.   Overview

	DSC_59	To support the Directive (EU) 2015/719 on the maximal weights and dimensions for heavy goods vehicles, the transaction protocol to download OWS data across the 5,8 GHz DSRC interface link will be the same as that used for the RTM data (see 5.4.1), the only difference being that the Object Identifier that relates to the TARV standard will be addressing the ISO 15638 standard (TARV) Part 20 related to WOB/OWS.’;

• (j) in point 5.6.1, sub-paragraph (a) in paragraph DSC_68 is replaced by the following:

• ‘(a) In 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’;

• (k) in point 5.7.1, paragraph DSC_77 is replaced by the following:

• ‘DSC_77 The Data shall be provided, already secured, by 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.’;

• (40) Appendix 15 is amended as follows:

• (a) the first paragraph of point 2.2 is replaced by the following:

‘It is understood that first generation tachograph cards are interoperable with first generation vehicle units in compliance with Annex IB to Regulation (EEC) No 3821/85, while second generation tachograph cards are interoperable with second generation vehicle units in compliance with Annex IC to this Regulation. In addition, the requirements below shall apply.’;

• (b) in point 2.4.1, paragraph MIG_11 is amended as follows:

• (i) the first indent is replaced by the following:

• ‘— non signed EFs IC and ICC (optional),’;

• (ii) the third indent is replaced by the following:

• ‘— the other application data EFs (within DF Tachograph) requested by the first generation card download protocol. This information shall be secured with a digital signature, according to the first generation security mechanisms.

Such download shall not include application data EFs only present in second generation driver (and workshop) cards (application data EFs within DF Tachograph_G2).’;

• (c) In point 2.4.3, paragraphs MIG_014 and MIG_015 are replaced by the following:

• ‘MIG_014 Outside the frame of drivers' control by non EU control authorities, data shall be downloaded from second generation vehicle units using the second generation security mechanisms, and the data download protocol specified in Appendix 7 of this Annex.

MIG_015 To allow drivers' control by non EU control authorities, it may optionally also be possible to download data from second generation vehicle units using the first generation security mechanisms. Downloaded data shall then have the same format as data downloaded from a first generation vehicle unit. This capability may be selected through commands in the menu.’;

ANNEX II

Annex II to Regulation (EU) 2016/799 is amended as follows:

• (1) in Chapter I, paragraph b) in point 1 is replaced by the following:

• ‘(b) an approval number corresponding to the number of the approval certificate drawn up for the prototype of the recording equipment or the record sheet or the tachograph card, placed at any point within the immediate proximity of that rectangle.’;

• (2) in Chapter III, point 5 is replaced by the following:

• ‘5. Submitted for approval on …’;

• (3) in Chapter IV, point 5 is replaced by the following:

• ‘5. Submitted for approval on …’.