Commission Implementing Regulation (EU) 2023/980 of 16 May 2023 amending Implementing Regulation (EU) 2016/799 as regards a transitional smart tachograph and its use of the Galileo Open Service Navigation Message Authentication and amending Implementing Regulation (EU) 2021/1228 (Text with EEA relevance)

Article 2

The following paragraph is added in Article 2 of Implementing Regulation (EU) 2021/1228:

‘However, from 25 May 2023, national authorities shall not refuse to grant EU type approval for a new type of tachograph, tachograph component, or tachograph card, or grant extension for an existing type of tachograph, tachograph component, or tachograph card, or prohibit registration, placing on the market or entry into service of a new tachograph, tachograph component, or tachograph card where the equipment concerned complies with Implementing Regulation (EU) 2016/799 as amended by this Regulation, if a manufacturer so requests.’

Article 3

This Regulation shall enter into force on the third day following that of its publication in the Official Journal of the European Union .
It shall apply from 21 August 2023.
However, from 25 May 2023, national authorities shall not refuse to grant EU type approval for a new type of tachograph, tachograph component, or tachograph card, or grant extension for an existing type of tachograph or tachograph component, or tachograph card, or prohibit registration, placing on the market or entry into service of a new tachograph, tachograph component, or tachograph card where the equipment concerned complies with Implementing Regulation (EU) 2016/799 as amended by Implementing Regulation (EU) 2021/1228 and this Regulation, if a manufacturer so requests.

ANNEX

