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)

Command	Reference
Select	Appendix 2 chapter 3.5.1
Read Binary	Appendix 2 chapter 3.5.2
Get Challenge	Appendix 2 chapter 3.5.4
PSO: Verify Certificate	Appendix 2 chapter 3.5.7
External Authenticate	Appendix 2 chapter 3.5.9
General Authenticate	Appendix 2 chapter 3.5.10
MSE:SET	Appendix 2 chapter 3.5.11

4.3.   Coupling, mutual authentication and session key agreement of the external GNSS facility with vehicle unit

The coupling, mutual authentication and session key agreement of the external GNSS facility with the vehicle unit is described in Appendix 11. Common security mechanisms, Chapter 11.

4.4.   Error Handling

This section describes how potential error conditions by the external GNSS facility are addressed and recorded in the VU.

4.4.1   Communication error with the external GNSS facility

• GNS_28A communication error with the external GNSS facility event shall be recorded in the VU, as defined in requirement 82 of Annex IC and Appendix 1 (EventFaultType). 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.

4.4.2   Breach of the physical integrity of the external GNSS facility

• GNS_29If the external GNSS facility has been breached, the GNSS Secure Transceiver shall ensure that cryptographic material is unavailable. As described in GNS_25 and GNS_26, the VU shall detect tampering if the Response has status ‘6690’. The VU shall then generate and record a security breach attempt event as defined in requirement 85 of Annex IC and Appendix 1 (EventFaultType for tamper detection of GNSS). Alternately, the external GNSS facility may respond to VU requests without secure messaging and with status ‘6A88’.

4.4.3   Absence of position information from GNSS receiver

• GNS_30If the GNSS Secure Transceiver does not receive data from the GNSS receiver, 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 absence of position information from GNSS receiver event, as defined in requirement 81 of Annex IC and Appendix 1 (EventFaultType).

4.4.4   External GNSS facility certificate expired

- GNS_31If the VU detects that the EGF certificate used for mutual authentication is not valid any longer, the VU shall generate and record a security breach attempt event as defined in requirement 85 of Annex IC and Appendix 1 (EventFaultType for external GNSS facility certificate expired). The VU shall still use the received GNSS position data.

Figure 6

Schema of the external GNSS facility

Image omitted; see official source

5.1.   Configuration

In this configuration, the GNSS receiver is inside the Vehicle Unit as described in Figure 1.

• GNS_32For transmitting position, DOP and satellites data, the GNSS receiver shall act as a talker and transmit NMEA or NMEA-like sentences to the VU processor, which shall act as a listener with a frequency of 1/10 Hz or faster for the pre-defined set of sentences, which shall include at least the RMC, GSA, AMC and ASA sentences. Alternatively, the VU processor and the internal GNSS receiver may use other data formats to exchange the data contained in the NMEA or NMEA-like sentences specified in GNS_4, GNS_4a and GNS_5.

• GNS_33An external GNSS antenna installed on the vehicle or an internal GNSS antenna shall be connected to the VU.

5.2.   Transfer of information from the GNSS receiver to the VU

• GNS_34 The VU processor checks the received data extracting the information (e.g., latitude, longitude, time) from the RMC NMEA sentence and the AMC sentence.

• GNS_35 The RMC NMEA sentence includes the information if the non-authenticated position is valid. If the non-authenticated position is not valid, the position data is not available and it cannot be used to record the position of the vehicle. If the non-authenticated position is valid, the VU processor also extracts the values of HDOP from GSA NMEA.

• GNS_36 The VU processor also extracts the information (e.g. latitude, longitude, time) from the AMC sentence. The AMC sentence includes the information if the non-authenticated position is valid according to GNS_4a. If the non-authenticated position is valid, the VU processor also extracts the values of HDOP from ASA sentences.

5.3.   Transfer of information from the VU to the GNSS receiver

• GNS_37 The VU processor provides to the GNSS receiver the VU RTC time and the maximal difference between true time and the VU RTC time, in accordance with GNS_3f and GNS_3g.

5.4.   Error handling

• 5.4.1 Absence of position information from GNSS receiver GNS_38 The VU shall generate and record an absence of position information from GNSS receiver event, as defined in requirement 81 of Annex IC and Appendix 1 (EventFaultType).

This section is valid both for the configuration of the Smart Tachograph with or without an external GNSS facility.

• GNS_39 Position data shall be stored in the VU, together with a flag indicating if the position has been authenticated. When position data need to be recorded in the VU, the following rules shall apply:

• (a) If both authenticated and standard positions are valid and consistent, the standard position and its accuracy shall be recorded in the VU and the flag shall be set to ‘authenticated’.

• (b) If both authenticated and standard positions are valid but not consistent, the VU shall store the authenticated position and its accuracy, and the flag shall be set to ‘authenticated’.

• (c) If the authenticated position is valid and the standard position is not valid, the VU shall record the authenticated position and its accuracy, and the flag shall be set to ‘authenticated’.

