ANNEX
Annex IC is amended as follows:
(1)the table of content is amended as follows:
(a)the following point 3.6.4 is inserted:
‘3.6.4
Entry of load/unload operation’;
(b)the following point 3.9.18 is inserted:
‘3.9.18
‘GNSS anomaly’ event’;
(c)the following points 3.12.17, 3.12.18 and 3.12.19 are inserted:
‘3.12.17
Border crossings
3.12.18
Load/unload operations
3.12.19
Digital map’;
(d)point 3.20 is replaced by the following:
‘3.20
Data exchanges with additional external devices’;
(e)the following points 3.27 and 3.28 are inserted:
‘3.27
Monitoring border crossings
3.28
Software update’;
(f)the following point 4.5.3.2.1.1 is inserted:
‘4.5.3.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)’;
(g)the following points 4.5.3.2.17 to 4.5.3.2.22 are inserted:
‘4.5.3.2.17
Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units)
4.5.3.2.18
Authentication status for positions where three hours accumulated driving time are reached (not accessed by version 1 of second generation vehicle units)
4.5.3.2.19
Border crossings (not accessed by version 1 of second generation vehicle units)
4.5.3.2.20
Load/unload operations (not accessed by version 1 of second generation vehicle units)
4.5.3.2.21
Load type entries (not accessed by version 1 of second generation vehicle units)
4.5.3.2.22
VU configurations (not accessed by version 1 of second generation vehicle units)’;
(h)the following point 4.5.4.2.1.1 is inserted:
‘4.5.4.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)’;
(i)the following points 4.5.4.2.16 to 4.5.4.2.22 are inserted:
‘4.5.4.2.16
Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units)
4.5.4.2.17
Authentication status for positions where three hours accumulated driving are reached (not accessed by version 1 of second generation vehicle units)
4.5.4.2.18
Border crossings (not accessed by version 1 of second generation vehicle units)
4.5.4.2.19
Load/unload operations (not accessed by version 1 of second generation vehicle units)
4.5.4.2.20
Load type entries (not accessed by version 1 of second generation vehicle units)
4.5.4.2.21
Calibration Additional Data (not accessed by version 1 of second generation vehicle units)
4.5.4.2.22
VU configurations (not accessed by version 1 of second generation vehicle units)’;
(j)the following point 4.5.5.2.1.1 is inserted after point 4.5.5.2.1:
‘4.5.5.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)’;
(k)the following point 4.5.5.2.6 is inserted:
‘4.5.5.2.6
VU configurations (not accessed by version 1 of second generation vehicle units)’;
(l)the following point 4.5.6.2.1.1 is inserted after point 4.5.6.2.1:
‘4.5.6.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)’;
(m)the following point 4.5.6.2.6 is inserted:
‘4.5.6.2.6
VU configurations (not accessed by version 1 of second generation vehicle units)’;
(2)the introductory text before the List of Appendixes is replaced by the following:
‘INTRODUCTION
This Annex contains second generation recording equipment and tachograph cards requirements.
Since June 15th 2019, second generation recording equipment is being installed in vehicles registered in the Union for the first time, and second generation tachograph cards are being issued.
In order to smoothly implement the second generation tachograph system, second generation tachograph cards have been designed to be also used in first generation vehicle units built in accordance with Annex IB to Regulation (EEC) No 3821/85.
Reciprocally, first generation tachograph cards may be used in second generation vehicle units. Nevertheless, second generation vehicle units can only be calibrated using second generation workshop cards.
The requirements regarding the interoperability between the first and the second generation tachograph systems are specified in this Annex. In this respect, Appendix 15 contains additional details on the management of the co-existence of both generations.
In addition, due to the implementation of new functions such as the use of Galileo Open Signal Navigation Messages Authentication, detection of border crossings, entry of load and unload operations, and also to the need to increase the driver card capacity to 56 days of driver activities, this Regulation introduces the technical requirements for the second version of the second generation recording equipment and tachograph cards.’;
(3)section 1, is amended as follows:
(a)point (f) is replaced by the following:
‘(f)
‘calibration of a smart tachograph’ means:
updating or confirming vehicle parameters to be held in the data memory. Vehicle parameters include vehicle identification (VIN, VRN and registering Member State) and vehicle characteristics (w, k, l, tyre size, speed-limiting device setting (if applicable), current UTC time, current odometer value, by-default load type); during the calibration of a recording equipment, the types and identifiers of all type-approval relevant seals in place shall also be stored in the data memory;
any update or confirmation of UTC time only, shall be considered as a time adjustment and not as a calibration, provided it does not contradict requirement 409 set out in point 6.4.
calibrating a recording equipment requires the use of a workshop card;’;
(b)point (g) is replaced by the following:
‘(g)
‘card number’ means:
a 16-alpha-numerical characters number that uniquely identifies a tachograph card within a Member State. The card number includes an identification, which consists in a driver identification, or in a card owner identification together with a card consecutive index, a card replacement index and a card renewal index;
a card is therefore uniquely identified by the code of the issuing Member State and the card number;’;
(c)points (i) and (j) are replaced by the following:
‘(i)
‘card renewal index’ means:
the 16th alpha-numerical character of a card number which is incremented each time a tachograph card corresponding to a given identification, i.e. driver identification or owner identification together with consecutive index, is renewed;
(j)
‘card replacement index’ means:
the 15th alpha-numerical character of a card number which is incremented each time a tachograph card corresponding to a given identification, i.e. driver identification or owner identification together with consecutive index, is replaced;’;
(d)point (ee) is replaced by the following:
‘(ee)
‘non-valid card’ means:
a card detected as faulty, or which authentication failed, or whose start of validity date is not yet reached, or which expiry date has passed;
a card is also considered as non-valid by the vehicle unit:
-
if a card with the same card issuing Member State, the same identification, i.e. driver identification or owner identification together with consecutive index, and a higher renewal index has already been inserted in the vehicle unit, or
-
if a card with the same card issuing Member State, the same identification, i.e. driver identification or owner identification together with consecutive index and renewal index but with a higher replacement index has already been inserted in the vehicle unit;’;
(e)point (ll) is replaced by the following:
‘(ll)
‘remote communication facility’, ‘remote communication module’ or ‘remote early detection facility’ means:
the equipment of the vehicle unit which is used to perform targeted roadside checks;’;
(f)point (nn) is replaced by the following:
‘(nn)
‘card renewal’ means:
issue of a new tachograph card when an existing card reaches its expiry date, or is malfunctioning and has been returned to the issuing authority;’;
(g)point (pp) is replaced by the following:
‘(pp)
‘card replacement’ means:
issue of a new tachograph card in replacement of an existing card, which has been declared as lost, stolen or malfunctioning and has not been returned to the issuing authority;’;
(h)point (tt) is replaced by the following:
‘(tt)
‘time adjustment’ means:
an adjustment of current time; this adjustment can be automatic, using the time provided by the GNSS receiver as a reference, or performed in calibration mode;’;
(i)in point (yy), the first indent is replaced by the following:
‘-
installed and used only in M1 and N1 type vehicles, as defined in Article 4 of Regulation (EU) 2018/858 of the European Parliament and of the Council,’;
(j)point (aaa) is replaced by the following:
‘(aaa)
reserved for future use;’;
(k)point (ccc) is replaced by the following:
‘(ccc)
‘introduction date’ means:
the date set out in Regulation (EU) No 165/2014 as from which vehicles registered for the first time shall be fitted with a tachograph in accordance with this Regulation.’;
(4)point 2.1 is amended as follows:
(a)paragraph (5) is replaced by the following:
‘(5)
The vehicle unit shall include an ITS interface, which is specified in Appendix 13.
The recording equipment may be connected to other facilities through additional interfaces and/or through the ITS interface.’;
(b)in paragraph (7), the last subparagraph is replaced by the following:
‘This is done in accordance with the applicable Union legislation regarding data protection and in compliance with Article 7 of Regulation (EU) No 165/2014.’;
(5)point 2.2 is amended as follows:
(a)the sixth indent is replaced by the following:
‘-
drivers manual entries:
-
entry of places where daily work periods begin and/or end,
-
manual entry of driver activities and driver consent for ITS interface,
-
entry of specific conditions,
-
entry of load/unload operations,’;
(b)the following indents are added
‘-
monitoring border crossings,
-
software update.’;
(6)point 2.3 is amended as follows
(a)in paragraph (12), the fifth indent is replaced by the following:
‘-
The downloading function is not accessible in the operational mode, except:
a)
as provided for in requirement 193,
b)
downloading a driver card when no other card type is inserted into the VU.’;
(b)paragraph (13) is amended as follows:
(i)
the second indent is replaced by the following:
‘-
in the company mode, driver related data (requirements 102, 105, 108, 133a and 133e) can be output only for periods where no lock exists or no other company,’;
(ii)
the fourth indent is replaced by the following:
‘-
personal data recorded and produced by either the tachograph or the tachograph cards shall not be output through the ITS interface of the VU unless the consent of the driver to whom the data relates is verified.’;
(7)in point 2.4(14), the fourth indent is replaced by the following:
‘-
external GNSS facility (this Profile is only needed and applicable for the external GNSS facility variant).’;
(8)point 3.1 is amended as follows:
(a)paragraph (16) is replaced by the following:
‘(16)
Upon card insertion (or remote card authentication) the recording equipment shall detect whether the card is a valid tachograph card in accordance with definition (ee) in section 1, and in such a case identify the card type and the card generation.
For checking if a card has already been inserted, the recording equipment shall use the tachograph card data stored in its data memory, as set out in requirement 133.’;
(b)paragraph (20) is replaced by the following:
‘(20)
The withdrawal of tachograph cards may function only when the vehicle is stopped and after the relevant data have been stored on the cards. The withdrawal of the card shall require positive action by the user.’;
(9)point 3.2 is amended as follows:
(a)paragraphs (26) and (27) are replaced by the following:
‘(26)
To detect manipulation of motion data, information from the motion sensor shall be corroborated by vehicle motion information derived from the GNSS receiver and by other source(s) independent from the motion sensor. At least another independent vehicle motion source shall be inside the VU without the need of an external interface.
(27)
This function shall measure the position of the vehicle in order to allow for the recording of:
-
positions where the driver and/or the co-driver begins his daily work period;
-
positions where the accumulated driving time reaches a multiple of three hours;
-
positions where the vehicle has crossed the border of a country;
-
positions where operations of load/unload have been carried out;
-
positions where the driver and/or the co-driver ends his daily work period.’;
(b)in point 3.2.1, the following sentence is added in paragraph (30):
‘The tolerances shall not be used to intentionally alter the distance measured.’;
(c)in point 3.2.2, paragraph (33) is replaced by the following:
‘(33)
To ensure a maximum tolerance on speed displayed of ± 6 km/h in use, and taking into account:
-
a ± 2 km/h tolerance for input variations (tyre variations, …),
-
a ± 1 km/h tolerance in measurements made during installation or periodic inspections,
the recording equipment shall, for speeds between 20 and 180 km/h, and for characteristic coefficients of the vehicle between 2400 and 25000 imp/km, measure the speed with a tolerance of ± 1 km/h (at constant speed).
Note: The resolution of data storage brings an additional tolerance of ± 0.5 km/h to speed stored by the recording equipment.’;
(d)in point 3.2.3, paragraph (37) is replaced by the following:
‘(37)
The absolute position shall be measured in geographical coordinates of latitude and longitude in degrees and minutes with a resolution of 1/10 of a minute.’;
(10)point 3.3 is amended as follows
(a)paragraph (41) is replaced by the following:
‘(41)
Time drift shall be ± 1 second per day or less, in temperature conditions in accordance with requirement 213, in the absence of any time adjustment.’;
(b)the following paragraphs (41a), (41b) and (41c) are inserted:
‘(41a)
Time accuracy when time is adjusted by workshops in accordance with requirement 212 shall be 3 seconds or better.
(41b)
The vehicle unit shall include a drift counter, which computes the maximal time drift since the last time adjustment in accordance with point 3.23. The maximal time drift shall be defined by the vehicle unit manufacturer and shall not exceed 1 second per day, as set out in requirement 41.
(41c)
The drift counter shall be reset to 1 second after each time adjustment of the recording equipment in accordance with point 3.23. This includes:
-
automatic time adjustments,
-
time adjustments performed in calibration mode.’;
(11)point 3.6 is amended as follows:
(a)point 3.6.1 is amended as follows:
(i)paragraphs (57) to (59) are replaced by the following:
‘(57)
Places are defined as the country and, in addition where applicable, the region.
(58)
Upon driver (or workshop) card withdrawal, the recording equipment shall display the current place of the vehicle on the basis of the GNSS information, and of stored digital map in accordance with point 3.12.19, and shall request the cardholder to confirm or to manually rectify the place.
(59)
The place entered in accordance with requirement 58 shall be considered as the place where the daily work period ends. It shall be recorded in the relevant driver (or workshop) card as a temporary record, and may therefore be later overwritten.
Under the following conditions temporary entry made at last card withdrawal is validated (i.e. shall not be overwritten anymore):
-
entry of a place where the current daily work period begins during manual entry according to requirement (61);
-
the next entry of a place where the current daily work period begins if the card holder does not enter any place where the work period begins or ended during the manual entry according to requirement (61).
Under the following conditions temporary entry made at last card withdrawal is overwritten and the new value is validated:
-
the next entry of a place where the current daily work period ends if the card holder does not enter any place where the work period begins or ended during the manual input according to requirement (61).’;
(ii)the following subparagraph is added in paragraph (60):
‘The recording equipment shall display the current place of the vehicle on the basis of the GNSS information, and of stored digital map(s) in accordance with point 3.12.19 and shall request the driver to confirm or to manually rectify the place.’;
(b)in point 3.6.2, paragraph (61) is replaced by the following:
‘(61)
Upon driver (or workshop) card insertion, and only at this time, the recording equipment shall allow manual entries of activities. Manual entries of activities shall be performed using local time and date values of the time zone (UTC offset) currently set for the vehicle unit.
At driver or workshop card insertion the cardholder shall be reminded of:
-
the date and time of his last card withdrawal;
-
optionally: the local time offset currently set for the vehicle unit.
At the first insertion of a given driver card or workshop card currently unknown to the vehicle unit, the cardholder shall be invited to express his consent for tachograph related personal data output through the ITS interface. For checking if a card has already been inserted, the recording equipment shall use the tachograph card data stored in its data memory, as set out in requirement 133.
At any moment, the driver (resp. workshop) consent can be enabled or disabled through commands in the menu, provided the driver (resp. workshop) card is inserted.
It shall be possible to input activities with the following restrictions:
-
Activity type shall be WORK, AVAILABILITY or BREAK/REST;
-
Start and end times for each activity shall be within the period of the last card withdrawal – current insertion only;
-
Activities shall not be allowed to overlap mutually in time.
It shall be possible to make manual entries, if required, at the first insertion of a previously unused driver (or workshop) card.
The procedure for manual entries of activities shall include as many consecutive steps as necessary to set a type, a start time and an end time for each activity. For any part of the time period between last card withdrawal and current card insertion, the cardholder shall have the option not to declare any activity.
During the manual entries associated with card insertion and if applicable, the card holder shall have the opportunity to input:
-
a place where a previous daily work period ended, associated to the relevant time (thus overwriting and validating the entry made at the last card withdrawal),
-
a place where the current daily work period begins, associated to the relevant time (thus validating a temporary entry made at last card withdrawal).
For the place where the current daily work period begins entered at the current card insertion, the recording equipment shall display the current place of the vehicle on the basis of the GNSS information, and of stored digital map(s) in accordance with point 3.12.19, and shall request the driver to confirm or to manually rectify the place.
If the card holder does not enter any place where the work period begins or ended, during the manual entries associated with card insertion, this shall be considered as a declaration that his work period has not changed since the last card withdrawal. The next entry of a place where a previous daily work period ends shall then overwrite the temporary entry made at the last card withdrawal.
If a place is entered, it shall be recorded in the relevant tachograph card.
Manual entries shall be interrupted if:
-
the card is withdrawn or,
-
the vehicle is moving and the card is in the driver slot.
Additional interruptions are allowed, e.g. a timeout after a certain period of user inactivity. If manual entries are interrupted, the recording equipment shall validate any complete place and activity entries (having either unambiguous place and time, or activity type, begin time and end time) already made.
If a second driver or workshop card is inserted while manual entries of activities are in progress for a previously inserted card, the manual entries for this previous card shall be allowed to be completed before manual entries start for the second card.
The cardholder shall have the option to insert manual entries according to the following minimum procedure:
-
Enter activities manually, in chronological order, for the period last card withdrawal – current insertion.
-
Begin time of the first activity shall be set to card withdrawal time. For each subsequent entry, the start time shall be preset to immediately follow the end time of the previous entry. Activity type and end time shall be selected for each activity.
The procedure shall end when the end time of a manually entered activity equals the card insertion time.
The recording equipment shall allow drivers and workshops to alternately upload manual entries that need to be entered during the procedure through the ITS interface specified in Appendix 13 and, optionally, through other interfaces.
The recording equipment shall allow the card holder to modify any activity manually entered, until validation by selection of a specific command. Thereafter, any such modification shall be forbidden.’;
(c)in point 3.6.3, paragraph (62) is replaced by the following:
‘(62)
The recording equipment shall allow the driver to enter, in real time, the following two specific conditions:
-
‘OUT OF SCOPE’ (begin, end),
-
‘FERRY / TRAIN CROSSING’ (begin, end).
A ‘FERRY / TRAIN CROSSING’ shall not occur if an ‘OUT OF SCOPE’ condition is opened. If an ‘OUT OF SCOPE’ condition is opened, the recording equipment shall not allow users to enter a ‘FERRY / TRAIN CROSSING’ begin flag.
An opened ‘OUT OF SCOPE’ condition must be automatically closed, by the recording equipment, if a driver card is inserted or withdrawn.
An opened ‘OUT OF SCOPE’ condition shall inhibit the following events and warnings:
-
Driving without an appropriate card,
-
Warnings associated with continuous driving time.
The driver shall enter the FERRY / TRAIN CROSSING begin flag immediately after selecting BREAK/REST on the ferry or train.
An opened FERRY / TRAIN CROSSING must be ended by the recording equipment when any of the following options occurs:
-
the driver manually ends the FERRY/TRAIN CROSSING, which shall occur upon arrival to destination of the ferry/train, before driving off the ferry/train,
-
an ‘OUT OF SCOPE’ condition is opened,
-
the driver ejects his card,
-
driver activity is computed as DRIVING during a calendar minute in accordance with point 3.4.
If more than one specific conditions entry of the same type is done within one calendar minute, only the last one shall be kept recorded.’;
(d)the following point 3.6.4 is added:
‘3.6.4
Entry of load/unload operation
(62a)
The recording equipment shall allow the driver to enter and confirm, in real time, information indicating that the vehicle is being loaded, unloaded or that simultaneous load/unload operation is being performed.
If more than one load/unload operation entry of the same type is done within one calendar minute, only the last one shall be kept recorded.
(62b)
Load, unload or simultaneous load/unload operations shall be recorded as separate events.
(62c)
The load/unload information shall be entered before the vehicle leaves the place where the load/unload operation is carried out.’;
(12)point 3.9 is amended as follows:
(a)in point 3.9.12, paragraph (83) is replaced by the following:
‘(83)
This event shall be triggered, while not in calibration mode, in case of interruption of the normal data flow between the motion sensor and the vehicle unit and/or in case of data integrity or data authentication error during data exchange between the motion sensor and the vehicle unit. This event shall also be triggered, while not in calibration mode, in case the speed calculated from the motion sensor pulses increases from 0 to more than 40 km/h within 1 second, and then stays above 40km/h during at least 3 seconds.’;
(b)in point 3.9.13, paragraph (84) is replaced by the following:
‘(84)
This event shall be triggered, as specified in Appendix 12, while not in calibration mode, in case motion information calculated from the motion sensor is contradicted by motion information calculated from the internal GNSS receiver or from the external GNSS facility or by other independent source(s) in accordance with requirement 26. This event shall not be triggered during a ferry/train crossing.’;
(c)in point 3.9.15, paragraph (86) is replaced by the following:
‘(86)
This event shall be triggered, while not in calibration mode, when the VU detects a discrepancy between the time of the vehicle unit’s time measurement function and the time originating from the authenticated positions transmitted by the GNSS receiver or the external GNSS facility. A ‘time discrepancy’ is detected if the time difference exceeds ±3 seconds corresponding to the time accuracy set out in requirement 41a, the latter increased by the maximal time drift per day. This event shall be recorded together with the internal clock value of the recording equipment. The VU shall perform the check for triggering the ‘time conflict’ event right before the VU automatically re-adjusts the VU internal clock, in accordance with requirement 211.’;
(d)in point 3.9.17, the eighth indent is replaced by the following:
‘-
ITS interface fault.’;
(e)the following point is added:
‘3.9.18
‘GNSS anomaly’ event
(88a)
This event shall be triggered, while not in calibration mode, when the GNSS receiver detects an attack, or when authentication of navigation messages has failed, as specified in Appendix 12. After a GNSS anomaly event has been triggered, the VU shall not generate other GNSS anomaly events for the next 10 minutes.’;
(13)in point 3.10, the last row in the table is replaced by the following:
‘
|
ITS interface
|
Proper operation
|
|
’;
(14)point 3.12 is amended as follows:
(a)the first paragraph is replaced by the following:
‘For the purpose of this point,
-
‘365 days’ is defined as 365 calendar days of average drivers’ activity in a vehicle. The average activity per day in a vehicle is defined as at least 6 drivers or co-drivers, 6 card insertion withdrawal cycles, and 256 activity changes. ‘365 days’ therefore include at least 2190 drivers or co-drivers, 2190 card insertion withdrawal cycles, and 93440 activity changes,
-
the average number of place entries per day is defined as at least 6 entries where the daily work period begins and 6 entries where the daily work period ends, so that ‘365 days’ include at least 4380 place entries,
-
the average number of positions per day when the accumulated driving time reaches a multiple of three hours is defined as at least 6 positions, so that ‘365 days’ include at least 2190 such positions,
-
the average number of border crossings per day is defined as at least 20 crossings, so that ‘365 days’ include at least 7300 border crossings,
-
the average number of load/unload operations per day is defined as at least 25 operations (irrespective of the type), so that ‘365 days’ include at least 9125 load/unload operations,
-
times are recorded with a resolution of one minute, unless otherwise specified,
-
odometer values are recorded with a resolution of one kilometre,
-
speeds are recorded with a resolution of 1 km/h,
-
positions (latitudes and longitudes) are recorded in degrees and minutes, with a resolution of 1/10 of minute, with the associated GNSS accuracy and acquisition time, and with a flag indicating whether the position has been authenticated.’;
(b)point 3.12.1.1 is amended as follows:
(i)in paragraph (93), the following indent is added:
‘-
digital map version identifier (requirement 133l).’;
(ii)paragraph (94) is replaced by the following:
‘(94)
Vehicle unit identification data are recorded and stored once and for all by the vehicle unit manufacturer, except data which may be changed in case of software update in accordance with this Regulation, and the ability to use first generation tachograph cards.’;
(c)in point 3.12.1.2, the first subparagraph of paragraph (97) is replaced by the following:
‘(97)
The vehicle unit shall be able to record and store in its data memory the following data related to the 20 most recent successful pairings of motion sensors (if several pairings happen within one calendar day, only the first and the last one of the day shall be stored):’;
(d)in point 3.12.1.3, the first subparagraph of paragraph (100) is replaced by the following:
‘(100)
The vehicle unit shall be able to record and store in its data memory the following data related to the 20 most recent successful couplings of external GNSS facilities (if several couplings happen within one calendar day, only the first and the last one of the day shall be stored).’;
(e)point 3.12.5 is amended as follows:
(i)paragraph (110) is amended as follows:
(1)
the first indent is replaced by the following:
‘-
the driver and/or co-driver card number and card issuing Member State’;
(2)
the following indent is added:
‘-
a flag indicating whether the position has been authenticated.’;
(ii)the following paragraph (110a) is inserted:
‘(110a)
For places where the daily work period begins or ends entered during the manual entry procedure at card insertion in accordance with requirement 61, the current odometer value and position of the vehicle shall be stored.’;
(f)in point 3.12.8, the table in paragraph (117) is amended as follows:
(i)the fifth row is replaced by the following:
‘
|
Last card session not correctly closed
|
-
the 10 most recent events.
|
-
date and time of card insertion,
-
card(s) type, number, issuing Member State and generation,
-
last session data as read from the card:
-
date and time of card
insertion.
|
’:
(ii)the following row is added:
‘
|
GNSS anomaly
|
-
the longest events for each of the 10 last days of occurrence,
-
the 5 longest events over the last 365 days.
|
-
date and time of beginning of event,
-
date and time of end of event,
-
card(s) type, number, issuing Member State and generation of any card inserted at beginning and/or end of the event,
-
number of similar events that day.
|
’;
(g)in point 3.12.10, the following indents are added in paragraph (120):
‘-
the serial numbers of the motion sensor, the external GNSS facility (if any), and the external remote communication facility (if any),
-
the by-default load type associated to the vehicle (load of either goods or passengers),
-
the country in which the calibration has been performed, and the date time when the position used to determine this country was provided by the GNSS receiver.’;
(h)the following points are added:
‘3.12.17
Border crossings
(133a)
The recording equipment shall record and store in its data memory the following information about border crossings:
-
the country that the vehicle is leaving,
-
the country that the vehicle is entering,
-
the position where the vehicle has crossed the border.
(133b)
Together with countries and position, the recording equipment shall record and store in its data memory:
-
the driver and/or co-driver card number and card issuing Member State,
-
the card generation,
-
the related GNSS accuracy, date and time,
-
a flag indicating whether the position has been authenticated
-
the vehicle odometer value at the time of border crossing detection.
(133c)
The data memory shall be able to hold border crossings for at least 365 days.
(133d)
When storage capacity is exhausted, new data shall replace oldest data.
3.12.18
Load/unload operations
(133e)
The recording equipment shall record and store in its data memory the following information about load and unload operations of the vehicle:
-
the type of operation (load, unload or simultaneous load/unload),
-
the position where the load/unload operation has occurred.
(133f)
When the position of the vehicle is not available from the GNSS receiver at the time of the load/unload operation, the recording equipment shall use the latest available position, and the related date and time.
(133g)
Together with the type of operation and position, the recording equipment shall record and store in its data memory:
-
the driver and/or co-driver card number and card issuing Member State,
-
the card generation,
-
the date and time of the load/unload operation,
-
the related GNSS accuracy, date and time if applicable,
-
a flag indicating whether the position has been authenticated,
-
the vehicle odometer value.
(133h)
The data memory shall be able to store load/unload operations for at least 365 calendar days.
(133i)
When storage capacity is exhausted, new data shall replace oldest data.
3.12.19
Digital map
(133j)
For the purpose of recording the position of the vehicle when the border of a country is crossed, the recording equipment shall store in its data memory a digital map.
(133k)
Allowed digital maps for supporting the border crossing monitoring function of the recording equipment shall be made available by the European Commission for download from a dedicated secured website, under various formats.
(133l)
For each of these maps, a version identifier and a hash value shall be available on the website.
(133m)
The maps shall feature:
-
a level of definition corresponding to NUTS level 0, according to the Nomenclature of Territorial Units for Statistics,
-
a scale of 1:1 million.
(133n)
Tachograph manufacturers shall select a map from the website and download it securely.
(133o)
Tachograph manufacturers shall only use a downloaded map from the website after having verified its integrity using the hash value of the map.
(133p)
The selected map shall be imported in the recording equipment by its manufacturer, under an appropriate format, but the semantic of the imported map shall remain unchanged.
(133q)
The manufacturer shall also store the version identifier of the map used in the recording equipment.
(133r)
It shall be possible to update or replace the stored digital map by a new one made available by the European Commission.
(133s)
Digital map updates shall be made using the software update mechanisms set up by the manufacturer, in application of requirements 226d and 226e, so that the recording equipment can verify the authenticity and integrity of a new imported map, before storing it and replacing the previous one.
(133t)
Tachograph manufacturers may add additional information to the basic map referred to in requirement (133m), for purposes other than recording border crossings, such as the borders of the EU regions, provided that the semantic of the basic map is not changed.’;
(15)point 3.13 is amended as follows:
(a)in paragraph (134), the third indent is replaced by the following:
‘-
to compute the driver's continuous driving time, cumulative break time and accumulated driving times for the previous and the current week,’;
(b)the following paragraph (135a) is added:
‘(135a)
The structure in the ‘TACHO_G2’ application depends on the version. Version 2 cards contain additional Elementary Files to the ones of version 1 cards, in particular:
-
in driver and workshop cards:
-
EF Places_Authentication shall contain the authentication status of the vehicle positions stored in EF Places. A timestamp shall be stored with each authentication status, which shall be exactly the same as the date and time of the entry stored with the corresponding position in EF Places.
-
EF GNSS_Places_Authentication shall contain the authentication status of the vehicle positions stored in EF GNSS_Places. A timestamp shall be stored with each authentication status, which shall be exactly the same as the date and time of the entry stored with the corresponding position in EF Places.
-
EF Border_Crossings, EF Load_Unload_Operations and EF Load_Type_Entries shall contain data related to border crossings, load/unload operations and load types.
-
in workshop cards:
-
EF Calibration_Add_Data shall contain additional calibration data to the ones stored in EF Calibration. The old date and time value and the vehicle identification number shall be stored with each additional calibration data record, which shall be exactly the same as the old date and time value and the vehicle identification number stored with the corresponding calibration data in EF Calibration.
-
in all tachograph cards:
-
EF VU_Configuration shall contain the cardholder tachograph specific settings.
The vehicle unit shall ignore any authentication status found in EF Places_Authentication or EF GNSS_Places_Authentication, when no vehicle position with the same timestamp is found in EF Places or EF GNSS_Places.
The vehicle unit shall ignore the elementary file EF VU_Configuration in all cards insofar as no specific rules have been provided with respect to the use of such elementary file. Those rules shall be set out through an amendment of Annex IC, which shall include the modification or deletion of this paragraph.’;
(16)point 3.14 is amended as follows:
(a)point 3.14.1 is amended as follows:
(i)paragraph (140) is replaced by the following:
‘(140)All events and faults not defined for the first generation recording equipment shall not be stored on the first generation driver and workshop cards.’;
(ii)paragraph (143) is replaced by the following:
‘(143)Before releasing a driver or workshop card and after all relevant data have been stored on the card, the recording equipment shall reset the ‘card session data’.’;
(b)point 3.14.2 is amended as follows:
(i)in paragraph (144), the following sub-paragraph is added:
‘The structure in the ‘TACHO_G2’ application depends on the version. Version 2 cards contain additional Elementary Files to the ones of version 1 cards.’;
(ii)the following paragraphs (147a) and (147b) are inserted:
‘(147a)
On insertion of a driver or workshop card, the recording equipment shall store on the card the by-default load type of the vehicle.
(147b)
On insertion of a driver or workshop card, and after the manual entry procedure, the recording equipment shall check the last place where the daily work period begins or ends stored on the card. This place may be temporary, as specified in requirement 59. If this place is in a different country from the current one in which the vehicle is located, the recording equipment shall store on the card a border crossing record, with:
-
the country that the driver left: not available,
-
the country that the driver is entering: the current country in which the vehicle is located,
-
the date and time when the driver has crossed the border: the card insertion time,
-
the position of the driver when the border has been crossed: not available,
-
the vehicle odometer value: not available.’;
(iii)the following paragraph (150a) is added:
‘(150a)
The vehicle unit shall ignore the elementary file EF VU_Configuration in all cards insofar as no specific rules have been provided with respect to the use of such elementary file. Those rules shall be set out through an amendment of Annex IC, which shall include the modification or deletion of this paragraph.’;
(17)in point 3.15.4, paragraph (167) is amended as follows:
(a)the second indent is replaced by the following:
‘-
the content of any of the printouts listed in requirement 169 under the same formats as the printouts themselves,’;
(b)the fifth and sixth indents are replaced by the following:
‘-
the accumulated driving time of the driver for the previous and the current week,
-
the accumulated driving time of the co-driver for the previous and the current week,’;
(c)the eighth, ninth and tenth indents are replaced by the following:
‘-
the accumulated driving time of the driver for the current week,
-
the accumulated driving time of the co-driver for the current daily work period,
-
the accumulated driving time of the driver for the current daily work period.’;
(18)point 3.18 is amended as follows:
(a)paragraph (193) is replaced by the following:
‘(193)
In addition and as an optional feature, the recording equipment may, in any mode of operation, download data through any other interface to a company authenticated through this channel. In such a case, company mode data access rights shall apply to this download.’;
(b)the following paragraphs (196a) and (196b) are added:
‘(196a)
A transport undertaking which uses vehicles that are fitted with recording equipment complying with this Annex and fall within the scope of Regulation (EC) No 561/2006, shall ensure that all data are downloaded from the vehicle unit and driver cards.
The maximum period within which the relevant data are downloaded shall not exceed:
-
90 days for data from vehicle unit;
-
28 days for data from the driver card.
(196b)
Transport undertakings shall keep the data downloaded from the vehicle unit and driver cards for at least twelve months following recording.’;
(19)in point 3.19, the following indents are added in paragraph (199):
‘-
vehicle position,
-
an indication if the driver may currently infringe the driving times.’;
(20)point 3.20 is amended as follows:
(a)the header is replaced by the following:
‘3.20
Data exchanges with additional external devices’;
(b)paragraph (200) is replaced by the following:
‘(200)
The recording equipment shall also be equipped with an ITS interface in accordance with Appendix 13, allowing the data recorded or produced by either the tachograph or the tachograph cards to be used by an external facility.
In operational mode, the driver consent shall be needed for the transmission of personal data through the ITS interface. Nevertheless, the driver consent shall not apply to tachograph or card data accessed in control, company or calibration mode. The data and functional access rights for these modes are specified in requirements 12 and 13.
The following requirements shall apply to ITS data made available through that interface:
-
personal data shall only be available after the verifiable consent of the driver has been given, accepting that personal data can leave the vehicle network.
A set of selected existing data that can be available via the ITS interface, and the classification of the data as personal or not personal are specified in Appendix 13. Additional data may also be output in addition to the set of data provided in Appendix 13. The VU manufacturer shall classify those data as ‘personal’ or ‘not personal’, being the driver consent applicable to those data classified as ‘personal’,
-
at any moment, the driver consent can be enabled or disabled through commands in the menu, provided the driver card is inserted,
-
in any circumstances, the presence of the ITS interface shall not disturb or affect the correct functioning and the security of the vehicle unit.
Additional vehicle unit interfaces may co-exist, provided they fully comply with the requirements of Appendix 13 in terms of driver consent. The recording equipment shall have the capacity to communicate the driver consent status to other platforms in the vehicle network and to external devices.
For personal data injected in the vehicle network, which are further processed outside the vehicle network, it shall not be the responsibility of the tachograph manufacturer to have that personal data process compliant with the applicable Union legislation regarding data protection.
The ITS interface shall also allow for data entry during the manual entry procedure in accordance with requirement 61, for both the driver and the co-driver.
The ITS interface may also be used to enter additional information, in real time, such as:
-
driver activity selection, in accordance with requirement 46,
-
places in accordance with requirement 56,
-
specific conditions, in accordance with requirement 62,
-
load/unload operations, in accordance with requirement 62a.
This information may also be entered through other interfaces.’;
(c)paragraph (201) is replaced by the following:
‘(201)
The serial link interface as specified in Annex IB to Regulation (EEC) No 3821/85, as last amended, can continue to equip tachographs for back compatibility. The serial link is classified as a part of the vehicle network, in accordance with requirement 200.’;
(21)point 3.21 is amended as follows,
(a)paragraph (202) is amended as follows:
(i)the ninth indent is replaced by the following:
‘-
to update or confirm other parameters known to the recording equipment: vehicle identification, w, l, tyre size and speed limiting device setting if applicable, and by-default load type,’;
(ii)
the following indent is added:
‘-
to automatically store the country in which the calibration has been performed, and the date time when the position used to determine this country was provided by the GNSS receiver.’;
(b)paragraph (205) is replaced by the following:
‘(205)
Coupling the external GNSS facility to the VU shall consist, at least, in:
-
updating external GNSS facility installation data held by the external GNSS facility (as needed),
-
copying from the external GNSS facility to the VU data memory the necessary external GNSS facility identification data including the serial number of the external GNSS facility.’;
(22)in point 3.22, the following sub-paragraph is added in paragraph (209):
‘When the I/O mode of the calibration I/O signal line is active according to this requirement, the ‘Driving without an appropriate card’ warning (requirement 75) shall not be triggered by the vehicle unit.’;
(23)point 3.23 is amended as follows:
(a)paragraph (211) is replaced by the following:
‘(211)
The time setting of the VU internal clock shall be automatically re-adjusted at variable time intervals. The next automatic time re-adjustment shall be triggered between 72h and 168h after the previous one, and after the VU can access to GNSS time through a valid authenticated position message in accordance with Appendix 12. Nevertheless, the time adjustment shall never be bigger than the accumulated maximal time drift per day, as calculated by the VU manufacturer in accordance with requirement 41b. If the difference between internal VU clock time and GNSS receiver time is bigger than the accumulated maximum time drift per day, then the time adjustment shall bring the VU internal clock as close as possible to the GNSS receiver time. The time setting may only be done if the time provided by the GNSS receiver is obtained using authenticated position messages as set out in Appendix 12. The time reference for the automatic time setting of the VU internal clock shall be the time provided in the authenticated position message.’;
(b)paragraph (212) is replaced by the following:
‘(212)
The time adjustment function shall also allow for triggered adjustment of the current time, in calibration mode.
Workshops may adjust time:
-
either by writing a time value in the VU, using the WriteDataByIdentifier service in accordance with section 6.2 of Appendix 8,
-
or by requesting an alignment of the VU clock to the time provided by the GNSS receiver. This may only be done if the time provided by the GNSS receiver is obtained using authenticated position messages. In this latter case, the RoutineControl service shall be used in accordance with section 8 of Appendix 8.’;
(24)the following points 3.27 and 3.28 are inserted:
‘3.27
Monitoring border crossings
(226a)
This function shall detect when the vehicle has crossed the border of a country, which country has been left and which country has been entered.
(226b)
The border crossing detection shall be based on the position measured by the recording equipment, and stored digital map in accordance with point 3.12.19.
(226c)
Border crossings related to the presence of the vehicle in a country for a shorter period than 120s shall not be recorded.
3.28
Software update
(226d)
The vehicle unit shall incorporate a function for the implementation of software updates whenever such updates do not involve the availability of additional hardware resources beyond the resources set out in requirement 226f, and the type-approval authorities give their authorisation to the software updates based on the existing type-approved vehicle unit, in accordance with Article 12(5) of Regulation (EU) No 165/2014.
(226e)
The software update function shall be designed for supporting the following functional features, whenever they are legally required:
-
modification of the functions referred to in point 2.2, except the software update function itself,
-
the addition of new functions directly related to the enforcement of Union legislation on road transport,
-
modification of the modes of operation in point 2.3,
-
modification of the file structure such as the addition of new data or the increase of the file size,
-
deployment of software patches to address software as well as security defects or reported attacks on the functions of the recording equipment.
(226f)
The vehicle unit shall provide free hardware resources of at least 35% for software and data needed for the implementation of requirement 226e and free hardware resources of at least 65% for the update of the digital map based on the hardware resources required for the NUTS 0 map version 2021.’;
(25)in point 4.1, after paragraph (235), the image ‘Community model tachograph cards’, the reverse side of the control card is replaced by the following:
‘
’;
(26)point 4.5 is amended as follows:
(a)paragraph (246) is replaced by the following:
‘(246)
Any additional data may be stored on tachograph cards, provided that the storage of those data complies with the applicable legislation regarding data protection.’;
(b)in paragraph (247), the following note is inserted after the second indent:
‘Note: version 2 of second generation cards contains additional Elementary Files in DF Tachograph_G2.’;
(c)point 4.5.3.2 is amended as follows:
(i)the header is replaced by the following:
‘4.5.3.2
Tachograph generation 2 application (not accessible to first generation vehicle units, accessible to version 1 and version 2 of second generation vehicle units)’;
(ii)the following point 4.5.3.2.1.1 is inserted after point 4.5.3.2.1:
‘4.5.3.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)
(278a)
The driver card shall be able to store additional application identification data only applicable for version 2.’;
(iii)in point 4.5.3.2.7, paragraph (287) is replaced by the following:
‘(287)
The driver card shall be able to store data for the 12 most recent events of each type (i.e. 132 events).’;
(iv)in point 4.5.3.2.8, paragraph (290) is replaced by the following:
‘(290)
The driver card shall be able to store data for the 24 most recent faults of each type (i.e. 48 faults).’;
(v)in point 4.5.3.2.9, paragraph (292) is replaced by the following:
‘(292)
The driver card memory shall be able to hold driver activity data for 56 days (the average activity of a driver is defined for this requirement as 117 activity changes per day).’;
(vi)in point 4.5.3.2.10, paragraph (295) is replaced by the following:
‘(295)
The driver card shall be able to store 200 such records.’;
(vii)in point 4.5.3.2.11, paragraph (297) is replaced by the following:
‘(297)
The driver card memory shall be able to hold 112 such records.’;
(viii)in point 4.5.3.2.14, paragraph (302) is replaced by the following:
‘(302)
The driver card shall be able to store 112 such records.’;
(ix)in point 4.5.3.2.15, paragraph (304) is replaced by the following:
‘(304)
The driver card shall be able to store 200 such records.’;
(x)in point 4.5.3.2.16, paragraph (306) is replaced by the following:
‘(306)
The driver card shall be able to store 336 such records.’;
(xi)the following points 4.5.3.2.17 to 4.5.3.2.22 are added:
‘4.5.3.2.17
Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units)
(306a)
The driver card shall be able to store additional data related to places where daily work periods begin and/or end, entered by the driver in accordance with point 4.5.3.2.11:
-
the date and time of the entry, which shall be exactly the same date and time as the one stored in EF Places under the DF Tachograph_G2,
-
a flag indicating whether the position has been authenticated.
(306b)
The driver card memory shall be able to hold 112 such records.
4.5.3.2.18
Authentication status for positions where three hours accumulated driving time are reached (not accessed by version 1 of second generation vehicle units)
(306c)
The driver card shall be able to store additional data related to the position of the vehicle where the accumulated driving time reaches a multiple of three hours in accordance with point 4.5.3.2.16:
-
the date and time when the accumulated driving time reaches a multiple of three hours, which shall be exactly the same date and time as the one stored in EF GNSS_Places under the DF Tachograph_G2,
-
a flag indicating whether the position has been authenticated.
(306d)
The driver card shall be able to store 336 such records.
4.5.3.2.19
Border crossings (not accessed by version 1 of second generation vehicle units)
(306e)
The driver card shall be able to store the following data related to border crossings either upon card insertion in accordance with requirement 147b or with the card already inserted:
-
the country that the vehicle is leaving,
-
the country that the vehicle is entering,
-
the date and time when the vehicle has crossed the border,
-
the position of the vehicle when the border was crossed,
-
the GNSS accuracy,
-
a flag indicating whether the position has been authenticated,
-
the vehicle odometer value.
(306f)
The driver card memory shall be able to store 1120 such records.
4.5.3.2.20
Load/unload operations (not accessed by version 1 of second generation vehicle units)
(306g)
The driver card shall be able to store the following data related to load/unload operations:
-
operation type (load, unload or simultaneous load/unload),
-
the date and time of the load/unload operation,
-
the position of the vehicle,
-
the GNSS accuracy, date and time when the position was determined,
-
a flag indicating whether the position has been authenticated,
-
the vehicle odometer value.
(306h)
The driver card shall be able to store 1624 load/unload operations.
4.5.3.2.21
Load type entries (not accessed by version 1 of second generation vehicle units)
(306i)
The driver card shall be able to store the following data related to load type automatically entered by the VU at each card insertion:
-
the load type entered (goods or passengers),
-
the date and time of the entry.
(306j)
The driver card shall be able to store 336 such records.
4.5.3.2.22
VU configurations (not accessed by version 1 of second generation vehicle units)
(306k)
The driver card shall be able to store the cardholder tachograph specific settings.
(306l)
The driver card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’;
(d)point 4.5.4.2 is amended as follows:
(i)the header is replaced by the following:
‘4.5.4.2
Tachograph Generation 2 application (not accessible to first generation vehicle units, accessible to version 1 and version 2 of second generation vehicle units)’;
(ii)the following point 4.5.4.2.1.1 is inserted after point 4.5.4.2.1:
‘4.5.4.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)
(330a)
The workshop card shall be able to store additional application identification data only applicable for version 2.’;
(iii)in point 4.5.4.2.6, paragraph (338) is replaced by the following:
‘(338)
The workshop card shall be able to store 255 such records.’;
(iv)in point 4.5.4.2.8, paragraph (344) is replaced by the following:
‘(344)
The workshop card shall be able to hold driver activity data for 1 day containing 240 activity changes.’;
(v)in point 4.5.4.2.9, paragraph (346) is replaced by the following:
‘(346)
The workshop card shall be able to store 8 such records.’;
(vi)point 4.5.4.2.10 is replaced by the following:
‘4.5.4.2.10
Places and positions where daily work periods start and/or end data
(347)
The workshop card shall be able to store places and positions where daily work periods begin and/or end data records in the same manner as a driver card.
(348)
The workshop card shall be able to store 4 pairs of such records.’;
(vii)in point 4.5.4.2.13, paragraph (352) is replaced by the following:
‘(352)
The workshop card shall be able to store 8 such records.’;
(viii)in point 4.5.4.2.14, paragraph (354) is replaced by the following:
‘(354)
The workshop card shall be able to store 24 such records.’;
(ix)in point 4.5.4.2.15, paragraph (356) is replaced by the following:
‘(356)
The workshop card shall be able to store 4 such records.’;
(x)the following points 4.5.4.2.16 to 4.5.4.2.22 are added:
‘4.5.4.2.16
Authentication status for positions related to places where daily work periods start and/or end (not accessed by version 1 of second generation vehicle units)
(356a)
The workshop card shall be able to store additional data related to places where daily work periods start and/or end in the same manner as a driver card.
(356b)
The workshop card memory shall be able to store 4 pairs of such records.
4.5.4.2.17
Authentication status for positions where three hours accumulated driving are reached (not accessed by version 1 of second generation vehicle units)
(356c)
The workshop card shall be able to store additional data related to the position of the vehicle where the accumulated driving time reaches a multiple of three hours in the same manner as a driver card.
(356d)
The workshop card shall be able to store 24 such records.
4.5.4.2.18
Border crossings (not accessed by version 1 of second generation vehicle units)
(356e)
The workshop card shall be able to store the border crossings in the same manner as a driver card.
(356f)
The workshop card memory shall be able to store 4 such records.
4.5.4.2.19
Load/unload operations (not accessed by version 1 of second generation vehicle units)
(356g)
The workshop card shall be able to store the load/unload operations in the same manner as a driver card.
(356h)
The workshop card shall be able to store 8 load, unload or simultaneous load/unload operations.
4.5.4.2.20
Load type entries (not accessed by version 1 of second generation vehicle units)
(356i)
The workshop card shall be able to store the load type entries in the same manner as a driver card.
(356j)
The workshop card shall be able to store 4 such records.
4.5.4.2.21
Calibration Additional Data (not accessed by version 1 of second generation vehicle units)
(356k)
The workshop card shall be able to store additional calibration data only applicable for version 2:
-
the old date and time and the vehicle identification number, which shall be exactly the same values as the one stored in EF Calibration under the DF Tachograph_G2,
-
the by-default load type entered during this calibration,
-
the country in which the calibration has been performed, and the date time when the position used to determine this country was provided by the GNSS receiver.
(356l)
The workshop card shall be able to store 255 such records.
4.5.4.2.22
VU configurations (not accessed by version 1 of second generation vehicle units)
(356m)
The workshop card shall be able to store the cardholder tachograph specific settings.
(356n)
The workshop card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’;
(e)point 4.5.5 is amended as follows:
(i)in point 4.5.5.1.5 the second indent is replaced by the following:
‘-
type of the control (displaying and/or printing and/or VU downloading and/or card downloading),’;
(ii)the following point 4.5.5.2.1.1 is inserted after point 4.5.5.2.1:
‘4.5.5.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)
(363a)
The control card shall be able to store additional application identification data only applicable for version 2.’;
(iii)the following point is inserted after point 4.5.5.2.5:
‘4.5.5.2.6
VU configurations (not accessed by version 1 of second generation vehicle units)
(368a)
The control card shall be able to store the cardholder tachograph specific settings.
(368b)
The control card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’;
(f)point 4.5.6.2 is amended as follows:
(i)the following point is inserted after point 4.5.6.2.1:
‘4.5.6.2.1.1
Additional application identification (not accessed by version 1 of second generation vehicle units)
(375a)
The company card shall be able to store additional application identification data only applicable for version 2.’;
(ii)the following point 4.5.6.2.6 is added:
‘4.5.6.2.6
VU configurations (not accessed by version 1 of second generation vehicle units)
(380a)
The company card shall be able to store the cardholder tachograph specific settings.
(380b)
The company card storage capacity for cardholder tachograph specific settings shall be 3072 bytes.’;
(27)point 5 is amended as follows:
(a)point 5.1 is amended as follows:
(i)paragraph (383) is replaced by the following:
‘(383)
Before its activation, the recording equipment shall neither record nor store data referred to by the requirements 102 to 133 inclusive. Nevertheless, before its activation, the recording equipment may record and store the security breach attempt events in accordance with requirement 117, and the recording equipment faults in accordance with requirement 118.’;
(ii)paragraph (392) is replaced by the following:
‘(392)
Installation shall be followed by a calibration. The first calibration may not necessarily include entry of the vehicle registration identification (VRN and Member State), when it is not known by the approved workshop having to undertake this calibration. In these circumstances, it shall be possible, for the vehicle owner, and at this time only, to enter the VRN and the Member State using his company card prior to using the vehicle in scope of Regulation (EC) No 561/2006 (e.g by using commands through an appropriate menu structure of the vehicle unit's man-machine interface). Any update or confirmation of this entry shall only be possible using a workshop card.’;
(b)point 5.2 is amended as follows:
(i)the first subparagraph in paragraph (395) is replaced by the following:
‘After the recording equipment has been checked on installation, an installation plaque, engraved or printed in a permanent way, which is clearly visible and easily accessible shall be affixed onto the recording equipment. In cases where this is not possible, the plaque shall be affixed to the vehicle's ‘B’ pillar so that it is clearly visible. For vehicles that do not have a ‘B’ pillar, the installation plaque should be affixed in the area of the door of the vehicle and be clearly visible in all cases.’;
(ii)paragraph (396) is amended as follows:
(1)
the tenth indent is replaced by the following:
‘-
the serial number of the remote communication facility, if any,’;
(2)
the following sixteenth indent is added:
‘-
the by-default load type associated to the vehicle.’;
(28)point 6.4 is amended as follows:
(a)paragraph (409) is replaced by the following:
‘(409)
Periodic inspections of the equipment fitted to the vehicles shall take place after any repair of the equipment, or after any alteration of the characteristic coefficient of the vehicle or of the effective circumference of the tyres, or after equipment UTC time is wrong by more than 5 minutes, or when the VRN has changed, and at least once within two years (24 months) of the last inspection.’;
(b)in paragraph (410), the following ninth indent is added:
‘-
that the version identifier of the stored digital map is the most recent one.’;
(c)the following paragraph (410a) is inserted:
‘(410a)In case of detection of a manipulation by the competent national authorities, the vehicle may be sent to an authorised workshop for a recalibration of the recording equipment.’;
(29)point 8 is amended as follows:
(a)in point 8.1, paragraphs (429) and (430) are replaced by the following:
‘(429)Procedures to update in-situ recording equipment software shall be approved by the authority which granted type approval for the recording equipment. Software update must not alter nor delete any driver activity data stored in the recording equipment. Software may be updated only under the responsibility of the equipment manufacturer.
(430)
Type approval of software modifications aimed to update a previously type approved recording equipment may not be refused if such modifications only apply to functions not specified in this Annex. Software update of a recording equipment may exclude the introduction of new character sets, if not technically feasible.’;
(b)point 8.4 is amended as follows:
(i)paragraph (443) is replaced by the following:
‘(443)No interoperability tests shall be carried out by the laboratory, for recording equipment or tachograph cards that have not passed the vulnerability analysis of their security evaluation and a functional evaluation, except in the exceptional circumstances described in requirement 432.’;
(ii)paragraph (447) is replaced by the following:
‘(447)The interoperability certificate shall be issued by the laboratory to the manufacturer only after all required interoperability tests have been successfully passed and after the manufacturer has shown that both a valid functional certificate and a valid security certificate for the product has been granted, except in the exceptional circumstances described in requirement 432.’;
(30)Appendix 1 is amended as follows:
(a)the Table of Content is amended as follows:
(i)the following points 2.11a and 2.11b are inserted:
‘2.11a.
CardBorderCrossing
2.11b.
CardBorderCrossingRecord’;
(ii)the following points 2.24a, 2.24b, 2.24c and 2.24d are inserted:
‘2.24a.
CardLoadTypeEntries
2.24b.
CardLoadTypeEntryRecord
2.24c.
CardLoadUnloadOperations
2.24d.
CardLoadUnloadRecord’;
(iii)the following point 2.26a is inserted:
‘2.26a.
CardPlaceAuthDailyWorkPeriod’;
(iv)the following point 2.48a is inserted:
‘2.48a.
CompanyCardApplicationIdentificationV2’;
(v)the following point 2.50a is inserted:
‘2.50a.
ControlCardApplicationIdentificationV2’;
(vi)the following point 2.60a is inserted:
‘2.60a.
DownloadInterfaceVersion’;
(vii)the following point 2.61a is inserted:
‘2.61a.
DriverCardApplicationIdentificationV2’;
(viii)the following points 2.79a, 2.79b and 2.79c are inserted:
‘2.79a.
GNSSAuthAccumulatedDriving
2.79b.
GNSSAuthStatusADRecord
2.79c.
GNSSPlaceAuthRecord’;
(ix)point 2.84 is replaced by the following:
‘2.84.
Reserved for future use’;
(x)the following point 2.89a is inserted:
‘2.89a.
LengthOfFollowingData’;
(xi)the following point 2.90a is inserted:
‘2.90a.
LoadType’;
(xii)the following point 2.101a is inserted:
‘2.101a.
NoOfBorderCrossingRecords’;
(xiii)the following point 2.111a is inserted:
‘2.111a.
NoOfLoadUnloadRecords’;
(xiv)the following point 2.112a is inserted:
‘2.112a.
NoOfLoadTypeEntryRecords’;
(xv)the following point 2.114a is inserted:
‘2.114a.
OperationType’;
(xvi)the following points 2.116a and 2.116b are inserted:
‘2.116a.
PlaceAuthRecord
2.116b.
PlaceAuthStatusRecord’;
(xvii)the following point 2.117a is inserted:
‘2.117a.
PositionAuthenticationStatus’;
(xviii)the following point 2.158a is inserted:
‘2.158a.
TachographCardsGen1Suppression’;
(xix)the following point 2.166a is inserted:
‘2.166a.
VehicleRegistrationIdentificationRecordArray’;
(xx)the following point 2.185a is inserted:
‘2.185a.
VuConfigurationLengthRange’;
(xxi)the following point 2.192a is inserted:
‘2.192a.
VuDigitalMapVersion’;
(xxii)the following points 2.203a and 2.203b are inserted:
‘2.203a.
VuBorderCrossingRecord
2.203b.
VuBorderCrossingRecordArray’;
(xxiii)the following point 2.204a is inserted:
‘2.204a.
VuGnssMaximalTimeDifference’;
(xxiv)the following points 2.208a and 2.208b are inserted:
‘2.208a.
VuLoadUnloadRecord
2.208b.
VuLoadUnloadRecordArray’;
(xxv)the following point 2.222a is inserted:
‘2.222a.
VuRtcTime’;
(xxvi)the following points 2.234a, 2.234b and 2.234c are inserted:
‘2.234a.
WorkshopCardApplicationIdentificationV2
2.234b.
WorkshopCardCalibrationAddData
2.234c.
WorkshopCardCalibrationAddDataRecord’;
(b)in point 2, the text before point 2.1 is replaced by the following:
‘For any of the following data types, the default value for an ‘unknown’ or a ‘not applicable’ content will consist in filling the data element with Hex ‘FF’ bytes, unless otherwise specified.
All data types are used for Generation 1 and Generation 2 applications unless otherwise specified. Data types only used for Generation 2, version 2 applications are indicated.
For card data types used for Generation 1 and Generation 2 applications, the size specified in this Appendix is the one for Generation 2 application. The size for Generation 1 application is supposed to be already known by the reader. The Annex IC requirement numbers related to such data types cover both Generation 1 and Generation 2 applications.
Card data types not defined for Generation 1 cards are not stored in Generation 1 application of Generation 2 cards. In particular:
-
Type approval numbers stored in Generation 1 application of Generation 2 cards are truncated to the 8 first characters where needed,
-
Only the ‘FERRY / TRAIN CROSSING begin’ of a ‘FERRY / TRAIN CROSSING’ specific condition is stored in Generation 1 application of Generation 2 cards.’;
(c)the following points 2.11a and 2.11b are inserted:
‘2.11a.
CardBorderCrossings
Generation 2, version 2:
Information, stored in a driver or workshop card, related to the border crossings of the vehicle when the latter has crossed the border of a country (Annex IC requirements 306f and 356f).
|
CardBorderCrossings ::= SEQUENCE {
borderCrossingPointerNewestRecord
INTEGER (0..NoOfBorderCrossingRecords -1),
cardBorderCrossingRecords
SET SIZE (NoOfBorderCrossingRecords)
OF CardBorderCrossingRecord
}
|
borderCrossingPointerNewestRecord is the index of the last updated card border crossing record.
Value assignment is the number corresponding to the numerator of the card border crossing record, beginning with ‘0’ for the first occurrence of the card border crossing record in the structure.
cardBorderCrossingRecords is the set of card border crossing records.
2.11b.
CardBorderCrossingRecord
Generation 2, version 2:
Information, stored in a driver or workshop card, related to the border crossings of the vehicle when the latter has crossed the border of a country (Annex IC requirements 147b, 306e and 356e).
|
CardBorderCrossingRecord ::= SEQUENCE {
countryLeft
NationNumeric,
countryEntered
NationNumeric,
gnssPlaceAuthRecord
GNSSPlaceAuthRecord,
vehicleOdometerValue
OdometerShort
}
|
countryLeft is the country which was left by the vehicle, or ‘no information available’ according to Annex IC requirement 147b. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps).
countryEntered is the country into which the vehicle has entered, or the country in which the vehicle is located at card insertion time. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps).
gnssPlaceAuthRecord contains information related to the position of the vehicle, when the vehicle unit has detected that the vehicle has crossed the border of a country, or ‘no information available’ according to requirement 147b of Annex IC, and its authentication status.
vehicleOdometerValue is the odometer value when the vehicle unit has detected that the vehicle has crossed the border of a country, or ‘no information available’ according to requirement 147b of Annex IC.’;
(d)the following points 2.24a, 2.24b, 2.24c and 2.24d are inserted:
‘2.24a.
CardLoadTypeEntries
Generation 2, version 2:
Information, stored in a driver or workshop card, related to the load type entries when the card is inserted in a vehicle unit (Annex IC requirements 306j and 356j).
|
CardLoadTypeEntries ::= SEQUENCE {
loadTypeEntryPointerNewestRecord
INTEGER(0..NoOfLoadTypeEntryRecords -1),
cardLoadTypeEntryRecords
SET SIZE(NoOfLoadTypeEntryRecords) OF
CardLoadTypeEntryRecord
}
|
loadTypeEntryPointerNewestRecord is the index of the last updated card load type entry record.
Value assignment: number corresponding to the numerator of the card load type entry record, beginning with '0' for the first occurrence of the card load type entry record in the structure.
cardLoadTypeEntryRecords is the set of records containing the date and time of the entry and the load type entered.
2.24b.
CardLoadTypeEntryRecord
Generation 2, version 2:
Information, stored in a driver or workshop card, related to the load type changes entered when the card is inserted in a vehicle unit (Annex IC requirements 306i and 356i).
|
CardLoadTypeEntryRecord ::= SEQUENCE {
timeStampTimeReal,
loadTypeEnteredLoadType
}
|
timeStamp is the date and time when the load type was entered.
loadTypeEntered is the load type entered.
2.24c.
CardLoadUnloadOperations
Generation 2, version 2:
Information, stored in a driver or workshop card, related to load/unload operations of the vehicle (Annex IC requirements 306h and 356h).
|
CardLoadUnloadOperations ::= SEQUENCE {
loadUnloadPointerNewestRecordINTEGER(0..NoOfLoadUnloadRecords -1),
cardLoadUnloadRecords
SET SIZE(NoOfLoadUnloadRecords) OF
CardLoadUnloadRecord
}
|
loadUnloadPointerNewestRecord is the index of the last updated card load/unload record.
Value assignment: is the number corresponding to the numerator of the card load/unload record, beginning with '0' for the first occurrence of the card load/unload record in the structure.
cardLoadUnloadRecords is the set of records containing the indication of the type of operation performed (load, unload, or simultaneous load and unload), the date and time the load/unload operation has been entered, information about the position of the vehicle, and the vehicle odometer value.
2.24d.
CardLoadUnloadRecord
Generation 2, version 2:
Information, stored in a driver or workshop card, related to load/unload operations of the vehicle (Annex IC requirements 306g and 356g).
|
CardLoadUnloadRecord ::= SEQUENCE {
timeStampTimeReal,
operationTypeOperationType,
gnssPlaceAuthRecordGNSSPlaceAuthRecord,
vehicleOdometerValueOdometerShort
}
|
timeStamp is the date and time at the beginning of the load/unload operation.
operationType is the type of operation entered (load, unload, or simultaneous load/unload).
gnssPlaceAuthRecord contains information related to the position of the vehicle.
vehicleOdometerValue is the odometer value related to the beginning of the load/unload operation.’;
(e)the following point 2.26a is inserted:
‘2.26a.
CardPlaceAuthDailyWorkPeriod
Generation 2, version 2:
Information, stored in a driver or a workshop card, providing the authentication status of places where daily work periods begin and/or end (Annex IC requirements 306b and 356b).
|
CardPlaceAuthDailyWorkPeriod ::= SEQUENCE {
placeAuthPointerNewestRecordINTEGER(0 .. NoOfCardPlaceRecords-1),
placeAuthStatusRecordsSET SIZE(NoOfCardPlaceRecords) OF PlaceAuthStatusRecord
}
|
placeAuthPointerNewestRecord is the index of the last updated place authentication status record.
Value assignment: Number corresponding to the numerator of the place authentication status record, beginning with ‘0’ for the first occurrence of the place authentication status records in the structure.
placeAuthStatusRecords is the set of records containing the place authentication status of the places entered.’;
(f)in point 2.36, the text corresponding to the value assignment ‘bbH’ is replaced by the following:
‘‘bb’H
Index for changes concerning the use of the data elements defined for the structure given by the high byte.
‘00’H for Generation 1 applications
‘00’H for version 1 of Generation 2 applications
‘01’H for version 2 of Generation 2 applications’;
(g)in point 2.40, the paragraph between the header and the code is replaced by the following:
‘Generation 2:
Information, stored in a driver or workshop card, related to the vehicle units used by the card holder (Annex IC requirements 304 and 352).’;
(h)the following point 2.48a is inserted:
‘2.48a.
CompanyCardApplicationIdentificationV2
Generation 2, version 2:
Information, stored in a company card related to the identification of the application of the card (Annex IC requirement 375a).
|
CompanyCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingData
LengthOfFollowingData,
vuConfigurationLengthRange
VuConfigurationLengthRange
}
|
lengthOfFollowingData is the number of bytes following in the record.
vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.’;
(i)the following point 2.50a is inserted:
‘2.50a.
ControlCardApplicationIdentificationV2
Generation 2, version 2:
Information, stored in a control card related to the identification of the application of the card (Annex IC requirement 363a).
|
ControlCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingData
LengthOfFollowingData,
vuConfigurationLengthRange
VuConfigurationLengthRange
}
|
lengthOfFollowingData is the number of bytes following in the record.
vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.’;
(j)the following point 2.60a is inserted:
‘2.60a.
DownloadInterfaceVersion
Generation 2, version 2:
Code indicating the version of the download interface of a vehicle unit.
|
DownloadInterfaceVersion ::= OCTET STRING (SIZE(2))
|
Value assignment: ‘aabb’H:
‘aa’H
‘00’H: not used,
‘01’H: Generation 2 vehicle unit,
‘bb’H
‘00’H: not used,
‘01’H: version 2 of Generation 2 vehicle unit.’;
(k)the following point 2.61a is inserted:
‘2.61a.
DriverCardApplicationIdentificationV2
Generation 2, version 2:
Information, stored in a driver card related to the identification of the application of the card (Annex IC requirement 278a).
|
DriverCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingDataLengthOfFollowingData,
noOfBorderCrossingRecordsNoOfBorderCrossingRecords,
noOfLoadUnloadRecordsNoOfLoadUnloadRecords,
noOfLoadTypeEntryRecordsNoOfLoadTypeEntryRecords,
vuConfigurationLengthRangeVuConfigurationLengthRange
}
|
lengthOfFollowingData is the number of bytes following in the record.
noOfBorderCrossingRecords is the number of border crossing records the driver card can store.
noOfLoadUnloadRecords is the number of load/unload records the driver card can store.
noOfLoadTypeEntryRecords is the number of load type entry records the driver card can store.
vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.’;
(l)point 2.63 is replaced by the following:
‘2.63.
DSRCSecurityData
Generation 2:
For the definition of this data type, see Appendix 11.’;
(m)in point 2.66, the text corresponding to generation 2 is replaced by the following:
‘Generation 2
|
EntryTypeDailyWorkPeriod ::= INTEGER {
Begin,
related time = card insertion time or time of entry(0),
End,
related time = card withdrawal time or time of entry
(1),
Begin,
related time manually entered (start time)
(2),
End,
related time manually entered (end of work period)
(3)
}
|
Value assignment: according to ISO/IEC8824-1.’;
(n)point 2.70 is amended as follows:
(i)the header corresponding to Generation 2 is replaced by the following:
‘Generation 2, version 1:’;
(ii)the following text is added:
‘Generation 2, version 2:
‘0x’H General events,
‘00’HNo further details,
‘01’HInsertion of a non valid card,
‘02’HCard conflict,
‘03’HTime overlap,
‘04’HDriving without an appropriate card,
‘05’HCard insertion while driving,
‘06’HLast card session not correctly closed,
‘07’HOver speeding,
‘08’HPower supply interruption,
‘09’HMotion data error,
‘0A’HVehicle Motion Conflict,
‘0B’HTime conflict (GNSS versus VU internal clock),
‘0C’HCommunication error with the remote communication facility,
‘0D’HAbsence of position information from GNSS receiver,
‘0E’HCommunication error with the external GNSS facility,
‘0F’HGNSS anomaly,
‘1x’HVehicle unit related security breach attempt events,
‘10’HNo further details,
‘11’HMotion sensor authentication failure,
‘12’HTachograph card authentication failure,
‘13’HUnauthorised change of motion sensor,
‘14’HCard data input integrity error,
‘15’HStored user data integrity error,
‘16’HInternal data transfer error,
‘17’HUnauthorised case opening,
‘18’HHardware sabotage,
‘19’HTamper detection of GNSS,
‘1A’HExternal GNSS facility authentication failure,
‘1B’H External GNSS facility certificate expired,
‘1C’HInconsistency between motion data and stored driver activity data,
‘1D’H to ‘1F’HRFU,
‘2x’HSensor related security breach attempt events,
‘20’HNo further details,
‘21’HAuthentication failure,
‘22’HStored data integrity error,
‘23’HInternal data transfer error,
‘24’HUnauthorised case opening,
‘25’HHardware sabotage,
‘26’H to ‘2F’HRFU,
‘3x’H Recording equipment faults,
‘30’HNo further details,
‘31’HVU internal fault,
‘32’HPrinter fault,
‘33’HDisplay fault,
‘34’HDownloading fault,
‘35’HSensor fault,
‘36’HInternal GNSS receiver,
‘37’HExternal GNSS facility,
‘38’HRemote communication facility,
‘39’HITS interface,
‘3A’HInternal Sensor Fault,
‘3B’H to ‘3F’HRFU,
‘4x’HCard faults,
‘40’HNo further details,
‘41’H to ‘4F’HRFU,
‘50’H to ‘7F’HRFU,
‘80’H to ‘FF’HManufacturer specific.’;
(o)point 2.71 is replaced by the following:
‘2.71.
ExtendedSealIdentifier
Generation 2:
The extended seal identifier uniquely identifies a seal (Annex IC requirement 401).
|
ExtendedSealIdentifier ::= SEQUENCE{
manufacturerCode
IA5String (SIZE(2)),
sealIdentifier
IA5String (SIZE(8))
}
|
manufacturerCode is a code of the manufacturer of the seal. Value assignment: see database registration to be managed by the European Commission (see
https://dtc.jrc.ec.europa.eu
).
sealIdentifier is an identifier for the seal which is unique for the manufacturer. Value assignment: alpha-numeric number, unique in the manufacturer domain according to [ISO8859-1].’;
(p)in point 2.76, the paragraph between the header and the code is replaced by the following:
‘Generation 2:
The geo-coordinates are encoded as integers. These integers are multiples of the ±DDMM.M encoding for the latitude and ±DDDMM.M for the longitude. Here ±DD respectively ±DDD denotes the degrees and MM.M the minutes. Longitude and latitude of an unknown position shall be represented as Hex ‘7FFFFF’ (Decimal 8388607).’;
(q)the following points 2.79a, 2.79b and 2.79c are inserted:
‘2.79a.
GNSSAuthAccumulatedDriving
Generation 2, version 2:
Information, stored in a driver or workshop card, providing the authentication status of GNSS positions of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirements 306d and 356d).
|
GNSSAuthAccumulatedDriving ::= SEQUENCE {
gnssAuthADPointerNewestRecord
INTEGER(0..NoOfGNSSADRecords -1),
gnssAuthStatusADRecords
SET SIZE (NoOfGNSSADRecords) OF GNSSAuthStatusADRecord
}
|
gnssAuthADPointerNewestRecord is the index of the last updated GNSS position authentication status record.
Value assignment is the number corresponding to the numerator of the GNSS position authentication status record, beginning with '0' for the first occurrence of the GNSS position authentication status record in the structure.
gnssAuthStatusADRecords is the set of records containing the date and time the accumulated driving reaches a multiple of three hours and the authentication status of the GNSS position.
2.79b.
GNSSAuthStatusADRecord
Generation 2, version 2:
Information, stored in a driver or workshop card, providing the authentication status of a GNSS position of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirements 306c and 356c). Other information related to the GNSS position itself is stored in another record (see 2.79 GNSSAccumulatedDrivingRecord).
|
GNSSAuthStatusADRecord ::= SEQUENCE {
timeStamp
TimeReal,
authenticationStatus
PositionAuthenticationStatus
}
|
timeStamp is the date and time when the accumulated driving time reaches a multiple of three hours (which is the same date and time as in the corresponding GNSSAccumulatedDrivingRecord).
authenticationStatus is the authentication status of the GNSS position when the accumulated driving time reaches a multiple of three hours.
2.79c.
GNSSPlaceAuthRecord
Generation 2, version 2:
Information related to the GNSS position of the vehicle (Annex IC requirements 108, 109, 110, 296, 306a, 306c, 306e, 306g, 356a, 356c, 356e and 356g).
|
GNSSPlaceAuthRecord ::= SEQUENCE {
timeStamp
TimeReal,
gnssAccuracy
GNSSAccuracy,
geoCoordinates
GeoCoordinates,
authenticationStatus
PositionAuthenticationStatus
}
|
timeStamp is the date and time when the GNSS position of the vehicle was determined.
gnssAccuracy is the accuracy of the GNSS position data.
geoCoordinates is the recorded location using GNSS.
authenticationStatus is the authentication status of the GNSS position when it was determined.’;
(r)point 2.84 is replaced by the following:
‘2.84.
Reserved for future use’;
(s)the following point 2.89a is inserted:
‘2.89a.
LengthOfFollowingData
Generation 2, version 2:
Length indicator for extensible records.
|
LengthOfFollowingData ::= INTEGER(0.. 216-1)
|
Value assignment: See Appendix 2.’;
(t)the following point 2.90a is inserted:
‘2.90a.
LoadType
Generation 2, version 2:
Code identifying a load type entered.
|
LoadType ::= INTEGER(0..255)
|
Value assignment:
‘00’H
Undefined load type,
‘01’H
Goods,
‘02’H
Passengers,
‘03’H .. ‘FF’H
RFU.’;
(u)the following point 2.101a is inserted:
‘2.101a.
NoOfBorderCrossingRecords
Generation 2, version 2:
Number of border crossing records a driver or workshop card can store.
|
NoOfBorderCrossingRecords ::= INTEGER(0.. 216-1)
|
Value assignment: see Appendix 2.’;
(v)the following point 2.111a is inserted:
‘2.111a.
NoOfLoadUnloadRecords
Generation 2, version 2:
Number of load/unload records a card can store.
|
NoOfLoadUnloadRecords ::= INTEGER(0..216-1)
|
Value assignment: see Appendix 2.’;
(w)the following point 2.112a is inserted:
‘2.112a.
NoOfLoadTypeEntryRecords
Generation 2, version 2:
Number of load type entry records a driver or workshop card can store.
|
NoOfLoadTypeEntryRecords ::= INTEGER(0..216-1)
|
Value assignment: see Appendix 2.’;
(x)the following point 2.114a is inserted:
‘2.114a.
OperationType
Generation 2, version 2:
Code identifying a type of operation entered.
|
OperationType ::= INTEGER(0..255)
|
Value assignment:
‘00’H
RFU,
‘01’H
Load operation,
‘02’H
Unload operation,
‘03’H
Simultaneous load/unload operation,
‘04’H .. ‘FF’H
RFU.’;
(y)the following points 2.116a and 2.116b are inserted:
‘2.116a.
PlaceAuthRecord
Information related to a place where a daily work period begins or ends (Annex IC requirements 108, 271, 296, 324 and 347).
Generation 2, version 2:
|
PlaceAuthRecord ::= SEQUENCE {
entryTime
TimeReal,
entryTypeDailyWorkPeriod
EntryTypeDailyWorkPeriod,
dailyWorkPeriodCountry
NationNumeric,
dailyWorkPeriodRegion
RegionNumeric,
vehicleOdometerValue
OdometerShort,
entryGNSSPlaceAuthRecord
GNSSPlaceAuthRecord
}
|
entryTime is a date and time related to the entry.
entryTypeDailyWorkPeriod is the type of entry.
dailyWorkPeriodCountry is the country entered.
dailyWorkPeriodRegion is the region entered.
vehicleOdometerValue is the odometer value at the time of place entry.
entryGNSSPlaceAuthRecord is the recorded location, GNSS authentication status and time.
2.116b.
PlaceAuthStatusRecord
Generation 2, version 2:
Information, stored in a driver or workshop card, providing the authentication status of a place where a daily work period begins or ends (Annex IC requirements 306a and 356a). Other information related to the place itself is stored in another record (see 2.117 PlaceRecord).
|
PlaceAuthStatusRecord ::= SEQUENCE {
entryTimeTimeReal,
authenticationStatusPositionAuthenticationStatus
}
|
entryTime is a date and time related to the entry (which is the same date and time as in the corresponding PlaceRecord).
authenticationStatus is the authentication status of the recorded GNSS position.’;
(z)the following point 2.117a is inserted:
‘2.117a.
PositionAuthenticationStatus
Generation 2, version 2:
|
PositionAuthenticationStatus ::= INTEGER(0..255)
|
Value assignment (see Appendix 12):
‘00’H
Not Authenticated (see Appendix 12, requirement GNS_39),
‘01’H
Authenticated (see Appendix 12, requirement GNS_39),
‘02’H .. ‘FF’H
RFU.’;
(aa)in point 2.120, value assignments ‘22’H to ‘7F’H are replaced by the following:
‘‘22’H
VuBorderCrossingRecord,
‘23’H
VuLoadUnloadRecord,
‘24’H
VehicleRegistrationIdentification,
‘25’H to ‘7F’H
RFU.’;
(bb)the following point 2.158a is inserted:
‘2.158a.
TachographCardsGen1Suppression
Generation 2, version 2:
Ability of a second generation VU to use first generation of driver, control and company cards (see Appendix 15, MIG_002).
|
TachographCardsGen1Suppression ::= INTEGER (0..216-1)
|
Value assignment:
‘0000’H
The VU is able to use the generation 1 of tachograph cards (default value),
‘A5E3’H
The VU is not able to use the tachograph cards generation 1,
All other values
Not used.’;
(cc)the following point 2.166a is inserted:
‘2.166a.
VehicleRegistrationIdentificationRecordArray
Generation 2, version 2:
The Vehicle Registration Identification plus metadata as used in the download protocol.
|
VehicleRegistrationIdentificationRecordArray ::= SEQUENCE {
recordTypeRecordType,
recordSizeINTEGER(1..65535),
noOfRecordsINTEGER(0..65535),
recordsSET SIZE(noOfRecords) OF VehicleRegistrationIdentification
}
|
recordType denotes the type of the record (VehicleRegistrationIdentification). Value assignment: see RecordType.
recordSize is the size of the VehicleRegistrationIdentification in bytes.
noOfRecords is the number of records in the set records.
records is the set of vehicle registration identification.’;
(dd)in point 2.168, the first line after the header is replaced by the following:
‘Generation 2, version 1:’;
(ee)point 2.174 is amended as follows:
(i)the header for Generation 2 is replaced by the following:
‘Generation 2, version 1:’;
(ii)the following text is added:
‘Generation 2, version 2:
|
VuCalibrationRecord ::= SEQUENCE {
calibrationPurposeCalibrationPurpose,
workshopNameName,
workshopAddressAddress,
workshopCardNumberFullCardNumber,
workshopCardExpiryDateTimeReal,
vehicleIdentificationNumberVehicleIdentificationNumber,
vehicleRegistrationIdentificationVehicleRegistrationIdentification,
wVehicleCharacteristicConstantW-VehicleCharacteristicConstant,
kConstantOfRecordingEquipmentK-ConstantOfRecordingEquipment,
lTyreCircumferenceL-TyreCircumference,
tyreSizeTyreSize,
authorisedSpeedSpeedAuthorised,
oldOdometerValueOdometerShort,
newOdometerValueOdometerShort,
oldTimeValueTimeReal,
newTimeValueTimeReal,
nextCalibrationDateTimeReal,
sensorSerialNumberSensorSerialNumber,
sensorGNSSSerialNumberSensorGNSSSerialNumber,
rcmSerialNumberRemoteCommunicationModuleSerialNumber,
sealDataVuSealDataVu,
byDefaultLoadTypeLoadType,
calibrationCountryNationNumeric,
calibrationCountryTimestampTimeReal
}
|
In addition to generation 1 the following data element is used:
sensorSerialNumber is the serial number of the motion sensor paired with the vehicle unit at the end of the calibration,
sensorGNSSSerialNumber is the serial number of the external GNSS facility coupled with the vehicle unit at the end of the calibration (if any),
rcmSerialNumber is the serial number of the remote communication facility coupled with the vehicle unit at the end of the calibration (if any),
sealDataVu gives information about the seals that are attached to different components of the vehicle.
byDefaultLoadType is the by-default load type of the vehicle (only present in version 2).
calibrationCountry is the country in which the calibration has been performed.
calibrationCountryTimestamp is the date and time when the position used to determine the country in which the calibration has been performed was provided by the GNSS receiver.’;
(ff)the following point 2.185a is inserted:
‘2.185a.
VuConfigurationLengthRange
Generation 2, version 2:
Number of bytes in a tachograph card, available to store VU configurations.
|
VuConfigurationLengthRange ::= INTEGER(0..216-1)
|
Value assignment: see Appendix 2.’;
(gg)the following point 2.192a is inserted:
‘2.192a.
VuDigitalMapVersion
Generation 2, version 2:
Version of the digital map stored in the vehicle unit (Annex IC requirement 133j).
|
VuDigitalMapVersion ::= IA5String(SIZE(12))
|
Value assignment: as specified on the dedicated secured website made available by the European Commission (Annex IC requirement 133k).’;
(hh)point 2.203 is amended as follows:
(i)the header corresponding to Generation 2 is replaced by the following:
‘Generation 2, version 1:’;
(ii)the following text is added:
‘Generation 2, version 2:
Information, stored in a vehicle unit, related to the GNSS position of the vehicle if the accumulated driving time reaches a multiple of three hours (Annex IC requirement 108, 110).
|
VuGNSSADRecord ::= SEQUENCE {
timestamp
TimeReal,
cardNumberAndGenDriverSlot
FullCardNumberAndGeneration,
cardNumberAndGenCodriverSlot
FullCardNumberAndGeneration,
gnssPlaceAuthRecord
GNSSPlaceAuthRecord,
vehicleOdometerValue
OdometerShort
}
|
In Generation 2 version 2, instead of gnssPlaceRecord, the gnssPlaceAuthRecord is used, which contains the GNSS authentication status in addition.’;
(ii)the following points 2.203a and 2.203b are inserted:
‘2.203a.
VuBorderCrossingRecord
Generation 2, version 2:
Information, stored in a vehicle unit, related to border crossings of the vehicle when the latter has crossed the border of a country (Annex IC requirement 133a and 133b).
|
VuBorderCrossingRecord ::= SEQUENCE {
cardNumberAndGenDriverSlotFullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotFullCardNumberAndGeneration,
countryLeftNationNumeric,
countryEnteredNationNumeric,
gnssPlaceAuthRecordGNSSPlaceAuthRecord,
vehicleOdometerValueOdometerShort
}
|
cardNumberAndGenDriverSlot identifies the card including its generation which is inserted in the driver slot.
cardNumberAndGenCodriverSlot identifies the card including its generation which is inserted in the co-driver slot.
countryLeft is the country which was left by the vehicle, based on the last available position before the border crossing has been detected. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps).
countryEntered is the country into which the vehicle has entered. ‘Rest of the World’ (NationNumeric code ‘FF’H) shall be used when the vehicle unit is not able to determine the country where the vehicle is located (e.g. the current country is not part of the stored digital maps).
gnssPlaceAuthRecord contains information related to the position of the vehicle when the border crossing was detected, and its authentication status.
vehicleOdometerValue is the odometer value when the vehicle unit has detected that the vehicle has crossed the border of a country.
2.203b.
VuBorderCrossingRecordArray
Generation 2, version 2:
Information, stored in a vehicle unit, related to border crossings of the vehicle (Annex IC requirement 133c).
|
VuBorderCrossingRecordArray ::= SEQUENCE {
recordTypeRecordType,
recordSizeINTEGER(1..65535),
noOfRecordsINTEGER(0..65535),
recordsSET SIZE(noOfRecords) OF VuBorderCrossingRecord
}
|
recordType denotes the type of the record (VuBorderCrossingRecord). Value assignment: see RecordType.
recordSize is the size of the VuBorderCrossingRecord in bytes.
noOfRecords is the number of records in the set records.
records is a set of border crossing records.’;
(jj)the following point 2.204a is inserted:
‘2.204a.
VuGnssMaximalTimeDifference
Generation 2, version 2:
The maximal difference between true time and the VU Real Time Clock time, based on the maximal time drift specified in Annex IC requirement 041, transmitted by the vehicle unit to an external GNSS Facility, see Appendix 12 requirement GNS_3g.
|
VuGnssMaximalTimeDifference ::= INTEGER(0..65535)
|
’;
(kk)in point 2.205, the text corresponding to Generation 2 is replaced by the following:
‘Generation 2:
|
VuIdentification ::= SEQUENCE {
vuManufacturerNameVuManufacturerName,
vuManufacturerAddressVuManufacturerAddress,
vuPartNumberVuPartNumber,
vuSerialNumberVuSerialNumber,
vuSoftwareIdentificationVuSoftwareIdentification,
vuManufacturingDateVuManufacturingDate,
vuApprovalNumberVuApprovalNumber,
vuGenerationGeneration,
vuAbilityVuAbility,
vuDigitalMapVersionVuDigitalMapVersion
}
|
In addition to generation 1 the following data elements are used:
vuGeneration identifies the generation of the vehicle unit.
vuAbility provides information whether the VU supports generation 1 tachograph cards or not.
vuDigitalMapVersion is the version of the digital map stored in the vehicle unit (only present in version 2).’;
(ll)the following points 2.208a and 2.208b are inserted:
‘2.208a.
VuLoadUnloadRecord
Generation 2, version 2:
Information, stored in the vehicle unit, related to a load/unload operation entered (Annex IC requirements 133e, 133f and 133g).
|
VuLoadUnloadRecord ::= SEQUENCE {
timeStampTimeReal,
operationTypeOperationType
cardNumberAndGenDriverSlotFullCardNumberAndGeneration,
cardNumberAndGenCodriverSlotFullCardNumberAndGeneration,
gnssPlaceAuthRecordGNSSPlaceAuthRecord,
vehicleOdometerValueOdometerShort
}
|
timeStamp is the date and time when the load/unload operation was entered.
operationType is the type of the operation entered (load, unload, or simultaneous load/unload).
cardNumberAndGenDriverSlot identifies the card including its generation which is inserted in the driver slot.
cardNumberAndGenCodriverSlot identifies the card including its generation which is inserted in the co-driver slot.
gnssPlaceAuthRecord contains information related to the position of the vehicle, and its authentication status.
vehicleOdometerValue is the odometer value related to the load/unload operation.
2.208b.
VuLoadUnloadRecordArray
Generation 2, version 2:
Information, stored in a vehicle unit, related to a load/unload operation vehicle entered (Annex IC requirement 133h).
|
VuLoadUnloadRecordArray ::= SEQUENCE {
recordTypeRecordType,
recordSizeINTEGER(1..65535),
noOfRecordsINTEGER(0..65535),
recordsSET SIZE(noOfRecords) OF VuLoadUnloadRecord
}
|
recordType denotes the type of the record (VuLoadUnloadRecord).Value Assignment: See RecordType.
recordSize is the size of the VuLoadUnloadRecord in bytes.
noOfRecords is the number of records in the set records.
records is a set of load/unload operation records.’;
(mm)point 2.219 is amended as follows:
(i)the header for Generation 2 is replaced by the following:
‘Generation 2, version 1:’;
(ii)the following text is added:
‘Generation 2, version 2:
Information, stored in a vehicle unit, related to a place where a driver begins or ends a daily work period (Annex 1B requirement 087 and Annex 1C requirement 108 and 110).
|
VuPlaceDailyWorkPeriodRecord ::= SEQUENCE {
fullCardNumberAndGeneration
FullCardNumberAndGeneration,
placeAuthRecord
PlaceAuthRecord
}
|
Instead of placeRecord, the generation 2 version 2 data structure makes use of the following data element:
placeAuthRecord contains the information related to the place entered, the recorded position, GNSS authentication status and position determination time.’;
(nn)the following point is inserted after point 2.222:
‘2.222a.
VuRtcTime
Generation 2, version 2:
The time of the VU RTC clock, transmitted by the VU to an External GNSS Facility, see Appendix 12 requirement GNS_3f.
’;
(oo)the following points 2.234a, 2.234b and 2.234c are inserted:
‘2.234a.
WorkshopCardApplicationIdentificationV2
Generation 2, version 2:
Information, stored in a workshop card related to the identification of the application of the card (Annex IC requirement 330a).
|
WorkshopCardApplicationIdentificationV2 ::= SEQUENCE {
lengthOfFollowingDataLengthOfFollowingData,
noOfBorderCrossingRecordsNoOfBorderCrossingRecords,
noOfLoadUnloadRecordsNoOfLoadUnloadRecords,
noOfLoadTypeEntryRecordsNoOfLoadTypeEntryRecords,
vuConfigurationLengthRangeVuConfigurationLengthRange
}
|
lengthOfFollowingData is the number of bytes following in the record.
noOfBorderCrossingRecords is the number of border crossing records the workshop card can store.
noOfLoadUnloadRecords is the number of load/unload records the workshop card can store.
noOfLoadTypeEntryRecords is the number of load type entry records the workshop card can store.
vuConfigurationLengthRange is the number of bytes in a tachograph card, available to store VU configurations.
2.234b.
WorkshopCardCalibrationAddData
Generation 2, version 2:
Information, stored in a workshop card, related to the additional data (i.e. by-default load type) entered during a calibration (Annex IC requirement 356l).
|
WorkshopCardCalibrationAddData ::= SEQUENCE {
calibrationPointerNewestRecordINTEGER(0..NoOfCalibrationRecords -1),
workshopCardCalibrationAddDataRecordsSET SIZE(NoOfCalibrationRecords) OF WorkshopCardCalibrationAddDataRecord
}
|
calibrationPointerNewestRecord is the index of the last updated calibration additional data record.
Value assignment is the number corresponding to the numerator of the calibration additional data record, beginning with '0' for the first occurrence of the calibration additional data record in the structure.
workshopCardCalibrationAddDataRecords is the set of records containing the old date and time value, the vehicle identification value and the by-default load type of the vehicle.
2.234c.
WorkshopCardCalibrationAddDataRecord
Generation 2, version 2:
Information, stored in a workshop card, related to the by-default load type entered during a calibration (Annex IC requirement 356k).
|
WorkshopCardCalibrationAddDataRecord ::= SEQUENCE {
oldTimeValueTimeReal,
vehicleIdentificationNumberVehicleIdentificationNumber,
byDefaultLoadTypeLoadType,
calibrationCountryNationNumeric,
calibrationCountryTimestampTimeReal
}
|
oldTimeValue is the old value of date and time contained in the corresponding WorkshopCardCalibrationRecord,
vehicleIdentificationNumber is the vehicle identification number of the vehicle, also contained in the corresponding WorkshopCardCalibrationRecord,
byDefaultLoadType is the by-default load type of the vehicle (only present in version 2).
calibrationCountry is the country in which the calibration has been performed,
calibrationCountryTimestamp is the date time when the position used to determine this country was provided by the GNSS receiver.’;
(31)Appendix 2 is amended as follows:
(a)in point 2.5, the second sub-paragraph in paragraph TCS_09 is replaced by the following:
‘Operation state while executing commands or interfacing with Vehicle Unit,’;
(b)point 3 is amended as follows:
(i)in point 3.2.1, the fourth indent in paragraph TCS_16 is deleted.
(ii)point 3.5.7.2 is amended as follows:
(1)
paragraph TCS_86 is replaced by the following:
‘TCS_86
The command can be performed in the MF, DF Tachograph and DF Tachograph_G2, see also TCS_34.’;
(2)
paragraphs TCS_88 and TCS_89 are replaced by the following:
‘TCS_88
For short length APDUs the following provisions apply: the IFD shall use the minimum number of APDUs required to transmit the command payload and transmit the maximum number of bytes in the first command APDU. However any value of ‘Lc’ up to 255 bytes must be supported by the card.
TCS_89
For extended length APDUs the following provisions apply: if the certificate does not fit into a single APDU, the card shall support command chaining. The IFD shall use the minimum number of APDUs required to transmit the command payload and transmit the maximum number of bytes in the first command APDU. If chaining is needed, any value of ‘Lc’ up to the maximum extended length size indicated must be supported by the card.
Note: According to Appendix 11 the card stores the certificate or the relevant contents of the certificate and updates its currentAuthenticatedTime.
The response message structure and status words are as defined in TCS_85.’;
(iii)in point 3.5.10, the last row of the table in paragraph TCS_101 is replaced by the following:
‘
|
Le
|
1
|
‘00h’
|
As specified in ISO/IEC 7816-4
|
’;
(iv)in point 3.5.16, the last row of the table in paragraph TCS_138 is replaced by the following:
‘
|
Le
|
1
|
‘00h’
|
As specified in ISO/IEC 7816-4
|
’;
(c)point 4 is amended as follows:
(i)in paragraph TCS_141, the second subparagraph is replaced by the following:
‘The maximum and minimum numbers of records are specified in this chapter for the different applications. In version 2 of generation 2 driver and workshop cards, the generation 1 application shall support the maximum number of records specified in TCS_150 and TCS_158.’;
(ii)in point 4.2.1, the table in paragraph TCS_150 is amended as follows:
(1)the row corresponding to cardIssuingAuthorityName is replaced by the following:
‘
|
|
|
|
|
|
|
|
cardIssuingAuthorityName
|
|
36
|
36
|
{00,20..20}
|
’;
(2)the row corresponding to LastCardDownload is replaced by the following:
‘
|
|
|
|
|
|
|
LastCardDownload
|
|
4
|
4
|
{00..00}
|
’;
(iii)point 4.2.2 is amended as follows:
(1)paragraph TCS_152 is replaced by the following:
‘TCS_152
After its personalisation, the driver card application generation 2 shall have the following permanent file structure and file access rules:
Notes:
-
The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary.
-
EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration and EF Load_Type_Entries are only present in version 2 of the generation 2 driver card.
-
cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 driver card, while it was equal to {01 00} for version 1 of the generation 2 driver card.
|
|
|
Access rules
|
|
File
|
File ID
|
SFID
|
Read / Select
|
Update
|
|
|
|
DF
|
Tachograph_G2
|
|
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Application_Identification
|
‘0501h’
|
1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
CardSignCertificate
|
‘C101h’
|
3
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
CA_Certificate
|
‘C108h’
|
4
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Link_Certificate
|
‘C109h’
|
5
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Identification
|
‘0520h’
|
6
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Card_Download
|
‘050Eh’
|
7
|
SC1
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Driving_Licence_Info
|
‘0521h’
|
10
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Events_Data
|
‘0502h’
|
12
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Faults_Data
|
‘0503h’
|
13
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Driver_Activity_Data
|
‘0504h’
|
14
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Vehicles_Used
|
‘0505h’
|
15
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Places
|
‘0506h’
|
16
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Current_Usage
|
‘0507h’
|
17
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Control_Activity_Data
|
‘0508h’
|
18
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Specific_Conditions
|
‘0522h’
|
19
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
VehicleUnits_Used
|
‘0523h’
|
20
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
GNSS_Places
|
‘0524h’
|
21
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Places_Authentication
|
‘0526h’
|
23
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF GNSS_Places_Authentication
|
‘0527h’
|
24
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Border_Crossings
|
‘0528h’
|
25
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Load_Unload_Operations
|
‘0529h’
|
26
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF
|
Load_Type_Entries
|
‘0530h’
|
27
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Vu_Configuration
|
‘0540h’
|
30
|
SC5/SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
The following abbreviations for the security condition are used in this table:
SC1
ALW OR SM-MAC-G2
SC5
For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported): NEV’;
(2)paragraph TCS_154 is replaced by the following:
‘TCS_154
The driver card application generation 2 shall have the following data structure:
|
File / Data Element
|
|
|
|
|
No of Records
|
Size (bytes)
Min Max
|
Default Values
|
|
DF Tachograph_G2
|
|
|
|
|
|
98300
|
98848
|
|
|
|
EF Application_Identification
|
|
|
17
|
17
|
|
|
|
|
DriverCardApplicationIdentification
|
|
17
|
17
|
|
|
|
|
|
typeOfTachographCardId
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
|
2
|
2
|
{01 01}
|
|
|
|
|
noOfEventsPerType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
noOfFaultsPerType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
activityStructureLength
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardPlaceRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfGNSSADRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfSpecificConditionRecords
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleUnitRecords
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
204
|
341
|
{00..00}
|
|
|
EF CardSignCertificate
|
|
|
|
204
|
341
|
|
|
|
|
CardSignCertificate
|
|
|
|
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 Identification
|
|
|
|
|
143
|
143
|
|
|
|
|
CardIdentification
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
4
|
4
|
{00..00}
|
|
|
|
DriverCardHolderIdentification
|
|
|
78
|
78
|
|
|
|
|
|
cardHolderName
|
|
|
72
|
72
|
|
|
|
|
|
|
holderSurname
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
holderFirstNames
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderBirthDate
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Card_Download
|
|
|
|
|
4
|
4
|
|
|
|
|
|
LastCardDownload
|
|
|
4
|
4
|
{00..00}
|
|
|
EF Driving_Licence_Info
|
|
|
|
53
|
53
|
|
|
|
|
|
CardDrivingLicenceInformation
|
|
53
|
53
|
|
|
|
|
|
|
drivingLicenceIssuingAuthority
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
drivingLicenceIssuingNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
drivingLicenceNumber
|
|
|
16
|
16
|
{20..20}
|
|
|
EF Events_Data
|
|
|
|
|
3168
|
3168
|
|
|
|
|
CardEventData
|
|
|
|
|
3168
|
3168
|
|
|
|
|
|
cardEventRecords
|
|
11
|
288
|
288
|
|
|
|
|
|
|
CardEventRecord
|
|
n1
|
24
|
24
|
|
|
|
|
|
|
|
eventType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
eventBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Faults_Data
|
|
|
|
|
1152
|
1152
|
|
|
|
|
CardFaultData
|
|
|
|
|
1152
|
1152
|
|
|
|
|
|
cardFaultRecords
|
|
2
|
576
|
576
|
|
|
|
|
|
|
CardFaultRecord
|
|
n2
|
24
|
24
|
|
|
|
|
|
|
|
faultType
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
faultBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Driver_Activity_Data
|
|
|
|
13780
|
13780
|
|
|
|
|
CardDriverActivity
|
|
|
|
13780
|
13780
|
|
|
|
|
|
activityPointerOldestDayRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityDailyRecords
|
|
n6
|
13776
|
13776
|
{00..00}
|
|
|
EF Vehicles_Used
|
|
|
|
|
9602
|
9602
|
|
|
|
|
CardVehiclesUsed
|
|
|
|
9602
|
9602
|
|
|
|
|
|
vehiclePointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleRecords
|
|
|
9600
|
9600
|
|
|
|
|
|
|
cardVehicleRecord
|
|
n3
|
48
|
48
|
|
|
|
|
|
|
|
vehicleOdometerBegin
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleOdometerEnd
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleFirstUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleLastUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
vuDataBlockCounter
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
EF Places
|
|
|
|
|
|
2354
|
2354
|
|
|
|
|
CardPlaceDailyWorkPeriod
|
|
|
2354
|
2354
|
|
|
|
|
|
placePointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeRecords
|
|
|
|
2352
|
2352
|
|
|
|
|
|
|
PlaceRecord
|
|
n4
|
21
|
21
|
|
|
|
|
|
|
|
entryTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
entryTypeDailyWorkPeriod
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodCountry
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodRegion
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
entryGNSSPlaceRecord
|
|
11
|
11
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
EF Current_Usage
|
|
|
|
|
19
|
19
|
|
|
|
|
CardCurrentUse
|
|
|
|
|
19
|
19
|
|
|
|
|
|
sessionOpenTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
sessionOpenVehicle
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Control_Activity_Data
|
|
|
|
46
|
46
|
|
|
|
|
CardControlActivityDataRecord
|
|
|
46
|
46
|
|
|
|
|
|
controlType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
controlTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlCardNumber
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardNumber
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
controlVehicleRegistration
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
controlDownloadPeriodBegin
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlDownloadPeriodEnd
|
|
|
4
|
4
|
{00..00}
|
|
|
EF Specific_Conditions
|
|
|
|
562
|
562
|
|
|
|
|
SpecificConditions
|
|
|
|
562
|
562
|
|
|
|
|
|
conditionPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
specificConditionRecords
|
|
|
560
|
560
|
|
|
|
|
|
|
SpecificConditionRecord
|
n9
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
specificConditionType
|
|
1
|
1
|
{00}
|
|
|
EF VehicleUnits_Used
|
|
|
|
2002
|
2002
|
|
|
|
|
CardVehicleUnitsUsed
|
|
|
2002
|
2002
|
|
|
|
|
|
vehicleUnitPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleUnitRecords
|
|
|
2000
|
2000
|
|
|
|
|
|
|
CardVehicleUnitRecord
|
n7
|
10
|
10
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
manufacturerCode
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
deviceID
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vuSoftwareVersion
|
|
4
|
4
|
{00..00}
|
|
|
EF GNSS_Places
|
|
|
|
|
6050
|
6050
|
|
|
|
|
GNSSAccumulatedDriving
|
|
|
6050
|
6050
|
|
|
|
|
|
gnssADPointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAccumulatedDrivingRecords
|
|
6048
|
6048
|
|
|
|
|
|
|
GNSSAccumulatedDrivingRecord
|
n8
|
18
|
18
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceRecord
|
|
|
14
|
14
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Application_Identification_V2
|
|
|
10
|
10
|
|
|
|
|
DriverCardApplicationIdentificationV2
|
|
10
|
10
|
|
|
|
|
|
lengthOfFollowingData
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfBorderCrossingRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadUnloadRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadTypeEntryRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
|
2
|
2
|
{00 00}
|
|
|
EF Places_Authentication
|
|
|
562
|
562
|
|
|
|
|
CardPlaceAuthDailyWorkPeriod
|
|
562
|
562
|
|
|
|
|
|
placeAuthPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeAuthStatusRecords
|
|
|
560
|
560
|
|
|
|
|
|
|
PlaceAuthStatusRecord
|
n4
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF GNSS_Places_Authentication
|
|
|
1682
|
1682
|
|
|
|
|
GNSSAuthAccumulatedDriving
|
|
|
1682
|
1682
|
|
|
|
|
|
gnssAuthADPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAuthStatusADRecords
|
|
1680
|
1680
|
|
|
|
|
|
|
GNSSAuthStatusADRecord
|
n8
|
5
|
5
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF Border_Crossings
|
|
|
|
19042
|
19042
|
|
|
|
|
CardBorderCrossings
|
|
|
|
19042
|
19042
|
|
|
|
|
|
borderCrossingPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardBorderCrossingRecords
|
|
|
19040
|
19040
|
|
|
|
|
|
|
CardBorderCrossingRecord
|
n10
|
17
|
17
|
|
|
|
|
|
|
|
countryLeft
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
countryEntered
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Unload_Operations
|
|
|
32482
|
32482
|
|
|
|
|
CardLoadUnloadOperations
|
|
|
32482
|
32482
|
|
|
|
|
|
loadUnloadPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardloadUnloadRecords
|
|
|
32480
|
32480
|
|
|
|
|
|
|
CardLoadUnloadRecord
|
|
n11
|
20
|
20
|
|
|
|
|
|
|
|
timestamp
|
|
|
4
|
4
|
{00}
|
|
|
|
|
|
|
operationType
|
|
|
1
|
1
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Type_Entries
|
|
|
1682
|
1682
|
|
|
|
|
CardLoadTypeEntries
|
|
|
1682
|
1682
|
|
|
|
|
|
loadtypeEntryPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardLoadTypeEntryRecords
|
|
1680
|
1680
|
|
|
|
|
|
|
CardLoadTypeEntryRecord
|
n12
|
5
|
5
|
|
|
|
|
|
|
|
timestamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
loadTypeEntered
|
|
|
1
|
1
|
{00}
|
|
|
EF VU_Configuration
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
n13
|
3072
|
3072
|
|
’;
(3)in paragraph TCS_155, the table is replaced by the following:
‘
|
|
|
Min
|
Max
|
|
n1
|
|
|
12
|
|
n2
|
NoOfFaultsPerType
|
24
|
24
|
|
n3
|
NoOfCardVehicleRecords
|
200
|
200
|
|
n4
|
NoOfCardPlaceRecords
|
112
|
112
|
|
n6
|
CardActivityLengthRange
|
13776 Bytes
(56 days * 117 activity changes)
|
13776 Bytes
(56 days * 117 activity changes)
|
|
n7
|
NoOfCardVehicleUnitRecords
|
200
|
200
|
|
n8
|
NoOfGNSSADRecords
|
336
|
336
|
|
n9
|
NoOfSpecificConditionRecords
|
112
|
112
|
|
n10
|
NoOfBorderCrossingRecords
|
1120
|
1120
|
|
n11
|
NoOfLoadUnloadRecords
|
1624
|
1624
|
|
n12
|
NoOfLoadTypeEntryRecords
|
336
|
336
|
|
n13
|
VuConfigurationLengthRange
|
3072 Bytes
|
3072 Bytes
|
’;
(iv)point 4.3.2 is amended as follows:
(1)paragraph TCS_160 is replaced by the following:
‘TCS_160
After its personalisation, the workshop card application generation 2 shall have the following permanent file structure and file access rules.
Notes:
-
The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary.
-
EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration and EF Calibration_Add_Data are only present in version 2 of the generation 2 workshop card.
-
cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 workshop card, while it was equal to {01 00} for version 1 of the generation 2 workshop card.
|
|
|
|
Access rules
|
|
File
|
File ID
|
SFID
|
Read
|
Select
|
Update
|
|
|
|
DF Tachograph_G2
|
|
|
SC1
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification
|
‘0501h’
|
1
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardSignCertificate
|
‘C101h’
|
3
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CA_Certificate
|
‘C108h’
|
4
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Link_Certificate
|
‘C109h’
|
5
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Identification
|
‘0520h’
|
6
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Card_Download
|
‘0509h’
|
7
|
SC1
|
SC1
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Calibration
|
‘050Ah’
|
10
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Sensor_Installation_Data
|
‘050Bh’
|
11
|
SC5
|
SM-MAC-G2
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Events_Data
|
‘0502h’
|
12
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Faults_Data
|
‘0503h’
|
13
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Driver_Activity_Data
|
‘0504h’
|
14
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Vehicles_Used
|
‘0505h’
|
15
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Places
|
‘0506h’
|
16
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Current_Usage
|
‘0507h’
|
17
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Control_Activity_Data
|
‘0508h’
|
18
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Specific_Conditions
|
‘0522h’
|
19
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VehicleUnits_Used
|
‘0523h’
|
20
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF GNSS_Places
|
‘0524h’
|
21
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Places_Authentication
|
‘0526h’
|
23
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF GNSS_Places_Authentication
|
‘0527h’
|
24
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Border_Crossings
|
‘0528h’
|
25
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Load_Unload_Operations
|
‘0529h’
|
26
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Load_Type_Entries
|
‘0530h’
|
27
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Calibration_Add_Data
|
‘0531h’
|
28
|
SC1
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VU_Configuration
|
‘0540h’
|
30
|
SC5
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
The following abbreviations for the security conditions are used in this table:
SC1
ALW OR SM-MAC-G2
SC5
For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported):
NEV’;
(2)in paragraph TCS_162, the table is replaced by the following:
‘
|
File / Data Element
|
|
|
|
|
|
No of Records
|
Size (bytes)
Min Max
|
Default Values
|
|
DF Tachograph_G2
|
|
|
|
|
|
|
59582
|
60214
|
|
|
|
EF Application_Identification
|
|
|
|
19
|
19
|
|
|
|
|
WorkshopCardApplicationIdentification
|
|
19
|
19
|
|
|
|
|
|
typeOfTachographCardId
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
|
|
2
|
2
|
{01 01}
|
|
|
|
|
noOfEventsPerType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
noOfFaultsPerType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
activityStructureLength
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardPlaceRecords
|
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCalibrationRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfGNSSADRecords
|
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfSpecificConditionRecords
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfCardVehicleUnitRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
|
204
|
341
|
{00..00}
|
|
|
EF CardSignCertificate
|
|
|
|
|
204
|
341
|
|
|
|
|
CardSignCertificate
|
|
|
|
|
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 Identification
|
|
|
|
|
|
211
|
211
|
|
|
|
|
CardIdentification
|
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
WorkshopCardHolderIdentification
|
|
146
|
146
|
|
|
|
|
|
workshopName
|
|
|
|
|
36
|
36
|
|
|
|
|
|
workshopAddress
|
|
|
|
36
|
36
|
|
|
|
|
|
cardHolderName
|
|
|
|
|
72
|
72
|
|
|
|
|
|
|
holderSurname
|
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
holderFirstNames
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Card_Download
|
|
|
|
|
|
2
|
2
|
|
|
|
|
NoOfCalibrationsSinceDownload
|
|
|
2
|
2
|
{00 00}
|
|
|
EF Calibration
|
|
|
|
|
|
45394
|
45394
|
|
|
|
|
WorkshopCardCalibrationData
|
|
|
45394
|
45394
|
|
|
|
|
|
calibrationTotalNumber
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
calibrationPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
calibrationRecords
|
|
|
|
45390
|
45390
|
|
|
|
|
|
|
WorkshopCardCalibrationRecord
|
n5
|
178
|
178
|
|
|
|
|
|
|
|
calibrationPurpose
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
|
|
|
|
vehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
wVehicleCharacteristicConstant
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
kConstantOfRecordingEquipment
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
lTyreCircumference
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
tyreSize
|
|
|
|
15
|
15
|
{20..20}
|
|
|
|
|
|
|
authorisedSpeed
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
oldOdometerValue
|
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
newOdometerValue
|
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
oldTimeValue
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
newTimeValue
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
nextCalibrationDate
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vuPartNumber
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
|
|
vuSerialNumber
|
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
sensorSerialNumber
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
sensorGNSSSerialNumber
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
rcmSerialNumber
|
|
|
8
|
8
|
{00..00}
|
|
|
|
|
|
|
vuAbility
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
sealDataCard
|
|
|
56
|
56
|
|
|
|
|
|
|
|
|
noOfSealRecords
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
SealRecords
|
|
55
|
55
|
|
|
|
|
|
|
|
|
|
SealRecord
|
5
|
11
|
11
|
|
|
|
|
|
|
|
|
|
|
equipmentType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
|
|
extendedSealIdentifier
|
10
|
10
|
{00..00}
|
|
|
EF Sensor_Installation_Data
|
|
|
|
18
|
102
|
|
|
|
|
SensorInstallationSecData
|
|
|
|
18
|
102
|
{00..00}
|
|
|
EF Events_Data
|
|
|
|
|
|
792
|
792
|
|
|
|
|
CardEventData
|
|
|
|
|
|
792
|
792
|
|
|
|
|
|
cardEventRecords
|
|
|
11
|
72
|
72
|
|
|
|
|
|
|
CardEventRecord
|
|
|
n1
|
24
|
24
|
|
|
|
|
|
|
|
eventType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
eventBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
eventVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Faults_Data
|
|
|
|
|
|
288
|
288
|
|
|
|
|
CardFaultData
|
|
|
|
|
|
288
|
288
|
|
|
|
|
|
cardFaultRecords
|
|
|
2
|
144
|
144
|
|
|
|
|
|
|
CardFaultRecord
|
|
|
n2
|
24
|
24
|
|
|
|
|
|
|
|
faultType
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
faultBeginTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultEndTime
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
faultVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Driver_Activity_Data
|
|
|
|
|
496
|
496
|
|
|
|
|
CardDriverActivity
|
|
|
|
|
496
|
496
|
|
|
|
|
|
activityPointerOldestDayRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
activityDailyRecords
|
|
|
n6
|
492
|
492
|
{00..00}
|
|
|
EF Vehicles_Used
|
|
|
|
|
|
386
|
386
|
|
|
|
|
CardVehiclesUsed
|
|
|
|
|
386
|
386
|
|
|
|
|
|
vehiclePointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleRecords
|
|
|
|
384
|
384
|
|
|
|
|
|
|
cardVehicleRecord
|
|
n3
|
48
|
48
|
|
|
|
|
|
|
|
vehicleOdometerBegin
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleOdometerEnd
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
vehicleFirstUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleLastUse
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
vuDataBlockCounter
|
|
2
|
2
|
{00 00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
EF Places
|
|
|
|
|
|
|
170
|
170
|
|
|
|
|
CardPlaceDailyWorkPeriod
|
|
|
|
170
|
170
|
|
|
|
|
|
placePointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeRecords
|
|
|
|
|
168
|
168
|
|
|
|
|
|
|
PlaceRecord
|
|
|
n4
|
21
|
21
|
|
|
|
|
|
|
|
entryTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
entryTypeDailyWorkPeriod
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodCountry
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
dailyWorkPeriodRegion
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
|
|
|
|
entryGNSSPlaceRecord
|
|
11
|
11
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
EF Current_Usage
|
|
|
|
|
|
19
|
19
|
|
|
|
|
CardCurrentUse
|
|
|
|
|
|
19
|
19
|
|
|
|
|
|
sessionOpenTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
sessionOpenVehicle
|
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
EF Control_Activity_Data
|
|
|
|
|
46
|
46
|
|
|
|
|
CardControlActivityDataRecord
|
|
|
46
|
46
|
|
|
|
|
|
controlType
|
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
controlTime
|
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlCardNumber
|
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
controlVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
|
1
|
1
|
{00}
|
|
|
|
|
|
vehicleRegistrationNumber
|
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
controlDownloadPeriodBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
controlDownloadPeriodEnd
|
|
|
4
|
4
|
{00..00}
|
|
|
EF VehicleUnits_Used
|
|
|
|
|
82
|
82
|
|
|
|
|
CardVehicleUnitsUsed
|
|
|
|
82
|
82
|
|
|
|
|
|
vehicleUnitPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardVehicleUnitRecords
|
|
|
80
|
80
|
|
|
|
|
|
|
CardVehicleUnitRecord
|
n7
|
10
|
10
|
|
|
|
|
|
|
|
timeStamp
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
manufacturerCode
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
deviceID
|
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vuSoftwareVersion
|
|
4
|
4
|
{00..00}
|
|
|
EF GNSS_Places
|
|
|
|
|
|
434
|
434
|
|
|
|
|
GNSSAccumulatedDriving
|
|
|
|
434
|
434
|
|
|
|
|
|
gnssADPointerNewestRecord
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAccumulatedDrivingRecords
|
|
432
|
432
|
|
|
|
|
|
|
GNSSAccumulatedDrivingRecord
|
n8
|
18
|
18
|
|
|
|
|
|
|
|
timeStamp
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceRecord
|
|
|
14
|
14
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Specific_Conditions
|
|
|
|
|
22
|
22
|
|
|
|
|
SpecificConditions
|
|
|
|
|
22
|
22
|
|
|
|
|
|
conditionPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
specificConditionRecords
|
|
|
20
|
20
|
|
|
|
|
|
|
SpecificConditionRecord
|
n9
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
specificConditionType
|
|
1
|
1
|
{00}
|
|
|
EF Application_Identification_V2
|
|
|
10
|
10
|
|
|
|
|
WorkshopCardApplicationIdentificationV2
|
|
10
|
10
|
|
|
|
|
|
LengthOfFollowingData
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfBorderCrossingRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadUnloadRecords
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
noOfLoadTypeEntryRecords
|
|
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
|
|
2
|
2
|
{00 00}
|
|
|
EF Places_Authentication
|
|
|
|
42
|
42
|
|
|
|
|
CardPlaceAuthDailyWorkPeriod
|
|
|
42
|
42
|
|
|
|
|
|
placeAuthPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
placeAuthStatusRecords
|
|
|
|
40
|
40
|
|
|
|
|
|
|
|
PlaceAuthStatusRecord
|
n4
|
5
|
5
|
|
|
|
|
|
|
|
entryTime
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF GNSS_Places_Authentication
|
|
|
122
|
122
|
|
|
|
|
GNSSAuthAccumulatedDriving
|
|
|
122
|
122
|
|
|
|
|
|
gnssAuthADPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
gnssAuthStatusADRecords
|
|
120
|
120
|
|
|
|
|
|
|
GNSSAuthStatusADRecord
|
n8
|
5
|
5
|
|
|
|
|
|
|
|
timeStamp
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
EF Border_Crossings
|
|
|
|
|
70
|
70
|
|
|
|
|
CardBorderCrossings
|
|
|
|
|
70
|
70
|
|
|
|
|
|
borderCrossingPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardBorderCrossingRecords
|
|
|
68
|
68
|
|
|
|
|
|
|
CardBorderCrossingRecord
|
n10
|
17
|
17
|
|
|
|
|
|
|
|
countryLeft
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
countryEntered
|
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Unload_Operations
|
|
|
|
162
|
162
|
|
|
|
|
CardLoadUnloadOperations
|
|
|
|
162
|
162
|
|
|
|
|
|
loadUnloadPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardloadUnloadRecords
|
|
|
|
160
|
160
|
|
|
|
|
|
|
CardLoadUnloadRecord
|
|
n11
|
20
|
20
|
|
|
|
|
|
|
|
timestamp
|
|
|
4
|
4
|
{00}
|
|
|
|
|
|
|
operationType
|
|
|
1
|
1
|
{00..00}
|
|
|
|
|
|
|
gnssPlaceAuthRecord
|
|
12
|
12
|
|
|
|
|
|
|
|
|
timeStamp
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
|
gnssAccuracy
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
geoCoordinates
|
|
6
|
6
|
{00..00}
|
|
|
|
|
|
|
|
authenticationStatus
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
vehicleOdometerValue
|
|
3
|
3
|
{00..00}
|
|
|
EF Load_Type_Entries
|
|
|
|
22
|
22
|
|
|
|
|
CardLoadTypeEntries
|
|
|
|
22
|
22
|
|
|
|
|
|
loadtypeEntryPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
cardLoadTypeEntryRecords
|
|
20
|
20
|
|
|
|
|
|
|
CardLoadTypeEntryRecord
|
n12
|
5
|
5
|
|
|
|
|
|
|
|
timestamp
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
loadTypeEntered
|
|
1
|
1
|
{00}
|
|
|
EF Calibration_Add_Data
|
|
|
|
6887
|
6887
|
|
|
|
|
WorkshopCardCalibrationAddData
|
|
|
6887
|
6887
|
|
|
|
|
|
calibrationPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
workshopCardCalibrationAddDataRecords
|
|
|
6885
|
6885
|
|
|
|
|
|
|
WorkshopCardCalibrationAddDataRecord
|
n5
|
27
|
27
|
|
|
|
|
|
|
|
oldTimeValue
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
vehicleIdentificationNumber
|
|
17
|
17
|
{20..20}
|
|
|
|
|
|
|
byDefaultLoadType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
calibrationCountry
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
calibrationCountryTimestamp
|
|
4
|
4
|
{00..00}
|
|
|
EF VU_Configuration
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
n13
|
3072
|
3072
|
|
’;
(3)in paragraph TCS_163, the table is replaced by the following:
‘
|
|
|
Min
|
Max
|
|
n1
|
|
|
3
|
|
n2
|
NoOfFaultsPerType
|
6
|
6
|
|
n3
|
NoOfCardVehicleRecords
|
8
|
8
|
|
n4
|
NoOfCardPlaceRecords
|
8
|
8
|
|
n5
|
NoOfCalibrationRecords
|
255
|
255
|
|
n6
|
CardActivityLengthRange
|
492 bytes (1 day * 240 activity changes)
|
492 bytes (1 day *
240 activity changes)
|
|
n7
|
NoOfCardVehicleUnitRecords
|
8
|
8
|
|
n8
|
NoOfGNSSADRecords
|
24
|
24
|
|
n9
|
NoOfSpecificConditionRecords
|
4
|
4
|
|
n10
|
NoOfBorderCrossingRecords
|
4
|
4
|
|
n11
|
NoOfLoadUnloadRecords
|
8
|
8
|
|
n12
|
NoOfLoadTypeEntryRecords
|
4
|
4
|
|
n13
|
VuConfigurationLengthRange
|
3072 Bytes
|
3072 Bytes
|
’;
(v)point 4.4.2 is amended as follows:
(1)paragraph TCS_168 is replaced by the following:
‘TCS_168
After its personalisation, the control card application generation 2 shall have the following permanent file structure and file access rules.
Notes:
-
the short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary,
-
EF Application_Identification_V2, and EF VU_Configuration are only present in version 2 of the generation 2 control card,
-
cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 control card, while it was equal to {01 00} for version 1 of the generation 2 control card.
|
|
Access rules
|
|
File
|
File ID
|
SFID
|
Read / Select
|
Update
|
|
|
|
DF Tachograph_G2
|
|
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification
|
‘0501h’
|
1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CA_Certificate
|
‘C108h’
|
4
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Link_Certificate
|
‘C109h’
|
5
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Identification
|
‘0520h’
|
6
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Controller_Activity_Data
|
‘050Ch’
|
14
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VU_Configuration
|
‘0540h’
|
30
|
SC5/SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
The following abbreviations for the security condition are used in this table:
SC1
ALW OR SM-MAC-G2
SC5
For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported): NEV’;
(2)in paragraph TCS_170, the table is replaced by the following:
‘
|
File / Data Element
|
|
|
|
|
No of Records
|
Min
|
Max
|
Default Values
|
|
DF Tachograph_G2
|
|
|
|
|
|
14486
|
28237
|
|
|
|
EF Application_Identification
|
|
5
|
5
|
|
|
|
|
ControlCardApplicationIdentification
|
|
5
|
5
|
|
|
|
|
|
typeOfTachographCardId
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
2
|
2
|
{01 01} V2
|
|
|
|
|
noOfControlActivityRecords
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
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 Identification
|
|
|
|
|
211
|
211
|
|
|
|
|
CardIdentification
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
ControlCardHolderIdentification
|
|
146
|
146
|
|
|
|
|
|
controlBodyName
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
controlBodyAddress
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderName
|
|
|
|
|
|
|
|
|
|
|
|
holderSurname
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
|
holderFirstNames
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Controller_Activity_Data
|
|
|
10582
|
23922
|
|
|
|
|
ControlCardControlActivityData
|
|
10582
|
23922
|
|
|
|
|
|
controlPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
controlActivityRecords
|
|
10580
|
23920
|
|
|
|
|
|
|
controlActivityRecord
|
n7
|
46
|
46
|
|
|
|
|
|
|
|
controlType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
controlTime
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
controlledCardNumber
|
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardIssuingMemberState
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardNumber
|
|
16
|
16
|
{20..20}
|
|
|
|
|
|
|
controlledVehicleRegistration
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
controlDownloadPeriodBegin
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
controlDownloadPeriodEnd
|
4
|
4
|
{00..00}
|
|
|
EF Application_Identification_V2
|
|
4
|
4
|
|
|
|
|
ControlCardApplicationIdentificationV2
|
|
4
|
4
|
|
|
|
|
|
lengthOfFollowingData
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
2
|
2
|
{00 00}
|
|
|
EF VuConfiguration
|
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
|
n13
|
3072
|
3072
|
|
’;
(3)in paragraph TCS_171, the table is replaced by the following:
‘
|
|
|
Min
|
Max
|
|
n7
|
|
|
520
|
|
n13
|
|
|
3072 Bytes
|
’;
(vi)point 4.5.2 is amended as follows:
(1)paragraph TCS_176 is replaced by the following:
‘TCS_176After its personalisation, the company card application generation 2 shall have the following permanent file structure and file access rules.
Notes:
-the short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary,
-EF Application_Identification_V2, and EF VU_Configuration are only present in version 2 of the generation 2 company card,
-cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 company card, while it was equal to {01 00} for version 1 of the generation 2 company card.
|
|
|
Access rules
|
|
File
|
File ID
|
SFID
|
Read / Select
|
Update
|
|
|
|
DF Tachograph_G2
|
|
|
SC1
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification
|
‘0501h’
|
1
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CardMA_Certificate
|
‘C100h’
|
2
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF CA_Certificate
|
‘C108h’
|
4
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Link_Certificate
|
‘C109h’
|
5
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Identification
|
‘0520h’
|
6
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Company_Activity_Data
|
‘050Dh’
|
14
|
SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF Application_Identification_V2
|
‘0525h’
|
22
|
SC1
|
NEV
|
|
|
|
|
|
|
|
|
|
|
|
|
|
EF VU_Configuration
|
‘0540h’
|
30
|
SC5/SC1
|
SM-MAC-G2
|
|
|
|
|
|
|
|
|
|
The following abbreviations for the security condition are used in this table:
SC1
ALW OR SM-MAC-G2
SC5
For the Read Binary command with even INS byte:
SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported):
NEV’;
(2)in paragraph TCS_178, the table is replaced by the following:
‘
|
File / Data Element
|
|
|
|
|
No of Records
|
Min
|
Max
|
Default Values
|
|
DF Tachograph_G2
|
|
|
|
|
|
14414
|
28165
|
|
|
|
EF Application_Identification
|
|
5
|
5
|
|
|
|
|
CompanyCardApplicationIdentification
|
|
5
|
5
|
|
|
|
|
|
typeOfTachographCardId
|
|
1
|
1
|
{00}
|
|
|
|
|
cardStructureVersion
|
|
2
|
2
|
{01 01} V2
|
|
|
|
|
noOfCompanyActivityRecords
|
|
2
|
2
|
{00 00}
|
|
|
EF CardMA_Certificate
|
|
|
|
204
|
341
|
|
|
|
|
CardMA_Certificate
|
|
|
|
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 Identification
|
|
|
|
|
139
|
139
|
|
|
|
|
CardIdentification
|
|
|
|
65
|
65
|
|
|
|
|
|
cardIssuingMemberState
|
|
1
|
1
|
{00}
|
|
|
|
|
cardNumber
|
|
|
|
16
|
16
|
{20..20}
|
|
|
|
|
cardIssuingAuthorityName
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardIssueDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardValidityBegin
|
|
|
4
|
4
|
{00..00}
|
|
|
|
|
cardExpiryDate
|
|
|
|
4
|
4
|
{00..00}
|
|
|
|
CompanyCardHolderIdentification
|
|
74
|
74
|
|
|
|
|
|
companyName
|
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
companyAddress
|
|
|
|
36
|
36
|
{00, 20..20}
|
|
|
|
|
cardHolderPreferredLanguage
|
|
2
|
2
|
{20 20}
|
|
|
EF Company_Activity_Data
|
|
|
|
10582
|
23922
|
|
|
|
|
CompanyActivityData
|
|
|
|
10582
|
23922
|
|
|
|
|
|
companyPointerNewestRecord
|
|
2
|
2
|
{00 00}
|
|
|
|
|
companyActivityRecords
|
|
10580
|
23920
|
|
|
|
|
|
|
companyActivityRecord
|
n8
|
46
|
46
|
|
|
|
|
|
|
|
companyActivityType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
companyActivityTime
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
cardNumberInformation
|
|
|
|
|
|
|
|
|
|
|
|
cardType
|
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardIssuingMemberState
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
cardNumber
|
|
16
|
16
|
{20..20}
|
|
|
|
|
|
|
vehicleRegistrationInformation
|
|
|
|
|
|
|
|
|
|
|
vehicleRegistrationNation
|
1
|
1
|
{00}
|
|
|
|
|
|
|
|
vehicleRegistrationNumber
|
14
|
14
|
{00, 20..20}
|
|
|
|
|
|
|
downloadPeriodBegin
|
|
4
|
4
|
{00..00}
|
|
|
|
|
|
|
downloadPeriodEnd
|
|
4
|
4
|
{00..00}
|
|
|
EF Application_Identification_V2
|
|
4
|
4
|
|
|
|
|
CompanyCardApplicationIdentificationV2
|
|
4
|
4
|
|
|
|
|
|
lengthOfFollowingData
|
|
2
|
2
|
{00 00}
|
|
|
|
|
VuConfigurationLengthRange
|
|
2
|
2
|
{00 00}
|
|
|
EF VuConfiguration
|
|
|
|
3072
|
3072
|
|
|
|
|
VuConfigurations
|
|
|
n13
|
3072
|
3072
|
|
’;
(3)in paragraph TCS_179, the table is replaced by the following:
‘
|
|
|
Min
|
Max
|
|
n8
|
|
|
520
|
|
n13
|
|
|
3072 Bytes
|
’;
(32)Appendix 3 is amended as follows:
(a)point 1 is amended as follows:
(i)the paragraph on specific conditions is replaced by the following:
‘Specific conditions, manual entries
Out of scope
Ferry/train crossing
Load operation
Unload operation
Simultaneous load/unload operation
Load type: passengers
Load type: goods
Load type: undefined load type’;
(ii)the pictograms for miscellaneous are amended as follows:
(1)the security pictogram is replaced by the following:
‘
Security/authenticated data/seals’;
(2)the following pictogram is added
‘
Digital map/border crossing’;
(b)point 2 is amended as follows:
(i)the following pictogram combinations are added to the pictograms for miscellaneous:
‘
|
|
Position where the vehicle has crossed the border between two countries
|
|
|
Position where a load operation has occurred
|
|
|
Position where an unload operation has occurred
|
|
|
Position where a simultaneous load/unload operation has occurred’;
|
(ii)the following pictogram combination is added to the pictograms for printouts:
‘
Historic of inserted cards printout’;
(iii)the following pictogram combination is added to the pictograms for events:
‘
GNSS anomaly’;
(33)Appendix 4 is amended as follows:
(a)in point 1, paragraph PRT_005 is replaced by the following:
‘PRT_005
String data fields are printed left aligned and filled up with spaces to data item length, or truncated to data item length when needed. Names and addresses may be printed in two lines.’;
(b)point 2 is amended as follows:
(i)the following indents are added after the table and before paragraph PRT_007:
‘-
In a data block, the text after ‘pi=’ refers to the corresponding pictogram or pictogram combination defined in Appendix 3,
-
When printed after the longitude and the latitude of a recorded position, or after the timestamp when the position was determined, the
pictogram indicates that this position has been computed from authenticated navigation messages,
-
* data only available in GEN2 tachographs (all versions),
-
** data only available in GEN2 version 2.’;
(ii)blocks 2 and 3 are replaced by the following:
‘
|
2
|
Type of printout.
|
|
|
Block identifier
VU generation and version**
|
-----------
------------
GEN2 v2
|
|
|
Printout pictogram combination (see App. 3), Speed limiting device setting (Over speeding printout only)
|
Picto xxx km/h
|
|
|
|
|
|
|
|
|
3
|
Card holder identification.
|
|
|
Block identifier. P= people pictogram
|
-----------P------------
|
|
|
Card holder surname
|
P Last_Name_____________
|
|
|
Card holder first name(s) (if any)
|
First_Name____________
|
|
|
Card identification
|
Card_Identification_____
|
|
|
Card expiry date (if any) and Card generation number (GEN1 or GEN2)* and version**
|
dd/mm/yyyy - GEN2 v2
|
In the case where the card is a non-personal card, and holds no card holder surname, the company or workshop or control body name shall be printed instead.’;
(iii)before block 4, the sentence preceded by an asterisk is deleted.
(iv)the following block is inserted after block 4:
‘
|
4a
|
Vehicle by-default load type**
|
|
|
pi = by-default load type of the vehicle pictogram**
|
pi
|
’;
(v)block 5 is replaced by the following:
‘
|
5
|
VU identification.
|
|
|
Block identifier
|
-----------
------------
|
|
|
VU manufacturer’s name
|
VU_Manufacturer_______
|
|
|
VU part number
VU generation number*
|
VU_Part_Number__
GEN2
|
’;
(vi)before block 6, the sentence preceded by an asterisk is deleted.
(vii)the following block is inserted after block 8a:
‘
|
8b
|
Load type in the beginning of this day** (if the card is inserted in a VU, leave blank otherwise), pi=load type pictogram**
|
-----------pi-----------
|
’;
(viii)block 8.2 is replaced by the following:
‘
|
8.2
|
Card insertion in slot S
|
|
|
Record identifier; S = Slot pictogram
|
---------S---------
|
|
|
Vehicle registering Member State and VRN
|
Nat/VRN__________
|
|
|
Vehicle odometer at card insertion
pi = vehicle load type at card insertion**
|
x xxx xxx km
pi
|
’;
(ix)block 10.2 is replaced by the following:
‘
|
10.2
|
Card insertion
|
|
|
Card insertion Record identifier
|
--------------------
|
|
|
|
Last_Name_____________
|
|
|
Driver’s first name
|
First_Name____________
|
|
|
Driver’s Card identification
|
Card_Identification_____
|
|
|
Card expiry date (if any) and Card generation number (GEN1 or GEN2)* and version**
|
dd/mm/yyyy - GEN2 v2
|
|
|
Registering Member State and VRN of previous vehicle used
|
Nat/VRN__________
|
|
|
Date and time of card withdrawal from previous vehicle
|
dd/mm/yyyy hh:mm
|
|
|
Blank line
|
|
|
|
Vehicle odometer at card insertion, Manual entry of driver activities flag (M if yes, Blank if No).
If no card insertion of a driver card happened on the day for which the printout is done then for block 10.2 the odometer data reading from the last available card insertion before that day shall be used.
|
x xxx xxx km M
|
|
|
|
|
’;
(x)before block 11, the sentence preceded by an asterisk is deleted.
(xi)blocks 11.4 and 11.5 are replaced by the following:
‘
|
11.4
|
Entry of place where a daily work period begins and/or ends
|
|
|
pi=location begin / end pictogram, time, country, region
latitude of the recorded position*, authentication status**
longitude of the recorded position*, authentication status**
timestamp when position was determined*, authentication status**
|
pihh:mm Cou Reg
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Odometer
|
x xxx xxx km
|
|
11.5
|
Position after 3 hours accumulated driving time*
|
|
|
pi=position after 3 hours accumulated driving time*, time of the record *
latitude of the recorded position*, authentication status**
longitude of the recorded position*, authentication status**
timestamp when position was determined*, authentication status**
|
pihh:mm
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Odometer*
|
x xxx xxx km
|
|
11.5a
|
Border crossing**
pi=position where the vehicle has crossed the border
|
|
|
of a country**
Country that the vehicle was leaving/entering**
latitude of the recorded position**, authentication status**
longitude of the recorded position**, authentication status**
timestamp when position was determined**, authentication status**
|
pi
Cou
Cou
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Odometer**
|
x xxx xxx km
|
|
11.5b
|
Load/unload operation**
|
|
|
pi=position where a load/unload operation has occurred, time of the record**
latitude of the recorded position**, authentication status**
longitude of the recorded position**, authentication status**
timestamp when position was determined**
|
pihh:mm
lat ± DD°MM.M’
lon ±DDD°MM.M’
dd/mm/yyyy hh:mm
|
|
|
Odometer**
|
x xxx xxx km
|
’;
(xii)block 14 is replaced by the following:
‘
|
14
|
VU Identification
|
|
|
Block identifier
|
-----------
------------
|
|
|
VU manufacturer name
|
Name__________________
|
|
|
VU manufacturer address
|
Address_______________
|
|
|
VU part number
|
PartNumber______
|
|
|
VU approval number
|
Apprv___________
|
|
|
|
S/N_____
|
|
|
VU year of manufacture
VU generation and version**
|
yyyy
GEN2 v2
|
|
|
|
V xxxx dd/mm/yyyy
xxxxxxxxxxxx
|
’;
(xiii)block 15.1 is replaced by the following:
‘
|
15.1
|
Pairing record
|
|
|
|
Sensor serial number (S/N = serialNumber in decimal, MY = monthYear in decimal, T = type in decimal, MC = manufacturerCode in hexadecimal, see Appendix 1, ExtendedSerialNumber)
|
S/N_______ MY__ T__ MC_
|
|
|
Sensor approval number
|
Apprv___________
|
|
|
Sensor pairing date
|
dd/mm/yyyy hh:mm
|
’;
(xiv)blocks 16 and 16.1 are replaced by the following:
‘
16
GNSS identification*
|
|
Block identifier*
|
-----------
-----------
|
16.1
Coupling record*
|
|
External GNSS facility serial number* (S/N = serialNumber in decimal, MY = monthYear in decimal, T = type in decimal, MC = manufacturerCode in hexadecimal, see Appendix 1, ExtendedSerialNumber)
|
S/N_______ MY__ T__ MC_
|
|
|
External GNSS facility approval number*
|
Apprv___________
|
|
|
External GNSS facility coupling date*
|
dd/mm/yyyy hh:mm
|
|
16a
|
Remote communication facility identification**
|
|
|
Block identifier**
|
-----------
-----------
|
16a.1
Remote communication facility serial number**
|
Remote communication facility serial number** (S/N = serialNumber in decimal, MY = monthYear in decimal, T = type in decimal, MC = manufacturerCode in hexadecimal, see Appendix 1, ExtendedSerialNumber)
|
S/N_______ MY__ T__ MC_
|
’;
(xv)block 17.1 is replaced by the following:
‘
|
17.1
|
Calibration record
|
|
|
Record identifier
|
--------------------
|
|
|
Workshop having performed the calibration
|
Workshop_name_________
|
|
|
Workshop address
|
Workshop_address______
|
|
|
Workshop card identification
|
Card_Identification_____
|
|
|
Workshop card expiry date
|
dd/mm/yyyy
|
|
|
Blank line
|
|
|
|
Calibration date time (oldTimeValue in the calibration record) + calibration purpose in hexadecimal
|
dd/mm/yyyy hh:mm (p)
|
|
|
VIN
|
VIN______________
|
|
|
Registering Member State & VRN
|
Nat/VRN__________
|
|
|
Characteristic coefficient of vehicle
|
w xx xxx Imp/km
|
|
|
Constant of the recording equipment
|
k xx xxx Imp/km
|
|
|
Effective circumference of wheel tyres
|
l xx xxx mm
|
|
|
Size of tyres mounted
|
TyreSize_______
|
|
|
Speed limiting device setting
|
xxx km/h
|
|
|
Old and new odometer values
pi=by-default load type of the vehicle**
Country in which the calibration has been performed and date time
Seal data (up to 5 seal records, 1 line for each used seal), ET = equipmentType in decimal**, MC = manufacturerCode as two characters**,SI = sealIdentifier as 8 characters**, see Appendix 1, SealRecord)
|
x xxx xxx – x xxx xxx km
pi
Cou dd/mm/yyyy hh:mm
ET_ MC SI______
|
The calibration purpose (p) is a numerical code explaining why these calibration parameters were recorded, coded in accordance with the data element CalibrationPurpose.’;
(xvi)block 23 is replaced by the following:
‘
|
23
|
Most recent cards inserted in VU*
|
|
|
Block identifier*
|
--------
--------
|
|
23.1
|
Inserted Card*
|
|
|
|
Record identifier*
|
----
|
|
|
|
<gen> <version> <MC>
|
|
|
Card Identification*
Card Serial Number*
Date and time of last card insertion*
|
Card Identification
Card Serial Number
dd/mm/yyyy hh:mm
|
|
|
|
|
1 (everything in one line)
with
type of card: Pictogram, one character + space
gen: GEN1 or GEN2, 4 characters + space
version: up to 10 characters
MC: manufacturer code, 3 characters’;
(c)point 3 is amended as follows:
(i)in point 3.1, paragraph PRT_008 is replaced by the following :
‘PRT_008
The driver activities from card daily printout shall be in accordance with the following format:
|
1
|
Date and time at which the document is printed
|
|
2
|
Type of printout
|
|
3
|
Controller identification (if a control card is inserted in the VU)
|
|
3
|
Driver identification (from card subject of the printout + GEN)
|
|
4
|
Vehicle identification (vehicle from which printout is taken)
|
|
5
|
VU identification (VU from which printout is taken + GEN)
|
|
6
|
Last calibration of this VU
|
|
7
|
Last control the inspected driver has been subject to
|
|
8
|
Driver activities delimiter
|
|
8a
|
Out of scope condition in the beginning of this day
|
|
8b
|
Load type in the beginning of the day (if the card is inserted in a VU)
|
|
8.1a / 8.1b / 8.1c / 8.2 / 8.3 / 8.3a / 8.4
|
Activities of the driver in order of occurrence
|
|
11
|
Daily summary delimiter
|
|
11.4
|
Places entered in chronological order
|
|
11.5
|
Positions after 3 hours accumulated driving time, in chronological order
|
|
11.5a
|
Border crossings, in chronological order
|
|
11.5b
|
Load/unload operations, in chronological order
|
|
11.6
|
Activity totals
|
|
12.1
|
Events or faults from card delimiter
|
|
12.4
|
Event/Fault records (Last 5 events or faults stored in the card)
|
|
13.1
|
Events or faults from VU delimiter
|
|
13.4
|
Event/Fault records (Last 5 events or faults stored or on-going in the VU)
|
|
22.1
|
Control place
|
|
22.2
|
Controller’s signature
|
|
22.5
|
Driver's signature
|
’;
(ii)in point 3.2, paragraph PRT_009 is replaced by the following:
‘PRT_009
The driver activities from VU daily printout shall be in accordance with the following format:
|
1
|
Date and time at which the document is printed
|
|
2
|
Type of printout
|
|
3
|
Card holder identification (for all cards inserted in VU + GEN)
|
|
4
|
Vehicle identification (vehicle from which printout is taken)
|
|
4a
|
Vehicle by-default load type
|
|
5
|
VU identification (VU from which printout is taken + GEN)
|
|
6
|
Last calibration of this VU
|
|
7
|
Last control on this tachograph
|
|
9
|
Driver activities delimiter
|
|
10
|
Driver slot delimiter (slot 1)
|
|
10a
|
Out of scope condition in the beginning of this day
|
|
10.1 / 10.2 / 10.3 /10.3a / 10.4
|
Activities in chronological order (driver slot)
|
|
10
|
Co-driver slot delimiter (slot 2)
|
|
10a
|
Out of scope condition in the beginning of this day
|
|
10.1 / 10.2 / 10.3 /10.3a / 10.4
|
Activities in chronological order (co-driver slot)
|
|
11
|
Daily summary delimiter
|
|
11.1
|
Summary of periods without card in driver slot
|
|
11.4
|
Places entered in chronological order
|
|
11.5
|
Positions after 3 hours accumulated driving time, in chronological order
|
|
11.5a
|
Border crossings, in chronological order
|
|
11.5b
|
Load/unload operations, in chronological order
|
|
11.7
|
Activity totals
|
|
11.2
|
Summary of periods without card in co-driver slot
|
|
11.4
|
Places entered in chronological order
|
|
11.5
|
Positions after 3 hours accumulated driving time, in chronological order
|
|
11.5a
|
Border crossings, in chronological order
|
|
11.5b
|
Positions where load/unload operation has occurred, in chronological order
|
|
11.8
|
Activity totals
|
|
11.3
|
Summary of activities for a driver both slots included
|
|
|
11.4
|
|
Places entered by this driver in chronological order
|
|
|
11.5
|
|
Positions after 3 hours accumulated driving time in chronological order
|
|
|
11.5a
|
|
Border crossings, in chronological order
|
|
|
11.5b
|
|
Load/unload operations, in chronological order
|
|
11.9
|
Activity totals for this driver
|
|
13.1
|
Events faults delimiter
|
|
13.4
|
Event/Fault records (Last 5 events or faults stored or on-going in the VU)
|
|
22.1
|
Control place
|
|
22.2
|
Controller’s signature
|
|
22.3
|
|
|
22.4
|
To time
which periods are relevant to himself)
|
|
22.5
|
Driver's signature
|
’;
(iii)in point 3.5, paragraph PRT_012 is replaced by the following:
‘PRT_012
The technical data printout shall be in accordance with the following format:
|
1
|
Date and time at which the document is printed
|
|
2
|
Type of printout
|
|
3
|
Card holder identification (for all cards inserted in VU + GEN)
|
|
4
|
Vehicle identification (vehicle from which printout is taken)
|
|
14
|
VU identification
|
|
15
|
Sensor identification
|
|
15.1
|
Sensor Pairing data (all data available in chronological order)
|
|
16
|
GNSS identification
|
|
16.1
|
External GNSS facility coupling data (all data available in chronological order)
|
|
16a
|
Remote communication facility identification
|
|
16a.1
|
Remote communication facility serial number
|
|
17
|
Calibration data delimiter
|
|
17.1
|
Calibration records (all records available in chronological order)
|
|
18
|
Time adjustment delimiter
|
|
18.1
|
Time adjustment records (all records available from time adjustment and from calibration data records)
|
|
19
|
Most recent event and Fault recorded in the VU
|
|
2
|
Type of printout (indicates the end of the printout)
|
’;
(iv)in point 3.7, paragraph PRT_014 is replaced by the following:
‘PRT_014
The historic of inserted cards printout shall be in accordance with the following format:
|
1
|
Date and time at which the document is printed
|
|
2
|
Type of printout
|
|
3
|
Card holder identifications (of all cards inserted in the VU)
|
|
23
|
Most recent card inserted in the VU
|
|
23.1
|
Inserted cards (up to 88 records)
|
|
2
|
Type of printout (indicates the end of the printout)
|
’;
(34)Appendix 7 is amended as follows:
(a)the Table of Content is amended as follows:
(i)points 2.2.6.1 to 2.2.6.5 are replaced by the following:
‘2.2.6.1
Positive Response Transfer Data Download Interface Version
2.2.6.2
Positive Response Transfer Data Overview
2.2.6.3
Positive Response Transfer Data Activities
2.2.6.4
Positive Response Transfer Data Events and Faults
2.2.6.5
Positive Response Transfer Data Detailed Speed’;
(ii)the following point is added:
‘2.2.6.6
Positive Response Transfer Data Technical Data’;
(b)point 2 is amended as follows:
(i)in point 2.2.2, the message structure table and the notes after the table are replaced by the following:
‘
|
Message Structure
|
Max 4 Bytes
|
Max 255 Bytes
|
1 Byte
|
|
|
|
Header
|
Data
|
CheckSum
|
|
IDE ->
|
<- VU
|
FMT
|
TGT
|
SRC
|
LEN
|
SID
|
DS_ / TRTP
|
DATA
|
CS
|
|
Start Communication Request
|
81
|
EE
|
F0
|
|
81
|
|
|
E0
|
|
Positive Response Start Communication
|
80
|
F0
|
EE
|
03
|
C1
|
|
EA, 8F
|
9B
|
|
Start Diagnostic Session Request
|
80
|
EE
|
F0
|
02
|
10
|
81
|
|
F1
|
|
Positive Response Start Diagnostic
|
80
|
F0
|
EE
|
02
|
50
|
81
|
|
31
|
|
Link Control Service
|
|
|
|
|
|
|
|
|
|
Verify Baud Rate (stage 1)
|
|
|
|
|
|
|
|
|
|
9 600 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,01
|
EC
|
|
19 200 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,02
|
ED
|
|
38 400 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,03
|
EE
|
|
57 600 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,04
|
EF
|
|
115 200 Bd
|
80
|
EE
|
F0
|
04
|
87
|
01
|
01,05
|
F0
|
|
Positive Response Verify Baud Rate
|
80
|
F0
|
EE
|
02
|
C7
|
01
|
|
28
|
|
Transition Baud Rate (stage 2)
|
80
|
EE
|
F0
|
03
|
87
|
02
|
03
|
ED
|
|
Request Upload
|
80
|
EE
|
F0
|
0A
|
35
|
|
00,00,00,00,00,FF,FF,
FF,FF
|
99
|
|
Positive Response Request Upload
|
80
|
F0
|
EE
|
03
|
75
|
|
00,FF
|
D5
|
|
Transfer Data Request
|
|
|
|
|
|
|
|
|
|
Download interface version
|
80
|
EE
|
F0
|
02
|
36
|
00
|
|
96
|
|
Overview
|
80
|
EE
|
F0
|
02
|
36
|
01, 21 or 31
|
|
CS
|
|
Activities
|
80
|
EE
|
F0
|
06
|
36
|
02, 22 or 32
|
Date
|
CS
|
|
Events & Faults
|
80
|
EE
|
F0
|
02
|
36
|
03, 23 or 33
|
Date
|
CS
|
|
Detailed Speed
|
80
|
EE
|
F0
|
02
|
36
|
04 or 24
|
Date
|
CS
|
|
Technical Data
|
80
|
EE
|
F0
|
02
|
36
|
05, 25 or 35
|
Date
|
CS
|
|
Card download
|
80
|
EE
|
F0
|
02 or 03
|
36
|
06
|
Slot
|
CS
|
|
Positive Response Transfer Data
|
80
|
F0
|
EE
|
Len
|
76
|
TREP
|
Data
|
CS
|
|
Request Transfer Exit
|
80
|
EE
|
F0
|
01
|
37
|
|
|
96
|
|
Positive Response Request Transfer Exit
|
80
|
F0
|
EE
|
01
|
77
|
|
|
D6
|
|
Stop Communication Request
|
80
|
EE
|
F0
|
01
|
82
|
|
|
E1
|
|
Positive Response Stop Communication
|
80
|
F0
|
EE
|
01
|
C2
|
|
|
21
|
|
Acknowledge sub message
|
80
|
EE
|
F0
|
Len
|
83
|
|
Data
|
CS
|
|
Negative responses
|
|
|
|
|
|
|
|
|
|
General reject
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
10
|
CS
|
|
Service not supported
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
11
|
CS
|
|
Sub function not supported
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
12
|
CS
|
|
Incorrect Message Length
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
13
|
CS
|
|
Conditions not correct or Request sequence error
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
22
|
CS
|
|
Request out of range
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
31
|
CS
|
|
Upload not accepted
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
50
|
CS
|
|
Response pending
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
78
|
CS
|
|
Data not available
|
80
|
F0
|
EE
|
03
|
7F
|
Sid Req
|
FA
|
CS
|
Notes:
-
Sid Req = the Sid of the corresponding request.
-
TREP = the TRTP of the corresponding request.
-
Dark cells denote that nothing is transmitted.
-
The term upload (as seen from the IDE) is used for compatibility with ISO 14229. It means the same as download (as seen from the VU).
-
Potential 2-byte sub message counters are not shown in this table.
-
Slot is the slot number, either ‘1’ (card on driver slot) or ‘2’ (card on co-driver slot).
-
In case the slot is not specified, the VU shall select slot 1 if a card is inserted in this slot and it shall select slot 2 only in case it is specifically selected by the user.
-
TRTP 24 is used for Generation 2, for version 1 and version 2 type of VU data download requests.
-
TRTP 00, 31, 32, 33 and 35 are used for Generation 2 version 2 type of VU data download requests.
-
TRTP 21, 22, 23, and 25 are used for Generation 2 version 1 type of VU data download requests.
-
TRTP 01 to 05 are used for Generation 1 type of VU data download requests. They can optionally be accepted by Generation 2 type of VU, but only in the frame of drivers' control performed by a non-EU control authority, using a first generation control card.
-
TRTP 11 to 1F are reserved for manufacturer specific download requests.’;
(ii)point 2.2.2.9 is amended as follows:
(1)
in paragraph DDP_011, the second subparagraph and the first table are replaced by the following:
‘There are seven types of data transfer. For VU data download, two different TRTP values can be used for each transfer type:
|
Data transfer type
|
TRTP value for generation 1 type of
VU data download
|
TRTP value for generation 2, version 1 type of
VU data download
|
TRTP value for generation 2, version 2 type of
VU data download
|
|
Download interface version
|
Not used
|
Not used
|
00
|
|
Overview
|
01
|
21
|
31
|
|
Activities of a specified date
|
02
|
22
|
32
|
|
Events and faults
|
03
|
23
|
33
|
|
Detailed speed
|
04
|
24
|
24
|
|
Technical data
|
05
|
25
|
35
|
’;
(2)
paragraph DDP_054 is replaced by the following:
‘DDP_054
It is mandatory for the IDE to request the overview data transfer (TRTP 01, 21 or 31) during a download session as this only will ensure that the VU certificates are recorded within the downloaded file (and allow for verification of digital signature).
In the third case (TRTP 02, 22 or 32) the Transfer Data Request message includes the indication of the calendar day (TimeReal format) to be downloaded.’;
(iii)in point 2.2.2.10, the text before the indents in paragraph DDP_055 is replaced by the following:
‘DDP_055
In the first case (TREP 01, 21 or 31), the VU will send data helping the IDE operator to choose the data he wants to download further. The information contained within this message is:’;
(iv)in point 2.2.5.2, Figure 2 is replaced by the following:
‘
Figure 2
VU error handling
’;
(v)points 2.2.6.1 to 2.2.6.5 are replaced by the following:
‘2.2.6.1
Positive Response Transfer Data Download Interface Version
DDP_028a
The data field of the ‘Positive Response Transfer Data Download Interface Version’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 00 Hex:
Data structure generation 2, version 2 (TREP 00 Hex)
|
Data element
|
|
Comment
|
|
DownloadInterfaceVersion
|
|
Generation and version of the VU: 02,02 Hex for Generation 2, version 2.
Not supported by Generation 1 and Generation 2, version 1 VU, which shall respond negatively (Sub function not supported, see DDP_018)
|
2.2.6.2
Positive Response Transfer Data Overview
DDP_029
The data field of the ‘Positive Response Transfer Data Overview’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 01, 21 or 31 Hex and appropriate sub message splitting and counting:
Data structure generation 1 (TREP 01 Hex)
|
Data element
|
|
Comment
|
|
MemberStateCertificate
|
|
VU Security certificates
|
|
VUCertificate
|
|
|
|
VehicleIdentificationNumber
|
|
Vehicle identification
|
|
VehicleRegistrationIdentification
|
|
|
|
CurrentDateTime
|
|
VU current date and time
|
|
VuDownloadablePeriod
|
|
Downloadable period
|
|
CardSlotsStatus
|
|
Type of cards inserted in the VU
|
|
VuDownloadActivityData
|
|
Previous VU download
|
|
VuCompanyLocksData
|
|
All company locks stored. If the section is empty, only noOfLocks = 0 is sent.
|
|
|
|
|
|
VuControlActivityData
|
|
All control records stored in the VU. If the section is empty, only noOfControls = 0 is sent
|
|
|
|
|
|
|
|
|
|
Signature
|
|
RSA signature of all data (except certificates) starting from VehicleIdentificationNumber down to last byte of last VuControlActivityData.
|
|
Data structure generation 2, version 1 (TREP 21 Hex)
|
|
Data element
|
|
Comment
|
|
MemberStateCertificateRecordArray
|
|
Member state certificate
|
|
VUCertificateRecordArray
|
|
VU certificate
|
|
VehicleIdentificationNumberRecordArray
|
|
Vehicle identification
|
|
VehicleRegistrationIdentificationRecordArray
|
|
Vehicle registration number
|
|
CurrentDateTimeRecordArray
|
|
VU current date and time
|
|
VuDownloadablePeriodRecordArray
|
|
Downloadable period
|
|
CardSlotsStatusRecordArray
|
|
Type of cards inserted in the VU
|
|
VuDownloadActivityDataRecordArray
|
|
Previous VU download
|
|
VuCompanyLocksRecordArray
|
|
All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent
|
|
VuControlActivityRecordArray
|
|
All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data except the certificates.
|
|
Data structure generation 2, version 2 (TREP 31 Hex)
|
|
Data element
|
|
Comment
|
|
MemberStateCertificateRecordArray
|
|
Member state certificate
|
|
VUCertificateRecordArray
|
|
VU certificate
|
|
VehicleIdentificationNumberRecordArray
|
|
Vehicle identification
|
|
VehicleRegistrationNumberRecordArray
|
|
Vehicle registration number
|
|
CurrentDateTimeRecordArray
|
|
VU current date and time
|
|
VuDownloadablePeriodRecordArray
|
|
Downloadable period
|
|
CardSlotsStatusRecordArray
|
|
Type of cards inserted in the VU
|
|
VuDownloadActivityDataRecordArray
|
|
Previous VU download
|
|
VuCompanyLocksRecordArray
|
|
All company locks stored. If the section is empty, an array header with noOfRecords = 0 is sent
|
|
VuControlActivityRecordArray
|
|
All control records stored in the VU. If the section is empty, an array header with noOfRecords = 0 is sent
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data except the certificates.
|
2.2.6.3
Positive Response Transfer Data Activities
DDP_030
The data field of the ‘Positive Response Transfer Data Activities’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 02, 22 or 32 Hex and appropriate sub message splitting and counting:
Data structure generation 1 (TREP 02 Hex)
|
Data element
|
|
Comment
|
|
TimeReal
|
|
Date of day downloaded
|
|
OdometerValueMidnight
|
|
Odometer at end of downloaded day
|
|
VuCardIWData
|
|
Cards insertion withdrawal cycles data.
-If this section contains no available data, only noOfVuCardIWRecords = 0 is sent.
-When a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
VuActivityDailyData
|
|
Slots status at 00:00 and activity changes recorded for the day downloaded.
|
|
|
|
|
|
VuPlaceDailyWorkPeriodData
|
|
Places related data recorded for the day downloaded. If the section is empty, only noOfPlaceRecords = 0 is sent.
|
|
|
|
|
|
|
|
|
|
VuSpecificConditionData
|
|
Specific conditions data recorded for the day downloaded. If the section is empty, only noOfSpecificConditionRecords=0 is sent
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Signature
|
|
RSA signature of all data starting from TimeReal down to last byte of last specific condition record.
|
Data structure generation 2, version 1 (TREP 22 Hex)
|
Data element
|
Comment
|
|
DateOfDayDownloadedRecordArray
|
|
Date of day downloaded
|
|
OdometerValueMidnightRecordArray
|
|
Odometer at end of downloaded day
|
|
VuCardIWRecordArray
|
|
Cards insertion withdrawal cycles data.
-If this section contains no available data, an array header with noOfRecords = 0 is sent.
-When a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved.
|
|
VuActivityDailyRecordArray
|
|
Slots status at 00:00 and activity changes recorded for the day downloaded.
|
|
VuPlaceDailyWorkPeriodRecordArray
|
|
Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuGNSSADRecordArray
|
|
GNSS positions of the vehicle if the accumulated driving time of the vehicle reaches a multiple of three hours. If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuSpecificConditionRecordArray
|
|
Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
Data structure generation 2, version 2 (TREP 32 Hex)
|
Data element
|
Comment
|
|
DateOfDayDownloadedRecordArray
|
|
Date of day downloaded
|
|
OdometerValueMidnightRecordArray
|
|
Odometer at end of downloaded day
|
|
VuCardIWRecordArray
|
|
Cards insertion withdrawal cycles data.
-If this section contains no available data, an array header with noOfRecords = 0 is sent.
-When a VuCardIWRecord lies across 00:00 (card insertion on previous day) or across 24:00 (card withdrawal the following day) it shall appear in full within the two days involved.
|
|
VuActivityDailyRecordArray
|
|
Slots status at 00:00 and activity changes recorded for the day downloaded.
|
|
VuPlaceDailyWorkPeriodRecordArray
|
|
Places related data recorded for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuGNSSADRecordArray
|
|
GNSS positions of the vehicle if the accumulated driving time of the vehicle reaches a multiple of three hours. If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuSpecificConditionRecordArray
|
|
Specific conditions data recorded for the day downloaded. If the section is empty, an array header with noOfRecords =0 is sent
|
|
VuBorderCrossingRecordArray
|
|
Border crossings for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuLoadUnloadRecordArray
|
|
Load/unload operations for the day downloaded. If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
2.2.6.4
Positive Response Transfer Data Events and Faults
DDP_031
The data field of the ‘Positive Response Transfer Data Events and Faults’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 03, 23 or 33 Hex and appropriate sub message splitting and counting:
Data structure generation 1, (TREP 03 Hex)
|
Data element
|
|
Comment
|
|
VuFaultData
|
|
All faults stored or on-going in the VU.
If the section is empty, only noOfVuFaults = 0 is sent.
|
|
|
|
|
|
|
|
|
|
VuEventData
|
|
All events (except over speeding) stored or on-going in the VU.
If the section is empty, only noOfVuEvents = 0 is sent.
|
|
|
|
|
|
|
|
|
|
VuOverSpeedingControlData
|
|
Data related to last over speeding control (default value if no data).
|
|
|
|
|
|
VuOverSpeedingEventData
|
|
All over speeding events stored in the VU.
If the section is empty, only noOfVuOverSpeedingEvents = 0 is sent.
|
|
|
|
|
|
|
|
|
|
VuTimeAdjustmentData
|
|
All time adjustment events stored in the VU (outside the frame of a full calibration).
If the section is empty, only noOfVuTimeAdjRecords = 0 is sent.
|
|
|
|
|
|
|
|
|
|
Signature
|
|
RSA signature of all data starting from noOfVuFaults down to last byte of last time adjustment record
|
|
|
|
|
|
Data structure generation 2, version 1 (TREP 23 Hex)
|
|
Data element
|
|
Comment
|
|
VuFaultRecordArray
|
|
All faults stored or on-going in the VU.
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuEventRecordArray
|
|
All events (except over speeding) stored or on-going in the VU.
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuOverSpeedingControlDataRecordArray
|
|
Data related to last over speeding control (default value if no data).
|
|
VuOverSpeedingEventRecordArray
|
|
All over speeding events stored in the VU.
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuTimeAdjustmentRecordArray
|
|
All time adjustment events stored in the VU (outside the frame of a full calibration).
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
|
Data structure generation 2, version 2 (TREP 33 Hex)
|
|
Data element
|
|
Comment
|
|
VuFaultRecordArray
|
|
All faults stored or on-going in the VU.
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuEventRecordArray
|
|
All events (except over speeding) stored or on-going in the VU.
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuOverSpeedingControlDataRecordArray
|
|
Data related to last over speeding control (default value if no data).
|
|
VuOverSpeedingEventRecordArray
|
|
All over speeding events stored in the VU.
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
VuTimeAdjustmentRecordArray
|
|
All time adjustment events stored in the VU (outside the frame of a full calibration).
If the section is empty, an array header with noOfRecords = 0 is sent.
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
2.2.6.5
Positive Response Transfer Data Detailed Speed
DDP_032
The data field of the ‘Positive Response Transfer Data Detailed Speed’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 04 or 24 Hex and appropriate sub message splitting and counting:
Data structure generation 1 (TREP 04 Hex)
|
Data element
|
|
Comment
|
|
VuDetailedSpeedData
|
|
All detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving)
60 speed values per minute (one per second).
|
|
|
|
|
|
|
|
|
|
Signature
|
|
RSA signature of all data starting from noOfSpeedBlocks down to last byte of last speed block.
|
|
Data structure generation 2 (TREP 24 Hex)
|
|
Data element
|
Comment
|
|
VuDetailedSpeedBlockRecordArray
|
|
All detailed speed stored in the VU (one speed block per minute during which the vehicle has been moving)
60 speed values per minute (one per second).
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
’;
(vi)the following point is added:
‘2.2.6.6
Positive Response Transfer Data Technical Data
DDP_033
The data field of the ‘Positive Response Transfer Data Technical Data’ message shall provide the following data in the following order under the SID 76 Hex, the TREP 05, 25 or 35 Hex and appropriate sub message splitting and counting:
Data structure generation 1 (TREP 05 Hex)
|
Data element
|
|
Comment
|
|
VuIdentification
|
|
|
|
SensorPaired
|
|
|
|
VuCalibrationData
|
|
All calibration records stored in the VU.
|
|
|
|
|
|
Signature
|
|
RSA signature of all data starting from vuManufacturerName down to last byte of last VuCalibrationRecord.
|
Data structure generation 2, version 1 (TREP 25 Hex)
|
Comment
|
|
Data element
|
|
|
|
VuIdentificationRecordArray
|
|
|
|
VuSensorPairedRecordArray
|
|
All MS pairings stored in the VU
|
|
VuSensorExternalGNSSCoupledRecordArray
|
|
All external GNSS facility couplings stored in the VU
|
|
VuCalibrationRecordArray
|
|
All calibration records stored in the VU.
|
|
VuCardRecordArray
|
|
All card insertion data stored in the VU.
|
|
VuITSConsentRecordArray
|
|
|
|
VuPowerSupplyInterruptionRecordArray
|
|
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
Data structure generation 2, version 2 (TREP 35 Hex)
|
Comment
|
|
Data element
|
|
|
|
VuIdentificationRecordArray
|
|
|
|
VuSensorPairedRecordArray
|
|
All MS pairings stored in the VU
|
|
VuSensorExternalGNSSCoupledRecordArray
|
|
All external GNSS facility couplings stored in the VU
|
|
VuCalibrationRecordArray
|
|
All calibration records stored in the VU.
|
|
VuCardRecordArray
|
|
All card insertion data stored in the VU.
|
|
VuITSConsentRecordArray
|
|
|
|
VuPowerSupplyInterruptionRecordArray
|
|
|
|
SignatureRecordArray
|
|
ECC signature of all preceding data.
|
’;
(c)in point 3.3, paragraph DDP_035 is replaced by the following
‘DDP_035
The download of a tachograph card includes the following steps:
-
Download the common information of the card in the EFs ICC and IC. This information is optional and is not secured with a digital signature.
-
For first and second generation tachograph cards
-
Download EFs within Tachograph DF:
-
Download the EFs Card_Certificate and CA_Certificate. This information is not secured with a digital signature.
It is mandatory to download these files for each download session.
-
Download the other application data EFs (within Tachograph DF) except EF Card_Download. This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part A.
-
It is mandatory to download at least the EFs Application_Identification and Identification for each download session.
-
When downloading a driver card it is also mandatory to download the following EFs:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions.
-
For second generation tachograph cards only:
-
Except when a download of a driver card inserted in a VU is performed during drivers' control by a non EU control authority, using a first generation control card, download EFs within Tachograph_G2 DF:
-
Download the EFs CardSignCertificate, CA_Certificate and Link_Certificate. This information is not secured with a digital signature.
-
It is mandatory to download these files for each download session.
-
Download the other application data EFs (within Tachograph_G2 DF) except EF Card_Download. This information is secured with a digital signature, using Appendix 11 Common Security Mechanisms Part B.
-
It is mandatory to download at least the EFs Application_Identification, Application_Identification_V2 (if present) and Identification for each download session.
-
When downloading a driver card it is also mandatory to download the following EFs:
Events_Data,
Faults_Data,
Driver_Activity_Data,
Vehicles_Used,
Places,
Control_Activity_Data,
Specific_Conditions,
VehicleUnits_Used,
GNSS_Places,
Places_Authentication, if present,
GNSS_Places_Authentication, if present,
Border_Crossings, if present,
Load_Unload_Operations, if present,
Load_Type_Entries, if present.
-
When downloading a driver card, update the LastCardDownload date in EF Card_Download, in the Tachograph and, if applicable, Tachograph_G2 DFs.
-
When downloading a workshop card, reset the calibration counter in EF Card_Download in the Tachograph and, if applicable, Tachograph_G2 DFs.
-
When downloading a workshop card the EF Sensor_Installation_Data in the Tachograph and, if applicable, Tachograph_G2 DFs shall not be downloaded.’;
(35)Appendix 8 is amended as follows:
(a)the Table of Content is amended as follows:
(i)points 8, 8.1 and 8.2 are replaced by the following:
‘8.
ROUTINECONTROL SERVICE (TIME ADJUSTMENT)
8.1.
Message description
8.2.
Message format’;
(ii)the following points 9, 9.1 and 9.2 are added:
‘9.
DATARECORDS FORMATS
9.1.
Transmitted parameter ranges
9.2.
dataRecords formats’;
(b)in point 3.1, the following row is added to Table 1:
‘
|
|
Diagnostic Sessions
|
|
RoutineControl
|
8
|
31
|
|
■
|
■
|
’;
(c)in point 6.1.3, paragraph CPR_053 is replaced by the following:
‘CPR_053
recordDataIdentifier values defined by this document are shown in the table below.
The recordDataIdentifier table consists of five columns and multiple lines.
-
The 1st column (Hex) includes the ‘Hex Value’ assigned to the recordDataIdentifier specified in the 3rd column.
-
The 2nd column (Data element) specifies the data element of Appendix 1 on which the recordDataIdentifier is based (transcoding is sometimes necessary).
-
The 3rd column (Description) specifies the corresponding recordDataIdentifier name.
-
The 4th column (Access rights) specifies the access rights to this recordDataIdentifier.
-
The 5th column (Mnemonic) specifies the mnemonic of this recordDataIdentifier.
Table 28
Definition of recordDataIdentifier values
|
Hex
|
Data element
|
recordDataIdentifier Name
(see format in Section 8.2)
|
Access rights
(Read/Write)
|
Mnemonic
|
|
F90B
|
CurrentDateTime
|
TimeDate
|
R/W
|
RDI_TD
|
|
F912
|
HighResOdometer
|
HighResolutionTotalVehicleDistance
|
R/W
|
RDI_HRTVD
|
|
F918
|
K-ConstantOfRecordingEquipment
|
Kfactor
|
R/W
|
RDI_KF
|
|
F91C
|
L-TyreCircumference
|
LfactorTyreCircumference
|
R/W
|
RDI_LF
|
|
F91D
|
W-VehicleCharacteristicConstant
|
WvehicleCharacteristicFactor
|
R/W
|
RDI_WVCF
|
|
F921
|
TyreSize
|
TyreSize
|
R/W
|
RDI_TS
|
|
F922
|
nextCalibrationDate
|
NextCalibrationDate
|
R/W
|
RDI_NCD
|
|
F92C
|
SpeedAuthorised
|
SpeedAuthorised
|
R/W
|
RDI_SA
|
|
F97D
|
vehicleRegistrationNation
|
RegisteringMemberState
|
R/W
|
RDI_RMS
|
|
F97E
|
VehicleRegistrationNumber
|
VehicleRegistrationNumber
|
R/W
|
RDI_ VRN
|
|
F190
|
VehicleIdentificationNumber
|
VIN
|
R/W
|
RDI_ VIN
|
|
F9D0
|
SensorSerialNumber
|
MotionSensorSerialNumber
|
R
|
RDI_SSN
|
|
F9D1
|
RemoteCommunicationModuleSerialNumber
|
RemoteCommunicationFacilitySerialNumber
|
R
|
RDI_RCSN
|
|
F9D2
|
SensorGNSSSerialNumber
|
ExternalGNSSFacilitySerialNumber
|
R
|
RDI_GSSN
|
|
F9D3
|
SealDataVu
|
SmartTachographSealsSerialNumber
|
R/W
|
RDI_SDV
|
|
F9D4
|
VuSerialNumber
|
VuSerialNumber
|
R
|
RDI_VSN
|
|
F9D5
|
ByDefaultLoadType
|
ByDefaultLoadType
|
R/W
|
RDI_BDLT
|
|
F9D6
|
TachographCardsGen1Suppression
|
TachographCardsGen1Suppression
|
R/W
|
RDI_TCG1S
|
|
F9D7
|
VehiclePosition
|
VehiclePosition
|
R
|
RDI_VP
|
|
F9D8
|
LastCalibrationCountry
|
CalibrationCountry
|
R
|
RDI_CC
|
’;
(d)point 8 is replaced by the following:
‘8.
ROUTINECONTROL SERVICE (TIME ADJUSTMENT)
8.1.
Message description
CPR_065a
The service RoutineControl (TimeAdjustment) provides the ability to trigger an alignment of the VU clock to the time provided by the GNSS receiver.
For the service RoutineControl (TimeAdjustment) execution the VU must be in CALIBRATION mode.
Precondition: it is ensured that the VU is able to receive authenticated position messages from the GNSS receiver.
As long the time adjustment is ongoing, the VU shall respond to the request RoutineControl, subfunction requestRoutineResults, with routineInfo = 0x78.
Note: the time adjustment may take some time. The diagnostic tester shall request the time adjustment status by using the sub-function requestRoutineResults.
8.2.
Message format
CPR_065b
The message formats for the service RoutineControl (TimeAdjustment) and its primitives are detailed in the following tables.
Table 37a
RoutineControl, routine (TimeAdjustment) Request Message, subfunction startRoutine
|
Byte #
|
Parameter Name
|
Hex Value
|
Mnemonic
|
|
#1
|
Format byte - physical addressing
|
80
|
FMT
|
|
#2
|
Target address byte
|
EE
|
TGT
|
|
#3
|
Source address byte
|
tt
|
SRC
|
|
#4
|
Additional length byte
|
xx
|
LEN
|
|
#5
|
RoutineControl Request Sid
|
31
|
RC
|
|
#6
|
routineControlType = [startRoutine]
|
01
|
RCTP_STR
|
|
#7 and #8
|
routineIdentifier = [TimeAdjustment]
|
0100
|
RI_TA
|
|
#9
|
Checksum
|
00-FF
|
CS
|
Table 37b
RoutineControl, routine (TimeAdjustment), subfunction startRoutine, Positive Response Message
|
Byte #
|
Parameter Name
|
Hex Value
|
Mnemonic
|
|
#1
|
Format byte – physical addressing
|
80
|
FMT
|
|
#2
|
Target address byte
|
tt
|
TGT
|
|
#3
|
Source address byte
|
EE
|
SRC
|
|
#4
|
Additional length byte
|
xx
|
LEN
|
|
#5
|
RoutineControl Positive Response Sid
|
71
|
RCPR
|
|
#6
|
routineControlType = [startRoutine]
|
01
|
RCTP_STR
|
|
#7 and #8
|
routineIdentifier= [TimeAdjustment]
|
0100
|
RI_TA
|
|
#9
|
Checksum
|
00-FF
|
CS
|
Table 37c
RoutineControl, routine (TimeAdjustment) Request Message, subfunction requestRoutineResults
|
Byte #
|
Parameter Name
|
Hex Value
|
Mnemonic
|
|
#1
|
Format byte - physical addressing
|
80
|
FMT
|
|
#2
|
Target address byte
|
EE
|
TGT
|
|
#3
|
Source address byte
|
tt
|
SRC
|
|
#4
|
Additional length byte
|
xx
|
LEN
|
|
#5
|
RoutineControl Request Sid
|
31
|
RC
|
|
#6
|
routineControlType = [requestRoutineResults]
|
03
|
RCTP_RRR
|
|
#7 and #8
|
routineIdentifier= [TimeAdjustment]
|
0100
|
RI_TA
|
|
#9
|
Checksum
|
00-FF
|
CS
|
Table 37d
RoutineControl, routine (TimeAdjustment), subfunction requestRoutineResults, Positive Response Message
|
Byte #
|
Parameter Name
|
Hex Value
|
Mnemonic
|
|
#1
|
Format byte – physical addressing
|
80
|
FMT
|
|
#2
|
Target address byte
|
tt
|
TGT
|
|
#3
|
Source address byte
|
EE
|
SRC
|
|
#4
|
Additional length byte
|
xx
|
LEN
|
|
#5
|
RoutineControl Positive Response Sid
|
71
|
RCPR
|
|
#6
|
routineControlType = [requestRoutineResults]
|
03
|
RCTP_RRR
|
|
#7 and #8
|
routineIdentifier= [TimeAdjustment]
|
0100
|
RI_TA
|
|
#9
|
routineInfo (see Table 37f)
|
XX
|
RINF_TA
|
|
#10
|
routineStatusRecord[] = routineStatus#1 (see Table 37g)
|
XX
|
RS_TA
|
|
#11
|
Checksum
|
00-FF
|
CS
|
Table 37e
RoutineControl, routine (TimeAdjustment) Negative Response Message
|
Byte #
|
Parameter Name
|
Hex Value
|
Mnemonic
|
|
#1
|
Format byte – physical addressing
|
80
|
FMT
|
|
#2
|
Target address byte
|
tt
|
TGT
|
|
#3
|
Source address byte
|
EE
|
SRC
|
|
#4
|
Additional length byte
|
03
|
LEN
|
|
#5
|
negativeResponse Service Id
|
7F
|
NR
|
|
#6
|
inputOutputControlByIdentifier Request SId
|
31
|
RC
|
|
#7
|
responseCode=[
sub-functionNotSupported
incorrectMessageLengthOrInvalidFormat
conditionsNotCorrect
requestOutOfRange
]
|
12
13
22
31
|
SFNS
IMLOIF
CNC
ROOR
|
|
#8
|
Checksum
|
00-FF
|
CS
|
Table 37f
RoutineControl, routine (TimeAdjustment), routineInfo
|
routineInfo
|
Hex Value
|
Description
|
|
NormalExitWithResultAvailable
|
61
|
The routine was executed completely; additional routine results available.
|
|
RoutineExecutionOngoing
|
78
|
The requested routine is still executed.
|
Table 37g
RoutineControl, routine (TimeAdjustment), routineStatus
|
Hex Value
|
Test result
|
Description
|
|
01
|
positive
|
The time adjustment successfully finished.
|
|
02..0F
|
|
RFU
|
|
10
|
negative
|
No GNSS signal reception.
|
|
11..7F
|
|
RFU
|
|
80..FF
|
|
Manufacturer specific
|
’;
(e)the following point 9 is added:
‘9.
DATARECORDS FORMATS
This section details:
-
general rules that shall be applied to ranges of parameters transmitted by the vehicle unit to the tester,
-
formats that shall be used for data transferred via the Data Transmission Services described in section 6.
CPR_067
All parameters identified shall be supported by the VU.
CPR_068
Data transmitted by the VU to the tester in response to a request message shall be of the measured type (i.e. current value of the requested parameter as measured or observed by the VU).
9.1.
Transmitted parameter ranges
CPR_069
Table 38 defines the ranges used to determine the validity of a transmitted parameter.
CPR_070
The values in the range «error indicator» provide a means for the vehicle unit to immediately indicate that valid parametric data is not currently available due to some type of error in the tachograph.
CPR_071
The values in the range «not available» provide a means for the vehicle unit to transmit a message which contains a parameter that is not available or not supported in that module. The values in the range «not requested» provide a means for a device to transmit a command message and identify those parameters where no response is expected from the receiving device.
CPR_072
If a component failure prevents the transmission of valid data for a parameter, the error indicator as described in Table 38 should be used in place of that parameter’s data. However, if the measured or calculated data has yielded a value that is valid yet exceeds the defined parameter range, the error indicator should not be used. The data should be transmitted using the appropriate minimum or maximum parameter value.
Table 38
dataRecords ranges
|
Range Name
|
1 byte
(Hex value)
|
2 bytes
(Hex value)
|
4 bytes
(Hex Value)
|
ASCII
|
|
Valid signal
|
00 to FA
|
0000 to FAFF
|
00000000 to FAFFFFFF
|
1 to 254
|
|
Parameter specific indicator
|
FB
|
FB00 to FBFF
|
FB000000 to FBFFFFFF
|
none
|
|
Reserved range for future indicator bits
|
FC to FD
|
FC00 to FDFF
|
FC000000 to FDFFFFFF
|
none
|
|
Error indicator
|
FE
|
FE00 to FEFF
|
FE000000 to FEFFFFFF
|
0
|
|
Not available or not requested
|
FF
|
FF00 to FFFF
|
FF000000 to FFFFFFFF
|
FF
|
CPR_073
For parameters coded in ASCII, the ASCII character ‘*’ is reserved as a delimiter.
9.2.
dataRecords formats
Table 39 to Table 42 below detail the formats that shall be used via the ReadDataByIdentifier and WriteDataByIdentifier Services.
CPR_074
Table 39 provides the length, resolution and operating range for each parameter identified by its recordDataIdentifier:
Table 39
Format of dataRecords
|
Parameter Name
|
Data length (bytes)
|
Resolution
|
Operating range
|
|
TimeDate
|
8
|
See details in Table 40
|
|
HighResolutionTotalVehicleDistance
|
4
|
5 m/bit gain, 0 m offset
|
0 to +21 055 406 km
|
|
Kfactor
|
2
|
0.001 pulse/m /bit gain, 0 offset
|
0 to 64.255 pulse/m
|
|
LfactorTyreCircumference
|
2
|
0.125 10-3 m /bit gain, 0 offset
|
0 to 8.031 m
|
|
WvehicleCharacteristicFactor
|
2
|
0.001 pulse/m /bit gain, 0 offset
|
0 to 64.255 pulse/m
|
|
TyreSize
|
15
|
ASCII
|
ASCII
|
|
NextCalibrationDate
|
3
|
See details in Table 41
|
|
SpeedAuthorised
|
2
|
1/256 km/h/bit gain, 0 offset
|
0 to 250.996 km/h
|
|
RegisteringMemberState
|
3
|
ASCII
|
ASCII
|
|
VehicleRegistrationNumber
|
14
|
See details in Table 42
|
|
VIN
|
17
|
ASCII
|
ASCII
|
|
SealDataVu
|
55
|
See details in Table 43
|
|
ByDefaultLoadType
|
1
|
See details in Table 44
|
|
VuSerialNumber
|
8
|
See details in Table 45
|
|
SensorSerialNumber
|
8
|
See details in Table 45
|
|
SensorGNSSSerialNumber
|
8
|
See details in Table 45
|
|
RemoteCommunicationModuleSerialNumber
|
8
|
See details in Table 45
|
|
TachographCardsGen1Suppression
|
2
|
See details in Table 46
|
|
VehiclePosition
|
14
|
See details in Table 47
|
|
CalibrationCountry
|
3
|
ASCII
|
NationAlpha as defined in Appendix 1
|
CPR_075
Table 40 details the formats of the different
bytes of the TimeDate parameter:
Table 40
Detailed format of TimeDate (recordDataIdentifier value # F90B)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1
|
|
0.25 s/bit gain, 0 s offset
|
0 to 59.75s
|
|
2
|
Minutes
|
1 min/bit gain, 0 min offset
|
0 to 59 min
|
|
3
|
Hours
|
1 h/bit gain, 0 h offset
|
0 to 23 h
|
|
4
|
Month
|
1 month/bit gain, 0 month offset
|
1 to 12 month
|
|
5
|
Day
|
0.25 day/bit gain, 0 day offset (see NOTE below Table 41)
|
0.25 to 31.75 day
|
|
6
|
Year
|
1 year/bit gain, +1985 year offset
(see NOTE below Table 41)
|
1985 to 2235 year
|
|
7
|
Local Minute Offset
|
1 min/bit gain, -125 min offset
|
-59 to +59 min
|
|
8
|
Local Hour Offset
|
1 h/bit gain, -125 h offset
|
- 23 to +23 h
|
CPR_076
Table 41 details the formats of the different
bytes of the NextCalibrationDate parameter:
Table 41
Detailed format of NextCalibrationDate (recordDataIdentifier value # F922)
|
|
Parameter definition
|
Resolution
|
Operating range
|
|
1
|
Month
|
1 month/bit gain, 0 month offset
|
1 to 12 month
|
|
2
|
Day
|
0.25 day/bit gain, 0 day offset (see NOTE below)
|
0.25 to 31.75 day
|
|
3
|
Year
|
1 year/bit gain, +1985 year offset
(see NOTE below)
|
1985 to 2235 year
|
NOTE concerning the use of the ‘Day’ parameter:
1)
A value of 0 for the date is null. The values 1, 2, 3, and 4 are used to identify the first day of the month; 5, 6, 7, and 8 identify the second day of the month; etc.
2)
This parameter does not influence or change the hours parameter above.
NOTE concerning the use of the ‘Year’ parameter:
A value of 0 for the year identifies the year 1985; a value of 1 identifies 1986; etc.
CPR_078
Table 42 details the formats of the different bytes of the VehicleRegistrationNumber parameter:
Table 42
Detailed format of VehicleRegistrationNumber (recordDataIdentifier value # F97E)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1
|
|
not applicable
|
VehicleRegistrationNumber
|
|
2 – 14
|
Vehicle Registration Number (as defined in Appendix 1)
|
not applicable
|
VehicleRegistrationNumber
|
CPR_090
Table 43 details the formats of the different
bytes of the SealDataVu parameter:
Table 43
Detailed format of SealDataVu (recordDataIdentifier value # F9D3)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1 – 11
|
|
not applicable
|
SealRecord
|
|
12 - 22
|
|
not applicable
|
SealRecord
|
|
23 – 33
|
|
not applicable
|
SealRecord
|
|
34 – 44
|
|
not applicable
|
SealRecord
|
|
45 – 55
|
sealRecord5. Format SealRecord as defined in Appendix 1.
|
not applicable
|
SealRecord
|
NOTE:
If there are less than 5 seals available the value of the EquipmentType in all unused sealRecords shall be set to 15, i.e. unused.
CPR_091
Table 44 details the formats of the different
bytes of the ByDefaultLoadType parameter:
Table 44
Detailed format of ByDefaultLoadType (recordDataIdentifier value # F9D5)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1
|
|
not applicable
|
'00'H to '02'H
|
CPR_092
Table 45 details the formats of the different bytes of the VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber parameters:
Table 45
Detailed format of VuSerialNumber, SensorSerialNumber, SensorGNSSSerialNumber and RemoteCommunicationModuleSerialNumber (recordDataIdentifier values # F9D4, F9D0, F9D2, F9D1)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1
|
|
not applicable
|
ExtendedSerialNumber
|
CPR_093
Table 46 details the formats of the different bytes of the TachographCardsGen1Suppression parameter:
Table 46
Detailed format of TachographCardsGen1Suppression (recordDataIdentifier value # F9D6)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1-2
|
|
not applicable
|
'0000'H, 'A5E3'H
|
CPR_094
Table 47 details the formats of the different bytes of the VehiclePosition parameter.
Table 47
Detailed format of VehiclePosition (recordDataIdentifier value # F9D7)
|
Byte
|
Parameter definition
|
Resolution
|
Operating range
|
|
1 - 4
|
Time stamp of the vehicle position was determined.
|
Not applicable
|
TimeReal
|
|
5
|
GNSS accuracy
|
Not applicable
|
GNSSAccuracy
|
|
6 - 11
|
Vehicle position
|
Not applicable
|
GeoCoordinates
|
|
12
|
Authentication status
|
Not applicable
|
PositionAuthenticationStatus
|
|
13
|
Current country
|
Not applicable
|
NationNumeric
|
|
14
|
Current region
|
Not applicable
|
RegionNumeric
|
Note: after vehicle position update, the update of current country and region may be delayed.’;
(36)Appendix 9 is amended as follows:
(a)in the Table of Content, the following point 9 is added:
‘9.
OSNMA TESTS’;
(b)point 1 is amended as follows:
(i)in point 1.1, the following sub-paragraph is added:
‘The Member States authority in charge of the functional tests of a vehicle unit or an external GNSS facility must make sure that the embedded GNSS receiver has successfully passed the OSNMA tests specified in this Appendix. These tests are considered to be a part of the functional tests of the vehicle unit or the external GNSS facility.’;
(ii)in point 1.2, the following reference is added:
‘RGODP
JRC Technical Report - Receiver guidelines for OSNMA data processing’;
(c)in point 2, rows 3.1 to 3.41 are replaced by the following:
‘
|
3.1
|
Functions provided
|
02, 03, 04, 05, 07, 382,
|
|
3.2
|
Modes of operation
|
09 to 11*, 134, 135
|
|
3.3
|
Functions and data access rights
|
12*, 13*, 382, 383, 386 to 389
|
|
3.4
|
Monitoring cards insertion and withdrawal
|
15, 16, 17, 18, 19*, 20*, 134
|
|
3.5
|
Speed, position and distance measurement
|
21 to 37
|
|
3.6
|
Time measurement (test performed at 20°C)
|
38 to 43
|
|
3.7
|
Monitoring driver activities
|
44 to 53, 134
|
|
3.8
|
Monitoring driving status
|
54, 55, 134
|
|
3.9
|
Driver’s entries
|
56 to 62c
|
|
3.10
|
Company locks management
|
63 to 68
|
|
3.11
|
Monitoring control activities
|
69, 70
|
|
3.12
|
Detection of events and/or faults
|
71 to 88a, 134
|
|
3.13
|
Equipment identification data
|
93*, 94*, 97, 100
|
|
3.14
|
Driver or workshop card insertion and withdrawal data
|
102* to 104*
|
|
3.15
|
Driver activity data
|
105* to 107*
|
|
3.16
|
Places and positions data
|
108* to 112*
|
|
3.17
|
Odometer data
|
113* to 115*
|
|
3.18
|
Detailed speed data
|
116*
|
|
3.19
|
Events data
|
117*
|
|
3.20
|
Faults data
|
118*
|
|
3.21
|
Calibration data
|
119* to 121*
|
|
3.22
|
Time adjustment data
|
124*, 125*
|
|
3.23
|
Control activity data
|
126*, 127*
|
|
3.24
|
Company locks data
|
128*
|
|
3.25
|
Download activity data
|
129*
|
|
3.26
|
Specific conditions data
|
130*, 131*
|
|
3.27
|
Tachograph cards data
|
132*, 133*
|
|
3.28
|
Border crossings
|
133a* to 133d*
|
|
3.29
|
Load/unload operation
|
133e* to 133i*
|
|
3.30
|
Digital map
|
133j* to 133t*
|
|
3.31
|
Recording and storing on tachographs cards
|
136, 137, 138*, 139*, 141*, 142, 143
144, 145, 146*, 147*, 147a*, 147b*, 148*, 149, 150, 150a
|
|
3.32
|
Displaying
|
90, 134,
151 to 168,
PIC_001, DIS_001
|
|
3.33
|
Printing
|
90, 134,
169 to 181, PIC_001, PRT_001 to PRT_014
|
|
3.34
|
Warning
|
134, 182 to 191,
PIC_001
|
|
3.35
|
Data downloading to external media
|
90, 134, 192 to 196
|
|
3.36
|
Remote communication for targeted roadside checks
|
197 to 199
|
|
3.37
|
Data exchanges with additional external devices
|
200, 201
|
|
3.38
|
Calibration
|
202 to 206*, 383, 384, 386 to 391
|
|
3.39
|
Roadside calibration checking
|
207 to 209
|
|
3.40
|
Time adjustment
|
210 to 212*
|
|
3.41
|
Monitoring border crossings
|
226a to 226c
|
|
3.42
|
Software update
|
226d to 226f
|
|
3.43
|
Non-interference of additional functions
|
06, 425
|
|
3.44
|
Motion sensor interface
|
02, 122
|
|
3.45
|
External GNSS facility
|
03, 123
|
|
3.46
|
Verify that the VU detects, records and stores the event(s) and/or fault(s) defined by the VU manufacturer when a paired motion sensor reacts to magnetic fields disturbing vehicle motion detection.
|
217
|
|
3.47
|
Cypher suite and standardized domain parameters
|
CSM_48, CSM_50
|
’;
(d)the following point 9 is added:
‘9.
OSNMA TESTS
9.1.
Introduction
This chapter describes the tests to prove the correct implementation of OSNMA in the GNSS receiver. Since satellite signal authentication is carried out solely by the GNSS receiver with independence of any other component of the tachograph, the tests set out in this chapter may be performed on the GNSS receiver as a stand-alone element. In this case, the tachograph manufacturer shall present a report to the type-approval authorities providing details about the development and results of the tests that are performed under the responsibility of the GNSS receiver manufacturer.
9.2
Applicable conditions
-
The pass/fail criteria defined in the OSNMA tests shall be considered valid only for the identified testing conditions.
-
The criteria might be revised at the moment of the Galileo OSNMA service declaration and considering the associated service performance commitments.
9.3.
Definitions and acronyms
9.3.1
Definitions
GNSS cold/warm/hot start:
refers to the start condition of a GNSS receiver based on the availability of time (T), current almanac (A) and ephemeris (E), position (P):
-
GNSS Cold Start: none
-
GNSS Warm Start: T, A, P
-
GNSS Hot Start: T, A, E, P
OSNMA cold/warm/hot start:
refers to the start condition of the OSNMA function based on the availability of the Public Key (P) and DSM-KROOT (K) information (as defined in the OSNMA Receiver Guidelines referred to in Appendix 12):
-
OSNMA Cold Start: none
-
OSNMA Warm Start: P
-
OSNMA Hot Start: P, K
9.3.2
Acronyms
ADKD
Authentication Data & Key Delay
DSM-KROOT
Digital Signature Message KROOT
GNSS
Global Navigation Satellite System
KROOT
Root Key of the TESLA key chain
MAC
Message Authentication Code
NMACK
Number of MAC & key blocks (per 30 seconds)
OSNMA
Galileo Open Service Navigation Message Authentication
SLMAC
Slow MAC
TESLA
Timed Efficient Stream Loss-tolerant Authentication (Protocol used in OSNMA)
9.4.
Equipment for the generation of the GNSS signals
The generation of the GNSS signals can be carried out using a multi-constellation GNSS simulator supporting OSNMA message transmission. Alternatively, a radiofrequency signal re-player capable of playing back GNSS signal samples from files can be used. Typical bit depth and sampling rate are respectively 4 bits I/Q and 10MHz.
It is assumed that the GNSS receiver has interfaces to command the clearing of the receiver memory (to independently erase the public key, KROOT, clock information, position information, ephemeris and almanac), to set the receiver local time realisation for the OSNMA timing verification requirement, and to load the cryptographic information. These commands may be limited to test purposes and therefore may not be available for the receiver nominal operation.
9.5
Test conditions
9.5.1
GNSS conditions
The simulated or replayed GNSS signals will have the following features:
-
Static user receiver scenario;
-
At least GPS and Galileo constellations;
-
E1/L1 frequency;
-
At least 4 Galileo satellites with elevation angle greater than 5°;
-
Duration as required for each test;
-
Constant navigation ephemerides from the satellites during the test.
9.5.2
OSNMA conditions
The OSNMA message transmitted in the RF signal will have the following features:
-
An HKROOT message with OSNMA Status set to Operational or Test and a fixed DSM-KROOT of 8 blocks for the chain in force;
-
At least 4 Galileo satellites transmitting OSNMA;
-
A MACK message with one MACK block (i.e. NMACK=1), and at least one ADKD=0 and one ADKD=12 per satellite and MACK block;
-
A tag size of 40 bits;
-
The minimum equivalent tag length as required in the OSNMA Receiver Guidelines (currently 80 bits).
Except when noted, the internal receiver time realisation shall be known with sufficient accuracy and properly aligned with the simulated time. This guarantees that the OSNMA initial time synchronisation requirement is fulfilled for each test condition, i.e., nominal synchronization for all but the SLMAC test. See the OSNMA Receiver Guidelines for more details on the time initialization.
Note that the identified pass/fail criteria are conservative and do not represent the expected Galileo OSNMA performance.
9.6.
Tests specification
|
No
|
Test
|
Description
|
Related requirements
|
|
1.
|
Administrative examination
|
|
1.1
|
Documentation
|
Correctness of documentation
|
|
|
|
General Tests
|
|
|
OSNMA hot start
|
Objective: verify that the GNSS receiver computes a position with OSNMA after a hot start.
Procedure:
The GNSS receiver starts in GNSS and OSNMA hot start conditions and acquires the signals of visible Galileo satellites.
The receiver authenticates the Galileo navigation data with OSNMA (ADKD = 0) and provides a position with authenticated data.
Pass/fail criteria: the receiver computes an authenticated position fix within 160 seconds.
|
Appendix 12,
GNS_3b
|
|
|
OSNMA warm start
|
Objective: verify that the GNSS receiver computes a position with OSNMA after a warm start.
Procedure:
Before starting the test, the ephemeris and KROOT information shall be erased from the GNSS receiver memory in order to force a warm GNSS and OSNMA start.
The GNSS receiver starts and acquires the signals of the visible Galileo satellites.
The DSM-KROOT is received and verified.
The receiver authenticates the Galileo navigation data with OSNMA (ADKD=0) and provides a position with authenticated data.
Pass/fail criteria: the receiver computes an authenticated valid position fix within 430 seconds.
|
Appendix 12,
GNS_3b
|
|
|
OSNMA warm start with SLMAC
|
Objective: verify that the GNSS receiver computes a position with OSNMA after a warm start with a time initialisation requiring SLMAC mode, as defined in the OSNMA Receiver Guidelines.
Procedure:
The internal receiver time realisation shall be configured in order to have an initial time uncertainty of a value between 2 and 2.5 minutes so that, according to OSNMA Receiver Guidelines, the Slow MAC mode is activated.
Before starting the tests, the ephemeris and KROOT information shall be erased from the GNSS receiver memory in order to force a warm GNSS and OSNMA start.
The GNSS receiver starts and acquires the signals of the visible Galileo satellites.
The DSM-KROOT is received and verified.
The receiver authenticates the Galileo navigation data with only OSNMA Slow MAC (ADKD=12) and provides a position with authenticated data.
Pass/fail criteria: the receiver computes an authenticated valid position fix within 730 seconds.
|
Appendix 12,
GNS_3b
|
|
|
OSNMA hot start with replayed signal
|
Objective: verify that the GNSS receiver detects a replayed signal.
Procedure:
The GNSS receiver starts in GNSS and OSNMA hot start conditions and acquires the signals of visible Galileo satellites.
The receiver authenticates the Galileo navigation data with OSNMA (ADKD=0) and provides a position with authenticated data.
Once the receiver provides PVT solution with authenticated data, it is switched off.
A replayed signal with a delay of 40 seconds with respect to the previous one is simulated, and the receiver is switched on.
The receiver detects that the Galileo System Time from the signal-in-space time and the local timing realisation do not meet the synchronisation requirement and it stops processing OSNMA data as defined in OSNMA Receiver Guidelines.
Pass/fail criteria: the receiver detects the replay and does not compute an authenticated valid position since the start of the replay until the end of the test.
|
Appendix 12,
GNS_3b
|
|
|
OSNMA hot start with false data
|
Objective: Verify that OSNMA detects false data.
Procedure:
The GNSS receiver starts in GNSS and OSNMA hot start conditions.
The GNSS receiver shall be able to acquire the signal of all the visible Galileo satellites and verify the authenticity of their navigation messages by means of OSNMA.
At least one bit of the ephemeris data provided by each Galileo satellite does not correspond with the original and authenticated data, but the Galileo I/NAV message must be coherent, including CRC.
Pass/fail criteria: the receiver detects the false data within 160 seconds and does not compute an authenticated valid position until the end of the test.
|
Appendix 12,
GNS_3b
|
’;
(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:
‘1.1.1
References’;
(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
4.2.5
Other commands’;
(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
7.
GNSS TIME CONFLICT’;
(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):
Figure 2
Structure of the RMC sentence
$--RMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1)
Time (UTC)
2)
Status, A= Valid position, V= Warning
3)
Latitude
4)
N or S
5)
Longitude
6)
E or W
7)
Speed over ground in knots
8)
Track made good, degrees true
9)
Date, ddmmyy
10)
Magnetic Variation, degrees
11)
E or W
12)
FAA Mode Indicator
13)
Navigational status
14)
Checksum
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/1000 of minute or 1/60000 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):
Figure 3
Structure of the AMC sentence
$--AMC,hhmmss.ss,A,llll.ll,a,yyyyy.yy,a,x.x,x.x,xxxx,x.x,a,a,a*hh
1)
Time (UTC)
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)
3)
Latitude
4)
N or S
5)
Longitude
6)
E or W
7)
Speed over ground in knots
8)
Track made good, degrees true
9)
Date, ddmmyy
10)
Magnetic Variation, degrees
11)
E or W
12)
FAA Mode Indicator
13)
Navigational status
14)
Checksum
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).
Figure 4
Structure of the GSA sentence (standard positions)
$--GSA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
1)
Selection mode
2)
Mode
3)
ID of 1st satellite used for fix
4)
ID of 2nd satellite used for fix
…
14)
ID of 12th satellite used for fix
15)
PDOP
16)
HDOP
17)
VDOP
18)
System ID
19)
Checksum
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.
Figure 5
Structure of the ASA sentence (authenticated positions)
$--ASA,a,a,x,x,x,x,x,x,x,x,x,x,x,x,x.x,x.x,x.x,a*hh
1)
Selection mode
2)
Mode
3)
ID of 1st satellite used for fix
4)
ID of 2nd satellite used for fix
…
14)
ID of 12th satellite used for fix
15)
PDOP
16)
HDOP
17)
VDOP
18)
System ID
19)
Checksum
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.
|
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.
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:
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.’;
(38)Appendix 13 is replaced by the following:
‘
Appendix 13
ITS INTERFACE
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.
INTRODUCTION
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
3.
ITS INTERFACE WORKING PRINCIPLES
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.
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
|
Driver slot
|
|
|
No card
|
Driver card
|
Control card
|
Workshop card
|
Company card
|
|
Co-driver slot
|
No card
|
Not available
|
Available
|
Available
|
Available
|
Available
|
|
|
Driver card
|
Available
|
Available
|
Available
|
Available
|
Available
|
|
|
Control card
|
Available
|
Available
|
Available
|
Not available
|
Not available
|
|
|
Workshop card
|
Available
|
Available
|
Not available
|
Available
|
Not available
|
|
|
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
|
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
|
|
|
Driver card
|
Driver card
|
Driver card (**)
|
Control card
|
Workshop card
|
Company card
|
|
|
Control card
|
Control card
|
Control card
|
Control card (*)
|
Not available
|
Not available
|
|
|
Workshop card
|
Workshop card
|
Workshop card
|
Not available
|
Workshop card (*)
|
Not available
|
|
|
Company card
|
Company card
|
Company card
|
Not available
|
Not available
|
Company card (*)
|
(*) 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.
4.
LIST OF DATA AVAILABLE THROUGH THE ITS INTERFACE AND PERSONAL/NOT PERSONAL CLASSIFICATION
|
Data name
|
Data format
|
Source
|
Data classification (personal/ not personal)
|
Consent for the availability of the data
|
Availability
|
|
|
|
|
driver
|
co-driver
|
|
|
|
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
|
’;
(39)Appendix 14 is amended as follows:
(a)in the Table of Contents, the following point is inserted after point 5.4.8:
‘5.5
Reserved for future use’;
(b)in point 4.1.1.5, paragraph DCS_17 is replaced by the following:
‘DSC_17
Security 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.’;
(c)point 5 is amended as follows:
(i)in point 5.4.4, the TachographPayload sequence in the ASN.1 module definition for the DSRC data within the RTM application, is replaced by the following:
|
‘TachographPayload ∷= SEQUENCE {
|
|
|
tp15638VehicleRegistrationPlate
|
LPN -- Vehicle Registration Plate using the data structure from ISO 14906, but for the RTM application the LPN is fixed to 17 bytes (no length determinant)
|
|
tp15638SpeedingEvent
|
BOOLEAN, -- 1= Irregularities in speed (see Annex IC
|
|
tp15638DrivingWithoutValidCard
|
BOOLEAN,-- 1= Invalid card usage (see Annex IC)
|
|
tp15638DriverCard
|
BOOLEAN,-- 0= Indicates a valid driver card (see Annex IC)
|
|
tp15638CardInsertion
|
BOOLEAN, -- 1= Card insertion while driving (see Annex IC)
|
|
tp15638MotionDataError
|
BOOLEAN, -- 1= Motion data error (see Annex IC)
|
|
tp15638VehicleMotionConflict
|
BOOLEAN, -- 1= Motion conflict (see Annex IC)
|
|
tp156382ndDriverCard
|
BOOLEAN, -- 1= Second driver card inserted (see Annex IC)
|
|
tp15638CurrentActivityDriving
|
BOOLEAN, -- 1= other activity selected;
-- 0= driving selected
|
|
tp15638LastSessionClosed
|
BOOLEAN, -- 1= improperly, 0= properly, closed
|
|
tp15638PowerSupplyInterruption
|
INTEGER (0..127), -- Supply interrupts in the last 10 days
|
|
tp15638SensorFault
|
INTEGER (0..255),-- eventFaultType as per data dictionary
|
|
-- All subsequent time related types as defined in Annex IC.
|
|
tp15638TimeAdjustment
|
INTEGER(0..4294967295), -- Time of the last time adjustment
|
|
tp15638LatestBreachAttempt
|
INTEGER(0..4294967295), -- Time of last breach attempt
|
|
tp15638LastCalibrationData
|
INTEGER(0..4294967295), -- Time of last calibration data
|
|
tp15638PrevCalibrationData
|
INTEGER(0..4294967295), -- Time of previous calibration data
|
|
tp15638DateTachoConnected
|
INTEGER(0..4294967295), -- Date tachograph connected
|
|
tp15638CurrentSpeed
|
INTEGER (0..255), -- Last current recorded speed
|
|
tp15638Timestamp
|
INTEGER(0..4294967295) -- Timestamp of current record
|
|
tp15638LatestAuthenticatedPosition
|
INTEGER(0..4294967295), – Time of latest authenticated position
|
|
tp15638ContinuousDrivingTime
|
INTEGER (0..255), -- Continuous driving time of the driver
|
|
tp15638DailyDrivingTimeShift
|
INTEGER (0..255), -- Longest daily driving time of the driver for the current ongoing and previous RTM-shift
|
|
tp15638DailyDrivingTimeWeek
|
INTEGER (0..255), -- Longest daily driving time of the driver within the current ongoing week
|
|
tp15638WeeklyDrivingTime
|
INTEGER (0..255), -- Weekly driving time of the driver
|
|
tp15638FortnightlyDrivingTime
}
|
INTEGER (0..255) -- Fortnightly driving time of the driver
|
’;
(ii)in point 5.4.5, Table 14.3 is replaced by the following:
‘
Table 14.3
Elements of RtmData, actions performed and definitions
|
(1)
RTM Data Element
|
(2)
Action performed by the VU
|
|
(3)
ASN.1 definition of data
|
|
RTM1
Vehicle Registration
Plate
|
The VU shall set the value of the
tp15638VehicleRegistrationPlate data element RTM1 from the recorded value of the data type
VehicleRegistrationIdentification as
defined in Appendix 1 VehicleRegistrationIdentification
|
Vehicle Registration Plate
expressed as a string of characters
|
tp15638VehicleRegistrationPlate LPN,
--Vehicle RegistrationPlate using the data structure from ISO 14906, but with the following limitation for the RTM application:
the SEQUENCE starts with the Country Code, followed by an alphabet indicator, followed by the plate number itself,
which is always 14 octets (padded with zero's) so the LPN type length is always 17 octets (no length determinant needed), of which 14 are the ‘real’ plate number.
|
|
RTM2
Speeding Event
|
The VU shall generate a Boolean
value for data element RTM2
tp15638SpeedingEvent.
The tp15638SpeedingEvent value shall be calculated by the VU from the over speeding events recorded in the VU within the last 10 days, as defined in Annex IC.
|
1 (TRUE): if the most recent over speeding event ended within the last 10 days or is still ongoing;
0 (FALSE): in any other case.
|
tp15638SpeedingEvent BOOLEAN,
|
|
RTM3
Driving Without
Valid Card
|
The VU shall generate a Boolean
value for data element RTM3
tp15638DrivingWithoutValidCard.
The VU shall assign a value of TRUE to the tp15638DrivingWithoutValidCard variable if at least one driving without an appropriate card event has been recorded in the VU within the last 10 days as defined in Annex IC.
|
1 (TRUE): if the most recent driving without an appropriate card event ended within the last 10 days or is still ongoing;
0 (FALSE): in any other case.
|
tp15638DrivingWithoutValidCard
BOOLEAN,
|
|
RTM4
Valid Driver Card
|
The VU shall generate a Boolean value for data element RTM4
tp15638DriverCard on the basis of the inserted valid driver card in the driver slot.
|
1 (TRUE): if no valid driver card is present in the driver slot of the VU;
0 (FALSE): if a valid driver card is present in the driver slot of the VU.
|
tp15638DriverCard BOOLEAN,
|
|
RTM5
Card Insertion while
Driving
|
The VU shall generate a Boolean value for data element RTM5 tp15638CardInsertion.
The VU shall assign a value of TRUE to the tp15638CardInsertion variable if at least one card insertion while driving event has been recorded in the VU within the last 10 days as defined in Annex IC.
|
1 (TRUE): if the most recent card insertion while driving event has occurred within the last 10 days;
0 (FALSE): in any other case.
|
tp15638CardInsertion BOOLEAN,
|
|
RTM6
Motion Data Error
|
The VU shall generate a Boolean
value for data element RTM6.
The VU shall assign a value of TRUE to the tp15638MotionDataError variable if at least one motion data error event has been recorded in the VU within the last 10 days as defined in Annex IC.
|
1 (TRUE): if the most recent motion data error event ended within the last 10 days or is still ongoing;
0 (FALSE): in any other case.
|
tp15638MotionDataError BOOLEAN,
|
|
RTM7
Vehicle Motion
Conflict
|
The VU shall generate a Boolean
value for data element RTM7.
The VU shall assign a value of TRUE to the tp15638VehicleMotionConflict variable if at least one vehicle motion conflict event has been recorded in the VU within the last 10 days.
|
1 (TRUE): if the most recent vehicle motion conflict event ended within the last 10 days or is still ongoing;
0 (FALSE): in any other case.
|
tp15638VehicleMotionConflict
BOOLEAN,
|
|
RTM8
2nd Driver Card
|
The VU shall generate a Boolean
value for data element RTM8 on the basis of Annex IC (Driver Activity Data CREW and CO-DRIVER).
If a valid co-driver card is present the VU shall set the value of RTM8 to TRUE.
|
1 (TRUE): if a valid co-driver card is present in the VU;
2 (FALSE): if no valid co-driver card is present in the VU.
|
tp156382ndDriverCard BOOLEAN,
|
|
RTM9
Current Activity
|
The VU shall generate a Boolean
value for data element RTM9.
If the current activity is recorded in the VU as any activity other than DRIVING as defined in Annex IC the VU shall set the value of RTM9 to TRUE.
|
1 (TRUE): other activity
selected;
0 (FALSE): driving selected
|
tp15638CurrentActivityDriving
BOOLEAN
|
|
RTM10
Last Session Closed
|
The VU shall generate a Boolean value for data element RTM10.
If the last card session was not properly closed as defined in Annex IC the VU shall set the value of RTM10 to TRUE.
|
1 (TRUE): at least one of the inserted cards has triggered a last card session not correctly closed event;
0 (FALSE): None of the inserted cards has triggered a last card session not correctly closed event.
|
tp15638LastSessionClosed
BOOLEAN
|
|
RTM11
Power Supply
Interruption
|
The VU shall generate an integer
value for data element RTM11.
The VU shall assign a value for the tp15638PowerSupplyInterruption variable equal to the number of the recorded power supply interruption events stored in the VU within last 10 days as defined in Annex IC.
If no power supply interruption event has been recorded in the VU within the last 10 days, it shall set the value of RTM11 to 0.
|
Number of the recorded power supply interruption events within the last 10 days.
|
tp15638PowerSupplyInterruption
INTEGER (0..127),
|
|
RTM12
Sensor Fault
|
The VU shall generate an integer value for data element RTM12.
The VU shall assign to the variable sensorFault a value of:
- 1 if an event of type ‘35’H Sensor
fault ended during the last 10 days or is still ongoing.
- 2 if an event of type GNSS receiver fault (either internal or external with enum values ‘36’H or
‘37’H) ended during the last 10 days or is still ongoing.
- 3 if an event of type ‘0E’H Communication error with the external GNSS facility event ended during the last 10 days or is still ongoing.
- 4 If both Sensor Fault and GNSS receiver faults ended during the last 10 days or are still ongoing.
- 5 If both Sensor Fault and Communication error with the external GNSS facility event ended during the last 10 days or are still ongoing.
- 6 If both GNSS receiver fault and Communication error with the external GNSS facility event ended during the last 10 days or are still ongoing.
- 7 If all three sensor faults ended during the last 10 days or are still ongoing.
If no event have ended during the last 10 days or is still ongoing, the VU shall set the value of RTM12 to 0.
|
--sensor fault one octet as per data dictionary
|
tp15638SensorFault INTEGER (0..255),
|
|
RTM13
Time Adjustment
|
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM13 on the basis of the presence of Time Adjustment data as defined in Annex IC.
The VU shall set the value of RTM13 to the time at which the last time adjustment data event has occurred.
If no time adjustment event as defined in Annex IC is present in the VU data, it shall set the value of RTM13 to 0.
|
oldTimeValue of the most recent time adjustment.
|
tp15638TimeAdjustment
INTEGER(0..4294967295),
|
|
RTM14
Security Breach
Attempt
|
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM14 on the basis of the presence of a security breach attempt event as defined in Annex IC.
The VU shall set the value of the time of the latest security breach attempt event recorded by the VU.
If no security breach attempt event as defined in Annex IC is present in the VU data, it shall set the value of RTM14 to 0.
|
Beginning time of the latest stored security breach attempt event.
|
tp15638LatestBreachAttempt
INTEGER(0..4294967295),
|
|
RTM15
Last Calibration
|
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM15 on the basis of the presence of Last Calibration data as defined in Annex IC and Appendix 1.
The VU shall set the value of
RTM15 to the oldTimeValue of the latest calibration record.
If there has been no calibration, the VU shall set the value of RTM15 to 0.
|
oldTimeValue of the most recent calibration record.
|
tp15638LastCalibrationData
INTEGER(0..4294967295),
|
|
RTM16
Previous Calibration
|
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM16 on the basis of the calibration record preceding the last calibration.
The VU shall set the value of
RTM16 to the oldTimeValue of the calibration record preceding the last calibration.
If there has been no previous calibration, the VU shall set the value of RTM16 to 0.
|
oldTimeValue of the calibration record preceding the most recent calibration record.
|
tp15638PrevCalibrationData
INTEGER(0..4294967295),
|
|
RTM17
Date Tachograph
Connected
|
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM17.
The VU shall set the value of RTM17 to the date of first calibration of the VU in the current vehicle.
The VU shall extract this data from the VuCalibrationData (Appendix 1) from the vuCalibrationRecords with CalibrationPurpose equal to: ’03’H
If there has been no previous calibration, the VU shall set the value of RTM17 to 0.
|
Date of first calibration of the VU in the current vehicle.
|
tp15638DateTachoConnected
INTEGER(0..4294967295),
|
|
RTM18
Current Speed
|
The VU shall generate an integer
value for data element RTM18.
The VU shall set the value of RTM18 to the last current recorded speed at the time of the latest update of the RtmData.
|
Last current recorded speed
|
tp15638CurrentSpeed INTEGER (0..255),
|
|
RTM19
Timestamp
|
The VU shall generate an integer value for data element RTM19 (timeReal from Appendix 1).
The VU shall set the value of RTM19 to the time of the latest update of the RtmData.
|
Timestamp of current
TachographPayload record
|
tp15638Timestamp
INTEGER(0..4294967295),
|
|
RTM20
Time at which the latest authenticated vehicle position was available
|
The VU shall generate an integer value (timeReal from Appendix 1) for data element RTM20.
The VU shall set the value of RTM20 to the time at which the latest authenticated vehicle position was available from the GNSS receiver.
If no authenticated vehicle position was available ever from the GNSS receiver the VU shall set the value of RTM20 to 0.
|
Timestamp of the latest authenticated vehicle position
|
tp15638LatestAuthenticatedPosition
INTEGER(0..4294967295),
|
|
RTM21
Continuous driving time
|
The VU shall generate an integer value for data element RTM21.
The VU shall set the value of RTM21 to the ongoing continuous driving time of the driver.
|
Continuous driving time of the driver, encoded as an integer value.
Length: 1 byte
Resolution: 2 minutes/bit
No offset
Data range: 0 to 250
A value of 250 shall indicate that the continuous driving time of the driver is equal or greater than 500 minutes.
Values 251 to 254 are not used.
Value 255 indicates that the information is not available.
|
tp15638ContinuousDrivingTime INTEGER(0..255),
|
|
RTM22
Longest daily driving time for the ongoing and previous RTM-shift, calculated in accordance with the Addendum to Appendix 14
|
The VU shall generate an integer value for data element RTM22.
The VU shall set the value of RTM22 to the longer of the two daily driving times of the driver, being either the ongoing or the previous RTM-shift.
|
Daily driving time of the driver, encoded as an integer value.
Length: 1 byte
Resolution: 4 minutes/bit
No offset
Data range: 0 to 250
A value of 250 shall indicate that the daily driving time of the driver is equal or greater than 1000 minutes.
Values 251 to 254 are not used.
Value 255 indicates that the information is not available.
|
tp15638DailyDrivingTimeShift INTEGER(0..255),
|
|
RTM23
Longest daily driving time within the ongoing week, calculated in accordance with the Addendum to Appendix 14
|
The VU shall generate an integer value for data element RTM23.
The VU shall set the value of RTM23 to the longest daily driving time of the driver, being either the ongoing RTM-shift or any completed RTM-shift having started or finished in the ongoing week.
|
Daily driving time of the driver, encoded as an integer value.
Length: 1 byte
Resolution: 4 minutes/bit
No offset
Data range: 0 to 250
A value of 250 shall indicate that the daily driving time of the driver is equal or greater than 1000 minutes.
Values 251 to 254 are not used.
Value 255 indicates that the information is not available.
|
tp15638DailyDrivingTimeWeek INTEGER(0..255),
|
|
RTM24
Weekly driving time, calculated in accordance with the Addendum to Appendix 14
|
The VU shall generate an integer value for data element RTM24.
The VU shall set the value of RTM24 to the weekly driving time of the driver.
|
Weekly driving time of the driver, encoded as an integer value.
Length: 1 byte
Resolution: 20 minutes/bit
No offset
Data range: 0 to 250
A value of 250 shall indicate that the weekly driving time of the driver is equal or greater than 5000 minutes.
Values 251 to 254 are not used.
Value 255 indicates that the information is not available.
|
tp15638WeeklyDrivingTime INTEGER(0..255),
|
|
RTM25
Fortnightly driving time, calculated in accordance with the Addendum to Appendix 14
|
The VU shall generate an integer value for data element RTM25.
The VU shall set the value of RTM25 to the fortnightly driving time of the driver.
|
Fortnightly driving time of the driver, encoded as an integer value.
Length: 1 byte
Resolution: 30 minutes/bit
No offset
Data range: 0 to 250
A value of 250 shall indicate that the fortnightly driving time of the driver is equal or greater than 7500 minutes.
Values 251 to 254 are not used.
Value 255 indicates that the information is not available.
|
tp15638FortnightlyDrivingTime INTEGER(0..255),
|
Note: RTM22, RTM23, RTM24 and RTM25 shall be computed according to the Addendum to this Appendix’;
(iii)in point 5.4.7, Table 14.9 is replaced by the following:
‘
Table 14.9
Initialisation – VST frame contents example
|
Octet #
|
Attribute/Field
|
Bits in octet
|
Description
|
|
1
|
FLAG
|
0111 1110
|
Start flag
|
|
2
|
Private LID
|
xxxx xxxx
|
Link address of the specific DSRC-VU
|
|
3
|
|
xxxx xxxx
|
|
|
4
|
|
xxxx xxxx
|
|
|
5
|
|
xxxx xxxx
|
|
|
6
|
MAC Control field
|
1100 0000
|
Command PDU
|
|
7
|
LLC Control field
|
0000 0011
|
UI command
|
|
8
|
Fragmentation header
|
1xxx x001
|
No fragmentation
|
|
9
|
VST
SEQUENCE {
Fill BIT STRING (SIZE(4))
|
1001
|
Initialisation response
|
|
|
|
0000
|
Unused and set to 0
|
|
10
|
Profile INTEGER (0..127,...)
Applications SEQUENCE OF {
|
0000 0000
|
No extension. Example profile 0
No extension, 1 application
|
|
11
|
|
0000 0001
|
|
|
12
|
SEQUENCE {
OPTION indicator
OPTION indicator
AID DSRCApplicationEntityID
|
1
|
EID present
|
|
|
|
1
|
Parameter present
|
|
|
|
00 0010
|
No extension. AID= 2 Freight&Fleet
|
|
13
|
EID Dsrc-EID
|
xxxx xxxx
|
Defined within the OBU and identifying the application instance.
|
|
14
|
Parameter Container {
|
0000 0010
|
No extension, Container Choice = 02,
Octet string
|
|
15
|
|
0000 0110
|
No extension, Rtm Context Mark length = 6
|
|
16
|
Rtm-ContextMark ::= SEQUENCE {
StandardIdentifier
|
0000 0101
|
First octet is 05H, which is its length.
Subsequent 5 octets encode the Object Identifier of the supported standard, part and version.
{ISO (1) Standard (0) TARV (15638) part9(9) Version2 (2)}
|
|
17
|
standardIdentifier
|
0010 1000
|
|
|
18
|
|
1111 1010
|
|
|
19
|
|
0001 0110
|
|
|
20
|
|
0000 1001
|
|
|
21
|
|
0000 0010
|
|
|
22
|
ObeConfiguration Sequence {
OPTION indicator
|
0
|
ObeStatus not present
|
|
|
EquipmentClass INTEGER (0..32767)
|
xxx xxxx
|
This field shall be used to carry
|
|
23
|
|
xxxx xxxx
|
manufacturer’s indications about the software/hardware version of the DSRC interface
|
|
24
|
ManufacturerId INTEGER (0..65535)
|
xxxx xxxx
|
Manufacturer identifier for the DSRC-VU as described in ISO 14816 Register
|
|
25
|
|
xxxx xxxx
|
|
|
26
|
FCS
|
xxxx xxxx
|
Frame check sequence
|
|
27
|
|
xxxx xxxx
|
|
|
28
|
Flag
|
0111 1110
|
End Flag
|
’;
(iv)the following point 5.5 is inserted:
‘5.5
Reserved for future use’;
(v)in point 5.7, paragraphs DSC_77 and DSC_78 are replaced by the following:
‘DSC_77
The Data shall be provided, already secured, by the VUSM function to the DSRC-VU. The VUSM shall verify that data recorded in the DSRC-VU has been transmitted successfully to the DSRC-VU. The recording and reporting of any errors in the transfer of data from the VU to the memory of the DSRC-VU shall be recorded with type EventFaultType and enum value set to ‘0C’H Communication error with the remote communication facility event together with the timestamp. The VUSM shall verify that the data has been transmitted successfully to the DSRC-VU.
DSC_78
Reserved for future use.’;
(d)the following addendum is added:
‘
ADDENDUM
Rules for the computation of daily, weekly and fortnightly driving time
1.
Basic computation rules
The VU shall compute the daily driving time, the weekly driving time and the fortnightly driving time using relevant data stored in a driver (or workshop) card inserted in the driver slot (slot 1, card reader #1) of the Vehicle Unit, and selected driver’s activities while this card is inserted in the VU.
The driving times shall not be calculated while no driver (or workshop) card is inserted.
UNKNOWN period(s) found during the time period needed for computations shall be assimilated to BREAK/REST.
UNKNOWN periods and activities of negative duration (i.e. start of the activity occurs later than the end of the activity) due to time overlaps between two different VUs or due to time adjustment, are not taken into account.
Activities recorded in the driver card corresponding to ‘OUT OF SCOPE’ periods in accordance with definition (gg) of Annex IC, shall be interpreted as follows:
-
BREAK/REST shall be computed as ‘BREAK’ or ‘REST’
-
WORK and DRIVING shall be considered as ‘WORK’
-
AVAILABILITY shall be considered as ‘AVAILABILITY’
In the context of this Addendum, the VU shall assume to have a daily rest period at the beginning of the card activities records.
2.
Concepts
The following concepts apply exclusively to this appendix, and are intended to specify the computation of driving times by the VU and its later transmission by the remote communication facility.
(a)
‘RTM-shift’ is the period between the end of a daily rest period and the end of the directly following daily rest period.
The VU shall start a new RTM-shift after a daily rest period has finished.
The ongoing RTM-shift is the period since the end of last daily rest period;
(b)
‘accumulated driving time’ is the sum of the duration of all DRIVING activities of the driver within a period while not in OUT OF SCOPE;
(c)
‘daily driving time’ is the accumulated driving time within a RTM-shift;
(d)
‘weekly driving time’ is the accumulated driving time for the ongoing week;
(e)
‘continuous rest period’ is any uninterrupted period of BREAK/REST;
(f)
‘fortnightly driving time’ is the accumulated driving time for the previous and the ongoing week;
(g)
‘daily rest period' is a period of BREAK/REST, which can be either
-
a regular daily rest period,
-
a split daily rest period or
-
a reduced daily rest period
In the context of Appendix 14, when a VU is computing weekly rest periods, those weekly rest periods shall be considered as daily rest periods;
(h)
‘regular daily rest period’ is a continuous rest period of at least 11 hours.
As a matter of exception, when a FERRY/TRAIN CROSSING condition is active the regular daily rest period may be interrupted a maximum of two times by activities other than rest, with a maximal accumulated duration of one hour, i.e. the regular daily rest period containing ferry/train crossing period(s) may be split into two or three parts. The VU shall then compute a regular daily rest period when the accumulated rest time computed according to point 3 is at least 11 hours.
When a regular daily rest period has been interrupted the VU:
-
shall not incorporate the driving activity encountered during those interruptions to the computation of the daily driving time, and
-
shall start a new RTM-shift at the end of the regular daily rest period that has been interrupted.
Figure 1. Example of daily rest period interrupted due to ferry/train crossing
(i)
‘reduced daily rest period’ is a continuous rest period of at least 9 hours and less than 11 hours;
(j)
‘split daily rest period’ is a daily rest period taken in two parts:
-
the first part shall be a continuous rest period of at least 3 hours and less than 9,
-
the second part shall be a continuous rest period of at least 9 hours.
As a matter of exception, when a FERRY/TRAIN CROSSING condition is active during one or both of the parts of a split daily rest period, the split daily rest period may be interrupted a maximum of two times by other activities with the accumulated duration of maximal one hour, i.e.:
-
the first part of the split daily rest period may be interrupted one or two times, or
-
the second part of the split daily rest period may be interrupted one or two times, or
-
the first part of the split daily rest period may be interrupted one time and the second part of the split daily rest period may be interrupted one time.
The VU shall then compute a split daily rest period when the accumulated rest time computed according to point 3 is:
- at least three hours and less than 11 hours for the first rest period and at least 9 hours for the second rest period, when the first rest period has been interrupted by FERRY/TRAIN CROSSING.
- at least three hours and less than 9 hours for the first rest period and at least 9 hours for the second rest period, when the first rest period has not been interrupted by FERRY/TRAIN CROSSING.
Figure 2. Example of split daily rest period interrupted due to ferry/train crossing
When the split daily rest period is interrupted, the VU:
-
shall not incorporate the driving activity encountered during those interruptions to the computation of the daily driving time, and
-
shall start a new RTM-shift at the end of the split daily rest period that has been interrupted;
(k)
‘week’ is the period in UTC time between 00:00 hours on Monday and 24:00 hours on Sunday;
3.
Computation of the rest period when it has been interrupted due to ferry/train crossing
For the computation of the rest period when it has been interrupted due to ferry/train crossing, the VU shall calculate the accumulated rest time according to the following steps:
a)
Step 1
The VU shall detect interruptions to the rest time occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag, according to figure 3 and in its case figure 4, and shall evaluate for each interruption detected if the following conditions are met:
-
the interruption makes the total duration of the interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to exceed more than one hour in total,
-
the interruption makes the total number of interruptions detected, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing, to be bigger than two,
-
there is an ‘Entry of place where daily work periods end’ stored after the interruption ended.
If none of the above conditions are met, the continuous rest period immediately preceding the interruption shall be added to the accumulated rest time.
If at least one of the above conditions is met, the VU shall either stop the computation of the accumulated rest time according to step 2 or detect interruptions to the rest time occurring after the FERRY/TRAIN CROSSING (BEGIN) flag according to step 3.
b)
Step 2
For each interruption detected according to step 1, the VU shall evaluate whether the computation of the accumulated rest time should stop. The VU shall stop the computation process when two continuous rest periods occurring before the activation of the FERRY/TRAIN CROSSING (BEGIN) flag have been added to the accumulated rest time, including in its case rest periods added in the first part of a split daily rest period also interrupted by ferry/train crossing. Otherwise, the VU shall proceed according to step 3.
c)
Step 3
If after performance of step 2 the VU continues the computation of the accumulated rest time, the VU shall detect interruptions occurring after the deactivation of the FERRY/TRAIN CROSSING condition according to figure 3 and in its case figure 4.
For each interruption found, the VU shall evaluate if the interruption makes the accumulated time of all the interruptions detected to exceed more than one hour in total, in which case the computation of the accumulated rest period shall finish at the end of the continuous rest period previous to the interruption. Otherwise, the continuous rest periods occurring after the respective interruptions shall be added to the computation of the daily rest period until the condition in step 4 is fulfilled.
d)
Step 4
The computation of the accumulated rest time shall stop when the VU has added, as result of steps 1 and 3, a maximum of two continuous rest periods to the rest period for which the FERRY/TRAIN CROSSING condition is activated, including in its case interruptions occurring during the first part of a split daily rest period due to ferry/train crossing.
Figure 3. Processing of rest times by the VU in order to determine whether an interrupted rest period shall compute as regular daily rest period or as the first part of a split daily rest period
Figure 4. Processing of rest times by the VU in order to determine whether an interrupted rest period shall compute as the second part of a split daily rest period
Figure 5. Example of a daily rest period interrupted more than twice causing rest period H not to be included in the computation
Figure 6. Example of a daily rest period where Ferry/Train Calculation period is commenced at end of work period
Figure 7. Example of a daily rest period interrupted more than twice causing rest period B not to be included in the computation
Figure 8. Example of a split daily rest period interrupted once during the first rest period and once during 2nd rest period
4.
Computation of daily, weekly and fortnightly- driving times
The VU shall compute the daily driving time(s) for the ongoing and previous RTM-shifts. The driving time occurring during the interruptions of the daily rest periods shall not be added to the computation of the daily driving time, when such interruptions are due to ferry/train crossing and the requirements provided for in paragraphs (h) and (j) of point 2 and in point 3 have been fulfilled. Nevertheless, insofar as a complete regular or split daily rest period has not been computed by the VU according to point 3, the driving times occurring during the interruptions shall be added to the daily driving time for the ongoing RTM-shift.
The VU shall also compute the weekly and the fortnightly driving times. The driving time occurring during the interruptions of the daily rest periods due to ferry/train crossing shall be added to the computation of the weekly and the fortnightly driving times.’;
(40)Appendix 15 is amended as follows:
(a)the header is replaced by the following:
‘
Appendix 15
MIGRATION: MANAGING THE CO-EXISTENCE OF EQUIPMENT GENERATIONS AND VERSIONS’;
(b)the Table of Content is amended as follows:
(i)point 2.2 is replaced by the following:
‘2.2.
Interoperability between VU and cards’;
(ii)the following point 5 is added:
‘5.
Recording of border crossings in first generation and first version of second generation tachographs’;
(c)points 2 to 4 are replaced by the following:
‘2.
GENERAL PROVISIONS
2.1.
Overview of the transition
The introduction of this Annex provides an overview of the transition between the first and the second generation tachograph systems, and of the introduction of the second version of second generation recording equipment and tachograph cards.
In addition to the provisions of this introduction, the following information can be reminded:
-
first generation motion sensors are not interoperable with any version of second generation vehicle units,
-
only second generation motion sensors can be installed in vehicles equipped with any version of second generation vehicle units,
-
data download and calibration equipment need to support use of both generations or versions of recording equipment and tachograph cards.
2.2.
Interoperability between VU and cards
It is understood that first generation tachograph cards are interoperable with first generation vehicle units (in compliance with Annex IB of Regulation (EEC) No 3821/85), any version of second generation tachograph cards are interoperable with any version of second generation vehicle units (in compliance with Annex IC of this Regulation). In addition, the requirements below shall apply.
MIG_001
Except as provided for in requirement MIG_004 and MIG_005, first generation tachograph cards may continue to be used in any version of second generation vehicle units until their end of validity date. Their holders may however ask for their replacement by second generation tachograph cards as soon as they are available.
MIG_002
Any version of second generation vehicle units shall be able to use any valid first generation driver, control and company card inserted.
MIG_003
This capability may be suppressed once and forever in such vehicle units by workshops, so that first generation tachograph cards cannot be accepted anymore. This may only be done after the European Commission has launched a procedure aiming to request workshops to do so, for example during each periodic inspection of tachograph.
MIG_004
Second generation vehicle units shall only be able to use second generation workshop cards.
MIG_005
For determining the mode of operation, any version of second generation vehicle units shall only consider the types of the valid cards inserted, regardless of their generations or versions.
MIG_006
Any version of valid second generation tachograph card shall be able to be used in first generation vehicle units exactly the same manner as a first generation tachograph card of the same type.
2.3.
Interoperability between VU and MS
It is understood that first generation motion sensors are interoperable with first generation vehicle units, while second generation motion sensors are interoperable with any version of second generation vehicle units. In addition, the requirements below shall apply.
MIG_007
Any version of second generation vehicle units shall not be able to be paired and used with first generation motion sensors.
MIG_008
Second generation motion sensors may be paired and used with second generation vehicle units only, whichever the version, or with both generations of vehicle units.
2.4.
Interoperability between vehicle units, tachograph cards and equipment for data download
MIG_009
Equipment for data download may be compatible with all generations and versions of vehicle units and tachograph cards.
2.4.1
Direct card download by IDE
MIG_010
Data shall be downloaded by IDE from tachograph cards of one generation inserted in their card readers, using the security mechanisms and the data download protocol of this generation, and downloaded data shall have the format defined for this generation and version.
MIG_011
To allow drivers’ control by non EU control authorities, it shall also be possible to download second generation driver (and workshop) cards, whichever the version, in exactly the same manner as first generation drivers (and workshop) cards. Such download shall include:
-
non signed EFs IC and ICC (optional),
-
non signed EFs (first generation) Card_Certificate and CA_Certificate,
-
the other application data EFs (within DF Tachograph) requested by the first generation card download protocol. This information shall be secured with a digital signature, according to the first generation security mechanisms.
Such download shall not include application data EFs only present in version 1 or version 2 second generation driver (and workshop) cards (application data EFs within DF Tachograph_G2).
2.4.2
Card download through a vehicle unit
MIG_012
Data shall be downloaded from any version of second generation card, inserted in a first generation vehicle unit using the first generation data download protocol. The card shall answer to the vehicle unit commands exactly the same manner as a first generation card and downloaded data shall have the same format as data downloaded from a first generation card.
MIG_013
Data shall be downloaded from a first generation card inserted in any version of second generation vehicle unit using the data download protocol defined in Appendix 7 of this Annex. The vehicle unit shall send commands to the card exactly the same manner as a first generation vehicle unit, and downloaded data shall respect the format defined for first generation cards.
2.4.3
Vehicle unit download
MIG_014
Outside of the frame of drivers' control by non EU control authorities, data shall be downloaded from second generation vehicle units using the second generation security mechanisms, and the data download protocol specified in Appendix 7 of this Annex for the relevant version.
MIG_015
To allow drivers' control by non EU control authorities, it may optionally also be possible to download data from any version of second generation vehicle units using the first generation security mechanisms. Downloaded data shall then have the same format as data downloaded from a first generation vehicle unit. This capability may be selected through commands in the menu.
2.5.
Interoperability between VU and calibration equipment
MIG_016
Calibration equipment shall be able to perform calibration of each generation or version of tachograph, using the calibration protocol of this generation or version. Calibration equipment may be compatible with all generations and versions of vehicle units.
3.
MAIN STEPS DURING THE PERIOD BEFORE THE INTRODUCTION DATE
MIG_017
Test keys and certificates shall be available to manufacturers at the publication date of this Annex.
MIG_018
Interoperability tests shall be ready to start with version 2 of vehicle units and version 2 of tachograph cards if requested by manufacturers at the latest 15 months before the introduction date.
MIG_019
For version 2 of generation 2 tachographs, tachograph cards and motion sensors, the same keys and certificates are used as for generation 2 version 1 equipment.
MIG_020
Member States shall be able to issue version 2 of second generation workshop cards at the latest 1 month before the introduction date.
MIG_021
Member States shall be able to issue all other types of version 2 of second generation tachograph cards at the latest 1 month before the introduction date.
4.
PROVISIONS FOR THE PERIOD AFTER THE INTRODUCTION DATE
MIG_022
With effect from the introduction date, Member States shall only issue version 2 of second generation tachograph cards.
MIG_023
Vehicle units / motion sensors manufacturers shall be allowed to produce first generation vehicle units / motion sensors as long as they are used in the field, so that malfunctioning components can be replaced.
MIG_023a
With effect from the introduction date, malfunctioning version 1 of second generation vehicle units or external GNSS facilities shall be replaced with version 2 of second generation vehicle units or external GNSS facilities.
MIG_024
Vehicle units / motion sensors manufacturers shall be allowed to request and obtain type approval maintenance of first generation vehicle units / motion sensors types or version 1 of second generation vehicle units already type approved.’;
(d)the following point 5 is added:
‘5.
Recording of border crossings in first generation and first version of second generation tachographs
MIG_025
The symbol of the country and, if applicable, the region that the driver enters after crossing a border of a Member State in application of Article 34(7) of Regulation (EU) No 165/2014, shall be entered as a place where the daily work period begins in accordance with the manual entry of places set out in requirements 60 of Annex IC to Regulation (EU) No 165/2014 and 50 of Annex IB to Regulation (EEC) No 3821/85.’;
(41)in appendix 16, paragraph ADA_012 is replaced by the following:
‘ADA_012
The adaptor input interface shall be able, if applicable, to multiply or divide the frequency pulses of the incoming speed pulses by a fixed factor, to adapt the signal to the k factor range defined by this Annex (2400 to 25000 pulses/km). This fixed factor may only be programmed by the adaptor manufacturer, and the approved workshop performing the adaptor installation.’.
