1998R2135 — EN — 25.08.2002 — 001.001 — 1
This document is meant purely as a documentation tool and the institutions do not assume any liability for its contents
►B ►C1 COUNCIL REGULATION
(EC) No 2135/98
of 24 September 1998 amending Regulation (EEC) No 3821/85 on recording equipment in road
transport and Directive 88/599/EEC concerning the application of Regulations (EEC) No 3820/85
and (EEC) No 3821/85 ◄
(OJ L 274, 9.10.1998, p. 1)
Amended by:
Official Journal
No page date
►M1 Commission Regulation (EC) No 1360/2002 of 13 June 2002 L 207 1 5.8.2002
Corrected by:
►C1 Corrigendum, OJ L 49, 25.2.1999, p. 46 (2135/98/EEC)
▼B
COUNCIL REGULATION
(EC) No 2135/98
of 24 September 1998 amending Regulation (EEC) No 3821/85 on
recording equipment in road transport and Directive 88/599/EEC
concerning the application of Regulations (EEC) No 3820/85 and
(EEC) No 3821/85
THE COUNCIL OF THE EUROPEAN UNION,
Having regard to the Treaty establishing the European Community, andin particular Article 75(1)(c) and (d) thereof,
Having regard to the proposal from the Commission (
1),
Having regard to the opinion of the Economic and Social
Committee (2),
Acting in accordance with the procedure laid down in Article 189c of
the Teaty (3),
(1) Whereas Council Regulation (EEC) No 3821/85 of 20 December1985 on recording equipment in road transport (
4) lays down
provisions concerning the construction, installation, use andtesting of recording equipment in road transport;
(2) Whereas experience has shown that the economic pressures and
competition in road transport have led some drivers employed by
road haulage companies to flout certain rules, particularly thoseconcerning the driving and rest times laid down in CouncilRegulation (EEC) No 3820/85 of 20 December 1985 on theharmonisaton of certain social legislation relating to road trans-port (
5);
(3) Whereas blatant infringements and fraud present a road safety
hazard and are unacceptable for reasons of competition for the
individual driver who does respect the rules;
(4) Whereas road safety would be improved by the automaticrecording and regular monitoring, both by the undertaking andby the competent authorities, of details of the driver's perfor-mance and behaviour and of the vehicle's journey, such asspeed and distance covered;
(5) Whereas Community social regulations contain certain require-
ments for limits on the daily driving and rest time and also for
the total driving and rest time, for up to two weeks; whereas it isdifficult to monitor compliance with these requirements giventhat data are recorded on several daily record sheets, out ofwhich the record sheets for the current week and the last day ofthe previous week are to be stored in the cab;
(6) Whereas, to put an end to the most common abuses of the
present system, it is therefore necessary to introduce new
advanced equipment such as recording equipment fitted with anelectronic device for storing relevant information and a personaldriver card, so ensuring that the data recorded are retrievable,intelligible when printed out, and reliable, and that they provideanindisputable record of the work done by both the driver over1998R2135 — EN — 25.08.2002 — 001.001 — 2
(1) OJ C 243, 31.8.1994, p. 8 and OJ C 370, 31.12.1985, p. 1.
(2) OJ C 110, 21.4.1995, p. 19.
(3) Opinion of the European Parliament of 13 July 1995 (OJ C 249, 25.9.1995,
p. 128), Council Common Position of 11 December 1997 (OJ C 43,9.2.1998, p. 6) and Decision of the European Parliament of 31 March 1998
(OJ C 138, 4.5.1998, p. 26).
(
4) OJ L 370, 31.12.1985, p. 8. Regulation as last amended by Commission
Regulation (EC) No 1056/97 (OJ L 154, 12.6.1997, p. 21).
(5) OJ L 370, 31.12.1985, p. 1.▼C1
▼B
▼B
the last few days and by the vehicle over a period of several
months;
(7) Whereas the total security of the system and its components isessential if recording equipment is to function efficiently;
(8) Whereas provisions need to be established to govern the condi-
tons under which the memory cards provided for in Annex IB
may be issued and used;
(9) Whereas the data on drivers' activities must be verifiable by thedrivers themselves, by the companies that employ them and by
the competent authorities of the Member States; whereas,
however, only data relevant to their respective activities shouldbe accessible to a driver and his company;
(10) Whereas the recording equipment provided for in this Regulation
must be installed on vehicles put into service for the first time
after publication in the Official Journal of the European Commu-
nities of the technical specifications some of which are defined
by the Commission in accordance with the committee procedurereferred to in Article 18 of Regulation (EEC) No 3821/85;whereas a tansitional period is needed to allow new recording
equipment to be manufactured in accordance with those tech-
nical specifications and granted EC component type-approval;
(11) Whereas it is desirable that recording equipment complying withAnnex IB should also offer the possibility of low-cost expansion
of its functions for fleet management;
(12) Whereas, in accordance with the principle of subsidiarity,
Community action is necessary to amend Regulation (EEC) No3821/85 in order to ensure that recording equipment complying
with Annex IB is compatible with driver cards and that the data
produced by recording equipment complying with Annexes I andIB are consistent;
(13) Whereas technical progress necessitates the prompt adoption of
the technical requirements laid down in the Annexes to this
Regulation; whereas, in order to facilitate the implementation ofthe measures needed for this purpose, provision should be madefor technical adaptations of those Annexes to be approved by theCommission, acting in accordance with the committee procedureas set out in Council Decision 87/373/EEC of 13 July 1987
laying down the procedures for the exercise of implementing
powers conferred on the Commission (
1);
(14) Whereas the introduction of new recording equipment meansthat certain provisions of Directive 88/599/EEC (
2) concering
the application of Regulations (EEC) No 3820/85 and (EEC)
No 3821/85 need to be amended,
HAS ADOPTED THIS REGULATION:
Article 1
Regulation (EEC) No 3821/85 is hereby amended as follows:
1. in Article 1 the words ‘and of Annexes I and II thereto’ shall be
replaced by ‘and of Annexes I or IB and II thereto’;
2. Articles 4, 5, 6, 7, 8 and 11 shall be amended by adding the words
‘or memory card’ where reference is made to ‘record sheet’ or‘record sheets’;
3. in Article 4 the following subparagraph shall be inserted before the
first subparagraph:
‘For the purposes of this Chapter, the words “recording equipment”
shall mean “recording equipment or its components”.’;1998R2135 — EN — 25.08.2002 — 001.001 — 3
(1) OJ L 197, 18.7.1987, p. 33.
(2) OJ L 325, 29.11.1988, p. 55.
▼B
4. in Article 5, the first subparagraph shall be replaced by the
following:
‘A Member State shall grant EC component type-approval to any
type of recording equipment, to any model record sheet or memorycard which conforms to the requirements laid down in Annex I or
IB to this Regulation, provided the Member State is in a position to
check that production models conform to the approved type.
The system's security must comply with the technical requirements
laid down in Annex IB. The Commisson, acting in accordance withthe procedure laid down in Article 18, shall ensure that the saidAnnex stipulates that recording equipment may not be granted EC
component type-approval until the whole system (the recording
equipment itself, driver card and electrical gearbox connections)has demonstrated its capacity to resist attempts to tamper with oralter the data on driving times. The tests necessary to establishthis shall be carried out by experts familiar with up to date
tampering techniques.’;
5. in Article 12:
(a) the following shall be added to paragraph 1:
‘The period of administrative validity of approved workshop
and fitter cards shall not exceed one year.
If a card issued to an approved workshop or fitter is to be
extended, is damaged, malfunctions, is lost or is stolen, theauthority shall supply a replacement card within five workingdays of receiving a detailed request to that effect.
Where a new card is issued to replace an old one, the new card
shall bear the same “workshop” information number, but the
index shall be increased by one. The authority issuing the
card shall maintain a register of lost, stolen or defective cards.
Member States shall take any measure necessary to prevent the
cards distributed to approved fitters and workshops from beingfalsified.’;
(b) paragraph 2 shall be replaced by the following:
‘2. the approved fitter or workshop shall place a special
mark on the seals which it affixes and, in addition, shall enter
for recording equipment in conformity with Annex IB, the
electronic security data for carrying out, in particular, theauthentication checks. The competent authorities of eachMember State shall maintain a register of the marks and elec-tronic security data used and of approved workshop and fittercards issued.’;
(c) paragraph 3 shall be replaced by the following:
‘3. The competent authorities of the Member States shall
forward to the Commission the lists of approved fitters and
workshops and the cards issued to them and shall forward toit copies of the marks and of the necessary information relatingto the electronic security data used.’;
(d) in paragraph 4 the reference to ‘Annex I’ shall be replaced by a
reference to ‘Annexes I and IB’;
(e) in paragraph 5 the words ‘or in Annex IB section VI(c)’ shall
be in inserted after the words ‘paragraph 4’;
6. Article 13 shall be replaced by the following:
‘Article 13
The employer and drivers shall ensure the correct functioning and
proper use of, on the one hand, the recording equipment and, onthe other, the driver card where a driver is required to drive avehicle fitted with recording equipment in conformity with Annex
IB.’;
7. in Article 14:
(a) paragraph 1 shall be replaced by the following:1998R2135 — EN — 25.08.2002 — 001.001 — 4
▼B
‘1. The employer shall issue a sufficient number of record
sheets to drivers of vehicles fitted with recording equipmentin conformity with Annex I, bearing in mind the fact that these
sheets are personal in character, the length of the period of
service and the possible obligation to replace sheets which aredamaged, or have been taken by an authorised inspectingofficer. The employer shall issue to drivers only sheets of anapproved model suitable for use in the equipment installed in
the vehicle.
Where the vehicle is fitted with recording equipment in confor-
mity with Annex IB, the employer and the driver shall ensurethat, taking into account the length of the period of service, the
printing on request referred to in Annex IB can be carried out
correctly in the event of an inspection.’;
(b) the following paragraphs shall be added:
‘3. The driver card as defined in Annex IB shall be issued,
at the request of the driver, by the competent authority of the
Member State where the driver has his normal residence.
A Member State may require any driver subject to the provi-
sions of Regulation (EEC) No 3820/85 and normally residenton its territory to hold a driver card.
(a) For the purposes of this Regulation “normal residence”
means the place where a person usually lives, that is for
at least 185 days in each calendar year, because of personaland occupational ties, or, in the case of a person with nooccupational ties, because of personal ties which showclose links between that person and the place where he isliving.
However, the normal residence of a person whose occupa-
tional ties are in a different place from his personal ties andwho consequently lives in turn in differnt places situated intwo or more Member States shallbe regarded as being the
place of his personal ties, provided that such person returns
there regularly. This last condition need not be met wherethe person is living in a Member State in order to carry outa fixed-term assignment.
(b) Drivers shall give proof of their place of normal residence
by any appropriate means, such as their identity card orany other valid document.
(c) Where the competent authorities of the Member State
issuing the driver card have doubts as to the validity of a
statement as to normal residence made in accordance with
point (b), or for the purpose of ceratin specific controls,they may request any additional information or evidence.
(d) The competent authorities of the issuing Member State
shall, as far as this can be done, ensure that the applicant
does not already hold a valid driver card.
4. (a) The competent authority of the Member State shall
personalise the driver card in accordance with the provi-
sions of Annex IB.
For administarative purposes, the driver card may not be
valid for more than five years.
The driver may hold one valid driver card only. The
driver is authorised to use only his own personaliseddriver card. The driver shall not use a driver card whichis defective or which has expired.
When a new driver card is issued replacing the old, the
new card shall bear the same driver card issue numberbut the index shall be increased by one. The issuingauthority shall keep records of issued, stolen, lost ordefective driver cards for a period at least equivalent totheir period of administrative validity.1998R2135 — EN — 25.08.2002 — 001.001 — 5
▼B
If the driver card is damaged, malfunctions or is lost or
stolen, the authority shall supply a replacement cardwithin five working days of receiving a detailed request
to that effect.
In the event of a request for the renewal of a card whose
expiry date is approaching, the authority shall supply anew card before the expiry date provided that therequest was sent to it within the time limits laid down
in the second subparagraph of Article 15(1).
(b) Driver cards shall be issued only to applicants who are
subject to the provisions of Regulation (EEC) No 3820/85.
(c) The driver card shall be personal. It may not, during its
official period of validity, be withdrawn or suspended
for whatever reason unless the competent authority of a
Member State finds that the card has been falsified, orthe driver is using a card of which he is not the holder,or that the card held has been obtained on the basis offalse declarations and/or forged documents. If suchsuspension or withdrawal measures are taken by a
Member State other than the Member State of issue,
the former shall return the card to the authorities of theMember State which issued it and shall indicate thereasons for returning it.
(d) Driver cards issued by Member States shall be mutually
recognised.
Where the holder of a valid driver card issued by a
Member State has established his normal place of resi-dence in another Member State, he may ask for hiscard to be exchanged for an equivalent driver card; itshall be the responsibility of the Member State which
carries out the exchange to verify if necessary whether
the card produced is actually still valid.
Member States carrying out an exchange shall return the
old card to the authorities of the Member State of issueand inidcate the reasons for so doing.
(e) Where a Member State replaces or exchanges a driver
card, the replacement or exchange, and any subsequent
replacement or renewal, shall be registered in thatMember State.
(f) Member States shall take all the necessary measures to
prevent any possibility of driver cards being falsified.
5. Member States shall ensure that data needed to monitor
compliance with Regulation (EEC) No 3820/85 and Council
Directive 92/6/EEC of 10 February 1992 on the installationand use of speed limitation devices for certain categories ofmotor vehicles in the Community (*) which are recorded andstored by recording equipment in conformity with Annex IB
to this Regulation can be made available for at least 365 days
after thedate of their recording and that they can be madeavailable under conditions that guarantee the security and accu-racy of the data.
Member States shall take any measures necessary to ensure
that the resale or decommissioning of recording equipment
cannot detract, in particular, from the satisfactory application
of this paragraph.
(*) OJ L 57, 2.3.1992, p.27.’;
8. in Article 15:
(a) paragraph 1 and paragraph 2, first subparagraph, shall be
amended by adding the words ‘or driver card’ where referenceis made to ‘record sheet’ or ‘record sheets’;1998R2135 — EN — 25.08.2002 — 001.001 — 6
▼B
(b) in paragraph 1:
— the following subparagraph shall be inserted after the first
subparagraph:
‘Where a driver wishes to renew his driver card, he shall
apply to the competent authorities of the Member State in
which he has his normal residence not later than 15working days before the expiry date of the card.’;
— the following fourth subparagraph shall be added:
‘If the driver card is damaged, malfunctions or is lost or
stolen, the driver shall apply within seven calendar days
for its replacement to the competent authorities of theMember State in which he has his normal residence.’;
(c) after Article 5 the following paragraph shall be inserted:
‘5a. The driver shall enter in the recording equipment in
conformity with Annex IB the symbols of the countries inwhich he begins and ends his daily work period. However, a
Member State may require drivers of vehicles engaged in trans-
port operations inside its territory to add more detailedgeographic specifications to the country symbol provided thatthe Member State has notified them to the Commission before1 April 1998 and that they do not number more than 20.
The above data entries shall be activated by the driver, and
may be entirely manual or automatic if the recording equip-
ment is linked to a satellite tracking system.’;
(d) at the beginning of the first subparagraph of paragraph 6 the
word ‘equipment’ shall be replaced by ‘recording equipmentdefined in Annex I’;
(e) paragraph 7 shall be replaced by the following:
‘7. Where the driver drives a vehicle fitted with recording
equipment in conformity with Annex I, he must be able toproduce, whenever an inspecting officer so requests:
— the record sheets for the current week and, in any event, the
sheet for the last day on which he drove during the previousweek,
— the driver card if he holds one, and— print-outs from the recording equipment defined in Annex
IB relating to the periods of time indicated in paragraph 3,second indent, (a), (b), (c) and (d) if he drove a vehiclefitted with such recording equipment during the periodreferred to in the first indent of this paragraph.
Where the driver drives a vehicle fitted with recording equip-
ment in conformity with Annex IB, he must be able toproduce, whenever an inspecting officer so requests:
— the driver card of which he is the holder,
— the record sheets corresponding to the same period as the
one referred to in the first indent of the previous subpara-graph during which he drove a vehicle fitted withrecording equipment in conformity with Annex I.
An authorised inspecting officer may check compliance with
Regulation (EEC) No 3820/85 by analysis of the record sheets,of the displayed or printed data which have been recorded bythe recording equipment or by the driver card or, failing this,by analysis of any other supporting document that justifies
non-compliance with a provision, such as those laid down in
Article 16(2) and (3).’;
(f) the following paragraph shall be added:
‘8. It shall be forbidden to falsify, suppress or destroy data
recorded on the record sheet, stored in the recording equipmentor on the driver card, or print-outs from the recording equip-ment as defined in Annex IB. The same applies to anymanipulation of the recording equipment, recordsheet or driver1998R2135 — EN — 25.08.2002 — 001.001 — 7
▼B
card which may result in data and/or printed information being
falsified, suppressed or destroyed. No device which could beused to this effect shall be present on the vehicle.’;
9. in Article 16:
(a) paragraph 2 shall be replaced by the following:
‘2. While the recording equipment is unserviceable or
malfunctioning, drivers shall mark on the record sheet orsheets, or on a temporary sheet to be attached to the recordsheet or to the driver card, on which he shall enter dataenabling him to be identified (driver's card number and/or
name and/or driving licence number), including his signature,
all information for the various periods of time which are nolonger recorded or printed out correctly by the recording equip-ment.
If a driver card is damaged, malfunctions or is lost or stolen,
the driver shall, at the end of his journey, print out the informa-
tion relating to the periods of time recorded by the recording
equipment and mark on that document the details that enablehim to be identified (the driver card number and/or name and/or driving licence number), including his signature.’;
(b) the following paragraph shall be added:
‘3. If a driver card is damaged or if it malfunctions, the
driver shall return it to the competent authority of the MemberState in which he has his normal residence. Theft of the drivercard shall be the subject of a formal declaration to the compe-tent authorities of the State where the theft occurred.
Loss of the driver card must be reported in a formal declaration
to the competent authorities of the State that issued it and to
the competent authorities of the Member State of normal resi-dence where they are different.
The diver may continue to drive without a driver card for a
maximum period of 15 calendar days or for a longer period ifthis is necessary for the vehicle to return to its premises,
provided he can prove the impossibility of producing or using
the card during this period.
Where the authorities of the Member State in which the driver
has his normal residence are different from those which issuedhis card and where the latter are requested to renew, replace orexchange the driver card, they shall inform the authoritieswhich issued the old card of the precise reasons for its renewal,
replacement or exchange.’;
10. Article 17 shall be replaced by the following:
‘Article 17
1. The amendments necessary to adapt the Annexes to technical
progress shall be adopted in accordance with the procedure laid
down in Article 18.
2. The technical specifications relating to the following sections
of Annex IB shall be adopted as soon as possible and if possiblebefore 1 July 1998 by the same procedure:
(a) Chapter II
— (d) 17:
displaying and printing of faults in the recording equip-
ment,
— (d) 18:
displaying and printing of faults in the driver card,
— (d) 21:
displaying and printing of summary reports;1998R2135 — EN — 25.08.2002 — 001.001 — 8
▼B
(b) Chapter III
— (a) 6.3:
standards for the protection of vehicle electronics against
electrical interference and magnetic fields,
— (a) 6.5:
protection (security) of the total system,
— (c) 1:
warning signals indicating the internal malfunctioning of
the recording equipment,
— (c) 5:
format of the warnings,
— (f):
maximum tolerances;
(c) Chapter IV, A:
—4 :
standards,
—5 :
security, including data protection,
—6 :
temperature range,
—8 :
electrical characteristics,
—9 :
logical structure of the driver card,
— 10:
functions and commands,
— 11:
elementary files;
and Chapter IV, B;
(d) Chapter V:
printer and standard print-outs.’;
11. Article 18 shall be replaced by the following:
‘Article 18
1. Where reference is made to the procedure laid down in this
Article, the Commission shall be assisted by a committeecomposed of the representatives of the Member States and chairedby the representative of the Commission.
2. The representative of the Commission shall submit to the
committee a draft of the measures to be taken. The committee shalldeliver its opinion on the draft within a time limit which thechairman may lay down according to the urgency of the matter.
The opinion shall be delivered by the majority laid down in Article
148(2) of the Treaty in the case of decisions which the Council isrequired to adopt on a proposal from the Commission. The votes ofthe representatives of the Member States within the committeeshall be weighted in the manner set out in that Article. The
chairman shall not vote.
3. (a) The Commission shall adopt the measures envisaged if they are
in accordance with the opinion of the committee.
(b) If the measures envisaged are not in accordance with the
opinion of the committee, or if no opinion is delivered, theCommission shall, without delay, submit to the Council aproposal relating to the measures to be taken. The Councilshall act by a qualified majority.1998R2135 — EN — 25.08.2002 — 001.001 — 9
▼B
If, on the expiry of a period of three months from the date of
referral to the Council, the Council has not acted, the proposedmeasures shall be adopted by the Commission.’;
12. Annex IB, as contained in the Annex to the present Regulation, is
hereby added.
Article 2
1. (a) 24 months from the date of publication in the Official Journal of
the European Communities of the act to be adopted pursuant to
Article 17(2) of Regulation (EEC) No 3821/85, as amended bythis Regulation, vehicles put into service for the first time mustbe fitted with recording equipment in accordance with therequirements of Annex IB to Regulation (EEC) No 3821/85.
(b) As from the date of entry into force of the provisions of subpar-
agraph (a), vehicles used for the carriage of persons containing
more than eight seats apart from the driver's seat and having amaximum weight exceeding 10 tonnes, and also vehicles usedfor the carriage of goods having a maximum weight exceeding12 tonnes, registered for the first time as from 1 January 1996,shall in so far as the transmission of signals to the recording
equipment with which they are fitted is exclusively electrical,
satisfy the requirements of Annex IB to Regulation (EEC) No3821/85 when the equipment in question is replaced.
2. Member States shall take the necessary measures to ensure that
they are able to issue driver cards no later than 21 months followingthe date of publication of the act referred to in paragaph 1(a).
3. In the event that 12 months after the date of publication of the act
referred to in paragraph 1, EC type-approval has not been granted to
any item of recording equipment which conforms to the requirementsof Annex IB to Regulation (EEC) No 3821/85, the Commission shallsubmit a proposal to the Council for an extension of the deadline laiddown in paragraphs 1 and 2.
4. Drivers who, before the date laid down in paragraph 2, drive
vehicles fitted with recording equipment conforming to the require-ments of Annex IB to Regulation (EEC) No 3821/85 for which thecompetent authorities have not yet been able to issue a driver card shall
at the end of their daily work period print out the information
concerning the various periods of time recorded by the recordingequipment and shall indicate their identification details on the print-out (name and driving licence number), and sign it.
Article 3
Directive 88/599/EEC is hereby amended as follows:
1. Article 3(2) shall be replaced by the following:
‘2. The elements of roadside checks are:
— daily driving periods, breaks and daily rest periods; in the case
of clear indications of irregularities, also the preceding days'record sheets which have to be carried on board the vehicle in
accordance with Article 15(7) of Regulation (EEC) No 3821/85
as amended by Regulation (EC) No 2135/98 (*) and/or the datastored for the same period on the driver card and/or in thememory of the recording equipment in conformity with AnnexIB,
— for the period referred to in Article 15(7) of Regulation (EEC)
No 3821/85, any cases where the vehicle's authorised speed isexceeded, to be defined as being any periods of more than1 minute during which the vehicle's speed exceeds 90 km/h forcategory N
3vehicles or 105 km/h for category M3vehicles (cate-
gories N3and M3being as defined in Annex I to Directive 70/
156/EEC) (**),
— where appropriate, momentary speeds attained by the vehicle as
recorded by the recording equipment in no more than theprevious 24 hours' use of the vehicle,1998R2135 — EN — 25.08.2002 — 001.001 — 10
▼B
— last weekly rest period, where appropriate,
— correct functioning of the recording equipment (determination of
possible misuse of the equipment and/or the driver card and/orrecord sheets) or, where appropriate, presence of the documentsreferred to in Article 14(5) of Regulation (EEC) No 3820/85.
(*) Council Regulation (EC) No 2135/98 of 24 September 1998
amending Regulation (EEC) No 3821/85 on recording equip-ment in road transport and Directive 88/599/EEC concerningthe procedures for applying Regulations (EEC) No 3820/85 and
(EEC) No 3821/85 (OJ L 274, 9.10.1998, p. 1).
(**) Council Directive 70/156/EEC of 6 February 1970 on the
approximation of the laws of the Member States relating tothe type-approval of motor vehicles and their trailers (OJ L42, 23.2.1970, p. 1). Directive as last amended by Directive97/27/EC (OJ L 233, 25.8.1997, p. 1).’;
2. Article 4(3) shall be replaced by the following:
‘3. For the purposes of this Article, checks carried out at the
premises of the competent authorities, on the basis of relevant docu-ments and/or data handed over by undertakings at the request of thesaid authorities, shall have the same status as checks carried out at
the premises of undertakings.’.
Article 4
This Regulation shall enter into force on the day following its publica-
tion in the Official Journal of the European Communities .
This Regulation shall be binding in its entirety and directly applicable
in all Member States.1998R2135 — EN — 25.08.2002 — 001.001 — 11
▼M1
ANNEX
‘ANNEX I B
REQUIREMENTS FOR CONSTRUCTION, TESTING, INSTALLATION AND INSPECTION
CONTENTS
I. DEFINITIONS … ...........................................................
II. GENERAL CHARACTERISTICS AND FUNCTIONS OF THE RECORDING EQUIP-
MENT … ..................................................................
1. General characteristics … ............................................
2. Functions … .......................................................
3. Modes of operation … . . .............................................
4. Security … ........................................................
III. CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR RECORDING EQUIP-
MENT … ..................................................................
1. Monitoring cards insertion and withdrawal … ............................
2. Speed and distance measurement … . . ..................................
2.1. Measurement of distance travelled … ..................................
2.2. Measurement of speed … ............................................
3. Time measurement … . . .............................................
4. Monitoring driver activities … ........................................
5. Monitoring driving status … . . ........................................
6. Drivers manual entries … ............................................
6.1. Entry of places where daily work periods begin and/or end … . . ............
6.2. Manual entry of driver activities … . . ..................................
6.3. Entry of specific conditions … ........................................
7. Company locks management … .......................................
8. Monitoring control activities … .......................................
9. Detection of events and/or faults … . . ..................................
9.1. ‘Insertion of a non valid card’ event … .................................
9.2. ‘Card conflict’ event … . .............................................
9.3. ‘Time overlap’ event … .............................................
9.4. ‘Driving without an appropriate card’ event … ...........................
9.5. ‘Card insertion while driving’ event … .................................
9.6. ‘Last card session not correctly closed’ event … . . .......................
9.7. ‘Over speeding’event … .............................................
9.8. ‘Power supply interruption’ event … . ..................................
9.9. ‘Motion data error’ event … . . ........................................
9.10. ‘Security breach attempt’ event … . . . ..................................
9.11. ‘Card’ fault … . . ...................................................
9.12. ‘Recording equipment’ fault … ........................................
10. Built-in and self tests … .............................................
11. Reading from data memory … ........................................
12. Recording and storing in the data memory … ............................
12.1. Equipment identification data … .......................................
12.1.1. Vehicle Unit identification data … . . . ..................................1998R2135 — EN — 25.08.2002 — 001.001 — 12
▼M1
12.1.2. Motion sensor identification data … . . ..................................
12.2. Security elements … . . . .............................................
12.3. Driver card insertion and withdrawal data … ............................
12.4. Driver activity data … . . .............................................
12.5. Places where daily work periods start and/or end … ......................
12.6. Odometer data … ...................................................
12.7. Detailed speed data … . . .............................................
12.8. Events data … . . ...................................................
12.9. Faults data … . . . ...................................................
12.10. Calibration data … ..................................................
12.11. Time adjustment data … .............................................
12.12. Control activity data … . .............................................
12.13. Company locks data … . .............................................
12.14. Download activity data … ............................................
12.15. Specific conditions data … . . . ........................................
13. Reading from tachograph cards … . . . ..................................
14. Recording and storing on tachograph cards … ...........................
15. Displaying … . . . ...................................................
15.1 Default display … ..................................................
15.2. Warning display … .................................................
15.3. Menu access … . ...................................................
15.4. Other displays … ...................................................
16. Printing … ........................................................
17. Warnings … .......................................................
18. Data downloading to external media … .................................
19. Output data to additional external devices … ............................
20. Calibration … . . . ...................................................
21. Time adjustment … .................................................
22. Performance characteristics … ........................................
23. Materials … .......................................................
24. Markings … .......................................................
IV. CONSTRUCTIONS AND FUNCTIONAL REQUIREMTNS FOR TACHOGRAPH
CARDS … .................................................................
1. Visible data … . . ...................................................
2. Security … ........................................................
3. Standards … .......................................................
4. Environmental and electrical specifications … ...........................
5. Data storage … . . ...................................................
5.1. Card identification and security data … .................................
5.1.1. Application identification … . . ........................................
5.1.2. Chip identification … . . .............................................
5.1.3. IC card identification … .............................................
5.1.4. Security elements … . . . .............................................
5.2. Driver card … . . ...................................................
5.2.1. Card identification … . . .............................................
5.2.2. Card holder identification … . . ........................................1998R2135 — EN — 25.08.2002 — 001.001 — 13
▼M1
5.2.3. Driving licence information … ........................................
5.2.4. Vehicles used data … . . .............................................
5.2.5. Driver activity data … . . .............................................
5.2.6. Places where daily periods start and/or end … ...........................
5.2.7. Events data … . . ...................................................
5.2.8. Faults data … . . . ...................................................
5.2.9. Control activity data … . .............................................
5.2.10. Card session data … . . . .............................................
5.2.11. Secific conditions data … ............................................
5.3. Workshop card … ..................................................
5.3.1. Security elements … . . . .............................................
5.3.2. Card identification … . . .............................................
5.3.3. Card holder identification … . . ........................................
5.3.4. Vehicles' used data … . . .............................................
5.3.5. Driver activity data … . . .............................................
5.3.6. Daily work periods start and/or end data … .............................
5.3.7. Events and faults data … .............................................
5.3.8. Control activity data … . .............................................
5.3.9. Calibration and time adjustment data … . . . .............................
5.3.10. Specific conditions data … . . . ........................................
5.4. Control card … . . ...................................................
5.4.1. Card identification … . . .............................................
5.4.2. Card holder identification … . . ........................................
5.4.3. Control activity data … . .............................................
5.5. Company card … ...................................................
5.5.1. Card identification … . . .............................................
5.5.2. Card holder identification … . . ........................................
5.5.3. Company activity data … ............................................
V. INSTALATION OF RECORDING EQUIPMENT … ...............................
1. Installation … . . . ...................................................
2. Installation plaque … . . . .............................................
3. Sealing … . ........................................................
VI. CHECKS; INSPECTIONS AND REPAIRS … . . . .................................
1. Approval of fitters or workshops … . . ..................................
2. Check of new or repaired instruments … . . . .............................
3. Installation inspection … .............................................
4. Periodic inspections … . .............................................
5. Measurement of errors … ............................................
6. Repairs … . ........................................................
VII. CARD ISSUING … . . . .......................................................
VIII. TYPE APPROVAL OF RECORDING EQUIPMENT AND TACHOGRAPH CARDS … .
1. General points … ...................................................
2. Security certificate … . . .............................................
3. Funtctional certificate … .............................................
4. Interoperability certificate … . . ........................................
5. Type approval certificate … . . ........................................1998R2135 — EN — 25.08.2002 — 001.001 — 14
▼M1
6. Exceptional procedure: first interoperability tests … .......................
Appendix 1. Data dictionary
Appendix 2. Tachograph cards specification
Appendix 3. Pictograms
Appendix 4. Printouts
Appendix 5. Display
Appendix 6. External interfaces
Appendix 7. Data downloading protocol
Appendix 8. Calibration protocol
Appendix 9. TYPE APPROVAL — LIST OF MINIMUM REQUIRED TESTS
Appendix 10. GENERIC SECURITY TARGETS
Appendix 11. COMMON SECURITY MEACHANISMS1998R2135 — EN — 25.08.2002 — 001.001 — 15
▼M1
I. DEFINITIONS
In this Annex:(a) ‘activation’ means:
phase where the recording equipment becomes fully operational and
implements all functions, including security functions;
Activating a recording equipment requires the use of a workshop card
and the entry of its PIN code;
(b) ‘authentication’ means:
a function intended to establish and verify a claimed identity;
(c) ‘authenticity’ means:
the property that an information is coming from a party whose identity
can be verified;
(d) ‘built-in-test (BIT)’ means:
tests run at request, triggered by the operator or by an external equip-
ment;
(e) ‘calendar day’ means:
a day ranging from 00.00 hours to 24.00 hours. All calendar days relate
to UTC time (universal time coordinated);
(f) ‘calibration’ 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);
calibrating a recording equipment requires the use of a workshop card;
(g) ‘card number’ means:
a 16 alpha-numerical characters number that uniquely identifies a tacho-
graph card within a Member State. The card number includes a
consecutive index (if applicable), a replacement index and a renewal
index;
a card is therefore uniquely identified by the code of the issuing
Member State and the card number;
(h) ‘card consecutive index’ means:
the 14th alpha-numerical character of a card number that is used to
differentiate the different cards issued to a company or a body entitled
to be issued several tachograph cards. The company or the body is
uniquely identified by the 13 first characters of the card number;
(i) ‘card renewal index’ means:
the 16th alpha-numerical character of a card number which is incre-
mented each time a tachograph card is renewed;
(j) ‘card replacement index’ means:
the 15th alpha-numerical character of a card number which is incre-
mented each time a tachograph card is replaced;
(k) ‘characteristic coefficient of the vehicle’ means:
the numerical characteristic giving the value of the output signal emitted
by the part of the vehicle linking it with the recording equipment
(gearbox output shaft or axle) while the vehicle travels a distance of
one kilometre under standard test conditions (see Chapter VI(5)). The
characteristic coefficient is expressed in impulses per kilometre (w = …
imp/km);
(l) ‘company card’ means:
a tachograph card issued by the authorities of a Member State to the
owner or holder of vehicles fitted with recording equipment;
the company card identifies the company and allows for displaying,
downloading and printing of the data stored in the recording equipment
which has been locked by this company;
(m) ‘constant of the recording equipment’ means:
the numerical characteristic giving the value of the input signal required
to show and record a distance travelled of one kilometre; this constant
shall be expressed in impulses per kilometre (k = … imp/km);1998R2135 — EN — 25.08.2002 — 001.001 — 16
▼M1
(n) ‘continuous driving time’ is computed within the recording equip-
ment as (1):
the continuous driving time is computed as the current accumulated
driving times of a particular driver, since the end of his last AVAIL-
ABILITY or BREAK/REST or UNKNOWN (2) period of 45 minutes
or more (this period may have been split in several periods of 15
minutes or more). The computations involved take into account, as
needed, past activities stored on the driver card. When the driver has
not inserted his card, the computations involved are based on the data
memory recordings related to the current period where no card was
inserted and related to the relevant slot;
(o) ‘control card’ means:
a tachograph card issued by the authorities of a Member State to a
national competent control authority;
the control card identifies the control body and possibly the control
officer and allows for getting access to the data stored in the data
memory or in the driver cards for reading, printing and/or downloading;
(p) ‘cumulative break time’ is computed within the recording equip-
ment as (1):
the cumulative break from driving time is computed as the current accu-
mulated AVAILABILITY or BREAK/REST or UNKNOWN (2) times of
15 minutes or more of a particular driver, since the end of his last
AVAILABILITY or BREAK/REST or UNKNOWN (2) period of 45
minutes or more (this period may have been split in several periods of
15 minutes or more).
The computations involved take into account, as needed, past activities
stored on the driver card. Unknown periods of negative duration (start of
unknown period > end of unknown period) due to time overlaps
between two different recording equipments, are not taken into account
for the computation.
When the driver has not inserted his card, the computations involved are
based on the data memory recordings related to the current period where
no card was inserted and related to the relevant slot;
(q) ‘data memory’ means:
an electronic data storage device built into the recording equipment;
(r) ‘digital signature’ means:
data appended to, or a cryptographic transformation of, a block of data
that allows the recipient of the block of data to prove the authenticity
and integrity of the block of data;
(s) ‘downloading’ means:
copying together with digital signature of a part or of a complete set of
data stored in the data memory of the vehicle or in the memory of a
tachograph card;
downloading may not alter or delete any stored data;
(t) ‘driver card’ means:
a tachograph card issued by the authorities of a Member State to a parti-
cular driver;
the driver card identifies the driver and allows for storage of driver
activity data;
(u) ‘effective circumference of the wheel tyres’ means:
the average of the distances travelled by each of the wheels moving the
vehicle (driving wheels) in the course of one complete rotation. The
measurement of these distances shall be made under standard test condi-
tions (Chapter VI(5)) and is expressed in the form ‘l = … mm’. Vehicle
manufacturers may replace the measurement of these distances by a
theoretical calculation which takes into account the distribution of the
weight on the axles, vehicle unladen in normal running order (3). The1998R2135 — EN — 25.08.2002 — 001.001 — 17
(1) This way of computing the continuous driving time and the cumulative break time
serves into the recording equipment for computing the continuous driving time
warning. It does not prejudge the legal interpretation to be made of these times.
(2) UNKNOWN periods correspond to periods where the driver's card was not inserted in a
recording equipment and for which no manual entry of driver activities was made.
(3) Directive 97/27/EC of 22 July 1997 relating to the masses and dimensions of certain
categories of motor vehicles and their trailers and amending Directive 70/156/EEC
(OJ L 233, 25.8.1997, p. 1).
▼M1
methods for such theoretical calculation will be approved by a compe-
tent Member State authority;
(v) ‘event’ means:
abnormal operation detected by the recording equipment which may
come from a fraud attempt;
(w) ‘fault’ means:
abnormal operation detected by the recording equipment which may
come from an equipment malfunction or failure;
(x) ‘installation’ means:
mounting of the recording equipment in a vehicle;
(y) ‘motion sensor’ means:
part of the recording equipment, providing a signal representative of
vehicle speed and/or distance travelled;
(z) ‘non valid card’ means:
a card detected as faulty, or which initial authentication failed, or which
start of validity date is not yet reached, or which expiry date has passed;
(aa) ‘out of scope’ means:
when the use of the recording equipment is not required, according to
the provisions of Council Regulation (EEC) No 3820/85;
(bb) ‘over speeding’ means:
exceeding the authorised speed of the vehicle, defined as any period of
more than 60 seconds during which the vehicle's measured speed
exceeds the limit for setting the speed limitation device laid down in
Council Directive 92/6/EEC of 10 February 1992 on the installation
and use of speed limitation devices for certain categories of motor vehi-
cles in the Community (1);
(cc) ‘periodic inspection’ means:
set of operations performed to control that the recording equipment
works properly and that its settings correspond to the vehicle para-
meters;
(dd) ‘printer’ means:
component of the recording equipment which provides printouts of
stored data;
(ee) ‘recording equipment’ means:
the total equipment intended for installation in road vehicles to show,
record and store automatically or semi-automatically details of the
movement of such vehicles and of certain work periods of their drivers;
(ff) ‘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.
Renewal always implies the certainty that two valid cards do not co-
exist;
(gg) ‘repair’ means:
any repair of a motion sensor or of a vehicle unit that requires discon-
nection of its power supply, or disconnection from other recording
equipment components, or opening of it;
(hh) ‘replacement’ means:
issue of a tachograph card in replacement of an existing card, which has
been declared lost, stolen or malfunctioning and has not been returned to
the issuing authority. Replacement always implies a risk that two valid
cards may co-exist;
(ii) ‘security certification’ means:
process to certify, by an ITSEC (2) certification body, that the recording
equipment (or component) or the tachograph card under investigation
fulfils the security requirements defined in Appendix 10 Generic
security targets;1998R2135 — EN — 25.08.2002 — 001.001 — 18
(1) OJ L 57, 2.3.1992, p. 27.
(2) Council Recommendation 95/144/EC of 7 April 1995 on common information tech-
nology security evaluation criteria (OJ L 93, 26.4.1995, p. 27).
▼M1
(jj) ‘self test’ means:
tests run cyclically and automatically by the recording equipment to
detect faults;
(kk) ‘tachograph card’ means:
smart card intended for use with the recording equipment. Tachograph
cards allow for identification by the recording equipment of the identity
(or identity group) of the cardholder and allow for data transfer and
storage. A tachograph card may be of the following types:
— driver card,
— control card,— workshop card,— company card;
(ll) ‘type approval’ means:
process to certify, by a Member State, that the recording equipment (or
component) or the tachograph card under investigation fulfils the
requirements of this regulation;
(mm) ‘tyre size’ means:
the designation of the dimensions of the tyres (external driving wheels)
in accordance with Directive 92/23/EEC of 31 march 1992 (
1);
(nn) ‘vehicle identification’ means:
numbers identifying the vehicle: vehicle registration number (VRN) with
indication of the registering Member State and vehicle identification
number (VIN) (2);
(oo) ‘vehicle unit (VU)’ means:
the recording equipment excluding the motion sensor and the cables
connecting the motion sensor. The vehicle unit may either be a single
unit or be several units distributed in the vehicle, as long as it complies
with the security requirements of this regulation;
(pp) for computing sake in the recording equipment ‘week’ means:
the period between 00.00 hours UTC on Monday and 24.00 UTC on
Sunday;
(qq) ‘workshop card’ means:
a tachograph card issued by the authorities of a Member State to a
recording equipment manufacturer, a fitter, a vehicle manufacturer or
workshop, approved by that Member State.
The workshop card identifies the cardholder and allows for testing, cali-
bration and/or downloading of the recording equipment;
II. GENERAL CHARACTERISTICS AND FUNCTIONS OF THE
RECORDING EQUIPMENT
Any vehicle fitted with the recording equipment complying with the provisions
of this Annex, must include a speed display and an odometer. These functions
may be included within the recording equipment.
1.General characteristics
The purpose of the recording equipment is to record, store, display, print, and
output data related to driver activities.
The recording equipment includes cables, a motion sensor, and a vehicle unit.
The vehicle unit includes a processing unit, a data memory, a real time clock,
two smart card interface devices (driver and co-driver), a printer, a display, a
visual warning, a calibration/downloading connector, and facilities for entry of
user's inputs.
The recording equipment may be connected to other devices through additional
connectors.
Any inclusion in or connection to the recording equipment of any function,
device, or devices, approved or otherwise, shall not interfere with, or be capable1998R2135 — EN — 25.08.2002 — 001.001 — 19
(1) OJ L 129, 14.5.1992, p. 95.
(2) Directive 76/114/EEC, of 18 December 1975 on the approximation of the laws of the
Member States relating to statutory plates and inscriptions for motor vehicles and their
trailers, and their location and method of attachment (OJ L 24, 30.1.1976, p. 1).
▼M1
of interfering with, the proper and secure operation of the recording equipment
and the provisions of the Regulation.
Recording equipment users identify themselves to the equipment via tachograph
cards.
The recording equipment provides selective access rights to data and functions
according to user's type and/or identity.
The recording equipment records and stores data in its data memory and in
tachograph cards.
This is done in accordance with Directive 95/46/EC of 24 October 1995 on the
protection of individuals with regard to the processing of personal data and on
the free movement of such data (1).
2.Functions
The recording equipment shall ensure the following functions:— monitoring cards insertions and withdrawals,
— speed and distance measurement,
— time measurement,— monitoring driver activities,— monitoring driving status,— drivers manual entries:
— entry of places where daily work periods begin and/or end,
— manual entry of driver activities,— entry of specific conditions,
— company locks management,
— monitoring control activities,
— detection of events and/or faults,— built-in and self tests,— reading from data memory,— recording and storing in data memory,— reading from tachograph cards,
— recording and storing in tachograph cards,
— displaying,— printing,— warning,— data downloading to external media,— output data to additional external devices,
— calibration,
— time adjustment.
3.Modes of operation
The recording equipment shall possess four modes of operation:
— operational mode,
— control mode,— calibration mode,— company mode.1998R2135 — EN — 25.08.2002 — 001.001 — 20
(1) OJ L 281, 23.11.1995, p. 31.
▼M1
The recording equipment shall switch to the following mode of operation
according to the valid tachograph cards inserted into the card interface devices:
Mode of operationDriver slot
No card Driver card Control card Workshop card Company cardCo-driver slotNo card Operational Operational Control Calibration Company
Driver card Operational Operational Control Calibration Company
Control card Control Control Control (*) Operational OperationalWorkshop
cardCalibration Calibration Operational Calibration (*) Operational
Company
cardCompany Company Operational Operational Company (*)
(*) In these situations the recording equipment shall use only the tachograph card inserted in the driver slot.
The recording equipment shall ignore non-valid cards inserted, except
displaying, printing or downloading data held on an expired card which shall
be possible.
All functions listed in II.2. shall work in any mode of operation with the
following exceptions:
— the calibration function is accessible in the calibration mode only,
— the time adjustment function is limited when not in the calibration mode,— the driver manual entries functions are accessible in operational or calibra-
tion modes only,
— the company locks management function is accessible in the company mode
only,
— the monitoring of control activities function is operational in the control
mode only,
— the downloading function is not accessible in the operational mode (except
as provided for in Requirement 150).
The recording equipment can output any data to display, printer or external
interfaces with the following exceptions:
— in the operational mode, any personal identification (surname and first
name(s)) not corresponding to a tachograph card inserted shall be blankedand any card number not corresponding to a tachograph card inserted shall
be partially blanked (every odd character — from left to right — shall be
blanked),
— in the company mode, driver related data (requirements 081, 084 and 087)
can be output only for periods not locked by another company (as identified
by the first 13 digits of the company card number),
— when no card is inserted in the recording equipment, driver related data can
be output only for the current and eight previous calendar days.
4.Security
The system security aims at protecting the data memory in such a way as to
prevent unauthorised access to and manipulation of the data and detecting any
such attempts, protecting the integrity and authenticity of data exchanged
between the motion sensor and the vehicle unit, protecting the integrity and
authenticity of data exchanged between the recording equipment and the tacho-
graph cards, and verifying the integrity and authenticity of data downloaded.
In order to achieve the system security, the recording equipment shall meet the
security requirements specified in the motion sensor and vehicle unit generic
security targets (Appendix 10).
III. CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR
RECORDING EQUIPMENT
1.Monitoring cards insertion and withdrawal
The recording equipment shall monitor the card interface devices to detect card
insertions and withdrawals.1998R2135 — EN — 25.08.2002 — 001.001 — 21
▼M1
Upon card insertion the recording equipment shall detect whether the card
inserted is a valid tachograph card and in such a case identify the card type.
The recording equipment shall be so designed that the tachograph cards are
locked in position on their proper insertion into the card interface devices.
The release of tachograph cards may function only when the vehicle is stopped
and after the relevant data have been stored on the cards. The release of the card
shall require positive action by the user.
2.Speed and distance measurement
This function shall continuously measure and be able to provide the odometer
value corresponding to the total distance travelled by the vehicle.
This function shall continuously measure and be able to provide the speed of the
vehicle.
The speed measurement function shall also provide the information whether the
vehicle is moving or stopped. The vehicle shall be considered as moving as soon
as the function detects more than 1 imp/sec for at least five seconds from the
motion sensor, otherwise the vehicle shall be considered as stopped.
Devices displaying speed (speedometer) and total distance travelled (odometer)
installed in any vehicle fitted with a recording equipment complying with the
provisions of this Regulation, shall comply with the requirements relating to
maximum tolerances laid down in this Annex (Chapters III(2)(1) and III(2)(2)).
2.1. Measurement of distance travelled
The distance travelled may be measured either:— so as to cumulate both forward and reverse movements, or
— so as to include only forward movement.
The recording equipment shall measure distance from 0 to 9 999 999,9 km.
Distance measured shall be within the following tolerances (distances of at least
1 000 m):
— ± 1 % before installation,
— ± 2 % on installation and periodic inspection,— ± 4 % in use.
Distance measured shall have a resolution better than or equal to 0,1 km.
2.2. Measurement of speed
The recording equipment shall measure speed from 0 to 220 km/h.
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 4 000 and 25 000 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.
The speed shall be measured correctly within the normal tolerances within 2
seconds of the end of a speed change when the speed has changed at a rate up
to 2 m/s
2.
Speed measurement shall have a resolution better than or equal to 1 km/h.
3.Time measurement
The time measurement function shall measure permanently and digitally provide
UTC date and time.
UTC date and time shall be used for dating throughout the recording equipment
(recordings, printouts, data exchange, display, …).
In order to visualise the local time, it shall be possible to change the offset of
the time displayed, in half hour steps.
Time drift shall be within ± 2 seconds per day in type approval conditions.
Time measured shall have a resolution better than or equal to 1 second.
Time measurement shall not be affected by an external power supply cut-off of
less than 12 months in type approval conditions.1998R2135 — EN — 25.08.2002 — 001.001 — 22
▼M1
4.Monitoring driver activities
This function shall permanently and separately monitor the activities of one
driver and one co-driver.
Driver activity shall be DRIVING, WORK, AVAILABILITY, or BREAK/
REST.
It shall be possible for the driver and/or the co-driver to manually select WORK,
AVAILABILITY, or BREAK/REST.
When the vehicle is moving, DRIVING shall be selected automatically for the
driver and AVAILABILITY shall be selected automatically for the co-driver.
When the vehicle stops, WORK shall be selected automatically for the driver.The first change of activity arising within 120 seconds of the automatic change
to WORK due to the vehicle stop shall be assumed to have happened at the time
of vehicle stop (therefore possibly cancelling the change to WORK).
This function shall output activity changes to the recording functions at a reso-
lution of one minute.
Given a calendar minute, if any DRIVING activity has occurred within the
minute, the whole minute shall be regarded as DRIVING.
Given a calendar minute, if any DRIVING activity has occurred within both the
immediately preceding and the immediately succeeding minute, the whole
minute shall be regarded as DRIVING.
Given a calendar minute that is not regarded as DRIVING according to previous
requirements, the whole minute shall be regarded to be of the same type of
activity as the longest continuous activity within the minute (or the latest of
the equally longest).
This function shall also permanently monitor the continuous driving time and
the cumulative break time of the driver.
5.Monitoring driving status
This function shall permanently and automatically monitor the driving status.
The driving status CREW shall be selected when two valid driver cards are
inserted in the equipment, the driving status SINGLE shall be selected in any
other case.
6.Drivers manual entries
6.1. Entry of places where daily work periods begin and/or end
This function shall allow for the entry of places where the daily work periods
begin and/or end for a driver and/or a co-driver.
Places are defined as the country and, in addition where applicable, the region.
At the time of a driver (or workshop) card withdrawal, the recording equipment
shall prompt the (co-)driver to enter a ‘place where the daily work period ends’.
The recording equipment shall allow this request to be disregarded.It shall be possible to input places where daily work periods begin and/or end
without card or at times other than card insertion or withdrawal.
6.2. Manual entry of driver activities
Upon driver (or workshop) card insertion, and only at this time, the recording
equipment shall:
— remind the cardholder the date and time of his last card withdrawal, and
— ask the cardholder to identify if the current insertion of the card represents a
continuation of the current daily work period.
The recording equipment shall allow the cardholder to disregard the question
without answering, or to answer positively, or to answer negatively:
— in the case where the cardholder disregards the question, the recording
equipment shall prompt the cardholder for a ‘place where the daily work
period begins’. The recording equipment shall allow this request to be disre-
garded. If a location is entered, then it shall be recorded, in the data memory
and in the tachograph card, and related to the card insertion time,
— in the case of a negative or positive answer, the recording equipment shall
invite the cardholder to enter activities manually, with their dates and times
of beginning and end, among WORK, AVAILABILITY, or BREAK/REST
only, strictly included within the period last card withdrawal — current1998R2135 — EN — 25.08.2002 — 001.001 — 23
▼M1
insertion only, and without allowing such activities to overlap mutually. This
shall be done in accordance with the following procedures:
— in the case where the cardholder answers positively to the question, the
recording equipment shall invite the cardholder to enter activities manu-
ally, in chronological order, for the period last card withdrawal —
current insertion. The process shall end when the end time of a manually
entered activity equals the card insertion time.
— in the case where the cardholder answers negatively to the question, the
recording equipment shall:
— invite the card holder to enter manually activities in chronological
order from the card withdrawal time up to the time of end of the
related daily work period (or of the activities related to that vehicle
in the case where the daily work period continues on a record sheet).
The recording equipment shall therefore, before allowing the card-
holder to enter manually each activity, invite the cardholder to
identify if the time of end of the last recorded activity represents
the end of a previous work period (see note below),
No tes: in the case where the cardholder fails to declare when the
previous work period ended, and manually enters an activity of
which end time equals the card insertion time, the recording equip-
ment shall:
— assume that the daily work period ended at the start of the first
REST (or remaining UNKNOWN) period after card withdrawal
or at the time of card withdrawal if no rest period has been
entered (and if no period remains UNKNOWN),
— assume that the start time (see below) equals the card insertion
time,
— proceed through the steps below;
— then, if the time of end of the related work period is different from
the time of card withdrawal, or if no place of end of daily work
period had been entered at that time, prompt the cardholder to
‘confirm or enter the place where the daily work period ended’ (the
recording equipment shall allow this request to be disregarded). If a
location is entered, it shall be recorded in the tachograph card only
and only if different from the one entered at card withdrawal (if one
was entered), and related to the time of end of the work period,
— then invite the cardholder to ‘enter a start time’ of the current daily
work period (or of the activities related to the current vehicle in the
case where the card holder previously used a record sheet during this
period), and prompt the cardholder for a ‘place where the daily work
period begins’ (the recording equipment shall allow this request to be
disregarded). If a location is entered, it shall be recorded in the
tachograph card and related to this start time. If this start time is
equal to the card insertion time, the location shall also be recorded
in the data memory,
— then, if this start time is different from the card insertion time, invite
the cardholder to enter manually activities in chronological order
from this start time up to the time of card insertion. The process shall
end when the end time of a manually entered activity equals the card
insertion time,
— the recording equipment shall then allow the card holder to modify any
activity manually entered, until validation by selection of a specific
command, and thereafter forbid any such modification,
— such answers to the initial question followed by no activity entries, shall
be interpreted by the recording equipment as if the cardholder had disre-
garded the question.
During this whole process, the recording equipment shall wait for entries no
longer than the following time-outs:
— if no interaction with the equipment's human machine interface is happening
during one minute (with a visual, and possibly audible, warning after 30
seconds) or,
— if the card is withdrawn or another driver (or workshop) card is inserted or,— as soon as the vehicle is moving,
in this case the recording equipment shall validate any entries already made.
6.3. Entry of specific conditions
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’1998R2135 — EN — 25.08.2002 — 001.001 — 24
▼M1
A ‘FERRY/TRAIN CROSSING’ may not occur if an ‘OUT OF SCOPE’ condi-
tion is opened.
An opened ‘OUT OF SCOPE’ condition must be automatically closed, by the
recording equipment, if a driver card is inserted or withdrawn.
7.Company locks management
This function shall allow the management of the locks placed by a company to
restrict data access in company mode to itself.
Company locks consist in a start date/time (lock-in) and an end date/time (lock-
out) associated with the identification of the company as denoted by the
company card number (at lock-in).
Locks may be turned ‘in’ or ‘out’ in real time only.
Locking-out shall only be possible for the company whose lock is ‘in’ (as iden-
tified by the first 13 digits of the company card number), or,
locking-out shall be automatic if another company locks in.
In the case where a company locks in and where the previous lock was for the
same company, then it will be assumed that the previous lock has not been
turned ‘out’ and is still ‘in’.
8.Monitoring control activities
This function shall monitor DISPLAYING, PRINTING, VU and card DOWN-
LOADING activities carried while in control mode.
This function shall also monitor OVER SPEEDING CONTROL activities while
in control mode. An over speeding control is deemed to have happened when, in
control mode, the ‘over speeding’ printout has been sent to the printer or to the
display, or when ‘events and faults’ data have been downloaded from the VU
data memory.
9.Detection of events and/or faults
This function shall detect the following events and/or faults:
9.1. Insertion of a non-valid card‘ ’ event
This event shall be triggered at the insertion of any non-valid card and/or when
an inserted valid card expires.
9.2. ‘Card conflict’ event
This event shall be triggered when any of the valid cards combination noted X
in the following table arise:
Card conflictDriver slot
No card Driver card Control card Workshop card Company cardCo-driver slotNo card
Driver card X
Control card X X X
Workshop
cardXXXX
Company
cardXXX
9.3. ‘Time overlap’ event
This event shall be triggered when the date/time of last withdrawal of a driver
card, as read from the card, is later than the current date/time of the recording
equipment in which the card is inserted.1998R2135 — EN — 25.08.2002 — 001.001 — 25
▼M1
9.4. ‘Driving without an appropriate card’ event
This event shall be triggered for any tachograph cards combination noted X in
the following table, when driver activity changes to DRIVING, or when there is
a change of the mode of operation while driver activity is DRIVING:
Driving without an
appropriate cardDriver slot
No (or non-
valid) cardDriver card Control card Workshop card Company cardCo-driver slotNo (or non-
valid) cardXXX
Driver card X X X X
Control card X X X X XWorkshop
cardXXX X
Company
cardXXXXX
9.5. ‘Card insertion while driving’ event
This event shall be triggered when a tachograph card is inserted in any slot,
while driver activity is DRIVING.
9.6. ‘Last card session not correctly closed’ event
This event shall be triggered when at card insertion the recording equipment
detects that, despite the provisions laid down in paragraph III(1), the previous
card session has not been correctly closed (the card has been withdrawn before
all relevant data have been stored on the card). This event shall be triggered by
driver and workshop cards only.
9.7. ‘Over speeding’ event
This event shall be triggered for each over speeding.
9.8. ‘Power supply interruption’ event
This event shall be triggered, while not in calibration mode, in case of any inter-
ruption exceeding 200 milliseconds of the power supply of the motion sensor
and/or of the vehicle unit. The interruption threshold shall be defined by the
manufacturer. The drop in power supply due to the starting of the engine of
the vehicle shall not trigger this event.
9.9. ‘Motion data error’ event
This event shall be triggered 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.
9.10. ‘Security breach attempt’ event
This event shall be triggered for any other event affecting the security of the
motion sensor and/or of the vehicle unit as specified within the generic security
targets of these components, while not in calibration mode.
9.11. ‘Card’ fault
This fault shall be triggered when a tachograph card failure occurs during opera-
tion.
9.12. ‘Recording equipment’ fault
This fault shall be triggered for any of these failures, while not in calibration
mode:
— VU internal fault,
— printer fault,1998R2135 — EN — 25.08.2002 — 001.001 — 26
▼M1
— display fault,
— downloading fault,— sensor fault.
10.Built-in and self tests
The recording equipment shall self-detect faults through self tests and built-in-
tests, according to the following table:
Sub-assembly to test Self test Built-in-test
Software Integrity
Data memory Access Access, data integrity
Card interface devices Access Access
Keyboard Manual checkPrinter (up to manufacturer) PrintoutDisplay Visual checkDownloading (performed only
during downloading)Proper operation
Sensor Proper operation Proper operation
11.Reading from data memory
The recording equipment shall be able to read any data stored in its data
memory.
12.Recording and storing in the data memory
For the purpose of this paragraph,
— ‘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 six
drivers or co-drivers, six card insertion withdrawal cycles, and 256 activity
changes. ‘365 days’ therefore include at least 2 190 (co-)drivers, 2 190 card
insertion withdrawal cycles, and 93 440 activity changes,
— times are recorded with a resolution of one minute, unless otherwise speci-
fied,
— odometer values are recorded with a resolution of one kilometre,— speeds are recorded with a resolution of 1 km/h.
Data stored into the data memory shall not be affected by an external power
supply cut-off of less than twelve months in type approval conditions.
The recording equipment shall be able to record and store implicitly or expli-
citly in its data memory the following:
12.1. Equipment identification data
12.1.1. Vehicle unit identification data
The recording equipment shall be able to store in its data memory the following
vehicle unit identification data:
— name of the manufacturer,
— address of the manufacturer,— part number,— serial number,— software version number,— software version installation date,— year of equipment manufacture,— approval number.1998R2135 — EN — 25.08.2002 — 001.001 — 27
▼M1
Vehicle unit identification data are recorded and stored once and for all by the
vehicle unit manufacturer, except the software-related data and the approval
number which may be changed in case of software upgrade.
12.1.2. Motion sensor identification data
The motion sensor shall be able to store in its memory the following identifica-
tion data:
— name of the manufacturer,
— part number,
— serial number,— approval number,
— embedded security component identifier (e.g. internal chip/processor part
number),
— operating system identifier (e.g. software version number).
Motion sensor identification data are recorded and stored once and for all in the
motion sensor, by the motion sensor manufacturer.
The vehicle unit shall be able to record and store in its data memory the
following currently paired motion sensor identification data:
— serial number,
— approval number,
— first pairing date.
12.2. Security elements
The recording equipment shall be able to store the following security elements:
— European public key,
— Member State certificate,
— equipment certificate,
— equipment private key.
Recording equipment security elements are inserted in the equipment by the
vehicle unit manufacturer.
12.3. Driver card insertion and withdrawal data
For each insertion and withdrawal cycle of a driver or workshop card in the
equipment, the recording equipment shall record and store in its data memory:
— the card holder's surname and first name(s) as stored in the card,
— the card's number, issuing Member State and expiry date as stored in the
card,
— the insertion date and time,
— the vehicle odometer value at card insertion,— the slot in which the card is inserted,
— the withdrawal date and time,
— the vehicle odometer value at card withdrawal,— the following information about the previous vehicle used by the driver, as
stored in the card:
— VRN and registering Member State,
— card withdrawal date and time,
— a flag indicating whether, at card insertion, the card holder has manually
entered activities or not.
The data memory shall be able to hold these data for at least 365 days.When storage capacity is exhausted, new data shall replace oldest data.
12.4. Driver activity data
The recording equipment shall record and store in its data memory whenever
there is a change of activity for the driver and/or the co-driver, and/or whenever
there is a change of driving status, and/or whenever there is an insertion or with-
drawal of a driver or workshop card:
— the driving status (CREW, SINGLE),
— the slot (DRIVER, CO-DRIVER),— the card status in the relevant slot (INSERTED, NOT INSERTED) (see
Note),
— the activity (DRIVING, AVAILABILITY, WORK, BREAK/REST),— the date and time of the change.1998R2135 — EN — 25.08.2002 — 001.001 — 28
▼M1
Note: INSERTED means that a valid driver or workshop card is inserted in the
slot. NOT INSERTED means the opposite, i.e. no valid driver or workshop card
is inserted in the slot (e.g. a company card is inserted or no card is inserted).
Note: Activity data manually entered by a driver are not recorded in the data
memory.
The data memory shall be able to hold driver activity data for at least 365 days.
When storage capacity is exhausted, new data shall replace oldest data.
12.5. Places where daily work periods start and/or end
The recording equipment shall record and store in its data memory whenever a
(co-)driver enters the place where a daily work period begins and/or ends:
— if applicable, the (co-)driver card number and card issuing Member State,
— the date and time of the entry (or the date/time related to the entry when the
entry is made during the manual entry procedure),
— the type of entry (begin or end, condition of entry),— the country and region entered,— the vehicle odometer value.
The data memory shall be able to hold daily work periods start and/or end data
for at least 365 days (with the assumption that one driver enters two records per
day).
When storage capacity is exhausted, new data shall replace oldest data.
12.6. Odometer data
The recording equipment shall record in its data memory the vehicle odometer
value and the corresponding date at midnight every calendar day.
The data memory shall be able to store midnight odometer values for at least
365 calendar days.
When storage capacity is exhausted, new data shall replace oldest data.
12.7. Detailed speed data
The recording equipment shall record and store in its data memory the instanta-
neous speed of the vehicle and the corresponding date and time at every second
of at least the last 24 hours that the vehicle has been moving.
12.8. Events data
For the purpose of this subparagraph, time shall be recorded with a resolution of
one second.
The recording equipment shall record and store in its data memory the following
data for each event detected according to the following storage rules:
Event Storage rules Data to be recorded per event
Card conflict — the 10 most recent events. — date and time of beginning
of event,
— date and time of end of
event,
— cards' type, number and
issuing Member State of the
two cards creating the
conflict.
Driving without an appropriate
card— the longest event for each
of the 10 last days of
occurrence,
— the five longest events
over the last 365 days.— date and time of beginning
of event,
— date and time of end of
event,
— cards' type, number and
issuing Member State of
any card inserted at begin-
ning and/or end of the
event,
— number of similar events
that day.
Card insertion while driving — the last event for each of
the 10 last days of occur-rence.— date and time of the event,
— card's type, number and
issuing Member State,1998R2135 — EN — 25.08.2002 — 001.001 — 29
▼M1
Event Storage rules Data to be recorded per event
— number of similar events
that day.
Last card session not correctly
closed— the 10 most recent events. — date and time of card inser-
tion,
— card's type, number and
issuing Member State,
— last session data as read
from the card:
— date and time of card
insertion,
— VRN and Member State
of registration.
Over speeding (1) — the most serious event for
each of the 10 last days of
occurrence (i.e. the one
with the highest average
speed),
— the five most serious
events over the last 365
days.
— the first event having
occurred after the last
calibration.— date and time of beginning
of event,
— date and time of end of
event,
— maximum speed measured
during the event,
— arithmetic average speed
measured during the event,
— card's type, number and
issuing Member State of the
driver (if applicable),
— number of similar events
that day.
Power supply interruption (2) — the longest event for each
of the 10 last days of
occurrence,
— the five longest events
over the last 365 days.— date and time of beginning
of event,
— date and time of end of
event,
— cards' type, number and
issuing Member State of
any card inserted at begin-
ning and/or end of the
event,
— number of similar events
that day.
Motion data error — the longest event for each
of the 10 last days of
occurrence,
— the five longest events
over the last 365 days.— date and time of beginning
of event,
— date and time of end of
event,
— cards' type, number and
issuing Member State of
any card inserted at begin-
ning and/or end of the
event,
— number of similar events
that day.
Security breach attempt — the 10 most recent events
per type of event.— date and time of beginning
of event,
— date and time of end of
event (if relevant),
— cards' type, number and
issuing Member State of
any card inserted at begin-
ning and/or end of the
event,
— type of event.
(1) The recording equipment shall also record and store in its data memory:
— the date and time of the last OVER SPEEDING CONTROL,
— the date and time of the first over speeding following this OVER SPEEDING CONTROL,— the number of over speeding events since the last OVER SPEEDING CONTROL.
(
2) These data may be recorded at power supply reconnection only, times may be known with an accuracy to
the minute.1998R2135 — EN — 25.08.2002 — 001.001 — 30
▼M1
12.9. Faults data
For the purpose of this subparagraph, time shall be recorded with a resolution of
one second.
The recording equipment shall attempt to record and store in its data memory
the following data for each fault detected according to the following storage
rules:
Fault Storage rules Data to be recorded per fault
Card fault — the 10 most recent driver
card faults.— date and time of beginning
of fault,
— date and time of end of
fault,
— card's type number and
issuing Member State.
Recording equipment faults — the 10 most recent faults
for each type of fault,
— the first fault after the last
calibration.— date and time of beginning
of fault,
— date and time of end of
fault,
— type of fault,— cards' type, number and
issuing Member State of
any card inserted at begin-
ning and/or end of the fault.
12.10. Calibration data
The recording equipment shall record and store in its data memory data relevant
to:
— known calibration parameters at the moment of activation,
— its very first calibration following its activation,— its first calibration in the current vehicle (as identified by its VIN),— the five most recent calibrations (If several calibrations happen within one
calendar day, only the last one of the day shall be stored).
The following data shall be recorded for each of these calibrations:
— purpose of calibration (activation, first installation, installation, periodic
inspection),
— workshop name and address,— workshop card number, card issuing Member State and card expiry date,— vehicle identification,— parameters updated or confirmed: w, k, l, tyre size, speed limiting device
setting, odometer (old and new values), date and time (old and new values).
The motion sensor shall record and store in its memory the following motion
sensor installation data:
— first pairing with a VU (date, time, VU approval number, VU serial
number),
— last pairing with a VU (date, time, VU approval number, VU serial number).
12.11. Time adjustment data
The recording equipment shall record and store in its data memory data relevant
to:
— the most recent time adjustment,
— the five largest time adjustments, since last calibration,
performed in calibration mode outside the frame of a regular calibration (defini-
tion (f)).
The following data shall be recorded for each of these time adjustments:
— date and time, old value,
— date and time, new value,
— workshop name and address,
— workshop card number, card issuing Member State and card expiry date.1998R2135 — EN — 25.08.2002 — 001.001 — 31
▼M1
12.12. Control activity data
The recording equipment shall record and store in its data memory the following
data relevant to the 20 most recent control activities:
— date and time of the control,
— control card number and card issuing Member State,
— type of the control (displaying and/or printing and/or VU downloading and/
or card downloading).
In case of downloading, the dates of the oldest and of the most recent days
downloaded shall also be recorded.
12.13. Company locks data
The recording equipment shall record and store in its data memory the following
data relevant to the 20 most recent company locks:
— lock-in date and time,
— lock-out date and time,
— company card number and card issuing Member State,
— company name and address.
12.14. Download activity data
The recording equipment shall record and store in its data memory the following
data relevant to the last data memory downloading to external media while in
company or in calibration mode:
— date and time of downloading,
— company or workshop card number and card issuing Member State,— company or workshop name.
12.15. Specific conditions data
The recording equipment shall record in its data memory the following data
relevant to specific conditions:
— date and time of the entry,
— type of specific condition.
The data memory shall be able to hold specific conditions data for at least 365
days (with the assumption that on average, one condition is opened and closed
per day). When storage capacity is exhausted, new data shall replace oldest data.
13.Reading from tachograph cards
The recording equipment shall be able to read from tachograph cards, where
applicable, the necessary data:
— to identify the card type, the card holder, the previously used vehicle, the
date and time of the last card withdrawal and the activity selected at that
time,
— to check that last card session was correctly closed,— to compute the driver's continuous driving time, cumulative break time and
cumulated driving times for the previous and the current week,
— to print requested printouts related to data recorded on a driver card,
— to download a driver card to external media.
In case of a reading error, the recording equipment shall try again, three times
maximum, the same read command, and then if still unsuccessful, declare the
card faulty and non-valid.
14.Recording and storing on tachograph cards
The recording equipment shall set the ‘card session data’ in the driver or work-
shop card right after the card insertion.
The recording equipment shall update data stored on valid driver, workshop and/
or control cards with all necessary data relevant to the period while the card is
inserted and relevant to the card holder. Data stored on these cards are specified
in Chapter IV.
The recording equipment shall update driver activity and location data (as speci-
fied in Chapter IV, paragraphs 5.2.5 and 5.2.6), stored on valid driver and/or
workshop cards, with activity and location data manually entered by the card-
holder.
Tachograph cards data update shall be such that, when needed and taking into
account card actual storage capacity, most recent data replace oldest data.1998R2135 — EN — 25.08.2002 — 001.001 — 32
▼M1
In the case of a writing error, the recording equipment shall try again, three
times maximum, the same write command, and then if still unsuccessful, declare
the card faulty and non valid.
Before releasing a driver card, and after all relevant data have been stored on
the card, the recording equipment shall reset the card session data.
15.Displaying
The display shall include at least 20 characters.
The minimum character size shall be 5 mm high and 3,5 mm wide.The display shall support the Latin 1 and Greek character sets defined by ISO
8859 parts 1 and 7, as specified in Appendix 1 Chapter 4 ‘Character sets’. The
display may use simplified glyphs (e.g. accented characters may be displayed
without accent, or lower case letters may be shown as upper case letters).
The display shall be provided with adequate non-dazzling lighting.Indications shall be visible from outside the recording equipment.The recording equipment shall be able to display:
— default data,
— data related to warnings,
— data related to menu access,
— other data requested by a user.
Additional information may be displayed by the recording equipment, provided
that it is clearly distinguishable from information required above.
The display of the recording equipment shall use the pictograms or pictogram
combinations listed in Appendix 3. Additional pictograms or pictogram combi-
nations may also be provided by the display, if clearly distinguishable from the
aforementioned pictogram or pictogram combinations.
The display shall always be ON when the vehicle is moving.The recording equipment may include a manual or automatic feature to turn the
display OFF when the vehicle is not moving.
Displaying format is specified in Appendix 5.
15.1. Default display
When no other information needs to be displayed, the recording equipment shall
display, by default, the following:
— the local time (as a result of UTC time + offset as set by the driver),
— the mode of operation,
— the current activity of the driver and the current activity of the co-driver,
— information related to the driver:
— if his current activity is DRIVING, his current continuous driving time
and his current cumulative break time,
— if his current activity is not DRIVING, the current duration of this
activity (since it was selected) and his current cumulative break time,
— information related to the co-driver:
— the current duration of his activity (since it was selected).
Display of data related to each driver shall be clear, plain and unambiguous. In
the case where the information related to the driver and the co-driver cannot be
displayed at the same time, the recording equipment shall display by default the
information related to the driver and shall allow the user to display the informa-
tion related to the co-driver.
In the case where the display width does not allow to display by default the
mode of operation, the recording equipment shall briefly display the new mode
of operation when it changes.
The recording equipment shall briefly display the card holder name at card
insertion.
When an ‘OUT OF SCOPE’ condition is opened, then the default display must
show using the relevant pictogram that the condition is opened (It is acceptable
that the driver's current activity may not be shown at the same time).
15.2. Warning display
The recording equipment shall display warning information using primarily the
pictograms of Appendix 3, completed where needed by an additional numeri-
cally coded information. A literal description of the warning may also be
added in the driver's preferred language.1998R2135 — EN — 25.08.2002 — 001.001 — 33
▼M1
15.3. Menu access
The recording equipment shall provide necessary commands through an appro-
priate menu structure.
15.4. Other displays
It shall be possible to display selectively on request:— the UTC date and time,
— the mode of operation (if not provided by default),
— the continuous driving time and cumulative break time of the driver,
— the continuous driving time and cumulative break time of the co-driver,
— the cumulated driving time of the driver for the previous and the current
week,
— the cumulated driving time of the co-driver for the previous and the current
week,
— the content of any of the six printouts under the same formats as the print-
outs themselves.
Printout content display shall be sequential, line by line. If the display width is
less than 24 characters the user shall be provided with the complete information
through an appropriate mean (several lines, scrolling, …). Printout lines devoted
to hand-written information may be omitted for display.
16.Printing
The recording equipment shall be able to print information from its data
memory and/or from tachograph cards in accordance with the six following
printouts:
— driver activities from card daily printout,
— driver activities from Vehicle Unit daily printout,
— events and faults from card printout,
— events and faults from Vehicle Unit printout,
— technical data printout,
— over speeding printout.
The detailed format and content of these printouts are specified in Appendix 4.
Additional data may be provided at the end of the printoutsAdditional printouts may also be provided by the recording equipment, if clearly
distinguishable from the six aforementioned printouts.
The ‘driver activities from card daily printout’ and ‘events and faults from card
printout’ shall be available only when a driver card or a workshop card is
inserted in the recording equipment. The recording equipment shall update data
stored on the relevant card before starting printing.
In order to produce the ‘driver activities from card daily printout’ or the ‘events
and faults from card printout’, the recording equipment shall:
— either automatically select the driver card or the workshop card if one only
of these cards is inserted,
— or provide a command to select the source card or select the card in the
driver slot if two of these cards are inserted in the recording equipment.
The printer shall be able to print 24 characters per line.
The minimum character size shall be 2,1 mm high and 1,5 mm wide.
The printer shall support the Latin 1 and Greek character sets defined by ISO
8859 parts 1 and 7, as specified in Appendix 1 Chapter 4 ‘Character sets’.
Printers shall be so designed as to produce these printouts with a degree of defi-
nition likely to avoid any ambiguity when they are read.
Printouts shall retain their dimensions and recordings under normal conditions
of humidity (10 to 90 %) and temperature.
The paper for use by the recording equipment shall bear the relevant type
approval mark and the indication of the type(s) of recording equipment with
which it may be used. Printouts shall remain clearly legible and identifiable
under normal conditions of storage, in terms of light intensity, humidity and
temperature, for at least one year.
It shall also be possible to add handwritten notes, such as the driver's signature,
to these documents.
The recording equipment shall manage ‘paper out’ events while printing by,
once paper has been re-loaded, restarting printing from printout beginning or1998R2135 — EN — 25.08.2002 — 001.001 — 34
▼M1
by continuing printing and providing an unambiguous reference to previously
printed part.
17.Warnings
The recording equipment shall warn the driver when detecting any event and/or
fault.
Warning of a power supply interruption event may be delayed until the power
supply is reconnected.
The recording equipment shall warn the driver 15 minutes before and at the time
of exceeding 4 h 30 min. continuous driving time.
Warnings shall be visual. Audible warnings may also be provided in addition to
visual warnings.
Visual warnings shall be clearly recognisable by the user, shall be situated in the
driver's field of vision and shall be clearly legible both by day and by night.
Visual warnings may be built into the recording equipment and/or remote from
the recording equipment.
In the latter case it shall bear a ‘T’ symbol and shall be amber or orange.Warnings shall have a duration of at least 30 seconds, unless acknowledged by
the user by hitting any key of the recording equipment. This first acknowledge-
ment shall not erase warning cause display referred to in next paragraph.
Warning cause shall be displayed on the recording equipment and remain visible
until acknowledged by the user using a specific key or command of the
recording equipment.
Additional warnings may be provided, as long as they do not confuse drivers in
relation to previously defined ones.
18.Data downloading to external media
The recording equipment shall be able to download on request data from its data
memory or from a driver card to external storage media via the calibration/
downloading connector. The recording equipment shall update data stored on
the relevant card before starting downloading.
In addition and as an optional feature, the recording equipment may, in any
mode of operation, download data through another connector to a company
authenticated through this channel. In such a case, company mode data access
rights shall apply to this download.
Downloading shall not alter or delete any stored data.The calibration/downloading connector electrical interface is specified in
Appendix 6.
Downloading protocols are specified in Appendix 7.
19.Output data to additional external devices
When the recording equipment does not include speed and/or odometer display
functions, the recording equipment shall provide output signal(s) to allow for
displaying the speed of the vehicle (speedometer) and/or the total distance
travelled by the vehicle (odometer).
The vehicle unit shall also be able to output the following data using an appro-
priate dedicated serial link independent from an optional CAN bus connection
(ISO 11898 Road vehicles — Interchange of digital information — Controller
Area Network (CAN) for high speed communication), to allow their processing
by other electronic units installed in the vehicle:
— current UTC date and time,
— speed of the vehicle,— total distance travelled by the vehicle (odometer),
— currently selected driver and co-driver activity,
— information if any tachograph card is currently inserted in the driver slot and
in the co-driver slot and (if applicable) information about the corresponding
cards identification (card number and issuing Member State).
Other data may also be output in addition to this minimum list.
When the ignition of the vehicle is ON, these data shall be permanently broad-
cast. When the ignition of the vehicle is OFF, at least any change of driver or
co-driver activity and/or any insertion or withdrawal of a tachograph card shall
generate a corresponding data output. In the event that data output has been
withheld whilst the ignition of the vehicle is OFF, that data shall be made avail-
able once the ignition of the vehicle is ON again.1998R2135 — EN — 25.08.2002 — 001.001 — 35
▼M1
20.Calibration
The calibration function shall allow:
— to automatically pair the motion sensor with the VU,
— to digitally adapt the constant of the recording equipment (k) to the charac-
teristic coefficient of the vehicle (w) (vehicles with two or more axle ratios
shall be fitted with a switch device whereby these various ratios will auto-
matically be brought into line with the ratio for which the equipment has
been adapted to the vehicle),
— to adjust (without limitation) the current time,— to adjust the current odometer value,— to update motion sensor identification data stored in the data memory,— to update or confirm other parameters known to the recording equipment:
vehicle identification, w, l, tyre size and speed limiting device setting if
applicable.
Pairing the motion sensor to the VU shall consist, at least, in:
— updating motion sensor installation data held by the motion sensor (as
needed),
— copying from the motion sensor to the VU data memory necessary motion
sensor identification data.
The calibration function shall be able to input necessary data through the cali-
bration/downloading connector in accordance with the calibration protocol
defined in Appendix 8. The calibration function may also input necessary data
through other connectors.
21.Time adjustment
The time adjustment function shall allow for adjusting the current time in
amounts of one minute maximum at intervals of not less than seven days.
The time adjustment function shall allow for adjusting the current time without
limitation, in calibration mode.
22.Performance characteristics
The Vehicle Unit shall be fully operational in the temperature range − 20 ºC to
70 ºC, and the motion sensor in the temperature range − 40 ºC to 135 ºC. Data
memory content shall be preserved at temperatures down to − 40 ºC.
The recording equipment shall be fully operational in the humidity range 10 %
to 90 %.
The recording equipment shall be protected against over-voltage, inversion of its
power supply polarity, and short circuits.
The recording equipment shall conform to Commission Directive 95/54/EC of
31 October 1995 (
1) adapting to technical progress Council Directive 72/245/
EEC (2), related to electromagnetic compatibility, and shall be protected against
electrostatic discharges and transients.
23.Materials
All the constituent parts of the recording equipment shall be made of materials
of sufficient stability and mechanical strength and with stable electrical and
magnetic characteristics.
For normal conditions of use, all the internal parts of the equipment shall be
protected against damp and dust.
The Vehicle Unit shall meet the protection grade IP 40 and the motion sensor
shall meet the protection grade IP 64, as per standard IEC 529.
The recording equipment shall conform to applicable technical specifications
related to ergonomic design.
The recording equipment shall be protected against accidental damage.
24.Markings
If the recording equipment displays the vehicle odometer value and speed, the
following details shall appear on its display:
— near the figure indicating the distance, the unit of measurement of distance,
indicated by the abbreviation ‘km’,1998R2135 — EN — 25.08.2002 — 001.001 — 36
(1) OJ L 266, 8.11.1995, p. 1.
(2) OJ L 152, 6.7.1972, p. 15.
▼M1
— near the figure showing the speed, the entry ‘km/h’.
The recording equipment may also be switched to display the speed in miles per
hour, in which case the unit of measurement of speed shall be shown by the
abbreviation ‘mph’.
A descriptive plaque shall be affixed to each separate component of the
recording equipment and shall show the following details:
— name and address of the manufacturer of the equipment,
— manufacturer's part number and year of manufacture of the equipment,
— equipment serial number,— approval mark for the equipment type.
When physical space is not sufficient to show all abovementioned details, the
descriptive plaque shall show at least: the manufacturer's name or logo, and the
equipment's part number.
IV. CONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR TACHO-
GRAPH CARDS
1.Visible data
The front page will contain:the words ‘Driver card’ or ‘Control card’ or ‘Workshop card’ or ‘Company
card’ printed in large type in the official language or languages of the Member
State issuing the card, according to the type of the card;
the same words in the other official languages of the Community, printed to
form the background of the card:
ES TARJETA DEL
CONDUCTORTARJETA DE
CONTROLTARJETA DEL
CENTRO DE
ENSAYOTARJETA DE LA
EMPRESA
DK FØRERKORT KONTROLKORT VÆRKSTEDS-
KORTVIRKSOMHEDS-
KORT
DE FAHRERKARTE KONTROLLK-
ARTEWERKSTATT-
KARTEUNTERNEHMENS-
KARTE
EL ΚΑΡΤΑ Ο∆ΗΟΥ ΚΑΡΤΑ
ΕΛΕΓΧΟΥΚΑΡΤΑ
ΚΕΝΤΡΟΥ
∆ΟΚΙΜΩΝΚΑΡΤΑ ΕΠΙΧ-
ΕΙΡΗΣΗΣ
EN DRIVER CARD CONTROL CARD WORKSHOP
CARDCOMPANY CARD
FR CARTE DE
CONDUCTEURCARTE DE
CONTROLEURCARTE D'ATE-
LIERCARTE D'ENTRE-
PRISE
GA CÁRTA
TIOMÁNAÍCÁRTA
STIÚRTHACÁRTA CEAR-
DLAINNECÁRTA COMH-
LACHTA
IT CARTA DEL
CONDUCENTECARTA DI
CONTROLLOCARTA DELL'OF-
FICINACARTA DELL'A-
ZIENDA
NL BESTUURDERS
KAARTCONTROLE-
KAARTWERKPLAATS-
KAARTBEDRIJFSKAART
PT CARTÃO DE
CONDUTORCARTÃO DE
CONTROLOCARTÃO DO
CENTRO DE
ENSAIOCARTÃO DE
EMPRESA
FIN KULJETTAJA
KORTTILLAVALVONTA
KORTILLATESTAUSASEMA
KORTILLAYRITYSKORTILLA
SV FÖRARKORT KONTROLLKORT VERKSTADS-
KORTFÖRETAGSKORT
the name of the Member State issuing the card (optional);1998R2135 — EN — 25.08.2002 — 001.001 — 37
▼M1
the distinguishing sign of the Member State issuing the card, printed in negative
in a blue rectangle and encircled by 12 yellow stars. The distinguishing signs
shall be as follows:
B Belgium
DK DenmarkD Germany
GR Greece
E SpainF FranceIRL IrelandI ItalyL LuxembourgNL The Netherlands
A Austria
P PortugalFIN FinlandS SwedenUK The United Kingdom;information specific to the card issued, numbered as follows:
Driver card Control card Company or workshop card
1. Surname of the driver Control body name Company or workshop card
2. First name(s) of the driver Surname of the controller (if
applicable)Surname of card holder (if
applicable)
3. Birth date of the driver First name(s) of the
controller (if applicable)First name(s) of card holder
(if applicable)
4.(a) Card start of validity date
(b) Card expiry date (if any)(c) The name of the issuing authority (may be printed on page 2)(d) A different number from the one under heading 5, for administrative purposes (optional)
5.(a) Driving licence number (at
the date of issue of the
driver card)
5.(b) Card number6. Photograph of the driver Photograph of the controller
(optional)—
7. Signature of the driver Signature of the holder (optional)
8. Normal place of residence,
or postal address of the
holder (optional)Postal address of control
bodyPostal address of company or
workshop
dates shall be written using a ‘dd/mm/yyyy’ or ‘dd.mm.yyyy’ format (day,
month, year);
the reverse page will contain:an explanation of the numbered items which appear on the front page of the
card;
with the specific written agreement of the holder, information which is not
related to the administration of the card may also be added, such addition will
not alter in any way the use of the model as a tachograph card.1998R2135 — EN — 25.08.2002 — 001.001 — 38
▼M1
Tachograph cards shall be printed with the following background predominant
colours:
— driver card: white,
— control card: blue,— workshop card: red,— company card: yellow.
Tachograph cards shall bear at least the following features for protection of the
card body against counterfeiting and tampering:
— a security design background with fine guilloche patterns and rainbow
printing,
— in the area of the photograph, the security design background and the photo-
graph shall overlap,
— at least one two-coloured microprint line.
After consulting the Commission, Member States may add colours or markings,
such as national symbols and security features, without prejudice to the other
provisions of this Annex.1998R2135 — EN — 25.08.2002 — 001.001 — 39
▼M1
2.Security
The system security aims at protecting integrity and authenticity of data
exchanged between the cards and the recording equipment, protecting the integ-
rity and authenticity of data downloaded from the cards, allowing certain write
operations onto the cards to recording equipment only, ruling out any possibility
of falsification of data stored in the cards, preventing tampering and detecting
any attempt of that kind.
In order to achieve the system security, the tachograph cards shall meet the
security requirements defined in the tachograph cards generic security target
(Appendix 10).
Tachograph cards shall be readable by other equipment such as personal compu-
ters.
3.Standards
The tachograph cards shall comply with the following standards:
— ISO/IEC 7810 Identification cards — Physical characteristics,
— ISO/IEC 7816 Identification cards — Integrated circuits with contacts:
— Part 1: Physical characteristics,
— Part 2: Dimensions and location of the contacts,
— Part 3: Electronic signals and transmission protocols,
— Part 4: Inter-industry commands for interchange,— Part 8: Security related inter-industry commands,
— ISO/IEC 10373 Identification cards — Test methods.
4.Environmental and electrical specifications
The tachograph cards shall be capable of operating correctly in all the climatic
conditions normally encountered in Community territory and at least in the
temperature range − 25 ºC to + 70 ºC with occasional peaks of up to + 85 ºC,
‘occasional’ meaning not more than 4 hours each time and not over 100 times
during the lifetime of the card.
The tachograph cards shall be capable of operating correctly in the humidity
range 10 % to 90 %.
The tachograph cards shall be capable of operating correctly for a five-year
period if used within the environmental and electrical specifications.
During operation, the tachograph cards shall conform to Commission Directive
95/54/EC of 31 October 1995 (
1), related to electromagnetic compatibility, and
shall be protected against electrostatic discharges.
5.Data storage
For the purpose of this paragraph,
— times are recorded with a resolution of one minute, unless otherwise speci-
fied,
— odometer values are recorded with a resolution of one kilometre,— speeds are recorded with a resolution of 1 km/h.
The tachograph cards functions, commands and logical structures, fulfilling data
storage requirements are specified in Appendix 2.
This paragraph specifies minimum storage capacity for the various application
data files. The tachograph cards shall be able to indicate to the recording equip-
ment the actual storage capacity of these data files.
Any additional data that may be stored on tachograph cards, related to other
applications eventually borne by the card, shall be stored in accordance with
Directive 95/46/EC of 24 October 1995 on the protection of individuals with
regard to the processing of personal data and on the free movement of such
data (
2).1998R2135 — EN — 25.08.2002 — 001.001 — 40
(1) OJ L 266, 8.11.1995, p. 1.
(2) OJ L 281, 23.11.1995, p. 31.
▼M1
5.1. Card identification and security data
5.1.1. Application identification
The tachograph cards shall be able to store the following application identifica-
tion data:
— tachograph application identification,
— type of tachograph card identification.
5.1.2. Chip identification
The tachograph cards shall be able to store the following integrated circuit (IC)
identification data:
— IC serial number,
— IC manufacturing references.
5.1.3. IC card identification
The tachograph cards shall be able to store the following smart card identifica-
tion data:
— card serial number (including manufacturing references),
— card type approval number,
— card personaliser identification (ID),— embedder ID,
— IC identifier.
5.1.4. Security elements
The tachograph cards shall be able to store the following security elements data:
— European public key,
— Member State certificate,— card certificate,
— card private key.
5.2. Driver card
5.2.1. Card identification
The driver card shall be able to store the following card identification data:
— card number,
— issuing Member State, issuing authority name, issue date,
— card beginning of validity date, card expiry date.
5.2.2. Card holder identification
The driver card shall be able to store the following card holder identification
data:
— surname of the holder,
— first name(s) of the holder,— date of birth,
— preferred language.
5.2.3. Driving licence information
The driver card shall be able to store the following driving licence data:
— issuing Member State, issuing authority name,
— driving licence number (at the date of the issue of the card).
5.2.4. Vehicles used data
The driver card shall be able to store, for each calendar day where the card has
been used, and for each period of use of a given vehicle that day (a period of
use includes all consecutive insertion/withdrawal cycle of the card in the
vehicle, as seen from the card point of view), the following data:
— date and time of first use of the vehicle (i.e. first card insertion for this
period of use of the vehicle, or 00.00 if the period of use is on-going at
that time),
— vehicle odometer value at that time,1998R2135 — EN — 25.08.2002 — 001.001 — 41
▼M1
— date and time of last use of the vehicle, (i.e. last card withdrawal for this
period of use of the vehicle, or 23.59 if the period of use is on-going at
that time),
— vehicle odometer value at that time,— VRN and registering Member State of the vehicle.
The driver card shall be able to store at least 84 such records.
5.2.5. Driver activity data
The driver card shall be able to store, for each calendar day where the card has
been used or for which the driver has entered activities manually, the following
data:
— the date,
— a daily presence counter (increased by one for each of these calendar days),— the total distance travelled by the driver during this day,— a driver status at 00.00,— whenever the driver has changed of activity, and/or has changed of driving
status, and/or has inserted or withdrawn his card:
— the driving status (CREW, SINGLE),
— the slot (DRIVER, CO-DRIVER),— the card status (INSERTED, NOT INSERTED),— the activity (DRIVING, AVAILABILITY, WORK, BREAK/REST),— the time of the change.
The driver card memory shall be able to hold driver activity data for at least 28
days (the average activity of a driver is defined as 93 activity changes per day).
The data listed under requirements 197 and 199 shall be stored in a way
allowing the retrieval of activities in the order of their occurrence, even in case
of a time overlap situation.
5.2.6. Places where daily work periods start and/or end
The driver card shall be able to store the following data related to places where
daily work periods begin and/or end, entered by the driver:
— the date and time of the entry (or the date/time related to the entry if the
entry is made during the manual entry procedure),
— the type of entry (begin or end, condition of entry),— the country and region entered,— the vehicle odometer value.
The driver card memory shall be able to hold at least 42 pairs of such records.
5.2.7. Events data
For the purpose of this subparagraph, time shall be stored with a resolution of
one second.
The driver card shall be able to store data related to the following events
detected by the recording equipment while the card was inserted:
— time overlap (where this card is the cause of the event),
— card insertion while driving (where this card is the subject of the event),— last card session not correctly closed (where this card is the subject of the
event),
— power supply interruption,— motion data error,— security breach attempts.
The driver card shall be able to store the following data for these events:
— event code,
— date and time of beginning of the event (or of card insertion if the event was
on-going at that time),
— date and time of end of the event (or of card withdrawal if the event was on-
going at that time),
— VRN and registering Member State of vehicle in which the event happened.
Note: For the ‘time overlap’ event:
— date and time of beginning of the event shall correspond to the date and time
of the card withdrawal from the previous vehicle,
— date and time of end of the event shall correspond to the date and time of
card insertion in current vehicle,1998R2135 — EN — 25.08.2002 — 001.001 — 42
▼M1
— vehicle data shall correspond to the current vehicle raising the event.
Note: For the ‘last card session not correctly closed’ event:
— date and time of beginning of event shall correspond to the card insertion
date and time of the session not correctly closed,
— date and time of end of event shall correspond to the card insertion date and
time of the session during which the event was detected (current session),
— vehicle data shall correspond to the vehicle in which the session was not
correctly closed.
The driver card shall be able to store data for the six most recent events of each
type (i.e. 36 events).
5.2.8. Faults data
For the purpose of this subparagraph, time shall be recorded with a resolution of
one second.
The driver card shall be able to store data related to the following faults
detected by the recording equipment while the card was inserted:
— card fault (where this card is the subject of the event),
— recording equipment fault.
The driver card shall be able to store the following data for these faults:
— fault code,
— date and time of beginning of the fault (or of card insertion if the fault was
on-going at that time),
— date and time of end of the fault (or of card withdrawal if the fault was on-
going at that time),
— VRN and registering Member State of vehicle in which the fault happened.
The driver card shall be able to store data for the twelve most recent faults of
each type (i.e. 24 faults).
5.2.9. Control activity data
The driver card shall be able to store the following data related to control activ-
ities:
— date and time of the control,
— control card number and card issuing Member State,
— type of the control (displaying and/or printing and/or VU downloading and/
or card downloading (see note)),
— period downloaded, in case of downloading,
— VRN and registering Member State of the vehicle in which the control
happened.
Note: security requirements imply that card downloading will only be recorded
if performed through a recording equipment.
The driver card shall be able to hold one such record.
5.2.10. Card session data
The driver card shall be able to store data related to the vehicle which opened
its current session:
— date and time the session was opened (i.e. card insertion) with a resolution
of one second,
— VRN and registering Member State.
5.2.11. Specific conditions data
The driver card shall be able to store the following data related to specific
conditions entered while the card was inserted (whatever the slot):
— date and time of the entry,
— type of specific condition.
The driver card shall be able to hold 56 such records.
5.3. Workshop card
5.3.1. Security elements
The workshop card shall be able to store a personal identification number (PIN
code).1998R2135 — EN — 25.08.2002 — 001.001 — 43
▼M1
The workshop card shall be able to store the cryptographic keys needed for
pairing motion sensors to vehicle units.
5.3.2. Card identification
The workshop card shall be able to store the following card identification data:
— card number,
— issuing Member State, issuing authority name, issue date,
— card beginning of validity date, card expiry date.
5.3.3. Card holder identification
The workshop card shall be able to store the following card holder identification
data:
— workshop name,
— workshop address,— surname of the holder,
— first name(s) of the holder,
— preferred language.
5.3.4. Vehicles used data
The workshop card shall be able to store vehicles used data records in the same
manner as a driver card.
The workshop card shall be able to store at least 4 such records.
5.3.5. Driver activity data
The workshop card shall be able to store driver activity data in the same manner
as a driver card.
The workshop card shall be able to hold driver activity data for at least one day
of average driver activity.
5.3.6. Daily work periods start and/or end data
The workshop card shall be able to store daily works period start and/or end
data records in the same manner as a driver card.
The workshop card shall be able to hold at least three pairs of such records.
5.3.7. Events and faults data
The workshop card shall be able to store events and faults data records in the
same manner as a driver card.
The workshop card shall be able to store data for the three most recent events of
each type (i.e. 18 events) and the six most recent faults of each type (i.e. 12
faults).
5.3.8. Control activity data
The workshop card shall be able to store a control activity data record in the
same manner as a driver card.
5.3.9. Calibration and time adjustment data
The workshop card shall be able to hold records of calibrations and/or time
adjustments performed while the card is inserted in a recording equipment.
Each calibration record shall be able to hold the following data:
— purpose of calibration (first installation, installation, periodic inspection),
— vehicle identification,— parameters updated or confirmed (w, k, l, tyre size, speed limiting device
setting, odometer (new and old values), date and time (new and old values),
— recording equipment identification (VU part number, VU serial number,
motion sensor serial number).
The workshop card shall be able to store at least 88 such records.
The workshop card shall hold a counter indicating the total number of calibra-
tions performed with the card.
The workshop card shall hold a counter indicating the number of calibrations
performed since its last download.1998R2135 — EN — 25.08.2002 — 001.001 — 44
▼M1
5.3.10. Specific conditions data
The workshop card shall be able to store data relevant to specific conditions in
the same manner as the driver card. The workshop card shall be able to store
two such records.
5.4. Control card
5.4.1. Card identification
The control card shall be able to store the following card identification data:
— card number,
— issuing Member State, issuing authority name, issue date,
— card beginning of validity date, card expiry date (if any).
5.4.2. Card holder identification
The control card shall be able to store the following card holder identification
data:
— control body name,
— control body address,— surname of the holder,
— first name(s) of the holder,
— preferred language.
5.4.3. Control activity data
The control card shall be able to store the following control activity data:
— date and time of the control,
— type of the control (displaying and/or printing and/or VU downloading and/
or card downloading),
— period downloaded (if any),— VRN and Member State registering authority of the controlled vehicle,
— card number and card issuing Member State of the driver card controlled.
The control card shall be able to hold at least 230 such records.
5.5. Company card
5.5.1. Card identification
The company card shall be able to store the following card identification data:
— card number,
— issuing Member State, issuing authority name, issue date,
— card beginning of validity date, card expiry date (if any).
5.5.2. Card holder identification
The company card shall be able to store the following card holder identification
data:
— company name,
— company address.
5.5.3. Company activity data
The company card shall be able to store the following company activity data:
— date and time of the activity,
— type of the activity (VU locking in and/or out, and/or VU downloading and/
or card downloading),
— period downloaded (if any),— VRN and Member State registering authority of vehicle,— card number and card issuing Member State (in case of card downloading).
The company card shall be able to hold at least 230 such records.1998R2135 — EN — 25.08.2002 — 001.001 — 45
▼M1
V. INSTALLATION OF RECORDING EQUIPMENT
1.Installation
New recording equipment shall be delivered non-activated to fitters or vehicle
manufacturers, with all calibration parameters, as listed in Chapter III(20), set
to appropriate and valid default values. Where no particular value is appropriate,
literal parameters shall be set to strings of ‘?’ and numeric parameters shall be
set to ‘0’.
Before its activation, the recording equipment shall give access to the calibration
function even if not in calibration mode.
Before its activation, the recording equipment shall neither record nor store data
referred by points III.12.3. to III.12.9. and III.12.12 to III.12.14. inclusive.
During installation, vehicle manufacturers shall pre-set all known parameters.Vehicle manufacturers or fitters shall activate the installed recording equipment
before the vehicle leaves the premises where the installation took place.
The activation of the recording equipment shall be triggered automatically by
the first insertion of a workshop card in either of its card interface devices.
Specific pairing operations required between the motion sensor and the vehicle
unit, if any, shall take place automatically before or during activation.
After its activation, the recording equipment shall fully enforce functions and
data access rights.
The recording and storing functions of the recording equipment shall be fully
operational after its activation.
Installation shall be followed by a calibration. The first calibration will include
entry of VRN and will take place within 2 weeks of this installation or of VRN
allocation whichever comes last.
The recording equipment must be positioned in the vehicle in such a way as to
allow the driver to access the necessary functions from his seat.
2.Installation plaque
After the recording equipment has been checked on installation, an installation
plaque which is clearly visible and easily accessible shall be affixed on, in or
beside the recording equipment. After every inspection by an approved fitter or
workshop, a new plaque shall be affixed in place of the previous one.
The plaque shall bear at least the following details:
— name, address or trade name of the approved fitter or workshop,
— characteristic coefficient of the vehicle, in the form ‘w = … imp/km’,— constant of the recording equipment, in the form ‘k = … imp/km’,— effective circumference of the wheel tyres in the form ‘l = … mm’,
— tyre size,
— the date on which the characteristic coefficient of the vehicle was deter-
mined and the effective circumference of the wheel tyres measured,
— the vehicle identification number.
3.Sealing
The following part shall be sealed:
— any connection which, if disconnected, would cause undetectable alterations
to be made or undetectable data loss,
— the installation plaque, unless it is attached in such a way that it cannot be
removed without the markings thereon being destroyed.
The seals mentioned above may be removed:
— in case of emergency,
— to install, to adjust or to repair a speed limitation device or any other device
contributing to road safety, provided that the recording equipment continues
to function reliably and correctly and is resealed by an approved fitter or
workshop (in accordance with Chapter VI) immediately after fitting the
speed limitation device or any other device contributing to road safety or
within seven days in other cases.
On each occasion that these seals are broken a written statement giving the
reasons for such action shall be prepared and made available to the competent
authority.1998R2135 — EN — 25.08.2002 — 001.001 — 46
▼M1
VI. CHECKS, INSPECTIONS AND REPAIRS
Requirements on the circumstances in which seals may be removed, as referred
to in Article 12.5 of Regulation (EEC) No 3821/85 as last amended by Regula-
tion (EC) No 2135/98, are defined in Chapter V(3) of this annex.
1.Approval of fitters or workshops
The Member States will approve, regularly control and certify the bodies to
carry out:
— installations,
— checks,— inspections,— repairs.
In the framework of Article 12(1) of this Regulation, workshop cards will be
issued only to fitters and/or workshops approved for the activation and/or the
calibration of recording equipment in conformity with this annex and, unless
duly justified:
— who are not eligible for a company card,
— and whose other professional activities do not present a potential compro-
mise of the overall security of the system as defined in Appendix 10.
2.Check of new or repaired instruments
Every individual device, whether new or repaired, shall be checked in respect of
its proper operation and the accuracy of its reading and recordings, within the
limits laid down in Chapter III.2.1. and III.2.2 by means of sealing in accor-
dance with Chapter V.3. and calibration.
3.Installation inspection
When being fitted to a vehicle, the whole installation (including the recording
equipment) shall comply with the provisions relating to maximum tolerances
laid down in Chapter III.2.1 and III.2.2.
4.Periodic inspections
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 coeffi-
cient of the vehicle or of the effective circumference of the tyres, or after
equipment UTC time is wrong by more than 20 minutes, or when the VRN
has changed, and at least once within two years (24 months) of the last inspec-
tion.
These inspections shall include the following checks:
— that the recording equipment is working properly, including the data storage
in tachograph cards function,
— that compliance with the provisions of Chapter III.2.1 and III.2.2 on the
maximum tolerances on installation is ensured,
— that the recording equipment carries the type approval mark,— that the installation plaque is affixed,
— that the seals on the equipment and on the other parts of the installation are
intact,
— the tyre size and the actual circumference of the wheel tyres.
These inspections shall include a calibration.
5.Measurement of errors
The measurement of errors on installation and during use shall be carried out
under the following conditions, which are to be regarded as constituting stan-
dard test conditions:
— vehicle unladen, in normal running order,
— tyre pressures in accordance with the manufacturer's instructions,
— tyre wear, within the limits allowed by national law,— vehicle movement:
— the vehicle shall advance under its own engine power in a straight line
on level ground and at a speed of 50 ± 5 km/h. The measuring distance
shall be at least 1 000 m,
— provided that it is of comparable accuracy, alternative methods, such as a
suitable test bench, may also be used for the test.1998R2135 — EN — 25.08.2002 — 001.001 — 47
▼M1
6.Repairs
Workshops shall be able to download data from the recording equipment to give
the data back to the appropriate transport company.
Approved workshops shall issue to transport companies a certificate of data un-
downloadability where the malfunction of the recording equipment prevents
previously recorded data to be downloaded, even after repair by this workshop.
The workshops will keep a copy of each issued certificate for at least one year.
VII. CARD ISSUING
The card issuing processes set-up by the Member States shall conform to the
following:
The card number of the first issue of a tachograph card to an applicant shall
have a consecutive index (if applicable) and a replacement index and a renewal
index set to ‘0’.
The card numbers of all non-personal tachograph cards issued to a single control
body or a single workshop or a single transport company shall have the same
first 13 digits, and shall all have a different consecutive index.
A tachograph card issued in replacement of an existing tachograph card shall
have the same card number as the replaced one except the replacement index
which shall be raised by ‘1’ (in the order 0, …, 9, A, …, Z).
A tachograph card issued in replacement of an existing tachograph card shall
have the same card expiry date as the replaced one.
A tachograph card issued in renewal of an existing tachograph card shall have
the same card number as the renewed one except the replacement index which
shall be reset to ‘0’ and the renewal index which shall be raised by ‘1’ (in the
order 0, …, 9, A, …, Z).
The exchange of an existing tachograph card, in order to modify administrative
data, shall follow the rules of the renewal if within the same Member State, or
the rules of a first issue if performed by another Member State.
The ‘card holder surname’ for non-personal workshop or control cards shall be
filled with workshop or control body name.
VIII. TYPE APPROVAL OF RECORDING EQUIPMENT AND TACHO-
GRAPH CARDS
1.General points
For the purpose of this chapter, the words ‘recording equipment’ mean
‘recording equipment or its components’. No type approval is required for the
cable(s) linking the motion sensor to the VU. The paper, for use by the
recording equipment, shall be considered as a component of the recording
equipment.
Recording equipment shall be submitted for approval complete with any inte-
grated additional devices.
Type approval of recording equipment and of tachograph cards shall include
security related tests, functional tests and interoperability tests. Positive results
to each of these tests are stated by an appropriate certificate.
Member States type approval authorities will not grant a type approval certifi-
cate in accordance with Article 5 of this Regulation, as long as they do not hold:
— a security certificate,
— a functional certificate,— and an interoperability certificate,
for the recording equipment or the tachograph card, subject of the request for
type approval.
Any modification in software or hardware of the equipment or in the nature of
materials used for its manufacture shall, before being used, be notified to the
authority which granted type-approval for the equipment. This authority shall
confirm to the manufacturer the extension of the type approval, or may require
an update or a confirmation of the relevant functional, security and/or interoper-
ability certificates.
Procedures to upgrade in situ recording equipment software shall be approved
by the authority which granted type approval for the recording equipment. Soft-
ware upgrade must not alter nor delete any driver activity data stored in the
recording equipment. Software may be upgraded only under the responsibility
of the equipment manufacturer.1998R2135 — EN — 25.08.2002 — 001.001 — 48
▼M1
2.Security certificate
The security certificate is delivered in accordance with the provisions of
Appendix 10 to this Annex.
3.Functional certificate
Each candidate for type approval shall provide the Member State's type approval
authority with all the material and documentation that the authority deems
necessary.
A functional certificate shall be delivered to the manufacturer only after all
functional tests specified in Appendix 9, at least, have been successfully passed.
The type approval authority delivers the functional certificate. This certificate
shall indicate, in addition to the name of its beneficiary and the identification
of the model, a detailed list of the tests performed and the results obtained.
4.Interoperability certificate
Interoperability tests are carried out by a single laboratory under the authority
and responsibility of the European Commission.
The laboratory shall register interoperability test requests introduced by manu-
facturers in the chronological order of their arrival.
Requests will be officially registered only when the laboratory is in possession
of:
— the entire set of material and documents necessary for such interoperability
tests,
— the corresponding security certificate,— the corresponding functional certificate,
The date of the registration of the request shall be notified to the manufacturer.No interoperability tests shall be carried out by the laboratory, for a recording
equipment or a tachograph card that have not been granted a security certificate
and a functional certificate.
Any manufacturer requesting interoperability tests shall commit to leave to the
laboratory in charge of these tests the entire set of material and documents
which he provided to carry out the tests.
The interoperability tests shall be carried out, in accordance with the provisions
of paragraph 5 of Appendix 9 of this Annex, with respectively all the types of
recording equipment or tachograph cards:
— for which type approval is still valid, or
— for which type approval is pending and that have a valid interoperability
certificate.
The interoperability certificate shall be delivered by the laboratory to the manu-
facturer only after all required interoperability tests have been successfully
passed.
If the interoperability tests are not successful with one or more of the recording
equipment or tachograph card(s), as requested by requirement 283, the intero-
perability certificate shall not be delivered, until the requesting manufacturer
has realised the necessary modifications and has succeeded with the interoper-
ability tests. The laboratory shall identify the cause of the problem with the
help of the manufacturers concerned by this interoperability fault and shall
attempt to help the requesting manufacturer in finding a technical solution. In
the case where the manufacturer has modified its product, it is the manufac-
turer's responsibility to ascertain from the relevant authorities that the security
certificate and the functional certificates are still valid.
The interoperability certificate is valid for six months. It is revoked at the end of
this period if the manufacturer has not received a corresponding type approval
certificate. It is forwarded by the manufacturer to the type approval authority of
the Member State who has delivered the functional certificate.
Any element that could be at the origin of an interoperability fault shall not be
used for profit or to lead to a dominant position.
5.Type approval certificate
The type approval authority of the Member State may deliver the type approval
certificate as soon as it holds the three required certificates.
The type approval certificate shall be copied by the type approval authority to
the laboratory in charge of the interoperability tests at the time of deliverance to
the manufacturer.1998R2135 — EN — 25.08.2002 — 001.001 — 49
▼M1
The laboratory competent for interoperability tests shall run a public web site on
which will be updated the list of recording equipment or tachograph cards
models:
— for which a request for interoperability tests have been registered,
— having received an interoperability certificate (even provisional),— having received a type approval certificate.
6.Exceptional procedure: first interoperability certificates
Until four months after a first couple of recording equipment and tachograph
cards (driver, workshop, control and company cards) have been certified to be
interoperable, any interoperability certificate delivered (including this very first
one), regarding requests registered during this period, shall be considered provi-
sional.
If at the end of this period, all products concerned are mutually interoperable, all
corresponding interoperability certificates shall become definitive.
If during this period, interoperability faults are found, the laboratory in charge
of interoperability tests shall identify the causes of the problems with the help
of all manufacturers involved and shall invite them to realise the necessarymodifications.
If at the end of this period, interoperability problems still remain, the laboratory
in charge of interoperability tests, with the collaboration of the manufacturers
concerned and with the type approval authorities who delivered the corre-
sponding functional certificates shall find out the causes of the interoperability
faults and establish which modifications should be made by each of the manu-
facturers concerned. The search for technical solutions shall last for a maximum
of two months, after which, if no common solution is found, the Commission,
after having consulted the laboratory in charge of interoperability tests, shall
decide which equipment(s) and cards get a definitive interoperability certificate
and state the reasons why.
Any request for interoperability tests, registered by the laboratory between the
end of the four-month period after the first provisional interoperability certifi-
cate has been delivered and the date of the decision by the Commission
referred to in requirement 294, shall be postponed until the initial interoper-
ability problems have been solved. Those requests are then processed in the
chronological order of their registration.1998R2135 — EN — 25.08.2002 — 001.001 — 50
▼M1
Appendix 1
DATA DICTIONARY
CONTENTS
1. Introduction … . . . .........................................................
1.1. Approach for definitions of data types … . . . ...................................
1.2. References … .............................................................
2. Data Type Definitions … ...................................................
2.1. ActivityChangeInfo … . . . ...................................................
2.2. Address … . ..............................................................
2.3. BCDString … .............................................................
2.4. CalibrationPurpose … . . . ...................................................
2.5. CardActivityDailyRecord … . . . ..............................................
2.6. CardActivityLengthRange … . . . ..............................................
2.7. CardApprovalNumber … . ...................................................
2.8. CardCertificate … .........................................................
2.9. CardChipIdentification … ...................................................
2.10. CardConsecutiveIndex … ...................................................
2.11. CardControlActivityDataRecord … ............................................
2.12. CardCurrentUse … .........................................................
2.13. CardDriverActivity … . . . ...................................................
2.14. CardDrivingLicenceInformation … ............................................
2.15. CardEventData … .........................................................
2.16. CardEventRecord … .......................................................
2.17. CardFaultData … . .........................................................
2.18. CardFaultRecord … ........................................................
2.19. CardIccIdentification … . . ...................................................
2.20. CardIdentification … .......................................................
2.21. CardNumber … . . .........................................................
2.22. CardPlaceDailyWorkPeriod … . ..............................................
2.23. CardPrivateKey … .........................................................
2.24. CardPublicKey … .........................................................
2.25. CardRenewalIndex … . . . ...................................................
2.26. CardReplacementIndex … ...................................................
2.27. CardSlotNumber … ........................................................
2.28. CardSlotsStatus … .........................................................
2.29. CardStructureVersion … . ...................................................
2.30. CardVehicleRecord … . . . ...................................................
2.31. CardVehiclesUsed … .......................................................
2.32. Certificate … .............................................................
2.33. CertificateContent … .......................................................
2.34. CertificateHolderAuthorisation … .............................................
2.35. CertificateRequestID … . . ...................................................
2.36. CertificationAuthorityKID … . . ..............................................
2.37. CompanyActivityData … . ...................................................1998R2135 — EN — 25.08.2002 — 001.001 — 51
▼M1
2.38. CompanyActivityType … ...................................................
2.39. CompanyCardApplicationIdentification … . . . ...................................
2.40. CompanyCardHolderIdentification … . . ........................................
2.41. ControlCardApplicationIdentification … .......................................
2.42. ControlCardControlActivityData … . . . ........................................
2.43. ControlCardHolderIdentification … . . . ........................................
2.44. ControlType … . . . .........................................................
2.45. CurrentDateTime … ........................................................
2.46. DailyPresenceCounter … . ...................................................
2.47. Datef … . . . ..............................................................
2.48. Distance … . ..............................................................
2.49. DriverCardApplicationIdentification … ........................................
2.50. DriverCardHolderIdentification … ............................................
2.51. EntryTypeDailyWorkPeriod … . ..............................................
2.52. EquipmentType … .........................................................
2.53. EuropeanPublicKey … . . . ...................................................
2.54. EventFaultType … .........................................................
2.55. EventFaultRecordPurpose … . . . ..............................................
2.56. ExtendedSerialNumber … ...................................................
2.57. FullCardNumber … ........................................................
2.58. HighResOdometer … .......................................................
2.59. HighResTripDistance … . ...................................................
2.60. HolderName … . . .........................................................
2.61. K-ConstantOfRecordingEquipment … . ........................................
2.62. KeyIdentifier … . . .........................................................
2.63. L-TyreCircumference … . ...................................................
2.64. Language … ..............................................................
2.65. LastCardDownload … . . . ...................................................
2.66. ManualInputFlag … ........................................................
2.67. ManufacturerCode … .......................................................
2.68. MemberStateCertificate … ..................................................
2.69. MemberStatePublicKey … ...................................................
2.70. Name … . . . ..............................................................
2.71. NationAlpha … . . .........................................................
2.72. NationNumeric … .........................................................
2.73. NoOfCalibrationRecords … ..................................................
2.74. NoOfCalibrationSinceDonwload … . . . ........................................
2.75. NoOfCardPlaceRecords … ..................................................
2.76. NoOfCardVehicleRecords … . . . ..............................................
2.77. NoOfCompanyActivityRecords … ............................................
2.78. NoOfControlActivityRecords … ..............................................
2.79. NoOfEventsPerType … . . ...................................................
2.80. NoOfFaultsPerType … . . . ...................................................
2.81. OdometerValueMidnight … ..................................................
2.82. OdometerShort … .........................................................
2.83. OverspeedNumber … .......................................................1998R2135 — EN — 25.08.2002 — 001.001 — 52
▼M1
2.84. PlaceRecord … . . . .........................................................
2.85. PreviousVehicleInfo … . . ...................................................
2.86. PublicKey … .............................................................
2.87. RegionAlpha … . . .........................................................
2.88. RegionNumeric … .........................................................
2.89. RSAKeyModulus … .......................................................
2.90. RSAKeyPrivateExponent … . . . ..............................................
2.91. RSAKeyPublicExponent … ..................................................
2.92. SensorApprovalNumber … ..................................................
2.93. SensorIdentification … . . . ...................................................
2.94. SensorInstallation … .......................................................
2.95. SensorInstallationSecData … . . . ..............................................
2.96. SensorOSIdentifier … . . . ...................................................
2.97. SensorPaired … . . .........................................................
2.98. SensorPairingDate … .......................................................
2.99. SensorSerialNumber … . . ...................................................
2.100. SensorSCIdentifier … . . . ...................................................
2.101. Signature … ..............................................................
2.102. SimilarEventsNumber … . ...................................................
2.103. SpecificConditionType … ...................................................
2.104. SpecificConditionRecord … . . . ..............................................
2.105. Speed … . . . ..............................................................
2.106. SpeedAuthorised … ........................................................
2.107. SpeedAverage … . .........................................................
2.108. SpeedMax … .............................................................
2.109. TDesSessionKey … ........................................................
2.110. TimeReal … ..............................................................
2.111. TyreSize … . ..............................................................
2.112. VehicleIdentificationNumber … ..............................................
2.113. VehicleRegistrationIdentification … . . . ........................................
2.114. VehicleRegistrationNumber … . ..............................................
2.115. VuActivityDailyData … . . ...................................................
2.116. VuApprovalNumber … . . ...................................................
2.117. VuCalibrationData … .......................................................
2.118. VuCalibrationRecord … . . ...................................................
2.119. VuCardIWData … .........................................................
2.120. VuCardIWRecord … .......................................................
2.121. VuCertificate … . . .........................................................
2.122. VuCompanyLocksData … ...................................................
2.123. VuCompanyLocksRecord … . . . ..............................................
2.124. VuControlActivityData … ...................................................
2.125. VuControlActivityRecord … . . . ..............................................
2.126. VuDataBlockCounter … . ...................................................
2.127. VuDetailedSpeedBlock … ...................................................
2.128. VuDetailedSpeedData … . ...................................................
2.129. VuDownloadablePeriod … ..................................................1998R2135 — EN — 25.08.2002 — 001.001 — 53
▼M1
2.130. VuDownloadActivityData … . . . ..............................................
2.131. VuEventData … . . .........................................................
2.132. VuEventRecord … .........................................................
2.133. VuFaultData … . . .........................................................
2.134. VuFaultRecord … .........................................................
2.135. VuIdentification … .........................................................
2.136. VuManufacturerAddress … ..................................................
2.137. VuManufacturerName … . ...................................................
2.138. VuManufacturingDate … . ...................................................
2.139. VuOverSpeedingControlData … ..............................................
2.140. VuOverSpeedingEventData … . ..............................................
2.141. VuOverSpeedingEventRecord … .............................................
2.142. VuPartNumber … . .........................................................
2.143. VuPlaceDailyWorkPeriodData … .............................................
2.144. VuPlaceDailyWorkPeriodRecord … . . . ........................................
2.145. VuPrivateKey … . .........................................................
2.146. VuPublicKey … . . .........................................................
2.147. VuSerialNumber … ........................................................
2.148. VuSoftInstallationDate … ...................................................
2.149. VuSoftwareIdentification … . . . ..............................................
2.150. VuSoftwareVersion … . . . ...................................................
2.151. VuSpecificConditionData … . . . ..............................................
2.152. VuTimeAdjustmentData … ..................................................
2.153. VuTimeAdjustmentRecord … . . ..............................................
2.154. W-VehicleCharacteristicConstant … . . . ........................................
2.155. WorkshopCardApplicationIdentification … . . ...................................
2.156. WorkshopCardCalibrationData … .............................................
2.157. WorkshopCardCalibrationRecord … . . . ........................................
2.158. WorkshopCardHolderIdentification … . ........................................
2.159. WorkshopCardPIN … . . . ...................................................
3. Value and size range definitions … . . . ........................................
3.1. Definitions for the Driver Card … ............................................
3.2. Definitions für the Workshop Card … . ........................................
3.3. Definitions for the Control Card … . . . ........................................
3.4. Definitions for the Company Card … . ........................................
4. Character sets … . .........................................................
5. Encoding … ..............................................................1998R2135 — EN — 25.08.2002 — 001.001 — 54
▼M1
1. INTRODUCTION
This appendix specifies data formats, data elements, and data structures for use
within the recording equipment and tachograph cards.
1.1. Approach for definitions of data types
This appendix uses Abstract Syntax Notation One (ASN.1) to define data types.
This enables simple and structured data to be defined without implying any
specific transfer syntax (encoding rules) which will be application and environ-
ment dependent.
ASN.1 type naming conventions are done in accordance with ISO/IEC 8824-1.
This implies that:
— where possible, the meaning of the data type is implied through the names
being selected,
— where a data type is a composition of other data types, the data type name is
still a single sequence of alphabetical characters commencing with a capital
letter, however capitals are used within the name to impart the corre-
sponding meaning,
— in general, the data types names are related to the name of the data types
from which they are constructed, the equipment in which data is stored and
the function related to the data.
If an ASN.1 type is already defined as part of another standard and if it is rele-
vant for usage in the recording equipment, then this ASN.1 type will be defined
in this appendix.
To enable several types of encoding rules, some ASN.1 types in this appendix
are constrained by value range identifiers. The value range identifiers are
defined in paragraph 3.
1.2. References
The following references are used in this Appendix:
ISO 639 Code for the representation of names of languages. First
Edition: 1988
EN 726-3 Identification cards systems — Telecommunications inte-
grated circuit(s) cards and terminals — Part 3: Application
independent card requirements. December 1994
ISO 3779 Road vehicles — Vehicle identification number (VIN) —
Content and structure. Edition 3: 1983
ISO/IEC 7816-5 Information technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 5: Numbering system
and registration procedure for application identifiers. First
edition: 1994 + Amendment 1: 1996
ISO/IEC 8824-1 Information technology — Abstract Syntax Notation 1
(ASN.1): Specification of basic notation. Edition 2: 1998
ISO/IEC 8825-2 Information technology — ASN.1 encoding rules: Specifica-
tion of Packed Encoding Rules (PER). Edition 2: 1998
ISO/IEC 8859-1 Information technology — 8 bit single-byte coded graphic
character sets — Part 1: Latin alphabet No 1. First edition:
1998
ISO/IEC 8859-7 Information technology — 8 bit single-byte coded graphic
character sets — Part 7: Latin/Greek alphabet. First edition:
1987
ISO 16844-3 Road vehicles — Tachograph systems — Motion Sensor
Interface. WD 3-20/05/99.
2. DATA TYPE DEFINITIONS
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 ′FF′-Bytes.
2.1. ActivityChangeInfo
This data type enables to code, within a two bytes word, a slot status at 00.00
and/or a driver status at 00.00 and/or changes of activity and/or changes of
driving status and/or changes of card status for a driver or a co-driver. This
data type is related to requirements 084, 109a, 199 and 219.
ActivityChangeInfo ::= OCTET STRING (SIZE(2))1998R2135 — EN — 25.08.2002 — 001.001 — 55
▼M1
Value assignment — Octet Aligned: ′scpaattttttttttt′B (16 bits)
For Data Memory recordings (or slot status):
′s′B Slot:
′0′B: DRIVER,
′1′B: CO-DRIVER,
′c′B Driving status:
′0′B: SINGLE,
′1′B: CREW,
′p′B Driver (or workshop) card status in the relevant slot:
′0′B: INSERTED, a card is inserted,
′1′B: NOT INSERTED, no card is inserted (or a card is with-
drawn),
′aa′B Activity:
′00′B : BREAK/REST,
′01′B : AVAILABILITY,
′10′B : WORK,
′11′B : DRIVING,
′ttttttttttt′B Time of the change: Number of minutes since 00h00 on the given
day.
For Driver (or Workshop) card recordings (and driver status):
′s′B Slot (not relevant when ′p′= 1 except note below):
′0′B: DRIVER,
′1′B: 2. CO-DRIVER,
′c′B Driving status (case ′p′= 0) or Following activity status (case
′p′= 1):
′0′B: SINGLE, ′0′B: UNKNOWN
′1′B: CREW, ′1′B: KNOWN (= manually
entered)
′p′B Card status:
′0′B: INSERTED, the card is inserted in a recording equipment,
′1′B: NOT INSERTED, the card is not inserted (or the card is
withdrawn),
′aa′B Activity (not relevant when ′p′= 1 and′c′= 0 except note below):
′00′B : BREAK/REST,
′01′B : AVAILABILITY,
′10′B : WORK,
′11′B : DRIVING,
′ttttttttttt′B Time of the change: Number of minutes since 00h00 on the given
day.
Note for the case ‘card withdrawal’:
When the card is withdrawn:
—′s′is relevant and indicates the slot from which the card is withdrawn,
—′c′must be set to 0,
—′p′must be set to 1,
—′aa′must code the current activity selected at that time,
As a result of a manual entry, the bits ′c′and′aa′of the word (stored in a card)
may be overwritten later to reflect the entry.
2.2. Address
An address.
address ::= SEQUENCE {
codePage INTEGER (0..255),address OCTET STRING (SIZE(35))
}1998R2135 — EN — 25.08.2002 — 001.001 — 56
▼M1
codePage specifies the part of the ISO/IEC 8859 used to code the address,
address is an address coded in accordance with ISO/IEC 8859-codePage.
2.3. BCDString
BCDString is applied for Binary Code Decimal (BCD) representation. This data
type is used to represent one decimal digit in one semi octet (4 bits). BCDString
is based on the ISO/IEC 8824-1 ′CharacterStringType ′.
BCDString ::= CHARACTER STRING (WITH COMPONENTS {
identification ( WITH COMPONENTS {
fixed PRESENT }) })BCDString uses an ‘hstring’ notation. The leftmost hexadecimal digit shall be
the most significant semi octet of the first octet. To produce a multiple of octets,
zero trailing semi octets shall be inserted, as needed, from the leftmost semi
octet position in the first octet.
Permitted digits are: 0, 1, … 9.
2.4. CalibrationPurpose
Code explaining why a set of calibration parameters was recorded. This data
type is related to requirements 097 and 098.
CalibrationPurpose ::= OCTET STRING (SIZE(1)).Value assignment:
′00′H reserved value,
′01′H activation: recording of calibration parameters known, at the moment of
the VU activation,
′02′H first installation: first calibration of the VU after its activation,
′03′H installation: first calibration of the VU in the current vehicle,
′04′H periodic inspection.
2.5. CardActivityDailyRecord
Information, stored in a card, related to the driver activities for a particular
calendar day. This data type is related to requirements 199 and 219.
CardActivityDailyRecord ::= SEQUENCE {
activityPreviousRecordLength INTEGER(0..CardActivity-
LengthRange),
activityRecordDate TimeReal,activityDailyPresenceCounter DailyPresenceCounter,activityDayDistance Distance,activityChangeInfo SET SIZE(1..1 440) OF ActivityChange-
Info
}
activityPreviousRecordLength is the total length in bytes of the previous daily
record. The maximum value is given by the length of the OCTET STRING
containing these records (see CardActivityLengthRange paragraph 3). When
this record is the oldest daily record, the value of activityPreviousRecordLength
must be set to 0.
activityRecordLength is the total length in bytes of this record. The maximum
value is given by the length of the OCTET STRING containing these records.
activityRecordDate is the date of the record.
activityDailyPresenceCounter is the daily presence counter for the card this
day.
activityDayDistance is the total distance travelled this day.
activityChangeInfo is the set of ActivityChangeInfo data for the driver this day.
It may contain at maximum 1 440 values (one activity change per minute). This
set always includes the activityChangeInfo coding the driver status at 00.00.
2.6. CardActivityLengthRange
Number of bytes in a driver or a workshop card, available to store driver
activity records.
CardActivityLengthRange ::= INTEGER(0..2
16-1)
Value assignment: see paragraph 3.1998R2135 — EN — 25.08.2002 — 001.001 — 57
▼M1
2.7. CardApprovalNumber
Type approval number of the card.
CardApprovalNumber ::= IA5String(SIZE(8))
Value assignment: Unspecified.
2.8. CardCertificate
Certificate of the public key of a card.
CardCertificate ::= Certificate .
2.9. CardChipIdentification
Information, stored in a card, related to the identification of the card's Integrated
Circuit (IC) (requirement 191).
CardChipIdentification ::= SEQUENCE {
icSerialNumber OCTET STRING (SIZE(4)),icManufacturingReferences OCTET STRING (SIZE(4))
}
icSerialNumber is the IC serial number as defined in EN 726-3.
icManufacturingReferences is the IC manufacturer identifier and fabrication
elements as defined in EN 726-3.
2.10. CardConsecutiveIndex
A card consecutive index (definition h)).
CardConsecutiveIndex ::= IA5String(SIZE(1))
Value assignment: (see this Annex Chapter VII)
Order for increase: ′0, …, 9, A, … , Z, a, … , z ′.
2.11. CardControlActivityDataRecord
Information, stored in a driver or workshop card, related to the last control the
driver has been subject to (requirements 210 and 225).
CardControlActivityDataRecord ::= SEQUENCE {
controlType controlType,
controlTime TimeReal,
controlCardNumber FullCardNumber,controlVehicleRegistration VehicleRegistrationIdentification,
controlDownloadPeriodBegin TimeReal,
controlDownloadPeriodEnd TimeReal,
}
controlType is the type of the control.
controlTime is the date and time of the control.
controlCardNumber is the FullCardNumber of the control officer having
performed the control.
controlVehicleRegistration is the VRN and registering Member State of the
vehicle in which the control happened.
controlDownloadPeriodBegin and controlDownloadPeriodEnd is the period
downloaded, in case of downloading.
2.12. CardCurrentUse
Information about the actual usage of the card (requirement 212).
CardCurrentUse ::= SEQUENCE {
sessionOpenTime TimeReal,sessionOpenVehicle VehicleRegistrationIdentification
}
sessionOpenTime is the time when the card is inserted for the current usage.
This element is set to zero at card removal.
sessionOpenVehicle is the identification of the currently used vehicle, set at
card insertion. This element is set to zero at card removal.1998R2135 — EN — 25.08.2002 — 001.001 — 58
▼M1
2.13. CardDriverActivity
Information, stored in a driver or a workshop card, related to the activities of the
driver (requirements 199 and 219).
CardDriverActivity ::= SEQUENCE {
activityPointerOldestDayRecord INTEGER(0..CardActivity-
LengthRange-1),
activityPointerNewestRecord INTEGER(0..CardActivityLeng-
thRange-1),
activityDailyRecords OCTET STRING (SIZE(CardActivity-
LengthRange))
}
activityPointerOldestDayRecord is the specification of the begin of the storage
place (number of bytes from the beginning of the string) of the oldest complete
day record in the activityDailyRecords string. The maximum value is given by
the length of the string.
activityPointerNewestRecord is the specification of the begin of the storage
place (number of bytes from the beginning of the string) of the most recent
day record in the activityDailyRecords string. The maximum value is given by
the length of the string.
activityDailyRecords is the space available to store the driver activity data
(data structure: CardActivityDailyRecord) for each calendar day where the card
has been used.
Value assignment: this octet string is cyclically filled with records of CardAc-
tivityDailyRecord. At the first use storing is started at the first byte of the string.
All new records are appended at the end of the previous one. When the string is
full, storing continues at the first byte of the string independently of a break
being inside a data element. Before placing new activity data in the string
(enlarging current activityDailyRecord, or placing a new activityDailyRecord)
that replaces older activity data, activityPointerOldestDayRecord must be
updated to reflect the new location of the oldest complete day record, and acti-
vityPreviousRecordLength of this (new) oldest complete day record must be
reset to 0.
2.14. CardDrivingLicenceInformation
Information, stored in a driver card, related to the card holder driver licence data
(requirement 196).
CardDrivingLicenceInformation ::= SEQUENCE {
drivingLicenceIssuingAuthority Name,drivingLicenceIssuingNation NationNumeric,
drivingLicenceNumber IA5String(SIZE(16))
}
drivingLicenceIssuingAuthority is the authority responsible for issuing the
driving licence.
drivingLicenceIssuingNation is the nationality of the authority that issued the
driving licence.
drivingLicenceNumber is the number of the driving licence.
2.15. CardEventData
Information, stored in a driver or workshop card, related to the events associated
with the card holder (requirements 204 and 223).
CardEventData ::= SEQUENCE SIZE(6) OF {
cardEventRecords SET SIZE(NoOfEventsPerType) OF CardE-
ventRecord
}
CardEventData is a sequence, ordered by ascending value of EventFaultType,
of cardEventRecords (except security breach attempts related records which are
gathered in the last set of the sequence).
cardEventRecords is a set of event records of a given event type (or category
for security breach attempts events).
2.16. CardEventRecord
Information, stored in a driver or a workshop card, related to an event associated
to the card holder (requirements 205 and 223).1998R2135 — EN — 25.08.2002 — 001.001 — 59
▼M1
CardEventRecord ::= SEQUENCE {
eventType EventFaultType,
eventBeginTime TimeReal,
eventEndTime TimeReal,
eventVehicleRegistration VehicleRegistrationIdentification
}
eventType is the type of the event.
eventBeginTime is the date and time of beginning of event.
eventEndTime is the date and time of end of event.
eventVehicleRegistration is the VRN and registering Member State of vehicle
in which the event happened.
2.17. CardFaultData
Information, stored in a driver or a workshop card, related to the faults asso-
ciated to the card holder (requirements 207 and 223).
CardFaultData ::= SEQUENCE SIZE(2) OF {
cardFaultRecords SET SIZE(NoOfFaultsPerType) OF Card-
FaultRecord
}
CardFaultData is a sequence of Recording Equipment faults set of records
followed by card faults set of records.
cardFaultRecords is a set of fault records of a given fault category (Recording
Equipment or card).
2.18. CardFaultRecord
Information, stored in a driver or a workshop card, related to a fault associated
to the card holder (requirement 208 and 223).
CardFaultRecord ::= SEQUENCE {
faultType EventFaultType,faultBeginTime TimeReal,
faultEndTime TimeReal,
faultVehicleRegistration VehicleRegistrationIdentification
}
faultType is the type of the fault.
faultBeginTime is the date and time of beginning of fault.
faultEndTime is the date and time of end of fault.
faultVehicleRegistration is the VRN and registering Member State of vehicle
in which the fault happened.
2.19. CardIccIdentification
Information, stored in a card, related to the identification of the integrated
circuit (IC) card (requirement 192).
CardIccIdentification ::= SEQUENCE {
clockStop OCTET STRING (SIZE(1)),
cardExtendedSerialNumber ExtendedSerialNumber,cardApprovalNumber CardApprovalNumber
cardPersonaliserID OCTET STRING (SIZE(1)),
embedderIcAssemblerId OCTET STRING (SIZE(5)),
icIdentifier OCTET STRING (SIZE(2))
}
clockStop is the Clockstop mode as defined in EN 726-3.
cardExtendedSerialNumber is the IC card serial number and IC card manufac-
turing reference as defined in EN 726-3 and as further specified by the
ExtendedSerialNumber data type.
cardApprovalNumber is the type approval number of the card.
cardPersonaliserID is the card personaliser ID as defined in EN 726-3.1998R2135 — EN — 25.08.2002 — 001.001 — 60
▼M1
embedderIcAssemblerId is the embedder/IC assembler identifier as defined in
EN 726-3.
icIdentifier is the Identifier of the IC on the card and its IC manufacturer as
defined in EN 726-3.
2.20. CardIdentification
Information, stored in a card, related to the identification of the card (require-
ments 194, 215, 231, 235).
CardIdentification ::= SEQUENCE
cardIssuingMemberState NationNumeric,
cardNumber CardNumber,cardIssuingAuthorityName Name,
cardIssueDate TimeReal,
cardValidityBegin TimeReal,
cardExpiryDate TimeReal
}
cardIssuingMemberState is the code of the Member State issuing the card.
cardNumber is the card number of the card.
cardIssuingAuthorityName is the name of the authority having issued the
Card.
cardIssueDate is the issue date of the Card to the current holder.
cardValidityBegin is the first date of validity of the card.
cardExpiryDate is the date when the validity of the card ends.
2.21. CardNumber
A card number as defined by definition g).
CardNumber ::= CHOICE {
SEQUENCE {
driverIdentification IA5String(SIZE(14)),
cardReplacementIndex CardReplacementIndex,
cardRenewalIndex CardRenewalIndex
}
SEQUENCE {
ownerIdentification IA5String(SIZE(13)),
cardConsecutiveIndex Ca rdConsecutiveIndex,
cardReplacementIndex CardReplacementIndex,
cardRenewalIndex CardRenewalIndex
}
}
driverIdentification is the unique identification of a driver in a Member State.
ownerIdentification is the unique identification of a company or a workshop or
a control body within a Member State.
cardConsecutiveIndex is the card consecutive index.
cardReplacementIndex is the card replacement index.
cardRenewalIndex is the card renewal index.
The first sequence of the choice is suitable to code a driver card number, the
second sequence of the choice is suitable to code workshop, control, and
company card numbers.
2.22. CardPlaceDailyWorkPeriod
Information, stored in a driver or a workshop card, related to the places where
daily work periods begin and/or end (requirements 202 and 221).
CardPlaceDailyWorkPeriod ::= SEQUENCE {
placePointerNewestRecord INTEGER(0..NoOfCardPlaceRe-
cords-1),
placeRecords SET SIZE(NoOfCardPlaceRecords) OF PlaceRe-
cord1998R2135 — EN — 25.08.2002 — 001.001 — 61
▼M1
}
placePointerNewestRecord is the index of the last updated place record.
Value assignment: Number corresponding to the numerator of the place record,
beginning with ‘0’ for the first occurrence of the place records in the structure.
placeRecords is the set of records containing the information related to the
places entered.
2.23. CardPrivateKey
The private key of a card.
CardPrivateKey ::= RSAKeyPrivateExponent.
2.24. CardPublicKey
The public key of a card.
CardPublicKey ::= PublicKey.
2.25. CardRenewalIndex
A card renewal index (definition i)).
CardRenewalIndex ::= IA5String(SIZE(1)).
Value assignment: (see this Annex Chapter VII).
′0′ First issue.
Order for increase: ′0, …, 9, A, …, Z′.
2.26. CardReplacementIndex
A card replacement index (definition j)).
CardReplacementIndex ::= IA5String(SIZE(1))
Value assignment: (see this Annex Chapter VII).
′0′ Original card.
Order for increase: ′0, …, 9, A, …, Z′.
2.27. CardSlotNumber
Code to distinguish between the two slots of a vehicle unit.
CardSlotNumber ::= INTEGER {
driverSlot (0),co-driverSlot (1)
}
Value assignment: not further specified.
2.28. CardSlotsStatus
Code indicating the type of cards inserted in the two slots of the vehicle unit.
CardSlotsStatus ::= OCTET STRING (SIZE(1))
Value assignment — Octet Aligned: ′ccccdddd ′B:
′cccc′B Identification of the type of card inserted in the co-driver slot,
′dddd′B Identification of the type of card inserted in the driver slot,
with the following identification codes:
′0000′B no card is inserted,
′0001′B a driver card is inserted,
′0010′B a workshop card is inserted,
′0011′B a control card is inserted,
′0100′B a company card is inserted.
2.29. CardStructureVersion
Code indicating the version of the implemented structure in a tachograph card.
CardStructureVersion ::= OCTET STRING (SIZE(2))Value assignment: ′aabb′H:
′aa′H Index for changes of the structure,1998R2135 — EN — 25.08.2002 — 001.001 — 62
▼M1
′bb′H Index for changes concerning the use of the data elements defined for
the structure given by the high byte.
2.30. CardVehicleRecord
Information, stored in a driver or workshop card, related to a period of use of a
vehicle during a calendar day (requirements 197 and 217).
CardVehicleRecord ::= SEQUENCE {
vehicleOdometerBegin OdometerShort,vehicleOdometerEnd OdometerShort,vehicleFirstUse TimeReal,vehicleLastUse TimeReal,
vehicleRegistration VehicleRegistrationIdentification,
vuDataBlockCounter VuDataBlockCounter
}
vehicleOdometerBegin is the vehicle odometer value at the beginning of the
period of use of the vehicle.
vehicleOdometerEnd is the vehicle odometer value at the end of the period of
use of the vehicle.
vehicleFirstUse is the date and time of the beginning of the period of use of the
vehicle.
vehicleLastUse is the date and time of the end of the period of use of the
vehicle.
vehicleRegistration is the VRN and the registering Member State of the
vehicle.
vuDataBlockCounter is the value of the VuDataBlockCounter at last extraction
of the period of use of the vehicle.
2.31. CardVehiclesUsed
Information, stored in a driver or workshop card, related to the vehicles used by
the card holder (requirements 197 and 217).
CardVehiclesUsed := SEQUENCE {
vehiclePointerNewestRecord INTEGER(0..NoOfCardVehi-
cleRecords-1),
cardVehicleRecords SET SIZE(NoOfCardVehicleRecords) OF
CardVehicleRecord
}
vehiclePointerNewestRecord is the index of the last updated vehicle record.
Value assignment: Number corresponding to the numerator of the vehicle
record, beginning with ′0′for the first occurrence of the vehicle records in the
structure.
cardVehicleRecords is the set of records containing information on vehicles
used.
2.32. Certificate
The certificate of a public key issued by a Certification Authority.
Certificate ::= OCTET STRING (SIZE(194))Value assignment: digital signature with partial recovery of a CertificateCon-
tent according to Appendix 11 ‘common security mechanisms’: Signature (128
bytes) || Public Key remainder (58 Byte) || Certification Authority Reference (8
bytes).
2.33. CertificateContent
The (clear) content of the certificate of a public key according to Appendix 11
common security mechanisms.
CertificateContent ::= SEQUENCE {
certificateProfileIdentifier INTEGER(0..255),
certificationAuthorityReference KeyIdentifier,
certificateHolderAuthorisation CertificateHolderAuthorisa-
tion,
certificateEndOfValidity TimeReal,1998R2135 — EN — 25.08.2002 — 001.001 — 63
▼M1
certificateHolderReference KeyIdentifier,
publicKey PublicKey
}
certificateProfileIdentifier is the version of the corresponding certificate.
Value assignment: :′01h′for this version.
CertificationAuthorityReference identifies the Certification Authority issuing
the certificate. It also references the Public Key of this Certification Authority.
certificateHolderAuthorisation identifies the rights of the certificate holder.
certificateEndOfValidity is the date when the certificate expires administra-
tively.
certificateHolderReference identifies the certificate holder. It also references
his Public Key.
publicKey is the public key that is certified by this certificate.
2.34. CertificateHolderAuthorisation
Identification of the rights of a certificate holder.
CertificateHolderAuthorisation ::= SEQUENCE {
tachographApplicationID OCTET STRING(SIZE(6))equipmentType EquipmentType
}
tachographApplicationID is the application identifier for the tachograph appli-
cation.
Value assignment :′FFh′′54h′′41h′′43h′′48h′′4Fh′. This AID is a proprietary
non-registered application identifier in accordance with ISO/IEC 7816-5.
equipmentType is the identification of the type of equipment to which the
certificate is intended.
Value assignment : in accordance with EquipmentType data type. 0 if certificate
is the one of a Member State.
2.35. CertificateRequestID
Unique identification of a certificate request. It can also be used as a Vehicle
Unit Public Key Identifier if the serial number of the vehicle Unit to which the
key is intended is not known at certificate generation time.
CertificateRequestID ::= SEQUENCE {
requestSerialNumber INTEGER(0..2
32-1)
requestMonthYear BCDString(SIZE(2))
crIdentifier OCTET STRING(SIZE(1))
manufacturerCode ManufacturerCode
}
requestSerialNumber is a serial number for the certificate request, unique for
the manufacturer and the month below.
requestMonthYear is the identification of the month and the year of the certi-
ficate request.
Value assignment: BCD coding of month (two digits) and year (two last digits).
crIdentifier: is an identifier to distinguish a certificate request from an extended
serial number.
Value assignment: ′FFh′.
manufacturerCode: is the numerical code of the manufacturer requesting the
certificate.
2.36. CertificationAuthorityKID
Identifier of the Public Key of a Certification Authority (a Member State or the
European Certification Authority).
CertificationAuthorityKID ::= SEQUENCE {
nationNumeric NationNumericnationAlpha NationAlphakeySerialNumber INTEGER(0..255)additionalInfo OCTET STRING(SIZE(2))1998R2135 — EN — 25.08.2002 — 001.001 — 64
▼M1
caIdentifier OCTET STRING(SIZE(1))
}
nationNumeric is the numerical nation code of the Certification Authority.
nationAlpha is the alphanumerical nation code of the Certification Authority.
keySerialNumber is a serial number to distinguish the different keys of the
Certification Authority in the case keys are changed.
additionalInfo is a two byte field for additional coding (Certification Authority
specific).
caIdentifier is an identifier to distinguish a Certification Authority Key Identi-
fier from other Key Identifiers.
Value assignment: ′01h′.
2.37. CompanyActivityData
Information, stored in a company card, related to activities performed with the
card (requirement 237).
CompanyActivityData ::= SEQUENCE {
companyPointerNewestRecord INTEGER(0..NoOfCompanyAc-
tivityRecords-1),
companyActivityRecords SET SIZE(NoOfCompanyActivityRe-
cords) OF
companyActivityRecord SEQUENCE {
companyActivityType CompanyActivityType,companyActivityTime TimeReal,cardNumberInformation FullCardNumber,vehicleRegistrationInformation VehicleRegistrationI-
dentification,
downloadPeriodBegin TimeReal,downloadPeriodEnd TimeReal
}
}
companyPointerNewestRecord is the index of the last updated companyActivi-
tyRecord.
Value assignment: Number corresponding to the numerator of the company
activity record, beginning with ′0′for the first occurrence of the company
activity record in the structure.
companyActivityRecords is the set of all company activity records.
companyActivityRecord is the sequence of information related to one company
activity.
companyActivityType is the type of the company activity.
companyActivityTime is the date and time of the company activity.
cardNumberInformation is the card number and the card issuing Member
State of the card downloaded, if any.
vehicleRegistrationInformation is the VRN and registering Member State of
the vehicle downloaded or locked in or out.
downloadPeriodBegin and downloadPeriodEnd is the period downloaded
from the VU, if any.
2.38. CompanyActivityType
Code indicating an activity carried out by a company using its company card.
CompanyActivityType ::= INTEGER {
card downloading (1),VU downloading (2),VU lock-in (3),
VU lock-out (4).
}1998R2135 — EN — 25.08.2002 — 001.001 — 65
▼M1
2.39. CompanyCardApplicationIdentification
Information, stored in a company card related to the identification of the appli-
cation of the card (requirement 190).
CompanyCardApplicationIdentification ::= SEQUENCE {
typeOfTachographCardId EquipmentType,
cardStructureVersion CardStructureVersion,
noOfCompanyActivityRecords NoOfCompanyActivityRecords
}
typeOfTachographCardId is specifying the implemented type of card.
cardStructureVersion is specifying the version of the structure that is imple-
mented in the card.
noOfCompanyActivityRecords is the number of company activity records the
card can store.
2.40. CompanyCardHolderIdentification
Information, stored in a company card, related to the cardholder identification
(requirement 236).
CompanyCardHolderIdentification ::= SEQUENCE {
companyName Name,
companyAddress Address,
cardHolderPreferredLanguage Language
}
companyName is the name of the holder company.
companyAddress is the address of the holder company.
cardHolderPreferredLanguage is the preferred language of the card holder.
2.41. ControlCardApplicationIdentification
Information, stored in a control card related to the identification of the applica-
tion of the card (requirement 190).
ControlCardApplicationIdentification ::= SEQUENCE {
typeOfTachographCardId EquipmentType,
cardStructureVersion CardStructureVersion,
noOfControlActivityRecords NoOfControlActivityRecords
}
typeOfTachographCardId is specifying the implemented type of card.
cardStructureVersion is specifying the version of the structure that is imple-
mented in the card.
noOfControlActivityRecords is the number of control activity records the card
can store.
2.42. ControlCardControlActivityData
Information, stored in a control card, related to control activity performed with
the card (requirement 233).
ControlCardControlActivityData ::= SEQUENCE {
controlPointerNewestRecord INTEGER(0..NoOfControlActivi-
tyRecords-1),
controlActivityRecords SET SIZE(NoOfControlActivityRe-
cords) OF
controlActivityRecord SEQUENCE {
controlType ControlType,controlTime TimeReal,
controlledCardNumber FullCardNumber,
controlledVehicleRegistratio n VehicleRegistrationIdentifi-
cation,
controlDownloadPeriodBegin TimeReal,
controlDownloadPeriodEnd TimeReal
}1998R2135 — EN — 25.08.2002 — 001.001 — 66
▼M1
}
controlPointerNewestRecord is the index of the last updated control activity
record.
Value assignment: Number corresponding to the numerator of the control
activity record, beginning with ′0′for the first occurrence of the control activity
record in the structure.
controlActivityRecords is the set of all control activity records.
controlActivityRecord is the sequence of information related to one control.
controlType is the type of the control.
controlTime is the date and time of the control.
controlledCardNumber is the card number and the card issuing Member State
of the card controlled.
controlledVehicleRegistration is the VRN and registering Member State of the
vehicle in which the control happened.
controlDownloadPeriodBegin and controlDownloadPeriodEnd is the period
eventually downloaded.
2.43. ControlCardHolderIdentification
Information, stored in a control card, related to the identification of the card-
holder (requirement 232).
ControlCardHolderIdentification ::= SEQUENCE {
controlBodyName Name,
controlBodyAddress Address,cardHolderName HolderName,
cardHolderPreferredLanguage Language
}
controlBodyName is the name of the control body of the card holder.
controlBodyAddress is the address of the control body of the card holder.
cardHolderName is the name and first name(s) of the holder of the Control
Card.
cardHolderPreferredLanguage is the preferred language of the card holder.
2.44. ControlType
Code indicating the activities carried out during a control. This data type is
related to requirements 102, 210 and 225.
ControlType ::= OCTET STRING (SIZE(1))
Value assignment — Octet aligned: ′cvpdxxxx′B (8 bits)
′c′B card downloading:
′0′B: card not downloaded during this control activity,
′1′B: card downloaded during this control activity
′v′B VU downloading:
′0′B: VU not downloaded during this control activity,
′1′B: VU downloaded during this control activity
′p′B printing:
′0′B: no printing done during this control activity,
′1′B: printing done during this control activity
′d′B display:
′0′B: no display used during this control activity,
′1′B: display used during this control activity
′xxxx′B Not used.
2.45. CurrentDateTime
The current date and time of the recording equipment.
CurrentDateTime ::= TimeReal
Value assignment : not further specified.1998R2135 — EN — 25.08.2002 — 001.001 — 67
▼M1
2.46. DailyPresenceCounter
Counter, stored in a driver or workshop card, increased by one for each calendar
day the card has been inserted in a VU. This data type is related to requirements
199 and 219.
DailyPresenceCounter ::= BCDString(SIZE(2))
Value assignment : Consecutive number with maximum value = 9 999, starting
again with 0. At the time of first issuing of the card the number is set to 0.
2.47. Datef
Date expressed in a readily printable numeric format.
Datef ::= SEQUENCE {
year BCDString(SIZE(2)),month BCDString(SIZE(1)),day BCDString(SIZE(1))
}
Value assignment:
yyyy Year
mm Monthdd Day′00000000′H denotes explicitly no date.
2.48. Distance
A distance travelled (result of the calculation of the difference between two
vehicle's odometer value in kilometres).
Distance ::= INTEGER(0..2
16-1)
Value assignment: Unsigned binary. Value in km in the operational range 0 to
9 999 km.
2.49. DriverCardApplicationIdentification
Information, stored in a driver card related to the identification of the applica-
tion of the card (requirement 190).
DriverCardApplicationIdentification ::= SEQUENCE {
typeOfTachographCardId EquipmentType,
cardStructureVersion CardStructureVersion,noOfEventsPerType NoOfEventsPerType,noOfFaultsPerType NoOfFaultsPerType,activityStructureLength CardActivityLengthRange,
noOfCardVehicleRecords NoOfCardVehicleRecords,
noOfCardPlaceRecords NoOfCardPlaceRecords
}
typeOfTachographCardId is specifying the implemented type of card.
cardStructureVersion is specifying the version of the structure that is imple-
mented in the card.
noOfEventsPerType is the number of events per type of event the card can
record.
noOfFaultsPerType is the number of faults per type of fault the card can
record.
activityStructureLength indicates the number of bytes available for storing
activity records.
noOfCardVehicleRecords is the number of vehicle records the card can
contain.
noOfCardPlaceRecords is the number of places the card can record.
2.50. DriverCardHolderIdentification
Information, stored in a driver card, related to the identification of the card-
holder (requirement 195).
DriverCardHolderIdentification ::= SEQUENCE {
cardHolderName HolderName,1998R2135 — EN — 25.08.2002 — 001.001 — 68
▼M1
cardHolderBirthDate Datef,
cardHolderPreferredLanguage Language
}
cardHolderName is the name and first name(s) of the holder of the Driver
Card.
cardHolderBirthDate is the date of birth of the holder of the Driver Card.
cardHolderPreferredLanguage is the preferred language of the card holder.
2.51. EntryTypeDailyWorkPeriod
Code to distinguish between begin and end for an entry of a daily work period
place and condition of the entry.
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),
Begin, related time assumed by VU (4),End, related time assumed by VU (5)
}
Value assignment : according to ISO/IEC8824-1.
2.52. EquipmentType
Code to distinguish different types of equipment for the tachograph application.
EquipmentType ::= INTEGER(0..255)
- - Reserved (0),
--D r i v e rC a r d( 1 ) ,- - Workshop Card (2),
- - Control Card (3),
- - Company Card (4),
- - Manufacturing Card (5),
- - Vehicle Unit (6),
--M o t i o nS e n s o r( 7 ) ,
- - RFU (8..255)
Value assignment : According to ISO/IEC 8824-1.
Value 0 is reserved for the purpose of designating a Member State or Europe in
the CHA field of certificates.
2.53. EuropeanPublicKey
The European public key.
EuropeanPublicKey ::= PublicKey .
2.54. EventFaultType
Code qualifying an event or a fault.
EventFaultType ::= OCTET STRING (SIZE(1)) .
Value assignment:
′0x′H General events,
′00′H No further details,
′01′H Insertion of a non-valid card,
′02′H Card conflict,
′03′H Time overlap,
′04′H Driving without an appropriate card,
′05′H Card insertion while driving,
′06′H Last card session not correctly closed,
′07′H Over speeding,
′08′H Power supply interruption,1998R2135 — EN — 25.08.2002 — 001.001 — 69
▼M1
′09′H Motion data error,
′0A′Ht o′0F′H RFU,
′1x′H Vehicle unit related security breach attempt events,
′10′H No further details,
′11′H Motion sensor authentication failure,
′12′H Tachograph card authentication failure,
′13′H Unauthorised change of motion sensor,
′14′H Card data input integrity error
′15′H Stored user data integrity error,
′16′H Internal data transfer error,
′17′H Unauthorised case opening,
′18′H Hardware sabotage,
′19′Ht o′1F′H RFU,
′2x′H Sensor related security breach attempt events,
′20′H No further details,
′21′H Authentication failure,
′22′H Stored data integrity error,
′23′H Internal data transfer error,
′24′H Unauthorised case opening,
′25′H Hardware sabotage,
′26′Ht o′2F′H RFU,
′3x′H Recording equipment faults,
′30′H No further details,
′31′H VU internal fault,
′32′H Printer fault,
′33′H Display fault,
′34′H Downloading fault,
′35′H Sensor fault,
′36′Ht o′3F′H RFU
′4x′H Card faults,
′40′H No further details,
′41′Ht o′4F′H RFU
′50′Ht o′7F′H RFU,
′80′Ht o′FF′H Manufacturer specific.
2.55. EventFaultRecordPurpose
Code explaining why an event or a fault has been recorded.
EventFaultRecordPurpose ::= OCTET STRING (SIZE(1)) .
Value assignment:
′00′H one of the 10 most recent (or last) events or faults
′01′H the longest event for one of the last 10 days of occurrence
′02′H one of the 5 longest events over the last 365 days
′03′H the last event for one of the last 10 days of occurrence
′04′H the most serious event for one of the last 10 days of occurrence
′05′H one of the 5 most serious events over the last 365 days
′06′H the first event or fault having occurred after the last calibration
′07′H an active/on-going event or fault
′08′Ht o′7F′H RFU
′80′Ht o′FF′H manufacturer specific.
2.56. ExtendedSerialNumber
Unique identification of an equipment. It can also be used as an equipment
Public Key Identifier.
ExtendedSerialNumber ::= SEQUENCE {1998R2135 — EN — 25.08.2002 — 001.001 — 70
▼M1
serialNumber INTEGER(0..232-1)
monthYear BCDString(SIZE(2))
type OCTET STRING(SIZE(1))manufacturerCode ManufacturerCode
}
serialNumber is a serial number for the equipment, unique for the manufac-
turer, the equipment's type and the month below.
monthYear is the identification of the month and the year of manufacturing (or
of serial number assignment).
Value assignment: BCD coding of Month (two digits) and Year (two last
digits).
type is an identifier of the type of equipment.
Value assignment: manufacturer specific, with FFh' reserved value.
manufacturerCode: is the numerical code of the manufacturer of the equip-
ment.
2.57. FullCardNumber
Code fully identifying a tachograph card.
FullCardNumber ::= SEQUENCE {
cardType EquipmentType,cardIssuingMemberState NationNumeric,
cardNumber CardNumber
}
cardType is the type of the tachograph card.
cardIssuingMemberState is the code of the Member State having issued the
card.
cardNumber is the card number.
2.58. HighResOdometer
Odometer value of the vehicle: Accumulated distance travelled by the vehicle
during its operation.
HighResOdometer ::= INTEGER(0..2
32-1)
Value assignment : Unsigned binary. Value in 1/200 km in the operating range
0 to 21 055 406 km.
2.59. HighResTripDistance
A distance travelled during all or part of a journey.
HighResTripDistance ::= INTEGER(0..232-1)
Value assignment : Unsigned binary. Value in 1/200 km in the operating range
0 to 21 055 406 km.
2.60. HolderName
The surname and first name(s) of a card holder.
HolderName ::= SEQUENCE {
holderSurname Name,holderFirstNames Name
}
holderSurname is the surname (family name) of the holder. This surname does
not include titles.
Value assignment: When a card is not personal, holderSurname contains the
same information as companyName or workshopName or controlBodyName.
holderFirstNames is the first name(s) and initials of the holder.
2.61. K-ConstantOfRecordingEquipment
Constant of the recording equipment (definition m)).
K-ConstantOfRecordingEquipment ::= INTEGER(0..2
16-1)
Value assignment : Pulses per kilometre in the operating range 0 to
64 255 pulses/km.1998R2135 — EN — 25.08.2002 — 001.001 — 71
▼M1
2.62. KeyIdentifier
A unique identifier of a Public Key used to reference and select the key. It also
identifies the holder of the key.
KeyIdentifier ::= CHOICE {
extendedSerialNumber ExtendedSerialNumber,
certificateRequestID CertificateRequestID,
certificationAuthorityKID CertificationAuthorityKID
}
The first choice is suitable to reference the public key of a Vehicle Unit or of a
tachograph card.
The second choice is suitable to reference the public key of a Vehicle Unit (in
the case the serial number of the Vehicle Unit cannot be known at certificate
generation time).
The third choice is suitable to reference the public key of a Member State.
2.63. L-TyreCircumference
Effective circumference of the wheel tyres (definition u)).
L-TyreCircumference ::= INTEGER(0..216-1)
Value assignment : Unsigned binary, value in 1/8 mm in the operating range 0
to 8 031 mm.
2.64. Language
Code identifying a language.
Language ::= IA5String(SIZE(2))
Value assignment : Two-letter lower-case coding according to ISO 639.
2.65. LastCardDownload
Date and time, stored on a driver card, of last card download (for other purposes
than control). This date is updateable by a VU or any card reader.
LastCardDownload ::= TimeReal
Value assignment : not further specified.
2.66. ManualInputFlag
Code identifying whether a cardholder has manually entered driver activities at
card insertion or not (requirement 081).
ManualInputFlag ::= INTEGER {
noEntry (0)
manualEntries (1)
}
Value assignment : not further specified.
2.67. ManufacturerCode
Code identifying a manufacturer.
ManufacturerCode ::= INTEGER(0..255)
Value assignment:
′00′H No information available
′01′H Reserved value
′02′H. .′0F′H Reserved for Future Use
′10′H ACTIA
′11′H. .′17′H Reserved for manufacturers which name begins with ′A′
′18′H. .′1F′H Reserved for manufacturers which name begins with ′B′
′20′H. .′27′H Reserved for manufacturers which name begins with ′C′
′28′H. .′2F′H Reserved for manufacturers which name begins with ′D′
′30′H. .′37′H Reserved for manufacturers which name begins with ′E′
′38′H. .′3F′H Reserved for manufacturers which name begins with ′F′
′40′H Giesecke & Devrient GmbH1998R2135 — EN — 25.08.2002 — 001.001 — 72
▼M1
′41′H GEM plus
′42′H. .′47′H Reserved for manufacturers which name begins with ′G′
′48′H. .′4F′H Reserved for manufacturers which name begins with ′H′
′50′H. .′57′H Reserved for manufacturers which name begins with ′I′
′58′H. .′5F′H Reserved for manufacturers which name begins with ′J′
′60′H. .′67′H Reserved for manufacturers which name begins with ′K′
′68′H. .′6F′H Reserved for manufacturers which name begins with ′L′
′70′H. .′77′H Reserved for manufacturers which name begins with ′M′
′78′H. .′7F′H Reserved for manufacturers which name begins with ′N′
′80′H OSCARD
′81′H. .′87′H Reserved for manufacturers which name begins with ′O′
′88′H. .′8F′H Reserved for manufacturers which name begins with ′P′
′90′H. .′97′H Reserved for manufacturers which name begins with ′Q′
′98′H. .′9F′H Reserved for manufacturers which name begins with ′R′
′A0′H SETEC
′A1′H SIEMENS VDO
′A2′H STONERIDGE
′A3′H. .′A7′H Reserved for manufacturers which name begins with ′S′
′AA′H TACHOCONTROL
′AB′H. .′AF′H Reserved for manufacturers which name begins with ′T′
′B0′H. .′B7′H Reserved for manufacturers which name begins with ′U′
′B8′H. .′BF′H Reserved for manufacturers which name begins with ′V′
′C0′H. .′C7′H Reserved for manufacturers which name begins with W ′
′C8′H. .′CF′H Reserved for manufacturers which name begins with ′X′
′D0′H. .′D7′H Reserved for manufacturers which name begins with ′Y′
′D8′H. .′DF′H Reserved for manufacturers which name begins with ′Z′
2.68. MemberStateCertificate
The certificate of the public key of a Member State issued by the European
certification authority.
MemberStateCertificate ::= Certificate
2.69. MemberStatePublicKey
The public key of a Member State.
MemberStatePublicKey ::= PublicKey .
2.70. Name
A name.
Name ::= SEQUENCE {
codePage INTEGER (0..255),name OCTET STRING (SIZE(35))
}
codePage specifies the part of the ISO/IEC 8859 used to code the name,
name is a name coded in accordance with ISO/IEC 8859-codePage.
2.71. NationAlpha
Alphabetic reference to a country, in accordance with the conventional coding
of countries on car bumper stickers, and/or as used on internationally harmo-
nised vehicle insurance papers (green card).
NationAlpha ::= IA5String(SIZE(3))Value assignment:
′′ No information available
′A′ Austria
′AL′ Albania
′AND′Andorra1998R2135 — EN — 25.08.2002 — 001.001 — 73
▼M1
′ARM′Armenia
′AZ′ Azerbaijan
′B′ Belgium
′BG′ Bulgaria
′BIH′ Bosnia and Herzegovina
′BY′ Belarus
′CH′ Switzerland
′CY′ Cyprus
′CZ′ Czech Republic
′D′ Germany
′DK′ Denmark
′E′ Spain
′EST′ Estonia
′F′ France
′FIN′ Finland
′FL′ Liechtenstein
′FR′ Faeroe Islands
′UK′ United Kingdom, Alderney, Guernsey, Jersey, Isle of Man, Gibraltar
′GE′ Georgia
′GR′ Greece
′H′ Hungary
′HR′ Croatia
′I′ Italy
′IRL′ Ireland
′IS′ Iceland
′KZ′ Kazakhstan
′L′ Luxembourg
′LT′ Lithuania
′LV′ Latvia
′M′ Malta
′MC′ Monaco
′MD′ Republic of Moldova
′MK′ Macedonia
′N′ Norway
′NL′ The Netherlands
′P′ Portugal
′PL′ Poland
′RO′ Romania
′RSM′San Marino
′RUS′ Russian Federation
′S′ Sweden
′SK′ Slovakia
′SLO′ Slovenia
′TM′ Turkmenistan
′TR′ Turkey
′UA′ Ukraine
′V′ Vatican City
′YU′ Yugoslavia
′UNK′Unknown
′EC′ European Community
′EUR′ Rest of Europe
′WLD′Rest of the world.1998R2135 — EN — 25.08.2002 — 001.001 — 74
▼M1
2.72. NationNumeric
Numerical reference to a country.
NationNumeric ::= INTEGER(0..255)Value assignment:
- - No information available (00)H,
- - Austria (01)H,- - Albania (02)H,- - Andorra (03)H,- - Armenia (04)H,- - Azerbaijan (05)H,- - Belgium (06)H,- - Bulgaria (07)H,- - Bosnia and Herzegovina (08)H,- - Belarus (09)H,- - Switzerland (0A)H,- - Cyprus (0B)H,- - Czech Republic (0C)H,- - Germany (0D)H,- - Denmark (0E)H,- - Spain (0F)H,- - Estonia (10)H,- - France (11)H,- - Finland (12)H,- - Liechtenstein (13)H,
- - Faeroe Islands (14)H,
- - United Kingdom (15)H,- - Georgia (16)H,- - Greece (17)H,- - Hungary (18)H,- - Croatia (19)H,- - Italy (1A)H,- - Ireland (1B)H,- - Iceland (1C)H,- - Kazakhstan (1D)H,- - Luxembourg (1E)H,- - Lithuania (1F)H,- - Latvia (20)H,- - Malta (21)H,- - Monaco (22)H,- - Republic of Moldova (23)H,- - Macedonia (24)H,- - Norway (25)H,- - Netherlands (26)H,- - Portugal (27)H,- - Poland (28)H,- - Romania (29)H,- - San Marino (2A)H,
- - Russian Federation (2B)H,
- - Sweden (2C)H,- - Slovakia (2D)H,- - Slovenia (2E)H,- - Turkmenistan (2F)H,- - Turkey (30)H,1998R2135 — EN — 25.08.2002 — 001.001 — 75
▼M1
- - Ukraine (31)H,
- - Vatican City (32)H,
- - Yugoslavia (33)H,
- - RFU (34..FC)H,
- - European Community (FD)H,
- - Rest of Europe (FE)H,
- - Rest of the world (FF)H
2.73. NoOfCalibrationRecords
Number of calibration records, a workshop card can store.
NoOfCalibrationRecords ::= INTEGER(0..255)
Value assignment: see paragraph 3.
2.74. NoOfCalibrationsSinceDownload
Counter indicating the number of calibrations performed with a workshop card
since its last download (requirement 230).
NoOfCalibrationsSinceDownload ::= INTEGER(0..216-1),
Value assignment: Not specified further.
2.75. NoOfCardPlaceRecords
Number of place records a driver or workshop card can store.
NoOfCardPlaceRecords ::= INTEGER(0..255)
Value assignment: see paragraph 3.
2.76. NoOfCardVehicleRecords
Number of vehicles used records a driver or workshop card can store.
NoOfCardVehicleRecords ::= INTEGER(0..216-1)
Value assignment: see paragraph 3.
2.77. NoOfCompanyActivityRecords
Number of company activity records, a company card can store.
NoOfCompanyActivityRecords ::= INTEGER(0..216-1)
Value assignment : see paragraph 3.
2.78. NoOfControlActivityRecords
Number of control activity records, a control card can store.
NoOfControlActivityRecords ::= INTEGER(0..216-1)
Value assignment : see paragraph 3.
2.79. NoOfEventsPerType
Number of events per type of event a card can store.
NoOfEventsPerType ::= INTEGER(0..255)
Value assignment: see paragraph 3.
2.80. NoOfFaultsPerType
Number of faults per type of fault a card can store.
NoOfFaultsPerType ::= INTEGER(0..255)
Value assignment: see paragraph 3.
2.81. OdometerValueMidnight
The vehicle's odometer value at midnight on a given day (requirement 090).
OdometerValueMidnight ::= OdometerShort
Value assignment: not further specified.
2.82. OdometerShort
Odometer value of the vehicle in a short form.1998R2135 — EN — 25.08.2002 — 001.001 — 76
▼M1
OdometerShort ::= INTEGER(0..224-1)
Value assignment: Unsigned binary. Value in km in the operating range 0 to
9 999 999 km.
2.83. OverspeedNumber
Number of over speeding events since the last over speeding control.
OverspeedNumber ::= INTEGER(0..255)
Value assignment: 0 means that no over speeding event has occurred since the
last over speeding control, 1 means that one over speeding event has occurred
since the last over speeding control … 255 means that 255 or more over
speeding events have occurred since the last over speeding control.
2.84. PlaceRecord
Information related to a place where a daily work period begins or ends
(requirements 087, 202, 221).
PlaceRecord ::= SEQUENCE {
entryTime TimeReal,
entryTypeDailyWorkPeriod EntryTypeDailyWorkPeriod,
dailyWorkPeriodCountry NationNumeric,
dailyWorkPeriodRegion RegionNumeric,
vehicleOdometerValue OdometerShort
}
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.
2.85. PreviousVehicleInfo
Information related to the vehicle previously used by a driver when inserting his
card in a vehicle unit (requirement 081).
PreviousVehicleInfo ::= SEQUENCE {
vehicleRegistrationIdentification VehicleRegistrationIdentifi-
cation,
cardWithdrawalTime TimeReal
}
vehicleRegistrationIdentification is the VRN and the registering Member State
of the vehicle.
cardWithdrawalTime is the card withdrawal date and time.
2.86. PublicKey
A public RSA key.
PublicKey ::= SEQUENCE {
rsaKeyModulus RSAKeyModulus,
rsaKeyPublicExponent RSAKeyPublicExponent
}
rsaKeyModulus is the Modulus of the key pair.
rsaKeyPublicExponent is the public exponent of the key pair.
2.87. RegionAlpha
Alphabetic reference to a region within a specified country.
RegionAlpha ::= IA5STRING(SIZE(3))
Value assignment:
′′ No information available
Spain:
′AN′ Andalucía1998R2135 — EN — 25.08.2002 — 001.001 — 77
▼M1
′AR′ Aragón
′AST′Asturias
′C′ Cantabria
′CAT′Cataluña
′CL′ Castilla-León
′CM′ Castilla-La-Mancha
′CV′ Valencia
′EXT′Extremadura
′G′ Galicia
′IB′ Baleares
′IC′ Canarias
′LR′ La Rioja
′M′ Madrid
′MU′ Murcia
′NA′ Navarra
′PV′ País Vasco.
2.88. RegionNumeric
Numerical reference to a region within a specified country.
RegionNumeric ::= OCTET STRING (SIZE(1))
Value assignment:
′00′H No information available
Spain:
′01′H Andalucía
′02′H Aragón
′03′H Asturias
′04′H Cantabria
′05′H Cataluña
′06′H Castilla-León
′07′H Castilla-La-Mancha
′08′H Valencia
′09′H Extremadura
′0A′H Galicia
′0B′H Baleares
′0C′H Canarias
′0D′H La Rioja
′0E′H Madrid
′0F′H Murcia
′10′H Navarra
′11′H País Vasco.
2.89. RSAKeyModulus
The modulus of a RSA key pair.
RSAKeyModulus ::= OCTET STRING (SIZE(128))
Value assignment : Unspecified.
2.90. RSAKeyPrivateExponent
The private exponent of a RSA key pair.
RSAKeyPrivateExponent ::= OCTET STRING (SIZE(128))Value assignment : Unspecified.
2.91. RSAKeyPublicExponent
The public exponent of a RSA key pair.
RSAKeyPublicExponent ::= OCTET STRING (SIZE(8))1998R2135 — EN — 25.08.2002 — 001.001 — 78
▼M1
Value assignment : Unspecified.
2.92. SensorApprovalNumber
Type approval number of the sensor.
SensorApprovalNumber ::= IA5String(SIZE(8))Value assignment : Unspecified.
2.93. SensorIdentification
Information, stored in a motion sensor, related to the identification of the motion
sensor (requirement 077).
SensorIdentification ::= SEQUENCE {
sensorSerialNumber SensorSerialNumber,sensorApprovalNumber SensorApprovalNumber,sensorSCIdentifier SensorSCIdentifier,sensorOSIdentifier SensorOSIdentifier
}
sensorSerialNumber is the extended serial number of the motion sensor
(includes part number and manufacturer code).
sensorApprovalNumber is the approval number of the motion sensor.
sensorSCIdentifier is the identifier of the security component of the motion
sensor.
sensorOSIdentifier is the identifier of the operating system of the motion
sensor.
2.94. SensorInstallation
Information, stored in a motion sensor, related to the installation of the motion
sensor (requirement 099).
SensorInstallation ::= SEQUENCE {
sensorPairingDateFirst SensorPairingDate,firstVuApprovalNumber VuApprovalNumber,firstVuSerialNumber VuSerialNumber,sensorPairingDateCurrent SensorPairingDate,currentVuApprovalNumber VuApprovalNumber,currentVUSerialNumber VuSerialNumber
}
sensorPairingDateFirst is the date of the first pairing of the motion sensor with
a vehicle unit.
firstVuApprovalNumber is the approval number of the first vehicle unit paired
with the motion sensor.
firstVuSerialNumber is the serial number of the first vehicle unit paired with
the motion sensor.
sensorPairingDateCurrent is the date of the current pairing of the motion
sensor with the vehicle unit.
currentVuApprovalNumber is the approval number of the vehicle unit
currently paired with the motion sensor.
currentVUSerialNumber is the serial number of the vehicle unit currently
paired with the motion sensor.
2.95. SensorInstallationSecData
Information, stored in a workshop card, related to the security data needed for
pairing motion sensors to vehicle units (requirement 214).
SensorInstallationSecData ::= TDesSessionKeyValue assignment: in accordance with ISO 16844-3.
2.96. SensorOSIdentifier
Identifier of the operating system of the motion sensor.
SensorOSIdentifier ::= IA5String(SIZE(2))Value assignment: manufacturer specific.1998R2135 — EN — 25.08.2002 — 001.001 — 79
▼M1
2.97. SensorPaired
Information, stored in a vehicle unit, related to the identification of the motion
sensor paired with the vehicle unit (requirement 079).
SensorPaired ::= SEQUENCE {
sensorSerialNumber SensorSerialNumber,sensorApprovalNumber SensorApprovalNumber,sensorPairingDateFirst SensorPairingDate
}
sensorSerialNumber is the serial number of the motion sensor currently paired
with the vehicle unit.
sensorApprovalNumber is the approval number of the motion sensor currently
paired with the vehicle unit.
sensorPairingDateFirst is the date of the first pairing with a vehicle unit of the
motion sensor currently paired with the vehicle unit.
2.98. SensorPairingDate
Date of a pairing of the motion sensor with a vehicle unit.
SensorPairingDate ::= TimeRealValue assignment: Unspecified.
2.99. SensorSerialNumber
Serial number of the motion sensor.
SensorSerialNumber ::= ExtendedSerialNumber :
2.100. SensorSCIdentifier
Identifier of the security component of the motion sensor.
SensorSCIdentifier ::= IA5String(SIZE(8))Value assignment: component manufacturer specific.
2.101. Signature
A digital signature.
Signature ::= OCTET STRING (SIZE(128))Value assignment: in accordance with Appendix 11, ‘Common security
mechanisms’.
2.102. SimilarEventsNumber
The number of similar events for one given day (requirement 094).
SimilarEventsNumber ::= INTEGER(0..255)Value assignment: 0 is not used, 1 means that only one event of that type have
occurred and have been stored on that day, 2 means that 2 events of that type
have occurred on that day (one only has been stored), … 255 means that 255 or
more events of that type have occurred on that day.
2.103. SpecificConditionType
Code identifying a specific condition (requirements 050b, 105a, 212a and 230a).
SpecificConditionType ::= INTEGER(0..255)Value assignment:
′00′H RFU
′01′H Out of scope — Begin
′02′H Out of scope — End
′03′H Ferry/Train crossing
′04′H. .′FF′H RFU.
2.104. SpecificConditionRecord
Information, stored in a driver card, a workshop card or a vehicle unit, related to
a specific condition (requirements 105a, 212a and 230a).
SpecificConditionRecord ::= SEQUENCE {1998R2135 — EN — 25.08.2002 — 001.001 — 80
▼M1
entryTime TimeReal,
specificConditionType SpecificConditionType
}
entryTime is the date and time of the entry.
specificConditionType is the code identifying the specific condition.
2.105. Speed
Speed of the vehicle (km/h).
Speed ::= INTEGER(0..255)Value assignment: kilometre per hour in the operational range 0 to 220 km/h.
2.106. SpeedAuthorised
Maximum authorised Speed of the vehicle (definition bb)).
SpeedAuthorised ::= Speed .
2.107. SpeedAverage
Average speed in a previously defined duration (km/h).
SpeedAverage ::= Speed .
2.108. SpeedMax
Maximum speed measured in a previously defined duration.
SpeedMax ::= Speed .
2.109. TDesSessionKey
A triple DES session key.
TDesSessionKey ::= SEQUENCE {
tDesKeyA OCTET STRING (SIZE(8))tDesKeyB OCTET STRING (SIZE(8))
}
Value assignment: not further specified.
2.110. TimeReal
Code for a combined date and time field, where the date and time are expressed
as seconds past 00h.00m.00s. on 1 January 1970 GMT.
TimeReal{INTEGER:TimeRealRange} ::= INTEGER(0..TimeR-
ealRange)
Value assignment — Octet Aligned : Number of seconds since midnight 1
January 1970 GMT.
The max possible date/time is in the year 2106.
2.111. TyreSize
Designation of tyre dimensions.
TyreSize ::= IA5String(SIZE(15))Value assignment : in accordance with Directive 92/23 (EEC) 31.3.1992, OJ L
129, p. 95.
2.112. VehicleIdentificationNumber
Vehicle Identification Number (VIN) referring to the vehicle as a whole,
normally chassis serial number or frame number.
VehicleIdentificationNumber ::= IA5String(SIZE(17))Value assignment : As defined in ISO 3779.
2.113. VehicleRegistrationIdentification
Identification of a vehicle, unique for Europe (VRN and Member State).
VehicleRegistrationIdentification ::= SEQUENCE {
vehicleRegistrationNation NationNumeric,vehicleRegistrationNumber VehicleRegistrationNumber1998R2135 — EN — 25.08.2002 — 001.001 — 81
▼M1
}
vehicleRegistrationNation is the nation where the vehicle is registered.
vehicleRegistrationNumber is the registration number of the vehicle (VRN).
2.114. VehicleRegistrationNumber
Registration number of the vehicle (VRN). The registration number is assigned
by the vehicle licensing authority.
VehicleRegistrationNumber ::= SEQUENCE {
codePage INTEGER (0..255),vehicleRegNumber OCTET STRING (SIZE(13))
}
codePage specifies the part of the ISO/IEC 8859 used to code the vehicleReg-
Number,
vehicleRegNumber is a VRN coded in accordance with ISO/IEC 8859-code-
Page.
Value assignment: Country specific.
2.115. VuActivityDailyData
Information, stored in a VU, related to changes of activity and/or changes of
driving status and/or changes of card status for a given calendar day (require-
ment 084) and to slots status at 00.00 that day.
VuActivityDailyData ::= SEQUENCE {
noOfActivityChanges INTEGER SIZE(0..1 440),activityChangeInfos SET SIZE(noOfActivityChanges) OF
ActivityChangeInfo
}
noOfActivityChanges is the number of ActivityChangeInfo words in the activi-
tyChangeInfos set.
activityChangeInfos is the set of ActivityChangeInfo words stored in the VU
for the day. It always includes two ActivityChangeInfo words giving the status
of the two slots at 00.00 that day.
2.116. VuApprovalNumber
Type approval number of the vehicle unit.
VuApprovalNumber ::= IA5String(SIZE(8))
Value assignment: Unspecified.
2.117. VuCalibrationData
Information, stored in a vehicle unit, related to the calibrations of the recording
equipment (requirement 098).
VuCalibrationData ::= SEQUENCE {
noOfVuCalibrationRecords INTEGER(0..255),vuCalibrationRecords SET SIZE(noOfVuCalibrationRecords)
OF VuCalibrationRecord
}
noOfVuCalibrationRecords is the number of records contained in the vuCali-
brationRecords set.
vuCalibrationRecords is the set of calibration records.
2.118. VuCalibrationRecord
Information, stored in a vehicle unit, related a calibration of the recording equip-
ment (requirement 098).
VuCalibrationRecord ::= SEQUENCE {
calibrationPurpose CalibrationPurpose,workshopName Name,workshopAddress Address,workshopCardNumber FullCardNumber,workshopCardExpiryDate TimeReal,1998R2135 — EN — 25.08.2002 — 001.001 — 82
▼M1
vehicleIdentificationNumber VehicleIdentificationNumber,
vehicleRegistrationIdentification VehicleRegistrationIdentifi-
cation,
wVehicleCharacteristicConstan t W-VehicleCharacteristicCon-
stant,
kConstantOfRecordingEquipment K-ConstantOfRecordingE-
quipment,
lTyreCircumference L-TyreCircumference,tyreSize TyreSize,authorisedSpeed SpeedAuthorised,oldOdometerValue OdometerShort,newOdometerValue OdometerShort,oldTimeValue TimeReal,
newTimeValue TimeReal,
nextCalibrationDate TimeReal
}
calibrationPurpose is the purpose of the calibration.
workshopName, workshopAddress are the workshop name and address.
workshopCardNumber identifies the workshop card used during the calibra-
tion.
workshopCardExpiryDate is the card expiry date.
vehicleIdentificationNumber is the VIN.
vehicleRegistrationIdentification contains the VRN and registering Member
State.
wVehicleCharacteristicConstant is the characteristic coefficient of the vehicle.
kConstantOfRecordingEquipment is the constant of the recording equipment.
lTyreCircumference is the effective circumference of the wheel tyres.
tyreSize is the designation of the dimension of the tyres mounted on the
vehicle.
authorisedSpeed is the authorised speed of the vehicle.
oldOdometerValue, newOdometerValue are the old and new values of the
odometer.
oldTimeValue, newTimeValue are the old and new values of date and time.
nextCalibrationDate is the date of the next calibration of the type specified in
CalibrationPurpose to be carried out by the authorised inspection authority.
2.119. VuCardIWData
Information, stored in a vehicle unit, related to insertion and withdrawal cycles
of driver cards or of workshop cards in the vehicle unit (requirement 081).
VuCardIWData ::= SEQUENCE {
noOfIWRecords INTEGER(0..216-1),
vuCardIWRecords SET SIZE(noOfIWRecords) OF VuCardI-
WRecord
}
noOfIWRecords is the number of records in the set vuCardIWRecords.
vuCardIWRecords is a set of records related to card insertion withdrawal
cycles.
2.120. VuCardIWRecord
Information, stored in a vehicle unit, related to an insertion and withdrawal
cycle of a driver card or of a workshop card in the vehicle unit (requirement
081).
VuCardIWRecord ::= SEQUENCE {
cardHolderName HolderName,fullCardNumber FullCardNumber,cardExpiryDate TimeReal,cardInsertionTime TimeReal,
vehicleOdometerValueAtInsertion OdometerShort,1998R2135 — EN — 25.08.2002 — 001.001 — 83
▼M1
cardSlotNumber CardSlotNumber,
cardWithdrawalTime TimeReal,vehicleOdometerValueAtWithdrawal OdometerShort,previousVehicleInfo PreviousVehicleInfo
manualInputFlag ManualInputFlag
}
cardHolderName is the driver or workshop card holder's surname and first
names as stored in the card.
fullCardNumber is the type of card, its issuing Member State and its card
number as stored in the card.
cardExpiryDate is the card's expiry date as stored in the card.
cardInsertionTime is the insertion date and time.
vehicleOdometerValueAtInsertion is the vehicle odometer value at card inser-
tion.
cardSlotNumber is the slot in which the card is inserted.
cardWithdrawalTime is the withdrawal date and time.
vehicleOdometerValueAtWithdrawal is the vehicle odometer value at card
withdrawal.
previousVehicleInfo contains information about the previous vehicle used by
the driver, as stored in the card.
manualInputFlag is a flag identifying if the cardholder has manually entered
driver activities at card insertion.
2.121. VuCertificate
Certificate of the public key of a vehicle unit.
VuCertificate ::= Certificate
2.122. VuCompanyLocksData
Information, stored in a vehicle unit, related to company locks (requirement
104).
VuCompanyLocksData ::= SEQUENCE {
noOfLocks INTEGER(0..20),vuCompanyLocksRecords SET SIZE(noOfLocks) OF VuCom-
panyLocksRecord
}
noOfLocks is the number of locks listed in vuCompanyLocksRecords.
vuCompanyLocksRecords is the set of company locks records.
2.123. VuCompanyLocksRecord
Information, stored in a vehicle unit, related to one company lock (requirement
104).
VuCompanyLocksRecord ::= SEQUENCE {
lockInTime TimeReal,
lockOutTime TimeReal,
companyName Name,companyAddress Address,companyCardNumber FullCardNumber
}
lockInTime, lockOutTime are the date and time of lock-in and lock-out.
companyName, companyAddress are the company name and address related
with the lock-in.
companyCardNumber identifies the card used at lock-in.
2.124. VuControlActivityData
Information, stored in a vehicle unit, related to controls performed using this
VU (requirement 102).
VuControlActivityData ::= SEQUENCE {1998R2135 — EN — 25.08.2002 — 001.001 — 84
▼M1
noOfControls INTEGER(0..20),
vuControlActivityRecords SET SIZE(noOfControls) OF
VuControlActivityRecord
}
noOfControls is the number of controls listed in vuControlActivityRecords.
vuControlActivityRecords is the set of control activity records.
2.125. VuControlActivityRecord
Information, stored in a vehicle unit, related to a control performed using this
VU (requirement 102).
VuControlActivityRecord ::= SEQUENCE {
controlType ControlType,controlTime TimeReal,controlCardNumber FullCardNumber,downloadPeriodBeginTime TimeReal,downloadPeriodEndTime TimeReal
}
controlType is the type of the control.
controlTime is the date and time of the control.
ControlCardNumber identifies the control card used for the control.
downloadPeriodBeginTime is the begin time of the downloaded period, in case
of downloading.
downloadPeriodEndTime is the end time of the downloaded period, in case of
downloading.
2.126. VuDataBlockCounter
Counter, stored in a card, identifying sequentially the insertion withdrawal
cycles of the card in vehicle units.
VuDataBlockCounter ::= BCDString(SIZE(2))
Value assignment : Consecutive Number with max, value 9 999, starting again
with 0.
2.127. VuDetailedSpeedBlock
Information, stored in a vehicle unit, related to the vehicle's detailed speed for a
minute during which the vehicle has been moving (requirement 093).
VuDetailedSpeedBlock ::= SEQUENCE {
speedBlockBeginDate TimeReal,speedsPerSecond SEQUENCE SIZE(60) OF Speed
}
speedBlockBeginDate is the date and time of the first speed value within the
block.
speedsPerSecond is the chronological sequence of measured speeds every
seconds for the minute starting at speedBlockBeginDate (included).
2.128. VuDetailedSpeedData
Information, stored in a vehicle unit, related to the detailed speed of the vehicle.
VuDetailedSpeedData ::= SEQUENCE
noOfSpeedBlocks INTEGER(0.2
16-1),
vuDetailedSpeedBlocks SET SIZE(noOfSpeedBlocks) OF
VuDetailedSpeedBlock
}
noOfSpeedBlocks is the number of speed blocks in the vuDetailedSpeedBlocks
set.
vuDetailedSpeedBlocks is the set of detailed speed blocks.
2.129. VuDownloadablePeriod
Oldest and latest dates for which a vehicle unit holds data related to drivers
activities (requirements 081, 084 or 087).1998R2135 — EN — 25.08.2002 — 001.001 — 85
▼M1
VuDownloadablePeriod ::= SEQUENCE {
minDownloadableTime TimeReal
maxDownloadableTime TimeReal
}
minDownloadableTime is the oldest card insertion or activity change or place
entry date and time stored in the VU.
maxDownloadableTime is the latest card withdrawal or activity change or
place entry date and time stored in the VU.
2.130. VuDownloadActivityData
Information, stored in a vehicle unit, related to its last download (requirement
105).
VuDownloadActivityData ::= SEQUENCE {
downloadingTime TimeReal,
fullCardNumber FullCardNumber,companyOrWorkshopName Name
}
downloadingTime is the date and time of downloading.
fullCardNumber identifies the card used to authorise the download.
companyOrWorkshopName is the company or workshop name.
2.131. VuEventData
Information, stored in a vehicle unit, related to events (requirement 094 except
over speeding event).
VuEventData ::= SEQUENCE {
noOfVuEvents INTEGER(0..255),
vuEventRecords SET SIZE(noOfVuEvents) OF VuEventRecord
}
noOfVuEvents is the number of events listed in the vuEventRecords set.
vuEventRecords is a set of events records.
2.132. VuEventRecord
Information, stored in a vehicle unit, related to an event (requirement 094 except
over speeding event).
VuEventRecord ::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,eventBeginTime TimeReal,
eventEndTime TimeReal,
cardNumberDriverSlotBegin FullCardNumber,cardNumberCodriverSlotBegin FullCardNumber,
cardNumberDriverSlotEnd FullCardNumber,
cardNumberCodriverSlotEnd FullCardNumber,similarEventsNumber SimilarEventsNumber
}
eventType is the type of the event.
eventRecordPurpose is the purpose for which this event has been recorded.
eventBeginTime is the date and time of beginning of event.
eventEndTime is the date and time of end of event.
cardNumberDriverSlotBegin identifies the card inserted in the driver slot at
the beginning of the event.
cardNumberCodriverSlotBegin identifies the card inserted in the co-driver slot
at the beginning of the event.
cardNumberDriverSlotEnd identifies the card inserted in the driver slot at the
end of the event.1998R2135 — EN — 25.08.2002 — 001.001 — 86
▼M1
cardNumberCodriverSlotEnd identifies the card inserted in the co-driver slot
at the end of the event.
similarEventsNumber is the number of similar events that day.
This sequence can be used for all events other than over speeding events.
2.133. VuFaultData
Information, stored in a vehicle unit, related to faults (requirement 096).
VuFaultData ::= SEQUENCE {
noOfVuFaults INTEGER(0..255),
vuFaultRecords SET SIZE(noOfVuF aults) OF VuFaultRecord
}
noOfVuFaults is the number of faults listed in the vuFaultRecords set.
vuFaultRecords is a set of faults records.
2.134. VuFaultRecord
Information, stored in a vehicle unit, related to a fault (requirement 096).
VuFaultRecord ::= SEQUENCE {
faultType EventFaultType,
faultRecordPurpose EventFaultRecordPurpose,
faultBeginTime TimeReal,
faultEndTime TimeReal,
cardNumberDriverSlotBegin FullCardNumber,cardNumberCodriverSlotBegin FullCardNumber,
cardNumberDriverSlotEnd FullCardNumber,
cardNumberCodriverSlotEnd FullCardNumber
}
faultType is the type of recording equipment fault.
faultRecordPurpose is the purpose for which this fault has been recorded.
faultBeginTime is the date and time of beginning of fault.
faultEndTime is the date and time of end of fault.
cardNumberDriverSlotBegin identifies the card inserted in the driver slot at
the beginning of the fault.
cardNumberCodriverSlotBegin identifies the card inserted in the co-driver slot
at the beginning of the fault.
cardNumberDriverSlotEnd identifies the card inserted in the driver slot at the
end of the fault.
cardNumberCodriverSlotEnd identifies the card inserted in the co-driver slot
at the end of the fault.
2.135. VuIdentification
Information, stored in a vehicle unit, related to the identification of the vehicle
unit (requirement 075).
VuIdentification ::= SEQUENCE {
vuManufacturerName VuManufacturerName,
vuManufacturerAddress VuManufacturerAddress,
vuPartNumber VuPartNumber,
vuSerialNumber VuSerialNumber,
vuSoftwareIdentification VuSoftwareIdentification,
vuManufacturingDate VuManufacturingDate,
vuApprovalNumber VuApprovalNumber
}
vuManufacturerName is the name of the manufacturer of the vehicle unit.
vuManufacturerAddress is the address of the manufacturer of the vehicle unit.
vuPartNumber is the part number of the vehicle unit.
vuSerialNumber is the serial number of the vehicle unit.1998R2135 — EN — 25.08.2002 — 001.001 — 87
▼M1
vuSoftwareIdentification identifies the software implemented in the vehicle
unit.
vuManufacturingDate is the manufacturing date of the vehicle unit.
vuApprovalNumber is the type approval number of the vehicle unit.
2.136. VuManufacturerAddress
Address of the manufacturer of the vehicle unit.
VuManufacturerAddress ::= Address
Value assignment: Unspecified.
2.137. VuManufacturerName
Name of the manufacturer of the vehicle unit.
VuManufacturerName ::= NameValue assignment: Unspecified.
2.138. VuManufacturingDate
Date of manufacture of the vehicle unit.
VuManufacturingDate ::= TimeReal
Value assignment: Unspecified.
2.139. VuOverSpeedingControlData
Information, stored in a vehicle unit, related to over speeding events since the
last over speeding control (requirement 095).
VuOverSpeedingControlData ::= SEQUENCE {
lastOverspeedControlTime TimeReal,
firstOverspeedSince TimeReal,
numberOfOverspeedSince OverspeedNumber
}
lastOverspeedControlTime is the date and time of the last over speeding
control.
firstOverspeedSince is the date and time of the first over speeding following
this over speeding control.
numberOfOverspeedSince is the number of over speeding events since the last
over speeding control.
2.140. VuOverSpeedingEventData
Information, stored in a vehicle unit, related to over speeding events (require-
ment 094).
VuOverSpeedingEventData ::= SEQUENCE {
noOfVuOverSpeedingEvents INTEGER(0..255),
vuOverSpeedingEventRecords SET SIZE(noOfVuOverSpeedin-
gEvents) OF VuOverSpeedingEventRecord
}
noOfVuOverSpeedingEvents is the number of events listed in the vuOverSpee-
dingEventRecords set.
vuOverSpeedingEventRecords is a set of over speeding events records.
2.141. VuOverSpeedingEventRecord
Information, stored in a vehicle unit, related to over speeding events (require-
ment 094).
VuOverSpeedingEventRecord ::= SEQUENCE {
eventType EventFaultType,
eventRecordPurpose EventFaultRecordPurpose,
eventBeginTime TimeReal,
eventEndTime TimeReal,
maxSpeedValue SpeedMax,
averageSpeedValue SpeedAverage,1998R2135 — EN — 25.08.2002 — 001.001 — 88
▼M1
cardNumberDriverSlotBegin FullCardNumber,
similarEventsNumber SimilarEventsNumber
}
eventType is the type of the event.
eventRecordPurpose is the purpose for which this event has been recorded.
eventBeginTime is the date and time of beginning of event.
eventEndTime is the date and time of end of event.
maxSpeedValue is the maximum speed measured during the event.
averageSpeedValue is the arithmetic average speed measured during the event.
cardNumberDriverSlotBegin identifies the card inserted in the driver slot at
the beginning of the event.
similarEventsNumber is the number of similar events that day.
2.142. VuPartNumber
Part number of the vehicle unit.
VuPartNumber ::= IA5String(SIZE(16))
Value assignment : VU manufacturer specific.
2.143. VuPlaceDailyWorkPeriodData
Information, stored in a vehicle unit, related to places where drivers begin or
end a daily work periods (requirement 087).
VuPlaceDailyWorkPeriodData ::= SEQUENCE {
noOfPlaceRecords INTEGER(0..255),vuPlaceDailyWorkPeriodRecords SET SIZE(noOfPlaceRe-
cords) OF VuPlaceDailyWorkPeriodRecord
}
noOfPlaceRecords is the number of records listed in the vuPlaceDailyWorkPer-
iodRecords set.
vuPlaceDailyWorkPeriodRecords is a set of place related records.
2.144. VuPlaceDailyWorkPeriodRecord
Information, stored in a vehicle unit, related to a place where a driver begins or
ends a daily work period (requirement 087).
VuPlaceDailyWorkPeriodRecord ::= SEQUENCE {
fullCardNumber FullCardNumber,
placeRecord PlaceRecord
}
fullCardNumber is the driver's card type, card issuing Member State and card
number.
placeRecord contains the information related to the place entered.
2.145. VuPrivateKey
The private key of a vehicle unit.
VuPrivateKey ::= RSAKeyPrivateExponent
2.146. VuPublicKey
The public key of a vehicle unit.
VuPublicKey ::= PublicKey
2.147. VuSerialNumber
Serial number of the vehicle unit (requirement 075).
VuSerialNumber ::= ExtendedSerialNumber
2.148. VuSoftInstallationDate
Date of installation of the vehicle unit software version.
VuSoftInstallationDate ::= TimeReal1998R2135 — EN — 25.08.2002 — 001.001 — 89
▼M1
Value assignment: Unspecified.
2.149. VuSoftwareIdentification
Information, stored in a vehicle unit, related to the software installed.
VuSoftwareIdentification ::= SEQUENCE {
vuSoftwareVersion VuSoftwareVersion,vuSoftInstallationDate VuSoftInstallationDate
}
vuSoftwareVersion is the software version number of the Vehicle Unit.
vuSoftInstallationDate is the software version installation date.
2.150. VuSoftwareVersion
Software version number of the vehicle unit.
VuSoftwareVersion ::= IA5String(SIZE(4))
Value assignment: Unspecified.
2.151. VuSpecificConditionData
Information, stored in a vehicle unit, related to specific conditions.
VuSpecificConditionData ::= SEQUENCE {
noOfSpecificConditionRecords INTEGER(0..2
16-1)
specificConditionRecords SET SIZE (noOfSpecificCondition-
Records) OF SpecificConditionRecord
}
noOfSpecificConditionRecords is the number of records listed in the specific-
ConditionRecords set.
specificConditionRecords is a set of specific conditions related records.
2.152. VuTimeAdjustmentData
Information, stored in a vehicle unit, related to time adjustments performed
outside the frame of a regular calibration (requirement 101).
VuTimeAdjustmentData ::= SEQUENCE {
noOfVuTimeAdjRecords INTEGER(0..6),
vuTimeAdjustmentRecords SET SIZE(noOfVuTimeAdjRe-
cords) OF VuTimeAdjustmentRecords
}
noOfVuTimeAdjRecords is the number of records in vuTimeAdjustmentRe-
cords.
vuTimeAdjustmentRecords is a set of time adjustment records.
2.153. VuTimeAdjustmentRecord
Information, stored in a vehicle unit, related to a time adjustment performed
outside the frame of a regular calibration (requirement 101).
VuTimeAdjustmentRecord ::= SEQUENCE {
oldTimeValue TimeReal,
oldTimeValue TimeReal,
newTimeValue TimeReal,
workshopName Name,workshopAddress Address,
workshopCardNumber FullCardNumber
}
oldTimeValue, newTimeValue are the old and new values of date and time.
workshopName, workshopAddress are the workshop name and address.
workshopCardNumber identifies the workshop card used to perform the time
adjustment.1998R2135 — EN — 25.08.2002 — 001.001 — 90
▼M1
2.154. W-VehicleCharacteristicConstant
Characteristic coefficient of the vehicle (definition k)).
W-VehicleCharacteristicConstant ::= INTEGER(0..216-1))
Value assignment: Impulses per kilometre in the operating range 0 to
64 255 pulses/km.
2.155. WorkshopCardApplicationIdentification
Information, stored in a workshop card related to the identification of the appli-
cation of the card (requirement 190).
WorkshopCardApplicationIdentification ::= SEQUENCE {
typeOfTachographCardId EquipmentType,cardStructureVersion CardStructureVersion,noOfEventsPerType NoOfEventsPerType,noOfFaultsPerType NoOfFaultsPerType,activityStructureLength CardActivityLengthRange,noOfCardVehicleRecords NoOfCardVehicleRecords,noOfCardPlaceRecords NoOfCardPlaceRecords,noOfCalibrationRecords NoOfCalibrationRecords
}
typeOfTachographCardId is specifying the implemented type of card.
cardStructureVersion is specifying the the version of the structure that is
implemented in the card.
noOfEventsPerType is the number of events per type of event the card can
record.
noOfFaultsPerType is the number of faults per type of fault the card can
record.
activityStructureLength indicates the number of bytes available for storing
activity records.
noOfCardVehicleRecords is the number of vehicle records the card can
contain.
noOfCardPlaceRecords is the number of places the card can record.
noOfCalibrationRecords is the number of calibration records the card can
store.
2.156. WorkshopCardCalibrationData
Information, stored in a workshop card, related to workshop activity performed
with the card (requirements 227 and 229).
WorkshopCardCalibrationData ::= SEQUENCE {
calibrationTotalNumber INTEGER(0..2
16-1),
calibrationPointerNewestRecord INTEGER(0..NoOfCalibra-
tionRecords-1),
calibrationRecords SET SIZE(NoOfCalibrationRecords) OF
WorkshopCardCalibrationRecord
}
calibrationTotalNumber is the total number of calibrations performed with the
card.
calibrationPointerNewestRecord is the index of the last updated calibration
record.
Value assignment: Number corresponding to the numerator of the calibration
record, beginning with ‘0’ for the first occurrence of the calibration records in
the structure.
calibrationRecords is the set of records containing calibration and/or time
adjustment information.
2.157. WorkshopCardCalibrationRecord
Information, stored in a workshop card, related to a calibration performed with
the card (requirement 227).
WorkshopCardCalibrationRecord ::= SEQUENCE {
calibrationPurpose CalibrationPurpose,1998R2135 — EN — 25.08.2002 — 001.001 — 91
▼M1
vehicleIdentificationNumber VehicleIdentificationNumber,
vehicleRegistration VehicleRegistrationIdentification,wVehicleCharacteristicConstan t W-VehicleCharacteristicCon-
stant,
kConstantOfRecordingEquipment K-ConstantOfRecordingE-
quipment,
lTyreCircumference L-TyreCircumference,tyreSize TyreSize,
authorisedSpeed SpeedAuthorised,
oldOdometerValue OdometerShort,
newOdometerValue OdometerShort,
oldTimeValue TimeReal,newTimeValue TimeReal,
nextCalibrationDate TimeReal,
vuPartNumber VuPartNumber,vuSerialNumber VuSerialNumber,
sensorSerialNumber SensorSerialNumber
}
calibrationPurpose is the purpose of the calibration.
vehicleIdentificationNumber is the VIN.
vehicleRegistration contains the VRN and registering Member State.
wVehicleCharacteristicConstant is the characteristic coefficient of the vehicle.
kConstantOfRecordingEquipment is the constant of the recording equipment.
lTyreCircumference is the effective circumference of the wheel tyres.
tyreSize is the designation of the dimensions of the tyres mounted on the
vehicle.
authorisedSpeed is the maximum authorised speed of the vehicle.
oldOdometerValue, newOdometerValue are the old and new values of the
odometer.
oldTimeValue, newTimeValue are the old and new values of date and time.
nextCalibrationDate is the date of the next calibration of the type specified in
CalibrationPurpose to be carried out by the authorised inspection authority.
vuPartNumber, vuSerialNumber and sensorSerialNumber are the data
elements for recording equipment identification.
2.158. WorkshopCardHolderIdentification
Information, stored in a workshop card, related to the identification of the card-
holder (requirement 216).
WorkshopCardHolderIdentif ication ::= SEQUENCE {
workshopName Name,
workshopAddress Address,
cardHolderName HolderName,
cardHolderPreferredLanguage Language
}
workshopName is name of the workshop of the card holder.
workshopAddress is the address of the workshop of the card holder.
cardHolderName is the name and first name(s) of the holder (e.g. the name of
the mechanic).
cardHolderPreferredLanguage is the preferred language of the card holder.
2.159. WorkshopCardPIN
Personal identification number of the Workshop Card (requirement 213).
WorkshopCardPIN ::= IA5String(SIZE(8))
Value assignment : The PIN known to the cardholder, right padded with ‘FF’
bytes up to 8 bytes.1998R2135 — EN — 25.08.2002 — 001.001 — 92
▼M1
3. VALUE AND SIZE RANGE DEFINITIONS
Definition of variable values used for definitions in paragraph 2.
TimeRealRange ::= 232-1
3.1. Definitions for the Driver Card:
Name of the variable value Minimum Maximum
C ardAc tiv ity Len gth Rang e 5 544 bytes
(28 days 93 activity
changes per day)13 776 bytes
(28 days 240 activity
changes per day)
No OfCa rdPla ce Rec ords 84 112
NoOfCardVehicleRecords 84 200NoOfEventsPerType 6 12NoOfFaultsPerType 12 24
3.2. Definitions for the Workshop Card:
Name of the variable value Minimum Maximum
C ardAc tiv ity Len gth Rang e 198 bytes
(1 day 93 activity
changes)492 bytes
(1 day 240 activity
changes)
NoOfCardPlaceRecords 6 8
NoOfCardVehicleRecords 4 8
NoOfEventsPerType 3 3NoOfFaultsPerType 6 6NoOfCalibrationRecords 88 255
3.3. Definitions for the Control Card:
Name of the variable value Minimum Maximum
No OfCon trol Act ivit yRe cord s 230 520
3.4. Definitions for the Company Card:
Name of the variable value Minimum Maximum
No OfCom pa nyAc tivi tyR eco rds 230 520
4. CHARACTER SETS
IA5Strings use the ASCII characters as defined by ISO/IEC 8824-1. For read-
ability and for easy referencing the value assignment is given below. The ISO/
IEC 8824-1 supersedes this informative note in case of discrepancy.
!"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
/primerevabcdefghijklmnopqrstuvwxyz{|} =1998R2135 — EN — 25.08.2002 — 001.001 — 93
▼M1
Other character strings (Address, Name, VehicleRegistrationNumber) use, in
addition, the characters defined by the codes 192 to 255 of ISO/IEC 8859-1
(Latin1 character set) or ISO/IEC 8859-7 (Greek character set).
5. ENCODING
When encoded with ASN.1 encoding rules, all data types defined shall be
encoded according to ISO/IEC 8825-2, aligned variant.1998R2135 — EN — 25.08.2002 — 001.001 — 94
▼M1
Appendix 2
TACHOGRAPH CARDS SPECIFICATION
Contents
1. Introduction … . . . .........................................................
1.1. Abbreviations … . .........................................................
1.2. References … .............................................................
2. Electrical and physical characteristics … .......................................
2.1. Supply voltage and current consumption … . ...................................
2.2. Programming voltage Vpp… .................................................
2.3. Clock generation and frequency … ............................................
2.4. I/O contact … .............................................................
2.5. States of the card … .......................................................
3. Hardware and communication … .............................................
3.1. Introduction … . . . .........................................................
3.2. Transmission protocol … . ...................................................
3.2.1. Protocols … ..............................................................
3.2.2. ATR … ..................................................................
3.2.3. PTS … ..................................................................
3.3. Access conditions (AC) … ..................................................
3.4. Data encryption … .........................................................
3.5. Commands and error codes overview … .......................................
3.6. Commands description … ...................................................
3.6.1. Select file … .............................................................
3.6.1.1. Selection by name (AID) … . . . ..............................................
3.6.1.2. Selection of an elementary file using its file identifier … . ........................
3.6.2. Read Binary … . . . .........................................................
3.6.2.1. Command without secure messaging … ........................................
3.6.2.2. Command with secure messaging … . . ........................................
3.6.3. Update Binary … . .........................................................
3.6.3.1. Command without secure messaging … ........................................
3.6.3.2. Command with secure messaging … . . ........................................
3.6.4. Get challenge … . .........................................................
3.6.5. Verify … . . . ..............................................................
3.6.6. Get response … . . .........................................................
3.6.7. PSO: verify certificate … ...................................................
3.6.8. Internal authenticate … . . ...................................................
3.6.9. External authenticate … . . ...................................................
3.6.10. Manage security environment … .............................................
3.6.11. PSO: hash … .............................................................
3.6.12. Perform hash of file … . . ...................................................
3.6.13. PSO: compute digital signature … ............................................
3.6.14. PSO: verify digital signature … ..............................................
4. Tachograph cards structure … . . ..............................................
4.1. Driver card structure … . . ...................................................1998R2135 — EN — 25.08.2002 — 001.001 — 95
▼M1
4.2. Workshop card structure … ..................................................
4.3. Control card structure … . ...................................................
4.4. Company card structure … ..................................................1998R2135 — EN — 25.08.2002 — 001.001 — 96
▼M1
1. INTRODUCTION
1.1. Abbreviations
For the purpose of this appendix, the following abbreviations apply:
AC access conditions
AID application identifierALW alwaysAPDU application protocol data unit (structure of a command)
ATR answer to reset
AUT authenticatedC6, C7 contacts No 6 and 7 of the card as described in ISO/IEC 7816-2cc clock cyclesCHV card holder verification informationCLA class byte of an APDU commandDF dedicated file. A DF can contain other files (EF or DF)EF elementary fileENC encrypted: access is possible only by encoding dataetu elementary time unitIC integrated circuitICC integrated circuit cardID identifierIFD interface deviceIFS information field size
IFSC information field size for the card
IFSD information field size device (for the terminal)INS instruction byte of an APDU commandLc length of the input data for a APDU commandLe length of the expected data (output data for a command)MF master file (root DF)P1-P2 parameter bytesNAD node address used in T=1 protocolNEV neverPIN personal identification numberPRO SM protected with secure messagingPTS protocol transmission selectionRFU reserved for future useRST reset (of the card)
SM secure messaging
SW1-SW2 status bytesTS initial ATR characterVPP programming voltageXXh value XX in hexadecimal notation|| concatenation symbol 03||04=0304.
1.2. References
The following references are used in this Appendix:
EN 726-3 Identification cards systems — Telecommunications integrated circuit(s) cards
and terminals — Part 3: Application independent card requirements.
December 1994.
ISO/IEC 7816-2 Information technology — Identification cards — Integrated circuit(s) cards
with contacts — Part 2: Dimensions and location of the contacts. First edition:
1999.1998R2135 — EN — 25.08.2002 — 001.001 — 97
▼M1
ISO/IEC 7816-3 Information technology — Identification cards — Integrated circuit(s) cards
with contacts — Part 3: Electronic signals and transmission protocol. Edition
2: 1997.
ISO/IEC 7816-4 Information technology — Identification cards — Integrated circuit(s) cards
with contacts — Part 4: Interindustry commands for interexchange. First
edition: 1995 + Amendment 1: 1997.
ISO/IEC 7816-6 Information technology — Identification cards — Integrated circuit(s) cards
with contacts — Part 6: Interindustry data elements. First Edition: 1996 +
Cor 1: 1998.
ISO/IEC 7816-8 Information technology — Identification cards — Integrated circuit(s) cards
with contacts — Part 8: Security related interindustry commands. First
Edition: 1999.
ISO/IEC 9797 Information technology — Security techniques — Data integrity mechanism
using a cryptographic check function employing a block cipher algorithm.
Edition 2: 1994.
2. ELECTRICAL AND PHYSICAL CHARACTERISTICS
All electronic signals shall be in accordance with ISO/IEC 7816-3 unless speci-
fied otherwise.
The location and dimensions of the card contacts shall comply with the ISO/IEC
7816-2.
2.1. Supply voltage and current consumption
The card shall work according to specifications within the consumption limits
specified in ISO/IEC 7816-3.
The card shall work with Vcc= 3 V (+/− 0,3 V) o Vcc= 5 V (+/− 0,5 V).
Voltage selection shall be performed according to ISO/IEC 7816-3.
2.2. Programming voltage Vpp
The card shall not require a programming voltage at pin C6. It is expected that
pin C6 is not connected in an IFD. Contact C6 may be connected to Vccin the
card but shall not be connected to ground. This voltage should not be interpreted
in any case.
2.3. Clock generation and frequency
The card shall operate within a frequency range of 1 to 5 MHz. Within one card
session the clock frequency may vary ± 2 %. The clock frequency is generated
by the Vehicle Unit and not the card itself. The duty cycle may vary between 40
and 60 %.
Under conditions contained into the card file EFICC, the external clock can be
stopped. The first byte of the EFICCfile body codes the Clockstop mode condi-
tions (see EN 726-3 for further details):
Low High
Bit 1 Bit 3 Bit 2
00 1 Clockstop allowed, no preferred level
01 1 Clockstop allowed, high level preferred
10 1 Clockstop allowed, low level preferred
00 0 Clockstop not allowed
01 0 Clockstop only allowed on high level
10 0 Clockstop only allowed on low level
Bits 4 to 8 are not used.1998R2135 — EN — 25.08.2002 — 001.001 — 98
▼M1
2.4. I/O contact
The I/O contact C7 is used to receive data from and to transmit data to the IFD.
During operation only either the card or the IFD shall be in transmit mode.
Should both units be in transmit mode no damage shall occur to the card. Unless
transmitting, the card shall enter the reception mode.
2.5. States of the card
The card works in two states while the supply voltage is applied:
— operation state while executing commands or interfacing with Digital Unit,
— idle state at all other times; in this state all data shall be retained by the card.
3. HARDWARE AND COMMUNICATION
3.1. Introduction
This paragraph describes the minimum functionality required by Tachograph
cards and VUs to ensure correct operation and interoperability.
Tachograph cards are as compliant as possible with the available ISO/IEC
applicable norms (especially ISO/IEC 7816). However, commands and protocols
are fully described in order to specify some restricted usage or some differences
if they exist. The commands specified are fully compliant with the referred
norms except where indicated.
3.2. Transmission protocol
The Transmission protocol shall be compliant with ISO/IEC 7816-3. In parti-
cular, the VU shall recognise waiting time extensions sent by the card.
3.2.1. Protocols
The card shall provide both protocol T=0 and protocol T=1.
T=0 is the default protocol, a PTS command is therefore necessary to change
the protocol to T=1.
Devices shall support direct convention in both protocols: the direct convention
is hence mandatory for the card.
The Information Field Size Card byte shall be presented at the ATR in character
TA3. This value shall be at least ′F0h′(= 240 bytes).
The following restrictions apply to the protocols:
T=0
— The interface device shall support an answer on I/O after the rising edge of
the signal on RST from 400 cc.
— The interface device shall be able to read characters separated with 12 etu.
— The interface device shall read an erroneous character and its repetition if
separated with 13 etu. If an erroneous character is detected, the Error signal
on I/O can occur between 1 etu and 2 etu. The device shall support a 1 etu
delay.
— The interface device shall accept a 33 bytes ATR (TS+32)
— If TC1 is present in the ATR, the Extra Guard Time shall be present for
characters sent by the interface device although characters sent by the card
can still be separated with 12 etu. This is also true for the ACK character
sent by the card after a P3 character emitted by the interface device.
— The interface device shall take into account a NUL character emitted by the
card.
— The interface device shall accept the complementary mode for ACK.
— The get-response command cannot be used in chaining mode to get a data
which length could exceed 255 bytes.
T=1
— NAD byte: not used (NAD shall be set to ′00′).
— S-block ABORT: not used.
— S-block VPP state error: not used.
— The total chaining length for a data field will not exceed 255 bytes (to be
ensured by the IFD).
— The Information Field Size Device (IFSD) shall be indicated by the IFD
immediately after the ATR: the IFD shall transmit the S-Block IFS request
after the ATR and the card shall send back S-Block IFS. The recommended
value for IFSD is 254 bytes.1998R2135 — EN — 25.08.2002 — 001.001 — 99
▼M1
— The card will not ask for an IFS readjustment.
3.2.2. ATR
The device checks ATR bytes, according to ISO/IEC 7816-3. No verification
shall be done on ATR Historical Characters.
Example of Basic Biprotocol ATR according to ISO/IEC 7816-3
Character Value Remarks
TS ′3Bh′ Indicates direct convention
T0 ′85h′ TD1 present; 5 historical bytes are presents
TD1 ′80h′ TD2 present; T=0 to be used
TD2 ′11h′ TA3 present; T=1 to be used
TA3 ′XXh′(mind.
′F0h′)Information Field Size Card (IFSC)
TH1 bis TH5 ′XXh′ Historical characters
TCK ′XXh′ Check character (exclusive OR)
After the Answer To Reset (ATR), the Master File (MF) is implicitly selected
and becomes the Current Directory.
3.2.3. PTS
The default Protocol is T=0. To set the T=1 protocol, a PTS (also known as
PPS) must be sent to the card by the device.
As both T=0 and T=1 protocols are mandatory for the card, the basic PTS for
protocol switching is mandatory for the card.
The PTS can be used, as indicated in ISO/IEC 7816-3, to switch to higher baud
rates than the default one proposed by the card in the ATR if any (TA(1) byte).
Higher baud rates are optional for the card.
If no other baud rate than the default one are supported (or if the selected baud
rate is not supported), the card shall respond to the PTS correctly according to
ISO/IEC 7816-3 by omitting the PPS1 byte.
Examples of basic PTS for protocol selection are the following:
Character Value Remarks
PPSS ′FFh′ The initiate character
PPS0 ′00h′or′01h′ PPS1 to PPS3 are not present; ′00h′to select T0,′01h′to
select T1
PK ′XXh′ Check character:′XXh′=′FFh′if PPS0 =′00h′
′XXh′=′FEh′if PPS0 =′01h′
3.3. Access conditions (AC)
Access Conditions (AC) for the UPDATE_BINARY and READ_BINARY
commands are defined for each Elementary File.
The AC of the current file must be met before accessing the file via these
commands.
The definitions of the available access conditions are the following:
— ALW: The action is always possible and can be executed
without any restriction.
— NEV: The action is never possible.— AUT: The right corresponding a successful external authentica-
tion must be opened up (done by the
EXTERNAL_AUTHENTICATE command).1998R2135 — EN — 25.08.2002 — 001.001 — 100
▼M1
— PRO SM: Command must be transmitted with a cryptographic
checksum using secure messaging (See Appendix 11).
— AUT and PRO SM (combined)
On the processing commands (UPDATE_BINARY and READ_BINARY), the
following access conditions can be set in the card:
UPDATE_ BINARY READ_ BINARY
ALW Yes Yes
NEV Yes Yes
AUT Yes Yes
PRO SM Yes No
AUT and PRO SM Yes No
The PRO SM access condition is not available for the READ_BINARY
command. It means that the presence of a cryptographic checksum for a
READ command is never mandatory. However, using the value ′OC′for the
class, it is possible to use the READ_BINARY command with secure messa-
ging, as described in paragraph 3.6.2.
3.4. Data encryption
When confidentiality of data to be read from a file needs to be protected, the
file is marked as ‘Encrypted’. Encryption is performed using secure messaging
(See Appendix 11).
3.5. Commands and error codes overview
Commands and file organisation are deduced from and complies with ISO/IEC
7816-4.
This section describes the following APDU command-response pairs:
Command INS
SELECT FILE A4
READ BINARY B0UPDATE BINARY D6
GET CHALLENGE 84
VERIFY 20GET RESPONSE C0PERFORM SECURITY OPERATION:
VERIFY CERTIFICATE
COMPUTE DIGITAL SIGNATUREVERIFY DIGITAL SIGNATURE
HASH2A
INTERNAL AUTHENTICATE 88
EXTERNAL AUTHENTICATE 82MANAGE SECURITY ENVIRONMENT:
SETTING A KEY22
PERFORM HASH OF FILE 2A
The status word SW1 SW2 are returned in any response message and denote the
processing state of the command.1998R2135 — EN — 25.08.2002 — 001.001 — 101
▼M1
SW1 SW2 Meaning
90 00 Normal processing
61 XX Normal processing. XX = number of response bytes available62 81 Warning processing. Part of returned data may be corrupted63 CX Wrong CHV (PIN). Remaining attempts counter provided by ′X′
64 00 Execution error — State of non-volatile memory unchanged. Integrity
error
65 00 Execution error — State of non-volatile memory changed
65 81 Execution error — State of non-volatile memory changed — Memory
failure
66 88 Security error: wrong Cryptographic checksum (during secure messa-
ging) or
wrong certificate (during certificate verification)
or
wrong cryptogram (during external authentica-
tion) or
wrong signature (during signature verification)
67 00 Wrong length (wrong Lc or Le)69 00 Forbidden command (no response available in T=0)69 82 Security status not satisfied
69 83 Authentication method blocked
69 85 Conditions of use not satisfied69 86 Command not allowed (no current EF)69 87 Expected secure messaging data objects missing
69 88 Incorrect secure messaging data objects
6A 82 File not found6A 86 Wrong parameters P1-P26A 88 Referenced data not found
6B 00 Wrong parameters (offset outside the EF)
6C XX Wrong length, SW2 indicates the exact length. No data field is returned
6D 00 Instruction code not supported or invalid
6E 00 Class not supported
6F 00 Other checking errors
3.6. Commands description
The mandatory commands for the Tachograph cards are described in this
chapter.
Additional relevant details, related to cryptographic operations involved, are
given in Appendix 11 Common security mechanisms.1998R2135 — EN — 25.08.2002 — 001.001 — 102
▼M1
All commands are described independently of the used protocol (T=0 or T=1).
The APDU bytes CLA, INS, P1, P2, Lc and Le are always indicated. If Lc or
Le is not needed for the described command, the associated length, value and
description are empty.
If both length bytes (Lc and Le) are requested, the described command has to be
split in two parts if the IFD is using protocol T=0: the IFD sends the command
as described with P3=Lc + data and then sends a GET_RESPONSE (see point
3.6.6) command with P3=Le.
If both length bytes are requested, and Le=0 (secure messaging):
— When using protocol T=1, the card shall answer to Le=0 by sending all
available output data.
— When using protocol T=0, the IFD shall send the first command with
P3=Lc + data, the card shall answer (to this implicit Le=0) by the Status
bytes′61La′, where La is the number of response bytes available. The IFD
shall then generate a GET RESPONSE command with P3=La to read the
data.
3.6.1. Select file
This command is compliant with ISO/IEC 7816-4, but has a restricted usage
compared to the command defined in the norm.
The SELECT FILE command is used:
— to select an application DF (selection by name must be used)
— to select an elementary file corresponding to the submitted file ID
3.6.1.1. Selection by name (AID)
This command allows to select an application DF in the card.
This command can be performed from anywhere in the file structure (after the
ATR or at anytime).
The selection of an application resets the current security environment. After
performing the application selection, no current public key is selected anymore
and the former session key is no longer available for secure messaging. The
AUT access condition is also lost.
Command Message
Byte Length Value Description
CLA 1 ′00h′
INS 1 ′A4h′
P1 1 ′04h′ Selection by name (AID)
P2 1 ′0Ch′ No response expected
Lc 1 ′NNh′ Number of bytes sent to the card (length of the
AID):′06h′for the Tachograph application
#6-#(5+NN) NN ′XX..XXh′ AID:′FF 54 41 43 48 4F ′for the Tachograph
application
No response to the SELECT FILE command is needed (Le absent in T=1, or no
response asked in T=0).
Response Message (no response asked)
Byte Length Value Description
SW 2 ′XXXXh′ Status Words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the application corresponding with the AID is not found, the processing
state returned is′6A82′,
— in T=1, if the byte Le is present, the state returned is ′6700′,
— in T=0, if a response is asked after the SELECT FILE command, the state
returned is′6900′,
— if the selected application is considered corrupted (integrity error is detected
within the file attributes), the processing state returned is ′6400′or′6581′.1998R2135 — EN — 25.08.2002 — 001.001 — 103
▼M1
3.6.1.2. Selection of an elementary file using its file identifier
Command Message
Byte Length Value Description
CLA 1 ′00h′
INS 1 ′A4h′
P1 1 ′02h′ Selection of an EF under the current DF
P2 1 ′0Ch′ No response expected
Lc 1 ′02h′ Number of bytes sent to the card
#6-#7 2 ′XXXXh′ File Identifier
No response to the SELECT FILE command is needed (Le absent in T=1, or no
response asked in T=0).
Response Message (no response asked)
Byte Length Value Description
SW 2 ′XXXXh′ Status Words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the file corresponding with the file identifier is not found, the processing
state returned is′6A82′,
— in T=1, if the byte Le is present, the state returned is ′6700′,
— in T=0, if a response is asked after the SELECT FILE command, the state
returned is′6900′,
— if the selected file is considered corrupted (integrity error is detected within
the file attributes), the processing state returned is ′6400′or′6581′.
3.6.2. Read Binary
This command is compliant with ISO/IEC 7816-4, but has a restricted usage
compared to the command defined in the norm.
The Read Binary command is used to read data from a transparent file.The response of the card consists of returning the data read, optionally encapsu-
lated in a secure messaging structure.
The command can be performed only if the security status satisfies the security
attributes defined for the EF for the READ function.
3.6.2.1. Command without secure messaging
This command enables the IFD to read data from the EF currently selected,
without secure messaging.
Reading data from a file marked as ‘Encrypted’ shall not be possible through
this command.
Command Message
Byte Length Value Description
CLA 1 ′00h′ No secure messaging asked
INS 1 ′B0h′
P1 1 ′XXh′ Offset in bytes from the beginning of the file: most
significant byte
P2 1 ′XXh′ Offset in bytes from the beginning of the file: least
significant byte
Le 1 ′XXh′ Length of data expected. number of bytes to be
read1998R2135 — EN — 25.08.2002 — 001.001 — 104
▼M1
Note: bit 8 of P1 must be set to 0.
Response Message
Byte Length Value Description
#1-#X X ′XX..XXh′ Data read
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if no EF is selected, the processing state returned is ′6986′,
— if the Access Control of the selected file are not satisfied, the command is
interrupted with′6982′,
— if the Offset is not compatible with the size of the EF (Offset > EF size), the
processing state returned is ′6B00′,
— if the size of the data to be read is not compatible with the size of the EF
(Offset + Le > EF size) the processing state returned is ′6700′or′6Cxx′,
where′xx′indicates the exact length,
— if an integrity error is detected within the file attributes, the card shall
consider the file as corrupted and unrecoverable, the processing state
returned is′6400′or′6581′,
— if an integrity error is detected within the stored data, the card shall return
the demanded data, and the processing state returned is ′6281′.
3.6.2.2. Command with secure messaging
This command enables the IDF to read data from the EF currently selected with
secure messaging, in order to verify the integrity of the data received and to
protect the confidentiality of the data in the case the EF is marked as
‘Encrypted’.
Command Message
Byte Length Value Description
CLA 1 ′0Ch′ Secure Messaging asked
INS 1 ′B0h′ INS
P1 1 ′XXh′ P1 (offset in bytes from the beginning of the file):
Most Significant Byte
P2 1 ′XXh′ P2 (offset in bytes from the beginning of the file):
Least Significant Byte
Lc 1 ′09h′ Length of input data for secure messaging
#6 1 ′97h′ TLE: Tag for expected length specification
#7 1 ′01h′ LLE: Length of expected length
#8 1 ′NNh′ Expected length specification (original Le):
Number of Bytes to be read
#9 1 ′8Eh′ TCC: Tag for cryptographic checksum
#10 1 ′04h′ LCC: Length of following cryptographic checksum
#11-#14 4 ′XX..XXh′ Cryptographic checksum (4 most significant bytes)
Le 1 ′00h′ As specified in ISO/IEC 7816-4
Response Message if EF is not marked as ‘Encrypted’ and if Secure Messaging
input format is correct:
Byte Length Value Description
#1 1 ′81h′ TPV: Tag for plain value data1998R2135 — EN — 25.08.2002 — 001.001 — 105
▼M1
Byte Length Value Description
#2 L ′NNh′or′81
NNh′LPV: length of returned data (= original Le)
L is 2 bytes if LPV>127 bytes
#(2+L)-#(1+L+NN) NN ′XX..XXh′ Plain Data value
#(2+L+NN) 1 ′8Eh′ TCC: Tag for cryptographic checksum
#(3+L+NN) 1 ′04h′ LCC: Length of following cryptographic
checksum
#(4+L+NN)-
#(7+L+NN)4′XX..XXh′ Cryptographic checksum (4 most significant
bytes)
SW 2 ′XXXXh′ Status Words (SW1, SW2)
Response Message if EF is marked as ‘Encrypted’ and if Secure Messaging
input format is correct:
Byte Length Value Description
#1 1 ′87h′ TPI CG: Tag for encrypted data (cryptogram)
#2 L ′MMh′or′81
MMh′LPI CG: length of returned encrypted data
(different of original Le of the command
due to padding)
L is 2 byte if LPI CG> 127 bytes
#(2+L)-#(1+L+MM) MM ′01XX..XXh′ Encrypted data: padding indicator and cryp-
togram
#(2+L+MM) 1 ′8Eh′ TCC: tag for cryptographic checksum
#(3+L+MM) 1 ′04h′ LCC: length of following cryptographic
checksum
#(4+L+MM)-
#(7+L+MM)4′XX..XXh′ Cryptographic checksum (4 most significant
bytes)
SW 2 ′XXXXh′ Status words (SW1, SW2)
The encrypted data returned contain a first byte indicating the used padding
mode. For the tachograph application, the padding indicator always takes the
value '01h', indicating that the used padding mode is the one specified in ISO/
IEC 7816-4 (one byte with value ′80h′followed by some null bytes: ISO/IEC
9797 method 2).
The ‘regular’ processing states, described for the READ BINARY command
with no secure messaging (see point 3.6.2.1), can be returned using the response
message structures described above, under a ′99h′Tag (as described in TCS
335).
Additionally, some errors specifically related to secure messaging can happen.
In that case, the processing state is simply returned, with no secure messaging
structure involved:
Response Message if incorrect Secure Messaging input format
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If no current session key is available, the processing state ′6A88′is returned.
It happens either if the session key has not already been generated or if the
session key validity has expired (in this case the IFD must re-run a mutual
authentication process to set a new session key).
— If some expected data objects (as specified above) are missing in the secure
messaging format, the processing state ′6987′is returned: this error happens1998R2135 — EN — 25.08.2002 — 001.001 — 106
▼M1
if an expected tag is missing or if the command body is not properly
constructed.
— If some data objects are incorrect, the processing state returned is ′6988′:
this error happens if all the required tags are present but some lengths are
different from the ones expected.
— If the verification of the cryptographic checksum fails, the processing state
returned is′6688′.
3.6.3. Update Binary
This command is compliant with ISO/IEC 7816-4, but has a restricted usage
compared to the command defined in the norm.
The UPDATE BINARY command message initiates the update (erase + write)
of the bits already present in an EF binary with the bits given in the command
APDU.
The command can be performed only if the security status satisfies the security
attributes defined for the EF for the UPDATE function (If the access control of
the UPDATE function includes PRO SM, a secure messaging must be added in
the command).
3.6.3.1. Command without secure messaging
This command enables the IFD to write data into the EF currently selected,
without the card verifying the integrity of data received. This plain mode is
allowed only if the related file is not marked as ‘Encrypted’.
Command Message
Byte Length Value Description
CLA 1 ′00h′ No secure messaging asked
INS 1 ′D6h′
P1 1 ′XXh′ Offset in bytes from the beginning of the file: most
significant byte
P2 1 ′XXh′ Offset in bytes from the beginning of the file: least
significant byte
Lc 1 ′NNh′ Lc length of data to Update. Number of bytes to be
written
#6-#(5+NN) NN ′XX..XXh′ Data to be written
Note: bit 8 of P1 must be set to 0.
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if no EF is selected, the processing state returned is ′6986′,
— if the Access Control of the selected file are not satisfied, the command is
interrupted with′6982′,
— if the Offset is not compatible with the size of the EF (Offset > EF size), the
processing state returned is ′6B00′,
— if the size of the data to be written is not compatible with the size of the EF
(Offset + Le > EF size) the processing state returned is ′6700′,
— if an integrity error is detected within the file attributes, the card shall
consider the file as corrupted and unrecoverable, the processing state
returned is′6400′or′6500′,
— if writing is unsuccessful, the processing state returned is ′6581′.
3.6.3.2. Command with secure messaging
This command enables the IFD to write data into the EF currently selected, with
the card verifying the integrity of data received. As no confidentiality is
required, the data are not encrypted.1998R2135 — EN — 25.08.2002 — 001.001 — 107
▼M1
Command Message
Byte Length Value Description
CLA 1 ′0Ch′ Secure messaging. Asked
INS 1 ′D6h′ INS
P1 1 ′XXh′ Offset in bytes from the beginning of the
file: most significant byte
P2 1 ′XXh′ Offset in bytes from the beginning of the
file: least significant byte
Lc 1 ′XXh′ Length of the secured data field
#6 1 ′81h′ TPV: tag for plain value data
#7 L ′NNh′or′81
NNh′LPV: length of transmitted data
L is 2 bytes if LPV> 127 bytes
#(7+L)-#(6+L+NN) NN ′XX..XXh′ Plain data value (data to be written)
#(7+L+NN) 1 ′8Eh′ TCC: tag for cryptographic checksum
#(8+L+NN) 1 ′04h′ LCC: Length of following cryptographic
checksum
#(9+L+NN)-
#(12+L+NN)4′XX..XXh′ Cryptographic checksum (4 most significant
bytes)
Le 1 ′00h′ As specified in ISO/IEC 7816-4
Response message if correct Secure Messaging input format
Byte Length Value Description
#1 1 ′99h′ TSW: tag for status words (to be protected by CC)
#2 1 ′02h′ LSW: length of returned status words
#3-#4 2 ′XXXXh′ Status words (SW1, SW2)
#5 1 ′8Eh′ TCC: tag for cryptographic checksum
#6 1 ′04h′ LCC: Length of following cryptographic checksum
#7-#10 4 ′XX..XXh′ Cryptographic checksum (4 most significant bytes)
SW 2 ′XXXXh′ Status words (SW1, SW2)
The ‘regular’ processing states, described for the UPDATE BINARY command
with no secure messaging (see point 3.6.3.1), can be returned using the response
message structure described above.
Additionally, some errors specifically related to secure messaging can happen.
In that case, the processing state is simply returned, with no secure messaging
structure involved:
Response Message if error in secure messaging
Byte Length Value Description
SW 2 ′XXXXh′ Status Words (SW1, SW2)
— If no current session key is available, the processing state ′6A88′is returned,
— if some expected data objects (as specified above) are missing in the secure
messaging format, the processing state ′6987′is returned: this error happens1998R2135 — EN — 25.08.2002 — 001.001 — 108
▼M1
if an expected tag is missing or if the command body is not properly
constructed,
— if some data objects are incorrect, the processing state returned is ′6988′:
this error happens if all the required tags are present but some lengths are
different from the ones expected,
— if the verification of the cryptographic checksum fails, the processing state
returned is′6688′.
3.6.4. Get challenge
This command is compliant with ISO/IEC 7816-4, but has a restricted usage
compared to the command defined in the norm.
The GET CHALLENGE command asks the card to issue a challenge in order to
use it in a security related procedure in which a cryptogram or some ciphered
data are sent to the card.
The Challenge issued by the card is only valid for the next command, which
uses a challenge, sent to the card.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′84h′ INS
P1 1 ′00h′ P1
P2 1 ′00h′ P2
Le 1 ′08h′ Le (Length of challenge expected)
Response Message
Byte Length Value Description
#1-#8 8 ′XX..XXh′ Challenge
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if Le is different from ′08h′, the processing state is ′6700′,
— if parameters P1-P2 are incorrect, the processing state is ′6A86′.
3.6.5. Verify
This command is compliant with ISO/IEC 7816-4, but has a restricted usage
compared to the command defined in the norm.
The Verify command initiates the comparison in the card of the CHV (PIN) data
sent from the command with the reference CHV stored in the card.
Note: The PIN entered by the user must be right padded with FFh' bytes up
to a length of 8 bytes by the IFD.
If the command is successful, the rights corresponding to CHV presentation are
opened and the remaining CHV attempt counter is reinitialised.
An unsuccessful comparison is recorded in the card in order to limit the number
of further attempts of the use of the reference CHV.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′20h′ INS
P1 1 ′00h′ P1
P2 1 ′00h′ P2 (the verified CHV is implicitly known)
Lc 1 ′08h′ Length of CHV code transmitted1998R2135 — EN — 25.08.2002 — 001.001 — 109
▼M1
Byte Length Value Description
#6-#13 8 ′XX..XXh′ CHV
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the reference CHV is not found, the processing state returned is ′6A88′,
— if the CHV is blocked, (the remaining attempt counter of the CHV is null),
the processing state returned is ′6983′. Once in that state, the CHV can never
be successfully presented anymore,
— if the comparison is unsuccessful, the remaining attempt Counter is
decreased and the status ′63CX′is returned (X > 0, and X equals the
remaining CHV attempts counter. X = ′F′, the CHV attempts counter is
greater than′F′),
— if the reference CHV is considered corrupted, the processing state returned is
′6400′or′6581′.
3.6.6. Get response
This command is compliant with ISO/IEC 7816-4.
This command (only necessary and available for T=0 Protocol) is used to
transmit prepared data from the card to the interface device (case where a
command had included both Lc and Le).
The GET_RESPONSE command has to be issued immediately after the
command preparing the data, otherwise, the data are lost. After the execution
of the GET_RESPONSE command (except if the error ′61xx′or′6Cxx′occur,
see below), the previously prepared data are no longer available.
Command Message
Byte Length Value Description
CLA 1 ′00h′
INS 1 ′C0h′
P1 1 ′00h′
P2 1 ′00h′
Le 1 ′XXh′ Number of bytes expected
Response Message
Byte Length Value Description
#1-#X X ′XX..XXh′ Data
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′.
— If no data have been prepared by the card, the processing state returned is
′6900′or′6F00′.
— If Le exceeds the number of available bytes or if Le is null, the processing
state returned is′6Cxx′, where′xx′denotes the exact number of available
bytes. In that case, the prepared data are still available for a subsequent
GET_RESPONSE command.
— If Le is not null and is smaller than the number of available bytes, the
required data are sent normally by the card, and the processing state returned
is′61xx′, where′xx′indicates a number of extra bytes still available by a
subsequent GET_RESPONSE command.
— If the command is not supported (protocol T=1), the card returns ′6D00′.1998R2135 — EN — 25.08.2002 — 001.001 — 110
▼M1
3.6.7. PSO: verify certificate
This command is compliant with ISO/IEC 7816-8, but has a restricted usage
compared to the command defined in the norm.
The VERIFY CERTIFICATE command is used by the card to obtain a Public
Key from the outside and to check its validity.
When a VERIFY CERTIFICATE command is successful, the Public Key is
stored for a future use in the Security environment. This key shall be explicitly
set for the use in security related commands (INTERNAL AUTHENTICATE,
EXTERNAL AUTHENTICATE or VERIFY CERTIFICATE) by the MSE
command (see point 3.6.10) using its key identifier.
In any case, the VERIFY CERTIFICATE command uses the public key
previously selected by the MSE command to open the certificate. This public
key must be the one of a Member State or of Europe.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′2Ah′ Perform Security Operation
P1 1 ′00h′ P1
P2 1 ′AEh′ P2: non BER-TLV coded data (concatenation of
data elements)
Lc 1 ′CEh′ Lc: Length of the certificate, 194 bytes
#6-#199 194 ′XX..XXh′ Certificate: concatenation of data elements (as
described in Appendix 11)
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the certificate verification fails, the processing state returned is ′6688′. The
verification and unwrapping process of the certificate is described in
Appendix 11,
— if no Public Key is present in the Security Environment, ′6A88′is returned,
— if the selected public key (used to unwrap the certificate) is considered
corrupted, the processing state returned is ′6400′or′6581′,
— if the selected public key (used to unwrap the certificate) has a CHA.LSB
(Ce rti fica te Holde rAut hori sati on. equ ipm ent Typ e) different from
′00′(i.e. is not the one of a Member State or of Europe), the processing state
returned is′6985′.
3.6.8. Internal authenticate
This command is compliant with ISO/IEC 7816-4.
Using the INTERNAL AUTHENTICATE command, the IFD can authenticate
the card.
The authentication process is described in Appendix 11. It includes the
following statements:
The INTERNAL AUTHENTICATE command uses the card Private Key (impli-
citly selected) to sign authentication data including K1 (first element for session
key agreement) and RND1, and uses the Public Key currently selected (through
the last MSE command) to encrypt the signature and form the authentication
token (more details in Appendix 11).
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′88h′ INS1998R2135 — EN — 25.08.2002 — 001.001 — 111
▼M1
Byte Length Value Description
P1 1 ′00h′ P1
P2 1 ′00h′ P2
Lc 1 ′10h′ Length of data sent to the card
#6-#13 8 ′XX..XXh′ Challenge used to authenticate the card
#14-#21 8 ′XX..XXh′ VU.CHR (see Appendix 11)
Le 1 ′80h′ Length of the data expected from the card
Response Message
Byte Length Value Description
#1-#128 128 ′XX..XXh′ Card authentication token (see Appendix 11)
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if no Public Key is present in the Security Environment, the processing state
returned is′6A88′,
— if no Private Key is present in the Security Environment, the processing state
returned is′6A88′,
— if VU.CHR does not match the current public key identifier, the processing
state returned is′6A88′,
— if the selected private key is considered corrupted, the processing state
returned is′6400′or′6581′.
If the INTERNAL_AUTHENTICATE command is successful, the current
session key, if existing, is erased and no longer available. In order to have a
new session key available, the EXTERNAL_AUTHENTICATE command must
be successfully performed.
3.6.9. External authenticate
This command is compliant with ISO/IEC 7816-4.
Using the EXTERNAL AUTHENTICATE command, the card can authenticate
the IFD.
The authentication process is described in Appendix 11. It includes the
following statements:
A GET CHALLENGE command must precede the EXTERNAL_AUTHENTI-
CATE command immediately. The card issues a challenge to the outside
(RND3).
The verification of the cryptogram uses RND3 (challenge issued by the card),
the card private key (implicitly selected) and the public key previously selected
by the MSE command.
The card verifies the cryptogram, and if it is correct, the AUT access condition
is opened.
The input cryptogram is carries the second element for session key agreement
K2.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′82h′ INS
P1 1 ′00h′ P1
P2 1 ′00h′ P2 (the public key to be used is implicitly known,
and has been previously set by the MSE command)
Lc 1 ′80h′ Lc (Length of the data sent to the card)1998R2135 — EN — 25.08.2002 — 001.001 — 112
▼M1
Byte Length Value Description
#6-#133 128 ′XX..XXh′ Cryptogram (see Appendix 11)
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (status words (SW1, SW2))
— If the command is successful, the card returns ′9000′,
— if no Public Key is present in the Security Environment, ′6A88′is returned,
— if the CHA of the currently set public key is not the concatenation of the
Tachograph application AID and of a VU equipment Type, the processing
state returned is′6F00′(see Appendix 11),
— if no Private Key is present in the Security Environment, the processing state
returned is′6A88′,
— if the verification of the cryptogram is wrong, the processing state returned
is′6688′,
— if the command is not immediately preceded with a GET CHALLENGE
command, the processing state returned is ′6985′,
— if the selected private key is considered corrupted, the processing state
returned is′6400′or′6581′.
If the EXTERNAL AUTHENTICATE command is successful, and if the first
part of the session key is available from a successful INTERNAL AUTHENTI-
CATE recently performed, the session key is set for future commands using
secure messaging.
If the first session key part is not available from a previous INTERNAL
AUTHENTICATE command, the second part of the session key, sent by the
IFD, is not stored in the card. This mechanism ensures that the mutual authenti-
cation process is done in the order specified in Appendix 11.
3.6.10. Manage security environment
This command is used to set a public key for authentication purpose.
This command is compliant with ISO/IEC 7816-8. The use of this command is
restricted regarding the related standard.
The key referenced in the MSE data field is valid for every file of the Tacho-
graph DF.
The key referenced in the MSE data field remains the current public key until
the next correct MSE command.
If the key referenced is not (already) present into the card, the security environ-
ment remains unchanged.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′22h′ INS
P1 1 ′C1h′ P1: referenced key valid for all cryptographic
operations
P2 1 ′B6h′ P2 (referenced data concerning digital signature)
Lc 1 ′0Ah′ Lc: length of subsequent data field
#6 1 ′83h′ Tag for referencing a public key in asymmetric
cases
#7 1 ′08h′ Length of the key reference (key identifier)
#8-#15 08h ′XX..XXh′ Key identifier as specified in Appendix 111998R2135 — EN — 25.08.2002 — 001.001 — 113
▼M1
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the referenced key is not present into the card, the processing state
returned is′6A88′,
— if some expected data objects are missing in the secure messaging format,
the processing state ′6987′is returned. This can happen if the tag ′83h′is
missing,
— if some data objects are incorrect, the processing state returned is ′6988′.
This can happen if the length of the key identifier is not ′08h′,
— if the selected key is considered corrupted, the processing state returned is
′6400′or′6581′.
3.6.11. PSO: hash
This command is used to transfer to the card the result of a hash calculation on
some data. This command is used for the verification of digital signatures. The
hash value is stored in EEPROM for the subsequent command verify digital
signature.
This command is compliant with ISO/IEC 7816-8. The use of this command is
restricted regarding the related standard.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′2Ah′ Perform security operation
P1 1 ′90h′ Return hash code
P2 1 ′A0h′ Tag: data field contains DOs relevant for hashing
Lc 1 ′16h′ Length Lc of the subsequent data field
#6 1 ′90h′ Tag for the hash code
#7 1 ′14h′ Length of the hash code
#8-#27 20 ′XX..XXh′ Hash code
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if some expected data objects (as specified above) are missing, the proces-
sing state′6987′is returned. This can happen if one of the tag ′90h′is
missing,
— if some data objects are incorrect, the processing state returned is ′6988′.
This error happens if the required tag is present but with a length different
from′14h′.
3.6.12. Perform hash of file
This command is not compliant with ISO/IEC 7816-8. Thus the CLA byte of
this command indicates that there is a proprietary use of the PERFORM
SECURITY OPERATION/HASH.
The perform hash file command is used to hash the data area of the currently
selected transparent EF.
The result of the hash operation is stored in the card. It can then be used to get a
digital signature of the file, using the PSO-COMPUTE_DIGITAL_SIGNA-
TURE command. This result remains available for the COMPUTE DIGITAL1998R2135 — EN — 25.08.2002 — 001.001 — 114
▼M1
SIGNATURE command until the next successful PERFORM HASH of FILE
command.
Command Message
Byte Length Value Description
CLA 1 ′80h′ CLA
INS 1 ′2Ah′ Perform security operation
P1 1 ′90h′ Tag: hash
P2 1 ′00h′ P2: hash the data of the currently selected trans-
parent file
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if no application is selected, the processing state ′6985′is returned,
— if the selected EF is considered corrupted (file attributes or stored data integ-
rity errors), the processing state returned is ′6400′or′6581′,
— if the selected file is not a transparent file, the processing state returned is
′6986′.
3.6.13. PSO: compute digital signature
This command is used to compute the digital signature of previously computed
hash code (see PERFORM HASH of FILE, point 3.6.12).
This command is compliant with ISO/IEC 7816-8. The use of this command is
restricted regarding the related standard.
The card private key is used to compute the digital signature and is implicitly
known by the card.
The card performs a digital signature using a padding method compliant with
PKCS1 (see Appendix 11 for details).
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′2Ah′ Perform security operation
P1 1 ′9Eh′ Digital signature to be returned
P2 1 ′9Ah′ Tag: data field contains data to be signed. As no
data field is included, the data are supposed to be
already present in the card (hash of file)
Le 1 ′80h′ Length of the expected signature
Response Message
Byte Length Value Description
#1-#128 128 ′XX..XXh′ Signature of the previously computed hash
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the implicitly selected private key is considered as corrupted, the proces-
sing state returned is ′6400′or′6581′.1998R2135 — EN — 25.08.2002 — 001.001 — 115
▼M1
3.6.14. PSO: verify digital signature
This command is used to verify the digital signature, provided as an input, in
accordance with PKCS1 of a message, whose hash is known to the card. The
signature algorithm is implicitly known by the card.
This command is compliant with ISO/IEC 7816-8. The use of this command is
restricted regarding the related standard.
The Verify Digital Signature command always uses the public key selected by
the previous Manage Security Environment command, and the previous hash
code entered by a PSO: hash command.
Command Message
Byte Length Value Description
CLA 1 ′00h′ CLA
INS 1 ′2Ah′ Perform security operation
P1 1 ′00h′
P2 1 ′A8h′ Tag: data field contains DOs relevant for verifica-
tion
Lc 1 ′83h′ Length Lc of the subsequent data field
#28 1 ′9Eh′ Tag for digital signature
#29-#30 2 ′8180h′ Length of digital signature (128 bytes, coded in
accordance with ISO/IEC 7816-6)
#31-#158 128 ′XX..XXh′ Digital signature content
Response Message
Byte Length Value Description
SW 2 ′XXXXh′ Status words (SW1, SW2)
— If the command is successful, the card returns ′9000′,
— if the verification of the signature fails, the processing state returned is
′6688′. The verification process is described in Appendix 11,
— if no public key is selected, the processing state returned is ′6A88′,
— if some expected data objects (as specified above) are missing, the proces-
sing state′6987′is returned. This can happen if one of the required tag is
missing,
— if no hash code is available to process the command (as a result of a
previous PSO: hash command), the processing state returned is ′6985′,
— if some data objects are incorrect, the processing state returned is ′6988′.
This can happen if one of the required data objects length is incorrect,
— if the selected public key is considered corrupted, the processing state
returned is′6400′or′6581′.
4. TACHOGRAPH CARDS STRUCTURE
This paragraph specifies the file structures of the Tachograph cards for storage
of accessible data,
It does not specify card manufacturer dependant internal structures, such as e.g.
file headers, nor storage and handling of data elements needed for internal use
only such as
EuropeanPublicKey, CardPrivateKey, TDesSessionKey or
WorkshopCardPin.
The useful storage capacity of Tachograph cards shall be of 11 Kbytes
minimum. Greater capacities may be used. In such case, the structure of the
card remains the same, but the number of records of some elements of the struc-
ture is increased. This paragraph specifies minimum and maximum values of
these record numbers.1998R2135 — EN — 25.08.2002 — 001.001 — 116
▼M1
4.1. Driver card structure
After its personalisation, the driver card shall have the following permanent file
structure and file access conditions:
All EFs structures shall be transparent.
Read with secure messaging shall be possible for all files under the DF Tacho-
graph.
The driver card shall have the following data structure:
1998R2135 — EN — 25.08.2002 — 001.001 — 117
▼M1
1998R2135 — EN — 25.08.2002 — 001.001 — 118
▼M1
The following values, used to provide sizes in the table above, are the minimum
and maximum record number values the driver card data structure must use:
Min Max
n1NoOfEventsPerType 6 12
n2NoOfFaultsPerType 12 24
n3NoOfCardVehicleRecords 84 200
n4No OfCa rdPla ce Rec ords 84 112
n6C ardA cti vity Le ngth Ran ge 5 544 bytes
(28 days * 93
activity changes)13 776 bytes
(28 days * 240
activity changes)
4.2. Workshop card structure
After its personalisation, the workshop card shall have the following permanent
file structure and file access conditions:
All EFs structures shall be transparent.
Read with secure messaging shall be possible for all files under the DF Tacho-
graph.
The workshop card shall have the following data structure:
1998R2135 — EN — 25.08.2002 — 001.001 — 119
▼M1
1998R2135 — EN — 25.08.2002 — 001.001 — 120
▼M1
The following values, used to provide sizes in the table above, are the minimum
and maximum record number values the workshop card data structure must use:
Min Max
n1NoOfEventsPerType 3 3
n2NoOfFaultsPerType 6 6
n3NoOfCardVehicleRecords 4 8
n4NoOfCardPlaceRecords 6 8
n5NoOfCalibrationRecords 88 255
n6C ardA cti vity Le ngth Ran ge 198 bytes
(1 day * 93
activity changes)492 bytes
(1 day * 240
activity changes)1998R2135 — EN — 25.08.2002 — 001.001 — 121
▼M1
4.3. Control card structure
After its personalisation, the control card shall have the following permanent file
structure and file access conditions:
All EFs structures shall be transparent.
Read with secure messaging shall be possible for files under the DF Tacho-
graph.
The control card shall have the following data structure:
1998R2135 — EN — 25.08.2002 — 001.001 — 122
▼M1
The following values, used to provide sizes in the table above, are the minimum
and maximum record number values the control card data structure must use:
Min Max
n7NoOfControlActivityRecords 230 520
4.4. Company card structure
After its personalisation, the company card shall have the following permanent
file structure and file access conditions:
All EFs structures shall be transparent.
Read with secure messaging shall be possible for all files under the DF Tacho-
graph.
The company card shall have the following data structure:
1998R2135 — EN — 25.08.2002 — 001.001 — 123
▼M1
The following values, used to provide sizes in the table above, are the minimum
and maximum record number values the company card data structure must use:
Min Max
n8No OfCom pa nyAc tivi tyR eco rds 230 5201998R2135 — EN — 25.08.2002 — 001.001 — 124
▼M1
Appendix 3
PICTOGRAMS1998R2135 — EN — 25.08.2002 — 001.001 — 125
▼M1
The recording equipment may use the following pictograms and pictograms
combinations:
1. BASIC PICTOGRAMS
People Actions Modes of operation
Company Company mode
Controller Control Control mode
Driver Driver Operational mode
Workshop/test station Inspection/calibration Calibration mode
Manufacturer
Activities Duration
Available Current availability period
Driving Continuous driving time
Rest Current rest period
Work Current work period
Break Cumulative break time
Unknown
Equipment Functions
Driver slot
Co-driver slot
Card
Clock
Display Displaying
External storage Downloading
Power supply
Printer/printout Printing
Sensor
Tyre size
Vehicle/vehicle unit
Specific conditions
Out of scope
Ferry/train crossing
Miscellaneous
Events
 Faults
Start of daily work period
 End of daily work period
Location
 Manual entry of driver
activities
Security
 Speed
Time
 Total/summary
Qualifiers
Daily
Weekly
Two weeks
From or to
2. PICTOGRAM COMBINATIONS
Miscellaneous
Control place
Location start of daily
work period
Location end of daily workperiod
From time
 To time
From vehicle
Out of scope begin
 Out of scope end
Cards
Driver card1998R2135 — EN — 25.08.2002 — 001.001 — 126
▼M1
Cards
Company card
Control card
Workshop card
- - - No card
Driving
Crew driving
Driving time for one week
Driving time for two weeks
Printouts
Driver activities from card daily printout
Driver activities from VU daily printout
Events and faults from card printout
Events and faults from VU printout
Technical data printout
Over speeding printout
Events
Insertion of a non valid card
Card conflict
Time overlap
Driving without an appropriate card
Card insertion while driving
Last card session not correctly closed
Over speeding
Power supply interruption
Motion data error
Security breach
Time adjustment (by workshop)
Over speeding controlFaults
Card fault (driver slot)
Card fault (co-driver slot)
Display fault
Downloading fault
Printer fault
Sensor fault
VU internal faultManual entries procedure
Still same daily work period?
End of previous work period?
Confirm or enter location of end of work period
Enter start time
Enter location of start of work period.
Note: Additional pictogram combinations to form printout block or record iden-
tifiers are defined in Appendix 4.1998R2135 — EN — 25.08.2002 — 001.001 — 127
▼M1
Appendix 4
PRINTOUTS
CONTENTS
1. Generalities … .................................................................
2. Data blocks specification … . .....................................................
3. Printout specifications … .........................................................
3.1. Driver activities from card daily printout … .........................................
3.2. Driver activities from VU daily printout … ..........................................
3.3. Events and faults from card printout … . . . ..........................................
3.4. Events and faults from VU printout … . . . ..........................................
3.5. Technical data printout … . . . .....................................................
3.6. Over speeding printout … . . . .....................................................1998R2135 — EN — 25.08.2002 — 001.001 — 128
▼M1
1. GENERALITIES
Each printout is built up by chaining various data blocks, possibly identified
with a block identifier.
A data block contains one or more records, possibly identified with a record
identifier.
When a block identifier immediately precedes a record identifier, the record
identifier is not printed.
In the case where a data item is unknown, or must not be printed for data access
rights reasons, spaces are printed instead.
If the content of a complete line is unknown, or need not to be printed, then the
complete line is omitted.
Numerical data fields are printed right aligned, with a space separator for thou-
sands and millions, and without leading zeros.
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).
2. DATA BLOCKS SPECIFICATION
In this chapter the following format notation conventions have been used:— characters printed in bold denote plain text to be printed (printing remains in
normal characters),
— normal characters denote variables (pictograms or data) to be replaced by
their values for printing,
— variable names have been padded with underscores to show the data item
length available for the variable,
— dates are specified with a ‘dd/mm/yyyy’ (day, month, year) format. A
‘dd.mm.yyyy’ format may also be used,
— the term ‘card identification’ denotes the composition of: the type of card
through a card pictograms combination, the card issuing Member State
code, a forward slash character and the card number with the replacement
index and the renewal index separated with a space:
Printouts shall use the following data blocks and/or data records, in accordancewith the following meanings and formats:
Block or record number
Meaning
1.Date and time at which the document is
printed
2.Type of printout
Block identifier
Printout pictogram combination (see App. 3),
Speed limiting device setting (Over speeding
printout only).
1998R2135 — EN — 25.08.2002 — 001.001 — 129
▼M1
Block or record number
Meaning
3.Card holder identification
Block identifier. P = people pictogram
Card holder surnameCard holder first name(s) (if any)
Card identification
Card expiry date (if any)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.
4.Vehicle identification
Block identifier
(VIN)Registering Member State and VRN.
5.VU identification
Block identifier
VU manufacturer's nameVU part number.
6.Last calibration of the recording equipment
Block identifier
Workshop name
Workshop card identificationDate of the calibration.
7.Last control (by a control officer)
Block identifier
Controller's card identification
Control date, time and typeType of the control: Up to four pictograms.
The type of control can be (a combination) of:
: Card downloading,
 : VU downloading,
: printing,
 : Displaying.
8.Driver activities stored on a card in order
of occurrence
Block identifier
Enquiry date (calendar day subject of the
printout) + Daily card presence counter.
8.1. Period during which the card was not
inserted
8.1a. Record identifier (start of period)
8.1b. Unknown period. Start and end time,
duration
8.1c. Activity manually entered
Activity pictogram, start and end time
(included), duration, rest periods of at least
one hour are tagged with a star.
1998R2135 — EN — 25.08.2002 — 001.001 — 130
▼M1
Block or record number
Meaning
8.2. Card insertion in slot S
Record identifier; S = Slot pictogramVehicle registering Member State and VRN
Vehicle odometer at card insertion.
8.3. Activity (while card was inserted)
Activity pictogram, start and end time
(included), duration, crew status (crew
pictogram if CREW, blanks if SINGLE),
rest periods of at least one hour are tagged
with a star.
8.3a. Specific condition. Time of entry,
specific condition pictogram (or picto-
gram combination).
8.4. Card withdrawal
Vehicle odometer and distance travelled
since last insertion for which odometer is
known.
9.Driver activities stored in a VU per slot in
chronological order
Block identifier
Enquiry date (calendar day subject of the
printout)
Vehicle odometer at 00:00 and 24:00.
10. Activities carried in slot S
Block identifier.
10.1. Period where no card is inserted in slot
S
Record identifier
No Card insertedVehicle odometer at beginning of period.
10.2. Card insertion
Card insertion record identifier
Driver's name
Driver's first nameDriver's Card identification
Driver's card expiry date
Registering MS and VRN of previous
vehicle used
Date and time of card withdrawal from
previous vehicle
Blank line
Vehicle odometer at card insertion, manual
entry of driver activities flag (M if yes,
blank if No).
1998R2135 — EN — 25.08.2002 — 001.001 — 131
▼M1
Block or record number
Meaning
10.3. Activity
Activity pictogram, start and end time
(included), duration, crew status (crew
pictogram if CREW, blanks if SINGLE),
rests of at least one hour are tagged with
a star.
10.3a. Specific condition. Time of entry,
specific condition pictogram (or picto-
gram combination).
10.4. Card withdrawal or End of ‘No Card’
period
Vehicle odometer at card withdrawal or at
end of ‘no card’ period and distance
travelled since insertion, or since beginning
of the ‘No Card’ period.
11. Daily summary
Block identifier.
11.1. VU summary of periods without card in
driver slot
Block identifier.
11.2. VU summary of periods without card in
co-driver slot
Block identifier.
11.3. VU daily summary per driver
Record identifier
Driver's surnameDriver's first name(s)
Driver's card identification.
11.4. Entry of place where a daily work
period begins and/or ends
pi = location begin/end pictogram, time,
country, region,
Odometer.
11.5. Activity totals (from a card)
Total driving duration, distance travelled
Total working and availability durationTotal resting and unknown duration
Total duration of crew activities.
11.6. Activity totals (periods without card
driver slot)
Total driving duration, distance travelled
Total working and availability duration
Total resting duration.
1998R2135 — EN — 25.08.2002 — 001.001 — 132
▼M1
Block or record number
Meaning
11.7. Activity totals (periods without card co-
driver slot)
Total working and availability durationTotal resting duration.
11.8. Activity totals (per driver both slots
included)
Total driving duration, distance travelled
Total driving duration, distance travelled
Total resting durationTotal duration of crew activities
When a daily printout is required for the
current day, daily summary information is
computed with available data at the time
of the printout.
12. Events and/or faults stored on a card
12.1. Block identifier last 5 ‘Events and Faults’
from a card
12.2. Block identifier all recorded ‘Events’ on a
card
12.3. Block identifier all recorded ‘Faults’ on a
card
12.4. Event and/or Fault record
Record identifier
Event/fault pictogram, record purpose, date
time of start,
Additional event/fault code (if any), dura-
tion
Registering Member State & VRN of
vehicle in which the event or fault
occurred.
13. Events and/or faults stored or on-going in
aV U
13.1. Block identifier last 5 ‘Events and Faults’
from VU
13.2. Block identifier all recorded or on-going
‘Events’ in a VU
13.3. Block identifier all recorded or on-going
‘Faults’ in a VU
1998R2135 — EN — 25.08.2002 — 001.001 — 133
▼M1
Block or record number
Meaning
13.4. Event and/or fault record
Record identifier
Event/fault pictogram, record purpose, date
time of start,
Additional event/fault code (if any), No of
similar events this day, duration
Identification of the cards inserted at start
or end of the event or fault (up to 4 lines
without repeating twice the same card
numbers)
Case where no card was insertedThe record purpose (p) is a numerical code
explaining why the event or fault was
recorded, coded in accordance with the
data element EventFaultRecordPurpose.
14. VU Identification
Block identifier
VU manufacturer nameVU manufacturer address
VU part number
VU approval numberVU serial number
VU year of manufacture
VU software version and installation date.
15. Sensor identification
Block identifier
Sensor serial numberSensor approval numberSensor first installation date.
16. Calibration data
Block identifier
16.1. Calibration record
Record identifierWorkshop having performed the calibra-
tion
Workshop addressWorkshop card identification
Workshop card expiry date
Blank lineCalibration date + calibration purpose
VIN
Registering Member State & VRNCharacteristic coefficient of vehicle
Constant of the recording equipment
Effective circumference of wheel tyres
1998R2135 — EN — 25.08.2002 — 001.001 — 134
▼M1
Block or record number
Meaning
Size of tyres mounted
Speed limiting device settingOld and new odometer values
The calibration purpose (p) is a numerical
code explaining why these calibration
parameters were recorded, coded in accor-
dance with the data element Calibration-
Purpose.
17. Time adjustment
Block identifier
17.1. Time adjustment record
Record identifier
Old date and timeNew date and time
Workshop having performed the time
adjustment
Workshop address
Workshop card identification
Workshop card expiry date.
18. Most recent event and Fault recorded in
the VU
Block identifierMost recent event date time
Most recent fault date time.
19. Over speeding control information
Block identifierDate and time of last OVER SPEEDING
CONTROL
Date/time of first over speeding and number
of over speeding events since.
20. Over speeding record
20.1. Block identifier ‘First over speeding after
the last calibration’
20.2. Block identifier ‘The 5 most serious over
the last 365 days’.
20.3. Block identifier ‘The most serious for each
of the last 10 days of occurrence’
1998R2135 — EN — 25.08.2002 — 001.001 — 135
▼M1
Block or record number
Meaning
20.4. Record identifier
Date time and duration
Max and average speeds, No of similar
events this day
Driver's surname
Driver's first name(s)
Driver card identification
20.5. If no over speeding record exists in a
block.
21. Hand-written information
Block identifier
21.1. Control Place
21.2. Controller's signature
21.3. From time21.4. To time
21.5. Driver's signature
‘Hand-written information’ Insert enough
blank lines above a hand-written item, to
be able to actually write the required infor-
mation or to put a signature.
3. PRINTOUT SPECIFICATIONS
In this chapter the following notation conventions have been used:
Print block or record number N
Print block or record number N repeated as many times as neces-
sary
Print blocks or records X and/or Y as needed, and repeating as
many times as necessary
3.1. Driver activities from card daily printout
The driver activities from card daily printout shall be in accordance with the
following format:
Date and time at which the document is printed
Type of printout
Controller identification (if a control card is inserted in the VU)
Driver identification (from card subject of the printout)
Vehicle identification (vehicle from which printout is taken)
VU identification (VU from which printout is taken)
Last calibration of this VU
Last control the inspected driver has been subject to
Driver activities delimiter
Activities of the driver in order of occurrence1998R2135 — EN — 25.08.2002 — 001.001 — 136
▼M1
Daily summary delimiter
Places entered in chronological order
Activity totals
Events or faults from card delimiter
Event/Fault records (Last 5 events or faults stored in the card)
Events or faults from VU delimiter
Event/Fault records (Last 5 events or faults stored or on-going in
the VU)
Control place
Controller's signature
Driver's signature
3.2. Driver activities from VU daily printout
The driver activities from VU daily printout shall be in accordance with the
following format:
Date and time at which the document is printed
Type of printout
Card holder identification (for all cards inserted in VU)
Vehicle identification (vehicle from which printout is taken)
VU identification (VU from which printout is taken)
Last calibration of this VU
Last control on this recording equipment
Driver activities delimiter
Driver slot delimiter (slot 1)
Activities in chronological order (driver slot)
Co-driver slot delimiter (slot 2)
Activities in chronological order (co-driver slot)
Daily summary delimiter
Summary of periods without card in driver slot
Places entered in chronological order
Activity totals
Summary of periods without card in co-driver slot
Places entered in chronological order
Activity totals
Summary of activities for a driver both slots included
Places entered by this driver in chronological order
Activity totals for this driver
Events faults delimiter
Event/Fault records (Last 5 events or faults stored or on-going in
the VU)
Control place
Controller's signature
From time (space available for a driver
without a card to indicate which
periods are relevant to himself)
To time
Driver's signature1998R2135 — EN — 25.08.2002 — 001.001 — 137
▼M1
3.3. Events and faults from card printout
The events and faults from card printout shall be in accordance with the
following format:
Date and time at which the document is printed
Type of printout
Controller identification (if a control card is inserted in the VU)
Driver identification (from card subject of the printout)
Vehicle identification (vehicle from which printout is taken)
Events delimiter
Event records (all events stored on the card)
Faults delimiter
Fault records (all faults stored on the card)
Control place
Controller's signature
Driver's signature
3.4. Events and faults from VU printout
The events and faults from VU printout shall be in accordance with the
following format:
Date and time at which the document is printed
Type of printout
Card holder identification (for all cards inserted in VU)
Vehicle identification (vehicle from which printout is taken)
Events delimiter
Event records (All Events stored or on-going in the VU)
Faults delimiter
Fault records (All Faults stored or on-going in the VU)
Control place
Controller's signature
Driver's signature
3.5. Technical data printout
The technical data printout shall be in accordance with the following format:
Date and time at which the document is printed
Type of printout
Card holder identification (for all cards inserted in VU)
Vehicle identification (vehicle from which printout is taken)
VU identification
Sensor identification
Calibration data delimiter
Calibration records (all records available in chronological order)
Time adjustment delimiter
Time adjustment records (all records available from time adjust-
ment and from calibration data records)
Most recent event and Fault recorded in the VU1998R2135 — EN — 25.08.2002 — 001.001 — 138
▼M1
3.6. Over speeding printout
The over speeding printout shall be in accordance with the following format:
Date and time at which the document is printed
Type of printout
Card holder identification (for all cards inserted in VU)
Vehicle identification (vehicle from which printout is taken)
Over speeding control information
Over speeding data identifier
First over speeding after the last calibration
Over speeding data identifier
The 5 most serious over speeding events over the last 365 days
Over speeding data identifier
The most serious over speeding for each of the last 10 days of
occurrence
Control place
Controller's signature
Driver's signature.1998R2135 — EN — 25.08.2002 — 001.001 — 139
▼M1
Appendix 5
DISPLAY1998R2135 — EN — 25.08.2002 — 001.001 — 140
▼M1
In this appendix the following format notation conventions have been used:
— characters printed in bold denote plain text to be displayed (display remains
in normal character),
— normal characters denote variables (pictograms or data) to be replaced by
their values for displaying:
dd mm yyyy: day, month, year,
hh: hours,mm: minutes,
D: duration pictogram,
EF: event or fault pictograms combination,O: mode of operation pictogram.
The recording equipment shall display data using the following formats:
Data Fo rm a t
Default display
Local time hh:m mMode of operation OInformation related to the driver
Dhhhmm
 hhhmm
Information related to the co-driver
 Dhhhmm
Out of scope condition opened
Warning displayExceeding continuous driving time
hhhmm
 hhhmm
Event or fault EF
Other displays
UTC date UTC
 dd/mm/yyyy
or
UTC
 dd.mm.yyyy
time hh:m mDriver's continuous driving time and cumulative
break time
hhhmm
 hhhmm
Co-driver's continuous driving time and cumula-
tive break time
hhhmm
 hhhmm
Driver's cumulated driving time for the previous
and the current week
hhhhmm
Co-driver's cumulated driving time for the
previous and the current week
hhhhmm1998R2135 — EN — 25.08.2002 — 001.001 — 141
▼M1
Appendix 6
EXTERNAL INTERFACES
CONTENT
1. Hardware … . . .................................................................
1.1. Connector … . .................................................................
1.2. Contact allocation … . ...........................................................
1.3. Block diagram … ...............................................................
2. Downloading Interface … . . . .....................................................
3. Calibration Interface … ..........................................................1998R2135 — EN — 25.08.2002 — 001.001 — 142
▼M1
1. HARDWARE
1.1. Connector
The downloading/calibration connector shall be a six pin connector, accessible
on the front panel without the need to disconnect any part of the recording
equipment, and shall comply with the following drawing (all dimensions in
millimetres):
1998R2135 — EN — 25.08.2002 — 001.001 — 143
▼M1
The following diagram shows a typical six pin mating plug:
1998R2135 — EN — 25.08.2002 — 001.001 — 144
▼M1
1.2. Contact allocation
Contacts shall be allocated in accordance with the following table:
Pin Description Remark
1 Battery minus Connected to the battery minus of the vehicle
2 Data communication K-line (ISO 14 230-1)
3 RxD — Downloading Data input to recording equipment4 Input/output signal Calibration5 Permanent power output The voltage range is specified to be that of the vehicle
power minus 3V to allow for the voltage drop across the
protective circuitry
Output 40 mA
6 TxD — Downloading Data output from recording equipment
1.3. Block diagram
The block diagram shall comply with the following:
2. DOWNLOADING INTERFACEThe downloading interface shall comply to RS232 specifications.The downloading interface shall use one start bit, 8 data bits LSB first, one even
parity bit and 1 stop bit.
Data byte organisation
Start bit: one bit with logic level 0
Data bits: transmitted with LSB first
Parity bit: even parity
Stop bit: one bit with logic level 11998R2135 — EN — 25.08.2002 — 001.001 — 145
▼M1
When numerical data composed by more than one byte are transmitted, the most
significant byte is transmitted first and the least significant byte last.
Transmission baud rates shall be adjustable from 9 600 bps to 115 200 bps.
Transmission shall be achieved at the highest possible transmission speed, the
initial baud rate after a start of communication being set at 9 600 bps.
3. CALIBRATION INTERFACE
The data communication shall comply to ISO 14 230-1 Road vehicles — Diag-
nostic systems — Keyword protocol 2000 — Part 1: Physical layer, First
edition: 1999.
The input/output signal shall comply with the following electrical specification:
Parameter Minimum Typical Maximum Remark
Ulow(in) 1,0 V I = 750 µA
Uhigh(in) 4 V I = 200 µA
Frequency 4 kHzU
low(in) 1,0 V I = 1 mA
Uhigh(out) 4 V I = 1 mA
The input/output signal shall comply with the following timing diagrams:
Sensor signal (out)
Test signal (in)
UTC clock signal (out)
1998R2135 — EN — 25.08.2002 — 001.001 — 146
▼M1
Appendix 7
DATA DOWNLOADING PROTOCOLS
CONTENTS
1. Introduction … . . . .........................................................
1.1. Scope … . . . ..............................................................
1.2. Acronysmus and notations … . . ..............................................
2. VU data downloading … . ...................................................
2.1. Download procedure … . . ...................................................
2.2. Data download protocol … ..................................................
2.2.1. Message structure … .......................................................
2.2.2. Message types … . .........................................................
2.2.2.1. Start communication request (SID 81) … . . . ...................................
2.2.2.2. Positive response start communication (SID C1) … . .............................
2.2.2.3. Start diagnostic session request (SID 10) … . ...................................
2.2.2.4. Positive response start diagnostic (SID 50) … ...................................
2.2.2.5. Link control service (SID 87) … .............................................
2.2.2.6. Link control positive response (SID C7) … . . ...................................
2.2.2.7. Request upload (SID 35) … . . . ..............................................
2.2.2.8. Positive response request upload (SID 75) … ...................................
2.2.2.9. Transfer data request (SID 36) … .............................................
2.2.2.10. Positive response transfer data (SID 76) … . . ...................................
2.2.2.11. Transfer exit request (SID 37) … .............................................
2.2.2.12. Positive response request transfer exit (SID 77) … . . .............................
2.2.2.13. Stop communication request (SID 82) … . . . ...................................
2.2.2.14. Positive response stop communication (SID C2) … . .............................
2.2.2.15. Acknowledge sub message (SID 83) … ........................................
2.2.2.16. Negative response (SID 7F) … . ..............................................
2.2.3. Message flow … . .........................................................
2.2.4. Timing … . . ..............................................................
2.2.5. Error handling … . .........................................................
2.2.5.1. Start communication phase … . . ..............................................
2.2.5.2. Communication phase … . ...................................................
2.2.6. Response message content … . . ..............................................
2.2.6.1. Positive response transfer data overview … . . ...................................
2.2.6.2. Positive response transfer data activities … . . ...................................
2.2.6.3. Positive response transfer data events and faults … . .............................
2.2.6.4. Positive response transfer data detailed speed … . . . .............................
2.2.6.5. Positive response transfer data technical data … .................................
2.3. ESM file storage … ........................................................
3. Tachograph cards downloading protocol … . . ...................................
3.1. Scope … . . . ..............................................................
3.2. Definitions … .............................................................
3.3. Card downloading … .......................................................
3.3.1. Initialisation sequence … . ...................................................1998R2135 — EN — 25.08.2002 — 001.001 — 147
▼M1
3.3.2. Sequence for un-signed data files … . . ........................................
3.3.3. Sequence for signed data files … .............................................
3.3.4. Sequence for resetting the calibration counter … . . . .............................
3.4. Data storage format … . . ...................................................
3.4.1. Introduction … . . . .........................................................
3.4.2. File format … .............................................................
4. Downloading a tachograph card via a vehicle unit … ............................1998R2135 — EN — 25.08.2002 — 001.001 — 148
▼M1
1. INTRODUCTION
This appendix specifies the procedures to follow in order to perform the
different types of data download to an external storage medium, together with
the protocols that must be implemented to assure the correct data transfer and
the full compatibility of the downloaded data format to allow any controller to
inspect these data and be able to control their authenticity and their integrity
before analysing them.
1.1. Scope
Data may be downloaded to an ESM:— from a vehicle unit by an intelligent dedicated equipment (IDE) connected to
the VU,
— from a tachograph card by an IDE fitted with a card interface device (IFD),— from a tachograph card via a vehicle unit by an IDE connected to the VU.
To give the possibility to verify the authenticity and integrity of downloaded
data stored on an ESM, data is downloaded with a signature appended in accor-
dance with Appendix 11 Common Security Mechanisms. The source equipment
(VU or card) identification and its security certificates (Member State and
equipment) are also downloaded. The verifier of the data must possess indepen-
dently a trusted European public key.
Data downloaded during one download session must be stored in the ESM
within one file.
1.2. Acronyms and notations
The following acronyms are used in this appendix:
AID application identifier
ATR answer to reset
CS checksum byte
DF dedicated fileDS_ diagnostic sessionEF elementary fileESM external storage medium
FID file identifier (File ID)
FMT format byte (first byte of message header)ICC integrated circuit cardIDE intelligent dedicated equipment: The equipment used to perform data
downloading to the ESM (e.g. personal computer)
IFD interface deviceKWP keyword protocol 2000LEN length byte (last byte of message header)PPS protocol parameter selectionPSO perform security operation
SID service identifier
SRC source byteTGT target byteTLV tag length valueTREP transfer response parameterTRTP transfer request parameter
VU vehicle unit.1998R2135 — EN — 25.08.2002 — 001.001 — 149
▼M1
2. VU DATA DOWNLOADING
2.1. Download procedure
In order to carry on a VU data download, the operator must perform the
following operations:
— insert his tachograph card inside a card slot of the VU (1),
— connect the IDE to the VU download connector,
— establish the connection between the IDE and the VU,
— select on the IDE the data to download and send the request to the VU,— close the download session.
2.2. Data download protocol
The protocol is structured on a master-slave basis, with the IDE playing the
master role and the VU playing the slave role.
The message structure, types and flow are principally based on the Keyword
Protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Diagnostic systems —
Keyword protocol 2000 — Part 2: Data link layer).
The application layer is principally based on the current draft to date of ISO
14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic services,
version 6 of 22 February 2001).
2.2.1. Message structure
All the messages exchanged between the IDE and the VU are formatted with a
structure consisting of three parts:
— header composed by a format byte (FMT), a target byte (TGT), a source
byte (SRC) and possibly a length byte (LEN),
— data field composed by a service identifier byte (SID) and a variable number
of data bytes, which can include an optional diagnostic session byte (DS_)
or an optional transfer parameter byte (TRTP or TREP).
— checksum composed by a checksum byte (CS).
Header Data field Checksum
FMT TGT SRC LEN SID DATA … … … CS
4 bytes Max 225 bytes 1 byte
The TGT and SRC byte represent the physical address of the recipient and origi-
nator of the message. Values are F0 Hex for the IDE and EE Hex for the VU.
The LEN byte is the length of the data field part.
The checksum byte is the 8 bit sum series modulo 256 of all the bytes of the
message excluding the CS itself.
FMT, SID, DS_, TRTP and TREP bytes are defined later in this document.
In the case where the data to be carried by the message is longer than the space
available in the data field part, the message is actually sent in several submes-
sages. Each submessage bears a header, the same SID, TREP and a 2-byte
submessage counter indicating the submessage number within the total message.
To enable error checking and abort the IDE acknowledges every submessage.
The IDE can accept the submessage, ask for it to be re-transmitted, request the
VU to start again or abort the transmission.
If the last submessage contains exactly 255 bytes in the data field, a final
submessage with an empty (except SID TREP and submessage counter) data
field must be appended to show the end of the message.
Example:
Header SID TREP Message CS
4 Bytes Longer than 255 Bytes1998R2135 — EN — 25.08.2002 — 001.001 — 150
(1) The card inserted will trigger the appropriate access rights to the downloading function
and to the data.
▼M1
Will be transmitted as:
Header SID TREP 00 01 Submessage 1 CS
4 Bytes 255 Bytes
Header SID TREP 00 01 Submessage 2 CS
4 Bytes 255 Bytes
…
Header SID TREP xx yy Submessage n CS
4 Bytes Less than 255 Bytes
or as:
Header SID TREP 00 01 Submessage 1 CS
4 Bytes 255 Bytes
Header SID TREP 00 02 Submessage 2 CS
4 Bytes 255 Bytes
…
Header SID TREP xx yy Submessage n CS
4 Bytes 255 Bytes
Header SID TREP xx yy+1 CS
4 Bytes 4 bytes
2.2.2. Message types
The communication protocol for data download between the VU and the IDE
requires the exchange of eight different message types.
The following table summarises these messages.1998R2135 — EN — 25.08.2002 — 001.001 — 151
▼M1
Message Structure
IDE -> <- VUMaximum 4 bytes
HeaderMaximum 255 bytes
Data1
byte
Chec-kSum
FMT TGT SRC LEN SIDDS_/
TRTPDATA CS
Start communication request 81 EE F0 81 E0
Positive response start commu-
nication 80 F0 EE 03 C1 8F,EA 9B
Start diagnostic session request 80 EE F0 02 10 81 F1
Positive response start diag-
nostic 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 ED38 400 Bd 80 EE F0 04 87 01,01,03 ED57 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 3500,00,00,-
00,00,FF,-
FF,FF,FF 99
Positive response request
upload 80 F0 EE 03 75 00,FF D5
Transfer data request
Overview 80 EE F0 02 36 01 97Activities 80 EE F0 06 36 02 Date CS
Events and faults 80 EE F0 02 36 03 99
Detailed speed 80 EE F0 02 36 04 9ATechnical data 80 EE F0 02 36 05 9BCard download 80 EE F0 02 36 06 9C
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 commu-
nication 80 F0 EE 01 C2 211998R2135 — EN — 25.08.2002 — 001.001 — 152
▼M1
Message Structure
IDE -> <- VUMaximum 4 bytes
HeaderMaximum 255 bytes
Data1
byteChec-kSum
FMT TGT SRC LEN SIDDS_/
TRTPDATA CS
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
Subfunction 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 denotes that nothing is transmitted.
— The term upload (as seen from the IDE) is used for compatibility with ISO 14229. It means the same as down-
load (as seen from the VU).
— Potential 2-byte submessage counters are not shown in this Table.1998R2135 — EN — 25.08.2002 — 001.001 — 153
▼M1
2.2.2.1. Start communication request (SID 81)
This message is issued by the IDE to establish the communication link with the
VU. Initial communications are always performed at 9 600 baud (until baud rate
is eventually changed using the appropriate Link control services).
2.2.2.2. Positive response start communication (SID C1)
This message is issued by the VU to answer positively to a start communication
request. It includes the 2 key bytes ′8F′′EA′indicating that the unit supports
protocol with header including target source and length information.
2.2.2.3. Start diagnostic session request (SID 10)
The start diagnostic session request message is issued by the IDE in order to
request a new diagnostic session with the VU. The sub function 'default session'
(81 Hex) indicates a standard diagnostic session is to be opened.
2.2.2.4. Positive response start diagnostic (SID 50)
The positive response start diagnostic message is sent by the VU to answer posi-
tively to Diagnostic Session Request.
2.2.2.5. Link control service (SID 87)
The link control service is used by the IDE to initiate a change in baud rate.
This takes place in two steps. In step one the IDE proposes the baud rate
change, indicating the new rate. On receipt of a positive message from the VU
the IDE sends out confirmation of the baud rate change to the VU (step two).
The IDE then changes to the new baud rate. After receipt of the confirmation
the VU changes to the new baud rate
2.2.2.6. Link control positive response (SID C7)
The link control positive response is issued by the VU to answer positively to
Link Control Service request (step one). Note that no response is given to the
confirmation request (step two).
2.2.2.7. Request upload (SID 35)
The request upload message is issued by the IDE to specify to the VU that a
download operation is requested. To meet the requirements of ISO14229 data
is included covering address, the size and format details for the data requested.
As these are not known to the IDE prior to a download, the memory address is
set to 0, format is unencrypted and uncompressed and the memory size is set to
the maximum.
2.2.2.8. Positive response request upload (SID 75)
The positive response request upload message is sent by the VU to indicate to
the IDE that the VU is ready to download data. To meet the requirements of
ISO 14229 data is included in this positive response message, indicating to the
IDE that further positive response transfer data messages will include 00FF hex
bytes maximum.
2.2.2.9. Transfer data request (SID 36)
The transfer data request is sent by the IDE to specify to the VU the type of
data that are to be downloaded. A one byte transfer request parameter (TRTP)
indicates the type of transfer.
There are six types of data transfer:
— overview (TRTP 01),
— activities of a specified date (TRTP 02),— events and faults (TRTP 03),— detailed speed (TRTP 04),— technical data (TRTP 05),— card download (TRTP 06).
It is mandatory for the IDE to request the overview data transfer (TRTP 01)
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 signa-
ture).
In the second case (TRTP 02) the transfer data request message includes the
indication of the calendar day T ime Re al form at ) to be do wnloa ded .1998R2135 — EN — 25.08.2002 — 001.001 — 154
▼M1
2.2.2.10. Positive response transfer data (SID 76)
The positive response transfer data is sent by the VU in response to the transfer
data request. The message contains the requested data, with a transfer response
parameter (TREP) corresponding to the TRTP of the request.
In the first case (TREP 01), 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:
— security certificates,
— vehicle identification,
— VU current date and time,— minimum and maximum downloadable date (VU data),
— indication of cards presence in the VU,
— previous download to a company,— company locks,
— previous controls.
2.2.2.11. Request transfer exit (SID 37)
The request transfer exit message is sent by the IDE to inform the VU that the
download session is terminated.
2.2.2.12. Positive response request transfer exit (SID 77)
The positive response request transfer exit message is sent by the VU to
acknowledge the Request Transfer Exit.
2.2.2.13. Stop communication request (SID 82)
The stop communication request message is sent by the IDE to disconnect the
communication link with the VU.
2.2.2.14. Positive response stop communication (SID C2)
The positive response stop communication message is sent by the VU to
acknowledge the stop communication request.
2.2.2.15. Acknowledge submessage (SID 83)
The acknowledge sub message is sent by the IDE to confirm receipt of each part
of a message that is being transmitted as several submessages. The data field
contains the SID received from the VU and a 2-byte code as follows:
— MsgC +1 Acknowledges correct receipt of submessage number MsgC.
Request from the IDE to the VU to send next submessage,
— MsgC indicates a problem with the receipt of submessage number MsgC.
Request from the IDE to the VU to send the submessage again,
— FFFF requests termination of the message.
This can be used by the IDE to end the transmission of the VU message for
any reason.
The last submessage of a message (LEN byte < 255) may be acknowledged
using any of these codes or not acknowledged.
The VU responses that will consist of several sub messages are:
— positive response transfer Data (SID 76)
2.2.2.16. Negative Response (SID 7F)
The negative response message is sent by the VU in response to the above
request messages when the VU cannot satisfy the request. The data fields of
the message contains the SID of the response (7F), the SID of the request, and
a code specifying the reason of the negative response. The following codes are
available:
— 10 general reject
The action cannot be performed for a reason not covered below
— 11 service not supported
The SID of the request is not understood
— 12 sub function not supported
The DS_ or TRTP of the request is not understood, or there are no further
sub messages to be transmitted
— 13 incorrect message length1998R2135 — EN — 25.08.2002 — 001.001 — 155
▼M1
The length of the received message is wrong
— 22 conditions not correct or request sequence error
The required service is not active or the sequence of request messages is not
correct
— 31 request out of range
The request parameter record (data field) is not valid
— 50 upload not accepted
The request cannot be performed (VU in a non appropriate mode of opera-
tion or internal fault of the VU)
— 78 response pending
The action requested cannot be completed in time and the VU is not ready
to accept another request
— FA data not available
The data object of a data transfer request are not available in the VU (e.g. no
card is inserted, …)
2.2.3. Message flow
A typical message flow during a normal data download procedure is the
following:
IDE FE
Start communication request
Positive response
Start diagnostic service request
Positive response
Request upload
Positive response
Transfer data request overview
Positive response transfer
Data request #2
Positive response #1
Acknowledge submessage #1
Positive response #21998R2135 — EN — 25.08.2002 — 001.001 — 156
▼M1
IDE FE
Acknowledge submessage #2
Positive response #m
Acknowledge submessage #m
Positive response (Data field < 255 Bytes)
Acknowledge submessage (optional)
…
Transfer data request #n
Positive response
Request transfer exit
Positive response
Stop communication request
Positive response
2.2.4. Timing
During normal operation the timing parameters shown in the following figure
are relevant:
Figure 1
Message flow, timing
Where:
P1 = Inter byte time for VU response.1998R2135 — EN — 25.08.2002 — 001.001 — 157
▼M1
P2 = Time between end of IDE request and start of VU response, or between
end of IDE acknowledge and start of next VU response.
P3 = Time between end of VU response and start of new IDE request, or
between end of VU response and start of IDE acknowledge, or between
end of IDE request and start of new IDE request if VU fails to respond.
P4 = Inter byte time for IDE request.
P5 = Extended value of P3 for card downloading.
The allowed values for the timing parameters are showed in the following table
(KWP extended timing parameters set, used in case of physical addressing for
faster communication).
Timing
ParameterLower limit
Value (ms)Upper limit value (ms)
P1 0 20
P2 20 1 000 (*)
P3 10 5 000P4 5 20P5 10 20 minutes
(*) If the VU responds with a negative response containing a code meaning ‘request correctly received, response
pending’, this value is extended to the same upper limit value of P3.
2.2.5. Error handling
If an error occurs during the message exchange, the message flow scheme is
modified depending on which equipment has detected the error and on the
message generating the error.
In Figure 2 and Figure 3 the error handling procedures for the VU and the IDE
are respectively shown.
2.2.5.1. Start communication phase
If the IDE detects an error during the Start Communication phase, either by
timing or by the bit stream, then it will wait for a period P3 min before issuing
again the request.
If the VU detects an error in the sequence coming from the IDE, it shall send no
response and wait for another Start Communication Request message within a
period P3 max.
2.2.5.2. Communication phase
Two different error handling areas can be defined:1. The VU detects an IDE transmission error.
For every received message the VU shall detect timing errors, byte format errors
(e.g. start and stop bit violations) and frame errors (wrong number of bytes
received, wrong checksum byte).
If the VU detects one of the above errors, then it sends no response and ignores
the message received.
The VU may detect other errors in the format or content of the received
message (e.g. message not supported) even if the message satisfies the length
and checksum requirements; in such a case, the VU shall respond to the IDE
with a Negative Response message specifying the nature of the error.1998R2135 — EN — 25.08.2002 — 001.001 — 158
▼M1
Figure 2
VU error handling
1998R2135 — EN — 25.08.2002 — 001.001 — 159
▼M1
2. The IDE detects a VU transmission error.
For every received message the IDE shall detect timing errors, byte format
errors (e.g. start and stop bit violations) and frame errors (wrong number of
bytes received, wrong checksum byte).
The IDE shall detect sequence errors, e.g. incorrect sub message counter incre-
ments in successive received messages.
If the IDE detects an error or there was no response from the VU within a
P2max period, the request message will be sent again for a maximum of three
transmissions in total. For the purposes of this error detection a submessage
acknowledge will be considered as a request to the VU.
The IDE shall wait at least for a period of P3min before beginning each trans-
mission; the wait period shall be measured from the last calculated occurrence
of a stop bit after the error was detected.
Figure 3
IDE error handling
1998R2135 — EN — 25.08.2002 — 001.001 — 160
▼M1
2.2.6. Response message content
This paragraph specifies the content of the data fields of the various positive
response messages.
Data elements are defined in Appendix 1 data dictionary.
2.2.6.1. Positive response transfer data overview
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 Hex and appropriate sub message splitting and counting:
1998R2135 — EN — 25.08.2002 — 001.001 — 161
▼M1
2.2.6.2. Positive response transfer data activities
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 Hex and appropriate sub message splitting and counting:
1998R2135 — EN — 25.08.2002 — 001.001 — 162
▼M1
2.2.6.3. Positive response transfer data events and faults
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 Hex and appropriate sub message splitting and counting:
1998R2135 — EN — 25.08.2002 — 001.001 — 163
▼M1
2.2.6.4. Positive response transfer data detailed speed
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 Hex and appropriate sub message splitting and countering:
2.2.6.5. Positive response transfer data technical data
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 Hex and appropriate sub message splitting and counting:
1998R2135 — EN — 25.08.2002 — 001.001 — 164
▼M1
2.3. ESM File storage
When a download session has included a VU data transfer, the IDE shall store
within one physical file all data received from the VU during the download
session within positive response transfer data messages. Data stored excludes
message headers, sub-message counters, empty sub-messages and checksums
but include the SID and TREP (of the first sub-message only if several sub-
messages).
3. TACHOGRAPH CARDS DOWNLOADING PROTOCOL
3.1. Scope
This paragraph describes the direct card data downloading of a tachograph card
to an IDE. The IDE is not part of the secure environment; therefore no authen-
tication between the card and the IDE is performed.
3.2. Definitions
Download session: Each time a download of the ICC data is
performed. The session covers the complete procedure from the reset of the
ICC by an IFD until the deactivation of the ICC (withdraw of the card or next
reset).
Signed data file: A file from the ICC. The file is transferred to the
IFD in plain text. On the ICC the file is hashed and signed and the signature is
transferred to the IFD.
3.3. Card downloading
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,
— 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,
— it is mandatory to download at least the EFs Application_Identification
and ID 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.
— When downloading a driver card, update the LastCardDownload date in EF
Card_Download,
— When downloading a workshop card, reset the calibration counter in EF
Card_Download.
3.3.1. Initialisation sequence
The IDE shall initiate the sequence as follows:
Card Direction IDE/IFD Meaning/Remarks
Hardware reset
ATR
It is optional to use PPS to switch to a higher baudrate as long as the ICC
supports it.
3.3.2. Sequence for unsigned data files
The sequence to download the IC C, IC, C ard_ Cer tifi cat e and CA_C ert i-
fi ca te is as follows:1998R2135 — EN — 25.08.2002 — 001.001 — 165
▼M1
Card Direction IDE/IFD Meaning/Remarks
Select file Select file select by file identi-
fiers
OK
Read Binary If the file contains more data
than the buffer size of the reader
or the card the command has to
be repeated until the complete
file is read.
File data
OK
Store data to ESM according to 3.4, (Data storage
format)
Note: Before selecting the Ca rd_C ert ific at e EF, the Tachograph Application
must be selected (selection by AID).
3.3.3. Sequence for signed data files
The following sequence shall be used for each of the following files that has to
be downloaded with their signature:
Card Direction IDE/IFD Meaning/Remarks
Select File
OK
Perform hash of File Calculates the hash value over
the data content of the selected
file using the prescribed hash
algorithm in accordance with
Appendix 11. This command is
not an ISO-Command.
Calculate hash of
file and store
hash value
temporarily
OK
Read Binary If the file contains more data
than the buffer of the reader or
the card can hold, the command
has to be repeated until the
complete file is read.
File Data
OK
Store received data to ESM according to 3.4, (Data storage
format)
PSO: Compute digital signa-
ture
Perform security
operation
‘compute digital
signature’ using
the temporarily
stored hash value
Signature
OK
Append data to the previous
stored data on the ESMaccording to 3.4, (Data storage
format)1998R2135 — EN — 25.08.2002 — 001.001 — 166
▼M1
3.3.4. Sequence for resetting the calibration counter
The sequence to reset the NoOfC ali brat ion sSinc eDown loa d counter in
the EF Car d_Dow nloa d in a workshop card is the following:
Card Direction IDE/IFD Meaning/Remarks
Select File EF
Card_DownloadSelect by file identifiers
OK
Update Binary
NoOfCalibrationsSince-
Download =′00 00′
Resets card
download number
OK
3.4. Data storage format
3.4.1. Introduction
The downloaded data has to be stored according to the following conditions:— the data shall be stored transparent. This means that the order of the bytes as
well as the order of the bits inside the byte that are transferred from the card
has to be preserved during storage,
— all files of the card downloaded within a download session are stored in one
file on the ESM.
3.4.2. File format
The file format is a concatenation of several TLV objects.
The tag for an EF shall be the FID plus the appendix ‘00’.The tag of an EF's signature shall be the FID of the file plus the appendix ‘01’.
The length is a two byte value. The value defines the number of bytes in the
value field. The value ‘FF FF’ in the length field is reserved for future use.
When a file is not downloaded nothing related to the file shall be stored (no tag
and no zero length).
A signature shall be stored as the next TLV object directly after the TLV object
that contains the data of the file.
Definition Meaning Length
FID (2 Bytes) || ‘00’ Tag for EF (FID) 3 Bytes
FID (2 Bytes) || ‘01’ Tag for Signature of
EF(FID)3 Bytes
xx xx Length of value field 2 Bytes
Example of data in a download file on an ESM:
Tag Length Value
00 0 2 0 0 0 0 11 Data of EF ICC
C 1 0 0 00 0 0 C2 Data of EF Card _Ce rtif ica te
…
05 0 5 0 0 0 A 2 E Data of EF Vehi cle s_Use d1998R2135 — EN — 25.08.2002 — 001.001 — 167
▼M1
Tag Length Value
05 0 5 0 1 0 0 80 Signature of EF Vehi cle s_Used
4. DOWNLOADING A TACHOGRAPH CARD VIA A VEHICLE UNIT
The VU must allow for downloading the content of a driver card inserted to a
connected IDE.
The IDE shall send a ‘transfer data request card download’ message to the VU
to initiate this mode (see 2.2.2.9).
The VU shall then download the whole card, file by file, in accordance with the
card downloading protocol defined in paragraph 3, and forward all data received
from the card to the IDE within the appropriate TLV file format (see 3.4.2) and
encapsulated within a ‘positive response transfer data’ message.
The IDE shall retrieve card data from the ‘positive response transfer data’
message (stripping all headers, SIDs, TREPs, submessage counters, and check-
sums) and store them within one physical file as described in paragraph 2.3.
The VU shall then, as applicable, update the Cont rol _Act ivit y_Da ta or the
C ard_ Downl oad file of the driver card.1998R2135 — EN — 25.08.2002 — 001.001 — 168
▼M1
Appendix 8
CALIBRATION PROTOCOL
CONTENTS
1. Introduction … . ..............................................................
2. Terms, Definitions and References … ............................................
3. Overview of services … .......................................................
3.1. Services available … . . ........................................................
3.2. Response codes … ............................................................
4. Communication Services … . ...................................................
4.1. StartCommunication Service … .................................................
4.2. StopCommunication Service … .................................................
4.2.1. Message description … ........................................................
4.2.2. Message format … ............................................................
4.2.3. Parameter Definition … ........................................................
4.3. TesterPresent Service … .......................................................
4.3.1. Message description … ........................................................
4.3.2. Message format … ............................................................
5. Management Services … .......................................................
5.1. StartDiagnosticSession service … . . . .............................................
5.1.1. Message description … ........................................................
5.1.2. Message format … ............................................................
5.1.3. Parameter definition … ........................................................
5.2. SecurityAccess service … . . . ...................................................
5.2.1. Message description … ........................................................
5.2.2. Message format — SecurityAccess — requestSeed … . . . ............................
5.2.3. Message format — SecurityAccess — sendKey … ..................................
6. Data Transmission Services … ..................................................
6.1. DataByIdentifier service … . . ...................................................
6.1.1. Message description … ........................................................
6.1.2. Message format … ............................................................
6.1.3. Parameter Definition … ........................................................
6.2. WriteDataByIdentifier service … . . . .............................................
6.2.1 Message description … ........................................................
6.2.2. Message format … ............................................................
6.2.3. Parameter definition … ........................................................
7. Control of Test Pulses — Input/Output Control functional unit … .....................
7.1. InputOutputControlByIdentifier service … . . .......................................
7.1.1. Message description … ........................................................
7.1.2. Message format … ............................................................
7.1.3. Parameter definition … ........................................................
8. dataRecords formats … ........................................................
8.1. Transmitted parameter ranges … . . . .............................................
8.2. dataRecords formats … ........................................................1998R2135 — EN — 25.08.2002 — 001.001 — 169
▼M1
1. INTRODUCTION
This appendix describes how data is exchanged between a vehicle unit and a
tester via the K-line which forms part of the calibration interface described in
Appendix 6. It also describes control of the input/output signal line on the cali-
bration connector.
Establishing K-line communications is described in Section 4 ‘Communication
Services’.
This appendix uses the idea of diagnostic ‘sessions’ to determine the scope of
K-line control under different conditions. The default session is the ‘Standard-
DiagnosticSession’ where all data can be read from a vehicle unit but no data
can be written to a vehicle unit.
Selection of the diagnostic session is described in Section 5 ‘Management
Services’.
The ‘ECUProgrammingSession’ allows data entry into the vehicle unit. In the
case of entry of calibration data (requirements 097 and 098), the vehicle unit
must, in addition be in the CALIBRATION mode of operation.
Data transfer via K-line is described in Section 6 ‘Data Transmission Services’.
Formats of data transferred are detailed in Section 8 ‘dataRecords formats’.
The ‘ECUAdjustmentSession’ allows the selection of the I/O mode of the cali-
bration I/O signal line via the K-line interface. Control of the calibration I/O
signal line is described in section 7 ‘Control of Test Pulses — Input/Output
Control functional unit’.
Throughout this document the address of the tester is referred to as ′tt′.
Although there may be preferred addresses for testers, the VU shall respond
correctly to any tester address. The physical address of the VU is 0xEE.
2. TERMS, DEFINITIONS AND REFERENCES
The protocols, messages and error codes are principally based on the current
draft to date of ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1:
Diagnostic services, version 6 of 22 February 2001).
Byte encoding and hexadecimal values are used for the service identifiers, the
service requests and responses, and the standard parameters.
The term ‘tester’ refers to the equipment used to enter programming/calibration
data into the VU.
The terms ‘client’ and ‘server’ refer to the tester and the VU respectively.The term ECU means ‘Electronic Control Unit’ and refers to the VU.References:
ISO 14230-2: Road Vehicles — Diagnostic Systems — Keyword Protocol
2000- Part 2: Data Link Layer. First edition: 1999. Vehicles —
Diagnostic Systems.
3. OVERVIEW OF SERVICES3.1. Services available
The following table provides an overview of the services that will be available
in the recording equipment and are defined in this document.
The table indicates the services that are available in an enabled diagnostic
session.
— The first column lists the services that are available,
— the second column includes the section number in this appendix where of
service is further defined,
— the third column assigns the assigns the service identifier values for request
messages,
— the fourth column specifies the services of the ‘StandardDiagnosticSession’
(SD) which must be implemented in each VU,
— the fifth column specifies the services of the ‘ECUAdjustmentSession’
(ECUAS) which must be implemented to allow control of the I/O signal
line in the front panel calibration connector of the VU,
— the sixth column specifies the services of the ‘ECUProgrammingSession’
(ECUPS) which must be implemented to allow for programming of para-
meters in the VU.1998R2135 — EN — 25.08.2002 — 001.001 — 170
▼M1
Table 1
Service Identifier value summary table
Diagnostic Service Name Section NoSId
Req.ValueDiagnostic Sessions
SD ECUAS ECUPS
StartCommunication 4.1 81
StopCommunication 4.2 82TesterPresent 4.3 3EStartDiagnosticSession 5.1 10
SecurityAccess 5.2 27
ReadDataByIdentifier 6.1 22WriteDataByIdentifier 6.2 2EInputOutputControlByI-
dentifier7.1 2F
This symbol indicates that the service is mandatory in this diagnostic session.No symbol indicates that this service is
not allowed in this diagnostic session.
3.2. Response codes
Response codes are defined for each service.
4. COMMUNICATION SERVICES
Some services are necessary to establish and maintain communication. They do
not appear on the application layer. The services available are detailed in the
following table:
Table 2
Communication services
Service name Description
StartCommunication The client requests to start a communication session with a server(s)
StopCommunication The client requests to stop the current communication session
TesterPresent The client indicates to the server that it is still present
The StartCommunication Service is used for starting a communication. In order
to perform any service, communication must be initialised and the communica-
tion parameters need to be appropriate for the desired mode.
4.1. StartCommunication Service
Upon receiving a StartCommunication indication primitive, the VU shall check
if the requested communication link can be initialised under the present condi-
tions. Valid conditions for the initialisation of a communication link are
described in document ISO 14230-2.
Then the VU shall perform all actions necessary to initialise the communication
link and send a StartCommunication response primitive with the positive
response parameters selected.
If a VU that is already initialised (and has entered any diagnostic session)
receives a new StartCommunication request (e.g. due to error recovery in the
tester) the request shall be accepted and the VU shall be re-initialised.
If the communication link cannot be initialised for any reason, the VU shall
continue operating as it was immediately prior to the attempt to initialise the
communication link.
The StartCommunication Request message must be physically addressed.1998R2135 — EN — 25.08.2002 — 001.001 — 171
▼M1
Initialising the VU for services is performed through a ‘fast initialisation’
method,
— there is a bus-idle time prior to any activity,
— the tester then sends an initialisation pattern,— all information which is necessary to establish communication is contained
in the response of the VU.
After completion of the initialisation,
— all communication parameters are set to values defined in Table 4 according
to the key bytes,
— the VU is waiting for the first request of the tester,— the VU is in the default diagnostic mode, i.e. StandardDiagnosticSession,— the calibration I/O signal line is in the default state, i.e. disabled state.
The data rate on the K-line shall be 10 400 Baud.
The fast initialisation is started by the tester transmitting a wake-up pattern
(Wup) on the K-line. The pattern begins after the idle time on K-line with a
low time of Tinil. The tester transmits the first bit of the StartCommunication
Service after a time of Twup following the first falling edge.
The timing values for the fast initialisation and communications in general are
detailed in the tables below. There are different possibilities for the idle time:
— first transmission after power on, Tidle= 300 ms.
— after completion of a StopCommunication Service, Tidle= P3 min.
— after stopping communication by time-out P3 max, Tidle=O .
Table 3
Timing values for fast initialisation
Parameter minimum value maximum value
Tinil 25 ± 1 ms 24 ms 26 ms
Twup 50 ± 1 ms 49 ms 51 ms
Table 4
Communication timing values
Timing para-
meterParameter descriptionLower limit
values (ms)Upper limit
values (ms)
minimum maximum
P1 Inter byte time for VU response 0 20
P2 Time between tester request and VU response or
two VU responses25 250
P3 Time between end of VU responses and start of
new tester request55 5 000
P4 Inter byte time for tester request 5 20
The message format for fast initialisation is detailed in the following tables:1998R2135 — EN — 25.08.2002 — 001.001 — 172
▼M1
Table 5
StartCommunication request message
Byte # Parameter Name Hex value Mnemonic
#1 Format byte — physical addressing 81 FMT
#2 Target address byte EE TGT
#3 Source address byte tt SRC
#4 StartCommunication Request Service 81 SCR#5 Checksum 00-FF CS
Table 6
StartCommunication 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 03 LEN#5 StartCommunication Positive Response Service
IdC1 SCRPR
#6 Key byte 1 EA KB1
#7 Key byte 2 8F KB2#8 Checksum 00-FF CS
There is no negative response to the StartCommunication Request message, if
there is no positive response message to be transmitted then the VU is not initi-
alised, nothing is transmitted and it remains in its normal operation.
4.2. StopCommunication service
4.2.1. Message description
The purpose of this communication layer service is to terminate a communica-
tion session.
Upon receiving a StopCommunication indication primitive, the VU shall check
if the current conditions allow to terminate this communication. In this case the
VU shall perform all actions necessary to terminate this communication.
If it is possible to terminate the communication, the VU shall issue a StopCom-
munication response primitive with the Positive Response parameters selected,
before the communication is terminated.
If the communication cannot be terminated by any reason, the VU shall issue a
StopCommunication response primitive with the Negative Response parameter
selected.
If time -out of P3max is detected by the VU, the communication shall be termi-
nated without any response primitive being issued.
4.2.2. Message format
The message formats for the StopCommunication primitives are detailed in the
following tables:1998R2135 — EN — 25.08.2002 — 001.001 — 173
▼M1
Table 7
StopCommunication request message
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 01 LEN#5 StopCommunication Request Service Id 82 SPR#6 Checksum 00-FF CS
Table 8
StopCommunication 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 01 LEN#5 StopCommunication Positive Response Service C2 SPRPR#6 Checksum 00-FF CS
Table 9
StopCommunication 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 negative Response Service Id 7F NR
#6 StopCommunication Request Service Identifica-
tion82 SPR
#7 responseCode = generalReject 10 RC_GR
#8 Checksum 00-FF CS
4.2.3. Parameter definition
This service does not require any parameter definition.1998R2135 — EN — 25.08.2002 — 001.001 — 174
▼M1
4.3. TesterPresent service
4.3.1. Message description
The TesterPresent service is used by the tester to indicate to the server that it is
still present, in order to prevent the server from automatically returning to
normal operation and possibly stopping the communication. This service, sent
periodically, keeps the diagnostic session/communication active by resetting the
P3 timer each time a request for this service is received.
4.3.2. Message format
The message formats for the TesterPresent primitives are detailed in the
following tables.
Table 10
TesterPresent request message
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 02 LEN
#5 TesterPresent Request Service Id 3E TP
#6 Sub Function = responseRequired = [yes 01 RESPREQ_-
Y
no] 02 RESPREQ_-
NO
#7 Checksum 00-FF CS
If the responseRequired parameter is set to ‘yes’, then the server shall respond
with the following positive response message. If set to ‘no’, then no response is
sent by the server.
Table 11
TesterPresent 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 01 LEN
#5 TesterPresent Positive Response Service Id 7E TPPR#6 Checksum 00-FF CS
The service shall support the following negative responses codes:
Table 12
TesterPresent negative response message
Byte # Parameter Name Hex value Mnemonic
#1 Format byte — physical addressing 80 FMT
#2 Target address byte tt TGT1998R2135 — EN — 25.08.2002 — 001.001 — 175
▼M1
Byte # Parameter Name Hex value Mnemonic
#3 Source address byte EE SRC
#4 Additional length byte 03 LEN#5 negative Response Service Id 7F NR
#6 TesterPresent Request Service Identification 3E TP
#7 responseCode = [SubFunctionNotSupported-
InvalidFormat12 RC_SFNS_-
IF
incorrectMessageLength] 13 RC_IML
#8 Checksum 00-FF CS
5. MANAGEMENT SERVICES
The services available are detailed in the following table:
Table 13
Management services
Service name Description
StartDiagnosticSession The client requests to start a diagnostic session with a VU
SecurityAccess The client requests access to functions restricted to authorised users
5.1. StartDiagnosticSession service
5.1.1. Message description
The service StartDiagnosticSession is used to enable different diagnostic
sessions in the server. A diagnostic session enables a specific set of services
according to Table 17. A session can enable vehicle manufacturer specific
services which are not part of this document. Implementation rules shall
conform to the following requirements:
— there shall be always exactly one diagnostic session active in the VU,
— the VU shall always start the StandardDiagnosticSession when powered up.
If no other diagnostic session is started, then the StandardDiagnosticSession
shall be running as long as the VU is powered,
— if a diagnostic session which is already running has been requested by the
tester, then the VU shall send a positive response message,
— whenever the tester requests a new diagnostic session, the VU shall first
send a StartDiagnosticSession positive response message before the new
session becomes active in the VU. If the VU is not able to start the
requested new diagnostic session, then it shall respond with a StartDiagnos-
ticSession negative response message, and the current session shall continue.
The diagnostic session shall only be started if communication has been estab-
lished between the client and the VU.
The timing parameters defined in Table 4 shall be active after a successful Start-
DiagnosticSession with the diagnosticSession parameter set to
‘StandardDiagnosticSession’ in the request message if another diagnostic session
was previously active.1998R2135 — EN — 25.08.2002 — 001.001 — 176
▼M1
5.1.2. Message format
The message formats for the StartDiagnosticSession primitives are detailed in
the following tables:
Table 14
StartDiagnosticSession request message
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 02 LEN#5 StartDiagnosticSession request service Id 10 STDS
#6 diagnosticSession = (one value from Table 17) xx DS_ …
#7 Checksum 00-FF CS
Table 15
StartDiagnosticSession 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 02 LEN#5 StartDiagnosticSession Positive Response
Service Id50 STDSPR
#6 DiagnosticSession = (same value as in byte #6
Table 14)xx DS_ …
#7 Checksum 00-FF CS
Table 16
StartDiagnosticSession 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 Negative response service Id 7F NR1998R2135 — EN — 25.08.2002 — 001.001 — 177
▼M1
Byte # Parameter Name Hex value Mnemonic
#6 StartDiagnosticSession request service Id 10 STDS
#7 ResponseCode = (subFunctionNotSupported (a) 12 RC_SFNS
incorrectMessageLength (b) 13 RC_IML
conditionsNotCorrect (c)) 22 RC_CNC
#8 Checksum 00-FF CS
(a) The value inserted in byte #6 of the request message is not supported, i.e. not in Table 17.
(b) The length of the message is wrong.
(c) The criteria for the request StartDiagnosticSession are not met.
5.1.3. Parameter definition
The parameter diagnosticSession (DS_) is used by the StartDiagnosticSession
service to select the specific behaviour of the server(s). The following diagnostic
sessions are specified in this document:
Table 17
Definition of diagnosticSession values
Hex Description Mnemonic
81 StandardDiagnosticSession
This diagnostic session enables all services specified in Table 1
column 4 ‘SD’. These services allow reading of data from a server
(VU). This diagnostic Session is active after the initialisation has
been successfully completed between client (tester) and server
(VU). This diagnostic session may be overwritten by other diag-
nostic sessions specified in this section.SD
85 ECUProgrammingSession
This diagnostic session enables all services specified in Table 1
column 6 ‘ECUPS’. These services support the memory program-
ming of a server (VU) This diagnostic session may be overwritten
by other diagnostic sessions specified in this section.ECUPS
87 ECUAdjustmentSession
This diagnostic session enables all services specified in Table 1
column 5 ‘ECUAS’. These services support the input/output
control of a server (VU). This diagnostic session may be over-
written by other diagnostic sessions specified in this section.ECUAS
5.2. SecurityAccess service
Writing of calibration data or access to the calibration input/output line is not
possible unless the VU is in CALIBRATION mode. In addition to insertion of
a valid workshop card into the VU, it is necessary to enter the appropriate PIN
into the VU before access to the CALIBRATION mode is granted.
The SecurityAccess service provides a means to enter the PIN and to indicate to
the tester whether or not the VU is in CALIBRATION mode.
It is acceptable that the PIN may be entered through alternative methods.
5.2.1. Message description
The SecurityAccess service consists of a SecurityAccess ‘requestSeed’ message,
eventually followed by a SecurityAccess ‘sendKey’ message. The SecurityAc-
cess service must be carried out after the StartDiagnosticSession service.
The tester shall use the SecurityAccess "requestSeed" message to check if the
vehicle unit is ready to accept a PIN.
If the vehicle unit is already in CALIBRATION mode, it shall answer the
request by sending a ‘seed’ of 0x0000 using the service SecurityAccess Positive
Response.1998R2135 — EN — 25.08.2002 — 001.001 — 178
▼M1
If the vehicle unit is ready to accept a PIN for verification by a workshop card,
it shall answer the request by sending a ‘seed’ greater than 0x0000 using the
service SecurityAccess positive response.
If the vehicle unit is not ready to accept a PIN from the tester, either because
the workshop card inserted is not valid, or because no workshop card has been
inserted, or because the vehicle unit expects the PIN from another method, it
shall answer the request with a negative response with a response code set to
conditionsNotCorrectOrRequestSequenceError.
The tester shall then, eventually, use the SecurityAccess ‘sendKey’ message to
forward a PIN to the Vehicle Unit. To allow time for the card authentication
process to take place, the VU shall use the negative response code requestCor-
rectlyReceived-ResponsePending to extend the time to respond. However, the
maximum time to respond shall not exceed five minutes. As soon as the
requested service has been completed, the VU shall send a positive response
message or negative response message with a response code different from this
one. The negative response code requestCorrectlyReceived-ResponsePending
may be repeated by the VU until the requested service is completed and the
final response message is sent.
The vehicle unit shall answer to this request using the service SecurityAccess
Positive Response only when in CALIBRATION mode.
In the following cases, the vehicle unit shall answer to this request with a Nega-
tive Response with a response code set to:
— subFunctionNot supported: invalid format for the subfunction parameter
(accessType),
— conditionsNotCorrectOrRequestSequenceError: vehicle unit not ready to
accept a PIN entry,
— invalidKey: PIN not valid and number of PIN checks attempts not exceeded,
— exceededNumberOfAttempts: PIN not valid and number of PIN checks
attempts exceeded,
— generalReject: Correct PIN but mutual authentication with workshop card
failed.
5.2.2. Message format — SecurityAccess — requestSeed
The message formats for the SecurityAccess ‘requestSeed’ primitives are
detailed in the following tables:
Table 18
SecurityAccess request — requestSeed message
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 02 LEN#5 SecurityAccess request service Id 27 SA
#6 accessType — requestSeed 7D AT_RSD
#7 Checksum 00-FF CS
Table 19
SecurityAccess — requestSeed 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 04 LEN1998R2135 — EN — 25.08.2002 — 001.001 — 179
▼M1
Byte # Parameter Name Hex value Mnemonic
#5 SecurityAccess positive response service Id 67 SAPR
#6 accessType — requestSeed 7D AT_RSD#7 Seed High 00-FF SEEDH
#8 Seed Low 00-FF SEEDL
#9 Checksum 00-FF CS
Table 20
SecurityAccess 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 SecurityAccess request service Id 27 SA
#7 responseCode = (conditionsNotCorrectOrRequest-
SequenceError22 RC_CNC
incorrectMessageLength) 13 RC_IML
#8 Checksum 00-FF CS
5.2.3. Message format — SecurityAccess — sendKey
The message formats for the SecurityAccess ‘sendKey’ primitives are detailed
in the following tables:
Table 21
SecurityAccess request — sendKey message
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 m+2 LEN
#5 SecurityAccess Request Service Id 27 SA
#6 accessType — sendKey 7E AT_SK
#7 to #m+6 Key #1 (High) xx KEY
……
Key #m (low, m must be a minimum of 4, and a
maximum of 8)xx
#m+7 Checksum 00-FF CS1998R2135 — EN — 25.08.2002 — 001.001 — 180
▼M1
Table 22
SecurityAccess — sendKey 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 02 LEN
#5 SecurityAccess positive response service Id 67 SAPR
#6 accessType — sendKey 7E AT_SK#7 Checksum 00-FF CS
Table 23
SecurityAccess 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 SecurityAccess request service Id 27 SA
#7 ResponseCode = (generalReject 10 RC_GR
subFunctionNotSupported 12 RC_SFNS
incorrectMessageLength 13 RC_IMLconditionsNotCorrectOrRe-
questSequenceError22 RC_CNC
invalidKey 35 RC_IK
exceededNumberOfAttempts 36 RC_ENA
requestCorrectlyReceived-
ResponsePending)78 RC_RCR_-
RP
#8 Checksum 00-FF CS
6. DATA TRANSMISSION SERVICES
The services available are detailed in the following table:
Table 24
Data transmission services
Service name Description
ReadDataByIdentifier The client requests the transmission of the current value of a record
with access by recordDataIdentifier1998R2135 — EN — 25.08.2002 — 001.001 — 181
▼M1
Service name Description
WriteDataByIdentifier The client requests to write a record accessed by recordDataIdentifier
6.1. ReadDataByIdentifier service
6.1.1. Message description
The ReadDataByIdentifier service is used by the client to request data record
values from a server. The data are identified by a recordDataIdentifier. It is the
VU manufacturer's responsibility that the server conditions are met when
performing this service.
6.1.2. Message format
The message formats for the ReadDataByIdentifier primitives are detailed in the
following tables:
Table 25
ReadDataByIdentifier request message
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 03 LEN
#5 ReadDataByIdentifier Request Service Id 22 RDBI
#6 and #7 recordDataIdentifier = (a valor from Table 28) xxxx RDI_ …
#8 Checksum 00-FF CS
Table 26
ReadDataByIdentifier 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 m+3 LEN#5 ReadDataByIdentifier Positive Response Service
Id62 RDBIPR
#6 and #7 recordDataIdentifier = (the same value as bytes
#6 and #7 Table 25)xxxx RDI_ …
#8 to #m+7 dataRecord() = (data#1 xx DREC_-
DATA1
:: :data#m) xx DREC_-
DATAm
#m+8 Checksum 00-FF CS1998R2135 — EN — 25.08.2002 — 001.001 — 182
▼M1
Table 27
ReadDataByIdentifier 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 ReadDataByIdentifier Request Service Id 22 RDBI#7 ResponseCode = (requestOutOfRange 31 RC_ROOR
incorrectMessageLength 13 RC_IMLconditionsNotCorrect) 22 RC_CNC
#8 Checksum 00-FF CS
6.1.3. Parameter definition
The parameter recordDataIdentifier (RDI_) in the ReadDataByIdentifier request
message identifies a data record.
recordDataIdentifier values defined by this document are shown in the table
below.
The recordDataIdentifier table consists of four columns and multiple lines.— The first column (Hex) includes the ‘hex value’ assigned to the recordDataI-
dentifier specified in the third column.
— The second column (Data element) specifies the data element of Appendix 1
on which the recordDataIdentifier is based (transcoding is sometimes neces-
sary).
— The third column (Description) specifies the corresponding recordDataIden-
tifier name.
— The fourth column (Mnemonic) specifies the mnemonic of this recordDataI-
dentifier.
Table 28
Definition of recordDataIdentifier values
Hex Data elementrecordDataIdentifier Name
(see format in Section 8.2)Mnemonic
F90B Cur rent Dat eTi me TimeDate RDI_TD
F912 Hig hRe sOdom ete r HighResolutionTotalVehicleDis-
tanceRDI_HRT-
VD
F918 K-C onsta ntOf Rec ordi ngE-
quipmentKfactor RDI_KF
F91C L- Tyre Cir cum fere nce LfactorTyreCircumference RDI_LF
F91D W -Vehi cle Cha rac ter isti c-
ConstantWvehicleCharacteristicFactor RDI_WVCF
F921 Ty reSi ze TyreSize RDI_TS
F922 ne xtCa lib rat ionD ate NextCalibrationDate RDI_NCD
F92C Spe edAu thor ised SpeedAuthorised RDI_SA1998R2135 — EN — 25.08.2002 — 001.001 — 183
▼M1
Hex Data elementrecordDataIdentifier Name
(see format in Section 8.2)Mnemonic
F97D ve hic leR egist rat ion Nati on RegisteringMemberState RDI_RMS
F97E Veh icl eRe gist rat ion-
NumberVehicleRegistrationNumber RDI_VRN
F190 Veh icl eId enti fic ati on-
NumberVIN RDI_VIN
The parameter dataRecord (DREC_) is used by the ReadDataByIdentifier posi-
tive response message to provide the data record value identified by the
recordDataIdentifier to the client (tester). Data formats are specified in Section
8. Additional user optional dataRecords including VU specific input, internal
and output data may be implemented, but are not defined in this document.
6.2. WriteDataByIdentifier service
6.2.1. Message description
The WriteDataByIdentifier service is used by the client to write data record
values to a server. The data are identified by a recordDataIdentifier. It is the
VU manufacturer's responsibility that the server conditions are met when
performing this service. To update the parameters listed in Table 28 the VU
must be in CALIBRATION mode.
6.2.2. Message format
The message formats for the WriteDataByIdentifier primitives are detailed in the
following tables:
Table 29
WriteDataByIdentifier request message
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 m+3 LEN
#5 WriteDataByIdentifier request service Id 2E WDBI
#6 and #7 recordDataIdentifier = (a value from Table 28) xxxx RDI_ …
#8 to #m+7 dataRecord() = (data#1 xx DREC_-
DATA1
:: :
data#m) xx DREC_-
DATAm
#m+8 Checksum 00-FF CS
Table 30
WriteDataByIdentifier positive response message
Byte # Parameter Name Hex value Mnemonic
#1 Format byte — physical addressing 80 FMT
#2 Target address byte tt TGT1998R2135 — EN — 25.08.2002 — 001.001 — 184
▼M1
Byte # Parameter Name Hex value Mnemonic
#3 Source address byte EE SRC
#4 Additional length byte 03 LEN#5 WriteDataByIdentifier positive response service
Id6E WDBIPR
#6 and #7 recordDataIdentifier = (the same value as bytes
#6 and #7 Table 29)xxxx RDI_ …
#8 Checksum 00-FF CS
Table 31
WriteDataByIdentifier 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 WriteDataByIdentifier request service Id 2E WDBI#7 ResponseCode = (requestOutOfRange 31 RC_ROOR
incorrectMessageLength 13 RC_IMLconditionsNotCorrect) 22 RC_CNC
#8 Checksum 00-FF CS
6.2.3. Parameter definition
The parameter recordDataIdentifier (RDI_) is defined in Table 28.
The parameter dataRecord (DREC_) is used by the WriteDataByIdentifier
request message to provide the data record values identified by the recordDataI-
dentifier to the server (VU). Data formats are specified in Section 8.
7. CONTROL OF TEST PULSES — INPUT/OUTPUT CONTROL FUNC-
TIONAL UNIT
The services available are detailed in the following table:
Table 32
Input/Output control functional unit
Service name Description
InputOutputControlByIdentifier The client requests the control of an input/output specific to
the server
7.1. Message description
7.1.1. Message description
There is a connection via the front connector which allows test pulses to be
controlled or monitored using a suitable tester.1998R2135 — EN — 25.08.2002 — 001.001 — 185
▼M1
This calibration I/O signal line can be configured by K-line command using the
InputOutputControlByIdentifier service to select the required input or output
function for the line. The available states of the line are:
— disabled,
— speedSignalInput, where the calibration I/O signal line is used to input a
speed signal (test signal) replacing the motion sensor speed signal,
— realTimeSpeedSignalOutputSensor, where the calibration I/O signal line is
used to output the speed signal of the motion sensor,
— RTCOutput, where the calibration I/O signal line is used to output the UTC
clock signal.
The vehicle unit must have entered an adjustment session and must be in CALI-
BRATION mode to configure the state of the line. On exit of the adjustment
session or of the CALIBRATION mode the vehicle unit must ensure the calibra-
tion I/O signal line is returned to the ‘disabled’ (default) state.
If speed pulses are received at the real time speed signal input line of the VU
while the calibration I/O signal line is set to input then the calibration I/O signal
line shall be set to output or returned to the disabled state.
The sequence shall be:
— establish communications by StartCommunication Service
— enter an adjustment session by StartDiagnosticSession Service and be in
CALIBRATION mode of operation (the order of these two operations is
not important).
— change the state of the output by InputOutputControlByIdentifier Service.
7.1.2. Message format
The message formats for the InputOutputControlByIdentifier primitives are
detailed in the following tables:
Table 33
InputOutputControlByIdentifier request message
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 InputOutputControlByIdentifier request Sid 2F IOCBI
#6 and #7 InputOutputIdentifier = (CalibrationInputOutput) F960 IOI_CIO
#8 or #8 to
#9ControlOptionRecord = ( COR_ …
inputOutputControlPara-
meter — one value from
Table 36xx IOCP_ …
controlState — one value
from Table 38 (see note
below))xx CS_ …
#9 or #10 Checksum 00-FF CS
Note: The controlState parameter is present only in some cases (see 7.1.3).
Table 34
InputOutputControlByIdentifier positive response message
Byte # Parameter Name Hex value Mnemonic
#1 Format byte — physical addressing 80 FMT
#2 Target address byte tt TGT1998R2135 — EN — 25.08.2002 — 001.001 — 186
▼M1
Byte # Parameter Name Hex value Mnemonic
#3 Source address byte EE SRC
#4 Additional length byte xx LEN#5 inputOutputControlByIdentifier positive response
SId6F IOCBIPR
#6 and #7 inputOutputIdentifier = (CalibrationInputOutput) F960 IOI_CIO
#8 or #8 to
#9controlStatusRecord = ( CSR_
inputOutputControlPara-
meter (same value as byte
#8 Table 33)xx IOCP_ …
controlState (same value as
byte #9 Table 33)) (if
applicable)xx CS_ …
#9 or #10 Checksum 00-FF CS
Table 35
InputOutputControlByIdentifier 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 2F IOCBI
#7 responseCode = (
incorrectMessageLength 13 RC_IML
conditionsNotCorrect 22 RC_CNCrequestOutOfRange 31 RC_ROOR
deviceControlLimitsEx-
ceeded)7A RC_DCLE
#8 Checksum 00-FF CS
7.1.3. Parameter definition
The parameter inputOutputControlParameter (IOCP_) is defined in the following
table:
Table 36
Definition of inputOutputControlParameter values
Hex Description Mnemonic
00 ReturnControlToECU
This value shall indicate to the server (VU) that the tester does
no longer have control about the calibration I/O signal line.RCTECU1998R2135 — EN — 25.08.2002 — 001.001 — 187
▼M1
Hex Description Mnemonic
01 ResetToDefault
This value shall indicate to the server (VU) that it is requested to
reset the calibration I/O signal line to its default state.RTD
03 ShortTermAdjustment
This value shall indicate to the server (VU) that it is requested to
adjust the calibration I/O signal line to the value included in the
controlState parameter.STA
The parameter controlState is present only when the inputOutputControlPara-
meter is set to ShortTermAdjustment and is defined in the following table:
Table 37
Definition of controlState values
Mode Hex value Description
Disable 00 I/O line is disabled (default state)
Enable 01 Enable calibration I/O line as speedSignalInputEnable 02 Enable calibration I/O line as realTimeSpeedSignalOutput-
Sensor
Enable 03 Enable calibration I/O line as RTCOutput
8. 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.
All parameters identified shall be supported by the VU.
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).
8.1. Transmitted parameter ranges
Table 38 defines the ranges used to determine the validity of a transmitted para-
meter.
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 recording equipment.
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 para-
meters where no response is expected from the receiving device.
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 para-
meter'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.1998R2135 — EN — 25.08.2002 — 001.001 — 188
▼M1
Table 38
dataRecords ranges
Range Name1 byte
(Hex value)2 bytes
(Hex value)4 bytes
(Hex value)ASCII
Valid signal 00 to FA 0000 to
FAFF00000000 to
FAFFFFFF1 to 254
Parameter specific indi-
catorFB FB00 to
FBFFFB000000 to
FBFFFFFFnone
Reserved range for
future indicator bitsFC to FD FC00 to
FDFFFC000000 to
FDFFFFFFnone
Error indicator FE FE00 to
FEFFFE000000 to
FEFFFFFF0
Not available or not
requestedFF FF00 to
FFFFFF000000 to
FFFFFFFFFF
For parameters coded in ASCII, the ASCII character ‘*’ is reserved as a deli-
miter.
8.2. dataRecords formats
Table 40 to Table 44 below detail the formats that shall be used via the Read-
DataByIdentifier and WriteDataByIdentifier Services.
Table 40 provides the length, resolution and operating range for each parameter
identified by its recordDataIdentifier:
Table 39
Format of dataRecords
Parameter NameData length
(bytes)Resolution Operating range
TimeDate 8 See details in Table 40
HighResolutionTotalVehi-
cleDistance4 5 m/bit gain, 0 m offset 0 to + 21 055 406 km
Kfactor 2 0,001 pulse/m/bit gain,
offset 00 to 64,255 pulse/m
LfactorTyreCircumference 2 0,125 10-3/bit gain, 0
offset0 to 8 031 m
WvehicleCharacteristic-
Factor2 0,001 pulse/m/bit gain, 0
offset0 to 64,255 pulse/m
TyreSize 15 ASCII ASCII
NextCalibrationDate 3 See details in Table 41SpeedAuthorised 2 1/256 km/h/bit gain, 0
offset0 to 250 996 km/h
RegisteringMemberState 3 ASCII ASCII
VehicleRegistrationNumber 14 See details in Table 44
VIN 17 ASCII ASCII
Table 40 details the formats of the different bytes of the TimeDate parameter:1998R2135 — EN — 25.08.2002 — 001.001 — 189
▼M1
Table 40
Detailed format of TimeDate (recordDataIdentifier value # F00B)
Byte Parameter definition Resolution Operating range
1 Seconds 0,25 s/bit gain, 0 s offset 0 to 59,75 s
2 Minutes 1 min/bit gain, 0 min
offset0 to 59 min
3 Hours 1 h/bit gain, 0 h offset 0 to 23 h
4 Month 1 month/bit gain, 0 month
offset1 toa 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-5 9t o5 9m i n
8 Local Hour Offset 1 h/bit gain, - 125 offset - 23 to + 23 h
Table 41 details the formats of the different bytes of the NextCalibrationDate
parameter:
Table 41
Detailed format of NextCalibrationDate (recordDataIdentifier value # F022)
Byte Parameter definition Resolution Operating range
1 Month 1 month/bit gain, 0 month
offset1 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 conerning 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 byte ‘Year’ parameter:
A value of 0 for the year identifies the year 1985; a value of 1 identifies 1986; etc.
Table 42 details the formats of the different bytes of the VehicleRegistration-
Number parameter:
Table 42
Detailed format of VehicleRegistrationNumber (recordDataIdentifier value # F07E)
Byte Parameter definition Resolution Operating range
1 Code Page (as defined in
Appendix 1)ASCII 01 to 0A
2 to 14 Vehicle Registration
Number (as defined in
Appendix 1)ASCII ASCII1998R2135 — EN — 25.08.2002 — 001.001 — 190
▼M1
Appendix 9
TYPE APPROVAL — LIST OF MINIMUM REQUIRED TESTS
CONTENTS
1. Introduction … .................................................................
1.1. Type approval … ...............................................................
1.2. References … . .................................................................
2. Vehicle unit functional tests … ....................................................
3. Motion sensor functional tests … . . ................................................
4. Tachograph cards functional tests … ...............................................
5. Interoperability tests … ..........................................................1998R2135 — EN — 25.08.2002 — 001.001 — 191
▼M1
1. INTRODUCTION
1.1. Type approval
The EEC type approval for a recording equipment (or component) or a tacho-
graph card is based on:
— a security certification, performed by an ITSEC authority, against a security
target fully compliant with Appendix 10 to this Annex,
— a functional certification performed by a Member State authority certifying
that the item tested fulfils the requirements of this Annex in terms of func-
tions performed, measurement accuracy and environmental characteristics,
— an interoperability certification performed by the competent body certifying
that the recording equipment (or tachograph card) is fully interoperable with
the necessary tachograph card (or recording equipment) models (see Chapter
VIII of this Annex).
This Appendix specifies which tests, as a minimum, must be performed by a
Member State authority during the functional tests, and which tests, as a
minimum, must be performed by the competent body during the interoperability
tests. Procedures to follow to carry out the tests or the type of tests are not
specified further.
The security certification aspects are not covered by this Appendix. If some tests
requested for type approval are performed during the security evaluation and
certification process, then these tests do not need to be performed again. In
this case, only the results of these security tests may be inspected. For informa-
tion, the requirements expected to be tested (or closely related to tests expected
to be performed) during the security certification, are marked with a ‘*’ in this
Appendix.
This Appendix considers separately the type approval of the motion sensor and
of the vehicle unit, as components of the recording equipment. Interoperability
between every model of motion sensor and every model of vehicle unit is not
required, therefore the type approval for a motion sensor can be granted only
in combination with the type approval of a vehicle unit and vice versa.
1.2. References
The following references are used in this Appendix:IEC 68-2-1 Environmental testing — Part 2: Tests — Tests A: Cold.
1990 + Amendment 2: 1994.
IEC 68-2-2 Environmental testing — Part 2: Tests — Tests B: Dry heat.
1974 + Amendment 2: 1994.
IEC 68-2-6 Basic environmental testing procedures — Test methods —
Test Fc and guidance: Vibration (sinusoidal). 6th edition:
1985.
IEC 68-2-14 Basic environmental testing procedures — Test methods —
Test N: Change of temperature. Modification 1: 1986.
IEC 68-2-27 Basic environmental testing procedures — Test methods —
Test Ea and guidance: Shock. Edition 3: 1987.
IEC 68-2-30 Basic environmental testing procedures — Test methods —
Test Db and guidance: Damp heat, cyclic (12 + 12 — hour
cycle). Modification 1: 1985.
IEC 68-2-35 Basic environmental testing procedure — Test methods —
Test Fda: Random vibration wide band — Reproductibility
High. Modification 1: 1983.
IEC 529 Degrees of protection provided by enclosures (IP code).
Edition 2: 1989.
IEC 61000-4-2 Electromagnetic Compatibility (EMC) — Testing and
measurement techniques — Electrostatic discharge immunity
test: 1995/Amendment 1: 1998.
ISO 7637-1 Road vehicles — Electrical disturbance by conduction and
coupling — Part 1: Passenger cars and light commercial vehi-
cles with nominal 12 V supply voltage — Electrical transient
conduction along supply lines only. Edition 2: 1990.
ISO 7637-2 Road vehicles — Electrical disturbance by conduction and
coupling — Part 1: Passenger cars and light commercial vehi-
cles with nominal 12 V supply voltage — Electrical transient
conduction along supply lines only. Edition 2: 1990.
ISO 7637-3 Road vehicles — Electrical disturbance by conduction and
coupling — Part 3: Vehicles with 12 V or 24 V supply
voltage — Electrical transient transmission by capacitive and1998R2135 — EN — 25.08.2002 — 001.001 — 192
▼M1
inductive coupling via lines other than supply lines. First
Edition: 1995 + Cor 1: 1995.
ISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with
contacts — Part 1: Physical characteristics. First edition:
1998.
ISO/IEC 7816-2 Information technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 2: Dimensions and loca-
tion of the contacts. First edition: 1999.
ISO/IEC 7816-3 Information technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 3: Electronic signals
and transmission protocol. Edition 2: 1997.
ISO/IEC 10373 Identification cards — Test methods. First edition: 1993.
2. VEHICLE UNIT FUNCTIONAL TESTS
No Test DescriptionRelated require-
ments
1. Administrative examination
1.1. Documentation Correctness of documentation1.2. Manufacturer
test resultsResults of manufacturer test performed
during integration. Paper demonstrations070, 071, 073
2. Visual inspection
2.1. Compliance with documentation
2.2. Identification/markings 168, 169
2.3. Materials 163 to 1672.4 Sealing 2512.5. External interfaces
3. Functional tests
3.1. Functions provided 002, 004, 2443.2. Modes of operation 006*, 007*, 008*,
009*, 106, 107
3.3. Functions and data access rights 010*, 011*, 240,
246, 247
3.4. Monitoring cards insertion and withdrawal 013, 014, 015*,
016*, 106
3.5. Speed and distance measurement 017 to 026
3.6. Time measurement (test performed at 20 ºC) 027 to 032
3.7. Monitoring driver activities 033 to 043, 1063.8. Monitoring driving status 044, 045, 1063.9. Manual entries 046 to 050b3.10. Company locks management 051 to 055
3.11. Monitoring control activities 056, 057
3.12. Detection of events and/or faults 059 to 069, 1063.13. Equipment identification data 075*, 076*, 0791998R2135 — EN — 25.08.2002 — 001.001 — 193
▼M1
No Test DescriptionRelated require-
ments
3.14. Driver card insertion and withdrawal data 081* to 083*
3.15. Driver activity data 084* to 086*
3.16. Places data 087* to 089*
3.17. Odometer data 090* to 092*3.18. Detailed speed data 093*3.19. Events data 094*, 095
3.20. Faults data 096*
3.21. Calibration data 097*, 098*3.22. Time adjustment data 100*, 101*3.23. Control activity data 102*, 103*3.24. Company locks data 104*
3.25. Download activity data 105*
3.26. Specific conditions data 105a*, 105b*3.27. Recording and storing on tachographs cards 108, 109*, 109a*,
110*, 111, 112
3.28. Displaying 072, 106, 113 to
128, PIC_001,
DIS_001
3.29. Printing 072, 106, 129 to
138, PIC_001,
PRT_001 to
PRT_012
3.30. Warning 106, 139 to 148,
PIC_001
3.31. Data downloading to external media 072, 106, 149 to
151
3.32. Output data to additional external devices 152, 153
3.33. Calibration 154*, 155*, 156*,
245
3.34. Time adjustment 157*, 158*
3.35. Non-interference of additional functions 003, 269
4. Environmental tests
4.1. Temperature Verify functionality through:
— IEC 68-2-1, test Ad, with a test duration
of 72 hours at the lower temperature
(− 20 ºC), 1 hour operating, 1 hour non
operating,
— IEC 68-2-2, test Bd, with a test duration
of 72 hours at the higher temperature
(+ 70 ºC), 1 hour operating, 1 hour non
operating
Temperature cycles: verify that the vehicle
unit can withstand rapid changes in the1591998R2135 — EN — 25.08.2002 — 001.001 — 194
▼M1
No Test DescriptionRelated require-
ments
environment temperature through IEC 68-2-
14 test Na, 20 cycles, each with temperature
varying from the lower temperature (− 20 ºC)
to the higher temperature (+ 70 ºC) and a 2
hours stay at both the lower and the higher
temperature
A reduced set of tests (among those defined
in section 3 of this table) can be carried out
at the lower temperature, the higher tempera-
ture and during the temperature cycles
4.2. Humidity Verify that the vehicle unit can withstand a
cyclic damp (heat test) through IEC 68-2-30,
test Db, six 24 hours cycles, each tempera-
ture varying from + 25 ºC to + 55 ºC and a
relative humidity of 97 % at + 25 ºC and
equal to 93 % at + 55 ºC160
4.3. Vibration 1. Sinusoidal vibrations:
verify that the vehicle unit can withstand
sinusoidal vibrations with the following
characteristics:
constant displacement between 5 and
11 Hz: 10 mm peak
constant acceleration between 11 and
300 Hz: 5 g
This requirement is verified through IEC
68-2-6, test Fc, with a minimum test
duration of 3 × 12 hours (12 hours per
axis)
2. Random vibrations:
verify that the vehicle unit can withstand
random vibrations with the following
characteristics:
frequency 5-150 Hz, level 0,02 g2/Hz
This requirement is verified through IEC
68-2-35, test Ffda, with a minimum test
duration of 3 × 12 hours (12 hours per
axis), 1 hour operating, 1 hour non oper-
ating
The two tests described above are performed
on two different samples of the equipment
type being tested163
4.4. Protection
against water
and foreign
bodiesVerify that the vehicle unit protection index
according to IEC 529 is at least IP 40, when
mounted in operating conditions in a vehicle164, 165
4.5. Over-voltage
protectionVerify that the vehicle unit can withstand a
power supply of:
24V versions: 34 V at + 40 ºC 1 hour
12V versions: 17 V at + 40 ºC 1 hour161
4.6. Reverse polarity
protectionVerify that the vehicle unit can withstand an
inversion of its power supply161
4.7. Short-circuit
protectionVerify that input output signals are protected
against short circuits to power supply and
ground161
5. EMC tests
5.1. Radiated emis-
sions andCompliance with Directive 95/54/EEC 1621998R2135 — EN — 25.08.2002 — 001.001 — 195
▼M1
No Test DescriptionRelated require-
ments
susceptibility
5.2. Electrostatic
dischargeCompliance with IEC 61000-4-2, ± 2 kV
(level 1)162
5.3. Conducted tran-
sient suscept-
ibility on power
supplyFor 24V versions: compliance with ISO
7637-2:
pulse 1a: Vs = − 100 V, Ri = 10 ohms
pulse 2: Vs = + 100 V, Ri = 10 ohms
pulse 3a: Vs = − 100 V, Ri = 50 ohmspulse 3b: Vs = + 100 V, Ri = 50 ohmspulse 4: Vs = − 16 V Va = − 12 V,
t6=100 ms
pulse 5: Vs = + 120 V, Ri = 2,2 ohms,
td = 250 ms
For 12V versions: compliance with ISO
7637-1:
pulse 1: Vs = − 100 V, Ri = 10 ohms
pulse 2: Vs = + 100 V, Ri = 10 ohms
pulse 3a: Vs = − 100 V, Ri = 50 ohms
pulse 3b: Vs = + 100 V, Ri = 50 ohmspulse 4: Vs = − 6 V, Va = − 5 V, t6 = 15 ms
pulse 5: Vs = + 65 V, Ri = 3 ohms,
td = 100 ms
Pulse 5 shall be tested only for vehicle units
designed to be installed in vehicles for which
no external common protection against load
dump is implemented162
3. MOTION SENSOR FUNCTIONAL TESTS
No Test DescriptionRelated require-
ments
1. Administrative examination
1.1. Documentation Correctness of documentation
2. Visual inspection
2.1. Compliance with documentation2.2. Identification/markings 169, 1702.3. Materials 163 to 167
2.4. Sealing 251
3. Functional tests
3.1. Sensor identification data 077*3.2. Motion sensor — vehicle unit pairing 099*, 155
3.3. Motion detection
Motion measurement accuracy 022 to 026
4. Environmental tests1998R2135 — EN — 25.08.2002 — 001.001 — 196
▼M1
No Test DescriptionRelated require-
ments
4.1. Operating
temperatureVerify functionality (as defined in test No
3.3) in temperature range [− 40 ºC; + 135 ºC]
through:
— IEC 68-2-1 test Ad, with a test duration
of 96 hours at the lowest temperature
Tomin
— IEC 68-2-2 test Bd, with a test duration
of 96 hours at the highest temperature
Tomax159
4.2. Temperature
cyclesVerify functionality (as defined in test No
3.3) through IEC 68-2-14 test Na, 20 cycles,
each with temperature varying from the
lower temperature (− 40 ºC) to the higher
temperature (+135 ºC) and a 2 hours stay at
both the lower and the higher temperature
A reduced set of tests (among those defined
in test 3.3) can be carried out at the lower
temperature, the higher temperature and
during the temperature cycles159
4.3. Humidity cycles Verify functionality (as defined in test No
3.3) through IEC 68-2-30, test Db, six 24
hours cycles, each temperature varying from
+ 25 ºC to + 55 ºC and a relative humidity of
97 % at + 25 ºC and equal to 93 % at + 55 ºC160
4.4. Vibration Verify functionality (as defined in test No
3.3) through IEC 68-2-6, test Fc, with a test
duration of 100 frequency cycles:
constant displacement between 10 and 57 Hz:
1,5 mm peak constant accelaration between
57 and 500 Hz: 20 g163
4.5. Mechanical
shockVerify functionality (as defined in test No
3.3) through IEC 68-2-27, test Ea, 3 shocks
in both directions of the 3 perpendicular axes163
4.6. Protection
against water
and foreign
bodiesVerify that the motion sensor protection
index according to IEC 529 is at least IP 64,
when mounted in operating conditions in a
vehicle165
4.7. Reverse polarity
protectionVerify that the motion sensor can withstand
an inversion of its power supply161
4.8. Short circuit
protectionVerify that input output signals are protected
against short circuits to power supply and
ground161
5. EMC
5.1. Radiated emis-
sions and
susceptibilityVerify compliance with Directive 95/54/EEC 162
5.2. Electrostatic
dischargeCompliance with IEC 61000-4-2, ± 2 kV
(level 1)162
5.3. Conducted tran-
sient suscept-
ibility on data
lines)Compliance with ISO 7637-3 (level III) 1621998R2135 — EN — 25.08.2002 — 001.001 — 197
▼M1
4. TACHOGRAPH CARDS FUNCTIONAL TESTS
No Test DescriptionRelated require-
ments
1. Administrative examination
1.1. Documentation Correctness of documentation
2. Visual inspection
2.1. Make sure that all features for protection and
visible data are correctly printed on the card
and compliant171 to 181
3. Physical tests
3.1. Check dimension of the card and location of
the contacts184
ISO/IEC 7816-1ISO/IEC 7816-2
4. Protocol tests
4.1. ATR Check that the ATR is compliant ISO/IEC 7816-3
TCS 304, 307,
308
4.2. T=0 Check that T=0 protocol is compliant ISO/IEC 7816-3
TCS 302, 303,
305
4.3. PTS Check that the PTS command is compliant
by setting T=1 from T=0ISO/IEC 7816-3
TCS 309 to 311
4.4. T=1 Check that T=1 protocol is compliant ISO/IEC 7816-3
TCS 303, / 306
5. Card structure
5.1. Test that the file structure of the card is
compliant by checking the presence of the
mandatory files in the card and their access
conditionsTCS 312
TCS 400*, 401,
402, 403*, 404,
405*, 406, 407,
408*, 409, 410*,
411, 412, 413*,
414, 415*, 416,
417, 418*, 419
6. Functional tests
6.1. Normal proces-
singTest at least once each allowed usage of each
command (ex: test the UPDATE BINARY
command with CLA = ′00′, CLA =′0C′and
with different P1, P2 and Lc parameters)
Check that the operations have actually been
performed in the card (ex: by reading the file
the command has been performed on)TCS 313 to TCS
379
6.2. Error messages Test at least once each error message (as
specified in Appendix 2) for each command
Test at least once every generic error (except
′6400′integrity errors checked during
security certification)
7. Environmental tests
7.1. Make sure that the cards work within the 185 to 1881998R2135 — EN — 25.08.2002 — 001.001 — 198
▼M1
No Test DescriptionRelated require-
ments
limit conditions defined in accordance with
ISO/IEC 10373ISO/IEC 7816-1
5. INTEROPERABILITY TESTS
No Test Description
1. Mutual authen-
ticationCheck that the mutual authentication between the vehicle unit and
the tachograph card runs normally
2. Write/read tests Execute a typical activity scenario on the vehicle unit. The scenario
shall be adapted to the type of card being tested and involve writ-
ings in as many EFs as possible in the card
Verify through a card downloading that all corresponding record-
ings have been properly made
Verify through a card daily printout that all corresponding record-
ings can be properly read1998R2135 — EN — 25.08.2002 — 001.001 — 199
▼M1
Appendix 10
GENERIC SECURITY TARGETS
This appendix specifies the minimum required content of motion sensor, vehicle unit and tachograph
card security targets.
In order to form the security targets against which they may seek security certification, manufacturers
shall refine and complete the documents as necessary, without amending nor deleting existing threats,
objectives, procedural means and security enforcing functions specifications.
CONTENTS
Motion sensor generic security target
1. Introduction … . ..............................................................
2. Abbreviations, definitions and references … .......................................
2.1. Abbrevations … ..............................................................
2.2. Definitions … . . ..............................................................
2.3. References … . . ..............................................................
3. Product rationale … . . . ........................................................
3.1. Motion sensor description and method of use … . ..................................
3.2. Motion sensor life cycle … . . ...................................................
3.3. Threats … ...................................................................
3.3.1. Threats to access control policies … .............................................
3.3.2. Design related threats … .......................................................
3.3.3. Operation oriented threats … ...................................................
3.4. Security objectives … . ........................................................
3.5. Information technology security objectives … ......................................
3.6. Physical, personnel or procedural means … . .......................................
3.6.1. Equipment design … . . ........................................................
3.6.2. Equipment delivery … . ........................................................
3.6.3. Security data generation and delivery … . . . .......................................
3.6.4. Recording equipment installation, calibration, and inspection … .......................
3.6.5. Law enforcement control … . ...................................................
3.6.6. Software upgrades … . . ........................................................
4. Security enforcing functions … ..................................................
4.1. Identificacion and authentication … . .............................................
4.2. Access control … .............................................................
4.2.1. Acess control policy … ........................................................
4.2.2. Data access rights … . . ........................................................
4.2.3. File structure and access conditions … ...........................................
4.3. Accountability … .............................................................
4.4. Audit … . ...................................................................
4.5. Accuracy … . . . ..............................................................
4.5.1. Information flow control policy … . . .............................................
4.5.2. Internal data transfers … .......................................................
4.5.3. Stored data integrity … ........................................................
4.6. Reliability of service … ........................................................
4.6.1. Tests … . . ...................................................................
4.6.2. Software … ..................................................................
4.6.3. Physical protection … . ........................................................1998R2135 — EN — 25.08.2002 — 001.001 — 200
▼M1
4.6.4. Power supply interruptions … ...................................................
4.6.5. Reset conditions … . . . ........................................................
4.6.6. Data availability … . . . ........................................................
4.6.7. Multiple applications … .......................................................
4.7. Data exchange … .............................................................
4.8. Cryptographic support … .......................................................
5. Definition of security mechanisms … .............................................
6. Minimum strength of security mechanisms … ......................................
7. Level of assurance … . ........................................................
8. Rationale … . . . ..............................................................
Vehicle Unit generic security target
1. Introduction … . ..............................................................
2. Abbreviations, definitions and references … .......................................
2.1. Abbreviations … .............................................................
2.2. Definitions … . . ..............................................................
2.3. References … . . ..............................................................
3. Product rationale … . . . ........................................................
3.1. Vehicle unit description and method of use … . . . ..................................
3.2. Vehicle unit life cycle … . . . ...................................................
3.3. Threats … ...................................................................
3.3.1. Threats to identification and access control policies … . . ............................
3.3.2. Design related threats … .......................................................
3.3.3. Operation oriented threats … ...................................................
3.4. Security objectives … . ........................................................
3.5. Information technology security objectives … ......................................
3.6. Physica, personnel or procedural means … . .......................................
3.6.1. Equipment design … . . ........................................................
3.6.2. Equipment delivery and activation … ............................................
3.6.3. Security data generation and delivery … . . . .......................................
3.6.4. Cards delivery … .............................................................
3.6.5. Recording equipment installation, calibration, and ispection … . .......................
3.6.6. Equipment operation … ........................................................
3.6.7. Law enforcement control … . ...................................................
3.6.8. Software upgrades … . . ........................................................
4. Security enforcing functions … ..................................................
4.1. Identification and authentication … . .............................................
4.1.1. Motion sensor identification and authentication … ..................................
4.1.2. User identification and authentication … . . . .......................................
4.1.3. Remotely connected company identificatin and authentication … ......................
4.1.4. Management device identification and authentication … . ............................
4.2. Access control … .............................................................
4.2.1. Access control policy … .......................................................
4.2.2. Access rights to functions … ...................................................
4.2.3. Access rights to data … ........................................................
4.2.4. File structure and access conditions … ...........................................
4.3. Accountability … .............................................................1998R2135 — EN — 25.08.2002 — 001.001 — 201
▼M1
4.4. Audit … . ...................................................................
4.5. Object re-use … ..............................................................
4.6. Accuracy … . . . ..............................................................
4.6.1. Information flow control policy … . . .............................................
4.6.2. Internal data transfers … .......................................................
4.6.3. Stored data integrity … ........................................................
4.7. Reliability of service … ........................................................
4.7.1. Tests … . . ...................................................................
4.7.2. Software … ..................................................................
4.7.3. Physical protection … . ........................................................
4.7.4. Power supply interuptions … ...................................................
4.7.5. Reset conditions … . . . ........................................................
4.7.6. Data availability … . . . ........................................................
4.7.7. Multiple applications … .......................................................
4.8. Data exchange … .............................................................
4.8.1. Data exchange with motion sensor … ............................................
4.8.2. Data exchange with tachograph cards … . . . .......................................
4.8.3. Data exchange with external storage media (downloading function) … .................
4.9. Cryptographic support … .......................................................
5. Definition of security mechanisms … .............................................
6. Minimum strength of security mechanisms … ......................................
7. Level of assurance … . ........................................................
8. Rationale … . . . ..............................................................
Tachograph card generic security target
1. Introduction … . ..............................................................
2. Abbreviations, definitions and references … .......................................
2.1. Abbreviations … .............................................................
2.2. Defininitions … ..............................................................
2.3. References … . . ..............................................................
3. Product rationale … . . . ........................................................
3.1. Tachograph card description and method of use … .................................
3.2. Tachograph card life-cycle … ...................................................
3.3. Threats … ...................................................................
3.3.1. Final aims … . . ..............................................................
3.3.2. Attack paths … . ..............................................................
3.4. Security objecives … . . ........................................................
3.5. Information technology security objectives … ......................................
3.6. Physical, personnel or procedural means … . .......................................
4. Security enforcing functions … ..................................................
4.1. Compliance to protection profiles … .............................................
4.2. User identification and authentication … . . . .......................................
4.2.1. User identification … . . ........................................................
4.2.2. User authentication … . ........................................................
4.2.3. Authentication failures … . . . ...................................................
4.3. Access control … .............................................................
4.3.1. Access control policy … .......................................................1998R2135 — EN — 25.08.2002 — 001.001 — 202
▼M1
4.3.2. Access control functions … . . ...................................................
4.4. Accountability … .............................................................
4.5. Audit … . ...................................................................
4.6. Accuracy … . . . ..............................................................
4.6.1. Stored data integrity … ........................................................
4.6.2. Basic data authentication … . ...................................................
4.7. Reliability of service … ........................................................
4.7.1. Tests … . . ...................................................................
4.7.2. Software … ..................................................................
4.7.3. Power supply … ..............................................................
4.7.4. Reset conditions … . . . ........................................................
4.8. Data exchange … .............................................................
4.8.1. Data exchange with a vehicle unit … .............................................
4.8.2. Export of data to a non-vehicle unit (download function) … . . . .......................
4.9. Cryptographic support … .......................................................
5. Definition of security mechanisms … .............................................
6. Claimed minimum strength of mechanisms … . . . ..................................
7. Level of assurance … . ........................................................
8. Rationale … . . . ..............................................................1998R2135 — EN — 25.08.2002 — 001.001 — 203
▼M1
MOTION SENSOR GENERIC SECURITY TARGET
1.Introduction
This document contains a description of the motion sensor, of the threats it must
be able to counteract and of the security objectives it must achieve. It specifies
the required security enforcing functions. It states the claimed minimum strength
of security mechanisms and the required level of assurance for the development
and the evaluation.
Requirements referred to in the document, are those of the body of Annex I B.
For clarity of reading, duplication sometimes arises between Annex I B body
requirements and security target requirements. In case of ambiguity between a
security target requirement and the Annex I B body requirement referred by
this security target requirement, the Annex I B body requirement shall prevail.
Annex I B body requirements not referred by security targets are not the subject
of security enforcing functions.
Unique labels have been assigned to threats, objectives, procedural means and
SEF specifications for the purpose of traceability to development and evaluation
documentation.
2.Abbreviations, definitions and references
2.1. Abbreviations
ROM Read only Memory
SEF Security enforcing function
TBD To be defined
TOE Target of evaluation
VU Vehicle unit.
2.2. Definitions
Digital Tachograph Recording equipment
Entity A device connected to the motion sensor
Motion data The data exchanged with the VU, representative of
speed and distance travelled
Physically separated parts Physical components of the motion sensor that are
distributed in the vehicle as opposed to physical
components gathered into the motion sensor casing
Security data The specific data needed to support security enfor-
cing functions (e.g. crypto keys)
System Equipment, people or organisations, involved in
any way with the recording equipment
User A human user of the motion sensor (when not used
in the expression ‘user data’)
User data Any data, other than motion or security data,
recorded or stored by the motion sensor.
2.3. References
ITSEC ITSEC Information Technology Security Evalua-
tion Criteria 1991.
3.Product rationale
3.1. Motion sensor description and method of use
The motion sensor is intended to be installed in road transport vehicles. Its
purpose is to provide a VU with secured motion data representative of vehicle's
speed and distance travelled.
The motion sensor is mechanically interfaced to a moving part of the vehicle,
which movement can be representative of vehicle's speed or distance travelled.
It may be located in the vehicle's gear box or in any other part of the vehicle.
In its operational mode, the motion sensor is connected to a VU.
It may also be connected to specific equipment for management purposes (TBD
by manufacturer).
The typical motion sensor is described in the following figure:1998R2135 — EN — 25.08.2002 — 001.001 — 204
▼M1
Figure 1
Typical motion sensor
3.2. Motion sensor life cycle
The typical life cycle of the motion sensor is described in the following figure:
Figure 2
Motion sensor typical life cycle
1998R2135 — EN — 25.08.2002 — 001.001 — 205
▼M1
3.3. Threats
This paragraph describes the threats the motion sensor may face.
3.3.1. Threats to access control policies
T.Access Users could try to access functions not allowed to
them.
3.3.2. Design related threats
T.Faults Faults in hardware, software, communication
procedures could place the motion sensor in
unforeseen conditions compromising its security
T.Tests The use of non invalidated test modes or of
existing back doors could compromise the motion
sensor security
T.Design Users could try to gain illicit knowledge of design
either from manufacturer's material (through theft,
bribery, …) or from reverse engineering.
3.3.3. Operation oriented threats
T.Environment Users could compromise the motion sensor
security through environmental attacks (thermal,
electromagnetic, optical, chemical, mechanical, …)
T.Hardware Users could try to modify motion sensor hardwareT.Mechanical_Origin Users could try to manipulate the motion sensor
input (e.g. unscrewing from gearbox, …)
T.Motion_Data Users could try to modify the vehicle's motion data
(addition, modification, deletion, replay of signal)
T.Power_Supply Users could try to defeat the motion sensor
security objectives by modifying (cutting, redu-
cing, increasing) its power supply
T.Security_Data Users could try to gain illicit knowledge of
security data during security data generation or
transport or storage in the equipment
T.Software Users could try to modify motion sensor softwareT.Stored_Data Users could try to modify stored data (security or
user data).
3.4. Security objectives
The main security objective of the digital tachograph system is the following:
O.Main The data to be checked by control authorities must
be available and reflect fully and accurately the
activities of controlled drivers and vehicles in
terms of driving, work, availability and rest periods
and in terms of vehicle speed
Therefore the security objective of the motion sensor, contributing to the global
security objective, is:
O.Sensor_Main The data transmitted by the motion sensor must be
available to the VU so as to allow the VU to deter-
mine fully and accurately the movement of the
vehicle in terms of speed and distance travelled.
3.5. Information technology security objectives
The specific IT security objectives of the motion sensor contributing to its main
security objective, are the following:
O.Access The motion sensor must control connected entities'
access to functions and data
O.Audit The motion sensor must audit attempts to under-
mine its security and should trace them to
associated entities
O.Authentication The motion sensor must authenticate connected
entities
O.Processing The motion sensor must ensure that processing of
input to derive motion data is accurate1998R2135 — EN — 25.08.2002 — 001.001 — 206
▼M1
O.Reliability The motion sensor must provide a reliable service
O.Secured_Data_Exchange The motion sensor must secure data exchanges
with the VU.
3.6. Physical, personnel or procedural means
This paragraph describes physical, personnel or procedural requirements that
contribute to the security of the motion sensor.
3.6.1. Equipment design
M.Development Motion sensor developers must ensure that the
assignment of responsibilities during development
is done in a manner which maintains IT security
M.Manufacturing Motion sensor manufacturers must ensure that the
assignment of responsibilities during manufac-
turing is done in a manner which maintains IT
security, and that during the manufacturing process
the motion sensor is protected from physical
attacks which might compromise IT security.
3.6.2. Equipment delivery
M.Delivery Motion sensor manufacturers, vehicle manufac-
turers and fitters or workshops must ensure that
handling of the motion sensor is done in a manner
which maintains IT security.
3.6.3. Security data generation and delivery
M.Sec_Data_Generation Security data generation algorithms must be acces-
sible to authorised and trusted persons only
M.Sec_Data_Transport Security data must be generated, transported, and
inserted into the motion sensor, in such a way to
preserve its appropriate confidentiality and integ-
rity.
3.6.4. Recording equipment installation, calibration, and inspection
M.Approved_Workshops Installation, calibration and repair of recording
equipment must be carried by trusted and approved
fitters or workshops
M.Mechanical_Interface Means of detecting physical tampering with the
mechanical interface must be provided (e.g. seals)
M.Regular_Inpections Recording equipment must be periodically
inspected and calibrated.
3.6.5. Law enforcement control
M.Controls Law enforcement controls must be performed
regularly and randomly, and must include security
audits.
3.6.6. Software upgrades
M.Software_Upgrade Software revisions must be granted security certifi-
cation before they can be implemented in a motion
sensor.
4.Security enforcing functions
4.1. Identification and authentication
The motion sensor shall be able to establish, for every interaction, the identity of
any entity it is connected to.
The identity of a connected entity shall consist of:
— an entity group:
— VU,
— Management device,
— Other,
— an entity ID (VU only).1998R2135 — EN — 25.08.2002 — 001.001 — 207
▼M1
The entity ID of a connected VU shall consist of the VU approval number and
the VU serial number.
The motion sensor shall be able to authenticate any VU or management device
it is connected to:
— at entity connection,
— at power supply recovery.
The motion sensor shall be able to periodically re-authenticate the VU it is
connected to.
The motion sensor shall detect and prevent use of authentication data that has
been copied and replayed.
After (TBD by manufacturer and not more than 20) consecutive unsuccessful
authentication attempts have been detected, the SEF shall:
— generate an audit record of the event,
— warn the entity,— continue to export motion data in a non secured mode.
4.2. Access control
Access controls ensure that information is read from, created in, or modified
into the TOE only by those authorised to do so.
4.2.1. Access control policy
The motion sensor shall control access rights to function and data.
4.2.2. Data access rights
The motion sensor shall ensure that motion sensor identification data can be
written once only (requirement 078).
The motion sensor shall accept and/or store user data from authenticated entities
only.
The motion sensor shall enforce appropriate read and write access rights to
security data.
4.2.3. File structure and access conditions
Application and data files structure and access conditions shall be created during
the manufacturing process, and then locked from any future modification or
deletion.
4.3. Accountability
The motion sensor shall hold in its memory motion sensor identification data
(requirement 077).
The motion sensor shall store in its memory installation data (requirement 099).
The motion sensor shall have a capability to output accountability data to
authenticated entities at their request.
4.4. Audit
The motion sensor shall, for events impairing its security, generate audit records
of the events.
The events affecting the security of the motion sensor are the following:
— security breach attempts,
— authentication failure,
— stored data integrity error,— internal data transfer error,— unauthorised case opening,— hardware sabotage.
— sensor fault.
Audit records shall include the following data:
— date and time of the event,
— type of event,— connected entity identity.1998R2135 — EN — 25.08.2002 — 001.001 — 208
▼M1
when required data is not available, an appropriate default indication shall be
given (TBD by manufacturer).
The motion sensor shall send the generated audit records to the VU at the
moment of their generation, and may also store them in its memory.
In the case where the motion sensor stores audit records, it shall ensure that 20
audit records will be maintained independent of audit storage exhaustion, and
shall have a capability to output stored audit records to authenticated entities at
their request.
4.5. Accuracy
4.5.1. Information flow control policy
The motion sensor shall ensure that motion data may only been processed and
derived from sensor mechanical input.
4.5.2. Internal data transfers
The requirements of this paragraph apply only if the motion sensor makes use of
physically separated parts.
If data are transferred between physically separated parts of the motion sensor,
the data shall be protected from modification.
Upon detection of a data transfer error during an internal transfer, transmission
shall be repeated and the SEF shall generate an audit record of the event.
4.5.3. Stored data integrity
The motion sensor shall check user data stored in its memory for integrity
errors.
Upon detection of a stored user data integrity error, the SEF shall generate an
audit record.
4.6. Reliability of service
4.6.1 Tests
All commands, actions, or test points, specific to the testing needs of the manu-
facturing phase shall be disabled or removed before the end of the
manufacturing phase. It shall not be possible to restore them for later use.
The motion sensor shall run self-tests, during initial start-up, and during normal
operation to verify its correct operation. The motion sensor self-tests shall
include a verification of the integrity of security data and a verification of the
integrity of stored executable code (if not in ROM).
Upon detection of an internal fault during self-test, the SEF shall generate an
audit record (sensor fault).
4.6.2. Software
There shall be no way to analyse or debug the motion sensor software in the
field.
Inputs from external sources shall not be accepted as executable code.
4.6.3. Physical protection
If the motion sensor is designed so that it can be opened, the motion sensor shall
detect any case opening, even without external power supply for a minimum of
6 months. In such a case, the SEF shall generate an audit record of the event (It
is acceptable that the audit record is generated and stored after power supply
reconnection).
If the motion sensor is designed so that it cannot be opened, it shall be designed
such that physical tampering attempts can be easily detected (e.g. through visual
inspection).
The motion sensor shall detect specified (TBD by manufacturer) hardware sabo-
tage.
In the case described above, the SEF shall generate an audit record and the
motion sensor shall: (TBD by manufacturer).
4.6.4. Power supply interruptions
The motion sensor shall preserve a secure state during power supply cut-off or
variations.1998R2135 — EN — 25.08.2002 — 001.001 — 209
▼M1
4.6.5. Reset conditions
In case of a power supply interruption, or if a transaction is stopped before
completion, or on any other reset conditions, the motion sensor shall be reset
cleanly.
4.6.6. Data availability
The motion sensor shall ensure that access to resources is obtained when
required and that resources are not requested nor retained unnecessarily.
4.6.7. Multiple applications
If the motion sensor provides applications other than the tachograph application,
all applications shall be physically and/or logically separated from each other.
These applications shall not share security data. Only one task shall be active
at a time.
4.7. Data exchange
The motion sensor shall export motion data to the VU with associated security
attributes, such that the VU will be able to verify its integrity and authenticity.
4.8. Cryptographic support
The requirements of this paragraph are applicable only where needed, depending
upon security mechanisms used and upon the manufacturer's solutions.
Any cryptographic operation performed by the motion sensor shall be in accor-
dance with a specified algorithm and a specified key size.
If the motion sensor generates cryptographic keys, it shall be in accordance with
specified cryptographic key generation algorithms and specified cryptographic
key sizes.
If the motion sensor distributes cryptographic keys, it shall be in accordance
with specified key distribution methods.
If the motion sensor accesses cryptographic keys, it shall be in accordance with
specified cryptographic keys access methods.
If the motion sensor destroys cryptographic keys, it shall be in accordance with
specified cryptographic keys destruction methods.
5.Definition of security mechanisms
The security mechanisms, fulfilling the motion sensor security enforcing func-
tions, are defined by the motion sensor manufacturers.
6.Minimum strength of security mechanisms
The minimum strength of the motion sensor security mechanisms is High, as
defined in (ITSEC).
7.Level of assurance
The target level of assurance for the motion sensor is ITSEC level E3, as
defined in (ITSEC).
8.Rationale
The following matrixes give a rationale for the SEFs by showing:
— which SEFs or means counteract which threats,
— which SEFs fulfil which IT security objectives.1998R2135 — EN — 25.08.2002 — 001.001 — 210
Threats IT ObjectivesAccess
Faults
TestsDesignEnvironmentHardwareMechanical_Origin
Motion_Data
Power_SupplySecurity_DataSoftwareStored_DataAccess
Audit
AuthenticationProcessingReliabilitySecured_Data_Exchange
Physical Personnel Procedural means
Development x x x
Manufacturing x xDelivery xx x
Security Data Generation x
Security Data Transport x
Approved Workshops x
Mechanical interface x
Regular Inspection x x x x
Law enforcement controls x x x x x x
Software Upgrades x
Security Enforcing Functions
Identification and authentication
UIA_101 Entities identification x x x x x
UIA_102 Entities identity x xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 211
Threats IT ObjectivesAccess
Faults
TestsDesignEnvironmentHardwareMechanical_Origin
Motion_Data
Power_SupplySecurity_DataSoftwareStored_DataAccess
Audit
AuthenticationProcessingReliabilitySecured_Data_Exchange
UIA_103 VU identity x
UIA_104 Entities authentication x x x x xUIA_105 re-authentication x x x x xUIA_106 Unforgeable authentication x x x x
UIA_107 Authentication failure x x x
Access controlACC_101 Access control policy x x x xACC_102 Motion sensor ID xx
ACC_103 User data xx
ACC_104 Security Data xx x
ACC_105 File structure and access condi-
tionsxx x x
Accountability
ACT_101 Motion sensor ID data x
ACT_102 Pairing data x
ACT_103 Accountability data x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 212
Threats IT ObjectivesAccess
Faults
TestsDesignEnvironmentHardwareMechanical_Origin
Motion_Data
Power_SupplySecurity_DataSoftwareStored_DataAccess
Audit
AuthenticationProcessingReliabilitySecured_Data_Exchange
Audit
AUD_101 Audit records x
AUD_102 Audit events list x x x x x
AUD_103 Audit data x
AUD_104 Audit tools x
AUD_105 Audit records storage x
AccuracyACR_101 Information flow control policy x x xACR_102 Internal transfers xx
ACR_103 Internal transfers x
ACR_104 Stored data integrity xx
ACR_105 Stored data integrity xx
Reliability
RLB_101 Manufacturing tests x x x
RLB_102 Self tests x x x x x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 213
Threats IT ObjectivesAccess
Faults
TestsDesignEnvironmentHardwareMechanical_Origin
Motion_Data
Power_SupplySecurity_DataSoftwareStored_DataAccess
Audit
AuthenticationProcessingReliabilitySecured_Data_Exchange
RLB_103 Self tests x x x x
RLB_104 Software analysis x x x
RLB_105 Software input xx x
RLB_106 Case opening x x x x x x xRLB_107 Hardware sabotage x x
RLB_108 Hardware sabotage x x
RLB_109 Power supply interruptions xx
RLB_110 Reset x x
RLB_111 Data Availability xx
RLB_112 Multiple Applications x
Data exchange
DEX_101 Secured motion data export x x
Cryptographic supportCSP_101 Algorithms xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 214
Threats IT ObjectivesAccess
Faults
TestsDesignEnvironmentHardwareMechanical_Origin
Motion_Data
Power_SupplySecurity_DataSoftwareStored_DataAccess
Audit
AuthenticationProcessingReliabilitySecured_Data_Exchange
CSP_102 key generation xx
CSP_103 key distribution xx
CSP_104 key access xx
CSP_105 key destruction xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 215
▼M1
VEHICLE UNIT GENERIC SECURITY TARGET
1.Introduction
This document contains a description of the vehicle unit, of the threats it must
be able to counteract and of the security objectives it must achieve. It specifies
the required security enforcing functions. It states the claimed minimum strength
of security mechanisms and the required level of assurance for the development
and the evaluation.
Requirements referred to in the document, are those of the body of Annex I B.
For clarity of reading, duplication sometimes arises between Annex I B body
requirements and security target requirements. In case of ambiguity between a
security target requirement and the Annex I B body requirement referred by
this security target requirement, the Annex I B body requirement shall prevail.
Annex I B body requirements not referred by security targets are not the subject
of security enforcing functions.
Unique labels have been assigned to threats, objectives, procedural means and
SEF specifications for the purpose of traceability to development and evaluation
documentation.
2.Abbreviations, definitions and references
2.1. Abbreviations
PIN Personal identification number
ROM Read only memorySEF Security enforcing functionTBD To be defined
TOE Target of evaluation
VU Vehicle Unit.
2.2. Definitions
Digital tachograph Recording equipment
Motion data The data exchanged with the motion sensor, repre-
sentative of speed and distance travelled
Physically separated parts Physical components of the VU that are distributed
in the vehicle as opposed to physical components
gathered into the VU casing
Security data The specific data needed to support security enfor-
cing functions (e.g. crypto keys)
System Equipment, people or organisations, involved in
any way with the recording equipment
User Users are to be understood as human user of the
equipment. Normal users of the VU comprise
drivers, controllers, workshops and companies
User data Any data, other than security data, recorded or
stored by the VU, required by Chapter III.12.
2.3. References
ITSEC ITSEC Information Technology Security Evalua-
tion Criteria 1991.
3.Product rationale
3.1. Vehicle unit description and method of use
The VU is intended to be installed in road transport vehicles. Its purpose is
to record, store, display, print and output data related to driver activities.
It is connected to a motion sensor with which it exchanges vehicle's motion
data.
Users identify themselves to the VU using tachograph cards.
The VU records and stores user activities data in its data memory, it also
records user activities data in tachograph cards.
The VU outputs data to display, printer and external devices.1998R2135 — EN — 25.08.2002 — 001.001 — 216
▼M1
The vehicle unit's operational environment while installed in a vehicle is
described in the following figure:
Figure 1
VU operational environment
The VU general characteristics, functions and mode of operations are described
in Chapter II of Annex I B.
The VU functional requirements are specified in Chapter III of Annex I B.
The typical VU is described in the following figure:
Figure 2
Typical VU (…) optional
It must be noted that although the printer mechanism is part of the TOE, the
paper document once produced is not.
3.2. Vehicle unit life cycle
The typical life cycle of the VU is described in the following figure:1998R2135 — EN — 25.08.2002 — 001.001 — 217
▼M1
Figure 3
VU typical life cycle
3.3. Threats
This paragraph describes the threats the VU may face.
3.3.1. Threats to identification and access control policies
T.Access Users could try to access functions not allowed to
them (e.g. drivers gaining access to calibration
function)
T.Identification Users could try to use several identifications or no
identification.1998R2135 — EN — 25.08.2002 — 001.001 — 218
▼M1
3.3.2. Design related threats
T.Faults Faults in hardware, software, communication
procedures could place the VU in unforeseen
conditions compromising its security
T.Tests The use of non invalidated test modes or of
existing back doors could compromise the VU
security
T.Design Users could try to gain illicit knowledge of design
either from manufacturer's material (through theft,
bribery, …) or from reverse engineering
3.3.3. Operation oriented threats
T.Calibration_Parameters Users could try to use mis-calibrated equipment
(through calibration data modification, or through
organisational weaknesses)
T.Card_Data_Exchange Users could try to modify data while exchanged
between VU and tachograph cards (addition, modi-
fication, deletion, replay of signal)
T.Clock Users could try to modify internal clock
T.Environment Users could compromise the VU security through
environmental attacks (thermal, electromagnetic,
optical, chemical, mechanical, …)
T.Fake_Devices Users could try to connect fake devices (motion
sensor, smart cards) to the VU
T.Hardware Users could try to modify VU hardware
T.Motion_Data Users could try to modify the vehicle's motion data
(addition, modification, deletion, replay of signal)
T.Non_Activated Users could use non activated equipment
T.Output_Data Users could try to modify data output (print,
display or download)
T.Power_Supply Users could try to defeat the VU security objec-
tives by modifying (cutting, reducing, increasing)
its power supply
T.Security_Data Users could try to gain illicit knowledge of
security data during security data generation or
transport or storage in the equipment
T.Software Users could try to modify VU software
T.Stored_Data Users could try to modify stored data (security or
user data).
3.4. Security objectives
The main security objective of the digital tachograph system is the following:O.Main The data to be checked by control authorities must
be available and reflect fully and accurately the
activities of controlled drivers and vehicles in
terms of driving, work, availability and rest periods
and in terms of vehicle speed
Therefore the security objectives of the VU, contributing to the global security
objective, are the following:
O.VU_Main The data to be measured and recorded and then to
be checked by control authorities must be available
and reflect accurately the activities of controlled
drivers and vehicles in terms of driving, work,
availability and rest periods and in terms of vehicle
speed
O.VU_Export The VU must be able to export data to external
storage media in such a way as to allow for verifi-
cation of their integrity and authenticity.
3.5. Information technology security objectives
The specific IT security objectives of the VU contributing to its main security
objectives, are the following:
O.Access The VU must control user access to functions and
data1998R2135 — EN — 25.08.2002 — 001.001 — 219
▼M1
O.Accountability The VU must collect accurate accountability data
O.Audit The VU must audit attempts to undermine system
security and should trace them to associated users
O.Authentication The VU should authenticate users and connected
entities (when a trusted path needs to be estab-
lished between entities)
O.Integrity The VU must maintain stored data integrityO.Output The VU must ensure that data output reflects accu-
rately data measured or stored
O.Processing The VU must ensure that processing of inputs to
derive user data is accurate
O.Reliability The VU must provide a reliable serviceO.Secured_Data_Exchange The VU must secure data exchanges with the
motion sensor and with tachograph cards.
3.6. Physical, personnel or procedural means
This paragraph describes physical, personnel or procedural requirements that
contribute to the security of the VU.
3.6.1. Equipment design
M.Development VU developers must ensure that the assignment of
responsibilities during development is done in a
manner which maintains IT security
M.Manufacturing VU manufacturers must ensure that the assignment
of responsibilities during manufacturing is done in
a manner which maintains IT security, and that
during the manufacturing process the VU is
protected from physical attacks which might
compromise IT security.
3.6.2. Equipment delivery and activation
M.Delivery VU manufacturers, vehicle manufacturers and
fitters or workshops must ensure that handling of
non activated VUs is done in a manner which
maintains VU security
M.Activation Vehicle manufacturers and fitters or workshops
must activate the VU after its installation before
the vehicle leaves the premises where installation
took place.
3.6.3. Security data generation and delivery
M.Sec_Data_Generation Security data generation algorithms must be acces-
sible to authorised and trusted persons only
M.Sec_Data_Transport Security data must be generated, transported, and
inserted into the VU, in such a way to preserve
its appropriate confidentiality and integrity.
3.6.4. Cards delivery
M.Card_Availability Tachograph cards must be available and delivered
to authorised persons only
M.Driver_Card_Uniqueness Drivers must possess, at one time, one valid driver
card only
M.Card_Traceability Card delivery must be traceable (white lists, black
lists), and black lists must be used during security
audits.
3.6.5. Recording equipment installation, calibration, and inspection
M.Approved_Workshops Installation, calibration and repair of recording
equipment must be carried by trusted and approved
fitters or workshops
M.Regular_Inpections Recording equipment must be periodically
inspected and calibrated
M.Faithful_Calibration Approved fitters and workshops must enter proper
vehicle parameters in recording equipment during
calibration.1998R2135 — EN — 25.08.2002 — 001.001 — 220
▼M1
3.6.6. Equipment operation
M.Faithful_Drivers Drivers must play by the rules and act responsibly
(e.g. use their driver cards, properly select their
activity for those that are manually selected, …).
3.6.7. Law enforcement control
M.Controls Law enforcement controls must be performed
regularly and randomly, and must include security
audits.
3.6.8. Software upgrades
M.Software_Upgrade Software revisions must be granted security certifi-
cation before they can be implemented in a VU.
4.Security enforcing functions
4.1. Identification and authentication
4.1.1. Motion sensor identification and authentication
The VU shall be able to establish, for every interaction, the identity of the
motion sensor it is connected to.
The identity of the motion sensor shall consist of the sensor approval number
and the sensor serial number.
The VU shall authenticate the motion sensor it is connected to:
— at motion sensor connection,
— at each calibration of the recording equipment,— at power supply recovery.
Authentication shall be mutual and triggered by the VU.
The VU shall periodically (period TBD by manufacturer and more frequently
than once per hour) re-identify and re-authenticate the motion sensor it is
connected to, and ensure that the motion sensor identified during the last cali-
bration of the recording equipment has not been changed.
The VU shall detect and prevent use of authentication data that has been copied
and replayed.
After (TBD by manufacturer and not more than 20) consecutive unsuccessful
authentication attempts have been detected, and/or after detecting that the iden-
tity of the motion sensor has changed while not authorised (i.e. while not during
a calibration of the recording equipment), the SEF shall:
— generate an audit record of the event,
— warn the user,— continue to accept and use non secured motion data sent by the motion
sensor.
4.1.2. User identification and authentication
The VU shall permanently and selectively track the identity of two users, by
monitoring the tachograph cards inserted in respectively the driver slot and the
co-driver slot of the equipment.
The user identity shall consist of:
— a user group:
— DRIVER (driver card),
— CONTROLLER (control card),— WORKSHOP (workshop card),— COMPANY (company card),
— UNKNOWN (no card inserted),
— a user ID, composed of:
— the card issuing Member State code and of the card number,
— UNKNOWN if user group is UNKNOWN.
UNKNOWN identities may be implicitly or explicitly known.
The VU shall authenticate its users at card insertion.The VU shall re-authenticate its users:
— at power supply recovery,1998R2135 — EN — 25.08.2002 — 001.001 — 221
▼M1
— periodically or after occurrence of specific events (TBD by manufacturers
and more frequently than once per day).
Authentication shall be performed by means of proving that the card inserted is
a valid tachograph card, possessing security data that only the system could
distribute. Authentication shall be mutual and triggered by the VU.
In addition to the above, workshops shall be required to be successfully authen-
ticated through a PIN check. PINs shall be at least 4 characters long.
Note: In the case the PIN is transferred to the VU from an outside equipment
located in the vicinity of the VU, PIN confidentiality need not be protected
during the transfer.
The VU shall detect and prevent use of authentication data that has been copied
and replayed.
After 5 consecutive unsuccessful authentication attempts have been detected, the
SEF shall:
— generate an audit record of the event,
— warn the user,
— assume the user as UNKNOWN, and the card as non valid (definition z) and
requirement 007).
4.1.3. Remotely connected company identification and authentication
Company remote connection capability is optional. This paragraph therefore
applies only if this feature is implemented.
For every interaction with a remotely connected company, the VU shall be able
to establish the company's identity.
The remotely connected company's identity shall consist of its company card
issuing Member State code and of its company card number.
The VU shall successfully authenticate the remotely connected company before
allowing any data export to it.
Authentication shall be performed by means of proving that the company owns
a valid company card, possessing security data that only the system could distri-
bute.
The VU shall detect and prevent use of authentication data that has been copied
and replayed.
After 5 consecutive unsuccessful authentication attempts have been detected, the
VU shall:
— warn the remotely connected company.
4.1.4. Management device identification and authentication
VU manufacturers may foresee dedicated devices for additional VU manage-
ment functions (e.g. Software upgrading, security data reloading, …). This
paragraph therefore applies only if this feature is implemented.
For every interaction with a management device, the VU shall be able to estab-
lish the device identity.
Before allowing any further interaction, the VU shall successfully authenticate
the management device.
The VU shall detect and prevent use of authentication data that has been copied
and replayed.
4.2. Access control
Access controls ensure that information is read from, created in, or modified
into the TOE only by those authorised to do so.
It must be noted that the user data recorded by the VU, although presenting
privacy or commercial sensitivity aspects, are not of a confidential nature.
Therefore, the functional requirement related to data read access rights (require-
ment 011) is not the subject of a security enforcing function.
4.2.1. Access control policy
The VU shall manage and check access control rights to functions and to data.
4.2.2. Access rights to functions
The VU shall enforce the mode of operation selection rules (requirements 006 to
009).1998R2135 — EN — 25.08.2002 — 001.001 — 222
▼M1
The VU shall use the mode of operation to enforce the functions access control
rules (requirement 010).
4.2.3. Access rights to data
The VU shall enforce the VU identification data write access rules (requirement
076)
The VU shall enforce the paired motion sensor identification data write access
rules (requirements 079 and 155)
After the VU activation, the VU shall ensure that only in calibration mode, may
calibration data be input into the VU and stored into its data memory (require-
ments 154 and 156).
After the VU activation, the VU shall enforce calibration data write and delete
access rules (requirement 097).
After the VU activation, the VU shall ensure that only in calibration mode, may
time adjustment data be input into the VU and stored into its data memory (This
requirement does not apply to small time adjustments allowed by requirements
157 and 158).
After the VU activation, the VU shall enforce time adjustment data write and
delete access rules (requirement 100).
The VU shall enforce appropriate read and write access rights to security data
(requirement 080).
4.2.4. File structure and access conditions
Application and data files structure and access conditions shall be created during
the manufacturing process, and then locked from any future modification or
deletion.
4.3. Accountability
The VU shall ensure that drivers are accountable for their activities (require-
ments 081, 084, 087, 105a, 105b, 109 and 109a).
The VU shall hold permanent identification data (requirement 075).The VU shall ensure that workshops are accountable for their activities (require-
ments 098, 101 and 109).
The VU shall ensure that controllers are accountable for their activities (require-
ments 102, 103 and 109).
The VU shall record odometer data (requirement 090) and detailed speed data
(requirement 093).
The VU shall ensure that user data related to requirements 081 to 093 and 102
to 105b inclusive are not modified once recorded, except when becoming oldest
stored data to be replaced by new data.
The VU shall ensure that it does not modify data already stored in a tachograph
card (requirements 109 and 109a) except for replacing oldest data by new data
(requirement 110) or in the case described in Appendix 1 Paragraph 2.1 Note.
4.4. Audit
Audit capabilities are required only for events that may indicate a manipulation
or a security breach attempt. It is not required for the normal exercising of rights
even if relevant to security.
The VU shall, for events impairing the security of the VU, record those events
with associated data (requirements 094, 096 and 109).
The events affecting the security of the VU are the following:— Security breach attempts,
— motion sensor authentication failure,
— tachograph card authentication failure,— unauthorised change of motion sensor,— card data input integrity error,— stored user data integrity error,— internal data transfer error,— unauthorised case opening,— hardware sabotage,
— last card session not correctly closed,
— motion data error event,1998R2135 — EN — 25.08.2002 — 001.001 — 223
▼M1
— power supply interruption event,
— VU internal fault.
The VU shall enforce audit records storage rules (requirement 094 and 096).
The VU shall store audit records generated by the motion sensor in its data
memory.
It shall be possible to print, display and download audit records.
4.5. Object re-use
The VU shall ensure that temporary storage objects can be re-used without this
involving inadmissible information flow.
4.6. Accuracy
4.6.1. Information flow control policy
The VU shall ensure that user data related to requirements 081, 084, 087, 090,
093, 102, 104, 105, 105a and 109 may only be processed from the right input
sources:
— vehicle motion data,
— VU's real time clock,
— recording equipment calibration parameters,
— tachograph cards,— user's inputs.
The VU shall ensure that user data related to requirement 109a may only be
entered for the period last card withdrawal — current insertion (requirement
050a).
4.6.2. Internal data transfers
The requirements of this paragraph apply only if the VU makes use of physi-
cally separated parts.
If data are transferred between physically separated parts of the VU, the data
shall be protected from modification.
Upon detection of a data transfer error during an internal transfer, transmission
shall be repeated and the SEF shall generate an audit record of the event.
4.6.3. Stored data integrity
The VU shall check user data stored in the data memory for integrity errors.
Upon detection of a stored user data integrity error, the SEF shall generate an
audit record.
4.7. Reliability of service
4.7.1. Tests
All commands, actions or test points, specific to the testing needs of the manu-
facturing phase of the VU shall be disabled or removed before the VU
activation. It shall not be possible to restore them for later use.
The VU shall run self tests, during initial start-up, and during normal operation
to verify its correct operation. The VU self tests shall include a verification of
the integrity of security data and a verification of the integrity of stored execu-
table code (if not in ROM).
Upon detection of an internal fault during self test, the SEF shall:
— generate an audit record (except in calibration mode) (VU internal fault),
— Preserve the stored data integrity.
4.7.2. Software
There shall be no way to analyse or debug software in the field after the VU
activation.
Inputs from external sources shall not be accepted as executable code.
4.7.3. Physical protection
If the VU is designed so that it can be opened, the VU shall detect any case
opening, except in calibration mode, even without external power supply for a1998R2135 — EN — 25.08.2002 — 001.001 — 224
▼M1
minimum of six months. In such a case, the SEF shall generate an audit record
(It is acceptable that the audit record is generated and stored after power supply
reconnection).
If the VU is designed so that it cannot be opened, it shall be designed such that
physical tampering attempts can be easily detected (e.g. through visual inspec-
tion).
After its activation, the VU shall detect specified (TBD by manufacturer) hard-
ware sabotage.
In the case described above, the SEF shall generate an audit record and the VU
shall: (TBD by manufacturer).
4.7.4. Power supply interruptions
The VU shall detect deviations from the specified values of the power supply,
including cut-off.
In the case described above, the SEF shall:
— generate an audit record (except in calibration mode),
— preserve the secure state of the VU,— maintain the security functions, related to components or processes still
operational,
— preserve the stored data integrity.
4.7.5. Reset conditions
In case of a power supply interruption, or if a transaction is stopped before
completion, or on any other reset conditions, the VU shall be reset cleanly.
4.7.6. Data availability
The VU shall ensure that access to resources is obtained when required and that
resources are not requested nor retained unnecessarily.
The VU must ensure that cards cannot be released before relevant data have
been stored to them (requirements 015 and 016)
In the case described above, the SEF shall generate an audit record of the event.
4.7.7. Multiple applications
If the VU provides applications other than the tachograph application, all appli-
cations shall be physically and/or logically separated from each other. These
applications shall not share security data. Only one task shall be active at a time.
4.8. Data exchange
This paragraph addresses data exchange between the VU and connected devices.
4.8.1. Data exchange with motion sensor
The VU shall verify the integrity and authenticity of motion data imported from
the motion sensor
Upon detection of a motion data integrity or authenticity error, the SEF shall:
— generate an audit record,
— continue to use imported data.
4.8.2. Data exchange with tachograph cards
The VU shall verify the integrity and authenticity of data imported from tacho-
graph cards.
Upon detection of card data integrity or authenticity error, the VU shall:
— generate an audit record,
— not use the data.
The VU shall export data to tachograph smart cards with associated security
attributes such that the card will be able to verify its integrity and authenticity.
4.8.3. Data exchange with external storage media (downloading function)
The VU shall generate an evidence of origin for data downloaded to external
media.
The VU shall provide a capability to verify the evidence of origin of down-
loaded data to the recipient.1998R2135 — EN — 25.08.2002 — 001.001 — 225
▼M1
The VU shall download data to external storage media with associated security
attributes such that downloaded data integrity and authenticity can be verified.
4.9. Cryptographic support
The requirements of this paragraph are applicable only where needed, depending
upon security mechanisms used and upon the manufacturer's solutions.
Any cryptographic operation performed by the VU shall be in accordance with a
specified algorithm and a specified key size.
If the VU generates cryptographic keys, it shall be in accordance with specified
cryptographic key generation algorithms and specified cryptographic key sizes.
If the VU distributes cryptographic keys, it shall be in accordance with specified
key distribution methods.
If the VU accesses cryptographic keys, it shall be in accordance with specified
cryptographic keys access methods.
If the VU destroys cryptographic keys, it shall be in accordance with specified
cryptographic keys destruction methods.
5.Definition of security mechanisms
Required security mechanisms are specified in Appendix 11.
All other security mechanisms are to be defined by manufacturers.
6.Minimum strength of security mechanisms
The minimum strength of the Vehicle Unit security mechanisms is High ,a s
defined in (ITSEC).
7.Level of assurance
The target level of assurance for the Vehicle Unit is ITSEC level E3, as defined
in (ITSEC).
8.Rationale
The following matrixes give a rationale for the SEFs by showing:
— which SEFs or means counteract which threats,
— which SEFs fulfil which IT security objectives.1998R2135 — EN — 25.08.2002 — 001.001 — 226
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
Physical Personnel Procedural Means
Development x x x
Manufacturing x xDelivery x
Activation x x
Security data generation x
Security data transport x
Card availability xOne driver card x
Card traceability x
Approved workshops x xRegular inspection calibration x x x x xFaithful workshops x x
Faithful drivers x
Law enforcement controls x x x xxxx x x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 227
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
Software upgrade x
Security enforcing functions
Identification and authenticationUIA_201 Sensor identification x x x x
UIA_202 Sensor identity x x x x
UIA_203 Sensor authentication x x x xUIA_204 Sensor re-identification and re-
authenticationxx x x
UIA_205 Unforgeable authentication x x x
UIA_206 Authentication failure x x x xUIA_207 Users identification x x x x x xUIA_208 User identity x x x x x x
UIA_209 User authentication x x x x x x
UIA_210 User re-authentication x x x x x xUIA_211 Authentication means x x x x xUIA_212 PIN checks x x x x x x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 228
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
UIA_213 Unforgeable authentication x x x x x
UIA_214 Authentication failure x x x x
UIA_215 Remote user identification x x xx x
UIA_216 Remote user identity x x xx
UIA_217 Remote user authentication x x xx x
UIA_218 Authentication means x x xx
UIA_219 Unforgeable authentication x x xx
UIA_220 Authentication failure x xUIA_221 Management device identification x x xx
UIA_222 Management device authentication x x xx
UIA_223 Unforgeable authentication x x xx
Access Control
ACC_201 Access control policy x x x x x x
ACC_202 Access rights to functions x x x xACC_203 Access rights to functions x x x x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 229
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
ACC_204 VU ID xx
ACC_205 Connected sensor ID x x xACC_206 Calibration data x x x xACC_207 Calibration data x x x
ACC_208 Time adjustment data x x x
ACC_209 Time adjustment data x x xACC_210 Security data xx x
ACC_211 File structure and access condi-
tionsxx x x x
Accountability
ACT_201 Drivers accountability x
ACT_202 VU ID data xx
ACT_203 Workshops accountability x
ACT_204 Controllers accountability x
ACT_205 Vehicle movement accountability x
ACT_206 Accountability data modification xx x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 230
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
ACT_207 Accountability data modification xx x
Audit
AUD_201 Audit records x
AUD_202 Audit events list x x x x x x x xAUD_203 Audit records storage rules x
AUD_204 Sensor audit records x
AUD_205 Audit tools x
Re-useREU_201 Re-use xx x
Accuracy
ACR_201 Information flow control policy x x x xx
ACR_202 Internal transfers xx x x
ACR_203 Internal transfers xx
ACR_204 Stored data integrity xx x
ACR_205 Stored data integrity xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 231
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
Reliability
RLB_201 Manufacturing tests x x x
RLB_202 Self tests x x x x x
RLB_203 Self tests xx xx
RLB_204 Software analysis x x x
RLB_205 Software input xx x x
RLB_206 Case opening x x x x x x x x xRLB_207 Hardware sabotage x x
RLB_208 Hardware sabotage x x
RLB_209 Power supply interruptions xx
RLB_210 Power supply interruptions xx
RLB_211 Reset x x
RLB_212 Data availability xx
RLB_213 Card release x
RLB_214 Card session not correctly closed x▼M11998R2135 — EN — 25.08.2002 — 001.001 — 232
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
RLB_215 Multiple applications x
Data exchange
DEX_201 Secured motion data import x x
DEX_202 Secured motion data import x xDEX_203 Secured card data import x x
DEX_204 Secured card data import x x
DEX_205 Secured data export to cards x x
DEX_206 Evidence of origin xx
DEX_207 Evidence of origin xx
DEX_208 Secured export to external media x xCryptographic support
CSP_201 Algorithms xx
CSP_202 key generation xx
CSP_203 key distribution xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 233
Threats IT ObjectivesAccess
IdentificationFaults
Tests
Design
Calibration_Parameters
Card_Data_Exchange
Clock
Environment
Fake_Devices
Hardware
Motion_Data
Non_Activated
Output_Data
Power_Supply
Security_Data
Software
Stored_DataAccess
Accountability
Audit
Authentication
Integrity
Output
Processing
Reliability
Secured_Data_Exchange
CSP_204 key access xx
CSP_205 key destruction xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 234
▼M1
TACHOGRAPH CARD GENERIC SECURITY TARGET
1.Introduction
This document contains a description of the tachograph card, of the threats it
must be able to counteract and of the security objectives it must achieve. It
specifies the required security enforcing functions. It states the claimed
minimum strength of security mechanisms, and the required level of assurance
for the development and the evaluation.
Requirements referred to in the document, are those of the body of Annex I B.
For clarity of reading, duplication sometimes arises between Annex I B body
requirements and security target requirements. In case of ambiguity between a
security target requirement and the Annex I B requirement referred by this
security target requirement, the Annex I B body requirement shall prevail.
Annex I B body requirements not referred by security targets are not the subject
of security enforcing functions.
A tachograph card is a standard smart card carrying a dedicated tachograph
application, and shall comply with up-to-date functional and assurance security
requirements applicable to smart cards. This security target therefore incorpo-
rates only the extra security requirements needed by the tachograph application.
Unique labels have been assigned to threats, objectives, procedural means and
SEF specifications for the purpose of traceability to development and evaluation
documentation.
2.Abbreviations, definitions and references
2.1. Abbreviations
IC Integrated Circuit (electronic component designed
to perform processing and/or memory functions)
OS Operating systemPIN Personal identification numberROM Read only memorySFP Security functions policyTBD To be definedTOE Target of evaluationTSF TOE security functionVU Vehicle unit.
2.2. Definitions
Digital tachograph Recording equipment.
Sensitive data Data stored by the tachograph card that need to be
protected for integrity, unauthorised modification
and confidentiality (where applicable for security
data). Sensitive data includes security data and
user data.
Security data The specific data needed to support security enfor-
cing functions (e.g. crypto keys).
System Equipment, people or organisations involved in
any way with the recording equipment.
User Any entity (human user or external IT entity)
outside the TOE that interacts with the TOE
(when not used in the expression ‘user data’).
User data Sensitive data stored in the tachograph card, other
than security data. User data include identification
data and activity data.
Identification data Identification data include card identification data
and cardholder identification data.
Card identification data User data related to card identification as defined
by requirements 190, 191, 192, 194, 215, 231 and
235.
Cardholder identification data User data related to cardholder identification as
defined by requirements 195, 196, 216, 232 and
236.
Activity data Activity data include cardholder activities data,
events and faults data and control activity data.1998R2135 — EN — 25.08.2002 — 001.001 — 235
▼M1
Cardholder activities data User data related to the activities carried by the
cardholder as defined by requirements 197, 199,
202, 212, 212a, 217, 219, 221, 226, 227, 229,
230a, 233 and 237.
Events and faults data User data related to events or faults as defined by
requirements 204, 205, 207, 208 and 223.
Control activity data User data related to law enforcement controls as
defined by requirements 210 and 225.
2.3. References
ITSEC ITSEC Information Technology Security Evalua-
tion Criteria 1991
IC PP Smartcard Integrated Circuit Protection Profile —
version 2.0 — issue September 1998. Registered
at French certification body under the number PP/
9806
ES PP Smart Card Integrated Circuit With Embedded
Software Protection Profile — version 2.0 — issueJune 99. Registered at French certification body
under the number PP/9911
3.Product Rationale
3.1. Tachograph card description and method of use
A tachograph card is a smart card, as described in (IC PP) and (ES PP), carrying
an application intended for its use with the recording equipment.
The basic functions of the tachograph card are:— to store card identification and card holder identification data. These data are
used by the vehicle unit to identify the cardholder, provide accordingly func-
tions and data access rights, and ensure cardholder accountability for his
activities,
— to store cardholder activities data, events and faults data and control activ-
ities data, related to the cardholder.
A tachograph card is therefore intended to be used by a card interface device of
a vehicle unit. It may also be used by any card reader (e.g. of a personal
computer) which shall have full read access right on any user data.
During the end-usage phase of a tachograph card life cycle (phase 7 of life-cycle
as described in (ES PP)), vehicle units only may write user data to the card.
The functional requirements for a tachograph card are specified in Annex I B
body text and Appendix 2.
3.2. Tachograph card life cycle
The tachograph card life cycle conforms to smart card life cycle described in
(ES PP).
3.3. Threats
In addition to the smart card general threats listed in (ES PP) and (IC PP), the
tachograph card may face the following threats:
3.3.1. Final aims
The final aim of attackers will be to modify user data stored within the TOE.
T.Ident_Data A successful modification of identification data
held by the TOE (e.g. the type of card, or the
card expiry date or the cardholder identification
data) would allow a fraudulent use of the TOE
and would be a major threat to the global security
objective of the system.
T.Activity_Data A successful modification of activity data stored in
the TOE would be a threat to the security of the
TOE.
T.Data_Exchange A successful modification of activity data (addi-
tion, deletion, modification) during import or
export would be a threat to the security of the
TOE.1998R2135 — EN — 25.08.2002 — 001.001 — 236
▼M1
3.3.2. Attack paths
TOE's assets may be attacked by:
— trying to gain illicit knowledge of TOE's hardware and software design and
especially of its security functions or security data. Illicit knowledge may be
gained though attacks to designer or manufacturer material (theft, bribery,
…) or through direct examination of the TOE (physical probing, inference
analysis, …),
— taking advantage of weaknesses in TOE design or realisation (exploit errors
in hardware, errors in software, transmission faults, errors induced in TOE
by environmental stress, exploit weaknesses of security functions such as
authentication procedures, data access control, cryptographic operations, …),
— modifying the TOE or its security functions through physical, electrical or
logical attacks or combination of these.
3.4. Security Objectives
The main security objective of the entire digital tachograph system is the
following:
O.Main The data to be checked by control authorities must
be available and reflect fully and accurately the
activity of controlled drivers and vehicles in terms
of driving, work, availability and rest period and in
terms of vehicle speed.
Therefore the main security objectives of the TOE, contributing to this global
security objective are the following:
O.Card_Identification_Data The TOE must preserve card identification data
and cardholder identification data stored during
card personalisation process,
O.Card_Activity_Storage The TOE must preserve user data stored in the
card by vehicle units.
3.5. Information technology security objectives
In addition to the smart card general security objectives listed in (ES PP) and
(IC PP), the specific IT security objectives of the TOE that contributes to its
main security objectives during its end-usage life-cycle phase are the following:
O.Data_Access The TOE must limit user data write access rights
to authenticated vehicle units,
O.Secure_Communications The TOE must be able to support secure communi-
cation protocols and procedures between the card
and the card interface device when required by
the application.
3.6. Physical, personnel or procedural means
The physical, personnel or procedural requirements that contribute to the
security of the TOE are listed in (ES PP) and (IC PP) (chapters security objec-
tives for the environment).
4.Security enforcing functions
This paragraph refines some of the permitted operations such as assignment or
selection of (ES PP) and provides additional SEF functional requirements.
4.1. Compliance to protection profiles
The TOE shall comply with (IC PP).
The TOE shall comply with (ES PP) as refined further.
4.2. User identification and authentication
The card must identify the entity in which it is inserted and know whether it is
an authenticated vehicle unit or not. The card may export any user data what-
ever the entity it is connected to, except the control card which may export
card holder identification data to authenticated vehicle units only (such that a
controller is ensured that the vehicle unit is not a fake one by seeing his name
on display or printouts).1998R2135 — EN — 25.08.2002 — 001.001 — 237
▼M1
4.2.1. User identification
Assignment (FIA_UID.1.1) List of TSF mediated actions : none.
Assignment (FIA_ATD.1.1) List of security attributes :
USER_GROUP: VEHICLE_UNIT, NON_VEHICLE_UNIT,
USER_ID: Vehicle Registration Number (VRN) and regis-
tering Member State Code (USER_ID is known
for USER_GROUP = VEHICLE_UNIT only).
4.2.2. User authentication
Assignment (FIA_UAU.1.1) List of TSF mediated actions:
— Driver and Workshop cards: export user data with security attributes (card
data download function),
— Control card: export user data without security attributes except cardholder
identification data.
Authentication of a vehicle unit shall be performed by means of proving that it
possesses security data that only the system could distribute.
Selection (FIA_UAU.3.1 and FIA_UAU.3.2): prevent.
Assignment (FIA_UAU.4.1) Identified authentication mechanism(s) : any
authentication mechanism.
The Workshop card shall provide an additional authentication mechanism by
checking a PIN code (This mechanism is intended for the vehicle unit to ensure
the identity of the card holder, it is not intended to protect workshop card
content).
4.2.3. Authentication failures
The following assignments describe the card reaction for each single user
authentication failure.
Assignment (FIA_AFL.1.1) Number :1 , list of authentication events : authentica-
tion of a card interface device.
Assignment (FIA_AFL.1.2) List of actions:
— warn the entity connected,
— assume the user as NON_VEHICLE_UNIT.
The following assignments describe the card reaction in the case of failure of
the additional authentication mechanism required in UIA_302.
Assignment (FIA_AFL.1.1) Number :5 , list of authentication events : PIN
checks (workshop card).
Assignment (FIA_AFL.1.2) List of actions:
— warn the entity connected,
— block the PIN check procedure such that any subsequent PIN check attempt
will fail,
— be able to indicate to subsequent users the reason of the blocking.
4.3. Access control
4.3.1. Access control policy
During end-usage phase of its life cycle, the tachograph card is the subject of
one single access control security function policy (SFP) named AC_SFP.
Assignment (FDP_ACC.2.1) Access control SFP : AC_SFP.
4.3.2. Access control functions
Assignment (FDP_ACF.1.1) Access control SFP : AC_SFP.
Assignment (FDP_ACF.1.1) Named group of security attributes :
USER_GROUP.
Assignment (FDP_ACF.1.2) Rules governing access among controlled subjects
and controlled objects using controlled operations on controlled objects :
GENERAL_READ: User data may be read from the TOE by any user,
except cardholder identification data which may be
read from control cards by VEHICLE_UNIT only.
IDENTIF_WRITE: Identification data may only be written once and
before the end of phase 6 of card's life-cycle. No1998R2135 — EN — 25.08.2002 — 001.001 — 238
▼M1
user may write or modify identification data during
end-usage phase of card's life-cycle.
ACTIVITY_WRITE: Activity data may be written to the TOE by VEHI-
CLE_UNIT only.
SOFT_UPGRADE: No user may upgrade TOE's software.FILE_STRUCTURE: Files structure and access conditions shall be
created before end of phase 6 of TOE's life-cycle
and then locked from any future modification or
deletion by any user.
4.4. Accountability
The TOE shall hold permanent identification data.
There shall be an indication of the time and date of the TOE's personalisation.
This indication shall remain unalterable.
4.5. Audit
The TOE must monitor events that indicate a potential violation of its security.
Assignment (FAU_SAA.1.2) Subset of defined auditable events:
— cardholder authentication failure (5 consecutive unsuccessful PIN checks),
— self test error,— stored data integrity error,
— activity data input integrity error.
4.6. Accuracy
4.6.1. Stored data integrity
Assignment (FDP_SDI.2.2) Actions to be taken : warn the entity connected,
4.6.2. Basic data authentication
Assignment (FDP_DAU.1.1) List of objects or information types : activity data.
Assignment (FDP_DAU.1.2) List of subjects : any.
4.7. Reliability of service
4.7.1. Tests
Selection (FPT_TST.1.1): during initial start-up, periodically during normal
operation.
Note: during initial start-up means before code is executed (and not necessarily
during Answer To Reset procedure).
The TOE's self tests shall include the verification of the integrity of any soft-
ware code not stored in ROM.
Upon detection of a self test error the TSF shall warn the entity connected.
After OS testing is completed, all testing-specific commands and actions shall
be disabled or removed. It shall not be possible to override these controls and
restore them for use. Command associated exclusively with one life cycle state
shall never be accessed during another state.
4.7.2. Software
There shall be no way to analyse, debug or modify TOE's software in the field.
Inputs from external sources shall not be accepted as executable code.
4.7.3. Power supply
The TOE shall preserve a secure state during power supply cut-off or variations.
4.7.4. Reset conditions
If power is cut (or if power variations occur) from the TOE, or if a transaction is
stopped before completion, or on any other reset conditions, the TOE shall be
reset cleanly.1998R2135 — EN — 25.08.2002 — 001.001 — 239
▼M1
4.8. Data exchange
4.8.1. Data exchange with a vehicle unit
The TOE shall verify the integrity and authenticity of data imported from a
vehicle unit.
Upon detection of an imported data integrity error, the TOE shall:
— warn the entity sending the data,
— not use the data.
The TOE shall export user data to the vehicle unit with associated security attri-
butes, such that the vehicle unit will be able to verify the integrity and
authenticity of data received.
4.8.2. Export of data to a non-vehicle unit (download function)
The TOE shall be able to generate an evidence of origin for data downloaded to
external media.
The TOE shall be able to provide a capability to verify the evidence of origin of
downloaded data to the recipient.
The TOE shall be able to download data to external storage media with asso-
ciated security attributes such that downloaded data integrity can be verified.
4.9. Cryptographic support
If the TSF generates cryptographic keys, it shall be in accordance with specified
cryptographic key generation algorithms and specified cryptographic key sizes.
Generated cryptographic session keys shall have a limited (TBD by manufac-
turer and not more than 240) number of possible use.
If the TSF distributes cryptographic keys, it shall be in accordance with speci-
fied cryptographic key distribution methods.
5.Definition of security mechanisms
Required security mechanisms are specified in Appendix 11.
All other security mechanisms are to be defined by the TOE manufacturer.
6.Claimed minimum strength of mechanisms
The minimum strength of mechanisms for the Tachograph Card is High as
defined in (ITSEC).
7.Level of Assurance
The target level of assurance for the Tachograph Card is ITSEC level E3,a s
defined in (ITSEC).
8.Rationale
The following matrixes give a rationale for the additional SEFs by showing:
— which SEFs counteract which threats,
— which SEFs fulfil which IT security objectives.1998R2135 — EN — 25.08.2002 — 001.001 — 240
Threats IT ObjectivesT.CLON*
T.DIS_ES2T.T_ES
T.T_CMD
T.MOD_SOFT*T.MOD_LOADT.MOD_EXET.MOD_SHAREIdent_DataActivity_DataData_Exchange
O.TAMPER_ES
O.CLON*O.OPERATE*O.FLAW*O.DIS_MECHANISM2O.DIS_MEMORY*O.MOD_MEMORY*
Data_Access
Secured_Communications
UIA_301 Authentication means x
UIA_302 PIN checks x
ACT_301 Identification data
ACT_302 Personalisation date
RLB_301 Software integrity xx
RLB_302 Self tests xx
RLB_303 Manufacturing tests x x x x
RLB_304 Software analysis x x x x x
RLB_305 Software input x x x x xRLB_306 Power supply x xxx
RLB_307 Reset xx
DEX_301 Secured data import xx
DEX_302 Secured data import xx
DEX_303 Secured data export to VU xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 241
Threats IT ObjectivesT.CLON*
T.DIS_ES2T.T_ES
T.T_CMD
T.MOD_SOFT*T.MOD_LOADT.MOD_EXET.MOD_SHAREIdent_DataActivity_DataData_Exchange
O.TAMPER_ES
O.CLON*O.OPERATE*O.FLAW*O.DIS_MECHANISM2O.DIS_MEMORY*O.MOD_MEMORY*
Data_Access
Secured_Communications
DEX_304 Evidence of origin xx
DEX_305 Evidence of origin xx
DEX_306 Secured export to external media xx
CSP_301 key generation xx
CSP_302 key distribution xx▼M11998R2135 — EN — 25.08.2002 — 001.001 — 242
▼M1
Appendix 11
COMMON SECURITY MECHANISMS
CONTENTS
1. Generalities … . ..............................................................
1.1. References … . . ..............................................................
1.2. Notations and abbreviated terms … . .............................................
2. Cryptographic systems and algorithms … . . .......................................
2.1. Cryptographic systems … . . . ...................................................
2.2. Cryptographic algorithms … . ...................................................
2.2.1. RSA algorithm … ............................................................
2.2.2. Hash algorithm … ............................................................
2.2.3. Data encryption algorithm … ...................................................
3. Keys and certificates … ........................................................
3.1. Keys generation and distribution … . .............................................
3.1.1. RSA keys generation and distribution … . . . .......................................
3.1.2. RSA test keys … .............................................................
3.1.3. Motion sensor keys … . ........................................................
3.1.4. T-DES session keys generation and distribution … ..................................
3.2. Keys … . . ...................................................................
3.3. Certificates … . . ..............................................................
3.3.1. Certificates content … . ........................................................
3.3.2. Certificates issued … . . ........................................................
3.3.3. Certificate verification and unwrapping … . .......................................
4. Mutual authentication mechanism … .............................................
5. VU-cards data transfer confidentiality, integrity and authentication mechanism … . . ......
5.1. Secure messaging … . . ........................................................
5.2. Treatment of secure messaging errors … . . . .......................................
5.3. Algorithm to compute cryptographic checksums … .................................
5.4. Algorithm to compute cryptograms for confidentiality DOs … . .......................
6. Data download digital signature mechanisms … . . ..................................
6.1. Signature generation … ........................................................
6.2. Signature verification … .......................................................1998R2135 — EN — 25.08.2002 — 001.001 — 243
▼M1
1. GENERALITIES
This appendix specifies the security mechanisms ensuring:
— the mutual authentication between VUs and tachograph cards, including
session key agreement,
— the confidentiality, integrity and authentication of data transferred between
VUs and tachograph cards,
— the integrity and authentication of data downloaded from VUs to external
storage media,
— the integrity and authentication of data downloaded from tachograph cards to
external storage media.
1.1. References
The following references are used in this Appendix:
SHA-1 National Institute of Standards and Technology (NIST). FIPS
Publication 180-1: Secure Hash Standard. April 1995
PKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Standard.
Version 2.0. October 1998
TDES National Institute of Standards and Technology (NIST). FIPS
Publication 46-3: Data Encryption Standard. Draft 1999
TDES-OP ANSI X9.52, Triple Data Encryption Algorithm Modes of
Operation. 1998
ISO/IEC 7816-4 Information Technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 4: Interindustry
commands for interexchange. First edition: 1995 + Amend-ment 1: 1997
ISO/IEC 7816-6 Information Technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 6: Interindustry data
elements. First edition: 1996 + Cor 1: 1998
ISO/IEC 7816-8 Information Technology — Identification cards — Integrated
circuit(s) cards with contacts — Part 8: Security related inter-
industry commands. First edition 1999
ISO/IEC 9796-2 Information Technology — Security techniques — Digital
signature schemes giving message recovery — Part 2:
Mechanisms using a hash function. First edition: 1997
ISO/IEC 9798-3 Information Technology — Security techniques — Entity
authentication mechanisms — Part 3: Entity authentication
using a public key algorithm. Second edition 1998
ISO 16844-3 Road vehicles — Tachograph systems — Part 3: Motion
sensor interface.
1.2. Notations and abbreviated terms
The following notations and abbreviated terms are used in this Appendix:
(K
a,Kb,Kc) a key bundle for use by the triple data encryption algorithm
CA Certification authorityCAR Certification authority reference
CC Cryptographic checksum
CG CryptogramCH Command headerCHA Certificate holder authorisationCHR Certificate holder reference
D() Decryption with DES
DE Data elementDO Data objectd RSA private key, private exponent
e RSA public key, public exponent
E() Encryption with DES
EQT Equipment1998R2135 — EN — 25.08.2002 — 001.001 — 244
▼M1
Hash() hash value, an output of hash
Hash hash function
KID Key identifierKm TDES key. Master Key defined in ISO 16844-3Km
vuTDES key inserted in vehicle units
KmwcTDES key inserted in workshop cards
m message representative an integer between 0 and n-1
n RSA keys, modulus
PB Padding bytesPI Padding indicator byte (for use in cryptogram for confidenti-
ality DO)
PV Plain values signature representative, an integer between 0 and n-1
SSC Send sequence counter
SM Secure messaging
TCBC TDEA cipher block chaining mode of operationTDEA Triple data encryption algorithmTLV Tag length value
VU Vehicle unit
X.C the certificate of user X issued by a certification authorityX.CA a certification authority of user XX.CA.PK
oX.C the operation of unwrapping a certificate to extract a public
key. It is an infix operator, whose left operand is the public
key of a certification authority, and whose right operand is
the certificate issued by that certification authority. The
outcome is the public key of the user X whose certificate is
the right operand,
X.PK public key of a user XX.PK[I] RSA encipherment of some information I, using the public key
of user X
X.SK RSA private key of a user XX.SK[I] RSA encipherment of some information I, using the private
key of user X
′xx′ a Hexadecimal value
|| concatenation operator.
2. CRYPTOGRAPHIC SYSTEMS AND ALGORITHMS
2.1. Cryptographic systems
Vehicle units and tachograph cards shall use a classical RSA public-key crypto-
graphic system to provide the following security mechanisms:
— authentication between vehicle units and cards,
— transport of Triple-DES session keys between vehicle units and tachograph
cards,
— digital signature of data downloaded from vehicle units or tachograph cards
to external media.
Vehicle units and tachograph cards shall use a Triple DES symmetric crypto-
graphic system to provide a mechanism for data integrity during user data
exchange between vehicle units and tachograph cards, and to provide, where
applicable, confidentiality of data exchange between vehicle units and tacho-
graph cards.1998R2135 — EN — 25.08.2002 — 001.001 — 245
▼M1
2.2. Cryptographic algorithms
2.2.1. RSA algorithm
The RSA algorithm is fully defined by the following relations:
A more comprehensive description of the RSA function can be found in refer-
ence (PKCS1).
Public exponent, e, for RSA calculations will be different from 2 in all gener-
ated RSA keys.
2.2.2. Hash algorithm
The digital signature mechanisms shall use the SHA-1 hash algorithm as defined
in reference (SHA-1).
2.2.3. Data encryption algorithm
DES based algorithms shall be used in Cipher Block Chaining mode of opera-
tion.
3. KEYS AND CERTIFICATES3.1. Keys generation and distribution
3.1.1. RSA keys generation and distribution
RSA keys shall be generated through three functional hierarchical levels:— European level,
— Member State level,
— Equipment level.
At European level, a single European key pair (EUR.SK and EUR.PK) shall be
generated. The European private key shall be used to certify the Member States
public keys. Records of all certified keys shall be kept. These tasks shall be
handled by a European certification authority, under the authority and responsi-
bility of the European Commission.
At Member State level, a Member State key pair (MS.SK and MS.PK) shall be
generated. Member States public keys shall be certified by the European Certi-
fication Authority. The Member State private key shall be used to certify public
keys to be inserted in equipment (vehicle unit or tachograph card). Records of
all certified public keys shall be kept with the identification of the equipment to
which it is intended. These tasks shall be handled by a Member State certifica-
tion authority. A Member State may regularly change its key pair.
At equipment level, one single key pair (EQT.SK and EQT.PK) shall be gener-
ated and inserted in each equipment. Equipment public keys shall be certified by
a Member State certification authority. These tasks may be handled by equip-
ment manufacturers, equipment personalisers or Member State authorities. This
key pair is used for authentication, digital signature and encipherement services
Private keys confidentiality shall be maintained during generation, transport (if
any) and storage.1998R2135 — EN — 25.08.2002 — 001.001 — 246
▼M1
The following picture summarises the data flow of this process:
3.1.2. RSA test keys
For the purpose of equipment testing (including interoperability tests) the
European certification authority shall generate a different single European test
key pair and at least two Member State test key pairs, the public keys of whichshall be certified with the European private test key. Manufacturers shall insert,
in equipment undergoing type approval tests, test keys certified by one of these
Member State test keys.
3.1.3. Motion sensor keys
The confidentiality of the three TDES keys described below shall be appropri-
ately maintained during generation, transport (if any) and storage.
In order to support recording equipment compliant with ISO 16844, the
European certification authority and the Member State certification authorities
shall, in addition, ensure the following:
The European certification authority shall generate Km
VUand KmWC, two inde-
pendent and unique Triple DES keys, and generate Km as:
The European certification authority shall forward these keys, under appropri-ately secured procedures, to Member States certification authorities at their
request.1998R2135 — EN — 25.08.2002 — 001.001 — 247
▼M1
Member States certification authorities shall:
— use Km to encrypt motion sensor data requested by motion sensor manufac-
turers (data to be encrypted with Km is defined in ISO 16844-3),
— forward KmVUto vehicle unit manufacturers, under appropriately secured
procedures, for insertion in vehicle units,
— ensure that KmWCwill be inserted in all workshop cards (SensorInstallation-
SecData in Sensor_Installation_Data elementary file) during card
personalisation.
3.1.4. T-DES session keys generation and distribution
Vehicle units and tachograph cards shall, as a part of the mutual authentication
process, generate and exchange necessary data to elaborate a common Triple
DES session key. This exchange of data shall be protected for confidentiality
through an RSA crypt-mechanism.
This key shall be used for all subsequent cryptographic operations using secure
messaging. Its validity shall expire at the end of the session (withdrawal of the
card or reset of the card) and/or after 240 use (one use of the key = one
command using secure messaging sent to the card and associated response).
3.2. Keys
RSA keys shall have (whatever the level) the following lengths: modulus n1024
bits, public exponent e64 bits maximum, private exponent d1024 bits.
Triple DES keys shall have the form (Ka,Kb,Ka) where Kaand Kbare indepen-
dent 64 bits long keys. No parity error detecting bits shall be set.
3.3. Certificates
RSA Public key certificates shall be ‘non self-descriptive’ ‘Card Verifiable’
certificates (Ref.: ISO/IEC 7816-8)
3.3.1. Certificates content
RSA Public key certificates are built with the following data in the following
order:
Data Format Bytes Obs
CPI INTEGER 1 Certificate profile identifier ( ′01′for this
version)
CAR OCTET STRING 8 Certification authority referenceCHA OCTET STRING 7 Certificate holder authorisation
EOV TimeReal 4 Certificate end of validity. Optional, ′FF′
padded if not used
CHR OCTET STRING 8 Certificate holder reference
n OCTET STRING 128 Public key (modulus)
e OCTET STRING 8 Public key (public exponent)
164
Notes:
1. The ‘Certificate Profile Identifier’ (CPI) delineates the exact structure of
an authentication certificate. It can be used as an equipment internal iden-
tifier of a relevant headerlist which describes the concatenation of Data
Elements within the certificate.1998R2135 — EN — 25.08.2002 — 001.001 — 248
▼M1
The headerlist associated with this certificate content is as follows:
2. The ‘Certification Authority Reference’ (CAR) has the purpose of identi-
fying the certificate issuing CA, in such a way that the data element can
be used at the same time as an authority key identifier to reference the
public key of the certification authority (for coding, see Key Identifier
below).
3. The ‘Certificate Holder Authorisation’ ((CHA) is used to identify the
rights of the certificate holder. It consists of the Tachograph Application
ID and of the type of equipment to which the certificate is intended(according to EquipmentType data element, ‘00’ for a Member State).
4. ‘Certificate Holder Reference’ (CHR) has the purpose of identifying
uniquely the certificate holder, in such a way that the Data Element can
be used at the same time as a Subject Key Identifier to reference the
Public Key of the certificate holder.
5. Key Identifiers uniquely identify certificate holder or certification autho-
rities. They are coded as follows:
5.1. Equipment (VU or Card):
Data Equipment
serial numberDate Type Manufacturer
Length 4 Bytes 2 Bytes 1 Byte 1 Byte
Value Integer mm yy BCD
codingManufacturer
specificManufacturer
code
In the case of a VU, the manufacturer, when requesting certificates, may or
may not know the identification of the equipment in which the keys will be
inserted.
In the first case, the manufacturer will send the equipment identification
with the public key to its Member State authority for certification. The
certificate will then contain the equipment identification, and the manufac-
turer must ensure that keys and certificate are inserted in the intended
equipment. The Key identifier has the form shown above.
In the later case, the manufacturer must uniquely identify each certificate
request and send this identification with the public key to its Member State
authority for certification. The certificate will contain the request identifica-
tion. The manufacturer must feed back its Member State authority with the
assignment of key to equipment (i.e. certificate request identification,
equipment identification) after key installation in the equipment. The key
identifier has the following form:
Data Certificate
request serial
numberDate Type Manufacturer
Length 4 Bytes 2 Bytes 1 Byte 1 Byte
Value BCD coding mm jj BCD
coding′FF′ Manufacturer
code1998R2135 — EN — 25.08.2002 — 001.001 — 249
▼M1
5.2. Certification Authority:
Data Authority iden-
tificationKey serial
numberAdditional info Identifier
Length 4 Bytes 1 Byte 2 Bytes 1 Byte
Value 1 Byte nation
numerical codeInteger additional
coding (CA
specific)′01′
3 Bytes nation
alphanumerical
code′FF FF′if not
used
The key serial number is used to distinguish the different keys of a
Member State, in the case the key is changed.
6. Certificate verifiers shall implicitly know that the public key certified is
an RSA key relevant to authentication, digital signature verification and
encipherement for confidentiality services (the certificate contains no
Object Identifier to specify it).
3.3.2. Certificates issued
The certificate issued is a digital signature with partial recovery of the certifi-
cate content in accordance with ISO/IEC 9796-2, with the ‘Certification
Authority Reference’ appended.
With certificate content
Notes:
1. This certificate is 194 bytes long.2. CAR, being hidden by the signature, is also appended to the signature,
such that the public key of the certification authority may be selected
for the verification of the certificate.
3. The certificate verifier shall implicitly know the algorithm used by the
certification authority to sign the certificate.
4. The headerlist associated with this issued certificate is as follows:
3.3.3. Certificate verification and unwrapping
Certificate verification and unwrapping consists in verifying the signature in
accordance with ISO/IEC 9796-2, retrieving the certificate content and the
public key contained: X.PK = X.CA.PKoX.C, and verifying the validity of the
certificate.1998R2135 — EN — 25.08.2002 — 001.001 — 250
▼M1
It involves the following steps:
verify signature and retrieve content:
— from X.C retrieve Sign, Cn′and CAR′:
— from CAR′select appropriate Certification Authority Public Key (if not done
before through other means)
— open Sign with CA Public Key: Sr ′= X.CA.PK [Sign],
— check Sr′starts with′6A′and ends with′BC′
— compute Cr′and H′from:
— Recover certificate content C ′=Cr′|| Cn′,
— check Hash (C′)=H′
If the checks are OK the certificate is a genuine one, its content is C ′.
Verify validity. From C ′:
— if applicable, check End of validity date,
Retrieve and store public key, Key Identifier, Certificate Holder Authorisation
and Certificate End of Validity from C ′:
— X.PK = n||e
— X.KID = CHR— X.CHA = CHA— X.EOV = EOV.
4. MUTUAL AUTHENTICATION MECHANISM
Mutual authentication between cards and VUs is based on the following prin-
ciple:
Each party shall demonstrate to the other that it owns a valid key pair, the
public key of which has been certified by a Member State certification
authority, itself being certified by the European certification authority.
Demonstration is made by signing with the private key a random number sent
by the other party, who must recover the random number sent when verifying
this signature.
The mechanism is triggered at card insertion by the VU. It starts with the
exchange of certificates and unwrapping of public keys, and ends with the
setting of a session key.
The following protocol shall be used (arrows indicate commands and data
exchanged (see Appendix 2)):1998R2135 — EN — 25.08.2002 — 001.001 — 251
▼M1
1998R2135 — EN — 25.08.2002 — 001.001 — 252
▼M1
1998R2135 — EN — 25.08.2002 — 001.001 — 253
▼M1
5. VU-CARDS DATA TRANSFER CONFIDENTIALITY, INTEGRITY AND
AUTHENTICATION MECHANISMS
5.1. Secure messaging
VU-cards data transfers integrity shall be protected through Secure Messaging in
accordance with references (ISO/IEC 7816-4) and (ISO/IEC 7816-8).
When data need to be protected during transfer, a cryptographic checksum data
object shall be appended to the data objects sent within the command or the
response. The cryptographic checksum shall be verified by the receiver.
The cryptographic checksum of data sent within a command shall integrate the
command header, and all data objects sent (= > CLA = ′0C′, and all data objects
shall be encapsulated with tags in which b1 = 1).
The response status-information bytes shall be protected by a cryptographic
checksum when the response contains no data field.
Cryptographic checksums shall be four bytes long.The structure of commands and responses when using secure messaging is
therefore the following:
The DOs used are a partial set of the Secure Messaging DOs described in ISO/
IEC 7816-4:
Tag Mnemonic Meaning
′81′ TPVPlain Value not BER-TLV coded data (to be protected by
CC)
′97′ TLEValue of Le in the unsecured command (to be protected by
CC)
′99′ TSWStatus-Info (to be protected by CC)
′8E′ TCCCryptographic Checksum
′87′ TPI CGPadding Indicator Byte || Cryptogram (Plain Value not coded
in BER-TLV)
Given an unsecured command response pair:
Command header Command body
CLA INS P1 P2 (Lc-field) (Data field) (Le-field)
four bytes L bytes, denoted as B1to BL
Response body Response trailer
(Data field) SW1 SW2L
rdata bytes two bytes
The corresponding secured command response pair is:
Secured command:
Command
header
(CH)Command body
CLA INS
P1 P2(New Lcfield)(New Data field) (New Lefield)
′OC′ Length of
new data
fieldTPVLPVPV TLELLELeTCCLCCCC′00′
′81′ LcData
field′97′′ 01′ Le′8E′′ 04′ CC1998R2135 — EN — 25.08.2002 — 001.001 — 254
▼M1
Data to be integrated in checksum = CH || PB || TPV|| LPV|| PV || TLE|| LLE|| Le||
PB
PB = padding bytes (80 .. 00) in accordance with ISO-IEC 7816-4 and ISO 9797
method 1.
DOs PV and LE are present only when there is some corresponding data in the
unsecured command.
Secured response:
1. Case where response data field is not empty and needs not to be protected for
confidentiality:
Response body Response trailer
(New data field) new SW1
SW2
TPVLPVPV TCCLCCCC
′81′ LrData
field′8E′′ 04′ CC
Data to be integrated in checksum = TPV|| LPV|| PV || PB
2. Case where response data field is not empty and needs to be protected for
confidentiality:
Response body Response trailer
(New data field) new SW1
SW2
TPI CGLPI CGPI CG TCCLCCCC
′87′ PI || CG′8E′′ 04′ CC
Data to be carried by CG: non BER-TLV coded data and padding bytes.
Data to be integrated in checksum = TPI CG|| LPI CG|| PI CG || PB
3. Case where response data field is empty:
Response body Response trailer
(New data field) new SW1
SW2
TSWLSWSW TCCLCCCC
′99′′ 02′ New
SW1
SW2′8E′′ 04′ CC
Data to be integrated in checksum = TSW|| LSW|| SW || PB
5.2. Treatment of secure messaging errors
When the tachograph card recognises an SM error while interpreting a
command, then the status bytes must be returned without SM. In accordance
with ISO/IEC 7816-4, the following status bytes are defined to indicate SM
errors:
′66 88′: verification of cryptographic checksum failed,
′69 87′: expected SM data objects missing,
′69 88′: SM data objects incorrect.
When the tachograph card returns status bytes without SM DOs or with an erro-
neous SM DO, the session must be aborted by the VU.1998R2135 — EN — 25.08.2002 — 001.001 — 255
▼M1
5.3. Algorithm to compute cryptographic checksums
Cryptographic checksums are built using a retail MACs in accordance with
ANSI X9.19 with DES:
— initial stage: the initial check block y0 is E(Ka, SSC).
— sequential stage: the check blocks y1, …, yn are calculated using Ka.— final stage: the cryptographic checksum is calculated from the last check
block yn as follows: E(Ka, D(Kb, yn)).
where E() means encryption with DES, and D() means decryption with DES.The four most significant bytes of the cryptographic checksum are transferred
The send sequence counter (SSC) shall be initiated during key agreement proce-
dure to:
Initial SSC: Rnd3 (4 least significant bytes) || Rnd1 (4 least significant bytes).The send sequence counter shall be increased by 1 each time before a MAC is
calculated (i.e. the SSC for the first command is Initial SSC + 1, the SSC for the
first response is Initial SSC + 2).
The following figure shows the calculation of the retail MAC:
5.4. Algorithm to compute cryptograms for confidentiality DOs
Cryptograms are computed using TDEA in TCBC mode of operation in accor-
dance with references (TDES) and (TDES-OP) and with the Null vector as
Initial Value block.
The following figure shows the application of keys in TDES:
6. DATA DOWNLOAD DIGITAL SIGNATURE MECHANISMS
The intelligent dedicated equipment (IDE) stores data received from an equip-
ment (VU or card) during one download session within one physical data file.
This file must contain the certificates MSi.C and EQT.C. The file contains
digital signatures of data blocks as specified in Appendix 7 Data Downloading
Protocols.1998R2135 — EN — 25.08.2002 — 001.001 — 256
▼M1
Digital signatures of downloaded data shall use a digital signature scheme with
appendix such, that downloaded data may be read without any decipherment if
desired.
6.1. Signature generation
Data signature generation by the equipment shall follow the signature scheme
with appendix defined in reference (PKCS1) with the SHA-1 hash function:
Signature = EQT.SK[ ′00′||′01′||PS||′00′|| DER(SHA-1(Data))]
PS = Padding string of octets with value ′FF′such that length is 128.
DER(SHA-1( M)) is the encoding of the algorithm ID for the hash function and
the hash value into an ASN.1 value of type DigestInfo (distinguished encoding
rules):
′30′||′21′||′30′||′09′||′06′||′05′||′2B′||′0E′||′03′||′02′||′1A′||′05′||′00′||′04′||′14′||Hash
Value.
6.2. Signature verification
Data signature verification on downloaded data shall follow the signature
scheme with appendix defined in reference (PKCS1) with the SHA-1 hash func-
tion.
The European public key EUR.PK needs to be known independently (and
trusted) by the verifier.
The following table illustrates the protocol an IDE carrying a Control card can
follow to verify the integrity of data downloaded and stored on the ESM
(external storage media). The control card is used to perform the decipherement
of digital signatures. This function may in this case not be implemented in the
IDE.
The equipment that has downloaded and signed the data to be analysed is
denoted EQT.’1998R2135 — EN — 25.08.2002 — 001.001 — 257
▼M1
1998R2135 — EN — 25.08.2002 — 001.001 — 258