• (d) If the standard position is valid and the authenticated position is not valid, the VU shall record the standard position and its accuracy, and the flag shall be set to ‘not authenticated’.

Authenticated and standard positions are considered as consistent, as shown in Figure 7, when the horizontal authenticated position can be found in a circle centered at the horizontal standard position, which radius results of rounding up to the nearest upper whole number the value of R_H calculated according to the following formula:

R_H = 1.74 • σUERE • HDOP

where:

• — R_H is the relative radius of a circle around the estimated horizontal position, in meters. It is an indicator that is used to check consistency between standard and authenticated positions.

- — σUERE is the standard deviation for the user equivalent range error (UERE), which models all measurement errors for the target application, including urban environments. A constant value of σUERE = 10 meters shall be used.

• — HDOP is the horizontal dilution of precision calculated by the GNSS receiver.

• — σUERE . HDOP is the estimation of the root mean squared error in the horizontal domain.

Image omitted; see official source

Figure 7

Consistent Authenticated and Standard (non-authenticated) positions

- GNS_40 When the value of the Status in a received AMC sentence is set to ‘J’ or ‘O’ or ‘F’ 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.

• GNS_41 If the VU detects a discrepancy between the time of the vehicle unit’s time measurement function and the time originating from the GNSS signals, it shall generate and record a time conflict event, as defined in requirement 86 of Annex IC and Appendix 1 (EventFaultType).

• GNS_42 The VU shall trigger and record a Vehicle Motion Conflict event in accordance with requirement 84 of Annex IC, in case motion information calculated from the motion sensor is contradicted by motion information calculated from the internal GNSS receiver, from the external GNSS facility, or by other independent motion source(s) as set out in requirement 26 of Annex IC.

The vehicle motion conflict event shall be triggered upon occurrence of one of the following trigger conditions:

Trigger condition 1:

The trimmed mean value of the speed differences between these sources shall be used, when the position information from the GNSS receiver is available and when the ignition of the vehicle is switched on, as specified below:

• — every 10 seconds maximum, the absolute value of the difference between the vehicle speed estimated from the GNSS and the one estimated from the motion sensor shall be computed.

- — all the computed values in a time window containing the last 5 minutes of vehicle movement shall be used to compute the trimmed mean value.

• — the trimmed mean value shall be computed as the average of 80% of the remaining values, after having eliminated the highest ones in absolute values.

The Vehicle Motion Conflict event shall be triggered if the trimmed mean value is above 10 km/h for five uninterrupted minutes of vehicle movement. (Note: the use of the trimmed mean on the last 5 minutes is applied to mitigate the risk of measurement outliers and transient values).

For the trimmed mean computation, the vehicle shall be considered as moving if at least one vehicle speed value estimated either from motion sensor or from GNSS receiver is not equal to zero.

Trigger condition 2:

The vehicle motion conflict event shall also be triggered if the following condition is true:

GnssDistance>[OdometerDifference×OdometerToleranceFactor+Minimum(SlipDistanceUpperlimit;(OdometerDifference×SlipFactor))+GnssTolerance+FerryTrainDistance]

where:

• — GnssDistance is the distance between the current position of the vehicle and the previous one, both obtained from valid authenticated position messages, without considering the height,

• — OdometerDifference is the difference between the current odometer value and the odometer value corresponding to the previous valid authenticated position message,

• — OdometerToleranceFactor is equal to 1.1 (worst case tolerance factor for all measurement tolerances of the vehicle odometer),

• — GnssTolerance is equal to 1 km (worst case GNSS tolerance),

• — Minimum (SlipDistanceUpperLimit; (OdometerDifference * SlipFactor)) is the minimum value between: — SlipDistanceUpperLimit which is equal to 10 km (upper limit of the slip distance caused by slipping effects during braking), — and OdometerDifference * SlipFactor, in which SlipFactor is equal to 0.2 (maximal influence of slipping effects during breaking),

- — FerryTrainDistance is computed as: FerryTrainDistance =200km/h * tFerryTrain, where tFerryTrain is the sum of the durations in hours of the ferry/train crossings in the considered time interval. The duration of a ferry/train crossings is defined as the time difference between its end flag and its beginning flag.

The preceding verifications shall be performed every 15 minutes if the necessary position data are available, otherwise as soon as the position data are available.

For this trigger condition:

• — date and time of beginning of event shall be equal to the date and time when the previous position message was received,

• — date and time of end of event shall be equal to the date and time when the checked condition becomes false again.

Trigger condition 3:

The vehicle unit encounters a discrepancy consisting of the motion sensor not detecting any movement and the independent motion source detecting movement for a specific period. The conditions to record a discrepancy as well as the period of detection of the discrepancy shall be set out by the vehicle unit manufacturer, although the discrepancy shall be detected in no more than three hours.

Appendix 13

ITS INTERFACE