ANNEX
In Annex IC to Implementing Regulation (EU) 2016/799, the following Appendix 17 is added:
‘Appendix 17
TRANSITIONAL PROVISIONS RELATED to THE USE OF OSNMA BY TACHOGRAPHS
1.   DEFINITIONS AND ACRONYMS
1.1.    Definitions
Service Declaration of Galileo Open Service Navigation Message Authentication (OSNMA) means the declaration of the European Commission that Galileo OSNMA enters its operational phase.
Transitional vehicle unit : Vehicle unit complying with the provisions of this Appendix.
Transitional vehicle units are constructed in accordance with the SIS ICD and the OSNMA receiver guidelines applicable to the OSNMA public test phase. They contain a GNSS receiver which is capable of using OSNMA available during its public test phase.
Transitional vehicle units are however unable to authenticate the navigation messages available after the Service Declaration of OSNMA, due to a necessary update of the cryptographic material in the vehicle unit. An appropriate software update needs to be applied, so that they can start to use OSNMA, and comply with all the requirements of Annex IC and its Appendixes 1 to 16. Before being updated, transitional vehicle units implement the OSNMA related functionalities as specified in this Appendix. Functionalities unrelated to OSNMA remain unchanged.
If the appropriate software update is applied, transitional vehicle units implement the SIS ICD and the OSNMA receiver guidelines applicable to the OSNMA operational phase, and comply with all the requirements of Annex IC and its Appendixes 1 to 16, using OSNMA available during the operational phase.
Transitional tachograph : tachograph including a transitional vehicle unit.
1.2.    Acronyms
ICD
Interface Control Document
OSNMA
Galileo Open Service Navigation Message Authentication
SIS
Signal in Space
VU
Vehicle Unit
2.   GENERAL CONSIDERATIONS RELATED TO OSNMA
In order to allow vehicles registered for the first time to be fitted with version 2 of second generation tachographs, starting from the requested introduction date as defined in point (ccc) of Section 1 of Annex I C to Implementing Regulation (EU) 2016/799, there is a need to type-approve, produce and commercialize vehicle units before the Service Declaration of OSNMA. For these vehicle units, referred to as transitional vehicle units, OSNMA-related requirements of Annex IC and its Appendixes 1 to 16 need to be adapted, so that they can be type approved and used in the field.
The provisions laid down in this Appendix define the specific requirements applicable to transitional vehicle units. They only apply to vehicle units with an internal GNSS receiver.
3.   REQUIREMENTS APPLICABLE TO THE GNSS RECEIVER OF TRANSITIONAL TACHOGRAPHS
TRA_001
Transitional vehicle units shall include a GNSS receiver capable of using OSNMA available during its public test phase.
TRA_002
Appendix 12 requirements apply to the GNSS receiver included in transitional vehicle units, with the following interpretations:
—
SIS ICD and OSNMA Receiver Guidelines referred to are the documents available for the public test phase:
—
Galileo Open Service Navigation Message Authentication (OSNMA) User ICD for the Test Phase, Issue 1.0, November 2021,
—
Galileo Open Service Navigation Message Authentication (OSNMA) Receiver Guidelines for the Test Phase, Issue 1.0, November 2021,
—
OSNMA is the service available during the public test phase,
—
SIS is the Signal In Space available during the public test phase.
TRA_003
The GNSS receiver included in transitional vehicle units shall be so designed that after an update of its software, applied through a vehicle unit software update, it fully complies with Annex 12 requirements, using OSNMA available during its operational phase.
4.   REQUIREMENTS APPLICABLE TO TRANSITIONAL VEHICLE UNITS
Transitional vehicle units may process the OSNMA signal available during its public test phase, but are not able to report the Navigation Messages Authentication Status from the SIS available during OSNMA operational phase, until an appropriate software update is applied. They therefore assume that the standard positions provided by the GNSS receiver are always authenticated.
The requirements of Annex IC and its Appendixes 1 to 16 apply, with the following interpretations.
TRA_004
Annex IC, 3.9.15 ‘Time conflict’ event, requirement 86, shall be understood as:
This event shall be triggered, while not in calibration mode , when the VU detects a discrepancy between the time of the vehicle unit’s time measurement function and the time originating from the standard positions transmitted by the GNSS receiver or the external GNSS facility. A “ time discrepancy” is detected if the time difference exceeds ± 3 seconds corresponding to the time accuracy set out in requirement 41a, the latter increased by the maximal time drift per day. This event shall be recorded together with the internal clock value of the recording equipment. The VU shall perform the check for triggering the “time conflict” event right before the VU automatically re-adjusts the VU internal clock, in accordance with requirement 211.
TRA_005
Annex IC, 3.9.18 “GNSS anomaly” event, requirement 88a, shall be understood as:
This event shall be triggered, while not in calibration mode,
when the GNSS receiver detects an attack
, as specified in Appendix 12. After a GNSS anomaly event has been triggered, the VU shall not generate other GNSS anomaly events for the next 10 minutes.
TRA_006
Annex IC, 3.12.5 Recording and storing in the data memory, Places and positions where daily work periods begin, end, and/or where 3 hours accumulated driving time is reached, requirement 110, shall be understood as:
Together with each place or position, the recording equipment shall record and store in its data memory:
—
the driver and/or co-driver card number and card issuing Member State,
—
the card generation,
—
the date and time of the entry,
—
the type of entry (begin, end or 3 hours accumulated driving time),
—
the related GNSS accuracy, date and time if applicable,
—
the vehicle odometer value,
—
a flag indicating that the position has been assumed as authenticated.
TRA_007
Annex IC, 3.12.17 Recording and storing in the data memory, Border crossings, requirement 133b, shall be understood as:
Together with countries and position, the recording equipment shall record and store in its data memory:
—
the driver and/or co-driver card number and card issuing Member State,
—
the card generation,
—
the related GNSS accuracy, date and time,
—
a flag indicating that the position has been assumed as authenticated,
—
the vehicle odometer value at the time of border crossing detection.
TRA_008
Annex IC, 3.12.18 Recording and storing in the data memory, Load/unload operations, requirement 133g, shall be understood as:
Together with the type of operation and position, the recording equipment shall record and store in its data memory:
—
the driver and/or co-driver card number and card issuing Member State,
—
the card generation,
—
the date and time of the load/unload operation,
—
the related GNSS accuracy, date and time if applicable,
—
a flag indicating that the position has been assumed as authenticated,
—
the vehicle odometer value.
TRA_009
Annex IC, 3.23 Time adjustment, requirement 211, shall be understood as:
The time setting of the VU internal clock shall be automatically re-adjusted, at variable time intervals. The next automatic time re-adjustment shall be triggered between 72h and 168h after the previous one, and after the VU can access to GNSS time through a valid
standard
position message in accordance with Appendix 12. Nevertheless, the time adjustment shall never be bigger than the accumulated maximal time drift per day, as calculated by the VU manufacturer in accordance with requirement 41b. If the difference between internal VU clock time and GNSS receiver time is bigger than the accumulated maximum time drift per day, then the time adjustment shall bring the VU internal clock as close as possible to the GNSS receiver time. The time setting may only be done if the time provided by the GNSS receiver is obtained using
standard
position messages as set out in Appendix 12. The time reference for the automatic time setting of the VU internal clock shall be the time provided in the standard position message.
TRA_010
Annex IC, 3.23 Time adjustment, requirement 212, shall be understood as:
The time adjustment function shall also allow for triggered adjustment of the current time, in calibration mode.
Workshops may adjust time:
—
either by writing a time value in the VU, using the WriteDataByIdentifier service in accordance with section 6.2 of Appendix 8,
—
or by requesting an alignment of the VU clock to the time provided by the GNSS receiver. This may only be done if the time provided by the GNSS receiver is obtained using standard position messages. In this latter case, the RoutineControl service shall be used in accordance with section 8 of Appendix 8.
TRA_011
Appendix 4, 2. Data blocks specification, first paragraph, seventh indent, shall be understood as:
When printed after the longitude and the latitude of a recorded position, or after the timestamp when the position was determined, the
pictogram indicates that this position has been assumed as authentic.
TRA_012
Appendix 8, 8.1 RoutineControl service (Time adjustment), Message description, requirement CPR_065a, shall be understood as:
The service RoutineControl (TimeAdjustment) provides the ability to trigger an alignment of the VU clock to the time provided by the GNSS receiver.
For the service RoutineControl (TimeAdjustment) execution the VU must be in CALIBRATION mode.
Precondition: it is ensured that the VU is able to receive
standard
position messages from the GNSS receiver.
As long the time adjustment is ongoing, the VU shall respond to the request RoutineControl, subfunction requestRoutineResults, with routineInfo = 0x78.
Note: the time adjustment may take some time. The diagnostic tester shall request the time adjustment status by using the sub-function requestRoutineResults.
TRA_013
In Appendix 12, 3 Sentences provided by the GNSS receiver, requirement GNS_4a:
Data contained in the AMC sentences provided by the GNSS receiver, if any,
shall not be used
by the vehicle unit, except for the following values of the Status:
J = jamming or O = other GNSS attack (by implemented consistency checks according to GNS_3a),
V = Void (authenticated position is not available for any other reason).
TRA_014
In Appendix 12, 3 Sentences provided by the GNSS receiver, requirement GNS_5:
Data contained in the ASA sentences provided by the GNSS receiver, if any,
shall not be used
by the vehicle unit.
TRA_015
In Appendix 12, 5.2 Vehicle Unit without an external GNSS facility, Transfer of information from the GNSS receiver to the VU, requirements GNS_34 and 36:
The VU processor
shall not
use information extracted from the AMC sentence, except for the following values of the Status:
J = jamming or O = other GNSS attack (by implemented consistency checks according to GNS_3a),
V = Void (authenticated position is not available for any other reason).
The VU processor
shall not
use information extracted from the ASA sentence.
TRA_016
Appendix 12, 6 Position data processing and recording by the VU, requirement GNS_39, shall be understood as:
Position data shall be stored in the VU, together with a flag indicating if the position has been assumed as authenticated. When position data need to be recorded in the VU, the following rule shall apply:
(a)
If the standard position is valid, the standard position and its accuracy shall be recorded in the VU and the flag shall be set to ‘authenticated’.
TRA_017
Appendix 12, 6 Position data processing and recording by the VU, requirement GNS_40, shall be understood as:
When the value of the Status in a received AMC sentence is set to
‘J’ or ‘O’
in accordance with requirement GNS_4a, the VU shall generate and record a GNSS anomaly event, as defined in requirement 88a of Annex IC and Appendix 1 (EventFaultType), The vehicle unit may perform additional checks before storing a GNSS anomaly event following the reception of a ‘J’ or ‘O’ setting.
TRA_018
Appendix 12, 8 Vehicle motion conflict, requirement GNS_42, Trigger condition 2, the first and second indents after the formula shall be understood as:
—
GnssDistance is the distance between the current position of the vehicle and the previous one, both obtained from valid
standard
position messages, without considering the height,
—
OdometerDifference is the difference between the current odometer value and the odometer value corresponding to the previous valid
standard
position message.
TRA_019
Appendix 14, 5.4.5 DSRC Protocol requirements for RTMElements of RtmData, actions performed and definitions, requirement DSC_41, Table 14.3, second cell in the RTM20 row, shall be understood as:
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM20.
The VU shall set the value of RTM20 to the time at which the latest
standard
vehicle position was available from the GNSS receiver.
If no
standard
vehicle position was available ever from the GNSS receiver the VU shall set the value of RTM20 to 0.
TRA_020
The manufacturer of a type approved transitional vehicle unit shall inform the Commission of its software versions. The Commission shall publish these software versions on a publicly available website.
5.   SPECIFIC PROVISIONS FOR TYPE APPROVAL AND USE OF TRANSITIONAL TACHOGRAPHS
TRA_021
Transitional vehicle units shall be type approved according to the requirements of Annex IC and its Annexes 1 to 16, supplemented by the provisions of this Appendix.
TRA_022
Type approval certificates of transitional vehicle units and transitional tachographs may only be requested until 31 December 2023 or the Service Declaration date of OSNMA, whichever is the latest.
TRA_023
Transitional vehicle units may be fitted in vehicles registered for the first time only until 31 May 2024 or 5 months after the Service Declaration date of OSNMA, whichever is the latest.
’

Schedules & Appendices

Cite this act