|
(37)
|
Appendix 12 is amended as follows:
|
(a)
|
the Table of Content is amended as follows:
|
(i)
|
the following point 1.1.1 is inserted after point 1.1:
|
|
(ii)
|
point 2 is replaced by the following:
|
‘2.
|
BASIC CHARACTERISTICS OF THE GNSS RECEIVER’;
|
|
|
(iii)
|
point 3 is replaced by the following:
|
‘3.
|
SENTENCES PROVIDED BY THE GNSS RECEIVER’;
|
|
|
(iv)
|
the following points 4.2.4 and 4.2.5 are inserted:
|
‘4.2.4
|
Structure of the WriteRecord command
|
|
|
(v)
|
point 5.2 is replaced by the following:
|
‘5.2.
|
Transfer of information from the GNSS receiver to the VU’;
|
|
|
(vi)
|
point 5.2.1 is deleted;
|
|
(vii)
|
the following points 5.3, 5.4 and 5.4.1 are inserted:
|
‘5.3.
|
Transfer of information from the VU to the GNSS receiver
|
|
5.4.
|
Error handling
|
5.4.1
|
Absence of position information from GNSS receiver’;
|
|
|
|
(viii)
|
points 6 and 7 are replaced by the following:
|
‘6.
|
POSITION DATA PROCESSING AND RECORDING BY THE VU
|
|
|
(ix)
|
the following point 8 is added:
|
‘8.
|
VEHICLE MOTION CONFLICT’;
|
|
|
|
(b)
|
point 1 is amended as follows
|
(i)
|
the text before Figure 1 is replaced by the following:
‘1. INTRODUCTION
This Appendix provides the technical requirements for the GNSS receiver and GNSS data used by the Vehicle Unit, including the protocols that must be implemented to assure the secure and correct data transfer of the positioning information.
1.1. Scope
|
GNS_1
|
The Vehicle Unit shall collect location data from at least one GNSS satellite network.
The Vehicle Unit may be with or without an external GNSS facility as described in Figure 1:’;
|
|
|
(ii)
|
the following point 1.1.1 is inserted after point 1.1:
|
‘1.1.1
|
References
The following references are used in this part of this Appendix.
|
NMEA
|
NMEA (National Marine Electronics Association) 0183 Interface Standard, V4.11’;
|
|
|
|
(iii)
|
in point 1.2, the following acronyms are added:
|
‘OSNMA
|
Galileo Open Service Navigation Messages Authentication
|
|
RTC
|
Real Time Clock
|
’;
|
|
|
(c)
|
point 2 is amended as follows:
|
(i)
|
the header is replaced by the following:
|
‘2.
|
BASIC CHARACTERISTICS OF THE GNSS RECEIVER’;
|
|
|
(ii)
|
paragraph GNS_3 is replaced by the following:
|
‘GNS_3
|
The GNSS receiver shall have the capability to support Navigation Messages Authentication on the Open Service of Galileo (OSNMA).’;
|
|
|
(iii)
|
the following paragraphs GNS_3a to GNS_3g are added:
|
‘GNS_3a
|
The GNSS receiver shall perform a number of consistency checks in order to verify that the measurements computed by the GNSS receiver on the basis of the OSNMA data have resulted in the correct information about the position, velocity and data of the vehicle, and have therefore not been influenced by any external attack such as meaconing. These consistency checks shall consist, for instance, of:
|
—
|
detection of abnormal power emissions by means of combined monitoring of the Automatic Gain Control (AGC) and Carrier-to-Noise density ratio (C/N0),
|
|
—
|
pseudorange measurement consistency and Doppler measurement consistency over time, including the detection of abrupt measurement jumps,
|
|
—
|
receiver autonomous integrity monitoring (RAIM) techniques, including the detection of inconsistent measurements with the estimated position,
|
|
—
|
position and velocity checks, including abnormal position and velocity solutions, sudden jumps and behaviour not consistent with the dynamics of the vehicle,
|
|
—
|
time and frequency consistency, including clock jumps and drifts that are not consistent with the receiver clock characteristics.
|
|
|
GNS_3b
|
The European Commission shall develop and approve the following documents:
|
—
|
A Signal in Space Interface Control Document (SIS ICD), specifying in detail the OSNMA information transmitted in the Galileo signal.
|
|
—
|
OSNMA Receiver Guidelines, providing the requirements and processes in the receivers to guarantee a secure implementation of OSNMA, as well as recommendations to enhance OSNMA performance.
|
GNSS receivers fitted in tachographs, either internal or external, shall be constructed in accordance with the SIS ICD and the OSNMA receiver guidelines.
|
|
GNS_3c
|
The GNSS receiver shall provide position messages, called authenticated position messages in this Annex and its Appendixes, which are elaborated using only satellites from which the authenticity of the navigation messages has been successfully verified.
|
|
GNS_3d
|
The GNSS receiver shall also provide standard position messages, elaborated using the satellites in view, regardless whether they are authenticated or not.
|
|
GNS_3e
|
The GNSS receiver shall use the VU Real Time Clock (RTC) as time reference for the time synchronisation necessary for OSNMA.
|
|
GNS_3f
|
The VU RTC time shall be provided to the GNSS receiver by the VU.
|
|
GNS_3g
|
The maximal time drift specified in requirement 41 of Annex IC, shall be provided to the GNSS receiver by the VU, along with the VU RTC time.’;
|
|
|
|
(d)
|
point 3 is replaced by the following:
|
‘3.
|
SENTENCES PROVIDED BY THE GNSS RECEIVER
This section describes the sentences used in the functioning of the Smart Tachograph, for transmitting standard and authenticated position messages. This section is valid both for the configuration of the Smart Tachograph with or without an external GNSS facility.
|
GNS_4
|
The standard position data is based on the NMEA sentence Recommended Minimum Specific (RMC) GNSS Data, which contains the Position information (Latitude, Longitude), Time in UTC format (hhmmss.ss), and Speed Over Ground in Knots plus additional values.
The format of the RMC sentence is the following (as from NMEA V4.11 standard):
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
|
(2)
|
Status, A= Valid position, V= Warning
|
|
(7)
|
Speed over ground in knots
|
|
(8)
|
Track made good, degrees true
|
|
(10)
|
Magnetic Variation, degrees
|
The Navigational status is optional and may not be present in the RMC sentence.
The Status gives indication if the GNSS signal is available. Until the value of the Status is not set to ‘A’, the received data (e.g., on Time or Latitude/Longitude) cannot be used to record the position of the vehicle in the VU.
The resolution of the position is based on the format of the RMC sentence described above. The first part of the fields 3) and 5) are used to represent the degrees. The rest are used to represent the minutes with three decimals. So the resolution is 1/1 000 of minute or 1/60 000 of degree (because one minute is 1/60 of a degree).
|
|
GNS_4a
|
The authenticated position data is based on a NMEA-like sentence, Authenticated Minimum Specific (AMC) Data, which contains the Position information (Latitude, Longitude), Time in UTC format (hhmmss.ss), and Speed Over Ground in Knots plus additional values.
The format of the AMC sentence is the following (as from NMEA V4.11 standard, except for value number 2):
$--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
|
(2)
|
Status, A=Authenticated position (established using at least 4 satellites from which the authenticity of the navigation messages has been successfully verified), J=jamming or O=other GNSS attack in the absence of failed authentication of navigation messages (by implemented consistency checks according to GNS_3a), F=failed authentication of navigation messages (as detected by OSNMA verifications specified in the documents referred to in GNS_3b), V=Void (authenticated position is not available for any other reason)
|
|
(7)
|
Speed over ground in knots
|
|
(8)
|
Track made good, degrees true
|
|
(10)
|
Magnetic Variation, degrees
|
The Navigational status is optional and may not be present in the AMC sentence.
The Status gives indication if an authenticated GNSS position is available, if an attack on the GNSS signals has been detected, if authentication of navigation messages has failed, or if GNSS position is void. When the value of the Status is not set to ‘A’, the received data (e.g. Time or Latitude/Longitude) are considered to be not valid, and may not be used to record the position of the vehicle in the VU. When the value of the Status is set to ‘J’ (jamming), ‘O’ (other GNSS attack), or ‘F’ (failed authentication of navigation messages), a GNSS anomaly event shall be recorded in the VU, as defined in Annex IC and Appendix 1 (EventFaultCode).
|
|
GNS_5
|
The Vehicle Unit shall store in the VU database the position information for latitude and longitude with a resolution of 1/10 of minute or 1/600 of a degree as described in Appendix 1 for type GeoCoordinates.
The GPS DOP and active satellites (GSA) command, as from NMEA V4.11 standard, can be used by the VU to determine and record the signal availability and accuracy of standard positions. In particular the HDOP is used to provide an indication on the level of accuracy of the recorded location data (see 4.2.2). The VU will store the value of the Horizontal Dilution of Precision (HDOP) calculated as the minimum of the HDOP values collected on the available GNSS systems.
The GNSS Id. indicates the corresponding NMEA Id. for every GNSS constellation and Satellite-Based Augmentation System (SBAS).
$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
|
(3)
|
ID of 1st satellite used for fix
|
|
(4)
|
ID of 2nd satellite used for fix
|
…
|
(14)
|
ID of 12th satellite used for fix
|
The System ID is optional and may not be present in the GSA sentence.
Similarly, the NMEA-like sentence authenticated active satellites (ASA) command can be used by the VU to determine and record the signal availability and accuracy of authenticated positions. Values 1 to 18 are defined in NMEA V4.11 standard.
$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
|
(3)
|
ID of 1st satellite used for fix
|
|
(4)
|
ID of 2nd satellite used for fix
|
…
|
(14)
|
ID of 12th satellite used for fix
|
The System ID is optional and may not be present in the ASA sentence.
|
|
GNS_6
|
When an external GNSS facility is used, the GSA sentence shall be stored in the GNSS Secure Transceiver with record number ’02’ to ’06’, and the ASA sentence shall be stored with record number ‘12’ to ‘16’.
|
|
GNS_7
|
The maximum size of the sentences (e.g., RMC, AMC, GSA, ASA or others), which can be used for the sizing of the read record command shall be 85 bytes (see Table 1).’;
|
|
|
|
(e)
|
point 4 is amended as follows:
|
(i)
|
in point 4.1.1, paragraph GNS_9 is amended as follows:
|
(1)
|
the text before sub-paragraph (b) is replaced by the following:
|
‘GNS_9
|
The external GNSS facility shall consist of the following components (see Figure 6):
|
(a)
|
A commercial GNSS receiver to provide the position data through the GNSS data interface. For example, the GNSS data interface can be NMEA standard V4.11 where the GNSS receiver acts as a talker and transmits NMEA sentences to the GNSS Secure Transceiver with a frequency of 1Hz for the pre-defined set of NMEA and NMEA-like sentences, which must include at least the RMC, AMC, GSA and ASA sentences. The implementation of the GNSS data interface is a choice of the manufacturers of the external GNSS facility.’;
|
|
|
|
(2)
|
subparagraph (c) is replaced by the following:
|
‘(c)
|
An enclosure system with tamper detection function, which encapsulates both the GNSS receiver and the GNSS Secure Transceiver. The tamper detection function shall implement the security protection measures as requested in the Protection Profile of the Smart Tachograph.’;
|
|
|
|
(ii)
|
point 4.2.1 is amended as follows:
|
(1)
|
paragraph GNS_14 is replaced by the following:
|
‘GNS_14
|
The communication protocol between the external GNSS facility and the vehicle unit shall support the following functions:
|
1.
|
The collection and distribution of GNSS data (e.g., position, timing, speed),
|
|
2.
|
The collection of the configuration data of the external GNSS facility,
|
|
3.
|
The management protocol to support the coupling, mutual authentication and session key agreement between the external GNSS facility and the VU,
|
|
4.
|
The transmission to the external GNSS facility of the VU RTC time and of the maximal difference between true time and the VU RTC time.’;
|
|
|
|
(2)
|
the following paragraph is inserted after paragraph GNS_18:
|
‘GNS_18a
|
Regarding the function 4) the transmission to the external GNSS facility of the VU RTC time and of the maximal difference between true time and the VU RTC time, the GNSS Secure Transceiver shall use an EF (EF VU) in the same DF with file identifier equal to ‘2F30’ as described in Table 1.’;
|
|
|
(3)
|
the following paragraph is inserted after paragraph GNS_19:
|
‘GNS_19a
|
The GNSS Secure Transceiver shall store the data coming from the VU in the EF VU. This is a linear, fixed-length record file with an identifier equal to ‘2F30’ in hexadecimal format.’;
|
|
|
(4)
|
in paragraph GNS_20, the first subparagraph is replaced by the following:
|
‘GNS_20
|
The GNSS Secure Transceiver shall use a memory to store the data and be able to perform as many read/write cycles as needed during a lifetime of at least 15 years. Apart from this aspect, the internal design and implementation of the GNSS Secure Transceiver is left to the manufacturers.’;
|
|
|
(5)
|
in GNS_21, Table 1 is replaced by the following:
‘
Table 1
File Structure
|
|
|
Access conditions
|
|
File
|
File ID
|
Read
|
Update
|
Encrypted
|
|
MF
|
3F00
|
|
|
|
|
EF.ICC
|
0002
|
ALW
|
NEV
(by VU)
|
No
|
|
DF GNSS Facility
|
0501
|
ALW
|
NEV
|
No
|
|
EF EGF_MACertificate
|
C100
|
ALW
|
NEV
|
No
|
|
EF CA_Certificate
|
C108
|
ALW
|
NEV
|
No
|
|
EF Link_Certificate
|
C109
|
ALW
|
NEV
|
No
|
|
EF EGF
|
2F2F
|
SM-MAC
|
NEV
(by VU)
|
No
|
|
EF VU
|
2F30
|
SM-MAC
|
SM-MAC
|
No
|
|
File / Data element
|
Record no
|
Size (bytes)
|
Default values
|
|
|
|
Min
|
Max
|
|
|
MF
|
|
552
|
1031
|
|
|
EF.ICC
|
|
|
|
|
|
sensorGNSSSerialNumber
|
|
8
|
8
|
|
|
|
|
|
|
|
|
DF GNSS Facility
|
|
612
|
1023
|
|
|
EF EGF_MACertificate
|
|
204
|
341
|
|
|
EGFCertificate
|
|
204
|
341
|
{00..00}
|
|
EF CA_Certificate
|
|
204
|
341
|
|
|
MemberStateCertificate
|
|
204
|
341
|
{00..00}
|
|
EF Link_Certificate
|
|
204
|
341
|
|
|
LinkCertificate
|
|
204
|
341
|
{00..00}
|
|
|
|
|
|
|
|
EF EGF
|
|
|
|
|
|
RMC NMEA Sentence
|
'01'
|
85
|
85
|
|
|
1st GSA NMEA Sentence
|
'02'
|
85
|
85
|
|
|
2nd GSA NMEA Sentence
|
'03'
|
85
|
85
|
|
|
3rd GSA NMEA Sentence
|
'04'
|
85
|
85
|
|
|
4th GSA NMEA Sentence
|
'05'
|
85
|
85
|
|
|
5th GSA NMEA Sentence
|
'06'
|
85
|
85
|
|
|
Extended serial-number of the external GNSS facility defined in Appendix 1 as SensorGNSSSerialNumber.
|
'07'
|
8
|
8
|
|
|
Operating system identifier of the GNSS Secure Transceiver defined in Appendix 1 as SensorOSIdentifier.
|
'08'
|
2
|
2
|
|
|
Type approval number of the external GNSS facility defined in Appendix 1 as SensorExternalGNSSApprovalNumber.
|
'09'
|
16
|
16
|
|
|
Identifier of the security component of the external GNSS facility defined in Appendix 1 as SensorExternalGNSSSCIdentifier
|
'10'
|
8
|
8
|
|
|
AMC Sentence
|
'11'
|
85
|
85
|
|
|
1st ASA Sentence
|
'12'
|
85
|
85
|
|
|
2nd ASA Sentence
|
'13'
|
85
|
85
|
|
|
3rd ASA Sentence
|
'14'
|
85
|
85
|
|
|
4th ASA Sentence
|
'15'
|
85
|
85
|
|
|
5th ASA Sentence
|
'16'
|
85
|
85
|
|
|
RFU – Reserved for Future Use
|
From '17' to 'FD'
|
|
|
|
|
EF VU
|
|
|
|
|
|
VuRtcTime (see Appendix 1)
|
'01'
|
4
|
4
|
{00..00}
|
|
VuGnssMaximalTimeDifference (see Appendix 1)
|
'02'
|
2
|
2
|
{00..00}’
|
;
|
|
|
(iii)
|
point 4.2.2 is amended as follows:
|
(1)
|
in paragraph GNS_22, the first subparagraph is replaced by the following:
|
‘GNS_22
|
The secure transfer of GNSS position data, VU RTC time and maximal time difference between true time and the VU RTC time shall be allowed only in the following conditions:’;
|
|
|
(2)
|
paragraph GNS_23 is replaced by the following:
|
‘GNS_23
|
Every T seconds, where T is a value lower or equal to 20, unless coupling or mutual authentication and session key agreement takes place, the VU requests from the external GNSS facility the position information on the basis of the following flow:
|
1.
|
The VU requests position data from the External GNSS facility together with Dilution of Precision data (from the GSA and ASA sentences). The VU Secure Transceiver shall use the ISO/IEC 7816-4:2013 SELECT and READ RECORD(S) commands in secure messaging authentication-only mode as described in section 11.5 of Appendix 11 with the file identifier ‘2F2F’ and RECORD number equal to ‘01’ for RMC NMEA sentence, ‘02’,’03’,’04’,’05’,’06’ for GSA NMEA sentence, ‘11’ for AMC sentence, and ‘12’,’13’,’14’,’15’,’16’ for ASA sentence.
|
|
2.
|
The last position data received is stored in the EF with identifier ‘2F2F’ and the records described in Table 1 in the GNSS secure transceiver as the GNSS secure transceiver receives NMEA data with a frequency of at least 1 Hz from the GNSS receiver through the GNSS data interface.
|
|
3.
|
The GNSS Secure Transceiver sends the response to the VU Secure Transceiver by using the APDU response message in secure messaging authentication-only mode as described in section 11.5 of Appendix 11.
|
|
4.
|
The VU Secure Transceiver checks the authenticity and integrity of the received response. In case of positive outcome, the position data is transferred to the VU processor through the GNSS data interface.
|
|
5.
|
The VU processor checks the received data extracting the information (e.g., latitude, longitude, time) from the RMC NMEA sentence. The RMC NMEA sentence includes the information if the non-authenticated position is valid. If the non-authenticated position is valid, the VU processor also extracts the values of HDOP from GSA NMEA sentences and calculates the minimum value on the available satellite systems (i.e., when the fix is available).
|
|
6.
|
The VU processor also extracts the information (e.g., latitude, longitude, time) from the AMC sentence. The AMC sentence includes the information if the authenticated position is not valid or GNSS signal has been attacked. If the position is valid, the VU processor also extracts the values of HDOP from ASA sentences and calculates the minimum value on the available satellite systems (i.e., when the fix is available).
|
|
|
GNS_23a
|
The VU shall also write VU RTC time and maximal time difference between true time and the VU RTC time as needed, by using the ISO/IEC 7816-4:2013 SELECT and WRITE RECORD(S) commands in secure messaging authentication-only mode as described in section 11.5 of Appendix 11 with the file identifier ‘2F30’ and RECORD number equal to ‘01’ for VuRtcTime and ‘02’ for MaximalTimeDifference.’;
|
|
|
|
(iv)
|
point 4.2.3 is amended as follows:
|
(1)
|
in paragraph GNS_26, the fourth and fifth indents are replaced by the following:
|
‘-
|
If the record is not found, the GNSS secure transceiver returns ‘6A83’.
|
|
-
|
If the external GNSS facility has detected tampering, it shall return status words ‘6690’.’;
|
|
|
(2)
|
paragraph GNS_27 is deleted;
|
|
|
(v)
|
the following points 4.2.4 and 4.2.5 are inserted:
|
‘4.2.4
|
Structure of the WriteRecord command
This section describes in detail the structure of the Write Record command. Secure messaging (authentication-only mode) is added as described in Appendix 11 Common security mechanisms.
|
GNS_26a
|
The command shall support the Secure Messaging authentication-only-mode, see Appendix 11.
|
|
GNS_26b
|
Command Message
|
Byte
|
Length
|
Value
|
Description
|
|
CLA
|
1
|
‘0Ch’
|
Secure messaging asked.
|
|
INS
|
1
|
‘D2h’
|
Write Record
|
|
P1
|
1
|
‘XXh’
|
Record number ('00' references the current record)
|
|
P2
|
1
|
‘04h’
|
Write the record with the record number indicated in P1
|
|
Data
|
X
|
‘XXh’
|
Data
|
|
|
GNS_26c
|
The record referenced in P1 becomes the current record.
|
Byte
|
Length
|
Value
|
Description
|
|
SW
|
2
|
‘XXXXh’
|
Status Words (SW1,SW2)
|
|
—
|
If the command is successful, the GNSS secure transceiver returns ‘9000’.
|
|
—
|
If the current file is not record oriented, the GNSS secure transceiver returns '6981'.
|
|
—
|
If the command is used with P1 = '00' but there is no current EF the GNSS secure transceiver returns '6986' (command not allowed).
|
|
—
|
If the record is not found, the GNSS secure transceiver returns '6A83'.
|
|
—
|
If the external GNSS facility has detected tampering, it shall return status words ’6690’.
|
|
|
|
4.2.5
|
Other commands
|
GNS_27
|
The GNSS Secure Transceiver shall support the following tachograph generation 2 commands specified in Appendix 2:
|
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
|
|
|
’;
|
|
(vi)
|
in point 4.4.1, paragraph GNS_28 is replaced by the following:
|
‘GNS_28
|
A 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.’;
|
|
|
(vii)
|
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 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’.’;
|
|
|
(viii)
|
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, 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).’;
|
|
|
(ix)
|
point 4.4.4 is amended as follows:
|
(1)
|
paragraph GNS_31 is replaced by the following:
|
‘GNS_31
|
If 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.’;
|
|
|
(2)
|
the header of figure 4 is replaced by the following:
‘Figure 6
Schema of the external GNSS facility’;
|
|
|
|
(f)
|
point 5 is amended as follows:
|
(i)
|
in point 5.1, paragraph GNS_32 is replaced by the following:
|
‘GNS_32
|
For 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.’;
|
|
|
(ii)
|
point 5.2 is replaced by the following:
|
‘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).’;
|
|
|
|
|
|
(g)
|
points 6 and 7 are replaced by the following:
|
‘6.
|
POSITION DATA PROCESSING AND RECORDING BY THE VU
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.
|
|
|
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.
|
|
|
7.
|
GNSS TIME CONFLICT
|
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).’;
|
|
|
|
(h)
|
the following point 8 is added:
|
‘8.
|
VEHICLE MOTION CONFLICT
|
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.’;
|
|
|
|
|
In force: This act has been changed. Current consolidated version: 21/08/2023
pictogram indicates that this position has been computed from authenticated navigation messages,
’;
’;
’;
’;
’;
’;