TABLE OF CONTENTS	TABLE OF CONTENTS
1.	INTRODUCTION
1.1.	Scope
1.2.	Acronyms and definitions
2.	REFERENCED STANDARDS
3.	ITS INTERFACE WORKING PRINCIPLES
3.1.	Communication technology
3.2.	Available services
3.3.	Access through the ITS interface
3.4.	Data available and need of driver consent
4.	LIST OF DATA AVAILABLE THROUGH THE ITS INTERFACE AND PERSONAL/NOT PERSONAL CLASSIFICATION

1.1.   Scope

- ITS_01 This Appendix specifies the basics of the communication through the tachograph interface with Intelligent Transport Systems (ITS), requested in Articles 10 and 11 of Regulation (EU) No 165/2014.

• ITS_02 The ITS interface shall allow external devices to obtain data from the tachograph, to use tachograph services and also to provide data to the tachograph.

Other tachograph interfaces (e.g. CAN bus) may also be used for that purpose.

This Appendix does not specify:

- — how data provided through the ITS interface are collected and managed within the tachograph,

• — the form of presentation of collected data to applications hosted on the external device,

• — the ITS security specification in addition to what provides Bluetooth®,

- — the Bluetooth® protocols used by the ITS interface.

1.2.   Acronyms and definitions

The following acronyms and definitions specific to this Appendix are used:

• GNSS Global Navigation Satellite System

• ITS Intelligent Transport System

• OSI Open Systems Interconnection

• VU Vehicle Unit

• ITS unit an external device or application using the VU ITS interface.

2. REFERENCED STANDARDS

• ITS_03 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 referred to. In the event of any contradiction the clauses of this Appendix shall take precedence.

Standards referenced to in this Appendix are:

• — Bluetooth® – Core Version 5.0.

• — ISO 16844-7: Road vehicles -Tachograph systems - Part 7: Parameters

• — ISO/IEC 7498-1:1994 Information technology - Open Systems Interconnection - Basic Reference Model, the Basic Model

• ITS_04 The VU shall be responsible to keep updated and maintain tachograph data transmitted through the ITS interface, without any involvement of the ITS interface.

3.1.   Communication technology

- ITS_05 Communication through the ITS interface shall be performed via Bluetooth® interface and be compatible to Bluetooth® Low Energy according to Bluetooth version 5.0 or newer.

• ITS_06 The communication between the VU and the ITS unit shall be established after a Bluetooth® pairing process has been completed.

- ITS_07 A secure and encrypted communication shall be established between the VU and the ITS unit, in accordance with the Bluetooth® specification mechanisms. This Appendix does not specify encryption or other security mechanisms in addition to what Bluetooth® provides.

- ITS_08 Bluetooth® is using a server/client model to control the transmission of data between devices, in which the VU shall be the server and the ITS unit shall be the client.

3.2.   Available services

- ITS_09 The data to be transmitted through the ITS interface in accordance with point 4 shall be made available through the services specified in Appendix 7 and Appendix 8. In addition, the VU shall make available to the ITS unit the services that are necessary for manual data entry in accordance with requirement 61 of Annex IC, and optionally, for other data entries in real time.

Image omitted; see official source Figure 1

partition of the communication through the ITS interface according to the OSI Model layers

• ITS_10 When the download interface is used via the front connector, the VU shall not provide the download services specified in Appendix 7 via ITS Bluetooth® connection.

• ITS_11 When the calibration interface is used via the front connector, the VU shall not provide the calibration services specified in Appendix 8 via ITS Bluetooth® connection.

3.3.   Access through the ITS interface

• ITS_12 The ITS interface shall provide a wireless access to all services specified in Appendix 7 and Appendix 8, in replacement of a cable connection to the front connector for calibration and download specified in Appendix 6.

• ITS_13 The VU shall make the ITS interface available to the user according to the combination of valid tachograph cards inserted in the VU, as specified in Table 1.

Table 1

Availability of ITS interface depending on the type of card inserted in the tachograph

Availability of the ITS interface	Availability of the ITS interface	Driver slot	Driver slot	Driver slot	Driver slot	Driver slot
		No card	Driver card	Control card	Workshop card	Company card
Co-driver slot	No card	Not available	Available	Available	Available	Available
Co-driver slot	Driver card	Available	Available	Available	Available	Available
Co-driver slot	Control card	Available	Available	Available	Not available	Not available
Co-driver slot	Workshop card	Available	Available	Not available	Available	Not available
Co-driver slot	Company card	Available	Available	Not available	Not available	Available

• ITS_14 After a successful ITS Bluetooth® pairing, the VU shall assign the ITS Bluetooth® connection to the specific inserted tachograph card according to Table 2:

Table 2

Assignment of the ITS connection depending on the type of card inserted in the tachograph

Assignment of the ITS Bluetooth® connection	Assignment of the ITS Bluetooth® connection	Driver slot	Driver slot	Driver slot	Driver slot	Driver slot
		No card	Driver card	Control card	Workshop card	Company card
Co-driver slot	No card	Not available	Driver card	Control card	Workshop card	Company card
Co-driver slot	Driver card	Driver card	Driver card [^E0022]	Control card	Workshop card	Company card
Co-driver slot	Control card	Control card	Control card	Control card [^E0021]	Not available	Not available
Co-driver slot	Workshop card	Workshop card	Workshop card	Not available	Workshop card [^E0021]	Not available
Co-driver slot	Company card	Company card	Company card	Not available	Not available	Company card [^E0021]

[^E0021]: (^*1)

The ITS Bluetooth® connection shall be assigned to the tachograph card in the driver slot of the VU.

The user shall select the card to which the ITS Bluetooth® connection shall be assigned (inserted in the driver or in the co-driver slot).

• ITS_15 If a tachograph card is withdrawn, then the VU shall terminate the ITS Bluetooth® connection which is assigned to this card.

• ITS_16 The VU shall support the ITS connection to at least one ITS unit and may support connections to multiple ITS units at the same time.

• ITS_17 The access rights to the data and services available via the ITS interface shall comply with requirements 12 and 13 of Annex IC, in addition to the driver consent specified in section 3.4 of this Appendix.

3.4.   Data available and need of driver consent

• ITS_18 All tachograph data available via the services referred to in point 3.3 shall be classified as either personal or not personal for the driver, co-driver or both.

• ITS_19 At least the list of data classified as mandatory in section 4 shall be made available through the ITS interface.

• ITS_20 The data in section 4 that are classified as ‘personal’ shall only be accessible upon driver consent, accepting therefore that the personal data can leave the vehicle network, except in the case set out in requirement ITS_25, for which the driver consent is not needed.

• ITS_21 Data additional to those gathered in point 4 and considered as mandatory may be made available through the ITS interface. Additional data which are not included in point 4 shall be classified as ‘personal’ or not ‘personal’ by the VU manufacturer, being the driver consent requested for those data that have been classified as personal, except in the case set out in requirement ITS_25, for which the driver consent is not needed.

• ITS_22 Upon insertion of a driver card which is unknown to the vehicle unit, the cardholder shall be prompted by the tachograph to enter the consent for transmission of personal data output through the ITS interface, in accordance with requirement 61 of Annex IC.

• ITS_23 The consent status (enabled/disabled) shall be recorded in the data memory of the vehicle unit.

• ITS_24 In case of multiple drivers, only the personal data related to the drivers who gave their consent shall be accessible through the ITS interface. For instance, in a crew situation, if only the driver has given his/her consent, personal data related to the co-driver shall not be accessible.

• ITS_25 When the VU is in control, company or calibration modes, the access rights through the ITS interface shall be managed according to requirements 12 and 13 of Annex IC, hence the driver consent not being needed.

Data name	Data format	Source	Data classification (personal/ not personal)	Data classification (personal/ not personal)	Consent for the availability of the data	Availability
Data name	Data format	Source	driver	co-driver	Consent for the availability of the data	Availability
VehicleIdentificationNumber	Appendix 8	VU	not personal	not personal	no need of consent	mandatory
CalibrationDate	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
TachographVehicleSpeed	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver1WorkingState	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver2WorkingState	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
DriveRecognize	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
Driver1TimeRelatedStates	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver2TimeRelatedStates	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
DriverCardDriver1	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
DriverCardDriver2	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
OverSpeed	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
TimeDate	Appendix 8	VU	not personal	not personal	no need of consent	mandatory
HighResolutionTotalVehicleDistance	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
HighResolutionTripDistance	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
ServiceComponentIdentification	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
ServiceDelayCalendarTimeBased	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
Driver1Identification	ISO 16844-7	Driver Card	personal	N/A	driver consent	mandatory
Driver2Identification	ISO 16844-7	Driver Card	N/A	personal	co-driver consent	mandatory
NextCalibrationDate	Appendix 8	VU	not personal	not personal	no need of consent	mandatory
Driver1ContinuousDrivingTime	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver2ContinuousDrivingTime	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
Driver1CumulativeBreakTime	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver2CumulativeBreakTime	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
Driver1CurrentDurationOfSelectedActivity	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver2CurrentDurationOfSelectedActivity	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
SpeedAuthorised	Appendix 8	VU	not personal	not personal	no need of consent	mandatory
TachographCardSlot1	ISO 16844-7	VU	not personal	N/A	no need of consent	mandatory
TachographCardSlot2	ISO 16844-7	VU	N/A	not personal	no need of consent	mandatory
Driver1Name	ISO 16844-7	Driver Card	personal	N/A	driver consent	mandatory
Driver2Name	ISO 16844-7	Driver Card	N/A	personal	co-driver consent	mandatory
OutOfScopeCondition	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
ModeOfOperation	ISO 16844-7	VU	not personal	not personal	no need of consent	mandatory
Driver1CumulatedDrivingTimePreviousAndCurrentWeek	ISO 16844-7	VU	personal	N/A	driver consent	mandatory
Driver2CumulatedDrivingTimePreviousAndCurrentWeek	ISO 16844-7	VU	N/A	personal	co-driver consent	mandatory
EngineSpeed	ISO 16844-7	VU	personal	N/A	driver consent	optional
RegisteringMemberState	Appendix 8	VU	not personal	not personal	no need of consent	mandatory
VehicleRegistrationNumber	Appendix 8	VU	not personal	not personal	no need of consent	mandatory
Driver1EndOfLastDailyRestPeriod	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2EndOfLastDailyRestPeriod	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1EndOfLastWeeklyRestPeriod	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2EndOfLastWeeklyRestPeriod	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1EndOfSecondLastWeeklyRestPeriod	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2EndOfSecondLastWeeklyRestPeriod	ISO 16844-7	VU	N/A	Personal	co-driver consent	optional
Driver1TimeLastLoadUnloadOperation	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2TimeLastLoadUnloadOperation	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1CurrentDailyDrivingTime	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2CurrentDailyDrivingTime	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1CurrentWeeklyDrivingTime	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2CurrentWeeklyDrivingTime	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1TimeLeftUntilNewDailyRestPeriod	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2TimeLeftUntilNewDailyRestPeriod	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1CardExpiryDate	ISO 16844-7	Driver Card	personal	N/A	driver consent	optional
Driver2CardExpiryDate	ISO 16844-7	Driver Card	N/A	personal	co-driver consent	optional
Driver1CardNextMandatoryDownloadDate	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2CardNextMandatoryDownloadDate	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
TachographNextMandatoryDownloadDate	ISO 16844-7	VU	not personal	not personal	no need of consent	optional
Driver1TimeLeftUntilNewWeeklyRestPeriod	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2TimeLeftUntilNewWeeklyRestPeriod	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1NumberOfTimes9hDailyDrivingTimesExceeded	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2NumberOfTimes9hDailyDrivingTimesExceeded	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1CumulativeUninterruptedRestTime	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2CumulativeUninterruptedRestTime	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1MinimumDailyRest	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2MinimumDailyRest	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1MinimumWeeklyRest	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2MinimumWeeklyRest	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1MaximumDailyPeriod	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2MaximumDailyPeriod	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1MaximumDailyDrivingTime	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2MaximumDailyDrivingTime	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1NumberOfUsedReducedDailyRestPeriods	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2NumberOfUsedReducedDailyRestPeriods	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
Driver1RemainingCurrentDrivingTime	ISO 16844-7	VU	personal	N/A	driver consent	optional
Driver2RemainingCurrentDrivingTime	ISO 16844-7	VU	N/A	personal	co-driver consent	optional
VehiclePosition	Appendix 8	VU	personal	personal	driver and co-driver consent	mandatory
ByDefaultLoadType	Appendix 8	VU	personal	personal	driver and co-driver consent	mandatory

Appendix 14

REMOTE COMMUNICATION FUNCTION

TABLE OF CONTENTS	TABLE OF CONTENTS
1.	INTRODUCTION
2.	SCOPE
3.	ACRONYMS, DEFINITIONS AND NOTATIONS
4.	OPERATIONAL SCENARIOS
4.1	Overview
4.1.1	Preconditions to data transfer via 5.8 GHz DSRC interface
4.1.2	Profile 1a: via a hand aimed or temporary roadside mounted and aimed Remote Early Detection Communication Reader
4.1.3	Profile 1b: via a vehicle mounted and directed Remote Early Detection Communication Reader (REDCR)
4.2	Security/Integrity
5.	REMOTE COMMUNICATION DESIGN AND PROTOCOLS
5.1	Design
5.2	Workflow
5.2.1	Operations
5.2.2	Interpretation of the Data received via the DSRC communication
5.3	DSRC Physical interface parameters for remote communication
5.3.1	Location constraints
5.3.2	Downlink and uplink parameters
5.3.3	Antenna design
5.4	DSRC Protocol requirements for RTM
5.4.1	Overview
5.4.2	Commands
5.4.3	Interrogation command sequence
5.4.4	Data structures
5.4.5	Elements of RtmData, actions performed and definitions
5.4.6	Data transfer mechanism
5.4.7	Detailed DSRC transaction description
5.4.8	DSRC Test transaction description
5.5	Reserved for future use
5.6	Data transfer between the DSRC-VU and VU
5.6.1	Physical Connection and interfaces
5.6.2	Application Protocol
5.7	Error handling
5.7.1	Recording and communication of the Data in the DSRC-VU
5.7.2	Wireless Communication errors
6.	COMMISSIONING AND PERIODIC INSPECTION TESTS FOR THE REMOTE COMMUNICATION FUNCTION
6.1	General
6.2	ECHO
6.3	Tests to validate the secure data content

This 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).

• DSC_1Regulation (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.

• It 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.

• DSC_2 The 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)}.

• DSC_3 The 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)).

• DSC_4 The Data shall be secured to ensure integrity.

• DSC_5Access 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.

• DSC_6 The 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.

• DSC_7Data 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.

• DSC_8 The Data shall contain a timestamp for the time of its last update.

• DSC_9The 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.

• DSC_10The same architecture and equipment shall be capable be used to acquire other data concepts (such as weigh–on-board) using the architecture specified herein.

• DSC_11For 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.

The 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.

Regulation (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.

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.

This Appendix specifies:

• — The communications equipment, procedures and protocols to be used for the Communication

• — The Standards and Regulations to which the radio equipment shall comply

• — The presentation of the Data to the Communication equipment

• — The enquiry and download procedures and sequence of operations

• — The Data to be transferred

• — Potential interpretation of the Data transferred across the Communication

• — The provisions for security data relating to the Communication

• — The availability of the Data to the competent control authorities

• — How the Remote early detection communication reader can request different freight and fleet data concepts

For clarification, this Appendix does not specify:

• — the 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)

• — the 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

• — Data security provisions (such as encryption) concerning the content of the Data (which shall be specified within Appendix 11 Common Security Mechanisms).

• — detail of any data concepts other than RTM which may be obtained using the same architecture and equipment

• — detail 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).

The following acronyms and definitions specific to this Appendix are used in this appendix:

• the Antenna electrical 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

• the Communication exchange of information/data between a DSRC-REDCR and a DSRC-VU according to section 5 in a master-slave relationship to obtain the Data.

• the Data secured 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

• Regulation (EC) No 165/2014 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

• AID Application Identifier

• BLE Bluetooth Low Energy

• BST Beacon Service Table

• CIWD Card insertion while driving

- CRC cyclic redundancy check

- DSC (n) identifier of a requirement for a specific DSRC appendix

• DSRC Dedicated Short Range Communication

• DSRC-REDCR DSRC — Remote Early Detection Communication Reader.

• DSRC-VU DSRC — Vehicle Unit. This is the ‘remote early detection facility’ defined in Annex 1C.

• DWVC Driving without valid card

• EID Element Identifier

- LLC Logical Link Control

• LPDU LLC Protocol Data Unit

• OWS Onboard Weighing System

• PDU Protocol Data Unit

• REDCR Remote early detection communication reader. This is the ‘remote early detection communication reader equipment’ defined in Annex 1C.

• RTM Remote Tachograph Monitoring

• SM-REDCR Security Module-Remote early detection communication reader

• TARV Telematics Applications for Regulated Vehicles (ISO 15638 series of Standards)

• VU Vehicle Unit

• VUPM Vehicle Unit Payload Memory

• VUSM Vehicle Unit Security Module

• VST Vehicle Service Table

• WIM Weigh in motion

• WOB Weigh on board

The 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.

Regulations and standards referenced in this Appendix are:

• [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.

- [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).

• [3] ERC 70-03 CEPT: ECC Recommendation 70-03: Relating to the Use of Short Range Devices (SRD)

• [4] ISO 15638 Intelligent transport systems — Framework for cooperative telematics applications for regulated commercial freight vehicles (TARV).

• [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).

• [6] EN 12253 Road transport and traffic telematics — Dedicated short-range communication — Physical layer using microwave at 5.8 GHz.

- [7] EN 12795 Road transport and traffic telematics — Dedicated short-range communication — Data link layer: medium access and logical link control.

• [8] EN 12834 Road transport and traffic telematics — Dedicated short-range communication — Application layer.

• [9] EN 13372 Road transport and traffic telematics — Dedicated short-range communication — Profiles for RTTT applications

• [10] ISO 14906 Electronic fee collection — Application interface definition for dedicated short- range communication

4.1   Overview

Regulation (EU) No 165/2014 provides specific and controlled scenarios within which the Communication is to be used.

The scenarios supported are:

‘Communication Profile 1: Roadside inspection using a short range wireless communication Remote Early Detection Communication Reader instigating a physical roadside inspection (master-:-slave)

Reader Profile 1a: via a hand aimed or temporary roadside mounted and aimed Remote Early Detection Communication

Reader Profile 1b: via a vehicle mounted and directed Remote Early Detection Communication Reader’.

4.1.1   Preconditions to data transfer via 5,8 GHz DSRC interface

NOTE: In order to understand the context of the preconditions the reader is referred to Figure 14.3 below.

4.1.1.1   Data held in VU

• DSC_12The 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.

4.1.1.2   Data provided to DSRC-VU Facility

• DSC_13The 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.

• DSC_14The 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.

4.1.1.3   Content of the Data

• DSC_15The 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).

4.1.1.4   Data presentation

• DSC_16 The 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.

4.1.1.5   Security data

• DSC_17Security data (DSRCSecurityData), 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, for temporary storage in the DSRC-VU as the current version of DSRCSecurityData, in the form defined in section 5.4.4 of this Appendix.

4.1.1.6   VUPM data available for transfer across the DSRC interface

• DSC_18The 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.

General overview of communication Profile 1

This 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.

4.1.2   Profile 1a: via a hand aimed or temporary roadside mounted and aimed Remote Early Detection Communication Reader

In 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).

Figure 14.1

Roadside interrogation using 5,8 GHz DSRC

Image omitted; see official source

4.1.3   Profile 1b: via a vehicle mounted and directed Remote Early Detection Communication Reader (REDCR)

In 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).

Figure 14.2

Vehicle based interrogation using 5,8 GHz DSRC

Image omitted; see official source

4.2   Security/Integrity

To 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.

5.1   Design

The design of the remote communication function in the Smart Tachograph is shown as described in Figure 14.3.

Figure 14.3

Design of the remote communication function

Image omitted; see official source

• DSC_19The following functions are located in the VU:

• — Security 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.

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

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

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

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

- — If 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.

• — VU 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).

- — DSRC-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.

- — Security 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.

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

- — The 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.

• — 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.

• DSC_20The 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.

• DSC_21The 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.

- DSC_22

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.

Figure 14.4

Example of positioning of the 5,8 GHz DSRC antenna in the windshield of regulated vehicles

Image omitted; see official source

The 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.

A 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.

• DSC_23The 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.

• DSC_24The 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).

- DSC_25However, 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.

5.2   Workflow

5.2.1   Operations

The workflow of operations is represented in Figure 14.5.

Figure 14.5

Workflow for remote communication function

Image omitted; see official source

The steps are described below:

- a. 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.

• b. On every occasion that the Data is updated, the timestamp defined in the security data concept shall be updated.

• c. The VUSM function secures the data in accordance with the procedures determined in Appendix 11.

• d. 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.

• e. 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.

• f. 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.

• g. The data is analyzed by the REDCR equipment and provided to the agent of the competent control authority.

• h. 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.

5.2.2   Interpretation of the Data received via the DSRC communication

• DSC_26Data 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.

5.3   DSRC Physical interface parameters for remote communication

5.3.1   Location constraints

• DSC_27The 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.

5.3.2   Downlink and uplink parameters

• DSC_28The 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.

• DSC_29Further, 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.

Namely:

Table 14.1

Downlink parameters

Item No	Parameter	Value(s)	Remark
D1	Downlink Carrier Frequencies	There are four alternatives which may be used by an REDCR: 5,7975 GHz 5,8025 GHz 5,8075 GHz 5,8125 GHz	Within ERC 70-03. Carrier Frequencies may be selected by the implementer of the roadside system and need not be known in the DSRC-VU (Consistent with EN 12253, EN 13372)
D1a [^E0023]	Tolerance of Carrier Frequencies	within ± 5 ppm	(Consistent with EN 12253)
D2 [^E0023]	RSU (REDCR) Transmitter Spectrum Mask	Within ERC 70-03. REDCR shall be according to Class B,C as defined in EN 12253. No other specific requirement within this Annex	Parameter used for controlling interference between interrogators in proximity (as defined in EN 12253 and EN 13372).
D3	OBU(DSRC-VU) Minimum Frequency Range	5,795 — 5,815 GHz	(Consistent with EN 12253)
D4 [^E0023]	Maximum E.I.R.P.	Within ERC 70-03 (unlicensed) and within National Regulation Maximum + 33 dBm	(Consistent with EN 12253)
D4a	Angular E.I.R.P. mask	According to declared and published specification of interrogator designer	(Consistent with EN 12253)
D5	Polarisation	Left hand circular	(Consistent with EN 12253)
D5a	Cross-Polarisation	XPD: In bore sight: (REDCR) RSU t ≥ 15 dB (DSRC-VU) OBU r ≥ 10 dB At -3 dB area: (REDCR) RSU t ≥ 10 dB (DSRC-VU) OBU r ≥ 6 dB	(Consistent with EN 12253)
D6 [^E0023]	Modulation	Two level amplitude modulation.	(Consistent with EN 12253)
D6a [^E0023]	Modulation Index	0,5 ... 0,9	(Consistent with EN 12253)
D6b	Eye Pattern	≥ 90 % (time) / ≥ 85 % (amplitude)
D7 [^E0023]	Data Coding	FM0 ‘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.	(Consistent with EN 12253)
D8 [^E0023]	Bit rate	500 kBit/s	(Consistent with EN 12253)
D8a	Tolerance of Bit Clock	better than ± 100 ppm	(Consistent with EN 12253)
D9 [^E0023]	Bit Error Rate (B.E.R.) for communication	≤ 10– 6 when incident power at OBU (DSRC-VU) is in the range given by [D11a to D11b].	(Consistent with EN 12253)
D10	Wake-up trigger for OBU (DSRC-VU)	OBU (DSRC-VU) shall wake up on receiving any frame with 11 or more octets (including preamble)	No special wake-up pattern is necessary. DSRC-VU may wake up on receiving a frame with less than 11 octets (Consistent with EN 12253)
D10a	Maximum Start Time	≤ 5 ms	(Consistent with EN 12253)
D11	Communication zone	Spatial region within which a B.E.R. according to D9a is achieved	(Consistent with EN 12253)
D11a [^E0023]	Power Limit for communication (upper).	– 24dBm	(Consistent with EN 12253)
D11b [^E0023]	Power Limit for communication (lower).	Incident power: – 43 dBm (boresight) – 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))	(Consistent with EN 12253) Extended requirement for horizontal angles up to ±45°, due to the use cases defined in this annex.
D12 [^E0023]	Cut-off power level of (DSRC-VU)	– 60 dBm	(Consistent with EN 12253)
D13	Preamble	Preamble is mandatory.	(Consistent with EN 12253)
D13a	Preamble Length and Pattern	16 bits ± 1 bit of FM0 coded ‘1’ bits	(Consistent with EN 12253)
D13b	Preamble Wave form	An alternating sequence of low level and high level with pulse duration of 2 μs. The tolerance is given byD8a	(Consistent with EN 12253)
D13c	Trailing Bits	The 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.	(Consistent with EN 12253)

– Downlink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1.

Table 14.2

Uplink parameters

Item No.	Parameter	Value(s)	Remark
U1 [^E0024]	Sub-carrier Frequencies	A OBU (DSRC-VU) shall support 1,5 MHz and 2,0 MHz An RSU (REDCR) shall support 1,5 MHz or 2,0 MHz or both. U1-0: 1,5 MHz U1-1: 2,0 MHz	Selection of sub-carrier frequency (1,5 MHz or 2,0 MHz) depends on the EN 13372 profile selected.
U1a [^E0024]	Tolerance of Sub- carrier Frequencies	within ± 0,1 %	(Consistent with EN 12253)
U1b	Use of Side Bands	Same data on both sides	(Consistent with EN 12253)
U2 [^E0024]	OBU (DSRC-VU) Transmitter Spectrum Mask	According to EN12253 1) Out band power: see ETSI EN 300674-1 2) In band power: [U4a] dBm in 500 kHz 3) Emission in any other uplink channel: U2(3)-1 = – 35 dBm in 500 kHz	(Consistent with EN 12253)
U4a [^E0024]	Maximum Single Side Band E.I.R.P. (boresight)	Two options: U4a-0: – 14 dBm U4a-1: – 21 dBm	According to declared and published specification of equipment designer
U4b [^E0024]	Maximum Single Side Band E.I.R.P. (35°)	Two options: — Not applicable — – 17dBm	According to declared and published specification of equipment designer
U5	Polarisation	Left hand circular	(Consistent with EN 12253)
U5a	Cross Polarisation	XPD: In bore sight: (REDCR) RSU r ≥ 15 dB (DSRC-VU) OBU t ≥ 10 dB At – 3 dB: (REDCR) RSU r ≥ 10 dB (DSRC-VU) OBU t ≥ 6 dB	(Consistent with EN 12253)
U6	Sub-Carrier Modulation	2-PSK Encoded data synchronised with sub-carrier: Transitions of encoded data coincide with transitions of sub- carrier.	(Consistent with EN 12253)
U6b	Duty Cycle	Duty Cycle: 50 % ± α, α ≤ 5 %	(Consistent with EN 12253)
U6c	Modulation on Carrier	Multiplication of modulated sub- carrier with carrier.	(Consistent with EN 12253)
U7 [^E0024]	Data Coding	NRZI (No transition at beginning of ‘1’ bit, transition at beginning of ‘0’ bit, no transition within bit)	(Consistent with EN 12253)
U8 [^E0024]	Bit Rate	250 kbit/s	(Consistent with EN 12253)
U8a	Tolerance of Bit Clock	Within ± 1 000  ppm	(Consistent with EN 12253)
U9	Bit Error Rate (B.E.R.) for communication	≤10– 6	(Consistent with EN 12253)
U11	Communication Zone	The 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.	(Consistent with EN 12253)
U12a [^E0024]	Conversion Gain (lower limit)	1 dB for each side band Range of angle: Circularly symmetric between bore sight and ± 35° and
U12a [^E0024]	Conversion Gain (lower limit)	within – 45° ± 45° Corresponding to the plane parallel to the road surface when the DSRC-VU later is installed in the vehicle (Azimuth)	Greater that the specified value range for horizontal angles up to ± 45°, due to the use cases defined in this annex.
U12b [^E0024]	Conversion Gain (upper limit)	10 dB for each side band	Less than the specified value range for each side band within a circular cone around boresight of ± 45° opening angle
U13	Preamble	Preamble is mandatory.	(Consistent with EN 12253)
U13a	Preamble Length and Pattern	32 to 36 μs modulated with sub- carrier only, then 8 bits of NRZI coded ‘0’ bits.	(Consistent with EN 12253)
U13b	Trailing Bits	The 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.	(Consistent with EN 12253)

– Uplink parameters subject to conformance testing in accordance with relevant parameter test from EN 300 674-1

5.3.3   Antenna design

5.3.3.1   REDCR antenna

• DSC_30The 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.

5.3.3.2   VU antenna