{
  "url": "https://openlegislation.uk/eu-regulation-1998-2135/annex",
  "json_url": "https://openlegislation.uk/eu-regulation-1998-2135/annex.json",
  "legislation": "eur/1998/2135",
  "legislation_title": "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",
  "legislation_url": "https://openlegislation.uk/eu-regulation-1998-2135",
  "path": "annex",
  "kind": "annex",
  "number": null,
  "heading": null,
  "text": "‘ ANNEX I B\nREQUIREMENTS FOR CONSTRUCTION, TESTING, INSTALLATION AND INSPECTION\nI.\nDEFINITIONS\nIn this Annex:\n(a) ‘ activation ’ means phase where the recording equipment becomes fully operational and implements all functions, including security functions;\nActivating a recording equipment requires the use of a workshop card and the entry of its PIN code;\n(b) ‘ authentication ’ means a function intended to establish and verify a claimed identity;\n(c) ‘ authenticity ’ means the property that an information is coming from a party whose identity can be verified;\n(d) ‘ built-in-test (BIT) ’ means tests run at request, triggered by the operator or by an external equipment;\n(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);\n(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);\ncalibrating a recording equipment requires the use of a workshop card;\n(g) ‘ card number ’ means a 16 alpha-numerical characters number that uniquely identifies a tachograph card within a Member State. The card number includes a consecutive index (if applicable), a replacement index and a renewal index;\na card is therefore uniquely identified by the code of the issuing Member State and the card number;\n(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;\n(i) ‘ card renewal index ’ means the 16th alpha-numerical character of a card number which is incremented each time a tachograph card is renewed;\n(j) ‘ card replacement index ’ means the 15th alpha-numerical character of a card number which is incremented each time a tachograph card is replaced;\n(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);\n(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;\nthe 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;\n(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);\n(n) ‘continuous driving time’ is computed within the recording equipment as the continuous driving time is computed as the current accumulated driving times of a particular driver, since the end of his last AVAILABILITY or BREAK/REST or UNKNOWN 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;\n(o) ‘ control card ’ means a tachograph card issued by the authorities of a Member State to a national competent control authority;\nthe 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;\n(p) ‘cumulative break time’ is computed within the recording equipment as the cumulative break from driving time is computed as the current accumulated AVAILABILITY or BREAK/REST or UNKNOWN times of 15 minutes or more of a particular driver, since the end of his last AVAILABILITY or BREAK/REST or UNKNOWN period of 45 minutes or more (this period may have been split in several periods of 15 minutes or more).\nThe 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.\nWhen 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;\n(q) ‘ data memory ’ means an electronic data storage device built into the recording equipment;\n(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;\n(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;\ndownloading may not alter or delete any stored data;\n(t) ‘ driver card ’ means a tachograph card issued by the authorities of a Member State to a particular driver;\nthe driver card identifies the driver and allows for storage of driver activity data;\n(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 conditions (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 . The methods for such theoretical calculation will be approved by a competent Member State authority;\n(v) ‘ event ’ means abnormal operation detected by the recording equipment which may come from a fraud attempt;\n(w) ‘ fault ’ means abnormal operation detected by the recording equipment which may come from an equipment malfunction or failure;\n(x) ‘ installation ’ means mounting of the recording equipment in a vehicle;\n(y) ‘ motion sensor ’ means part of the recording equipment, providing a signal representative of vehicle speed and/or distance travelled;\n(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;\n(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;\n(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 vehicles in the Community ;\n(cc) ‘ periodic inspection ’ means set of operations performed to control that the recording equipment works properly and that its settings correspond to the vehicle parameters;\n(dd) ‘ printer ’ means component of the recording equipment which provides printouts of stored data;\n(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;\n(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;\n(gg) ‘ repair ’ means any repair of a motion sensor or of a vehicle unit that requires disconnection of its power supply, or disconnection from other recording equipment components, or opening of it;\n(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;\n(ii) ‘ security certification ’ means process to certify, by an ITSEC 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;\n(jj) ‘ self test ’ means tests run cyclically and automatically by the recording equipment to detect faults;\n(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:\ndriver card,\ncontrol card,\nworkshop card,\ncompany card;\n(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;\n(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 ;\n(nn) ‘ vehicle identification ’ means numbers identifying the vehicle: vehicle registration number (VRN) with indication of the registering Member State and vehicle identification number (VIN) ;\n(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;\n(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;\n(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.\nThe workshop card identifies the cardholder and allows for testing, calibration and/or downloading of the recording equipment;\nII.\nGENERAL CHARACTERISTICS AND FUNCTIONS OF THE RECORDING EQUIPMENT\nAny 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.\n1.\nGeneral characteristics\nThe purpose of the recording equipment is to record, store, display, print, and output data related to driver activities.\nThe recording equipment includes cables, a motion sensor, and a vehicle unit.\nThe 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.\nThe recording equipment may be connected to other devices through additional connectors.\nAny inclusion in or connection to the recording equipment of any function, device, or devices, approved or otherwise, shall not interfere with, or be capable of interfering with, the proper and secure operation of the recording equipment and the provisions of the Regulation.\nRecording equipment users identify themselves to the equipment via tachograph cards.\nThe recording equipment provides selective access rights to data and functions according to user's type and/or identity.\nThe recording equipment records and stores data in its data memory and in tachograph cards.\nThis 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 .\n2.\nFunctions\nThe recording equipment shall ensure the following functions:\nmonitoring cards insertions and withdrawals,\nspeed and distance measurement,\ntime measurement,\nmonitoring driver activities,\nmonitoring driving status,\ndrivers manual entries:\nentry of places where daily work periods begin and/or end,\nmanual entry of driver activities,\nentry of specific conditions,\ncompany locks management,\nmonitoring control activities,\ndetection of events and/or faults,\nbuilt-in and self tests,\nreading from data memory,\nrecording and storing in data memory,\nreading from tachograph cards,\nrecording and storing in tachograph cards,\ndisplaying,\nprinting,\nwarning,\ndata downloading to external media,\noutput data to additional external devices,\ncalibration,\ntime adjustment.\n3.\nModes of operation\nThe recording equipment shall possess four modes of operation:\noperational mode,\ncontrol mode,\ncalibration mode,\ncompany mode.\nThe recording equipment shall switch to the following mode of operation according to the valid tachograph cards inserted into the card interface devices:\nIn these situations the recording equipment shall use only the tachograph card inserted in the driver slot.\nMode of operation\nDriver slot\nNo card\nDriver card\nControl card\nWorkshop card\nCompany card\nCo-driver slot\nNo card\nOperational\nOperational\nControl\nCalibration\nCompany\nDriver card\nOperational\nOperational\nControl\nCalibration\nCompany\nControl card\nControl\nControl\nControl\nOperational\nOperational\nWorkshop card\nCalibration\nCalibration\nOperational\nCalibration\nOperational\nCompany card\nCompany\nCompany\nOperational\nOperational\nCompany\nThe recording equipment shall ignore non-valid cards inserted, except displaying, printing or downloading data held on an expired card which shall be possible.\nAll functions listed in II.2. shall work in any mode of operation with the following exceptions:\nthe calibration function is accessible in the calibration mode only,\nthe time adjustment function is limited when not in the calibration mode,\nthe driver manual entries functions are accessible in operational or calibration modes only,\nthe company locks management function is accessible in the company mode only,\nthe monitoring of control activities function is operational in the control mode only,\nthe downloading function is not accessible in the operational mode (except as provided for in Requirement 150).\nThe recording equipment can output any data to display, printer or external interfaces with the following exceptions:\nin the operational mode, any personal identification (surname and first name(s)) not corresponding to a tachograph card inserted shall be blanked and any card number not corresponding to a tachograph card inserted shall be partially blanked (every odd character — from left to right — shall be blanked),\nin 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),\nwhen no card is inserted in the recording equipment, driver related data can be output only for the current and eight previous calendar days.\n4.\nSecurity\nThe 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 tachograph cards, and verifying the integrity and authenticity of data downloaded.\nIn 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).\nIII.\nCONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR RECORDING EQUIPMENT\n1.\nMonitoring cards insertion and withdrawal\nThe recording equipment shall monitor the card interface devices to detect card insertions and withdrawals.\nUpon 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.\nThe recording equipment shall be so designed that the tachograph cards are locked in position on their proper insertion into the card interface devices.\nThe 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.\n2.\nSpeed and distance measurement\nThis function shall continuously measure and be able to provide the odometer value corresponding to the total distance travelled by the vehicle.\nThis function shall continuously measure and be able to provide the speed of the vehicle.\nThe 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.\nDevices 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)).\n2.1.\nMeasurement of distance travelled\nThe distance travelled may be measured either:\nso as to cumulate both forward and reverse movements, or\nso as to include only forward movement.\nThe recording equipment shall measure distance from 0 to 9 999 999,9 km.\nDistance measured shall be within the following tolerances (distances of at least 1 000 m):\n± 1 % before installation,\n± 2 % on installation and periodic inspection,\n± 4 % in use.\nDistance measured shall have a resolution better than or equal to 0,1 km.\n2.2.\nMeasurement of speed\nThe recording equipment shall measure speed from 0 to 220 km/h.\nTo ensure a maximum tolerance on speed displayed of ± 6 km/h in use, and taking into account:\na ± 2 km/h tolerance for input variations (tyre variations, …),\na ± 1 km/h tolerance in measurements made during installation or periodic inspections,\nthe 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).\nNote: The resolution of data storage brings an additional tolerance of ± 0,5 km/h to speed stored by the recording equipment.\nThe 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 .\nSpeed measurement shall have a resolution better than or equal to 1 km/h.\n3.\nTime measurement\nThe time measurement function shall measure permanently and digitally provide UTC date and time.\nUTC date and time shall be used for dating throughout the recording equipment (recordings, printouts, data exchange, display, …).\nIn order to visualise the local time, it shall be possible to change the offset of the time displayed, in half hour steps.\nTime drift shall be within ± 2 seconds per day in type approval conditions.\nTime measured shall have a resolution better than or equal to 1 second.\nTime measurement shall not be affected by an external power supply cut-off of less than 12 months in type approval conditions.\n4.\nMonitoring driver activities\nThis function shall permanently and separately monitor the activities of one driver and one co-driver.\nDriver activity shall be DRIVING, WORK, AVAILABILITY, or BREAK/REST.\nIt shall be possible for the driver and/or the co-driver to manually select WORK, AVAILABILITY, or BREAK/REST.\nWhen the vehicle is moving, DRIVING shall be selected automatically for the driver and AVAILABILITY shall be selected automatically for the co-driver.\nWhen the vehicle stops, WORK shall be selected automatically for the driver.\nThe 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).\nThis function shall output activity changes to the recording functions at a resolution of one minute.\nGiven a calendar minute, if any DRIVING activity has occurred within the minute, the whole minute shall be regarded as DRIVING.\nGiven 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.\nGiven 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).\nThis function shall also permanently monitor the continuous driving time and the cumulative break time of the driver.\n5.\nMonitoring driving status\nThis function shall permanently and automatically monitor the driving status.\nThe 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.\n6.\nDrivers manual entries\n6.1.\nEntry of places where daily work periods begin and/or end\nThis 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.\nPlaces are defined as the country and, in addition where applicable, the region.\nAt 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 ’ .\nThe recording equipment shall allow this request to be disregarded.\nIt 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.\n6.2.\nManual entry of driver activities\nUpon driver (or workshop) card insertion, and only at this time, the recording equipment shall:\nremind the cardholder the date and time of his last card withdrawal, and\nask the cardholder to identify if the current insertion of the card represents a continuation of the current daily work period.\nThe recording equipment shall allow the cardholder to disregard the question without answering, or to answer positively, or to answer negatively:\nin 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 disregarded. 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,\nin 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 — current insertion only, and without allowing such activities to overlap mutually. This shall be done in accordance with the following procedures:\nin the case where the cardholder answers positively to the question, the recording equipment shall invite the cardholder to enter activities manually, 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.\nin the case where the cardholder answers negatively to the question, the recording equipment shall:\ninvite 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 cardholder 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),\nNotes: 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 equipment shall:\nassume 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),\nassume that the start time (see below) equals the card insertion time,\nproceed through the steps below;\nthen, 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,\nthen 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,\nthen, 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,\nthe 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,\nsuch answers to the initial question followed by no activity entries, shall be interpreted by the recording equipment as if the cardholder had disregarded the question.\nDuring this whole process, the recording equipment shall wait for entries no longer than the following time-outs:\nif 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,\nif the card is withdrawn or another driver (or workshop) card is inserted or,\nas soon as the vehicle is moving,\nin this case the recording equipment shall validate any entries already made.\n6.3.\nEntry of specific conditions\nThe recording equipment shall allow the driver to enter, in real time, the following two specific conditions:\n‘ OUT OF SCOPE ’ (begin, end)\n‘ FERRY/TRAIN CROSSING ’\nA ‘ FERRY/TRAIN CROSSING ’ may not occur if an ‘ OUT OF SCOPE ’ condition is opened.\nAn opened ‘ OUT OF SCOPE ’ condition must be automatically closed, by the recording equipment, if a driver card is inserted or withdrawn.\n7.\nCompany locks management\nThis function shall allow the management of the locks placed by a company to restrict data access in company mode to itself.\nCompany 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).\nLocks may be turned ‘ in ’ or ‘ out ’ in real time only.\nLocking-out shall only be possible for the company whose lock is ‘ in ’ (as identified by the first 13 digits of the company card number), or,\nlocking-out shall be automatic if another company locks in.\nIn 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 ’ .\n8.\nMonitoring control activities\nThis function shall monitor DISPLAYING, PRINTING, VU and card DOWNLOADING activities carried while in control mode.\nThis 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.\n9.\nDetection of events and/or faults\nThis function shall detect the following events and/or faults:\n9.1.\nInsertion of a non-valid card‘’ event\nThis event shall be triggered at the insertion of any non-valid card and/or when an inserted valid card expires.\n9.2.\n‘Card conflict’ event\nThis event shall be triggered when any of the valid cards combination noted X in the following table arise:\nCard conflict\nDriver slot\nNo card\nDriver card\nControl card\nWorkshop card\nCompany card\nCo-driver slot\nNo card\nDriver card\nX\nControl card\nX\nX\nX\nWorkshop card\nX\nX\nX\nX\nCompany card\nX\nX\nX\n9.3.\n‘Time overlap’ event\nThis 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.\n9.4.\n‘Driving without an appropriate card’ event\nThis 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:\nDriving without an appropriate card\nDriver slot\nNo (or non-valid) card\nDriver card\nControl card\nWorkshop card\nCompany card\nCo-driver slot\nNo (or non-valid) card\nX\nX\nX\nDriver card\nX\nX\nX\nX\nControl card\nX\nX\nX\nX\nX\nWorkshop card\nX\nX\nX\nX\nCompany card\nX\nX\nX\nX\nX\n9.5.\n‘Card insertion while driving’ event\nThis event shall be triggered when a tachograph card is inserted in any slot, while driver activity is DRIVING.\n9.6.\n‘Last card session not correctly closed’ event\nThis 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.\n9.7.\n‘Over speeding’ event\nThis event shall be triggered for each over speeding.\n9.8.\n‘Power supply interruption’ event\nThis event shall be triggered, while not in calibration mode, in case of any interruption 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.\n9.9.\n‘Motion data error’ event\nThis 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.\n9.10.\n‘Security breach attempt’ event\nThis 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.\n9.11.\n‘Card’ fault\nThis fault shall be triggered when a tachograph card failure occurs during operation.\n9.12.\n‘Recording equipment’ fault\nThis fault shall be triggered for any of these failures, while not in calibration mode:\nVU internal fault,\nprinter fault,\ndisplay fault,\ndownloading fault,\nsensor fault.\n10.\nBuilt-in and self tests\nThe recording equipment shall self-detect faults through self tests and built-in-tests, according to the following table:\nSub-assembly to test\nSelf test\nBuilt-in-test\nSoftware\nIntegrity\nData memory\nAccess\nAccess, data integrity\nCard interface devices\nAccess\nAccess\nKeyboard\nManual check\nPrinter\n(up to manufacturer)\nPrintout\nDisplay\nVisual check\nDownloading (performed only during downloading)\nProper operation\nSensor\nProper operation\nProper operation\n11.\nReading from data memory\nThe recording equipment shall be able to read any data stored in its data memory.\n12.\nRecording and storing in the data memory\nFor the purpose of this paragraph,\n‘ 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,\ntimes are recorded with a resolution of one minute, unless otherwise specified,\nodometer values are recorded with a resolution of one kilometre,\nspeeds are recorded with a resolution of 1 km/h.\nData 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.\nThe recording equipment shall be able to record and store implicitly or explicitly in its data memory the following:\n12.1.\nEquipment identification data\n12.1.1.\nVehicle unit identification data\nThe recording equipment shall be able to store in its data memory the following vehicle unit identification data:\nname of the manufacturer,\naddress of the manufacturer,\npart number,\nserial number,\nsoftware version number,\nsoftware version installation date,\nyear of equipment manufacture,\napproval number.\nVehicle 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.\n12.1.2.\nMotion sensor identification data\nThe motion sensor shall be able to store in its memory the following identification data:\nname of the manufacturer,\npart number,\nserial number,\napproval number,\nembedded security component identifier (e.g. internal chip/processor part number),\noperating system identifier (e.g. software version number).\nMotion sensor identification data are recorded and stored once and for all in the motion sensor, by the motion sensor manufacturer.\nThe vehicle unit shall be able to record and store in its data memory the following currently paired motion sensor identification data:\nserial number,\napproval number,\nfirst pairing date.\n12.2.\nSecurity elements\nThe recording equipment shall be able to store the following security elements:\nEuropean public key,\nMember State certificate,\nequipment certificate,\nequipment private key.\nRecording equipment security elements are inserted in the equipment by the vehicle unit manufacturer.\n12.3.\nDriver card insertion and withdrawal data\nFor 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:\nthe card holder's surname and first name(s) as stored in the card,\nthe card's number, issuing Member State and expiry date as stored in the card,\nthe insertion date and time,\nthe vehicle odometer value at card insertion,\nthe slot in which the card is inserted,\nthe withdrawal date and time,\nthe vehicle odometer value at card withdrawal,\nthe following information about the previous vehicle used by the driver, as stored in the card:\nVRN and registering Member State,\ncard withdrawal date and time,\na flag indicating whether, at card insertion, the card holder has manually entered activities or not.\nThe data memory shall be able to hold these data for at least 365 days.\nWhen storage capacity is exhausted, new data shall replace oldest data.\n12.4.\nDriver activity data\nThe 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 withdrawal of a driver or workshop card:\nthe driving status (CREW, SINGLE),\nthe slot (DRIVER, CO-DRIVER),\nthe card status in the relevant slot (INSERTED, NOT INSERTED) (see Note),\nthe activity (DRIVING, AVAILABILITY, WORK, BREAK/REST),\nthe date and time of the change.\nNote: 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).\nNote: Activity data manually entered by a driver are not recorded in the data memory.\nThe data memory shall be able to hold driver activity data for at least 365 days.\nWhen storage capacity is exhausted, new data shall replace oldest data.\n12.5.\nPlaces where daily work periods start and/or end\nThe 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:\nif applicable, the (co-)driver card number and card issuing Member State,\nthe date and time of the entry (or the date/time related to the entry when the entry is made during the manual entry procedure),\nthe type of entry (begin or end, condition of entry),\nthe country and region entered,\nthe vehicle odometer value.\nThe 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).\nWhen storage capacity is exhausted, new data shall replace oldest data.\n12.6.\nOdometer data\nThe recording equipment shall record in its data memory the vehicle odometer value and the corresponding date at midnight every calendar day.\nThe data memory shall be able to store midnight odometer values for at least 365 calendar days.\nWhen storage capacity is exhausted, new data shall replace oldest data.\n12.7.\nDetailed speed data\nThe recording equipment shall record and store in its data memory the instantaneous 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.\n12.8.\nEvents data\nFor the purpose of this subparagraph, time shall be recorded with a resolution of one second.\nThe recording equipment shall record and store in its data memory the following data for each event detected according to the following storage rules:\nThe recording equipment shall also record and store in its data memory:\nthe date and time of the last OVER SPEEDING CONTROL,\nthe date and time of the first over speeding following this OVER SPEEDING CONTROL,\nthe number of over speeding events since the last OVER SPEEDING CONTROL.\nThese data may be recorded at power supply reconnection only, times may be known with an accuracy to the minute.\nEvent\nStorage rules\nData to be recorded per event\nCard conflict\nthe 10 most recent events.\ndate and time of beginning of event,\ndate and time of end of event,\ncards' type, number and issuing Member State of the two cards creating the conflict.\nDriving without an appropriate card\nthe longest event for each of the 10 last days of occurrence,\nthe five longest events over the last 365 days.\ndate and time of beginning of event,\ndate and time of end of event,\ncards' type, number and issuing Member State of any card inserted at beginning and/or end of the event,\nnumber of similar events that day.\nCard insertion while driving\nthe last event for each of the 10 last days of occurrence.\ndate and time of the event,\ncard's type, number and issuing Member State,\nnumber of similar events that day.\nLast card session not correctly closed\nthe 10 most recent events.\ndate and time of card insertion,\ncard's type, number and issuing Member State,\nlast session data as read from the card:\ndate and time of card insertion,\nVRN and Member State of registration.\nOver speeding\nthe most serious event for each of the 10 last days of occurrence (i.e. the one with the highest average speed),\nthe five most serious events over the last 365 days.\nthe first event having occurred after the last calibration.\ndate and time of beginning of event,\ndate and time of end of event,\nmaximum speed measured during the event,\narithmetic average speed measured during the event,\ncard's type, number and issuing Member State of the driver (if applicable),\nnumber of similar events that day.\nPower supply interruption\nthe longest event for each of the 10 last days of occurrence,\nthe five longest events over the last 365 days.\ndate and time of beginning of event,\ndate and time of end of event,\ncards' type, number and issuing Member State of any card inserted at beginning and/or end of the event,\nnumber of similar events that day.\nMotion data error\nthe longest event for each of the 10 last days of occurrence,\nthe five longest events over the last 365 days.\ndate and time of beginning of event,\ndate and time of end of event,\ncards' type, number and issuing Member State of any card inserted at beginning and/or end of the event,\nnumber of similar events that day.\nSecurity breach attempt\nthe 10 most recent events per type of event.\ndate and time of beginning of event,\ndate and time of end of event (if relevant),\ncards' type, number and issuing Member State of any card inserted at beginning and/or end of the event,\ntype of event.\n12.9.\nFaults data\nFor the purpose of this subparagraph, time shall be recorded with a resolution of one second.\nThe 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:\nFault\nStorage rules\nData to be recorded per fault\nCard fault\nthe 10 most recent driver card faults.\ndate and time of beginning of fault,\ndate and time of end of fault,\ncard's type number and issuing Member State.\nRecording equipment faults\nthe 10 most recent faults for each type of fault,\nthe first fault after the last calibration.\ndate and time of beginning of fault,\ndate and time of end of fault,\ntype of fault,\ncards' type, number and issuing Member State of any card inserted at beginning and/or end of the fault.\n12.10.\nCalibration data\nThe recording equipment shall record and store in its data memory data relevant to:\nknown calibration parameters at the moment of activation,\nits very first calibration following its activation,\nits first calibration in the current vehicle (as identified by its VIN),\nthe five most recent calibrations (If several calibrations happen within one calendar day, only the last one of the day shall be stored).\nThe following data shall be recorded for each of these calibrations:\npurpose of calibration (activation, first installation, installation, periodic inspection),\nworkshop name and address,\nworkshop card number, card issuing Member State and card expiry date,\nvehicle identification,\nparameters updated or confirmed: w, k, l, tyre size, speed limiting device setting, odometer (old and new values), date and time (old and new values).\nThe motion sensor shall record and store in its memory the following motion sensor installation data:\nfirst pairing with a VU (date, time, VU approval number, VU serial number),\nlast pairing with a VU (date, time, VU approval number, VU serial number).\n12.11.\nTime adjustment data\nThe recording equipment shall record and store in its data memory data relevant to:\nthe most recent time adjustment,\nthe five largest time adjustments, since last calibration,\nperformed in calibration mode outside the frame of a regular calibration (definition (f)).\nThe following data shall be recorded for each of these time adjustments:\ndate and time, old value,\ndate and time, new value,\nworkshop name and address,\nworkshop card number, card issuing Member State and card expiry date.\n12.12.\nControl activity data\nThe recording equipment shall record and store in its data memory the following data relevant to the 20 most recent control activities:\ndate and time of the control,\ncontrol card number and card issuing Member State,\ntype of the control (displaying and/or printing and/or VU downloading and/or card downloading).\nIn case of downloading, the dates of the oldest and of the most recent days downloaded shall also be recorded.\n12.13.\nCompany locks data\nThe recording equipment shall record and store in its data memory the following data relevant to the 20 most recent company locks:\nlock-in date and time,\nlock-out date and time,\ncompany card number and card issuing Member State,\ncompany name and address.\n12.14.\nDownload activity data\nThe 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:\ndate and time of downloading,\ncompany or workshop card number and card issuing Member State,\ncompany or workshop name.\n12.15.\nSpecific conditions data\nThe recording equipment shall record in its data memory the following data relevant to specific conditions:\ndate and time of the entry,\ntype of specific condition.\nThe 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.\n13.\nReading from tachograph cards\nThe recording equipment shall be able to read from tachograph cards, where applicable, the necessary data:\nto 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,\nto check that last card session was correctly closed,\nto compute the driver's continuous driving time, cumulative break time and cumulated driving times for the previous and the current week,\nto print requested printouts related to data recorded on a driver card,\nto download a driver card to external media.\nIn 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.\n14.\nRecording and storing on tachograph cards\nThe recording equipment shall set the ‘ card session data ’ in the driver or workshop card right after the card insertion.\nThe 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.\nThe recording equipment shall update driver activity and location data (as specified 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 cardholder.\nTachograph cards data update shall be such that, when needed and taking into account card actual storage capacity, most recent data replace oldest data.\nIn 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.\nBefore releasing a driver card, and after all relevant data have been stored on the card, the recording equipment shall reset the card session data.\n15.\nDisplaying\nThe display shall include at least 20 characters.\nThe minimum character size shall be 5 mm high and 3,5 mm wide.\nThe 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).\nThe display shall be provided with adequate non-dazzling lighting.\nIndications shall be visible from outside the recording equipment.\nThe recording equipment shall be able to display:\ndefault data,\ndata related to warnings,\ndata related to menu access,\nother data requested by a user.\nAdditional information may be displayed by the recording equipment, provided that it is clearly distinguishable from information required above.\nThe display of the recording equipment shall use the pictograms or pictogram combinations listed in Appendix 3. Additional pictograms or pictogram combinations may also be provided by the display, if clearly distinguishable from the aforementioned pictogram or pictogram combinations.\nThe display shall always be ON when the vehicle is moving.\nThe recording equipment may include a manual or automatic feature to turn the display OFF when the vehicle is not moving.\nDisplaying format is specified in Appendix 5.\n15.1.\nDefault display\nWhen no other information needs to be displayed, the recording equipment shall display, by default, the following:\nthe local time (as a result of UTC time + offset as set by the driver),\nthe mode of operation,\nthe current activity of the driver and the current activity of the co-driver,\ninformation related to the driver:\nif his current activity is DRIVING, his current continuous driving time and his current cumulative break time,\nif his current activity is not DRIVING, the current duration of this activity (since it was selected) and his current cumulative break time,\ninformation related to the co-driver:\nthe current duration of his activity (since it was selected).\nDisplay 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 information related to the co-driver.\nIn 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.\nThe recording equipment shall briefly display the card holder name at card insertion.\nWhen 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).\n15.2.\nWarning display\nThe recording equipment shall display warning information using primarily the pictograms of Appendix 3, completed where needed by an additional numerically coded information. A literal description of the warning may also be added in the driver's preferred language.\n15.3.\nMenu access\nThe recording equipment shall provide necessary commands through an appropriate menu structure.\n15.4.\nOther displays\nIt shall be possible to display selectively on request:\nthe UTC date and time,\nthe mode of operation (if not provided by default),\nthe continuous driving time and cumulative break time of the driver,\nthe continuous driving time and cumulative break time of the co-driver,\nthe cumulated driving time of the driver for the previous and the current week,\nthe cumulated driving time of the co-driver for the previous and the current week,\nthe content of any of the six printouts under the same formats as the printouts themselves.\nPrintout 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.\n16.\nPrinting\nThe recording equipment shall be able to print information from its data memory and/or from tachograph cards in accordance with the six following printouts:\ndriver activities from card daily printout,\ndriver activities from Vehicle Unit daily printout,\nevents and faults from card printout,\nevents and faults from Vehicle Unit printout,\ntechnical data printout,\nover speeding printout.\nThe detailed format and content of these printouts are specified in Appendix 4.\nAdditional data may be provided at the end of the printouts\nAdditional printouts may also be provided by the recording equipment, if clearly distinguishable from the six aforementioned printouts.\nThe ‘ 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.\nIn order to produce the ‘ driver activities from card daily printout ’ or the ‘ events and faults from card printout ’ , the recording equipment shall:\neither automatically select the driver card or the workshop card if one only of these cards is inserted,\nor 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.\nThe printer shall be able to print 24 characters per line.\nThe minimum character size shall be 2,1 mm high and 1,5 mm wide.\nThe 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 ’ .\nPrinters shall be so designed as to produce these printouts with a degree of definition likely to avoid any ambiguity when they are read.\nPrintouts shall retain their dimensions and recordings under normal conditions of humidity (10 to 90 %) and temperature.\nThe 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.\nIt shall also be possible to add handwritten notes, such as the driver's signature, to these documents.\nThe recording equipment shall manage ‘ paper out ’ events while printing by, once paper has been re-loaded, restarting printing from printout beginning or by continuing printing and providing an unambiguous reference to previously printed part.\n17.\nWarnings\nThe recording equipment shall warn the driver when detecting any event and/or fault.\nWarning of a power supply interruption event may be delayed until the power supply is reconnected.\nThe recording equipment shall warn the driver 15 minutes before and at the time of exceeding 4 h 30 min. continuous driving time.\nWarnings shall be visual. Audible warnings may also be provided in addition to visual warnings.\nVisual 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.\nVisual warnings may be built into the recording equipment and/or remote from the recording equipment.\nIn the latter case it shall bear a ‘ T ’ symbol and shall be amber or orange.\nWarnings shall have a duration of at least 30 seconds, unless acknowledged by the user by hitting any key of the recording equipment. This first acknowledgement shall not erase warning cause display referred to in next paragraph.\nWarning 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.\nAdditional warnings may be provided, as long as they do not confuse drivers in relation to previously defined ones.\n18.\nData downloading to external media\nThe 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.\nIn 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.\nDownloading shall not alter or delete any stored data.\nThe calibration/downloading connector electrical interface is specified in Appendix 6.\nDownloading protocols are specified in Appendix 7.\n19.\nOutput data to additional external devices\nWhen 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).\nThe vehicle unit shall also be able to output the following data using an appropriate 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:\ncurrent UTC date and time,\nspeed of the vehicle,\ntotal distance travelled by the vehicle (odometer),\ncurrently selected driver and co-driver activity,\ninformation 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).\nOther data may also be output in addition to this minimum list.\nWhen the ignition of the vehicle is ON, these data shall be permanently broadcast. 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 available once the ignition of the vehicle is ON again.\n20.\nCalibration\nThe calibration function shall allow:\nto automatically pair the motion sensor with the VU,\nto digitally adapt the constant of the recording equipment (k) to the characteristic coefficient of the vehicle (w) (vehicles with two or more axle ratios shall be fitted with a switch device whereby these various ratios will automatically be brought into line with the ratio for which the equipment has been adapted to the vehicle),\nto adjust (without limitation) the current time,\nto adjust the current odometer value,\nto update motion sensor identification data stored in the data memory,\nto update or confirm other parameters known to the recording equipment: vehicle identification, w, l, tyre size and speed limiting device setting if applicable.\nPairing the motion sensor to the VU shall consist, at least, in:\nupdating motion sensor installation data held by the motion sensor (as needed),\ncopying from the motion sensor to the VU data memory necessary motion sensor identification data.\nThe calibration function shall be able to input necessary data through the calibration/downloading connector in accordance with the calibration protocol defined in Appendix 8. The calibration function may also input necessary data through other connectors.\n21.\nTime adjustment\nThe time adjustment function shall allow for adjusting the current time in amounts of one minute maximum at intervals of not less than seven days.\nThe time adjustment function shall allow for adjusting the current time without limitation, in calibration mode.\n22.\nPerformance characteristics\nThe Vehicle Unit shall be fully operational in the temperature range − 20 o C to 70 o C, and the motion sensor in the temperature range − 40 o C to 135 o C. Data memory content shall be preserved at temperatures down to − 40 o C.\nThe recording equipment shall be fully operational in the humidity range 10 % to 90 %.\nThe recording equipment shall be protected against over-voltage, inversion of its power supply polarity, and short circuits.\nThe recording equipment shall conform to Commission Directive 95/54/EC of 31 October 1995 adapting to technical progress Council Directive 72/245/EEC , related to electromagnetic compatibility, and shall be protected against electrostatic discharges and transients.\n23.\nMaterials\nAll 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.\nFor normal conditions of use, all the internal parts of the equipment shall be protected against damp and dust.\nThe 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.\nThe recording equipment shall conform to applicable technical specifications related to ergonomic design.\nThe recording equipment shall be protected against accidental damage.\n24.\nMarkings\nIf the recording equipment displays the vehicle odometer value and speed, the following details shall appear on its display:\nnear the figure indicating the distance, the unit of measurement of distance, indicated by the abbreviation ‘ km ’ ,\nnear the figure showing the speed, the entry ‘ km/h ’ .\nThe 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 ’ .\nA descriptive plaque shall be affixed to each separate component of the recording equipment and shall show the following details:\nname and address of the manufacturer of the equipment,\nmanufacturer's part number and year of manufacture of the equipment,\nequipment serial number,\napproval mark for the equipment type.\nWhen 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.\nIV.\nCONSTRUCTION AND FUNCTIONAL REQUIREMENTS FOR TACHOGRAPH CARDS\n1.\nVisible data\nThe front page will contain:\nthe 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;\nthe same words in the other official languages of the Community, printed to form the background of the card:\nES\nTARJETA DEL CONDUCTOR\nTARJETA DE CONTROL\nTARJETA DEL CENTRO DE ENSAYO\nTARJETA DE LA EMPRESA\nDK\nFØRERKORT\nKONTROLKORT\nVÆRKSTEDSKORT\nVIRKSOMHEDSKORT\nDE\nFAHRERKARTE\nKONTROLLKARTE\nWERKSTATTKARTE\nUNTERNEHMENSKARTE\nEL\nΚΑΡΤΑ ΟΔΗΟΥ\nΚΑΡΤΑ ΕΛΕΓΧΟΥ\nΚΑΡΤΑ ΚΕΝΤΡΟΥ ΔΟΚΙΜΩΝ\nΚΑΡΤΑ ΕΠΙΧΕΙΡΗΣΗΣ\nEN\nDRIVER CARD\nCONTROL CARD\nWORKSHOP CARD\nCOMPANY CARD\nFR\nCARTE DE CONDUCTEUR\nCARTE DE CONTROLEUR\nCARTE D'ATELIER\nCARTE D'ENTREPRISE\nGA\nCÁRTA TIOMÁNAÍ\nCÁRTA STIÚRTHA\nCÁRTA CEARDLAINNE\nCÁRTA COMHLACHTA\nIT\nCARTA DEL CONDUCENTE\nCARTA DI CONTROLLO\nCARTA DELL'OFFICINA\nCARTA DELL'AZIENDA\nNL\nBESTUURDERS KAART\nCONTROLEKAART\nWERKPLAATSKAART\nBEDRIJFSKAART\nPT\nCARTÃO DE CONDUTOR\nCARTÃO DE CONTROLO\nCARTÃO DO CENTRO DE ENSAIO\nCARTÃO DE EMPRESA\nFIN\nKULJETTAJA KORTTILLA\nVALVONTA KORTILLA\nTESTAUSASEMA KORTILLA\nYRITYSKORTILLA\nSV\nFÖRARKORT\nKONTROLLKORT\nVERKSTADSKORT\nFÖRETAGSKORT\nthe name of the Member State issuing the card (optional);\nthe 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:\nB Belgium\nDK Denmark\nD Germany\nGR Greece\nE Spain\nF France\nIRL Ireland\nI Italy\nL Luxembourg\nNL The Netherlands\nA Austria\nP Portugal\nFIN Finland\nS Sweden\nUK The United Kingdom;\ninformation specific to the card issued, numbered as follows:\nDriver card\nControl card\nCompany or workshop card\n1.\nSurname of the driver\nControl body name\nCompany or workshop card\n2.\nFirst name(s) of the driver\nSurname of the controller (if applicable)\nSurname of card holder (if applicable)\n3.\nBirth date of the driver\nFirst name(s) of the controller (if applicable)\nFirst name(s) of card holder (if applicable)\n4.(a)\nCard start of validity date\n(b)\nCard expiry date (if any)\n(c)\nThe name of the issuing authority (may be printed on page 2)\n(d)\nA different number from the one under heading 5, for administrative purposes (optional)\n5.(a)\nDriving licence number (at the date of issue of the driver card)\n5.(b)\nCard number\n6.\nPhotograph of the driver\nPhotograph of the controller (optional)\n—\n7.\nSignature of the driver\nSignature of the holder (optional)\n8.\nNormal place of residence, or postal address of the holder (optional)\nPostal address of control body\nPostal address of company or workshop\ndates shall be written using a ‘ dd/mm/yyyy ’ or ‘ dd.mm.yyyy ’ format (day, month, year);\nthe reverse page will contain:\nan explanation of the numbered items which appear on the front page of the card;\nwith 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.\nTachograph cards shall be printed with the following background predominant colours:\ndriver card: white,\ncontrol card: blue,\nworkshop card: red,\ncompany card: yellow.\nTachograph cards shall bear at least the following features for protection of the card body against counterfeiting and tampering:\na security design background with fine guilloche patterns and rainbow printing,\nin the area of the photograph, the security design background and the photograph shall overlap,\nat least one two-coloured microprint line.\nAfter 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.\n2.\nSecurity\nThe system security aims at protecting integrity and authenticity of data exchanged between the cards and the recording equipment, protecting the integrity 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.\nIn order to achieve the system security, the tachograph cards shall meet the security requirements defined in the tachograph cards generic security target (Appendix 10).\nTachograph cards shall be readable by other equipment such as personal computers.\n3.\nStandards\nThe tachograph cards shall comply with the following standards:\nISO/IEC 7810 Identification cards — Physical characteristics,\nISO/IEC 7816 Identification cards — Integrated circuits with contacts:\nPart 1: Physical characteristics,\nPart 2: Dimensions and location of the contacts,\nPart 3: Electronic signals and transmission protocols,\nPart 4: Inter-industry commands for interchange,\nPart 8: Security related inter-industry commands,\nISO/IEC 10373 Identification cards — Test methods.\n4.\nEnvironmental and electrical specifications\nThe 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 o C to + 70 o C with occasional peaks of up to + 85 o C, ‘occasional’ meaning not more than 4 hours each time and not over 100 times during the lifetime of the card.\nThe tachograph cards shall be capable of operating correctly in the humidity range 10 % to 90 %.\nThe tachograph cards shall be capable of operating correctly for a five-year period if used within the environmental and electrical specifications.\nDuring operation, the tachograph cards shall conform to Commission Directive 95/54/EC of 31 October 1995 , related to electromagnetic compatibility, and shall be protected against electrostatic discharges.\n5.\nData storage\nFor the purpose of this paragraph,\ntimes are recorded with a resolution of one minute, unless otherwise specified,\nodometer values are recorded with a resolution of one kilometre,\nspeeds are recorded with a resolution of 1 km/h.\nThe tachograph cards functions, commands and logical structures, fulfilling data storage requirements are specified in Appendix 2.\nThis paragraph specifies minimum storage capacity for the various application data files. The tachograph cards shall be able to indicate to the recording equipment the actual storage capacity of these data files.\nAny 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 .\n5.1.\nCard identification and security data\n5.1.1.\nApplication identification\nThe tachograph cards shall be able to store the following application identification data:\ntachograph application identification,\ntype of tachograph card identification.\n5.1.2.\nChip identification\nThe tachograph cards shall be able to store the following integrated circuit (IC) identification data:\nIC serial number,\nIC manufacturing references.\n5.1.3.\nIC card identification\nThe tachograph cards shall be able to store the following smart card identification data:\ncard serial number (including manufacturing references),\ncard type approval number,\ncard personaliser identification (ID),\nembedder ID,\nIC identifier.\n5.1.4.\nSecurity elements\nThe tachograph cards shall be able to store the following security elements data:\nEuropean public key,\nMember State certificate,\ncard certificate,\ncard private key.\n5.2.\nDriver card\n5.2.1.\nCard identification\nThe driver card shall be able to store the following card identification data:\ncard number,\nissuing Member State, issuing authority name, issue date,\ncard beginning of validity date, card expiry date.\n5.2.2.\nCard holder identification\nThe driver card shall be able to store the following card holder identification data:\nsurname of the holder,\nfirst name(s) of the holder,\ndate of birth,\npreferred language.\n5.2.3.\nDriving licence information\nThe driver card shall be able to store the following driving licence data:\nissuing Member State, issuing authority name,\ndriving licence number (at the date of the issue of the card).\n5.2.4.\nVehicles used data\nThe 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:\ndate 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),\nvehicle odometer value at that time,\ndate 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),\nvehicle odometer value at that time,\nVRN and registering Member State of the vehicle.\nThe driver card shall be able to store at least 84 such records.\n5.2.5.\nDriver activity data\nThe 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:\nthe date,\na daily presence counter (increased by one for each of these calendar days),\nthe total distance travelled by the driver during this day,\na driver status at 00.00,\nwhenever the driver has changed of activity, and/or has changed of driving status, and/or has inserted or withdrawn his card:\nthe driving status (CREW, SINGLE),\nthe slot (DRIVER, CO-DRIVER),\nthe card status (INSERTED, NOT INSERTED),\nthe activity (DRIVING, AVAILABILITY, WORK, BREAK/REST),\nthe time of the change.\nThe 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).\nThe 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.\n5.2.6.\nPlaces where daily work periods start and/or end\nThe 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:\nthe date and time of the entry (or the date/time related to the entry if the entry is made during the manual entry procedure),\nthe type of entry (begin or end, condition of entry),\nthe country and region entered,\nthe vehicle odometer value.\nThe driver card memory shall be able to hold at least 42 pairs of such records.\n5.2.7.\nEvents data\nFor the purpose of this subparagraph, time shall be stored with a resolution of one second.\nThe driver card shall be able to store data related to the following events detected by the recording equipment while the card was inserted:\ntime overlap (where this card is the cause of the event),\ncard insertion while driving (where this card is the subject of the event),\nlast card session not correctly closed (where this card is the subject of the event),\npower supply interruption,\nmotion data error,\nsecurity breach attempts.\nThe driver card shall be able to store the following data for these events:\nevent code,\ndate and time of beginning of the event (or of card insertion if the event was on-going at that time),\ndate and time of end of the event (or of card withdrawal if the event was on-going at that time),\nVRN and registering Member State of vehicle in which the event happened.\nNote: For the ‘time overlap’ event:\ndate and time of beginning of the event shall correspond to the date and time of the card withdrawal from the previous vehicle,\ndate and time of end of the event shall correspond to the date and time of card insertion in current vehicle,\nvehicle data shall correspond to the current vehicle raising the event.\nNote: For the ‘last card session not correctly closed’ event:\ndate and time of beginning of event shall correspond to the card insertion date and time of the session not correctly closed,\ndate 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),\nvehicle data shall correspond to the vehicle in which the session was not correctly closed.\nThe driver card shall be able to store data for the six most recent events of each type (i.e. 36 events).\n5.2.8.\nFaults data\nFor the purpose of this subparagraph, time shall be recorded with a resolution of one second.\nThe driver card shall be able to store data related to the following faults detected by the recording equipment while the card was inserted:\ncard fault (where this card is the subject of the event),\nrecording equipment fault.\nThe driver card shall be able to store the following data for these faults:\nfault code,\ndate and time of beginning of the fault (or of card insertion if the fault was on-going at that time),\ndate and time of end of the fault (or of card withdrawal if the fault was on-going at that time),\nVRN and registering Member State of vehicle in which the fault happened.\nThe driver card shall be able to store data for the twelve most recent faults of each type (i.e. 24 faults).\n5.2.9.\nControl activity data\nThe driver card shall be able to store the following data related to control activities:\ndate and time of the control,\ncontrol card number and card issuing Member State,\ntype of the control (displaying and/or printing and/or VU downloading and/or card downloading (see note)),\nperiod downloaded, in case of downloading,\nVRN and registering Member State of the vehicle in which the control happened.\nNote: security requirements imply that card downloading will only be recorded if performed through a recording equipment.\nThe driver card shall be able to hold one such record.\n5.2.10.\nCard session data\nThe driver card shall be able to store data related to the vehicle which opened its current session:\ndate and time the session was opened (i.e. card insertion) with a resolution of one second,\nVRN and registering Member State.\n5.2.11.\nSpecific conditions data\nThe driver card shall be able to store the following data related to specific conditions entered while the card was inserted (whatever the slot):\ndate and time of the entry,\ntype of specific condition.\nThe driver card shall be able to hold 56 such records.\n5.3.\nWorkshop card\n5.3.1.\nSecurity elements\nThe workshop card shall be able to store a personal identification number (PIN code).\nThe workshop card shall be able to store the cryptographic keys needed for pairing motion sensors to vehicle units.\n5.3.2.\nCard identification\nThe workshop card shall be able to store the following card identification data:\ncard number,\nissuing Member State, issuing authority name, issue date,\ncard beginning of validity date, card expiry date.\n5.3.3.\nCard holder identification\nThe workshop card shall be able to store the following card holder identification data:\nworkshop name,\nworkshop address,\nsurname of the holder,\nfirst name(s) of the holder,\npreferred language.\n5.3.4.\nVehicles used data\nThe workshop card shall be able to store vehicles used data records in the same manner as a driver card.\nThe workshop card shall be able to store at least 4 such records.\n5.3.5.\nDriver activity data\nThe workshop card shall be able to store driver activity data in the same manner as a driver card.\nThe workshop card shall be able to hold driver activity data for at least one day of average driver activity.\n5.3.6.\nDaily work periods start and/or end data\nThe workshop card shall be able to store daily works period start and/or end data records in the same manner as a driver card.\nThe workshop card shall be able to hold at least three pairs of such records.\n5.3.7.\nEvents and faults data\nThe workshop card shall be able to store events and faults data records in the same manner as a driver card.\nThe 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).\n5.3.8.\nControl activity data\nThe workshop card shall be able to store a control activity data record in the same manner as a driver card.\n5.3.9.\nCalibration and time adjustment data\nThe workshop card shall be able to hold records of calibrations and/or time adjustments performed while the card is inserted in a recording equipment.\nEach calibration record shall be able to hold the following data:\npurpose of calibration (first installation, installation, periodic inspection),\nvehicle identification,\nparameters updated or confirmed (w, k, l, tyre size, speed limiting device setting, odometer (new and old values), date and time (new and old values),\nrecording equipment identification (VU part number, VU serial number, motion sensor serial number).\nThe workshop card shall be able to store at least 88 such records.\nThe workshop card shall hold a counter indicating the total number of calibrations performed with the card.\nThe workshop card shall hold a counter indicating the number of calibrations performed since its last download.\n5.3.10.\nSpecific conditions data\nThe 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.\n5.4.\nControl card\n5.4.1.\nCard identification\nThe control card shall be able to store the following card identification data:\ncard number,\nissuing Member State, issuing authority name, issue date,\ncard beginning of validity date, card expiry date (if any).\n5.4.2.\nCard holder identification\nThe control card shall be able to store the following card holder identification data:\ncontrol body name,\ncontrol body address,\nsurname of the holder,\nfirst name(s) of the holder,\npreferred language.\n5.4.3.\nControl activity data\nThe control card shall be able to store the following control activity data:\ndate and time of the control,\ntype of the control (displaying and/or printing and/or VU downloading and/or card downloading),\nperiod downloaded (if any),\nVRN and Member State registering authority of the controlled vehicle,\ncard number and card issuing Member State of the driver card controlled.\nThe control card shall be able to hold at least 230 such records.\n5.5.\nCompany card\n5.5.1.\nCard identification\nThe company card shall be able to store the following card identification data:\ncard number,\nissuing Member State, issuing authority name, issue date,\ncard beginning of validity date, card expiry date (if any).\n5.5.2.\nCard holder identification\nThe company card shall be able to store the following card holder identification data:\ncompany name,\ncompany address.\n5.5.3.\nCompany activity data\nThe company card shall be able to store the following company activity data:\ndate and time of the activity,\ntype of the activity (VU locking in and/or out, and/or VU downloading and/or card downloading),\nperiod downloaded (if any),\nVRN and Member State registering authority of vehicle,\ncard number and card issuing Member State (in case of card downloading).\nThe company card shall be able to hold at least 230 such records.\nV.\nINSTALLATION OF RECORDING EQUIPMENT\n1.\nInstallation\nNew 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 ’ .\nBefore its activation, the recording equipment shall give access to the calibration function even if not in calibration mode.\nBefore 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.\nDuring installation, vehicle manufacturers shall pre-set all known parameters.\nVehicle manufacturers or fitters shall activate the installed recording equipment before the vehicle leaves the premises where the installation took place.\nThe activation of the recording equipment shall be triggered automatically by the first insertion of a workshop card in either of its card interface devices.\nSpecific pairing operations required between the motion sensor and the vehicle unit, if any, shall take place automatically before or during activation.\nAfter its activation, the recording equipment shall fully enforce functions and data access rights.\nThe recording and storing functions of the recording equipment shall be fully operational after its activation.\nInstallation 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.\nThe 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.\n2.\nInstallation plaque\nAfter 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.\nThe plaque shall bear at least the following details:\nname, address or trade name of the approved fitter or workshop,\ncharacteristic coefficient of the vehicle, in the form ‘ w = … imp/km ’ ,\nconstant of the recording equipment, in the form ‘ k = … imp/km ’ ,\neffective circumference of the wheel tyres in the form ‘ l = … mm ’ ,\ntyre size,\nthe date on which the characteristic coefficient of the vehicle was determined and the effective circumference of the wheel tyres measured,\nthe vehicle identification number.\n3.\nSealing\nThe following part shall be sealed:\nany connection which, if disconnected, would cause undetectable alterations to be made or undetectable data loss,\nthe installation plaque, unless it is attached in such a way that it cannot be removed without the markings thereon being destroyed.\nThe seals mentioned above may be removed:\nin case of emergency,\nto 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.\nOn 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.\nVI.\nCHECKS, INSPECTIONS AND REPAIRS\nRequirements 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 Regulation (EC) No 2135/98, are defined in Chapter V(3) of this annex.\n1.\nApproval of fitters or workshops\nThe Member States will approve, regularly control and certify the bodies to carry out:\ninstallations,\nchecks,\ninspections,\nrepairs.\nIn 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:\nwho are not eligible for a company card,\nand whose other professional activities do not present a potential compromise of the overall security of the system as defined in Appendix 10.\n2.\nCheck of new or repaired instruments\nEvery 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 accordance with Chapter V.3. and calibration.\n3.\nInstallation inspection\nWhen 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.\n4.\nPeriodic inspections\nPeriodic inspections of the equipment fitted to the vehicles shall take place after any repair of the equipment, or after any alteration of the characteristic coefficient of the vehicle or of the effective circumference of the tyres, or after equipment UTC time is wrong by more than 20 minutes, or when the VRN has changed, and at least once within two years (24 months) of the last inspection.\nThese inspections shall include the following checks:\nthat the recording equipment is working properly, including the data storage in tachograph cards function,\nthat compliance with the provisions of Chapter III.2.1 and III.2.2 on the maximum tolerances on installation is ensured,\nthat the recording equipment carries the type approval mark,\nthat the installation plaque is affixed,\nthat the seals on the equipment and on the other parts of the installation are intact,\nthe tyre size and the actual circumference of the wheel tyres.\nThese inspections shall include a calibration.\n5.\nMeasurement of errors\nThe measurement of errors on installation and during use shall be carried out under the following conditions, which are to be regarded as constituting standard test conditions:\nvehicle unladen, in normal running order,\ntyre pressures in accordance with the manufacturer's instructions,\ntyre wear, within the limits allowed by national law,\nvehicle movement:\nthe 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,\nprovided that it is of comparable accuracy, alternative methods, such as a suitable test bench, may also be used for the test.\n6.\nRepairs\nWorkshops shall be able to download data from the recording equipment to give the data back to the appropriate transport company.\nApproved 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.\nVII.\nCARD ISSUING\nThe card issuing processes set-up by the Member States shall conform to the following:\nThe 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 ’ .\nThe 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.\nA 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).\nA tachograph card issued in replacement of an existing tachograph card shall have the same card expiry date as the replaced one.\nA 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).\nThe 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.\nThe ‘ card holder surname ’ for non-personal workshop or control cards shall be filled with workshop or control body name.\nVIII.\nTYPE APPROVAL OF RECORDING EQUIPMENT AND TACHOGRAPH CARDS\n1.\nGeneral points\nFor 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.\nRecording equipment shall be submitted for approval complete with any integrated additional devices.\nType 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.\nMember States type approval authorities will not grant a type approval certificate in accordance with Article 5 of this Regulation, as long as they do not hold:\na security certificate,\na functional certificate,\nand an interoperability certificate,\nfor the recording equipment or the tachograph card, subject of the request for type approval.\nAny 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 interoperability certificates.\nProcedures to upgrade in situ recording equipment software shall be approved by the authority which granted type approval for the recording equipment. Software 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.\n2.\nSecurity certificate\nThe security certificate is delivered in accordance with the provisions of Appendix 10 to this Annex.\n3.\nFunctional certificate\nEach candidate for type approval shall provide the Member State's type approval authority with all the material and documentation that the authority deems necessary.\nA functional certificate shall be delivered to the manufacturer only after all functional tests specified in Appendix 9, at least, have been successfully passed.\nThe 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.\n4.\nInteroperability certificate\nInteroperability tests are carried out by a single laboratory under the authority and responsibility of the European Commission.\nThe laboratory shall register interoperability test requests introduced by manufacturers in the chronological order of their arrival.\nRequests will be officially registered only when the laboratory is in possession of:\nthe entire set of material and documents necessary for such interoperability tests,\nthe corresponding security certificate,\nthe corresponding functional certificate,\nThe date of the registration of the request shall be notified to the manufacturer.\nNo 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.\nAny 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.\nThe 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:\nfor which type approval is still valid, or\nfor which type approval is pending and that have a valid interoperability certificate.\nThe interoperability certificate shall be delivered by the laboratory to the manufacturer only after all required interoperability tests have been successfully passed.\nIf the interoperability tests are not successful with one or more of the recording equipment or tachograph card(s), as requested by requirement 283, the interoperability certificate shall not be delivered, until the requesting manufacturer has realised the necessary modifications and has succeeded with the interoperability 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 manufacturer's responsibility to ascertain from the relevant authorities that the security certificate and the functional certificates are still valid.\nThe 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.\nAny element that could be at the origin of an interoperability fault shall not be used for profit or to lead to a dominant position.\n5.\nType approval certificate\nThe type approval authority of the Member State may deliver the type approval certificate as soon as it holds the three required certificates.\nThe 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.\nThe 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:\nfor which a request for interoperability tests have been registered,\nhaving received an interoperability certificate (even provisional),\nhaving received a type approval certificate.\n6.\nExceptional procedure: first interoperability certificates\nUntil 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 provisional.\nIf at the end of this period, all products concerned are mutually interoperable, all corresponding interoperability certificates shall become definitive.\nIf 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 necessary modifications.\nIf 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 corresponding functional certificates shall find out the causes of the interoperability faults and establish which modifications should be made by each of the manufacturers 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.\nAny request for interoperability tests, registered by the laboratory between the end of the four-month period after the first provisional interoperability certificate has been delivered and the date of the decision by the Commission referred to in requirement 294, shall be postponed until the initial interoperability problems have been solved. Those requests are then processed in the chronological order of their registration.\nAppendix 1\nDATA DICTIONARY\n1.\nINTRODUCTION\nThis appendix specifies data formats, data elements, and data structures for use within the recording equipment and tachograph cards.\n1.1.\nApproach for definitions of data types\nThis 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 environment dependent.\nASN.1 type naming conventions are done in accordance with ISO/IEC 8824-1. This implies that:\nwhere possible, the meaning of the data type is implied through the names being selected,\nwhere 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 corresponding meaning,\nin 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.\nIf an ASN.1 type is already defined as part of another standard and if it is relevant for usage in the recording equipment, then this ASN.1 type will be defined in this appendix.\nTo 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.\n1.2.\nReferences\nThe following references are used in this Appendix:\nISO 639 Code for the representation of names of languages. First Edition: 1988\nEN 726-3 Identification cards systems — Telecommunications integrated circuit(s) cards and terminals — Part 3: Application independent card requirements. December 1994\nISO 3779 Road vehicles — Vehicle identification number (VIN) — Content and structure. Edition 3: 1983\nISO/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\nISO/IEC 8824-1 Information technology — Abstract Syntax Notation 1 (ASN.1): Specification of basic notation. Edition 2: 1998\nISO/IEC 8825-2 Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules (PER). Edition 2: 1998\nISO/IEC 8859-1 Information technology — 8 bit single-byte coded graphic character sets — Part 1: Latin alphabet No 1. First edition: 1998\nISO/IEC 8859-7 Information technology — 8 bit single-byte coded graphic character sets — Part 7: Latin/Greek alphabet. First edition: 1987\nISO 16844-3 Road vehicles — Tachograph systems — Motion Sensor Interface. WD 3-20/05/99.\n2.\nDATA TYPE DEFINITIONS\nFor 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.\n2.1.\nActivityChangeInfo\nThis 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.\nActivityChangeInfo ::= OCTET STRING (SIZE(2))\nValue assignment — Octet Aligned: ′scpaattttttttttt′B (16 bits)\nFor Data Memory recordings (or slot status):\n′s′B Slot:\n′0′B : DRIVER,\n′1′B : CO-DRIVER,\n′c′B Driving status:\n′0′B : SINGLE,\n′1′B : CREW,\n′p′B Driver (or workshop) card status in the relevant slot:\n′0′B : INSERTED, a card is inserted,\n′1′B : NOT INSERTED, no card is inserted (or a card is withdrawn),\n′aa′B Activity:\n′00′B : BREAK/REST,\n′01′B : AVAILABILITY,\n′10′B : WORK,\n′11′B : DRIVING,\n′ttttttttttt′B Time of the change: Number of minutes since 00h00 on the given day.\nFor Driver (or Workshop) card recordings (and driver status):\n′s′B Slot (not relevant when ′p′ = 1 except note below):\n′0′B : DRIVER,\n′1′B : 2. CO-DRIVER,\n′c′B Driving status (case ′p′ = 0) or\nFollowing activity status (case ′p′ = 1):\n′0′B : SINGLE,\n′0′B : UNKNOWN\n′1′B : CREW,\n′1′B : KNOWN (= manually entered)\n′p′B Card status:\n′0′B : INSERTED, the card is inserted in a recording equipment,\n′1′B : NOT INSERTED, the card is not inserted (or the card is withdrawn),\n′aa′B Activity (not relevant when ′p′ = 1 and ′c′ = 0 except note below):\n′00′B : BREAK/REST,\n′01′B : AVAILABILITY,\n′10′B : WORK,\n′11′B : DRIVING,\n′ttttttttttt′B Time of the change: Number of minutes since 00h00 on the given day.\nNote for the case ‘card withdrawal’:\nWhen the card is withdrawn:\n′s′ is relevant and indicates the slot from which the card is withdrawn,\n′c′ must be set to 0,\n′p′ must be set to 1,\n′aa′ must code the current activity selected at that time,\nAs 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.\n2.2.\nAddress\nAn address.\naddress ::= SEQUENCE {\ncodePage INTEGER (0..255),\naddress OCTET STRING (SIZE(35))\n}\ncodePage specifies the part of the ISO/IEC 8859 used to code the address,\naddress is an address coded in accordance with ISO/IEC 8859-codePage.\n2.3.\nBCDString\nBCDString 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′.\nBCDString ::= CHARACTER STRING (WITH COMPONENTS {\nidentification ( WITH COMPONENTS {\nfixed PRESENT }) })\nBCDString 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.\nPermitted digits are: 0, 1, … 9.\n2.4.\nCalibrationPurpose\nCode explaining why a set of calibration parameters was recorded. This data type is related to requirements 097 and 098.\nCalibrationPurpose ::= OCTET STRING (SIZE(1)).\nValue assignment:\n′00′H reserved value,\n′01′H activation: recording of calibration parameters known, at the moment of the VU activation,\n′02′H first installation: first calibration of the VU after its activation,\n′03′H installation: first calibration of the VU in the current vehicle,\n′04′H periodic inspection.\n2.5.\nCardActivityDailyRecord\nInformation, stored in a card, related to the driver activities for a particular calendar day. This data type is related to requirements 199 and 219.\nCardActivityDailyRecord ::= SEQUENCE {\nactivityPreviousRecordLength INTEGER(0..CardActivityLengthRange),\nactivityRecordDate TimeReal,\nactivityDailyPresenceCounter DailyPresenceCounter,\nactivityDayDistance Distance,\nactivityChangeInfo SET SIZE(1..1440) OF ActivityChangeInfo\n}\nactivityPreviousRecordLength 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.\nactivityRecordLength is the total length in bytes of this record. The maximum value is given by the length of the OCTET STRING containing these records.\nactivityRecordDate is the date of the record.\nactivityDailyPresenceCounter is the daily presence counter for the card this day.\nactivityDayDistance is the total distance travelled this day.\nactivityChangeInfo 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.\n2.6.\nCardActivityLengthRange\nNumber of bytes in a driver or a workshop card, available to store driver activity records.\nCardActivityLengthRange ::= INTEGER(0..2 16 -1)\nValue assignment: see paragraph 3.\n2.7.\nCardApprovalNumber\nType approval number of the card.\nCardApprovalNumber ::= IA5String(SIZE(8))\nValue assignment: Unspecified.\n2.8.\nCardCertificate\nCertificate of the public key of a card.\nCardCertificate ::= Certificate .\n2.9.\nCardChipIdentification\nInformation, stored in a card, related to the identification of the card's Integrated Circuit (IC) (requirement 191).\nCardChipIdentification ::= SEQUENCE {\nicSerialNumber OCTET STRING (SIZE(4)),\nicManufacturingReferences OCTET STRING (SIZE(4))\n}\nicSerialNumber is the IC serial number as defined in EN 726-3.\nicManufacturingReferences is the IC manufacturer identifier and fabrication elements as defined in EN 726-3.\n2.10.\nCardConsecutiveIndex\nA card consecutive index (definition h)).\nCardConsecutiveIndex ::= IA5String(SIZE(1))\nValue assignment: (see this Annex Chapter VII)\nOrder for increase: ′0, …, 9, A, … , Z, a, … , z′.\n2.11.\nCardControlActivityDataRecord\nInformation, stored in a driver or workshop card, related to the last control the driver has been subject to (requirements 210 and 225).\nCardControlActivityDataRecord ::= SEQUENCE {\ncontrolType controlType,\ncontrolTime TimeReal,\ncontrolCardNumber FullCardNumber,\ncontrolVehicleRegistration VehicleRegistrationIdentification,\ncontrolDownloadPeriodBegin TimeReal,\ncontrolDownloadPeriodEnd TimeReal,\n}\ncontrolType is the type of the control.\ncontrolTime is the date and time of the control.\ncontrolCardNumber is the FullCardNumber of the control officer having performed the control.\ncontrolVehicleRegistration is the VRN and registering Member State of the vehicle in which the control happened.\ncontrolDownloadPeriodBegin and controlDownloadPeriodEnd is the period downloaded, in case of downloading.\n2.12.\nCardCurrentUse\nInformation about the actual usage of the card (requirement 212).\nCardCurrentUse ::= SEQUENCE {\nsessionOpenTime TimeReal,\nsessionOpenVehicle VehicleRegistrationIdentification\n}\nsessionOpenTime is the time when the card is inserted for the current usage. This element is set to zero at card removal.\nsessionOpenVehicle is the identification of the currently used vehicle, set at card insertion. This element is set to zero at card removal.\n2.13.\nCardDriverActivity\nInformation, stored in a driver or a workshop card, related to the activities of the driver (requirements 199 and 219).\nCardDriverActivity ::= SEQUENCE {\nactivityPointerOldestDayRecord INTEGER(0..CardActivityLengthRange-1),\nactivityPointerNewestRecord INTEGER(0..CardActivityLengthRange-1),\nactivityDailyRecords OCTET STRING (SIZE(CardActivityLengthRange))\n}\nactivityPointerOldestDayRecord 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.\nactivityPointerNewestRecord 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.\nactivityDailyRecords is the space available to store the driver activity data (data structure: CardActivityDailyRecord) for each calendar day where the card has been used.\nValue assignment: this octet string is cyclically filled with records of CardActivityDailyRecord. 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 activityPreviousRecordLength of this (new) oldest complete day record must be reset to 0.\n2.14.\nCardDrivingLicenceInformation\nInformation, stored in a driver card, related to the card holder driver licence data (requirement 196).\nCardDrivingLicenceInformation ::= SEQUENCE {\ndrivingLicenceIssuingAuthority Name,\ndrivingLicenceIssuingNation NationNumeric,\ndrivingLicenceNumber IA5String(SIZE(16))\n}\ndrivingLicenceIssuingAuthority is the authority responsible for issuing the driving licence.\ndrivingLicenceIssuingNation is the nationality of the authority that issued the driving licence.\ndrivingLicenceNumber is the number of the driving licence.\n2.15.\nCardEventData\nInformation, stored in a driver or workshop card, related to the events associated with the card holder (requirements 204 and 223).\nCardEventData ::= SEQUENCE SIZE(6) OF {\ncardEventRecords SET SIZE(NoOfEventsPerType) OF CardEventRecord\n}\nCardEventData 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).\ncardEventRecords is a set of event records of a given event type (or category for security breach attempts events).\n2.16.\nCardEventRecord\nInformation, stored in a driver or a workshop card, related to an event associated to the card holder (requirements 205 and 223).\nCardEventRecord ::= SEQUENCE {\neventType EventFaultType,\neventBeginTime TimeReal,\neventEndTime TimeReal,\neventVehicleRegistration VehicleRegistrationIdentification\n}\neventType is the type of the event.\neventBeginTime is the date and time of beginning of event.\neventEndTime is the date and time of end of event.\neventVehicleRegistration is the VRN and registering Member State of vehicle in which the event happened.\n2.17.\nCardFaultData\nInformation, stored in a driver or a workshop card, related to the faults associated to the card holder (requirements 207 and 223).\nCardFaultData ::= SEQUENCE SIZE(2) OF {\ncardFaultRecords SET SIZE(NoOfFaultsPerType) OF CardFaultRecord\n}\nCardFaultData is a sequence of Recording Equipment faults set of records followed by card faults set of records.\ncardFaultRecords is a set of fault records of a given fault category (Recording Equipment or card).\n2.18.\nCardFaultRecord\nInformation, stored in a driver or a workshop card, related to a fault associated to the card holder (requirement 208 and 223).\nCardFaultRecord ::= SEQUENCE {\nfaultType EventFaultType,\nfaultBeginTime TimeReal,\nfaultEndTime TimeReal,\nfaultVehicleRegistration VehicleRegistrationIdentification\n}\nfaultType is the type of the fault.\nfaultBeginTime is the date and time of beginning of fault.\nfaultEndTime is the date and time of end of fault.\nfaultVehicleRegistration is the VRN and registering Member State of vehicle in which the fault happened.\n2.19.\nCardIccIdentification\nInformation, stored in a card, related to the identification of the integrated circuit (IC) card (requirement 192).\nCardIccIdentification ::= SEQUENCE {\nclockStop OCTET STRING (SIZE(1)),\ncardExtendedSerialNumber ExtendedSerialNumber,\ncardApprovalNumber CardApprovalNumber\ncardPersonaliserID OCTET STRING (SIZE(1)),\nembedderIcAssemblerId OCTET STRING (SIZE(5)),\nicIdentifier OCTET STRING (SIZE(2))\n}\nclockStop is the Clockstop mode as defined in EN 726-3.\ncardExtendedSerialNumber is the IC card serial number and IC card manufacturing reference as defined in EN 726-3 and as further specified by the ExtendedSerialNumber data type.\ncardApprovalNumber is the type approval number of the card.\ncardPersonaliserID is the card personaliser ID as defined in EN 726-3.\nembedderIcAssemblerId is the embedder/IC assembler identifier as defined in EN 726-3.\nicIdentifier is the Identifier of the IC on the card and its IC manufacturer as defined in EN 726-3.\n2.20.\nCardIdentification\nInformation, stored in a card, related to the identification of the card (requirements 194, 215, 231, 235).\nCardIdentification ::= SEQUENCE\ncardIssuingMemberState NationNumeric,\ncardNumber CardNumber,\ncardIssuingAuthorityName Name,\ncardIssueDate TimeReal,\ncardValidityBegin TimeReal,\ncardExpiryDate TimeReal\n}\ncardIssuingMemberState is the code of the Member State issuing the card.\ncardNumber is the card number of the card.\ncardIssuingAuthorityName is the name of the authority having issued the Card.\ncardIssueDate is the issue date of the Card to the current holder.\ncardValidityBegin is the first date of validity of the card.\ncardExpiryDate is the date when the validity of the card ends.\n2.21.\nCardNumber\nA card number as defined by definition g).\nCardNumber ::= CHOICE {\nSEQUENCE {\ndriverIdentification IA5String(SIZE(14)),\ncardReplacementIndex CardReplacementIndex,\ncardRenewalIndex CardRenewalIndex\n}\nSEQUENCE {\nownerIdentification IA5String(SIZE(13)),\ncardConsecutiveIndex CardConsecutiveIndex,\ncardReplacementIndex CardReplacementIndex,\ncardRenewalIndex CardRenewalIndex\n}\n}\ndriverIdentification is the unique identification of a driver in a Member State.\nownerIdentification is the unique identification of a company or a workshop or a control body within a Member State.\ncardConsecutiveIndex is the card consecutive index.\ncardReplacementIndex is the card replacement index.\ncardRenewalIndex is the card renewal index.\nThe 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.\n2.22.\nCardPlaceDailyWorkPeriod\nInformation, stored in a driver or a workshop card, related to the places where daily work periods begin and/or end (requirements 202 and 221).\nCardPlaceDailyWorkPeriod ::= SEQUENCE {\nplacePointerNewestRecord INTEGER(0..NoOfCardPlaceRecords-1),\nplaceRecords SET SIZE(NoOfCardPlaceRecords) OF PlaceRecord\n}\nplacePointerNewestRecord is the index of the last updated place record.\nValue assignment: Number corresponding to the numerator of the place record, beginning with ’0’ for the first occurrence of the place records in the structure.\nplaceRecords is the set of records containing the information related to the places entered.\n2.23.\nCardPrivateKey\nThe private key of a card.\nCardPrivateKey ::= RSAKeyPrivateExponent.\n2.24.\nCardPublicKey\nThe public key of a card.\nCardPublicKey ::= PublicKey.\n2.25.\nCardRenewalIndex\nA card renewal index (definition i)).\nCardRenewalIndex ::= IA5String(SIZE(1)).\nValue assignment: (see this Annex Chapter VII).\n′0′ First issue.\nOrder for increase: ′0, …, 9, A, …, Z′.\n2.26.\nCardReplacementIndex\nA card replacement index (definition j)).\nCardReplacementIndex ::= IA5String(SIZE(1))\nValue assignment: (see this Annex Chapter VII).\n′0′ Original card.\nOrder for increase: ′0, …, 9, A, …, Z′.\n2.27.\nCardSlotNumber\nCode to distinguish between the two slots of a vehicle unit.\nCardSlotNumber ::= INTEGER {\ndriverSlot (0),\nco-driverSlot (1)\n}\nValue assignment: not further specified.\n2.28.\nCardSlotsStatus\nCode indicating the type of cards inserted in the two slots of the vehicle unit.\nCardSlotsStatus ::= OCTET STRING (SIZE(1))\nValue assignment — Octet Aligned: ′ccccdddd′B :\n′cccc′B Identification of the type of card inserted in the co-driver slot,\n′dddd′B Identification of the type of card inserted in the driver slot,\nwith the following identification codes:\n′0000′B no card is inserted,\n′0001′B a driver card is inserted,\n′0010′B a workshop card is inserted,\n′0011′B a control card is inserted,\n′0100′B a company card is inserted.\n2.29.\nCardStructureVersion\nCode indicating the version of the implemented structure in a tachograph card.\nCardStructureVersion ::= OCTET STRING (SIZE(2))\nValue assignment: ′aabb′H:\n′aa′H Index for changes of the structure,\n′bb′H Index for changes concerning the use of the data elements defined for the structure given by the high byte.\n2.30.\nCardVehicleRecord\nInformation, stored in a driver or workshop card, related to a period of use of a vehicle during a calendar day (requirements 197 and 217).\nCardVehicleRecord ::= SEQUENCE {\nvehicleOdometerBegin OdometerShort,\nvehicleOdometerEnd OdometerShort,\nvehicleFirstUse TimeReal,\nvehicleLastUse TimeReal,\nvehicleRegistration VehicleRegistrationIdentification,\nvuDataBlockCounter VuDataBlockCounter\n}\nvehicleOdometerBegin is the vehicle odometer value at the beginning of the period of use of the vehicle.\nvehicleOdometerEnd is the vehicle odometer value at the end of the period of use of the vehicle.\nvehicleFirstUse is the date and time of the beginning of the period of use of the vehicle.\nvehicleLastUse is the date and time of the end of the period of use of the vehicle.\nvehicleRegistration is the VRN and the registering Member State of the vehicle.\nvuDataBlockCounter is the value of the VuDataBlockCounter at last extraction of the period of use of the vehicle.\n2.31.\nCardVehiclesUsed\nInformation, stored in a driver or workshop card, related to the vehicles used by the card holder (requirements 197 and 217).\nCardVehiclesUsed := SEQUENCE {\nvehiclePointerNewestRecord INTEGER(0..NoOfCardVehicleRecords-1),\ncardVehicleRecords SET SIZE(NoOfCardVehicleRecords) OF CardVehicleRecord\n}\nvehiclePointerNewestRecord is the index of the last updated vehicle record.\nValue assignment: Number corresponding to the numerator of the vehicle record, beginning with ′0′ for the first occurrence of the vehicle records in the structure.\ncardVehicleRecords is the set of records containing information on vehicles used.\n2.32.\nCertificate\nThe certificate of a public key issued by a Certification Authority.\nCertificate ::= OCTET STRING (SIZE(194))\nValue assignment: digital signature with partial recovery of a CertificateContent according to Appendix 11 ‘common security mechanisms’: Signature (128 bytes) || Public Key remainder (58 Byte) || Certification Authority Reference (8 bytes).\n2.33.\nCertificateContent\nThe (clear) content of the certificate of a public key according to Appendix 11 common security mechanisms.\nCertificateContent ::= SEQUENCE {\ncertificateProfileIdentifier INTEGER(0..255),\ncertificationAuthorityReference KeyIdentifier,\ncertificateHolderAuthorisation CertificateHolderAuthorisation,\ncertificateEndOfValidity TimeReal,\ncertificateHolderReference KeyIdentifier,\npublicKey PublicKey\n}\ncertificateProfileIdentifier is the version of the corresponding certificate.\nValue assignment: : ′01h′ for this version.\nCertificationAuthorityReference identifies the Certification Authority issuing the certificate. It also references the Public Key of this Certification Authority.\ncertificateHolderAuthorisation identifies the rights of the certificate holder.\ncertificateEndOfValidity is the date when the certificate expires administratively.\ncertificateHolderReference identifies the certificate holder. It also references his Public Key.\npublicKey is the public key that is certified by this certificate.\n2.34.\nCertificateHolderAuthorisation\nIdentification of the rights of a certificate holder.\nCertificateHolderAuthorisation ::= SEQUENCE {\ntachographApplicationID OCTET STRING(SIZE(6))\nequipmentType EquipmentType\n}\ntachographApplicationID is the application identifier for the tachograph application.\nValue assignment : ′FFh′ ′54h′ ′41h′ ′43h′ ′48h′ ′4Fh′. This AID is a proprietary non-registered application identifier in accordance with ISO/IEC 7816-5.\nequipmentType is the identification of the type of equipment to which the certificate is intended.\nValue assignment : in accordance with EquipmentType data type. 0 if certificate is the one of a Member State.\n2.35.\nCertificateRequestID\nUnique 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.\nCertificateRequestID ::= SEQUENCE {\nrequestSerialNumber INTEGER(0..2 32 -1)\nrequestMonthYear BCDString(SIZE(2))\ncrIdentifier OCTET STRING(SIZE(1))\nmanufacturerCode ManufacturerCode\n}\nrequestSerialNumber is a serial number for the certificate request, unique for the manufacturer and the month below.\nrequestMonthYear is the identification of the month and the year of the certificate request.\nValue assignment: BCD coding of month (two digits) and year (two last digits).\ncrIdentifier: is an identifier to distinguish a certificate request from an extended serial number.\nValue assignment: ′FFh′.\nmanufacturerCode: is the numerical code of the manufacturer requesting the certificate.\n2.36.\nCertificationAuthorityKID\nIdentifier of the Public Key of a Certification Authority (a Member State or the European Certification Authority).\nCertificationAuthorityKID ::= SEQUENCE {\nnationNumeric NationNumeric\nnationAlpha NationAlpha\nkeySerialNumber INTEGER(0..255)\nadditionalInfo OCTET STRING(SIZE(2))\ncaIdentifier OCTET STRING(SIZE(1))\n}\nnationNumeric is the numerical nation code of the Certification Authority.\nnationAlpha is the alphanumerical nation code of the Certification Authority.\nkeySerialNumber is a serial number to distinguish the different keys of the Certification Authority in the case keys are changed.\nadditionalInfo is a two byte field for additional coding (Certification Authority specific).\ncaIdentifier is an identifier to distinguish a Certification Authority Key Identifier from other Key Identifiers.\nValue assignment: ′01h′.\n2.37.\nCompanyActivityData\nInformation, stored in a company card, related to activities performed with the card (requirement 237).\nCompanyActivityData ::= SEQUENCE {\ncompanyPointerNewestRecord INTEGER(0..NoOfCompanyActivityRecords-1),\ncompanyActivityRecords SET SIZE(NoOfCompanyActivityRecords) OF\ncompanyActivityRecord SEQUENCE {\ncompanyActivityType CompanyActivityType,\ncompanyActivityTime TimeReal,\ncardNumberInformation FullCardNumber,\nvehicleRegistrationInformation VehicleRegistrationIdentification,\ndownloadPeriodBegin TimeReal,\ndownloadPeriodEnd TimeReal\n}\n}\ncompanyPointerNewestRecord is the index of the last updated companyActivityRecord.\nValue 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.\ncompanyActivityRecords is the set of all company activity records.\ncompanyActivityRecord is the sequence of information related to one company activity.\ncompanyActivityType is the type of the company activity.\ncompanyActivityTime is the date and time of the company activity.\ncardNumberInformation is the card number and the card issuing Member State of the card downloaded, if any.\nvehicleRegistrationInformation is the VRN and registering Member State of the vehicle downloaded or locked in or out.\ndownloadPeriodBegin and downloadPeriodEnd is the period downloaded from the VU, if any.\n2.38.\nCompanyActivityType\nCode indicating an activity carried out by a company using its company card.\nCompanyActivityType ::= INTEGER {\ncard downloading (1),\nVU downloading (2),\nVU lock-in (3),\nVU lock-out (4).\n}\n2.39.\nCompanyCardApplicationIdentification\nInformation, stored in a company card related to the identification of the application of the card (requirement 190).\nCompanyCardApplicationIdentification ::= SEQUENCE {\ntypeOfTachographCardId EquipmentType,\ncardStructureVersion CardStructureVersion,\nnoOfCompanyActivityRecords NoOfCompanyActivityRecords\n}\ntypeOfTachographCardId is specifying the implemented type of card.\ncardStructureVersion is specifying the version of the structure that is implemented in the card.\nnoOfCompanyActivityRecords is the number of company activity records the card can store.\n2.40.\nCompanyCardHolderIdentification\nInformation, stored in a company card, related to the cardholder identification (requirement 236).\nCompanyCardHolderIdentification ::= SEQUENCE {\ncompanyName Name,\ncompanyAddress Address,\ncardHolderPreferredLanguage Language\n}\ncompanyName is the name of the holder company.\ncompanyAddress is the address of the holder company.\ncardHolderPreferredLanguage is the preferred language of the card holder.\n2.41.\nControlCardApplicationIdentification\nInformation, stored in a control card related to the identification of the application of the card (requirement 190).\nControlCardApplicationIdentification ::= SEQUENCE {\ntypeOfTachographCardId EquipmentType,\ncardStructureVersion CardStructureVersion,\nnoOfControlActivityRecords NoOfControlActivityRecords\n}\ntypeOfTachographCardId is specifying the implemented type of card.\ncardStructureVersion is specifying the version of the structure that is implemented in the card.\nnoOfControlActivityRecords is the number of control activity records the card can store.\n2.42.\nControlCardControlActivityData\nInformation, stored in a control card, related to control activity performed with the card (requirement 233).\nControlCardControlActivityData ::= SEQUENCE {\ncontrolPointerNewestRecord INTEGER(0..NoOfControlActivityRecords-1),\ncontrolActivityRecords SET SIZE(NoOfControlActivityRecords) OF\ncontrolActivityRecord SEQUENCE {\ncontrolType ControlType,\ncontrolTime TimeReal,\ncontrolledCardNumber FullCardNumber,\ncontrolledVehicleRegistration VehicleRegistrationIdentification,\ncontrolDownloadPeriodBegin TimeReal,\ncontrolDownloadPeriodEnd TimeReal\n}\n}\ncontrolPointerNewestRecord is the index of the last updated control activity record.\nValue 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.\ncontrolActivityRecords is the set of all control activity records.\ncontrolActivityRecord is the sequence of information related to one control.\ncontrolType is the type of the control.\ncontrolTime is the date and time of the control.\ncontrolledCardNumber is the card number and the card issuing Member State of the card controlled.\ncontrolledVehicleRegistration is the VRN and registering Member State of the vehicle in which the control happened.\ncontrolDownloadPeriodBegin and controlDownloadPeriodEnd is the period eventually downloaded.\n2.43.\nControlCardHolderIdentification\nInformation, stored in a control card, related to the identification of the cardholder (requirement 232).\nControlCardHolderIdentification ::= SEQUENCE {\ncontrolBodyName Name,\ncontrolBodyAddress Address,\ncardHolderName HolderName,\ncardHolderPreferredLanguage Language\n}\ncontrolBodyName is the name of the control body of the card holder.\ncontrolBodyAddress is the address of the control body of the card holder.\ncardHolderName is the name and first name(s) of the holder of the Control Card.\ncardHolderPreferredLanguage is the preferred language of the card holder.\n2.44.\nControlType\nCode indicating the activities carried out during a control. This data type is related to requirements 102, 210 and 225.\nControlType ::= OCTET STRING (SIZE(1))\nValue assignment — Octet aligned: ′cvpdxxxx′B (8 bits)\n′c′B card downloading:\n′0′B : card not downloaded during this control activity,\n′1′B : card downloaded during this control activity\n′v′B VU downloading:\n′0′B : VU not downloaded during this control activity,\n′1′B : VU downloaded during this control activity\n′p′B printing:\n′0′B : no printing done during this control activity,\n′1′B : printing done during this control activity\n′d′B display:\n′0′B : no display used during this control activity,\n′1′B : display used during this control activity\n′xxxx′B Not used.\n2.45.\nCurrentDateTime\nThe current date and time of the recording equipment.\nCurrentDateTime ::= TimeReal\nValue assignment : not further specified.\n2.46.\nDailyPresenceCounter\nCounter, 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.\nDailyPresenceCounter ::= BCDString(SIZE(2))\nValue 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.\n2.47.\nDatef\nDate expressed in a readily printable numeric format.\nDatef ::= SEQUENCE {\nyear BCDString(SIZE(2)),\nmonth BCDString(SIZE(1)),\nday BCDString(SIZE(1))\n}\nValue assignment:\nyyyy Year\nmm Month\ndd Day\n′00000000′H denotes explicitly no date.\n2.48.\nDistance\nA distance travelled (result of the calculation of the difference between two vehicle's odometer value in kilometres).\nDistance ::= INTEGER(0..2 16 -1)\nValue assignment: Unsigned binary. Value in km in the operational range 0 to 9 999 km.\n2.49.\nDriverCardApplicationIdentification\nInformation, stored in a driver card related to the identification of the application of the card (requirement 190).\nDriverCardApplicationIdentification ::= SEQUENCE {\ntypeOfTachographCardId EquipmentType,\ncardStructureVersion CardStructureVersion,\nnoOfEventsPerType NoOfEventsPerType,\nnoOfFaultsPerType NoOfFaultsPerType,\nactivityStructureLength CardActivityLengthRange,\nnoOfCardVehicleRecords NoOfCardVehicleRecords,\nnoOfCardPlaceRecords NoOfCardPlaceRecords\n}\ntypeOfTachographCardId is specifying the implemented type of card.\ncardStructureVersion is specifying the version of the structure that is implemented in the card.\nnoOfEventsPerType is the number of events per type of event the card can record.\nnoOfFaultsPerType is the number of faults per type of fault the card can record.\nactivityStructureLength indicates the number of bytes available for storing activity records.\nnoOfCardVehicleRecords is the number of vehicle records the card can contain.\nnoOfCardPlaceRecords is the number of places the card can record.\n2.50.\nDriverCardHolderIdentification\nInformation, stored in a driver card, related to the identification of the cardholder (requirement 195).\nDriverCardHolderIdentification ::= SEQUENCE {\ncardHolderName HolderName,\ncardHolderBirthDate Datef,\ncardHolderPreferredLanguage Language\n}\ncardHolderName is the name and first name(s) of the holder of the Driver Card.\ncardHolderBirthDate is the date of birth of the holder of the Driver Card.\ncardHolderPreferredLanguage is the preferred language of the card holder.\n2.51.\nEntryTypeDailyWorkPeriod\nCode to distinguish between begin and end for an entry of a daily work period place and condition of the entry.\nEntryTypeDailyWorkPeriod ::= INTEGER\nBegin, related time = card insertion time or time of entry (0),\nEnd, related time = card withdrawal time or time of entry (1),\nBegin, related time manually entered (start time) (2),\nEnd, related time manually entered (end of work period) (3),\nBegin, related time assumed by VU (4),\nEnd, related time assumed by VU (5)\n}\nValue assignment : according to ISO/IEC8824-1.\n2.52.\nEquipmentType\nCode to distinguish different types of equipment for the tachograph application.\nEquipmentType ::= INTEGER(0..255)\n- - Reserved (0),\n- - Driver Card (1),\n- - Workshop Card (2),\n- - Control Card (3),\n- - Company Card (4),\n- - Manufacturing Card (5),\n- - Vehicle Unit (6),\n- - Motion Sensor (7),\n- - RFU (8..255)\nValue assignment : According to ISO/IEC 8824-1.\nValue 0 is reserved for the purpose of designating a Member State or Europe in the CHA field of certificates.\n2.53.\nEuropeanPublicKey\nThe European public key.\nEuropeanPublicKey ::= PublicKey .\n2.54.\nEventFaultType\nCode qualifying an event or a fault.\nEventFaultType ::= OCTET STRING (SIZE(1)) .\nValue assignment:\n′0x′H General events,\n′00′H No further details,\n′01′H Insertion of a non-valid card,\n′02′H Card conflict,\n′03′H Time overlap,\n′04′H Driving without an appropriate card,\n′05′H Card insertion while driving,\n′06′H Last card session not correctly closed,\n′07′H Over speeding,\n′08′H Power supply interruption,\n′09′H Motion data error,\n′0A′H to ′0F′H RFU,\n′1x′H Vehicle unit related security breach attempt events,\n′10′H No further details,\n′11′H Motion sensor authentication failure,\n′12′H Tachograph card authentication failure,\n′13′H Unauthorised change of motion sensor,\n′14′H Card data input integrity error\n′15′H Stored user data integrity error,\n′16′H Internal data transfer error,\n′17′H Unauthorised case opening,\n′18′H Hardware sabotage,\n′19′H to ′1F′H RFU,\n′2x′H Sensor related security breach attempt events,\n′20′H No further details,\n′21′H Authentication failure,\n′22′H Stored data integrity error,\n′23′H Internal data transfer error,\n′24′H Unauthorised case opening,\n′25′H Hardware sabotage,\n′26′H to ′2F′H RFU,\n′3x′H Recording equipment faults,\n′30′H No further details,\n′31′H VU internal fault,\n′32′H Printer fault,\n′33′H Display fault,\n′34′H Downloading fault,\n′35′H Sensor fault,\n′36′H to ′3F′H RFU\n′4x′H Card faults,\n′40′H No further details,\n′41′H to ′4F′H RFU\n′50′H to ′7F′H RFU,\n′80′H to ′FF′H Manufacturer specific.\n2.55.\nEventFaultRecordPurpose\nCode explaining why an event or a fault has been recorded.\nEventFaultRecordPurpose ::= OCTET STRING (SIZE(1)) .\nValue assignment:\n′00′H one of the 10 most recent (or last) events or faults\n′01′H the longest event for one of the last 10 days of occurrence\n′02′H one of the 5 longest events over the last 365 days\n′03′H the last event for one of the last 10 days of occurrence\n′04′H the most serious event for one of the last 10 days of occurrence\n′05′H one of the 5 most serious events over the last 365 days\n′06′H the first event or fault having occurred after the last calibration\n′07′H an active/on-going event or fault\n′08′H to ′7F′H RFU\n′80′H to ′FF′H manufacturer specific.\n2.56.\nExtendedSerialNumber\nUnique identification of an equipment. It can also be used as an equipment Public Key Identifier.\nExtendedSerialNumber ::= SEQUENCE {\nserialNumber INTEGER(0..2 32 -1)\nmonthYear BCDString(SIZE(2))\ntype OCTET STRING(SIZE(1))\nmanufacturerCode ManufacturerCode\n}\nserialNumber is a serial number for the equipment, unique for the manufacturer, the equipment's type and the month below.\nmonthYear is the identification of the month and the year of manufacturing (or of serial number assignment).\nValue assignment: BCD coding of Month (two digits) and Year (two last digits).\ntype is an identifier of the type of equipment.\nValue assignment: manufacturer specific, with FFh' reserved value.\nmanufacturerCode: is the numerical code of the manufacturer of the equipment.\n2.57.\nFullCardNumber\nCode fully identifying a tachograph card.\nFullCardNumber ::= SEQUENCE {\ncardType EquipmentType,\ncardIssuingMemberState NationNumeric,\ncardNumber CardNumber\n}\ncardType is the type of the tachograph card.\ncardIssuingMemberState is the code of the Member State having issued the card.\ncardNumber is the card number.\n2.58.\nHighResOdometer\nOdometer value of the vehicle: Accumulated distance travelled by the vehicle during its operation.\nHighResOdometer ::= INTEGER(0..2 32 -1)\nValue assignment : Unsigned binary. Value in 1/200 km in the operating range 0 to 21 055 406 km.\n2.59.\nHighResTripDistance\nA distance travelled during all or part of a journey.\nHighResTripDistance ::= INTEGER(0..2 32 -1)\nValue assignment : Unsigned binary. Value in 1/200 km in the operating range 0 to 21 055 406 km.\n2.60.\nHolderName\nThe surname and first name(s) of a card holder.\nHolderName ::= SEQUENCE {\nholderSurname Name,\nholderFirstNames Name\n}\nholderSurname is the surname (family name) of the holder. This surname does not include titles.\nValue assignment: When a card is not personal, holderSurname contains the same information as companyName or workshopName or controlBodyName.\nholderFirstNames is the first name(s) and initials of the holder.\n2.61.\nK-ConstantOfRecordingEquipment\nConstant of the recording equipment (definition m)).\nK-ConstantOfRecordingEquipment ::= INTEGER(0..2 16 -1)\nValue assignment : Pulses per kilometre in the operating range 0 to 64 255 pulses/km.\n2.62.\nKeyIdentifier\nA unique identifier of a Public Key used to reference and select the key. It also identifies the holder of the key.\nKeyIdentifier ::= CHOICE {\nextendedSerialNumber ExtendedSerialNumber,\ncertificateRequestID CertificateRequestID,\ncertificationAuthorityKID CertificationAuthorityKID\n}\nThe first choice is suitable to reference the public key of a Vehicle Unit or of a tachograph card.\nThe 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).\nThe third choice is suitable to reference the public key of a Member State.\n2.63.\nL-TyreCircumference\nEffective circumference of the wheel tyres (definition u)).\nL-TyreCircumference ::= INTEGER(0..2 16 -1)\nValue assignment : Unsigned binary, value in 1/8 mm in the operating range 0 to 8 031 mm.\n2.64.\nLanguage\nCode identifying a language.\nLanguage ::= IA5String(SIZE(2))\nValue assignment : Two-letter lower-case coding according to ISO 639.\n2.65.\nLastCardDownload\nDate 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.\nLastCardDownload ::= TimeReal\nValue assignment : not further specified.\n2.66.\nManualInputFlag\nCode identifying whether a cardholder has manually entered driver activities at card insertion or not (requirement 081).\nManualInputFlag ::= INTEGER {\nnoEntry (0)\nmanualEntries (1)\n}\nValue assignment : not further specified.\n2.67.\nManufacturerCode\nCode identifying a manufacturer.\nManufacturerCode ::= INTEGER(0..255)\nValue assignment:\n′00′H No information available\n′01′H Reserved value\n′02′H .. ′0F′H Reserved for Future Use\n′10′H ACTIA\n′11′H .. ′17′H Reserved for manufacturers which name begins with ′A′\n′18′H .. ′1F′H Reserved for manufacturers which name begins with ′B′\n′20′H .. ′27′H Reserved for manufacturers which name begins with ′C′\n′28′H .. ′2F′H Reserved for manufacturers which name begins with ′D′\n′30′H .. ′37′H Reserved for manufacturers which name begins with ′E′\n′38′H .. ′3F′H Reserved for manufacturers which name begins with ′F′\n′40′H Giesecke & Devrient GmbH\n′41′H GEM plus\n′42′H .. ′47′H Reserved for manufacturers which name begins with ′G′\n′48′H .. ′4F′H Reserved for manufacturers which name begins with ′H′\n′50′H .. ′57′H Reserved for manufacturers which name begins with ′I′\n′58′H .. ′5F′H Reserved for manufacturers which name begins with ′J′\n′60′H .. ′67′H Reserved for manufacturers which name begins with ′K′\n′68′H .. ′6F′H Reserved for manufacturers which name begins with ′L′\n′70′H .. ′77′H Reserved for manufacturers which name begins with ′M′\n′78′H .. ′7F′H Reserved for manufacturers which name begins with ′N′\n′80′H OSCARD\n′81′H .. ′87′H Reserved for manufacturers which name begins with ′O′\n′88′H .. ′8F′H Reserved for manufacturers which name begins with ′P′\n′90′H .. ′97′H Reserved for manufacturers which name begins with ′Q′\n′98′H .. ′9F′H Reserved for manufacturers which name begins with ′R′\n′A0′H SETEC\n′A1′H SIEMENS VDO\n′A2′H STONERIDGE\n′A3′H .. ′A7′H Reserved for manufacturers which name begins with ′S′\n′AA′H TACHOCONTROL\n′AB′H .. ′AF′H Reserved for manufacturers which name begins with ′T′\n′B0′H .. ′B7′H Reserved for manufacturers which name begins with ′U′\n′B8′H .. ′BF′H Reserved for manufacturers which name begins with ′V′\n′C0′H .. ′C7′H Reserved for manufacturers which name begins with W′\n′C8′H .. ′CF′H Reserved for manufacturers which name begins with ′X′\n′D0′H .. ′D7′H Reserved for manufacturers which name begins with ′Y′\n′D8′H .. ′DF′H Reserved for manufacturers which name begins with ′Z′\n2.68.\nMemberStateCertificate\nThe certificate of the public key of a Member State issued by the European certification authority.\nMemberStateCertificate ::= Certificate\n2.69.\nMemberStatePublicKey\nThe public key of a Member State.\nMemberStatePublicKey ::= PublicKey .\n2.70.\nName\nA name.\nName ::= SEQUENCE {\ncodePage INTEGER (0..255),\nname OCTET STRING (SIZE(35))\n}\ncodePage specifies the part of the ISO/IEC 8859 used to code the name,\nname is a name coded in accordance with ISO/IEC 8859-codePage.\n2.71.\nNationAlpha\nAlphabetic reference to a country, in accordance with the conventional coding of countries on car bumper stickers, and/or as used on internationally harmonised vehicle insurance papers (green card).\nNationAlpha ::= IA5String(SIZE(3))\nValue assignment:\n′ ′ No information available\n′A′ Austria\n′AL′ Albania\n′AND′ Andorra\n′ARM′ Armenia\n′AZ′ Azerbaijan\n′B′ Belgium\n′BG′ Bulgaria\n′BIH′ Bosnia and Herzegovina\n′BY′ Belarus\n′CH′ Switzerland\n′CY′ Cyprus\n′CZ′ Czech Republic\n′D′ Germany\n′DK′ Denmark\n′E′ Spain\n′EST′ Estonia\n′F′ France\n′FIN′ Finland\n′FL′ Liechtenstein\n′FR′ Faeroe Islands\n′UK′ United Kingdom, Alderney, Guernsey, Jersey, Isle of Man, Gibraltar\n′GE′ Georgia\n′GR′ Greece\n′H′ Hungary\n′HR′ Croatia\n′I′ Italy\n′IRL′ Ireland\n′IS′ Iceland\n′KZ′ Kazakhstan\n′L′ Luxembourg\n′LT′ Lithuania\n′LV′ Latvia\n′M′ Malta\n′MC′ Monaco\n′MD′ Republic of Moldova\n′MK′ Macedonia\n′N′ Norway\n′NL′ The Netherlands\n′P′ Portugal\n′PL′ Poland\n′RO′ Romania\n′RSM′ San Marino\n′RUS′ Russian Federation\n′S′ Sweden\n′SK′ Slovakia\n′SLO′ Slovenia\n′TM′ Turkmenistan\n′TR′ Turkey\n′UA′ Ukraine\n′V′ Vatican City\n′YU′ Yugoslavia\n′UNK′ Unknown\n′EC′ European Community\n′EUR′ Rest of Europe\n′WLD′ Rest of the world.\n2.72.\nNationNumeric\nNumerical reference to a country.\nNationNumeric ::= INTEGER(0..255)\nValue assignment:\n- - No information available (00)H,\n- - Austria (01)H,\n- - Albania (02)H,\n- - Andorra (03)H,\n- - Armenia (04)H,\n- - Azerbaijan (05)H,\n- - Belgium (06)H,\n- - Bulgaria (07)H,\n- - Bosnia and Herzegovina (08)H,\n- - Belarus (09)H,\n- - Switzerland (0A)H,\n- - Cyprus (0B)H,\n- - Czech Republic (0C)H,\n- - Germany (0D)H,\n- - Denmark (0E)H,\n- - Spain (0F)H,\n- - Estonia (10)H,\n- - France (11)H,\n- - Finland (12)H,\n- - Liechtenstein (13)H,\n- - Faeroe Islands (14)H,\n- - United Kingdom (15)H,\n- - Georgia (16)H,\n- - Greece (17)H,\n- - Hungary (18)H,\n- - Croatia (19)H,\n- - Italy (1A)H,\n- - Ireland (1B)H,\n- - Iceland (1C)H,\n- - Kazakhstan (1D)H,\n- - Luxembourg (1E)H,\n- - Lithuania (1F)H,\n- - Latvia (20)H,\n- - Malta (21)H,\n- - Monaco (22)H,\n- - Republic of Moldova (23)H,\n- - Macedonia (24)H,\n- - Norway (25)H,\n- - Netherlands (26)H,\n- - Portugal (27)H,\n- - Poland (28)H,\n- - Romania (29)H,\n- - San Marino (2A)H,\n- - Russian Federation (2B)H,\n- - Sweden (2C)H,\n- - Slovakia (2D)H,\n- - Slovenia (2E)H,\n- - Turkmenistan (2F)H,\n- - Turkey (30)H,\n- - Ukraine (31)H,\n- - Vatican City (32)H,\n- - Yugoslavia (33)H,\n- - RFU (34..FC)H,\n- - European Community (FD)H,\n- - Rest of Europe (FE)H,\n- - Rest of the world (FF)H\n2.73.\nNoOfCalibrationRecords\nNumber of calibration records, a workshop card can store.\nNoOfCalibrationRecords ::= INTEGER(0..255)\nValue assignment: see paragraph 3.\n2.74.\nNoOfCalibrationsSinceDownload\nCounter indicating the number of calibrations performed with a workshop card since its last download (requirement 230).\nNoOfCalibrationsSinceDownload ::= INTEGER(0..2 16 -1),\nValue assignment: Not specified further.\n2.75.\nNoOfCardPlaceRecords\nNumber of place records a driver or workshop card can store.\nNoOfCardPlaceRecords ::= INTEGER(0..255)\nValue assignment: see paragraph 3.\n2.76.\nNoOfCardVehicleRecords\nNumber of vehicles used records a driver or workshop card can store.\nNoOfCardVehicleRecords ::= INTEGER(0..2 16 -1)\nValue assignment: see paragraph 3.\n2.77.\nNoOfCompanyActivityRecords\nNumber of company activity records, a company card can store.\nNoOfCompanyActivityRecords ::= INTEGER(0..2 16 -1)\nValue assignment : see paragraph 3.\n2.78.\nNoOfControlActivityRecords\nNumber of control activity records, a control card can store.\nNoOfControlActivityRecords ::= INTEGER(0..2 16 -1)\nValue assignment : see paragraph 3.\n2.79.\nNoOfEventsPerType\nNumber of events per type of event a card can store.\nNoOfEventsPerType ::= INTEGER(0..255)\nValue assignment: see paragraph 3.\n2.80.\nNoOfFaultsPerType\nNumber of faults per type of fault a card can store.\nNoOfFaultsPerType ::= INTEGER(0..255)\nValue assignment: see paragraph 3.\n2.81.\nOdometerValueMidnight\nThe vehicle's odometer value at midnight on a given day (requirement 090).\nOdometerValueMidnight ::= OdometerShort\nValue assignment: not further specified.\n2.82.\nOdometerShort\nOdometer value of the vehicle in a short form.\nOdometerShort ::= INTEGER(0..2 24 -1)\nValue assignment: Unsigned binary. Value in km in the operating range 0 to 9 999 999 km.\n2.83.\nOverspeedNumber\nNumber of over speeding events since the last over speeding control.\nOverspeedNumber ::= INTEGER(0..255)\nValue 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.\n2.84.\nPlaceRecord\nInformation related to a place where a daily work period begins or ends (requirements 087, 202, 221).\nPlaceRecord ::= SEQUENCE {\nentryTime TimeReal,\nentryTypeDailyWorkPeriod EntryTypeDailyWorkPeriod,\ndailyWorkPeriodCountry NationNumeric,\ndailyWorkPeriodRegion RegionNumeric,\nvehicleOdometerValue OdometerShort\n}\nentryTime is a date and time related to the entry.\nentryTypeDailyWorkPeriod is the type of entry.\ndailyWorkPeriodCountry is the country entered.\ndailyWorkPeriodRegion is the region entered.\nvehicleOdometerValue is the odometer value at the time of place entry.\n2.85.\nPreviousVehicleInfo\nInformation related to the vehicle previously used by a driver when inserting his card in a vehicle unit (requirement 081).\nPreviousVehicleInfo ::= SEQUENCE {\nvehicleRegistrationIdentification VehicleRegistrationIdentification,\ncardWithdrawalTime TimeReal\n}\nvehicleRegistrationIdentification is the VRN and the registering Member State of the vehicle.\ncardWithdrawalTime is the card withdrawal date and time.\n2.86.\nPublicKey\nA public RSA key.\nPublicKey ::= SEQUENCE {\nrsaKeyModulus RSAKeyModulus,\nrsaKeyPublicExponent RSAKeyPublicExponent\n}\nrsaKeyModulus is the Modulus of the key pair.\nrsaKeyPublicExponent is the public exponent of the key pair.\n2.87.\nRegionAlpha\nAlphabetic reference to a region within a specified country.\nRegionAlpha ::= IA5STRING(SIZE(3))\nValue assignment:\n′ ′ No information available\nSpain:\n′AN′ Andalucía\n′AR′ Aragón\n′AST′ Asturias\n′C′ Cantabria\n′CAT′ Cataluña\n′CL′ Castilla-León\n′CM′ Castilla-La-Mancha\n′CV′ Valencia\n′EXT′ Extremadura\n′G′ Galicia\n′IB′ Baleares\n′IC′ Canarias\n′LR′ La Rioja\n′M′ Madrid\n′MU′ Murcia\n′NA′ Navarra\n′PV′ País Vasco.\n2.88.\nRegionNumeric\nNumerical reference to a region within a specified country.\nRegionNumeric ::= OCTET STRING (SIZE(1))\nValue assignment:\n′00′H No information available\nSpain:\n′01′H Andalucía\n′02′H Aragón\n′03′H Asturias\n′04′H Cantabria\n′05′H Cataluña\n′06′H Castilla-León\n′07′H Castilla-La-Mancha\n′08′H Valencia\n′09′H Extremadura\n′0A′H Galicia\n′0B′H Baleares\n′0C′H Canarias\n′0D′H La Rioja\n′0E′H Madrid\n′0F′H Murcia\n′10′H Navarra\n′11′H País Vasco.\n2.89.\nRSAKeyModulus\nThe modulus of a RSA key pair.\nRSAKeyModulus ::= OCTET STRING (SIZE(128))\nValue assignment : Unspecified.\n2.90.\nRSAKeyPrivateExponent\nThe private exponent of a RSA key pair.\nRSAKeyPrivateExponent ::= OCTET STRING (SIZE(128))\nValue assignment : Unspecified.\n2.91.\nRSAKeyPublicExponent\nThe public exponent of a RSA key pair.\nRSAKeyPublicExponent ::= OCTET STRING (SIZE(8))\nValue assignment : Unspecified.\n2.92.\nSensorApprovalNumber\nType approval number of the sensor.\nSensorApprovalNumber ::= IA5String(SIZE(8))\nValue assignment : Unspecified.\n2.93.\nSensorIdentification\nInformation, stored in a motion sensor, related to the identification of the motion sensor (requirement 077).\nSensorIdentification ::= SEQUENCE {\nsensorSerialNumber SensorSerialNumber,\nsensorApprovalNumber SensorApprovalNumber,\nsensorSCIdentifier SensorSCIdentifier,\nsensorOSIdentifier SensorOSIdentifier\n}\nsensorSerialNumber is the extended serial number of the motion sensor (includes part number and manufacturer code).\nsensorApprovalNumber is the approval number of the motion sensor.\nsensorSCIdentifier is the identifier of the security component of the motion sensor.\nsensorOSIdentifier is the identifier of the operating system of the motion sensor.\n2.94.\nSensorInstallation\nInformation, stored in a motion sensor, related to the installation of the motion sensor (requirement 099).\nSensorInstallation ::= SEQUENCE {\nsensorPairingDateFirst SensorPairingDate,\nfirstVuApprovalNumber VuApprovalNumber,\nfirstVuSerialNumber VuSerialNumber,\nsensorPairingDateCurrent SensorPairingDate,\ncurrentVuApprovalNumber VuApprovalNumber,\ncurrentVUSerialNumber VuSerialNumber\n}\nsensorPairingDateFirst is the date of the first pairing of the motion sensor with a vehicle unit.\nfirstVuApprovalNumber is the approval number of the first vehicle unit paired with the motion sensor.\nfirstVuSerialNumber is the serial number of the first vehicle unit paired with the motion sensor.\nsensorPairingDateCurrent is the date of the current pairing of the motion sensor with the vehicle unit.\ncurrentVuApprovalNumber is the approval number of the vehicle unit currently paired with the motion sensor.\ncurrentVUSerialNumber is the serial number of the vehicle unit currently paired with the motion sensor.\n2.95.\nSensorInstallationSecData\nInformation, stored in a workshop card, related to the security data needed for pairing motion sensors to vehicle units (requirement 214).\nSensorInstallationSecData ::= TDesSessionKey\nValue assignment: in accordance with ISO 16844-3.\n2.96.\nSensorOSIdentifier\nIdentifier of the operating system of the motion sensor.\nSensorOSIdentifier ::= IA5String(SIZE(2))\nValue assignment: manufacturer specific.\n2.97.\nSensorPaired\nInformation, stored in a vehicle unit, related to the identification of the motion sensor paired with the vehicle unit (requirement 079).\nSensorPaired ::= SEQUENCE {\nsensorSerialNumber SensorSerialNumber,\nsensorApprovalNumber SensorApprovalNumber,\nsensorPairingDateFirst SensorPairingDate\n}\nsensorSerialNumber is the serial number of the motion sensor currently paired with the vehicle unit.\nsensorApprovalNumber is the approval number of the motion sensor currently paired with the vehicle unit.\nsensorPairingDateFirst is the date of the first pairing with a vehicle unit of the motion sensor currently paired with the vehicle unit.\n2.98.\nSensorPairingDate\nDate of a pairing of the motion sensor with a vehicle unit.\nSensorPairingDate ::= TimeReal\nValue assignment: Unspecified.\n2.99.\nSensorSerialNumber\nSerial number of the motion sensor.\nSensorSerialNumber ::= ExtendedSerialNumber :\n2.100.\nSensorSCIdentifier\nIdentifier of the security component of the motion sensor.\nSensorSCIdentifier ::= IA5String(SIZE(8))\nValue assignment: component manufacturer specific.\n2.101.\nSignature\nA digital signature.\nSignature ::= OCTET STRING (SIZE(128))\nValue assignment: in accordance with Appendix 11, ‘Common security mechanisms’.\n2.102.\nSimilarEventsNumber\nThe number of similar events for one given day (requirement 094).\nSimilarEventsNumber ::= INTEGER(0..255)\nValue 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.\n2.103.\nSpecificConditionType\nCode identifying a specific condition (requirements 050b, 105a, 212a and 230a).\nSpecificConditionType ::= INTEGER(0..255)\nValue assignment:\n′00′H RFU\n′01′H Out of scope — Begin\n′02′H Out of scope — End\n′03′H Ferry/Train crossing\n′04′H .. ′FF′H RFU.\n2.104.\nSpecificConditionRecord\nInformation, stored in a driver card, a workshop card or a vehicle unit, related to a specific condition (requirements 105a, 212a and 230a).\nSpecificConditionRecord ::= SEQUENCE {\nentryTime TimeReal,\nspecificConditionType SpecificConditionType\n}\nentryTime is the date and time of the entry.\nspecificConditionType is the code identifying the specific condition.\n2.105.\nSpeed\nSpeed of the vehicle (km/h).\nSpeed ::= INTEGER(0..255)\nValue assignment: kilometre per hour in the operational range 0 to 220 km/h.\n2.106.\nSpeedAuthorised\nMaximum authorised Speed of the vehicle (definition bb)).\nSpeedAuthorised ::= Speed .\n2.107.\nSpeedAverage\nAverage speed in a previously defined duration (km/h).\nSpeedAverage ::= Speed .\n2.108.\nSpeedMax\nMaximum speed measured in a previously defined duration.\nSpeedMax ::= Speed .\n2.109.\nTDesSessionKey\nA triple DES session key.\nTDesSessionKey ::= SEQUENCE {\ntDesKeyA OCTET STRING (SIZE(8))\ntDesKeyB OCTET STRING (SIZE(8))\n}\nValue assignment: not further specified.\n2.110.\nTimeReal\nCode 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.\nTimeReal{INTEGER:TimeRealRange} ::= INTEGER(0..TimeRealRange)\nValue assignment — Octet Aligned : Number of seconds since midnight 1 January 1970 GMT.\nThe max possible date/time is in the year 2106.\n2.111.\nTyreSize\nDesignation of tyre dimensions.\nTyreSize ::= IA5String(SIZE(15))\nValue assignment : in accordance with Directive 92/23 (EEC) 31.3.1992, OJ L 129, p. 95 .\n2.112.\nVehicleIdentificationNumber\nVehicle Identification Number (VIN) referring to the vehicle as a whole, normally chassis serial number or frame number.\nVehicleIdentificationNumber ::= IA5String(SIZE(17))\nValue assignment : As defined in ISO 3779.\n2.113.\nVehicleRegistrationIdentification\nIdentification of a vehicle, unique for Europe (VRN and Member State).\nVehicleRegistrationIdentification ::= SEQUENCE {\nvehicleRegistrationNation NationNumeric,\nvehicleRegistrationNumber VehicleRegistrationNumber\n}\nvehicleRegistrationNation is the nation where the vehicle is registered.\nvehicleRegistrationNumber is the registration number of the vehicle (VRN).\n2.114.\nVehicleRegistrationNumber\nRegistration number of the vehicle (VRN). The registration number is assigned by the vehicle licensing authority.\nVehicleRegistrationNumber ::= SEQUENCE {\ncodePage INTEGER (0..255),\nvehicleRegNumber OCTET STRING (SIZE(13))\n}\ncodePage specifies the part of the ISO/IEC 8859 used to code the vehicleRegNumber,\nvehicleRegNumber is a VRN coded in accordance with ISO/IEC 8859-codePage.\nValue assignment: Country specific.\n2.115.\nVuActivityDailyData\nInformation, 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 (requirement 084) and to slots status at 00.00 that day.\nVuActivityDailyData ::= SEQUENCE {\nnoOfActivityChanges INTEGER SIZE(0.. 1 440 ),\nactivityChangeInfos SET SIZE(noOfActivityChanges) OF ActivityChangeInfo\n}\nnoOfActivityChanges is the number of ActivityChangeInfo words in the activityChangeInfos set.\nactivityChangeInfos 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.\n2.116.\nVuApprovalNumber\nType approval number of the vehicle unit.\nVuApprovalNumber ::= IA5String(SIZE(8))\nValue assignment: Unspecified.\n2.117.\nVuCalibrationData\nInformation, stored in a vehicle unit, related to the calibrations of the recording equipment (requirement 098).\nVuCalibrationData ::= SEQUENCE {\nnoOfVuCalibrationRecords INTEGER(0..255),\nvuCalibrationRecords SET SIZE(noOfVuCalibrationRecords) OF VuCalibrationRecord\n}\nnoOfVuCalibrationRecords is the number of records contained in the vuCalibrationRecords set.\nvuCalibrationRecords is the set of calibration records.\n2.118.\nVuCalibrationRecord\nInformation, stored in a vehicle unit, related a calibration of the recording equipment (requirement 098).\nVuCalibrationRecord ::= SEQUENCE {\ncalibrationPurpose CalibrationPurpose,\nworkshopName Name,\nworkshopAddress Address,\nworkshopCardNumber FullCardNumber,\nworkshopCardExpiryDate TimeReal,\nvehicleIdentificationNumber VehicleIdentificationNumber,\nvehicleRegistrationIdentification VehicleRegistrationIdentification,\nwVehicleCharacteristicConstant W-VehicleCharacteristicConstant,\nkConstantOfRecordingEquipment K-ConstantOfRecordingEquipment,\nlTyreCircumference L-TyreCircumference,\ntyreSize TyreSize,\nauthorisedSpeed SpeedAuthorised,\noldOdometerValue OdometerShort,\nnewOdometerValue OdometerShort,\noldTimeValue TimeReal,\nnewTimeValue TimeReal,\nnextCalibrationDate TimeReal\n}\ncalibrationPurpose is the purpose of the calibration.\nworkshopName, workshopAddress are the workshop name and address.\nworkshopCardNumber identifies the workshop card used during the calibration.\nworkshopCardExpiryDate is the card expiry date.\nvehicleIdentificationNumber is the VIN.\nvehicleRegistrationIdentification contains the VRN and registering Member State.\nwVehicleCharacteristicConstant is the characteristic coefficient of the vehicle.\nkConstantOfRecordingEquipment is the constant of the recording equipment.\nlTyreCircumference is the effective circumference of the wheel tyres.\ntyreSize is the designation of the dimension of the tyres mounted on the vehicle.\nauthorisedSpeed is the authorised speed of the vehicle.\noldOdometerValue, newOdometerValue are the old and new values of the odometer.\noldTimeValue, newTimeValue are the old and new values of date and time.\nnextCalibrationDate is the date of the next calibration of the type specified in CalibrationPurpose to be carried out by the authorised inspection authority.\n2.119.\nVuCardIWData\nInformation, stored in a vehicle unit, related to insertion and withdrawal cycles of driver cards or of workshop cards in the vehicle unit (requirement 081).\nVuCardIWData ::= SEQUENCE {\nnoOfIWRecords INTEGER(0..216-1),\nvuCardIWRecords SET SIZE(noOfIWRecords) OF VuCardIWRecord\n}\nnoOfIWRecords is the number of records in the set vuCardIWRecords.\nvuCardIWRecords is a set of records related to card insertion withdrawal cycles.\n2.120.\nVuCardIWRecord\nInformation, 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).\nVuCardIWRecord ::= SEQUENCE {\ncardHolderName HolderName,\nfullCardNumber FullCardNumber,\ncardExpiryDate TimeReal,\ncardInsertionTime TimeReal,\nvehicleOdometerValueAtInsertion OdometerShort,\ncardSlotNumber CardSlotNumber,\ncardWithdrawalTime TimeReal,\nvehicleOdometerValueAtWithdrawal OdometerShort,\npreviousVehicleInfo PreviousVehicleInfo\nmanualInputFlag ManualInputFlag\n}\ncardHolderName is the driver or workshop card holder's surname and first names as stored in the card.\nfullCardNumber is the type of card, its issuing Member State and its card number as stored in the card.\ncardExpiryDate is the card's expiry date as stored in the card.\ncardInsertionTime is the insertion date and time.\nvehicleOdometerValueAtInsertion is the vehicle odometer value at card insertion.\ncardSlotNumber is the slot in which the card is inserted.\ncardWithdrawalTime is the withdrawal date and time.\nvehicleOdometerValueAtWithdrawal is the vehicle odometer value at card withdrawal.\npreviousVehicleInfo contains information about the previous vehicle used by the driver, as stored in the card.\nmanualInputFlag is a flag identifying if the cardholder has manually entered driver activities at card insertion.\n2.121.\nVuCertificate\nCertificate of the public key of a vehicle unit.\nVuCertificate ::= Certificate\n2.122.\nVuCompanyLocksData\nInformation, stored in a vehicle unit, related to company locks (requirement 104).\nVuCompanyLocksData ::= SEQUENCE {\nnoOfLocks INTEGER(0..20),\nvuCompanyLocksRecords SET SIZE(noOfLocks) OF VuCompanyLocksRecord\n}\nnoOfLocks is the number of locks listed in vuCompanyLocksRecords.\nvuCompanyLocksRecords is the set of company locks records.\n2.123.\nVuCompanyLocksRecord\nInformation, stored in a vehicle unit, related to one company lock (requirement 104).\nVuCompanyLocksRecord ::= SEQUENCE {\nlockInTime TimeReal,\nlockOutTime TimeReal,\ncompanyName Name,\ncompanyAddress Address,\ncompanyCardNumber FullCardNumber\n}\nlockInTime, lockOutTime are the date and time of lock-in and lock-out.\ncompanyName, companyAddress are the company name and address related with the lock-in.\ncompanyCardNumber identifies the card used at lock-in.\n2.124.\nVuControlActivityData\nInformation, stored in a vehicle unit, related to controls performed using this VU (requirement 102).\nVuControlActivityData ::= SEQUENCE {\nnoOfControls INTEGER(0..20),\nvuControlActivityRecords SET SIZE(noOfControls) OF VuControlActivityRecord\n}\nnoOfControls is the number of controls listed in vuControlActivityRecords.\nvuControlActivityRecords is the set of control activity records.\n2.125.\nVuControlActivityRecord\nInformation, stored in a vehicle unit, related to a control performed using this VU (requirement 102).\nVuControlActivityRecord ::= SEQUENCE {\ncontrolType ControlType,\ncontrolTime TimeReal,\ncontrolCardNumber FullCardNumber,\ndownloadPeriodBeginTime TimeReal,\ndownloadPeriodEndTime TimeReal\n}\ncontrolType is the type of the control.\ncontrolTime is the date and time of the control.\nControlCardNumber identifies the control card used for the control.\ndownloadPeriodBeginTime is the begin time of the downloaded period, in case of downloading.\ndownloadPeriodEndTime is the end time of the downloaded period, in case of downloading.\n2.126.\nVuDataBlockCounter\nCounter, stored in a card, identifying sequentially the insertion withdrawal cycles of the card in vehicle units.\nVuDataBlockCounter ::= BCDString(SIZE(2))\nValue assignment : Consecutive Number with max, value 9 999 , starting again with 0.\n2.127.\nVuDetailedSpeedBlock\nInformation, stored in a vehicle unit, related to the vehicle's detailed speed for a minute during which the vehicle has been moving (requirement 093).\nVuDetailedSpeedBlock ::= SEQUENCE {\nspeedBlockBeginDate TimeReal,\nspeedsPerSecond SEQUENCE SIZE(60) OF Speed\n}\nspeedBlockBeginDate is the date and time of the first speed value within the block.\nspeedsPerSecond is the chronological sequence of measured speeds every seconds for the minute starting at speedBlockBeginDate (included).\n2.128.\nVuDetailedSpeedData\nInformation, stored in a vehicle unit, related to the detailed speed of the vehicle.\nVuDetailedSpeedData ::= SEQUENCE\nnoOfSpeedBlocks INTEGER(0.2 16 -1),\nvuDetailedSpeedBlocks SET SIZE(noOfSpeedBlocks) OF VuDetailedSpeedBlock\n}\nnoOfSpeedBlocks is the number of speed blocks in the vuDetailedSpeedBlocks set.\nvuDetailedSpeedBlocks is the set of detailed speed blocks.\n2.129.\nVuDownloadablePeriod\nOldest and latest dates for which a vehicle unit holds data related to drivers activities (requirements 081, 084 or 087).\nVuDownloadablePeriod ::= SEQUENCE {\nminDownloadableTime TimeReal\nmaxDownloadableTime TimeReal\n}\nminDownloadableTime is the oldest card insertion or activity change or place entry date and time stored in the VU.\nmaxDownloadableTime is the latest card withdrawal or activity change or place entry date and time stored in the VU.\n2.130.\nVuDownloadActivityData\nInformation, stored in a vehicle unit, related to its last download (requirement 105).\nVuDownloadActivityData ::= SEQUENCE {\ndownloadingTime TimeReal,\nfullCardNumber FullCardNumber,\ncompanyOrWorkshopName Name\n}\ndownloadingTime is the date and time of downloading.\nfullCardNumber identifies the card used to authorise the download.\ncompanyOrWorkshopName is the company or workshop name.\n2.131.\nVuEventData\nInformation, stored in a vehicle unit, related to events (requirement 094 except over speeding event).\nVuEventData ::= SEQUENCE {\nnoOfVuEvents INTEGER(0..255),\nvuEventRecords SET SIZE(noOfVuEvents) OF VuEventRecord\n}\nnoOfVuEvents is the number of events listed in the vuEventRecords set.\nvuEventRecords is a set of events records.\n2.132.\nVuEventRecord\nInformation, stored in a vehicle unit, related to an event (requirement 094 except over speeding event).\nVuEventRecord ::= SEQUENCE {\neventType EventFaultType,\neventRecordPurpose EventFaultRecordPurpose,\neventBeginTime TimeReal,\neventEndTime TimeReal,\ncardNumberDriverSlotBegin FullCardNumber,\ncardNumberCodriverSlotBegin FullCardNumber,\ncardNumberDriverSlotEnd FullCardNumber,\ncardNumberCodriverSlotEnd FullCardNumber,\nsimilarEventsNumber SimilarEventsNumber\n}\neventType is the type of the event.\neventRecordPurpose is the purpose for which this event has been recorded.\neventBeginTime is the date and time of beginning of event.\neventEndTime is the date and time of end of event.\ncardNumberDriverSlotBegin identifies the card inserted in the driver slot at the beginning of the event.\ncardNumberCodriverSlotBegin identifies the card inserted in the co-driver slot at the beginning of the event.\ncardNumberDriverSlotEnd identifies the card inserted in the driver slot at the end of the event.\ncardNumberCodriverSlotEnd identifies the card inserted in the co-driver slot at the end of the event.\nsimilarEventsNumber is the number of similar events that day.\nThis sequence can be used for all events other than over speeding events.\n2.133.\nVuFaultData\nInformation, stored in a vehicle unit, related to faults (requirement 096).\nVuFaultData ::= SEQUENCE {\nnoOfVuFaults INTEGER(0..255),\nvuFaultRecords SET SIZE(noOfVuFaults) OF VuFaultRecord\n}\nnoOfVuFaults is the number of faults listed in the vuFaultRecords set.\nvuFaultRecords is a set of faults records.\n2.134.\nVuFaultRecord\nInformation, stored in a vehicle unit, related to a fault (requirement 096).\nVuFaultRecord ::= SEQUENCE {\nfaultType EventFaultType,\nfaultRecordPurpose EventFaultRecordPurpose,\nfaultBeginTime TimeReal,\nfaultEndTime TimeReal,\ncardNumberDriverSlotBegin FullCardNumber,\ncardNumberCodriverSlotBegin FullCardNumber,\ncardNumberDriverSlotEnd FullCardNumber,\ncardNumberCodriverSlotEnd FullCardNumber\n}\nfaultType is the type of recording equipment fault.\nfaultRecordPurpose is the purpose for which this fault has been recorded.\nfaultBeginTime is the date and time of beginning of fault.\nfaultEndTime is the date and time of end of fault.\ncardNumberDriverSlotBegin identifies the card inserted in the driver slot at the beginning of the fault.\ncardNumberCodriverSlotBegin identifies the card inserted in the co-driver slot at the beginning of the fault.\ncardNumberDriverSlotEnd identifies the card inserted in the driver slot at the end of the fault.\ncardNumberCodriverSlotEnd identifies the card inserted in the co-driver slot at the end of the fault.\n2.135.\nVuIdentification\nInformation, stored in a vehicle unit, related to the identification of the vehicle unit (requirement 075).\nVuIdentification ::= SEQUENCE {\nvuManufacturerName VuManufacturerName,\nvuManufacturerAddress VuManufacturerAddress,\nvuPartNumber VuPartNumber,\nvuSerialNumber VuSerialNumber,\nvuSoftwareIdentification VuSoftwareIdentification,\nvuManufacturingDate VuManufacturingDate,\nvuApprovalNumber VuApprovalNumber\n}\nvuManufacturerName is the name of the manufacturer of the vehicle unit.\nvuManufacturerAddress is the address of the manufacturer of the vehicle unit.\nvuPartNumber is the part number of the vehicle unit.\nvuSerialNumber is the serial number of the vehicle unit.\nvuSoftwareIdentification identifies the software implemented in the vehicle unit.\nvuManufacturingDate is the manufacturing date of the vehicle unit.\nvuApprovalNumber is the type approval number of the vehicle unit.\n2.136.\nVuManufacturerAddress\nAddress of the manufacturer of the vehicle unit.\nVuManufacturerAddress ::= Address\nValue assignment: Unspecified.\n2.137.\nVuManufacturerName\nName of the manufacturer of the vehicle unit.\nVuManufacturerName ::= Name\nValue assignment: Unspecified.\n2.138.\nVuManufacturingDate\nDate of manufacture of the vehicle unit.\nVuManufacturingDate ::= TimeReal\nValue assignment: Unspecified.\n2.139.\nVuOverSpeedingControlData\nInformation, stored in a vehicle unit, related to over speeding events since the last over speeding control (requirement 095).\nVuOverSpeedingControlData ::= SEQUENCE {\nlastOverspeedControlTime TimeReal,\nfirstOverspeedSince TimeReal,\nnumberOfOverspeedSince OverspeedNumber\n}\nlastOverspeedControlTime is the date and time of the last over speeding control.\nfirstOverspeedSince is the date and time of the first over speeding following this over speeding control.\nnumberOfOverspeedSince is the number of over speeding events since the last over speeding control.\n2.140.\nVuOverSpeedingEventData\nInformation, stored in a vehicle unit, related to over speeding events (requirement 094).\nVuOverSpeedingEventData ::= SEQUENCE {\nnoOfVuOverSpeedingEvents INTEGER(0..255),\nvuOverSpeedingEventRecords SET SIZE(noOfVuOverSpeedingEvents) OF VuOverSpeedingEventRecord\n}\nnoOfVuOverSpeedingEvents is the number of events listed in the vuOverSpeedingEventRecords set.\nvuOverSpeedingEventRecords is a set of over speeding events records.\n2.141.\nVuOverSpeedingEventRecord\nInformation, stored in a vehicle unit, related to over speeding events (requirement 094).\nVuOverSpeedingEventRecord ::= SEQUENCE {\neventType EventFaultType,\neventRecordPurpose EventFaultRecordPurpose,\neventBeginTime TimeReal,\neventEndTime TimeReal,\nmaxSpeedValue SpeedMax,\naverageSpeedValue SpeedAverage,\ncardNumberDriverSlotBegin FullCardNumber,\nsimilarEventsNumber SimilarEventsNumber\n}\neventType is the type of the event.\neventRecordPurpose is the purpose for which this event has been recorded.\neventBeginTime is the date and time of beginning of event.\neventEndTime is the date and time of end of event.\nmaxSpeedValue is the maximum speed measured during the event.\naverageSpeedValue is the arithmetic average speed measured during the event.\ncardNumberDriverSlotBegin identifies the card inserted in the driver slot at the beginning of the event.\nsimilarEventsNumber is the number of similar events that day.\n2.142.\nVuPartNumber\nPart number of the vehicle unit.\nVuPartNumber ::= IA5String(SIZE(16))\nValue assignment : VU manufacturer specific.\n2.143.\nVuPlaceDailyWorkPeriodData\nInformation, stored in a vehicle unit, related to places where drivers begin or end a daily work periods (requirement 087).\nVuPlaceDailyWorkPeriodData ::= SEQUENCE {\nnoOfPlaceRecords INTEGER(0..255),\nvuPlaceDailyWorkPeriodRecords SET SIZE(noOfPlaceRecords) OF VuPlaceDailyWorkPeriodRecord\n}\nnoOfPlaceRecords is the number of records listed in the vuPlaceDailyWorkPeriodRecords set.\nvuPlaceDailyWorkPeriodRecords is a set of place related records.\n2.144.\nVuPlaceDailyWorkPeriodRecord\nInformation, stored in a vehicle unit, related to a place where a driver begins or ends a daily work period (requirement 087).\nVuPlaceDailyWorkPeriodRecord ::= SEQUENCE {\nfullCardNumber FullCardNumber,\nplaceRecord PlaceRecord\n}\nfullCardNumber is the driver's card type, card issuing Member State and card number.\nplaceRecord contains the information related to the place entered.\n2.145.\nVuPrivateKey\nThe private key of a vehicle unit.\nVuPrivateKey ::= RSAKeyPrivateExponent\n2.146.\nVuPublicKey\nThe public key of a vehicle unit.\nVuPublicKey ::= PublicKey\n2.147.\nVuSerialNumber\nSerial number of the vehicle unit (requirement 075).\nVuSerialNumber ::= ExtendedSerialNumber\n2.148.\nVuSoftInstallationDate\nDate of installation of the vehicle unit software version.\nVuSoftInstallationDate ::= TimeReal\nValue assignment: Unspecified.\n2.149.\nVuSoftwareIdentification\nInformation, stored in a vehicle unit, related to the software installed.\nVuSoftwareIdentification ::= SEQUENCE {\nvuSoftwareVersion VuSoftwareVersion,\nvuSoftInstallationDate VuSoftInstallationDate\n}\nvuSoftwareVersion is the software version number of the Vehicle Unit.\nvuSoftInstallationDate is the software version installation date.\n2.150.\nVuSoftwareVersion\nSoftware version number of the vehicle unit.\nVuSoftwareVersion ::= IA5String(SIZE(4))\nValue assignment: Unspecified.\n2.151.\nVuSpecificConditionData\nInformation, stored in a vehicle unit, related to specific conditions.\nVuSpecificConditionData ::= SEQUENCE {\nnoOfSpecificConditionRecords INTEGER(0..2 16 -1)\nspecificConditionRecords SET SIZE (noOfSpecificConditionRecords) OF SpecificConditionRecord\n}\nnoOfSpecificConditionRecords is the number of records listed in the specificConditionRecords set.\nspecificConditionRecords is a set of specific conditions related records.\n2.152.\nVuTimeAdjustmentData\nInformation, stored in a vehicle unit, related to time adjustments performed outside the frame of a regular calibration (requirement 101).\nVuTimeAdjustmentData ::= SEQUENCE {\nnoOfVuTimeAdjRecords INTEGER(0..6),\nvuTimeAdjustmentRecords SET SIZE(noOfVuTimeAdjRecords) OF VuTimeAdjustmentRecords\n}\nnoOfVuTimeAdjRecords is the number of records in vuTimeAdjustmentRecords.\nvuTimeAdjustmentRecords is a set of time adjustment records.\n2.153.\nVuTimeAdjustmentRecord\nInformation, stored in a vehicle unit, related to a time adjustment performed outside the frame of a regular calibration (requirement 101).\nVuTimeAdjustmentRecord ::= SEQUENCE {\noldTimeValue TimeReal,\noldTimeValue TimeReal,\nnewTimeValue TimeReal,\nworkshopName Name,\nworkshopAddress Address,\nworkshopCardNumber FullCardNumber\n}\noldTimeValue, newTimeValue are the old and new values of date and time.\nworkshopName, workshopAddress are the workshop name and address.\nworkshopCardNumber identifies the workshop card used to perform the time adjustment.\n2.154.\nW-VehicleCharacteristicConstant\nCharacteristic coefficient of the vehicle (definition k)).\nW-VehicleCharacteristicConstant ::= INTEGER(0..2 16 -1))\nValue assignment: Impulses per kilometre in the operating range 0 to 64 255 pulses/km.\n2.155.\nWorkshopCardApplicationIdentification\nInformation, stored in a workshop card related to the identification of the application of the card (requirement 190).\nWorkshopCardApplicationIdentification ::= SEQUENCE {\ntypeOfTachographCardId EquipmentType,\ncardStructureVersion CardStructureVersion,\nnoOfEventsPerType NoOfEventsPerType,\nnoOfFaultsPerType NoOfFaultsPerType,\nactivityStructureLength CardActivityLengthRange,\nnoOfCardVehicleRecords NoOfCardVehicleRecords,\nnoOfCardPlaceRecords NoOfCardPlaceRecords,\nnoOfCalibrationRecords NoOfCalibrationRecords\n}\ntypeOfTachographCardId is specifying the implemented type of card.\ncardStructureVersion is specifying the the version of the structure that is implemented in the card.\nnoOfEventsPerType is the number of events per type of event the card can record.\nnoOfFaultsPerType is the number of faults per type of fault the card can record.\nactivityStructureLength indicates the number of bytes available for storing activity records.\nnoOfCardVehicleRecords is the number of vehicle records the card can contain.\nnoOfCardPlaceRecords is the number of places the card can record.\nnoOfCalibrationRecords is the number of calibration records the card can store.\n2.156.\nWorkshopCardCalibrationData\nInformation, stored in a workshop card, related to workshop activity performed with the card (requirements 227 and 229).\nWorkshopCardCalibrationData ::= SEQUENCE {\ncalibrationTotalNumber INTEGER(0..2 16 -1),\ncalibrationPointerNewestRecord INTEGER(0..NoOfCalibrationRecords-1),\ncalibrationRecords SET SIZE(NoOfCalibrationRecords) OF WorkshopCardCalibrationRecord\n}\ncalibrationTotalNumber is the total number of calibrations performed with the card.\ncalibrationPointerNewestRecord is the index of the last updated calibration record.\nValue assignment: Number corresponding to the numerator of the calibration record, beginning with ‘0’ for the first occurrence of the calibration records in the structure.\ncalibrationRecords is the set of records containing calibration and/or time adjustment information.\n2.157.\nWorkshopCardCalibrationRecord\nInformation, stored in a workshop card, related to a calibration performed with the card (requirement 227).\nWorkshopCardCalibrationRecord ::= SEQUENCE {\ncalibrationPurpose CalibrationPurpose,\nvehicleIdentificationNumber VehicleIdentificationNumber,\nvehicleRegistration VehicleRegistrationIdentification,\nwVehicleCharacteristicConstant W-VehicleCharacteristicConstant,\nkConstantOfRecordingEquipment K-ConstantOfRecordingEquipment,\nlTyreCircumference L-TyreCircumference,\ntyreSize TyreSize,\nauthorisedSpeed SpeedAuthorised,\noldOdometerValue OdometerShort,\nnewOdometerValue OdometerShort,\noldTimeValue TimeReal,\nnewTimeValue TimeReal,\nnextCalibrationDate TimeReal,\nvuPartNumber VuPartNumber,\nvuSerialNumber VuSerialNumber,\nsensorSerialNumber SensorSerialNumber\n}\ncalibrationPurpose is the purpose of the calibration.\nvehicleIdentificationNumber is the VIN.\nvehicleRegistration contains the VRN and registering Member State.\nwVehicleCharacteristicConstant is the characteristic coefficient of the vehicle.\nkConstantOfRecordingEquipment is the constant of the recording equipment.\nlTyreCircumference is the effective circumference of the wheel tyres.\ntyreSize is the designation of the dimensions of the tyres mounted on the vehicle.\nauthorisedSpeed is the maximum authorised speed of the vehicle.\noldOdometerValue, newOdometerValue are the old and new values of the odometer.\noldTimeValue, newTimeValue are the old and new values of date and time.\nnextCalibrationDate is the date of the next calibration of the type specified in CalibrationPurpose to be carried out by the authorised inspection authority.\nvuPartNumber, vuSerialNumber and sensorSerialNumber are the data elements for recording equipment identification.\n2.158.\nWorkshopCardHolderIdentification\nInformation, stored in a workshop card, related to the identification of the cardholder (requirement 216).\nWorkshopCardHolderIdentification ::= SEQUENCE {\nworkshopName Name,\nworkshopAddress Address,\ncardHolderName HolderName,\ncardHolderPreferredLanguage Language\n}\nworkshopName is name of the workshop of the card holder.\nworkshopAddress is the address of the workshop of the card holder.\ncardHolderName is the name and first name(s) of the holder (e.g. the name of the mechanic).\ncardHolderPreferredLanguage is the preferred language of the card holder.\n2.159.\nWorkshopCardPIN\nPersonal identification number of the Workshop Card (requirement 213).\nWorkshopCardPIN ::= IA5String(SIZE(8))\nValue assignment : The PIN known to the cardholder, right padded with ‘FF’ bytes up to 8 bytes.\n3.\nVALUE AND SIZE RANGE DEFINITIONS\nDefinition of variable values used for definitions in paragraph 2.\nTimeRealRange ::= 2 32 -1\n3.1.\nDefinitions for the Driver Card:\nName of the variable value\nMinimum\nMaximum\nCardActivityLengthRange\n5 544 bytes\n(28 days 93 activity changes per day)\n13 776 bytes\n(28 days 240 activity changes per day)\nNoOfCardPlaceRecords\n84\n112\nNoOfCardVehicleRecords\n84\n200\nNoOfEventsPerType\n6\n12\nNoOfFaultsPerType\n12\n24\n3.2.\nDefinitions for the Workshop Card:\nName of the variable value\nMinimum\nMaximum\nCardActivityLengthRange\n198 bytes\n(1 day 93 activity changes)\n492 bytes\n(1 day 240 activity changes)\nNoOfCardPlaceRecords\n6\n8\nNoOfCardVehicleRecords\n4\n8\nNoOfEventsPerType\n3\n3\nNoOfFaultsPerType\n6\n6\nNoOfCalibrationRecords\n88\n255\n3.3.\nDefinitions for the Control Card:\nName of the variable value\nMinimum\nMaximum\nNoOfControlActivityRecords\n230\n520\n3.4.\nDefinitions for the Company Card:\nName of the variable value\nMinimum\nMaximum\nNoOfCompanyActivityRecords\n230\n520\n4.\nCHARACTER SETS\nIA5Strings use the ASCII characters as defined by ISO/IEC 8824-1. For readability and for easy referencing the value assignment is given below. The ISO/IEC 8824-1 supersedes this informative note in case of discrepancy.\n! \" # $ % & ' ( ) * + , - . / 0 1 2 3 4 5 6 7 8 9 : ; < = > ?\n@ A B C D E F G H I J K L M N O P Q R S T U V W X Y Z [ \\ ] ˆ _\n‵ a b c d e f g h i j k l m n o p q r s t u v w x y z { | } ∼\nOther 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).\n5.\nENCODING\nWhen encoded with ASN.1 encoding rules, all data types defined shall be encoded according to ISO/IEC 8825-2, aligned variant.\nAppendix 2\nTACHOGRAPH CARDS SPECIFICATION\n1.\nINTRODUCTION\n1.1.\nAbbreviations\nFor the purpose of this appendix, the following abbreviations apply:\nAC access conditions\nAID application identifier\nALW always\nAPDU application protocol data unit (structure of a command)\nATR answer to reset\nAUT authenticated\nC6, C7 contacts No 6 and 7 of the card as described in ISO/IEC 7816-2\ncc clock cycles\nCHV card holder verification information\nCLA class byte of an APDU command\nDF dedicated file. A DF can contain other files (EF or DF)\nEF elementary file\nENC encrypted: access is possible only by encoding data\netu elementary time unit\nIC integrated circuit\nICC integrated circuit card\nID identifier\nIFD interface device\nIFS information field size\nIFSC information field size for the card\nIFSD information field size device (for the terminal)\nINS instruction byte of an APDU command\nLc length of the input data for a APDU command\nLe length of the expected data (output data for a command)\nMF master file (root DF)\nP1-P2 parameter bytes\nNAD node address used in T=1 protocol\nNEV never\nPIN personal identification number\nPRO SM protected with secure messaging\nPTS protocol transmission selection\nRFU reserved for future use\nRST reset (of the card)\nSM secure messaging\nSW1-SW2 status bytes\nTS initial ATR character\nVPP programming voltage\nXXh value XX in hexadecimal notation\n|| concatenation symbol 03||04=0304.\n1.2.\nReferences\nThe following references are used in this Appendix:\nEN 726-3\nIdentification cards systems — Telecommunications integrated circuit(s) cards and terminals — Part 3: Application independent card requirements. December 1994.\nISO/IEC 7816-2\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 2: Dimensions and location of the contacts. First edition: 1999.\nISO/IEC 7816-3\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 3: Electronic signals and transmission protocol. Edition 2: 1997.\nISO/IEC 7816-4\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 4: Interindustry commands for interexchange. First edition: 1995 + Amendment 1: 1997.\nISO/IEC 7816-6\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements. First Edition: 1996 + Cor 1: 1998.\nISO/IEC 7816-8\nInformation technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands. First Edition: 1999.\nISO/IEC 9797\nInformation technology — Security techniques — Data integrity mechanism using a cryptographic check function employing a block cipher algorithm. Edition 2: 1994.\n2.\nELECTRICAL AND PHYSICAL CHARACTERISTICS\nAll electronic signals shall be in accordance with ISO/IEC 7816-3 unless specified otherwise.\nThe location and dimensions of the card contacts shall comply with the ISO/IEC 7816-2.\n2.1.\nSupply voltage and current consumption\nThe card shall work according to specifications within the consumption limits specified in ISO/IEC 7816-3.\nThe card shall work with V cc = 3 V (+/− 0,3 V) o V cc = 5 V (+/− 0,5 V).\nVoltage selection shall be performed according to ISO/IEC 7816-3.\n2.2.\nProgramming voltage V pp\nThe 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 V cc in the card but shall not be connected to ground. This voltage should not be interpreted in any case.\n2.3.\nClock generation and frequency\nThe 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 %.\nUnder conditions contained into the card file EF ICC , the external clock can be stopped. The first byte of the EF ICC file body codes the Clockstop mode conditions (see EN 726-3 for further details):\nLow\nHigh\nBit 1\nBit 3\nBit 2\n0\n0\n1\nClockstop allowed, no preferred level\n0\n1\n1\nClockstop allowed, high level preferred\n1\n0\n1\nClockstop allowed, low level preferred\n0\n0\n0\nClockstop not allowed\n0\n1\n0\nClockstop only allowed on high level\n1\n0\n0\nClockstop only allowed on low level\nBits 4 to 8 are not used.\n2.4.\nI/O contact\nThe 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.\n2.5.\nStates of the card\nThe card works in two states while the supply voltage is applied:\noperation state while executing commands or interfacing with Digital Unit,\nidle state at all other times; in this state all data shall be retained by the card.\n3.\nHARDWARE AND COMMUNICATION\n3.1.\nIntroduction\nThis paragraph describes the minimum functionality required by Tachograph cards and VUs to ensure correct operation and interoperability.\nTachograph 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.\n3.2.\nTransmission protocol\nThe Transmission protocol shall be compliant with ISO/IEC 7816-3. In particular, the VU shall recognise waiting time extensions sent by the card.\n3.2.1.\nProtocols\nThe card shall provide both protocol T=0 and protocol T=1.\nT=0 is the default protocol, a PTS command is therefore necessary to change the protocol to T=1.\nDevices shall support direct convention in both protocols: the direct convention is hence mandatory for the card.\nThe Information Field Size Card byte shall be presented at the ATR in character TA3. This value shall be at least ′F0h′ (= 240 bytes).\nThe following restrictions apply to the protocols:\nT=0\nThe interface device shall support an answer on I/O after the rising edge of the signal on RST from 400 cc.\nThe interface device shall be able to read characters separated with 12 etu.\nThe 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.\nThe interface device shall accept a 33 bytes ATR (TS+32)\nIf 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.\nThe interface device shall take into account a NUL character emitted by the card.\nThe interface device shall accept the complementary mode for ACK.\nThe get-response command cannot be used in chaining mode to get a data which length could exceed 255 bytes.\nT=1\nNAD byte: not used (NAD shall be set to ′00′).\nS-block ABORT: not used.\nS-block VPP state error: not used.\nThe total chaining length for a data field will not exceed 255 bytes (to be ensured by the IFD).\nThe 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.\nThe card will not ask for an IFS readjustment.\n3.2.2.\nATR\nThe device checks ATR bytes, according to ISO/IEC 7816-3. No verification shall be done on ATR Historical Characters.\nExample of Basic Biprotocol ATR according to ISO/IEC 7816-3\nCharacter\nValue\nRemarks\nTS\n′3Bh′\nIndicates direct convention\nT0\n′85h′\nTD1 present; 5 historical bytes are presents\nTD1\n′80h′\nTD2 present; T=0 to be used\nTD2\n′11h′\nTA3 present; T=1 to be used\nTA3\n′XXh′ (mind. ′F0h′)\nInformation Field Size Card (IFSC)\nTH1 bis TH5\n′XXh′\nHistorical characters\nTCK\n′XXh′\nCheck character (exclusive OR)\nAfter the Answer To Reset (ATR), the Master File (MF) is implicitly selected and becomes the Current Directory.\n3.2.3.\nPTS\nThe 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.\nAs both T=0 and T=1 protocols are mandatory for the card, the basic PTS for protocol switching is mandatory for the card.\nThe 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).\nHigher baud rates are optional for the card.\nIf 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.\nExamples of basic PTS for protocol selection are the following:\nCharacter\nValue\nRemarks\nPPSS\n′FFh′\nThe initiate character\nPPS0\n′00h′ or ′01h′\nPPS1 to PPS3 are not present; ′00h′ to select T0, ′01h′ to select T1\nPK\n′XXh′\nCheck character: ′XXh′ = ′FFh′ if PPS0 = ′00h′\n′XXh′ = ′FEh′ if PPS0 = ′01h′\n3.3.\nAccess conditions (AC)\nAccess Conditions (AC) for the UPDATE_BINARY and READ_BINARY commands are defined for each Elementary File.\nThe AC of the current file must be met before accessing the file via these commands.\nThe definitions of the available access conditions are the following:\n— ALW: The action is always possible and can be executed without any restriction.\n— NEV: The action is never possible.\n— AUT: The right corresponding a successful external authentication must be opened up (done by the EXTERNAL_AUTHENTICATE command).\n— PRO SM: Command must be transmitted with a cryptographic checksum using secure messaging (See Appendix 11).\n— AUT and PRO SM (combined)\nOn the processing commands (UPDATE_BINARY and READ_BINARY), the following access conditions can be set in the card:\nUPDATE_ BINARY\nREAD_ BINARY\nALW\nYes\nYes\nNEV\nYes\nYes\nAUT\nYes\nYes\nPRO SM\nYes\nNo\nAUT and PRO SM\nYes\nNo\nThe 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 messaging, as described in paragraph 3.6.2.\n3.4.\nData encryption\nWhen 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).\n3.5.\nCommands and error codes overview\nCommands and file organisation are deduced from and complies with ISO/IEC 7816-4.\nThis section describes the following APDU command-response pairs:\nCommand\nINS\nSELECT FILE\nA4\nREAD BINARY\nB0\nUPDATE BINARY\nD6\nGET CHALLENGE\n84\nVERIFY\n20\nGET RESPONSE\nC0\nPERFORM SECURITY OPERATION:\nVERIFY CERTIFICATE\nCOMPUTE DIGITAL SIGNATURE\nVERIFY DIGITAL SIGNATURE\nHASH\n2A\nINTERNAL AUTHENTICATE\n88\nEXTERNAL AUTHENTICATE\n82\nMANAGE SECURITY ENVIRONMENT:\nSETTING A KEY\n22\nPERFORM HASH OF FILE\n2A\nThe status word SW1 SW2 are returned in any response message and denote the processing state of the command.\nSW1\nSW2\nMeaning\n90\n00\nNormal processing\n61\nXX\nNormal processing. XX = number of response bytes available\n62\n81\nWarning processing. Part of returned data may be corrupted\n63\nCX\nWrong CHV (PIN). Remaining attempts counter provided by ′X′\n64\n00\nExecution error — State of non-volatile memory unchanged. Integrity error\n65\n00\nExecution error — State of non-volatile memory changed\n65\n81\nExecution error — State of non-volatile memory changed — Memory failure\n66\n88\nSecurity error: wrong Cryptographic checksum (during secure messaging) or\nwrong certificate (during certificate verification) or\nwrong cryptogram (during external authentication) or\nwrong signature (during signature verification)\n67\n00\nWrong length (wrong Lc or Le)\n69\n00\nForbidden command (no response available in T=0)\n69\n82\nSecurity status not satisfied\n69\n83\nAuthentication method blocked\n69\n85\nConditions of use not satisfied\n69\n86\nCommand not allowed (no current EF)\n69\n87\nExpected secure messaging data objects missing\n69\n88\nIncorrect secure messaging data objects\n6A\n82\nFile not found\n6A\n86\nWrong parameters P1-P2\n6A\n88\nReferenced data not found\n6B\n00\nWrong parameters (offset outside the EF)\n6C\nXX\nWrong length, SW2 indicates the exact length. No data field is returned\n6D\n00\nInstruction code not supported or invalid\n6E\n00\nClass not supported\n6F\n00\nOther checking errors\n3.6.\nCommands description\nThe mandatory commands for the Tachograph cards are described in this chapter.\nAdditional relevant details, related to cryptographic operations involved, are given in Appendix 11 Common security mechanisms.\nAll 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.\nIf 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.\nIf both length bytes are requested, and Le=0 (secure messaging):\nWhen using protocol T=1, the card shall answer to Le=0 by sending all available output data.\nWhen 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.\n3.6.1.\nSelect file\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe SELECT FILE command is used:\nto select an application DF (selection by name must be used)\nto select an elementary file corresponding to the submitted file ID\n3.6.1.1.\nSelection by name (AID)\nThis command allows to select an application DF in the card.\nThis command can be performed from anywhere in the file structure (after the ATR or at anytime).\nThe 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.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nINS\n1\n′A4h′\nP1\n1\n′04h′\nSelection by name (AID)\nP2\n1\n′0Ch′\nNo response expected\nLc\n1\n′NNh′\nNumber of bytes sent to the card (length of the AID): ′06h′ for the Tachograph application\n#6-#(5+NN)\nNN\n′XX..XXh′\nAID: ′FF 54 41 43 48 4F′ for the Tachograph application\nNo response to the SELECT FILE command is needed (Le absent in T=1, or no response asked in T=0).\nResponse Message (no response asked)\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the application corresponding with the AID is not found, the processing state returned is ′6A82′,\nin T=1, if the byte Le is present, the state returned is ′6700′,\nin T=0, if a response is asked after the SELECT FILE command, the state returned is ′6900′,\nif the selected application is considered corrupted (integrity error is detected within the file attributes), the processing state returned is ′6400′ or ′6581′.\n3.6.1.2.\nSelection of an elementary file using its file identifier\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nINS\n1\n′A4h′\nP1\n1\n′02h′\nSelection of an EF under the current DF\nP2\n1\n′0Ch′\nNo response expected\nLc\n1\n′02h′\nNumber of bytes sent to the card\n#6-#7\n2\n′XXXXh′\nFile Identifier\nNo response to the SELECT FILE command is needed (Le absent in T=1, or no response asked in T=0).\nResponse Message (no response asked)\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the file corresponding with the file identifier is not found, the processing state returned is ′6A82′,\nin T=1, if the byte Le is present, the state returned is ′6700′,\nin T=0, if a response is asked after the SELECT FILE command, the state returned is ′6900′,\nif the selected file is considered corrupted (integrity error is detected within the file attributes), the processing state returned is ′6400′ or ′6581′.\n3.6.2.\nRead Binary\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe Read Binary command is used to read data from a transparent file.\nThe response of the card consists of returning the data read, optionally encapsulated in a secure messaging structure.\nThe command can be performed only if the security status satisfies the security attributes defined for the EF for the READ function.\n3.6.2.1.\nCommand without secure messaging\nThis command enables the IFD to read data from the EF currently selected, without secure messaging.\nReading data from a file marked as ‘ Encrypted ’ shall not be possible through this command.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nNo secure messaging asked\nINS\n1\n′B0h′\nP1\n1\n′XXh′\nOffset in bytes from the beginning of the file: most significant byte\nP2\n1\n′XXh′\nOffset in bytes from the beginning of the file: least significant byte\nLe\n1\n′XXh′\nLength of data expected. number of bytes to be read\nNote: bit 8 of P1 must be set to 0.\nResponse Message\nByte\nLength\nValue\nDescription\n#1-#X\nX\n′XX..XXh′\nData read\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no EF is selected, the processing state returned is ′6986′,\nif the Access Control of the selected file are not satisfied, the command is interrupted with ′6982′,\nif the Offset is not compatible with the size of the EF (Offset > EF size), the processing state returned is ′6B00′,\nif 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,\nif 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′,\nif an integrity error is detected within the stored data, the card shall return the demanded data, and the processing state returned is ′6281′.\n3.6.2.2.\nCommand with secure messaging\nThis 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 ’ .\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′0Ch′\nSecure Messaging asked\nINS\n1\n′B0h′\nINS\nP1\n1\n′XXh′\nP1 (offset in bytes from the beginning of the file): Most Significant Byte\nP2\n1\n′XXh′\nP2 (offset in bytes from the beginning of the file): Least Significant Byte\nLc\n1\n′09h′\nLength of input data for secure messaging\n#6\n1\n′97h′\nT LE : Tag for expected length specification\n#7\n1\n′01h′\nL LE : Length of expected length\n#8\n1\n′NNh′\nExpected length specification (original Le): Number of Bytes to be read\n#9\n1\n′8Eh′\nT CC : Tag for cryptographic checksum\n#10\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#11-#14\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nLe\n1\n′00h′\nAs specified in ISO/IEC 7816-4\nResponse Message if EF is not marked as ‘ Encrypted ’ and if Secure Messaging input format is correct:\nByte\nLength\nValue\nDescription\n#1\n1\n′81h′\nT PV : Tag for plain value data\n#2\nL\n′NNh′ or ′81 NNh′\nL PV : length of returned data (= original Le)\nL is 2 bytes if L PV >127 bytes\n#(2+L)-#(1+L+NN)\nNN\n′XX..XXh′\nPlain Data value\n#(2+L+NN)\n1\n′8Eh′\nT CC : Tag for cryptographic checksum\n#(3+L+NN)\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#(4+L+NN)-#(7+L+NN)\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nResponse Message if EF is marked as ‘ Encrypted ’ and if Secure Messaging input format is correct:\nByte\nLength\nValue\nDescription\n#1\n1\n′87h′\nT PI CG : Tag for encrypted data (cryptogram)\n#2\nL\n′MMh′ or ′81 MMh′\nL PI CG : length of returned encrypted data (different of original Le of the command due to padding)\nL is 2 byte if L PI CG > 127 bytes\n#(2+L)-#(1+L+MM)\nMM\n′01XX..XXh′\nEncrypted data: padding indicator and cryptogram\n#(2+L+MM)\n1\n′8Eh′\nT CC : tag for cryptographic checksum\n#(3+L+MM)\n1\n′04h′\nL CC : length of following cryptographic checksum\n#(4+L+MM)-#(7+L+MM)\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nThe 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).\nThe ‘ 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).\nAdditionally, some errors specifically related to secure messaging can happen. In that case, the processing state is simply returned, with no secure messaging structure involved:\nResponse Message if incorrect Secure Messaging input format\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf 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).\nIf some expected data objects (as specified above) are missing in the secure messaging format, the processing state ′6987′ is returned: this error happens if an expected tag is missing or if the command body is not properly constructed.\nIf 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.\nIf the verification of the cryptographic checksum fails, the processing state returned is ′6688′.\n3.6.3.\nUpdate Binary\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe 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.\nThe 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).\n3.6.3.1.\nCommand without secure messaging\nThis 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 ’ .\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nNo secure messaging asked\nINS\n1\n′D6h′\nP1\n1\n′XXh′\nOffset in bytes from the beginning of the file: most significant byte\nP2\n1\n′XXh′\nOffset in bytes from the beginning of the file: least significant byte\nLc\n1\n′NNh′\nLc length of data to Update. Number of bytes to be written\n#6-#(5+NN)\nNN\n′XX..XXh′\nData to be written\nNote: bit 8 of P1 must be set to 0.\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no EF is selected, the processing state returned is ′6986′,\nif the Access Control of the selected file are not satisfied, the command is interrupted with ′6982′,\nif the Offset is not compatible with the size of the EF (Offset > EF size), the processing state returned is ′6B00′,\nif 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′,\nif 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′,\nif writing is unsuccessful, the processing state returned is ′6581′.\n3.6.3.2.\nCommand with secure messaging\nThis 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.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′0Ch′\nSecure messaging. Asked\nINS\n1\n′D6h′\nINS\nP1\n1\n′XXh′\nOffset in bytes from the beginning of the file: most significant byte\nP2\n1\n′XXh′\nOffset in bytes from the beginning of the file: least significant byte\nLc\n1\n′XXh′\nLength of the secured data field\n#6\n1\n′81h′\nT PV : tag for plain value data\n#7\nL\n′NNh′ or ′81 NNh′\nL PV : length of transmitted data\nL is 2 bytes if L PV > 127 bytes\n#(7+L)-#(6+L+NN)\nNN\n′XX..XXh′\nPlain data value (data to be written)\n#(7+L+NN)\n1\n′8Eh′\nT CC : tag for cryptographic checksum\n#(8+L+NN)\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#(9+L+NN)-#(12+L+NN)\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nLe\n1\n′00h′\nAs specified in ISO/IEC 7816-4\nResponse message if correct Secure Messaging input format\nByte\nLength\nValue\nDescription\n#1\n1\n′99h′\nT SW : tag for status words (to be protected by CC)\n#2\n1\n′02h′\nL SW : length of returned status words\n#3-#4\n2\n′XXXXh′\nStatus words (SW1, SW2)\n#5\n1\n′8Eh′\nT CC : tag for cryptographic checksum\n#6\n1\n′04h′\nL CC : Length of following cryptographic checksum\n#7-#10\n4\n′XX..XXh′\nCryptographic checksum (4 most significant bytes)\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nThe ‘ 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.\nAdditionally, some errors specifically related to secure messaging can happen. In that case, the processing state is simply returned, with no secure messaging structure involved:\nResponse Message if error in secure messaging\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus Words (SW1, SW2)\nIf no current session key is available, the processing state ′6A88′ is returned,\nif some expected data objects (as specified above) are missing in the secure messaging format, the processing state ′6987′ is returned: this error happens if an expected tag is missing or if the command body is not properly constructed,\nif 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,\nif the verification of the cryptographic checksum fails, the processing state returned is ′6688′.\n3.6.4.\nGet challenge\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe 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.\nThe Challenge issued by the card is only valid for the next command, which uses a challenge, sent to the card.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′84h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2\nLe\n1\n′08h′\nLe (Length of challenge expected)\nResponse Message\nByte\nLength\nValue\nDescription\n#1-#8\n8\n′XX..XXh′\nChallenge\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif Le is different from ′08h′, the processing state is ′6700′,\nif parameters P1-P2 are incorrect, the processing state is ′6A86′.\n3.6.5.\nVerify\nThis command is compliant with ISO/IEC 7816-4, but has a restricted usage compared to the command defined in the norm.\nThe 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.\nNote: The PIN entered by the user must be right padded with FFh' bytes up to a length of 8 bytes by the IFD.\nIf the command is successful, the rights corresponding to CHV presentation are opened and the remaining CHV attempt counter is reinitialised.\nAn unsuccessful comparison is recorded in the card in order to limit the number of further attempts of the use of the reference CHV.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′20h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2 (the verified CHV is implicitly known)\nLc\n1\n′08h′\nLength of CHV code transmitted\n#6-#13\n8\n′XX..XXh′\nCHV\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the reference CHV is not found, the processing state returned is ′6A88′,\nif 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,\nif 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′),\nif the reference CHV is considered corrupted, the processing state returned is ′6400′ or ′6581′.\n3.6.6.\nGet response\nThis command is compliant with ISO/IEC 7816-4.\nThis 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).\nThe 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.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nINS\n1\n′C0h′\nP1\n1\n′00h′\nP2\n1\n′00h′\nLe\n1\n′XXh′\nNumber of bytes expected\nResponse Message\nByte\nLength\nValue\nDescription\n#1-#X\nX\n′XX..XXh′\nData\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′.\nIf no data have been prepared by the card, the processing state returned is ′6900′ or ′6F00′.\nIf 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.\nIf 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.\nIf the command is not supported (protocol T=1), the card returns ′6D00′.\n3.6.7.\nPSO: verify certificate\nThis command is compliant with ISO/IEC 7816-8, but has a restricted usage compared to the command defined in the norm.\nThe VERIFY CERTIFICATE command is used by the card to obtain a Public Key from the outside and to check its validity.\nWhen 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.\nIn 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.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform Security Operation\nP1\n1\n′00h′\nP1\nP2\n1\n′AEh′\nP2: non BER-TLV coded data (concatenation of data elements)\nLc\n1\n′CEh′\nLc: Length of the certificate, 194 bytes\n#6-#199\n194\n′XX..XXh′\nCertificate: concatenation of data elements (as described in Appendix 11)\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the certificate verification fails, the processing state returned is ′6688′. The verification and unwrapping process of the certificate is described in Appendix 11,\nif no Public Key is present in the Security Environment, ′6A88′ is returned,\nif the selected public key (used to unwrap the certificate) is considered corrupted, the processing state returned is ′6400′ or ′6581′,\nif the selected public key (used to unwrap the certificate) has a CHA.LSB ( CertificateHolderAuthorisation.equipmentType ) different from ′00′ (i.e. is not the one of a Member State or of Europe), the processing state returned is ′6985′.\n3.6.8.\nInternal authenticate\nThis command is compliant with ISO/IEC 7816-4.\nUsing the INTERNAL AUTHENTICATE command, the IFD can authenticate the card.\nThe authentication process is described in Appendix 11. It includes the following statements:\nThe INTERNAL AUTHENTICATE command uses the card Private Key (implicitly 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).\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′88h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2\nLc\n1\n′10h′\nLength of data sent to the card\n#6-#13\n8\n′XX..XXh′\nChallenge used to authenticate the card\n#14-#21\n8\n′XX..XXh′\nVU.CHR (see Appendix 11)\nLe\n1\n′80h′\nLength of the data expected from the card\nResponse Message\nByte\nLength\nValue\nDescription\n#1-#128\n128\n′XX..XXh′\nCard authentication token (see Appendix 11)\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no Public Key is present in the Security Environment, the processing state returned is ′6A88′,\nif no Private Key is present in the Security Environment, the processing state returned is ′6A88′,\nif VU.CHR does not match the current public key identifier, the processing state returned is ′6A88′,\nif the selected private key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\nIf 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.\n3.6.9.\nExternal authenticate\nThis command is compliant with ISO/IEC 7816-4.\nUsing the EXTERNAL AUTHENTICATE command, the card can authenticate the IFD.\nThe authentication process is described in Appendix 11. It includes the following statements:\nA GET CHALLENGE command must precede the EXTERNAL_AUTHENTICATE command immediately. The card issues a challenge to the outside (RND3).\nThe 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.\nThe card verifies the cryptogram, and if it is correct, the AUT access condition is opened.\nThe input cryptogram is carries the second element for session key agreement K2.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′82h′\nINS\nP1\n1\n′00h′\nP1\nP2\n1\n′00h′\nP2 (the public key to be used is implicitly known, and has been previously set by the MSE command)\nLc\n1\n′80h′\nLc (Length of the data sent to the card)\n#6-#133\n128\n′XX..XXh′\nCryptogram (see Appendix 11)\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (status words (SW1, SW2))\nIf the command is successful, the card returns ′9000′,\nif no Public Key is present in the Security Environment, ′6A88′ is returned,\nif 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),\nif no Private Key is present in the Security Environment, the processing state returned is ′6A88′,\nif the verification of the cryptogram is wrong, the processing state returned is ′6688′,\nif the command is not immediately preceded with a GET CHALLENGE command, the processing state returned is ′6985′,\nif the selected private key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\nIf the EXTERNAL AUTHENTICATE command is successful, and if the first part of the session key is available from a successful INTERNAL AUTHENTICATE recently performed, the session key is set for future commands using secure messaging.\nIf 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 authentication process is done in the order specified in Appendix 11.\n3.6.10.\nManage security environment\nThis command is used to set a public key for authentication purpose.\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nThe key referenced in the MSE data field is valid for every file of the Tachograph DF.\nThe key referenced in the MSE data field remains the current public key until the next correct MSE command.\nIf the key referenced is not (already) present into the card, the security environment remains unchanged.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′22h′\nINS\nP1\n1\n′C1h′\nP1: referenced key valid for all cryptographic operations\nP2\n1\n′B6h′\nP2 (referenced data concerning digital signature)\nLc\n1\n′0Ah′\nLc: length of subsequent data field\n#6\n1\n′83h′\nTag for referencing a public key in asymmetric cases\n#7\n1\n′08h′\nLength of the key reference (key identifier)\n#8-#15\n08h\n′XX..XXh′\nKey identifier as specified in Appendix 11\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the referenced key is not present into the card, the processing state returned is ′6A88′,\nif 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,\nif some data objects are incorrect, the processing state returned is ′6988′. This can happen if the length of the key identifier is not ′08h′,\nif the selected key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\n3.6.11.\nPSO: hash\nThis 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.\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′90h′\nReturn hash code\nP2\n1\n′A0h′\nTag: data field contains DOs relevant for hashing\nLc\n1\n′16h′\nLength Lc of the subsequent data field\n#6\n1\n′90h′\nTag for the hash code\n#7\n1\n′14h′\nLength of the hash code\n#8-#27\n20\n′XX..XXh′\nHash code\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif some expected data objects (as specified above) are missing, the processing state ′6987′ is returned. This can happen if one of the tag ′90h′ is missing,\nif 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′.\n3.6.12.\nPerform hash of file\nThis 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.\nThe perform hash file command is used to hash the data area of the currently selected transparent EF.\nThe 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_SIGNATURE command. This result remains available for the COMPUTE DIGITAL SIGNATURE command until the next successful PERFORM HASH of FILE command.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′80h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′90h′\nTag: hash\nP2\n1\n′00h′\nP2: hash the data of the currently selected transparent file\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif no application is selected, the processing state ′6985′ is returned,\nif the selected EF is considered corrupted (file attributes or stored data integrity errors), the processing state returned is ′6400′ or ′6581′,\nif the selected file is not a transparent file, the processing state returned is ′6986′.\n3.6.13.\nPSO: compute digital signature\nThis command is used to compute the digital signature of previously computed hash code (see PERFORM HASH of FILE, point 3.6.12).\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nThe card private key is used to compute the digital signature and is implicitly known by the card.\nThe card performs a digital signature using a padding method compliant with PKCS1 (see Appendix 11 for details).\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′9Eh′\nDigital signature to be returned\nP2\n1\n′9Ah′\nTag: 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)\nLe\n1\n′80h′\nLength of the expected signature\nResponse Message\nByte\nLength\nValue\nDescription\n#1-#128\n128\n′XX..XXh′\nSignature of the previously computed hash\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the implicitly selected private key is considered as corrupted, the processing state returned is ′6400′ or ′6581′.\n3.6.14.\nPSO: verify digital signature\nThis 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.\nThis command is compliant with ISO/IEC 7816-8. The use of this command is restricted regarding the related standard.\nThe 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.\nCommand Message\nByte\nLength\nValue\nDescription\nCLA\n1\n′00h′\nCLA\nINS\n1\n′2Ah′\nPerform security operation\nP1\n1\n′00h′\nP2\n1\n′A8h′\nTag: data field contains DOs relevant for verification\nLc\n1\n′83h′\nLength Lc of the subsequent data field\n#28\n1\n′9Eh′\nTag for digital signature\n#29-#30\n2\n′8180h′\nLength of digital signature (128 bytes, coded in accordance with ISO/IEC 7816-6)\n#31-#158\n128\n′XX..XXh′\nDigital signature content\nResponse Message\nByte\nLength\nValue\nDescription\nSW\n2\n′XXXXh′\nStatus words (SW1, SW2)\nIf the command is successful, the card returns ′9000′,\nif the verification of the signature fails, the processing state returned is ′6688′. The verification process is described in Appendix 11,\nif no public key is selected, the processing state returned is ′6A88′,\nif some expected data objects (as specified above) are missing, the processing state ′6987′ is returned. This can happen if one of the required tag is missing,\nif no hash code is available to process the command (as a result of a previous PSO: hash command), the processing state returned is ′6985′,\nif some data objects are incorrect, the processing state returned is ′6988′. This can happen if one of the required data objects length is incorrect,\nif the selected public key is considered corrupted, the processing state returned is ′6400′ or ′6581′.\n4.\nTACHOGRAPH CARDS STRUCTURE\nThis paragraph specifies the file structures of the Tachograph cards for storage of accessible data,\nIt 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 .\nThe 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 structure is increased. This paragraph specifies minimum and maximum values of these record numbers.\n4.1.\nDriver card structure\nAfter its personalisation, the driver card shall have the following permanent file structure and file access conditions:\nAll EFs structures shall be transparent.\nRead with secure messaging shall be possible for all files under the DF Tachograph.\nThe driver card shall have the following data structure:\nThe 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:\nMin\nMax\nn 1\nNoOfEventsPerType\n6\n12\nn 2\nNoOfFaultsPerType\n12\n24\nn 3\nNoOfCardVehicleRecords\n84\n200\nn 4\nNoOfCardPlaceRecords\n84\n112\nn 6\nCardActivityLengthRange\n5 544 bytes\n(28 days * 93 activity changes)\n13 776 bytes\n(28 days * 240 activity changes)\n4.2.\nWorkshop card structure\nAfter its personalisation, the workshop card shall have the following permanent file structure and file access conditions:\nAll EFs structures shall be transparent.\nRead with secure messaging shall be possible for all files under the DF Tachograph.\nThe workshop card shall have the following data structure:\nThe 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:\nMin\nMax\nn 1\nNoOfEventsPerType\n3\n3\nn 2\nNoOfFaultsPerType\n6\n6\nn 3\nNoOfCardVehicleRecords\n4\n8\nn 4\nNoOfCardPlaceRecords\n6\n8\nn 5\nNoOfCalibrationRecords\n88\n255\nn 6\nCardActivityLengthRange\n198 bytes\n(1 day * 93 activity changes)\n492 bytes\n(1 day * 240 activity changes)\n4.3.\nControl card structure\nAfter its personalisation, the control card shall have the following permanent file structure and file access conditions:\nAll EFs structures shall be transparent.\nRead with secure messaging shall be possible for files under the DF Tachograph.\nThe control card shall have the following data structure:\nThe 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:\nMin\nMax\nn 7\nNoOfControlActivityRecords\n230\n520\n4.4.\nCompany card structure\nAfter its personalisation, the company card shall have the following permanent file structure and file access conditions:\nAll EFs structures shall be transparent.\nRead with secure messaging shall be possible for all files under the DF Tachograph.\nThe company card shall have the following data structure:\nThe 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:\nMin\nMax\nn 8\nNoOfCompanyActivityRecords\n230\n520\nAppendix 3\nPICTOGRAMS\nThe recording equipment may use the following pictograms and pictograms combinations:\n1.. BASIC PICTOGRAMS\nPeople\nActions\nModes of operation\nCompany\nCompany mode\nController\nControl\nControl mode\nDriver\nDriver\nOperational mode\nWorkshop/test station\nInspection/calibration\nCalibration mode\nManufacturer\nActivities\nDuration\nAvailable\nCurrent availability period\nDriving\nContinuous driving time\nRest\nCurrent rest period\nWork\nCurrent work period\nBreak\nCumulative break time\nUnknown\nEquipment\nFunctions\nDriver slot\nCo-driver slot\nCard\nClock\nDisplay\nDisplaying\nExternal storage\nDownloading\nPower supply\nPrinter/printout\nPrinting\nSensor\nTyre size\nVehicle/vehicle unit\nSpecific conditions\nOut of scope\nFerry/train crossing\nMiscellaneous\nEvents\nFaults\nStart of daily work period\nEnd of daily work period\nLocation\nManual entry of driver activities\nSecurity\nSpeed\nTime\nTotal/summary\nQualifiers\nDaily\nWeekly\nTwo weeks\nFrom or to\n2.. PICTOGRAM COMBINATIONS\nMiscellaneous\nControl place\nLocation start of daily work period\nLocation end of daily work period\nFrom time\nTo time\nFrom vehicle\nOut of scope begin\nOut of scope end\nCards\nDriver card\nCompany card\nControl card\nWorkshop card\n- - -\nNo card\nDriving\nCrew driving\nDriving time for one week\nDriving time for two weeks\nPrintouts\nDriver activities from card daily printout\nDriver activities from VU daily printout\nEvents and faults from card printout\nEvents and faults from VU printout\nTechnical data printout\nOver speeding printout\nEvents\nInsertion of a non valid card\nCard conflict\nTime overlap\nDriving without an appropriate card\nCard insertion while driving\nLast card session not correctly closed\nOver speeding\nPower supply interruption\nMotion data error\nSecurity breach\nTime adjustment (by workshop)\nOver speeding control\nFaults\nCard fault (driver slot)\nCard fault (co-driver slot)\nDisplay fault\nDownloading fault\nPrinter fault\nSensor fault\nVU internal fault\nManual entries procedure\nStill same daily work period?\nEnd of previous work period?\nConfirm or enter location of end of work period\nEnter start time\nEnter location of start of work period.\nNote: Additional pictogram combinations to form printout block or record identifiers are defined in Appendix 4.\nAppendix 4\nPRINTOUTS\n1.\nGENERALITIES\nEach printout is built up by chaining various data blocks, possibly identified with a block identifier.\nA data block contains one or more records, possibly identified with a record identifier.\nWhen a block identifier immediately precedes a record identifier, the record identifier is not printed.\nIn the case where a data item is unknown, or must not be printed for data access rights reasons, spaces are printed instead.\nIf the content of a complete line is unknown, or need not to be printed, then the complete line is omitted.\nNumerical data fields are printed right aligned, with a space separator for thousands and millions, and without leading zeros.\nString 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).\n2.\nDATA BLOCKS SPECIFICATION\nIn this chapter the following format notation conventions have been used:\ncharacters printed in bold denote plain text to be printed (printing remains in normal characters),\nnormal characters denote variables (pictograms or data) to be replaced by their values for printing,\nvariable names have been padded with underscores to show the data item length available for the variable,\ndates are specified with a ‘ dd/mm/yyyy ’ (day, month, year) format. A ‘ dd.mm.yyyy ’ format may also be used,\nthe 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:\nPrintouts shall use the following data blocks and/or data records, in accordance with the following meanings and formats:\nBlock or record number Meaning\n1.\nDate and time at which the document is printed\n2.\nType of printout\nBlock identifier\nPrintout pictogram combination (see App. 3), Speed limiting device setting (Over speeding printout only).\n3.\nCard holder identification\nBlock identifier. P = people pictogram\nCard holder surname\nCard holder first name(s) (if any)\nCard identification\nCard expiry date (if any)\nIn 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.\n4.\nVehicle identification\nBlock identifier\n(VIN)\nRegistering Member State and VRN.\n5.\nVU identification\nBlock identifier\nVU manufacturer's name\nVU part number.\n6.\nLast calibration of the recording equipment\nBlock identifier\nWorkshop name\nWorkshop card identification\nDate of the calibration.\n7.\nLast control (by a control officer)\nBlock identifier\nController's card identification\nControl date, time and type\nType of the control: Up to four pictograms. The type of control can be (a combination) of:\n: Card downloading, : VU downloading, : printing, : Displaying.\n8.\nDriver activities stored on a card in order of occurrence\nBlock identifier\nEnquiry date (calendar day subject of the printout) + Daily card presence counter.\n8.1.\nPeriod during which the card was not inserted\n8.1a.\nRecord identifier (start of period)\n8.1b.\nUnknown period . Start and end time, duration\n8.1c.\nActivity manually entered\nActivity pictogram, start and end time (included), duration, rest periods of at least one hour are tagged with a star.\n8.2.\nCard insertion in slot S\nRecord identifier; S = Slot pictogram\nVehicle registering Member State and VRN\nVehicle odometer at card insertion.\n8.3.\nActivity (while card was inserted)\nActivity 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.\n8.3a.\nSpecific condition . Time of entry, specific condition pictogram (or pictogram combination).\n8.4.\nCard withdrawal\nVehicle odometer and distance travelled since last insertion for which odometer is known.\n9.\nDriver activities stored in a VU per slot in chronological order\nBlock identifier\nEnquiry date (calendar day subject of the printout)\nVehicle odometer at 00:00 and 24:00.\n10.\nActivities carried in slot S\nBlock identifier.\n10.1.\nPeriod where no card is inserted in slot S\nRecord identifier\nNo Card inserted\nVehicle odometer at beginning of period.\n10.2.\nCard insertion\nCard insertion record identifier\nDriver's name\nDriver's first name\nDriver's Card identification\nDriver's card expiry date\nRegistering MS and VRN of previous vehicle used\nDate and time of card withdrawal from previous vehicle\nBlank line\nVehicle odometer at card insertion, manual entry of driver activities flag (M if yes, blank if No).\n10.3.\nActivity\nActivity 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.\n10.3a.\nSpecific condition . Time of entry, specific condition pictogram (or pictogram combination).\n10.4.\nCard withdrawal or End of ‘ No Card ’ period\nVehicle odometer at card withdrawal or at end of ‘ no card ’ period and distance travelled since insertion, or since beginning of the ‘ No Card ’ period.\n11.\nDaily summary\nBlock identifier.\n11.1.\nVU summary of periods without card in driver slot\nBlock identifier.\n11.2.\nVU summary of periods without card in co-driver slot\nBlock identifier.\n11.3.\nVU daily summary per driver\nRecord identifier\nDriver's surname\nDriver's first name(s)\nDriver's card identification.\n11.4.\nEntry of place where a daily work period begins and/or ends\npi = location begin/end pictogram, time, country, region,\nOdometer.\n11.5.\nActivity totals (from a card)\nTotal driving duration, distance travelled\nTotal working and availability duration\nTotal resting and unknown duration\nTotal duration of crew activities.\n11.6.\nActivity totals (periods without card driver slot)\nTotal driving duration, distance travelled\nTotal working and availability duration\nTotal resting duration.\n11.7.\nActivity totals (periods without card co-driver slot)\nTotal working and availability duration\nTotal resting duration.\n11.8.\nActivity totals (per driver both slots included)\nTotal driving duration, distance travelled\nTotal driving duration, distance travelled\nTotal resting duration\nTotal duration of crew activities\nWhen a daily printout is required for the current day, daily summary information is computed with available data at the time of the printout.\n12.\nEvents and/or faults stored on a card\n12.1.\nBlock identifier last 5 ‘ Events and Faults ’ from a card\n12.2.\nBlock identifier all recorded ‘ Events ’ on a card\n12.3.\nBlock identifier all recorded ‘ Faults ’ on a card\n12.4.\nEvent and/or Fault record\nRecord identifier\nEvent/fault pictogram, record purpose, date time of start,\nAdditional event/fault code (if any), duration\nRegistering Member State & VRN of vehicle in which the event or fault occurred.\n13.\nEvents and/or faults stored or on-going in a VU\n13.1.\nBlock identifier last 5 ‘ Events and Faults ’ from VU\n13.2.\nBlock identifier all recorded or on-going ‘ Events ’ in a VU\n13.3.\nBlock identifier all recorded or on-going ‘ Faults ’ in a VU\n13.4.\nEvent and/or fault record\nRecord identifier\nEvent/fault pictogram, record purpose, date time of start,\nAdditional event/fault code (if any), No of similar events this day, duration\nIdentification of the cards inserted at start or end of the event or fault (up to 4 lines without repeating twice the same card numbers)\nCase where no card was inserted\nThe record purpose (p) is a numerical code explaining why the event or fault was recorded, coded in accordance with the data element EventFaultRecordPurpose.\n14.\nVU Identification\nBlock identifier\nVU manufacturer name\nVU manufacturer address\nVU part number\nVU approval number\nVU serial number\nVU year of manufacture\nVU software version and installation date.\n15.\nSensor identification\nBlock identifier\nSensor serial number\nSensor approval number\nSensor first installation date.\n16.\nCalibration data\nBlock identifier\n16.1.\nCalibration record\nRecord identifier\nWorkshop having performed the calibration\nWorkshop address\nWorkshop card identification\nWorkshop card expiry date\nBlank line\nCalibration date + calibration purpose\nVIN\nRegistering Member State & VRN\nCharacteristic coefficient of vehicle\nConstant of the recording equipment\nEffective circumference of wheel tyres\nSize of tyres mounted\nSpeed limiting device setting\nOld and new odometer values\nThe calibration purpose (p) is a numerical code explaining why these calibration parameters were recorded, coded in accordance with the data element CalibrationPurpose .\n17.\nTime adjustment\nBlock identifier\n17.1.\nTime adjustment record\nRecord identifier\nOld date and time\nNew date and time\nWorkshop having performed the time adjustment\nWorkshop address\nWorkshop card identification\nWorkshop card expiry date.\n18.\nMost recent event and Fault recorded in the VU\nBlock identifier\nMost recent event date time\nMost recent fault date time.\n19.\nOver speeding control information\nBlock identifier\nDate and time of last OVER SPEEDING CONTROL\nDate/time of first over speeding and number of over speeding events since.\n20.\nOver speeding record\n20.1.\nBlock identifier ‘ First over speeding after the last calibration ’\n20.2.\nBlock identifier ‘ The 5 most serious over the last 365 days ’ .\n20.3.\nBlock identifier ‘ The most serious for each of the last 10 days of occurrence ’\n20.4.\nRecord identifier\nDate time and duration\nMax and average speeds, No of similar events this day\nDriver's surname\nDriver's first name(s)\nDriver card identification\n20.5.\nIf no over speeding record exists in a block.\n21.\nHand-written information\nBlock identifier\n21.1.\nControl Place\n21.2.\nController's signature\n21.3.\nFrom time\n21.4.\nTo time\n21.5.\nDriver's signature\n‘ Hand-written information ’ Insert enough blank lines above a hand-written item, to be able to actually write the required information or to put a signature.\n3.\nPRINTOUT SPECIFICATIONS\nIn this chapter the following notation conventions have been used:\nPrint block or record number N\nPrint block or record number N repeated as many times as necessary\nPrint blocks or records X and/or Y as needed, and repeating as many times as necessary\n3.1.\nDriver activities from card daily printout\nThe driver activities from card daily printout shall be in accordance with the following format:\nDate and time at which the document is printed\nType of printout\nController identification (if a control card is inserted in the VU)\nDriver identification (from card subject of the printout)\nVehicle identification (vehicle from which printout is taken)\nVU identification (VU from which printout is taken)\nLast calibration of this VU\nLast control the inspected driver has been subject to\nDriver activities delimiter\nActivities of the driver in order of occurrence\nDaily summary delimiter\nPlaces entered in chronological order\nActivity totals\nEvents or faults from card delimiter\nEvent/Fault records (Last 5 events or faults stored in the card)\nEvents or faults from VU delimiter\nEvent/Fault records (Last 5 events or faults stored or on-going in the VU)\nControl place\nController's signature\nDriver's signature\n3.2.\nDriver activities from VU daily printout\nThe driver activities from VU daily printout shall be in accordance with the following format:\nDate and time at which the document is printed\nType of printout\nCard holder identification (for all cards inserted in VU)\nVehicle identification (vehicle from which printout is taken)\nVU identification (VU from which printout is taken)\nLast calibration of this VU\nLast control on this recording equipment\nDriver activities delimiter\nDriver slot delimiter (slot 1)\nActivities in chronological order (driver slot)\nCo-driver slot delimiter (slot 2)\nActivities in chronological order (co-driver slot)\nDaily summary delimiter\nSummary of periods without card in driver slot\nPlaces entered in chronological order\nActivity totals\nSummary of periods without card in co-driver slot\nPlaces entered in chronological order\nActivity totals\nSummary of activities for a driver both slots included\nPlaces entered by this driver in chronological order\nActivity totals for this driver\nEvents faults delimiter\nEvent/Fault records (Last 5 events or faults stored or on-going in the VU)\nControl place\nController's signature\nFrom time\n(space available for a driver without a card to indicate which periods are relevant to himself)\nTo time\nDriver's signature\n3.3.\nEvents and faults from card printout\nThe events and faults from card printout shall be in accordance with the following format:\nDate and time at which the document is printed\nType of printout\nController identification (if a control card is inserted in the VU)\nDriver identification (from card subject of the printout)\nVehicle identification (vehicle from which printout is taken)\nEvents delimiter\nEvent records (all events stored on the card)\nFaults delimiter\nFault records (all faults stored on the card)\nControl place\nController's signature\nDriver's signature\n3.4.\nEvents and faults from VU printout\nThe events and faults from VU printout shall be in accordance with the following format:\nDate and time at which the document is printed\nType of printout\nCard holder identification (for all cards inserted in VU)\nVehicle identification (vehicle from which printout is taken)\nEvents delimiter\nEvent records (All Events stored or on-going in the VU)\nFaults delimiter\nFault records (All Faults stored or on-going in the VU)\nControl place\nController's signature\nDriver's signature\n3.5.\nTechnical data printout\nThe technical data printout shall be in accordance with the following format:\nDate and time at which the document is printed\nType of printout\nCard holder identification (for all cards inserted in VU)\nVehicle identification (vehicle from which printout is taken)\nVU identification\nSensor identification\nCalibration data delimiter\nCalibration records (all records available in chronological order)\nTime adjustment delimiter\nTime adjustment records (all records available from time adjustment and from calibration data records)\nMost recent event and Fault recorded in the VU\n3.6.\nOver speeding printout\nThe over speeding printout shall be in accordance with the following format:\nDate and time at which the document is printed\nType of printout\nCard holder identification (for all cards inserted in VU)\nVehicle identification (vehicle from which printout is taken)\nOver speeding control information\nOver speeding data identifier\nFirst over speeding after the last calibration\nOver speeding data identifier\nThe 5 most serious over speeding events over the last 365 days\nOver speeding data identifier\nThe most serious over speeding for each of the last 10 days of occurrence\nControl place\nController's signature\nDriver's signature.\nAppendix 5\nDISPLAY\nIn this appendix the following format notation conventions have been used:\ncharacters printed in bold denote plain text to be displayed (display remains in normal character),\nnormal characters denote variables (pictograms or data) to be replaced by their values for displaying:\ndd mm yyyy day, month, year,\nhh hours,\nmm minutes,\nD duration pictogram,\nEF event or fault pictograms combination,\nO mode of operation pictogram.\nThe recording equipment shall display data using the following formats:\nData\nFormat\nDefault display\nLocal time\nhh:mm\nMode of operation\nO\nInformation related to the driver\nDhhhmm hhhmm\nInformation related to the co-driver\nDhhhmm\nOut of scope condition opened\nWarning display\nExceeding continuous driving time\nhhhmm hhhmm\nEvent or fault\nEF\nOther displays\nUTC date\nUTC dd/mm/yyyy\nor\nUTC dd.mm.yyyy\ntime\nhh:mm\nDriver's continuous driving time and cumulative break time\nhhhmm hhhmm\nCo-driver's continuous driving time and cumulative break time\nhhhmm hhhmm\nDriver's cumulated driving time for the previous and the current week\nhhhhmm\nCo-driver's cumulated driving time for the previous and the current week\nhhhhmm\nAppendix 6\nEXTERNAL INTERFACES\n1.\nHARDWARE\n1.1.\nConnector\nThe 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):\nThe following diagram shows a typical six pin mating plug:\n1.2.\nContact allocation\nContacts shall be allocated in accordance with the following table:\nPin\nDescription\nRemark\n1\nBattery minus\nConnected to the battery minus of the vehicle\n2\nData communication\nK-line (ISO 14 230-1)\n3\nRxD — Downloading\nData input to recording equipment\n4\nInput/output signal\nCalibration\n5\nPermanent power output\nThe voltage range is specified to be that of the vehicle power minus 3V to allow for the voltage drop across the protective circuitry\nOutput 40 mA\n6\nTxD — Downloading\nData output from recording equipment\n1.3.\nBlock diagram\nThe block diagram shall comply with the following:\n2.\nDOWNLOADING INTERFACE\nThe downloading interface shall comply to RS232 specifications.\nThe downloading interface shall use one start bit, 8 data bits LSB first, one even parity bit and 1 stop bit.\nStart bit one bit with logic level 0\nData bits transmitted with LSB first\nParity bit even parity\nStop bit one bit with logic level 1\nWhen numerical data composed by more than one byte are transmitted, the most significant byte is transmitted first and the least significant byte last.\nTransmission 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.\n3.\nCALIBRATION INTERFACE\nThe data communication shall comply to ISO 14 230-1 Road vehicles — Diagnostic systems — Keyword protocol 2000 — Part 1: Physical layer, First edition: 1999.\nThe input/output signal shall comply with the following electrical specification:\nParameter\nMinimum\nTypical\nMaximum\nRemark\nU low (in)\n1,0 V\nI = 750 µA\nU high (in)\n4 V\nI = 200 µA\nFrequency\n4 kHz\nU low (in)\n1,0 V\nI = 1 mA\nU high (out)\n4 V\nI = 1 mA\nThe input/output signal shall comply with the following timing diagrams:\nSensor signal (out)\nTest signal (in)\nUTC clock signal (out)\nAppendix 7\nDATA DOWNLOADING PROTOCOLS\n1.\nINTRODUCTION\nThis 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.\n1.1.\nScope\nData may be downloaded to an ESM:\nfrom a vehicle unit by an intelligent dedicated equipment (IDE) connected to the VU,\nfrom a tachograph card by an IDE fitted with a card interface device (IFD),\nfrom a tachograph card via a vehicle unit by an IDE connected to the VU.\nTo give the possibility to verify the authenticity and integrity of downloaded data stored on an ESM, data is downloaded with a signature appended in accordance 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 independently a trusted European public key.\nData downloaded during one download session must be stored in the ESM within one file.\n1.2.\nAcronyms and notations\nThe following acronyms are used in this appendix:\nAID application identifier\nATR answer to reset\nCS checksum byte\nDF dedicated file\nDS_ diagnostic session\nEF elementary file\nESM external storage medium\nFID file identifier (File ID)\nFMT format byte (first byte of message header)\nICC integrated circuit card\nIDE intelligent dedicated equipment: The equipment used to perform data downloading to the ESM (e.g. personal computer)\nIFD interface device\nKWP keyword protocol 2000\nLEN length byte (last byte of message header)\nPPS protocol parameter selection\nPSO perform security operation\nSID service identifier\nSRC source byte\nTGT target byte\nTLV tag length value\nTREP transfer response parameter\nTRTP transfer request parameter\nVU vehicle unit.\n2.\nVU DATA DOWNLOADING\n2.1.\nDownload procedure\nIn order to carry on a VU data download, the operator must perform the following operations:\ninsert his tachograph card inside a card slot of the VU ,\nconnect the IDE to the VU download connector,\nestablish the connection between the IDE and the VU,\nselect on the IDE the data to download and send the request to the VU,\nclose the download session.\n2.2.\nData download protocol\nThe protocol is structured on a master-slave basis, with the IDE playing the master role and the VU playing the slave role.\nThe 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).\nThe 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 ).\n2.2.1.\nMessage structure\nAll the messages exchanged between the IDE and the VU are formatted with a structure consisting of three parts:\nheader composed by a format byte (FMT), a target byte (TGT), a source byte (SRC) and possibly a length byte (LEN),\ndata 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).\nchecksum composed by a checksum byte (CS).\nHeader\nData field\nChecksum\nFMT\nTGT\nSRC\nLEN\nSID\nDATA\n…\n…\n…\nCS\n4 bytes\nMax 225 bytes\n1 byte\nThe TGT and SRC byte represent the physical address of the recipient and originator of the message. Values are F0 Hex for the IDE and EE Hex for the VU.\nThe LEN byte is the length of the data field part.\nThe checksum byte is the 8 bit sum series modulo 256 of all the bytes of the message excluding the CS itself.\nFMT, SID, DS_, TRTP and TREP bytes are defined later in this document.\nIn 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 submessages. 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.\nIf 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.\nExample:\nHeader\nSID\nTREP\nMessage\nCS\n4 Bytes\nLonger than 255 Bytes\nWill be transmitted as:\nHeader\nSID\nTREP\n00\n01\nSubmessage 1\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\n00\n01\nSubmessage 2\nCS\n4 Bytes\n255 Bytes\n…\nHeader\nSID\nTREP\nxx\nyy\nSubmessage n\nCS\n4 Bytes\nLess than 255 Bytes\nor as:\nHeader\nSID\nTREP\n00\n01\nSubmessage 1\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\n00\n02\nSubmessage 2\nCS\n4 Bytes\n255 Bytes\n…\nHeader\nSID\nTREP\nxx\nyy\nSubmessage n\nCS\n4 Bytes\n255 Bytes\nHeader\nSID\nTREP\nxx\nyy+1\nCS\n4 Bytes\n4 bytes\n2.2.2.\nMessage types\nThe communication protocol for data download between the VU and the IDE requires the exchange of eight different message types.\nThe following table summarises these messages.\nNotes:\nSid Req = the Sid of the corresponding request.\nTREP = the TRTP of the corresponding request.\nDark cells denotes that nothing is transmitted.\nThe term upload (as seen from the IDE) is used for compatibility with ISO 14229. It means the same as download (as seen from the VU).\nPotential 2-byte submessage counters are not shown in this Table.\nMessage Structure\nMaximum 4 bytes Header\nMaximum 255 bytes Data\n1 byte CheckSum\nIDE ->\n<- VU\nFMT\nTGT\nSRC\nLEN\nSID\nDS_/TRTP\nDATA\nCS\nStart communication request\n81\nEE\nF0\n81\nE0\nPositive response start communication\n80\nF0\nEE\n03\nC1\n8F,EA\n9B\nStart diagnostic session request\n80\nEE\nF0\n02\n10\n81\nF1\nPositive response start diagnostic\n80\nF0\nEE\n02\n50\n81\n31\nLink control service\nVerify Baud rate (stage 1)\n9 600 Bd\n80\nEE\nF0\n04\n87\n01,01,01\nEC\n19 200 Bd\n80\nEE\nF0\n04\n87\n01,01,02\nED\n38 400 Bd\n80\nEE\nF0\n04\n87\n01,01,03\nED\n57 600 Bd\n80\nEE\nF0\n04\n87\n01,01,04\nEF\n115 200 Bd\n80\nEE\nF0\n04\n87\n01,01,05\nF0\nPositive response verify Baud rate\n80\nF0\nEE\n02\nC7\n01\n28\nTransition baud rate (stage 2)\n80\nEE\nF0\n03\n87\n02,03\nED\nRequest Upload\n80\nEE\nF0\n0A\n35\n00,00,00,00,00,FF,FF,FF,FF\n99\nPositive response request upload\n80\nF0\nEE\n03\n75\n00,FF\nD5\nTransfer data request\nOverview\n80\nEE\nF0\n02\n36\n01\n97\nActivities\n80\nEE\nF0\n06\n36\n02\nDate\nCS\nEvents and faults\n80\nEE\nF0\n02\n36\n03\n99\nDetailed speed\n80\nEE\nF0\n02\n36\n04\n9A\nTechnical data\n80\nEE\nF0\n02\n36\n05\n9B\nCard download\n80\nEE\nF0\n02\n36\n06\n9C\nPositive response transfer data\n80\nF0\nEE\nLen\n76\nTREP\nData\nCS\nRequest transfer exit\n80\nEE\nF0\n01\n37\n96\nPositive response request transfer exit\n80\nF0\nEE\n01\n77\nD6\nStop communication request\n80\nEE\nF0\n01\n82\nE1\nPositive response stop communication\n80\nF0\nEE\n01\nC2\n21\nAcknowledge sub message\n80\nEE\nF0\nLen\n83\nData\nCS\nNegative responses\nGeneral reject\n80\nF0\nEE\n03\n7F\nSid Req\n10\nCS\nService not supported\n80\nF0\nEE\n03\n7F\nSid Req\n11\nCS\nSubfunction not supported\n80\nF0\nEE\n03\n7F\nSid Req\n12\nCS\nIncorrect message length\n80\nF0\nEE\n03\n7F\nSid Req\n13\nCS\nConditions not correct or request sequence error\n80\nF0\nEE\n03\n7F\nSid Req\n22\nCS\nRequest out of range\n80\nF0\nEE\n03\n7F\nSid Req\n31\nCS\nUpload not accepted\n80\nF0\nEE\n03\n7F\nSid Req\n50\nCS\nResponse pending\n80\nF0\nEE\n03\n7F\nSid Req\n78\nCS\nData not available\n80\nF0\nEE\n03\n7F\nSid Req\nFA\nCS\n2.2.2.1.\nStart communication request (SID 81)\nThis 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).\n2.2.2.2.\nPositive response start communication (SID C1)\nThis 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.\n2.2.2.3.\nStart diagnostic session request (SID 10)\nThe 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.\n2.2.2.4.\nPositive response start diagnostic (SID 50)\nThe positive response start diagnostic message is sent by the VU to answer positively to Diagnostic Session Request.\n2.2.2.5.\nLink control service (SID 87)\nThe 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\n2.2.2.6.\nLink control positive response (SID C7)\nThe 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).\n2.2.2.7.\nRequest upload (SID 35)\nThe 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.\n2.2.2.8.\nPositive response request upload (SID 75)\nThe 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.\n2.2.2.9.\nTransfer data request (SID 36)\nThe 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.\nThere are six types of data transfer:\noverview (TRTP 01),\nactivities of a specified date (TRTP 02),\nevents and faults (TRTP 03),\ndetailed speed (TRTP 04),\ntechnical data (TRTP 05),\ncard download (TRTP 06).\nIt 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 signature).\nIn the second case (TRTP 02) the transfer data request message includes the indication of the calendar day TimeReal format) to be downloaded.\n2.2.2.10.\nPositive response transfer data (SID 76)\nThe 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.\nIn 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:\nsecurity certificates,\nvehicle identification,\nVU current date and time,\nminimum and maximum downloadable date (VU data),\nindication of cards presence in the VU,\nprevious download to a company,\ncompany locks,\nprevious controls.\n2.2.2.11.\nRequest transfer exit (SID 37)\nThe request transfer exit message is sent by the IDE to inform the VU that the download session is terminated.\n2.2.2.12.\nPositive response request transfer exit (SID 77)\nThe positive response request transfer exit message is sent by the VU to acknowledge the Request Transfer Exit.\n2.2.2.13.\nStop communication request (SID 82)\nThe stop communication request message is sent by the IDE to disconnect the communication link with the VU.\n2.2.2.14.\nPositive response stop communication (SID C2)\nThe positive response stop communication message is sent by the VU to acknowledge the stop communication request.\n2.2.2.15.\nAcknowledge submessage (SID 83)\nThe 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:\nMsgC +1 Acknowledges correct receipt of submessage number MsgC.\nRequest from the IDE to the VU to send next submessage,\nMsgC indicates a problem with the receipt of submessage number MsgC.\nRequest from the IDE to the VU to send the submessage again,\nFFFF requests termination of the message.\nThis can be used by the IDE to end the transmission of the VU message for any reason.\nThe last submessage of a message (LEN byte < 255) may be acknowledged using any of these codes or not acknowledged.\nThe VU responses that will consist of several sub messages are:\npositive response transfer Data (SID 76)\n2.2.2.16.\nNegative Response (SID 7F)\nThe 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:\n10 general reject\nThe action cannot be performed for a reason not covered below\n11 service not supported\nThe SID of the request is not understood\n12 sub function not supported\nThe DS_ or TRTP of the request is not understood, or there are no further sub messages to be transmitted\n13 incorrect message length\nThe length of the received message is wrong\n22 conditions not correct or request sequence error\nThe required service is not active or the sequence of request messages is not correct\n31 request out of range\nThe request parameter record (data field) is not valid\n50 upload not accepted\nThe request cannot be performed (VU in a non appropriate mode of operation or internal fault of the VU)\n78 response pending\nThe action requested cannot be completed in time and the VU is not ready to accept another request\nFA data not available\nThe data object of a data transfer request are not available in the VU (e.g. no card is inserted, …)\n2.2.3.\nMessage flow\nA typical message flow during a normal data download procedure is the following:\nIDE\nFE\nStart communication request\nPositive response\nStart diagnostic service request\nPositive response\nRequest upload\nPositive response\nTransfer data request overview\nPositive response transfer\nData request #2\nPositive response #1\nAcknowledge submessage #1\nPositive response #2\nAcknowledge submessage #2\nPositive response #m\nAcknowledge submessage #m\nPositive response (Data field < 255 Bytes)\nAcknowledge submessage (optional)\n…\nTransfer data request #n\nPositive response\nRequest transfer exit\nPositive response\nStop communication request\nPositive response\n2.2.4.\nTiming\nDuring normal operation the timing parameters shown in the following figure are relevant:\nWhere:\nP1 Inter byte time for VU response.\nP2 Time between end of IDE request and start of VU response, or between end of IDE acknowledge and start of next VU response.\nP3 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.\nP4 Inter byte time for IDE request.\nP5 Extended value of P3 for card downloading.\nThe 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).\nIf 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.\nTiming Parameter\nLower limit Value (ms)\nUpper limit value (ms)\nP1\n0\n20\nP2\n20\n1 000\nP3\n10\n5 000\nP4\n5\n20\nP5\n10\n20 minutes\n2.2.5.\nError handling\nIf 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.\nIn Figure 2 and Figure 3 the error handling procedures for the VU and the IDE are respectively shown.\n2.2.5.1.\nStart communication phase\nIf 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.\nIf 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.\n2.2.5.2.\nCommunication phase\nTwo different error handling areas can be defined:\n1.. The VU detects an IDE transmission error.\nFor 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).\nIf the VU detects one of the above errors, then it sends no response and ignores the message received.\nThe 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.\n2.. The IDE detects a VU transmission error.\nFor 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).\nThe IDE shall detect sequence errors, e.g. incorrect sub message counter increments in successive received messages.\nIf 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.\nThe IDE shall wait at least for a period of P3min before beginning each transmission; the wait period shall be measured from the last calculated occurrence of a stop bit after the error was detected.\n2.2.6.\nResponse message content\nThis paragraph specifies the content of the data fields of the various positive response messages.\nData elements are defined in Appendix 1 data dictionary.\n2.2.6.1.\nPositive response transfer data overview\nThe 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:\n2.2.6.2.\nPositive response transfer data activities\nThe 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:\n2.2.6.3.\nPositive response transfer data events and faults\nThe 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:\n2.2.6.4.\nPositive response transfer data detailed speed\nThe 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:\n2.2.6.5.\nPositive response transfer data technical data\nThe 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:\n2.3.\nESM File storage\nWhen 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).\n3.\nTACHOGRAPH CARDS DOWNLOADING PROTOCOL\n3.1.\nScope\nThis 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 authentication between the card and the IDE is performed.\n3.2.\nDefinitions\nDownload 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).\nSigned 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.\n3.3.\nCard downloading\nThe download of a tachograph card includes the following steps:\ndownload the common information of the card in the EFs ICC and IC . This information is optional and is not secured with a digital signature,\nDownload the EFs Card_Certificate and CA_Certificate. This information is not secured with a digital signature,\nIt is mandatory to download these files for each download session.\ndownload the other application data EFs (within Tachograph DF) except EF Card_Download. This information is secured with a digital signature,\nit is mandatory to download at least the EFs Application_Identification and ID for each download session,\nwhen downloading a driver card it is also mandatory to download the following EFs:\nEvents_Data,\nFaults_Data,\nDriver_Activity_Data,\nVehicles_Used,\nPlaces,\nControl_Activity_Data,\nSpecific_Conditions.\nWhen downloading a driver card, update the LastCardDownload date in EF Card_Download,\nWhen downloading a workshop card, reset the calibration counter in EF Card_Download.\n3.3.1.\nInitialisation sequence\nThe IDE shall initiate the sequence as follows:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nHardware reset\nATR\nIt is optional to use PPS to switch to a higher baudrate as long as the ICC supports it.\n3.3.2.\nSequence for unsigned data files\nThe sequence to download the ICC , IC , Card_Certificate and CA_Certificate is as follows:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nSelect file\nSelect file select by file identifiers\nOK\nRead Binary\nIf 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.\nFile data\nOK\nStore data to ESM\naccording to 3.4, (Data storage format)\nNote: Before selecting the Card_Certificate EF, the Tachograph Application must be selected (selection by AID).\n3.3.3.\nSequence for signed data files\nThe following sequence shall be used for each of the following files that has to be downloaded with their signature:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nSelect File\nOK\nPerform hash of File\nCalculates 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.\nCalculate hash of file and store hash value temporarily\nOK\nRead Binary\nIf 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.\nFile Data\nOK\nStore received data to ESM\naccording to 3.4, (Data storage format)\nPSO: Compute digital signature\nPerform security operation ‘ compute digital signature ’ using the temporarily stored hash value\nSignature\nOK\nAppend data to the previous stored data on the ESM\naccording to 3.4, (Data storage format)\n3.3.4.\nSequence for resetting the calibration counter\nThe sequence to reset the NoOfCalibrationsSinceDownload counter in the EF Card_Download in a workshop card is the following:\nCard\nDirection\nIDE/IFD\nMeaning/Remarks\nSelect File EF Card_Download\nSelect by file identifiers\nOK\nUpdate Binary\nNoOfCalibrationsSinceDownload = ′00 00′\nResets card download number\nOK\n3.4.\nData storage format\n3.4.1.\nIntroduction\nThe downloaded data has to be stored according to the following conditions:\nthe 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,\nall files of the card downloaded within a download session are stored in one file on the ESM.\n3.4.2.\nFile format\nThe file format is a concatenation of several TLV objects.\nThe tag for an EF shall be the FID plus the appendix ‘ 00 ’ .\nThe tag of an EF's signature shall be the FID of the file plus the appendix ‘ 01 ’ .\nThe 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.\nWhen a file is not downloaded nothing related to the file shall be stored (no tag and no zero length).\nA signature shall be stored as the next TLV object directly after the TLV object that contains the data of the file.\nDefinition\nMeaning\nLength\nFID (2 Bytes) || ‘ 00 ’\nTag for EF (FID)\n3 Bytes\nFID (2 Bytes) || ‘ 01 ’\nTag for Signature of EF(FID)\n3 Bytes\nxx xx\nLength of value field\n2 Bytes\nExample of data in a download file on an ESM:\nTag\nLength\nValue\n00 02 00\n00 11\nData of EF ICC\nC1 00 00\n00 C2\nData of EF Card_Certificate\n…\n05 05 00\n0A 2E\nData of EF Vehicles_Used\n05 05 01\n00 80\nSignature of EF Vehicles_Used\n4.\nDOWNLOADING A TACHOGRAPH CARD VIA A VEHICLE UNIT\nThe VU must allow for downloading the content of a driver card inserted to a connected IDE.\nThe IDE shall send a ‘ transfer data request card download ’ message to the VU to initiate this mode (see 2.2.2.9).\nThe 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.\nThe IDE shall retrieve card data from the ‘ positive response transfer data ’ message (stripping all headers, SIDs, TREPs, submessage counters, and checksums) and store them within one physical file as described in paragraph 2.3.\nThe VU shall then, as applicable, update the Control_Activity_Data or the Card_Download file of the driver card.\nAppendix 8\nCALIBRATION PROTOCOL\n1.\nINTRODUCTION\nThis 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 calibration connector.\nEstablishing K-line communications is described in Section 4 ‘ Communication Services ’ .\nThis appendix uses the idea of diagnostic ‘ sessions ’ to determine the scope of K-line control under different conditions. The default session is the ‘ StandardDiagnosticSession ’ where all data can be read from a vehicle unit but no data can be written to a vehicle unit.\nSelection of the diagnostic session is described in Section 5 ‘ Management Services ’ .\nThe ‘ 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.\nData transfer via K-line is described in Section 6 ‘ Data Transmission Services ’ . Formats of data transferred are detailed in Section 8 ‘ dataRecords formats ’ .\nThe ‘ ECUAdjustmentSession ’ allows the selection of the I/O mode of the calibration 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 ’ .\nThroughout 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.\n2.\nTERMS, DEFINITIONS AND REFERENCES\nThe 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 ).\nByte encoding and hexadecimal values are used for the service identifiers, the service requests and responses, and the standard parameters.\nThe term ‘ tester ’ refers to the equipment used to enter programming/calibration data into the VU.\nThe terms ‘ client ’ and ‘ server ’ refer to the tester and the VU respectively.\nThe term ECU means ‘ Electronic Control Unit ’ and refers to the VU.\nReferences:\nISO 14230-2 Road Vehicles — Diagnostic Systems — Keyword Protocol 2000- Part 2: Data Link Layer. First edition: 1999. Vehicles — Diagnostic Systems.\n3.\nOVERVIEW OF SERVICES\n3.1.\nServices available\nThe following table provides an overview of the services that will be available in the recording equipment and are defined in this document.\nThe table indicates the services that are available in an enabled diagnostic session.\nThe first column lists the services that are available,\nthe second column includes the section number in this appendix where of service is further defined,\nthe third column assigns the assigns the service identifier values for request messages,\nthe fourth column specifies the services of the ‘ StandardDiagnosticSession ’ (SD) which must be implemented in each VU,\nthe 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,\nthe sixth column specifies the services of the ‘ ECUProgrammingSession ’ (ECUPS) which must be implemented to allow for programming of parameters in the VU.\nTable 1\nService Identifier value summary table\nNo symbol indicates that this service is not allowed in this diagnostic session.This symbol indicates that the service is mandatory in this diagnostic session.\nDiagnostic Service Name\nSection No\nSId Req.Value\nDiagnostic Sessions\nSD\nECUAS\nECUPS\nStartCommunication\n4.1\n81\nStopCommunication\n4.2\n82\nTesterPresent\n4.3\n3E\nStartDiagnosticSession\n5.1\n10\nSecurityAccess\n5.2\n27\nReadDataByIdentifier\n6.1\n22\nWriteDataByIdentifier\n6.2\n2E\nInputOutputControlByIdentifier\n7.1\n2F\n3.2.\nResponse codes\nResponse codes are defined for each service.\n4.\nCOMMUNICATION SERVICES\nSome 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:\nTable 2\nCommunication services\nService name\nDescription\nStartCommunication\nThe client requests to start a communication session with a server(s)\nStopCommunication\nThe client requests to stop the current communication session\nTesterPresent\nThe client indicates to the server that it is still present\nThe StartCommunication Service is used for starting a communication. In order to perform any service, communication must be initialised and the communication parameters need to be appropriate for the desired mode.\n4.1.\nStartCommunication Service\nUpon receiving a StartCommunication indication primitive, the VU shall check if the requested communication link can be initialised under the present conditions. Valid conditions for the initialisation of a communication link are described in document ISO 14230-2.\nThen the VU shall perform all actions necessary to initialise the communication link and send a StartCommunication response primitive with the positive response parameters selected.\nIf 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.\nIf 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.\nThe StartCommunication Request message must be physically addressed.\nInitialising the VU for services is performed through a ‘ fast initialisation ’ method,\nthere is a bus-idle time prior to any activity,\nthe tester then sends an initialisation pattern,\nall information which is necessary to establish communication is contained in the response of the VU.\nAfter completion of the initialisation,\nall communication parameters are set to values defined in Table 4 according to the key bytes,\nthe VU is waiting for the first request of the tester,\nthe VU is in the default diagnostic mode, i.e. StandardDiagnosticSession,\nthe calibration I/O signal line is in the default state, i.e. disabled state.\nThe data rate on the K-line shall be 10 400 Baud.\nThe 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.\nThe timing values for the fast initialisation and communications in general are detailed in the tables below. There are different possibilities for the idle time:\nfirst transmission after power on, T idle = 300 ms.\nafter completion of a StopCommunication Service, T idle = P3 min.\nafter stopping communication by time-out P3 max, T idle = O.\nTable 3\nTiming values for fast initialisation\nParameter\nminimum value\nmaximum value\nTinil\n25 ± 1 ms\n24 ms\n26 ms\nTwup\n50 ± 1 ms\n49 ms\n51 ms\nTable 4\nCommunication timing values\nTiming parameter\nParameter description\nLower limit values (ms)\nUpper limit values (ms)\nminimum\nmaximum\nP1\nInter byte time for VU response\n0\n20\nP2\nTime between tester request and VU response or two VU responses\n25\n250\nP3\nTime between end of VU responses and start of new tester request\n55\n5 000\nP4\nInter byte time for tester request\n5\n20\nThe message format for fast initialisation is detailed in the following tables:\nTable 5\nStartCommunication request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n81\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nStartCommunication Request Service\n81\nSCR\n#5\nChecksum\n00-FF\nCS\nTable 6\nStartCommunication positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nStartCommunication Positive Response Service Id\nC1\nSCRPR\n#6\nKey byte 1\nEA\nKB1\n#7\nKey byte 2\n8F\nKB2\n#8\nChecksum\n00-FF\nCS\nThere is no negative response to the StartCommunication Request message, if there is no positive response message to be transmitted then the VU is not initialised, nothing is transmitted and it remains in its normal operation.\n4.2.\nStopCommunication service\n4.2.1.\nMessage description\nThe purpose of this communication layer service is to terminate a communication session.\nUpon 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.\nIf it is possible to terminate the communication, the VU shall issue a StopCommunication response primitive with the Positive Response parameters selected, before the communication is terminated.\nIf the communication cannot be terminated by any reason, the VU shall issue a StopCommunication response primitive with the Negative Response parameter selected.\nIf time -out of P3max is detected by the VU, the communication shall be terminated without any response primitive being issued.\n4.2.2.\nMessage format\nThe message formats for the StopCommunication primitives are detailed in the following tables:\nTable 7\nStopCommunication request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n01\nLEN\n#5\nStopCommunication Request Service Id\n82\nSPR\n#6\nChecksum\n00-FF\nCS\nTable 8\nStopCommunication positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n01\nLEN\n#5\nStopCommunication Positive Response Service\nC2\nSPRPR\n#6\nChecksum\n00-FF\nCS\nTable 9\nStopCommunication negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegative Response Service Id\n7F\nNR\n#6\nStopCommunication Request Service Identification\n82\nSPR\n#7\nresponseCode = generalReject\n10\nRC_GR\n#8\nChecksum\n00-FF\nCS\n4.2.3.\nParameter definition\nThis service does not require any parameter definition.\n4.3.\nTesterPresent service\n4.3.1.\nMessage description\nThe 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.\n4.3.2.\nMessage format\nThe message formats for the TesterPresent primitives are detailed in the following tables.\nTable 10\nTesterPresent request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nTesterPresent Request Service Id\n3E\nTP\n#6\nSub Function = responseRequired = [yes\nno]\n01\n02\nRESPREQ_Y\nRESPREQ_NO\n#7\nChecksum\n00-FF\nCS\nIf 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.\nTable 11\nTesterPresent positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n01\nLEN\n#5\nTesterPresent Positive Response Service Id\n7E\nTPPR\n#6\nChecksum\n00-FF\nCS\nThe service shall support the following negative responses codes:\nTable 12\nTesterPresent negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegative Response Service Id\n7F\nNR\n#6\nTesterPresent Request Service Identification\n3E\nTP\n#7\nresponseCode = [SubFunctionNotSupported-InvalidFormat\nincorrectMessageLength]\n12\n13\nRC_SFNS_IF\nRC_IML\n#8\nChecksum\n00-FF\nCS\n5.\nMANAGEMENT SERVICES\nThe services available are detailed in the following table:\nTable 13\nManagement services\nService name\nDescription\nStartDiagnosticSession\nThe client requests to start a diagnostic session with a VU\nSecurityAccess\nThe client requests access to functions restricted to authorised users\n5.1.\nStartDiagnosticSession service\n5.1.1.\nMessage description\nThe 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:\nthere shall be always exactly one diagnostic session active in the VU,\nthe 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,\nif a diagnostic session which is already running has been requested by the tester, then the VU shall send a positive response message,\nwhenever 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 StartDiagnosticSession negative response message, and the current session shall continue.\nThe diagnostic session shall only be started if communication has been established between the client and the VU.\nThe timing parameters defined in Table 4 shall be active after a successful StartDiagnosticSession with the diagnosticSession parameter set to ‘ StandardDiagnosticSession ’ in the request message if another diagnostic session was previously active.\n5.1.2.\nMessage format\nThe message formats for the StartDiagnosticSession primitives are detailed in the following tables:\nTable 14\nStartDiagnosticSession request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nStartDiagnosticSession request service Id\n10\nSTDS\n#6\ndiagnosticSession = (one value from Table 17)\nxx\nDS_ …\n#7\nChecksum\n00-FF\nCS\nTable 15\nStartDiagnosticSession positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nStartDiagnosticSession Positive Response Service Id\n50\nSTDSPR\n#6\nDiagnosticSession = (same value as in byte #6 Table 14)\nxx\nDS_ …\n#7\nChecksum\n00-FF\nCS\nTable 16\nStartDiagnosticSession negative response message\nThe value inserted in byte #6 of the request message is not supported, i.e. not in Table 17.\nThe length of the message is wrong.\nThe criteria for the request StartDiagnosticSession are not met.\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegative response service Id\n7F\nNR\n#6\nStartDiagnosticSession request service Id\n10\nSTDS\n#7\nResponseCode = (subFunctionNotSupported\nincorrectMessageLength\nconditionsNotCorrect )\n12\n13\n22\nRC_SFNS\nRC_IML\nRC_CNC\n#8\nChecksum\n00-FF\nCS\n5.1.3.\nParameter definition\nThe 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:\nTable 17\nDefinition of diagnosticSession values\nHex\nDescription\nMnemonic\n81\nStandardDiagnosticSession\nThis 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 diagnostic sessions specified in this section.\nSD\n85\nECUProgrammingSession\nThis diagnostic session enables all services specified in Table 1 column 6 ‘ ECUPS ’ . These services support the memory programming of a server (VU) This diagnostic session may be overwritten by other diagnostic sessions specified in this section.\nECUPS\n87\nECUAdjustmentSession\nThis 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 overwritten by other diagnostic sessions specified in this section.\nECUAS\n5.2.\nSecurityAccess service\nWriting 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.\nThe SecurityAccess service provides a means to enter the PIN and to indicate to the tester whether or not the VU is in CALIBRATION mode.\nIt is acceptable that the PIN may be entered through alternative methods.\n5.2.1.\nMessage description\nThe SecurityAccess service consists of a SecurityAccess ‘ requestSeed ’ message, eventually followed by a SecurityAccess ‘ sendKey ’ message. The SecurityAccess service must be carried out after the StartDiagnosticSession service.\nThe tester shall use the SecurityAccess \"requestSeed\" message to check if the vehicle unit is ready to accept a PIN.\nIf 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.\nIf 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.\nIf 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.\nThe 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 requestCorrectlyReceived-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.\nThe vehicle unit shall answer to this request using the service SecurityAccess Positive Response only when in CALIBRATION mode.\nIn the following cases, the vehicle unit shall answer to this request with a Negative Response with a response code set to:\nsubFunctionNot supported: invalid format for the subfunction parameter (accessType),\nconditionsNotCorrectOrRequestSequenceError: vehicle unit not ready to accept a PIN entry,\ninvalidKey: PIN not valid and number of PIN checks attempts not exceeded,\nexceededNumberOfAttempts: PIN not valid and number of PIN checks attempts exceeded,\ngeneralReject: Correct PIN but mutual authentication with workshop card failed.\n5.2.2.\nMessage format — SecurityAccess — requestSeed\nThe message formats for the SecurityAccess ‘ requestSeed ’ primitives are detailed in the following tables:\nTable 18\nSecurityAccess request — requestSeed message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nSecurityAccess request service Id\n27\nSA\n#6\naccessType — requestSeed\n7D\nAT_RSD\n#7\nChecksum\n00-FF\nCS\nTable 19\nSecurityAccess — requestSeed positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n04\nLEN\n#5\nSecurityAccess positive response service Id\n67\nSAPR\n#6\naccessType — requestSeed\n7D\nAT_RSD\n#7\nSeed High\n00-FF\nSEEDH\n#8\nSeed Low\n00-FF\nSEEDL\n#9\nChecksum\n00-FF\nCS\nTable 20\nSecurityAccess negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegativeResponse Service Id\n7F\nNR\n#6\nSecurityAccess request service Id\n27\nSA\n#7\nresponseCode = (conditionsNotCorrectOrRequestSequenceError\nincorrectMessageLength)\n22\n13\nRC_CNC\nRC_IML\n#8\nChecksum\n00-FF\nCS\n5.2.3.\nMessage format — SecurityAccess — sendKey\nThe message formats for the SecurityAccess ‘ sendKey ’ primitives are detailed in the following tables:\nTable 21\nSecurityAccess request — sendKey message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\nm+2\nLEN\n#5\nSecurityAccess Request Service Id\n27\nSA\n#6\naccessType — sendKey\n7E\nAT_SK\n#7 to #m+6\nKey #1 (High)\n…\nKey #m (low, m must be a minimum of 4, and a maximum of 8)\nxx\n…\nxx\nKEY\n#m+7\nChecksum\n00-FF\nCS\nTable 22\nSecurityAccess — sendKey positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n02\nLEN\n#5\nSecurityAccess positive response service Id\n67\nSAPR\n#6\naccessType — sendKey\n7E\nAT_SK\n#7\nChecksum\n00-FF\nCS\nTable 23\nSecurityAccess negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegativeResponse Service Id\n7F\nNR\n#6\nSecurityAccess request service Id\n27\nSA\n#7\nResponseCode = (generalReject\nsubFunctionNotSupported\nincorrectMessageLength\nconditionsNotCorrectOrRequestSequenceError\ninvalidKey\nexceededNumberOfAttempts\nrequestCorrectlyReceived-ResponsePending)\n10\n12\n13\n22\n35\n36\n78\nRC_GR\nRC_SFNS\nRC_IML\nRC_CNC\nRC_IK\nRC_ENA\nRC_RCR_RP\n#8\nChecksum\n00-FF\nCS\n6.\nDATA TRANSMISSION SERVICES\nThe services available are detailed in the following table:\nTable 24\nData transmission services\nService name\nDescription\nReadDataByIdentifier\nThe client requests the transmission of the current value of a record with access by recordDataIdentifier\nWriteDataByIdentifier\nThe client requests to write a record accessed by recordDataIdentifier\n6.1.\nReadDataByIdentifier service\n6.1.1.\nMessage description\nThe 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.\n6.1.2.\nMessage format\nThe message formats for the ReadDataByIdentifier primitives are detailed in the following tables:\nTable 25\nReadDataByIdentifier request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nReadDataByIdentifier Request Service Id\n22\nRDBI\n#6 and #7\nrecordDataIdentifier = (a valor from Table 28)\nxxxx\nRDI_ …\n#8\nChecksum\n00-FF\nCS\nTable 26\nReadDataByIdentifier positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\nm+3\nLEN\n#5\nReadDataByIdentifier Positive Response Service Id\n62\nRDBIPR\n#6 and #7\nrecordDataIdentifier = (the same value as bytes #6 and #7 Table 25)\nxxxx\nRDI_ …\n#8 to #m+7\ndataRecord() = (data#1\n:\ndata#m)\nxx\n:\nxx\nDREC_DATA1\n:\nDREC_DATAm\n#m+8\nChecksum\n00-FF\nCS\nTable 27\nReadDataByIdentifier negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegativeResponse Service Id\n7F\nNR\n#6\nReadDataByIdentifier Request Service Id\n22\nRDBI\n#7\nResponseCode = (requestOutOfRange\nincorrectMessageLength\nconditionsNotCorrect)\n31\n13\n22\nRC_ROOR\nRC_IML\nRC_CNC\n#8\nChecksum\n00-FF\nCS\n6.1.3.\nParameter definition\nThe parameter recordDataIdentifier (RDI_) in the ReadDataByIdentifier request message identifies a data record.\nrecordDataIdentifier values defined by this document are shown in the table below.\nThe recordDataIdentifier table consists of four columns and multiple lines.\nThe first column (Hex) includes the ‘ hex value ’ assigned to the recordDataIdentifier specified in the third column.\nThe second column (Data element) specifies the data element of Appendix 1 on which the recordDataIdentifier is based (transcoding is sometimes necessary).\nThe third column (Description) specifies the corresponding recordDataIdentifier name.\nThe fourth column (Mnemonic) specifies the mnemonic of this recordDataIdentifier.\nTable 28\nDefinition of recordDataIdentifier values\nHex\nData element\nrecordDataIdentifier Name (see format in Section 8.2)\nMnemonic\nF90B\nCurrentDateTime\nTimeDate\nRDI_TD\nF912\nHighResOdometer\nHighResolutionTotalVehicleDistance\nRDI_HRTVD\nF918\nK-ConstantOfRecordingEquipment\nKfactor\nRDI_KF\nF91C\nL-TyreCircumference\nLfactorTyreCircumference\nRDI_LF\nF91D\nW-VehicleCharacteristicConstant\nWvehicleCharacteristicFactor\nRDI_WVCF\nF921\nTyreSize\nTyreSize\nRDI_TS\nF922\nnextCalibrationDate\nNextCalibrationDate\nRDI_NCD\nF92C\nSpeedAuthorised\nSpeedAuthorised\nRDI_SA\nF97D\nvehicleRegistrationNation\nRegisteringMemberState\nRDI_RMS\nF97E\nVehicleRegistrationNumber\nVehicleRegistrationNumber\nRDI_VRN\nF190\nVehicleIdentificationNumber\nVIN\nRDI_VIN\nThe parameter dataRecord (DREC_) is used by the ReadDataByIdentifier positive 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.\n6.2.\nWriteDataByIdentifier service\n6.2.1.\nMessage description\nThe 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.\n6.2.2.\nMessage format\nThe message formats for the WriteDataByIdentifier primitives are detailed in the following tables:\nTable 29\nWriteDataByIdentifier request message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\nm+3\nLEN\n#5\nWriteDataByIdentifier request service Id\n2E\nWDBI\n#6 and #7\nrecordDataIdentifier = (a value from Table 28)\nxxxx\nRDI_ …\n#8 to #m+7\ndataRecord() = (data#1\n:\ndata#m)\nxx\n:\nxx\nDREC_DATA1\n:\nDREC_DATAm\n#m+8\nChecksum\n00-FF\nCS\nTable 30\nWriteDataByIdentifier positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nWriteDataByIdentifier positive response service Id\n6E\nWDBIPR\n#6 and #7\nrecordDataIdentifier = (the same value as bytes #6 and #7 Table 29)\nxxxx\nRDI_ …\n#8\nChecksum\n00-FF\nCS\nTable 31\nWriteDataByIdentifier negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nNegativeResponse Service Id\n7F\nNR\n#6\nWriteDataByIdentifier request service Id\n2E\nWDBI\n#7\nResponseCode = (requestOutOfRange\nincorrectMessageLength\nconditionsNotCorrect)\n31\n13\n22\nRC_ROOR\nRC_IML\nRC_CNC\n#8\nChecksum\n00-FF\nCS\n6.2.3.\nParameter definition\nThe parameter recordDataIdentifier (RDI_) is defined in Table 28.\nThe parameter dataRecord (DREC_) is used by the WriteDataByIdentifier request message to provide the data record values identified by the recordDataIdentifier to the server (VU). Data formats are specified in Section 8.\n7.\nCONTROL OF TEST PULSES — INPUT/OUTPUT CONTROL FUNCTIONAL UNIT\nThe services available are detailed in the following table:\nTable 32\nInput/Output control functional unit\nService name\nDescription\nInputOutputControlByIdentifier\nThe client requests the control of an input/output specific to the server\n7.1.\nMessage description\n7.1.1.\nMessage description\nThere is a connection via the front connector which allows test pulses to be controlled or monitored using a suitable tester.\nThis 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:\ndisabled,\nspeedSignalInput, where the calibration I/O signal line is used to input a speed signal (test signal) replacing the motion sensor speed signal,\nrealTimeSpeedSignalOutputSensor, where the calibration I/O signal line is used to output the speed signal of the motion sensor,\nRTCOutput, where the calibration I/O signal line is used to output the UTC clock signal.\nThe vehicle unit must have entered an adjustment session and must be in CALIBRATION 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 calibration I/O signal line is returned to the ‘ disabled ’ (default) state.\nIf 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.\nThe sequence shall be:\nestablish communications by StartCommunication Service\nenter an adjustment session by StartDiagnosticSession Service and be in CALIBRATION mode of operation (the order of these two operations is not important).\nchange the state of the output by InputOutputControlByIdentifier Service.\n7.1.2.\nMessage format\nThe message formats for the InputOutputControlByIdentifier primitives are detailed in the following tables:\nTable 33\nInputOutputControlByIdentifier request message\nNote: The controlState parameter is present only in some cases (see 7.1.3).\nByte #\nParameter name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\nEE\nTGT\n#3\nSource address byte\ntt\nSRC\n#4\nAdditional length byte\nxx\nLEN\n#5\nInputOutputControlByIdentifier request Sid\n2F\nIOCBI\n#6 and #7\nInputOutputIdentifier = (CalibrationInputOutput)\nF960\nIOI_CIO\n#8 or #8 to #9\nControlOptionRecord = (\ninputOutputControlParameter — one value from Table 36\ncontrolState — one value from Table 38 (see note below))\nxx\nxx\nCOR_ …\nIOCP_ …\nCS_ …\n#9 or #10\nChecksum\n00-FF\nCS\nTable 34\nInputOutputControlByIdentifier positive response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\nxx\nLEN\n#5\ninputOutputControlByIdentifier positive response SId\n6F\nIOCBIPR\n#6 and #7\ninputOutputIdentifier = (CalibrationInputOutput)\nF960\nIOI_CIO\n#8 or #8 to #9\ncontrolStatusRecord = (\ninputOutputControlParameter (same value as byte #8 Table 33)\ncontrolState (same value as byte #9 Table 33)) (if applicable)\nxx\nxx\nCSR_\nIOCP_ …\nCS_ …\n#9 or #10\nChecksum\n00-FF\nCS\nTable 35\nInputOutputControlByIdentifier negative response message\nByte #\nParameter Name\nHex value\nMnemonic\n#1\nFormat byte — physical addressing\n80\nFMT\n#2\nTarget address byte\ntt\nTGT\n#3\nSource address byte\nEE\nSRC\n#4\nAdditional length byte\n03\nLEN\n#5\nnegativeResponse Service Id\n7F\nNR\n#6\ninputOutputControlByIdentifier request SId\n2F\nIOCBI\n#7\nresponseCode = (\nincorrectMessageLength\nconditionsNotCorrect\nrequestOutOfRange\ndeviceControlLimitsExceeded)\n13\n22\n31\n7A\nRC_IML\nRC_CNC\nRC_ROOR\nRC_DCLE\n#8\nChecksum\n00-FF\nCS\n7.1.3.\nParameter definition\nThe parameter inputOutputControlParameter (IOCP_) is defined in the following table:\nTable 36\nDefinition of inputOutputControlParameter values\nHex\nDescription\nMnemonic\n00\nReturnControlToECU\nThis value shall indicate to the server (VU) that the tester does no longer have control about the calibration I/O signal line.\nRCTECU\n01\nResetToDefault\nThis value shall indicate to the server (VU) that it is requested to reset the calibration I/O signal line to its default state.\nRTD\n03\nShortTermAdjustment\nThis 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.\nSTA\nThe parameter controlState is present only when the inputOutputControlParameter is set to ShortTermAdjustment and is defined in the following table:\nTable 37\nDefinition of controlState values\nMode\nHex value\nDescription\nDisable\n00\nI/O line is disabled (default state)\nEnable\n01\nEnable calibration I/O line as speedSignalInput\nEnable\n02\nEnable calibration I/O line as realTimeSpeedSignalOutputSensor\nEnable\n03\nEnable calibration I/O line as RTCOutput\n8.\nDATARECORDS FORMATS\nThis section details:\ngeneral rules that shall be applied to ranges of parameters transmitted by the vehicle unit to the tester,\nformats that shall be used for data transferred via the Data Transmission Services described in Section 6.\nAll parameters identified shall be supported by the VU.\nData 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).\n8.1.\nTransmitted parameter ranges\nTable 38 defines the ranges used to determine the validity of a transmitted parameter.\nThe 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.\nThe values in the range ‘ not available ’ provide a means for the vehicle unit to transmit a message which contains a parameter that is not available or not supported in that module. The values in the range ‘ not requested ’ provide a means for a device to transmit a command message and identify those parameters where no response is expected from the receiving device.\nIf a component failure prevents the transmission of valid data for a parameter, the error indicator as described in Table 38 should be used in place of that parameter's data. However, if the measured or calculated data has yielded a value that is valid yet exceeds the defined parameter range, the error indicator should not be used. The data should be transmitted using the appropriate minimum or maximum parameter value.\nTable 38\ndataRecords ranges\nRange Name\n1 byte (Hex value)\n2 bytes (Hex value)\n4 bytes (Hex value)\nASCII\nValid signal\n00 to FA\n0000 to FAFF\n00000000 to FAFFFFFF\n1 to 254\nParameter specific indicator\nFB\nFB00 to FBFF\nFB000000 to FBFFFFFF\nnone\nReserved range for future indicator bits\nFC to FD\nFC00 to FDFF\nFC000000 to FDFFFFFF\nnone\nError indicator\nFE\nFE00 to FEFF\nFE000000 to FEFFFFFF\n0\nNot available or not requested\nFF\nFF00 to FFFF\nFF000000 to FFFFFFFF\nFF\nFor parameters coded in ASCII, the ASCII character ‘ * ’ is reserved as a delimiter.\n8.2.\ndataRecords formats\nTable 40 to Table 44 below detail the formats that shall be used via the ReadDataByIdentifier and WriteDataByIdentifier Services.\nTable 40 provides the length, resolution and operating range for each parameter identified by its recordDataIdentifier:\nTable 39\nFormat of dataRecords\nParameter Name\nData length (bytes)\nResolution\nOperating range\nTimeDate\n8\nSee details in Table 40\nHighResolutionTotalVehicleDistance\n4\n5 m/bit gain, 0 m offset\n0 to + 21 055 406 km\nKfactor\n2\n0,001 pulse/m/bit gain, offset 0\n0 to 64,255 pulse/m\nLfactorTyreCircumference\n2\n0,125 10 -3 /bit gain, 0 offset\n0 to 8 031 m\nWvehicleCharacteristicFactor\n2\n0,001 pulse/m/bit gain, 0 offset\n0 to 64,255 pulse/m\nTyreSize\n15\nASCII\nASCII\nNextCalibrationDate\n3\nSee details in Table 41\nSpeedAuthorised\n2\n1/256 km/h/bit gain, 0 offset\n0 to 250 996 km/h\nRegisteringMemberState\n3\nASCII\nASCII\nVehicleRegistrationNumber\n14\nSee details in Table 44\nVIN\n17\nASCII\nASCII\nTable 40 details the formats of the different bytes of the TimeDate parameter:\nTable 40\nDetailed format of TimeDate (recordDataIdentifier value # F00B)\nByte\nParameter definition\nResolution\nOperating range\n1\nSeconds\n0,25 s/bit gain, 0 s offset\n0 to 59,75 s\n2\nMinutes\n1 min/bit gain, 0 min offset\n0 to 59 min\n3\nHours\n1 h/bit gain, 0 h offset\n0 to 23 h\n4\nMonth\n1 month/bit gain, 0 month offset\n1 toa 12 month\n5\nDay\n0,25 day/bit gain, 0 day offset (see Note below Table 41)\n0,25 to 31,75 day\n6\nYear\n1 year/bit gain, +1985 year offset (see Note below Table 41)\n1985 to 2235 year\n7\nLocal Minute Offset\n1 min/bit gain, - 125 min offset\n- 59 to 59 min\n8\nLocal Hour Offset\n1 h/bit gain, - 125 offset\n- 23 to + 23 h\nTable 41 details the formats of the different bytes of the NextCalibrationDate parameter:\nTable 41\nDetailed format of NextCalibrationDate (recordDataIdentifier value # F022)\nNote conerning the use of the ‘ Day ’ parameter:\n1.. 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.\n2.. This parameter does not influence or change the hours parameter above.\nNote concerning the use of byte ‘ Year ’ parameter:\nA value of 0 for the year identifies the year 1985; a value of 1 identifies 1986; etc.\nByte\nParameter definition\nResolution\nOperating range\n1\nMonth\n1 month/bit gain, 0 month offset\n1 to 12 month\n2\nDay\n0,25 day/bit gain, 0 day offset (see Note below)\n0,25 to 31,75 day\n3\nYear\n1 Year/bit gain, +1985 year offset (see Note below)\n1985 to 2235 year\nTable 42 details the formats of the different bytes of the VehicleRegistrationNumber parameter:\nTable 42\nDetailed format of VehicleRegistrationNumber (recordDataIdentifier value # F07E)\nByte\nParameter definition\nResolution\nOperating range\n1\nCode Page (as defined in Appendix 1)\nASCII\n01 to 0A\n2 to 14\nVehicle Registration Number (as defined in Appendix 1)\nASCII\nASCII\nAppendix 9\nTYPE APPROVAL — LIST OF MINIMUM REQUIRED TESTS\n1.\nINTRODUCTION\n1.1.\nType approval\nThe EEC type approval for a recording equipment (or component) or a tachograph card is based on:\na security certification, performed by an ITSEC authority, against a security target fully compliant with Appendix 10 to this Annex,\na functional certification performed by a Member State authority certifying that the item tested fulfils the requirements of this Annex in terms of functions performed, measurement accuracy and environmental characteristics,\nan 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).\nThis 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.\nThe 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 information, 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.\nThis 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.\n1.2.\nReferences\nThe following references are used in this Appendix:\nIEC 68-2-1 Environmental testing — Part 2: Tests — Tests A: Cold. 1990 + Amendment 2: 1994.\nIEC 68-2-2 Environmental testing — Part 2: Tests — Tests B: Dry heat. 1974 + Amendment 2: 1994.\nIEC 68-2-6 Basic environmental testing procedures — Test methods — Test Fc and guidance: Vibration (sinusoidal). 6th edition: 1985.\nIEC 68-2-14 Basic environmental testing procedures — Test methods — Test N: Change of temperature. Modification 1: 1986.\nIEC 68-2-27 Basic environmental testing procedures — Test methods — Test Ea and guidance: Shock. Edition 3: 1987.\nIEC 68-2-30 Basic environmental testing procedures — Test methods — Test Db and guidance: Damp heat, cyclic (12 + 12 — hour cycle). Modification 1: 1985.\nIEC 68-2-35 Basic environmental testing procedure — Test methods — Test Fda: Random vibration wide band — Reproductibility High. Modification 1: 1983.\nIEC 529 Degrees of protection provided by enclosures (IP code). Edition 2: 1989.\nIEC 61000-4-2 Electromagnetic Compatibility (EMC) — Testing and measurement techniques — Electrostatic discharge immunity test: 1995/Amendment 1: 1998.\nISO 7637-1 Road vehicles — Electrical disturbance by conduction and coupling — Part 1: Passenger cars and light commercial vehicles with nominal 12 V supply voltage — Electrical transient conduction along supply lines only. Edition 2: 1990.\nISO 7637-2 Road vehicles — Electrical disturbance by conduction and coupling — Part 1: Passenger cars and light commercial vehicles with nominal 12 V supply voltage — Electrical transient conduction along supply lines only. Edition 2: 1990.\nISO 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 and inductive coupling via lines other than supply lines. First Edition: 1995 + Cor 1: 1995.\nISO/IEC 7816-1 Identification cards — Integrated circuit(s) cards with contacts — Part 1: Physical characteristics. First edition: 1998.\nISO/IEC 7816-2 Information technology — Identification cards — Integrated circuit(s) cards with contacts — Part 2: Dimensions and location of the contacts. First edition: 1999.\nISO/IEC 7816-3 Information technology — Identification cards — Integrated circuit(s) cards with contacts — Part 3: Electronic signals and transmission protocol. Edition 2: 1997.\nISO/IEC 10373 Identification cards — Test methods. First edition: 1993.\n2.\nVEHICLE UNIT FUNCTIONAL TESTS\nNo\nTest\nDescription\nRelated requirements\n1.\nAdministrative examination\n1.1.\nDocumentation\nCorrectness of documentation\n1.2.\nManufacturer test results\nResults of manufacturer test performed during integration. Paper demonstrations\n070, 071, 073\n2.\nVisual inspection\n2.1.\nCompliance with documentation\n2.2.\nIdentification/markings\n168, 169\n2.3.\nMaterials\n163 to 167\n2.4\nSealing\n251\n2.5.\nExternal interfaces\n3.\nFunctional tests\n3.1.\nFunctions provided\n002, 004, 244\n3.2.\nModes of operation\n006*, 007*, 008*, 009*, 106, 107\n3.3.\nFunctions and data access rights\n010*, 011*, 240, 246, 247\n3.4.\nMonitoring cards insertion and withdrawal\n013, 014, 015*, 016*, 106\n3.5.\nSpeed and distance measurement\n017 to 026\n3.6.\nTime measurement (test performed at 20 o C)\n027 to 032\n3.7.\nMonitoring driver activities\n033 to 043, 106\n3.8.\nMonitoring driving status\n044, 045, 106\n3.9.\nManual entries\n046 to 050b\n3.10.\nCompany locks management\n051 to 055\n3.11.\nMonitoring control activities\n056, 057\n3.12.\nDetection of events and/or faults\n059 to 069, 106\n3.13.\nEquipment identification data\n075*, 076*, 079\n3.14.\nDriver card insertion and withdrawal data\n081* to 083*\n3.15.\nDriver activity data\n084* to 086*\n3.16.\nPlaces data\n087* to 089*\n3.17.\nOdometer data\n090* to 092*\n3.18.\nDetailed speed data\n093*\n3.19.\nEvents data\n094*, 095\n3.20.\nFaults data\n096*\n3.21.\nCalibration data\n097*, 098*\n3.22.\nTime adjustment data\n100*, 101*\n3.23.\nControl activity data\n102*, 103*\n3.24.\nCompany locks data\n104*\n3.25.\nDownload activity data\n105*\n3.26.\nSpecific conditions data\n105a*, 105b*\n3.27.\nRecording and storing on tachographs cards\n108, 109*, 109a*, 110*, 111, 112\n3.28.\nDisplaying\n072, 106, 113 to 128, PIC_001, DIS_001\n3.29.\nPrinting\n072, 106, 129 to 138, PIC_001, PRT_001 to PRT_012\n3.30.\nWarning\n106, 139 to 148, PIC_001\n3.31.\nData downloading to external media\n072, 106, 149 to 151\n3.32.\nOutput data to additional external devices\n152, 153\n3.33.\nCalibration\n154*, 155*, 156*, 245\n3.34.\nTime adjustment\n157*, 158*\n3.35.\nNon-interference of additional functions\n003, 269\n4.\nEnvironmental tests\n4.1.\nTemperature\nVerify functionality through:\nIEC 68-2-1, test Ad, with a test duration of 72 hours at the lower temperature (− 20 o C), 1 hour operating, 1 hour non operating,\nIEC 68-2-2, test Bd, with a test duration of 72 hours at the higher temperature (+ 70 o C), 1 hour operating, 1 hour non operating\nTemperature cycles: verify that the vehicle unit can withstand rapid changes in the environment temperature through IEC 68-2-14 test Na, 20 cycles, each with temperature varying from the lower temperature (− 20 o C) to the higher temperature (+ 70 o C) and a 2 hours stay at both the lower and the higher temperature\nA reduced set of tests (among those defined in section 3 of this table) can be carried out at the lower temperature, the higher temperature and during the temperature cycles\n159\n4.2.\nHumidity\nVerify that the vehicle unit can withstand a cyclic damp (heat test) through IEC 68-2-30, test Db, six 24 hours cycles, each temperature varying from + 25 o C to + 55 o C and a relative humidity of 97 % at + 25 o C and equal to 93 % at + 55 o C\n160\n4.3.\nVibration\n1.. Sinusoidal vibrations:\nverify that the vehicle unit can withstand sinusoidal vibrations with the following characteristics:\nconstant displacement between 5 and 11 Hz: 10 mm peak\nconstant acceleration between 11 and 300 Hz: 5 g\nThis requirement is verified through IEC 68-2-6, test Fc, with a minimum test duration of 3 × 12 hours (12 hours per axis)\n2.. Random vibrations:\nverify that the vehicle unit can withstand random vibrations with the following characteristics:\nfrequency 5-150 Hz, level 0,02 g 2 /Hz\nThis 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 operating\nThe two tests described above are performed on two different samples of the equipment type being tested\n163\n4.4.\nProtection against water and foreign bodies\nVerify that the vehicle unit protection index according to IEC 529 is at least IP 40, when mounted in operating conditions in a vehicle\n164, 165\n4.5.\nOver-voltage protection\nVerify that the vehicle unit can withstand a power supply of:\n24V versions: 34 V at + 40 o C 1 hour\n12V versions: 17 V at + 40 o C 1 hour\n161\n4.6.\nReverse polarity protection\nVerify that the vehicle unit can withstand an inversion of its power supply\n161\n4.7.\nShort-circuit protection\nVerify that input output signals are protected against short circuits to power supply and ground\n161\n5.\nEMC tests\n5.1.\nRadiated emissions and susceptibility\nCompliance with Directive 95/54/EEC\n162\n5.2.\nElectrostatic discharge\nCompliance with IEC 61000-4-2, ± 2 kV (level 1)\n162\n5.3.\nConducted transient susceptibility on power supply\nFor 24V versions: compliance with ISO 7637-2:\npulse 1a: Vs = − 100 V, Ri = 10 ohms\npulse 2: Vs = + 100 V, Ri = 10 ohms\npulse 3a: Vs = − 100 V, Ri = 50 ohms\npulse 3b: Vs = + 100 V, Ri = 50 ohms\npulse 4: Vs = − 16 V Va = − 12 V, t6=100 ms\npulse 5: Vs = + 120 V, Ri = 2,2 ohms, td = 250 ms\nFor 12V versions: compliance with ISO 7637-1:\npulse 1: Vs = − 100 V, Ri = 10 ohms\npulse 2: Vs = + 100 V, Ri = 10 ohms\npulse 3a: Vs = − 100 V, Ri = 50 ohms\npulse 3b: Vs = + 100 V, Ri = 50 ohms\npulse 4: Vs = − 6 V, Va = − 5 V, t6 = 15 ms\npulse 5: Vs = + 65 V, Ri = 3 ohms, td = 100 ms\nPulse 5 shall be tested only for vehicle units designed to be installed in vehicles for which no external common protection against load dump is implemented\n162\n3.\nMOTION SENSOR FUNCTIONAL TESTS\nNo\nTest\nDescription\nRelated requirements\n1.\nAdministrative examination\n1.1.\nDocumentation\nCorrectness of documentation\n2.\nVisual inspection\n2.1.\nCompliance with documentation\n2.2.\nIdentification/markings\n169, 170\n2.3.\nMaterials\n163 to 167\n2.4.\nSealing\n251\n3.\nFunctional tests\n3.1.\nSensor identification data\n077*\n3.2.\nMotion sensor — vehicle unit pairing\n099*, 155\n3.3.\nMotion detection\nMotion measurement accuracy\n022 to 026\n4.\nEnvironmental tests\n4.1.\nOperating temperature\nVerify functionality (as defined in test No 3.3) in temperature range [− 40 o C; + 135 o C] through:\nIEC 68-2-1 test Ad, with a test duration of 96 hours at the lowest temperature To min\nIEC 68-2-2 test Bd, with a test duration of 96 hours at the highest temperature To max\n159\n4.2.\nTemperature cycles\nVerify 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 o C) to the higher temperature (+135 o C) and a 2 hours stay at both the lower and the higher temperature\nA 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 cycles\n159\n4.3.\nHumidity cycles\nVerify functionality (as defined in test No 3.3) through IEC 68-2-30, test Db, six 24 hours cycles, each temperature varying from + 25 o C to + 55 o C and a relative humidity of 97 % at + 25 o C and equal to 93 % at + 55 o C\n160\n4.4.\nVibration\nVerify functionality (as defined in test No 3.3) through IEC 68-2-6, test Fc, with a test duration of 100 frequency cycles:\nconstant displacement between 10 and 57 Hz: 1,5 mm peak constant accelaration between 57 and 500 Hz: 20 g\n163\n4.5.\nMechanical shock\nVerify functionality (as defined in test No 3.3) through IEC 68-2-27, test Ea, 3 shocks in both directions of the 3 perpendicular axes\n163\n4.6.\nProtection against water and foreign bodies\nVerify that the motion sensor protection index according to IEC 529 is at least IP 64, when mounted in operating conditions in a vehicle\n165\n4.7.\nReverse polarity protection\nVerify that the motion sensor can withstand an inversion of its power supply\n161\n4.8.\nShort circuit protection\nVerify that input output signals are protected against short circuits to power supply and ground\n161\n5.\nEMC\n5.1.\nRadiated emissions and susceptibility\nVerify compliance with Directive 95/54/EEC\n162\n5.2.\nElectrostatic discharge\nCompliance with IEC 61000-4-2, ± 2 kV (level 1)\n162\n5.3.\nConducted transient susceptibility on data lines)\nCompliance with ISO 7637-3 (level III)\n162\n4.\nTACHOGRAPH CARDS FUNCTIONAL TESTS\nNo\nTest\nDescription\nRelated requirements\n1.\nAdministrative examination\n1.1.\nDocumentation\nCorrectness of documentation\n2.\nVisual inspection\n2.1.\nMake sure that all features for protection and visible data are correctly printed on the card and compliant\n171 to 181\n3.\nPhysical tests\n3.1.\nCheck dimension of the card and location of the contacts\n184\nISO/IEC 7816-1\nISO/IEC 7816-2\n4.\nProtocol tests\n4.1.\nATR\nCheck that the ATR is compliant\nISO/IEC 7816-3\nTCS 304, 307, 308\n4.2.\nT=0\nCheck that T=0 protocol is compliant\nISO/IEC 7816-3\nTCS 302, 303, 305\n4.3.\nPTS\nCheck that the PTS command is compliant by setting T=1 from T=0\nISO/IEC 7816-3\nTCS 309 to 311\n4.4.\nT=1\nCheck that T=1 protocol is compliant\nISO/IEC 7816-3\nTCS 303, / 306\n5.\nCard structure\n5.1.\nTest that the file structure of the card is compliant by checking the presence of the mandatory files in the card and their access conditions\nTCS 312\nTCS 400*, 401, 402, 403*, 404, 405*, 406, 407, 408*, 409, 410*, 411, 412, 413*, 414, 415*, 416, 417, 418*, 419\n6.\nFunctional tests\n6.1.\nNormal processing\nTest 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)\nCheck that the operations have actually been performed in the card (ex: by reading the file the command has been performed on)\nTCS 313 to TCS 379\n6.2.\nError messages\nTest at least once each error message (as specified in Appendix 2) for each command\nTest at least once every generic error (except ′6400′ integrity errors checked during security certification)\n7.\nEnvironmental tests\n7.1.\nMake sure that the cards work within the limit conditions defined in accordance with ISO/IEC 10373\n185 to 188\nISO/IEC 7816-1\n5.\nINTEROPERABILITY TESTS\nNo\nTest\nDescription\n1.\nMutual authentication\nCheck that the mutual authentication between the vehicle unit and the tachograph card runs normally\n2.\nWrite/read tests\nExecute a typical activity scenario on the vehicle unit. The scenario shall be adapted to the type of card being tested and involve writings in as many EFs as possible in the card\nVerify through a card downloading that all corresponding recordings have been properly made\nVerify through a card daily printout that all corresponding recordings can be properly read\nAppendix 10\nGENERIC SECURITY TARGETS\nThis appendix specifies the minimum required content of motion sensor, vehicle unit and tachograph card security targets.\nIn 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.\nMOTION SENSOR GENERIC SECURITY TARGET\n1.\nIntroduction\nThis 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.\nRequirements 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.\nAnnex I B body requirements not referred by security targets are not the subject of security enforcing functions.\nUnique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.\n2.\nAbbreviations, definitions and references\n2.1.\nAbbreviations\nROM Read only Memory\nSEF Security enforcing function\nTBD To be defined\nTOE Target of evaluation\nVU Vehicle unit.\n2.2.\nDefinitions\nDigital Tachograph Recording equipment\nEntity A device connected to the motion sensor\nMotion data The data exchanged with the VU, representative of speed and distance travelled\nPhysically 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\nSecurity data The specific data needed to support security enforcing functions (e.g. crypto keys)\nSystem Equipment, people or organisations, involved in any way with the recording equipment\nUser A human user of the motion sensor (when not used in the expression ‘ user data ’ )\nUser data Any data, other than motion or security data, recorded or stored by the motion sensor.\n2.3.\nReferences\nITSEC ITSEC Information Technology Security Evaluation Criteria 1991.\n3.\nProduct rationale\n3.1.\nMotion sensor description and method of use\nThe 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.\nThe 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.\nIn its operational mode, the motion sensor is connected to a VU.\nIt may also be connected to specific equipment for management purposes (TBD by manufacturer).\nThe typical motion sensor is described in the following figure:\n3.2.\nMotion sensor life cycle\nThe typical life cycle of the motion sensor is described in the following figure:\n3.3.\nThreats\nThis paragraph describes the threats the motion sensor may face.\n3.3.1.\nThreats to access control policies\nT.Access Users could try to access functions not allowed to them.\n3.3.2.\nDesign related threats\nT.Faults Faults in hardware, software, communication procedures could place the motion sensor in unforeseen conditions compromising its security\nT.Tests The use of non invalidated test modes or of existing back doors could compromise the motion sensor security\nT.Design Users could try to gain illicit knowledge of design either from manufacturer's material (through theft, bribery, …) or from reverse engineering.\n3.3.3.\nOperation oriented threats\nT.Environment Users could compromise the motion sensor security through environmental attacks (thermal, electromagnetic, optical, chemical, mechanical, …)\nT.Hardware Users could try to modify motion sensor hardware\nT.Mechanical_Origin Users could try to manipulate the motion sensor input (e.g. unscrewing from gearbox, …)\nT.Motion_Data Users could try to modify the vehicle's motion data (addition, modification, deletion, replay of signal)\nT.Power_Supply Users could try to defeat the motion sensor security objectives by modifying (cutting, reducing, increasing) its power supply\nT.Security_Data Users could try to gain illicit knowledge of security data during security data generation or transport or storage in the equipment\nT.Software Users could try to modify motion sensor software\nT.Stored_Data Users could try to modify stored data (security or user data).\n3.4.\nSecurity objectives\nThe main security objective of the digital tachograph system is the following:\nO.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\nTherefore the security objective of the motion sensor, contributing to the global security objective, is:\nO.Sensor_Main The data transmitted by the motion sensor must be available to the VU so as to allow the VU to determine fully and accurately the movement of the vehicle in terms of speed and distance travelled.\n3.5.\nInformation technology security objectives\nThe specific IT security objectives of the motion sensor contributing to its main security objective, are the following:\nO.Access The motion sensor must control connected entities' access to functions and data\nO.Audit The motion sensor must audit attempts to undermine its security and should trace them to associated entities\nO.Authentication The motion sensor must authenticate connected entities\nO.Processing The motion sensor must ensure that processing of input to derive motion data is accurate\nO.Reliability The motion sensor must provide a reliable service\nO.Secured_Data_Exchange The motion sensor must secure data exchanges with the VU.\n3.6.\nPhysical, personnel or procedural means\nThis paragraph describes physical, personnel or procedural requirements that contribute to the security of the motion sensor.\n3.6.1.\nEquipment design\nM.Development Motion sensor developers must ensure that the assignment of responsibilities during development is done in a manner which maintains IT security\nM.Manufacturing Motion sensor 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 motion sensor is protected from physical attacks which might compromise IT security.\n3.6.2.\nEquipment delivery\nM.Delivery Motion sensor manufacturers, vehicle manufacturers and fitters or workshops must ensure that handling of the motion sensor is done in a manner which maintains IT security.\n3.6.3.\nSecurity data generation and delivery\nM.Sec_Data_Generation Security data generation algorithms must be accessible to authorised and trusted persons only\nM.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 integrity.\n3.6.4.\nRecording equipment installation, calibration, and inspection\nM.Approved_Workshops Installation, calibration and repair of recording equipment must be carried by trusted and approved fitters or workshops\nM.Mechanical_Interface Means of detecting physical tampering with the mechanical interface must be provided (e.g. seals)\nM.Regular_Inpections Recording equipment must be periodically inspected and calibrated.\n3.6.5.\nLaw enforcement control\nM.Controls Law enforcement controls must be performed regularly and randomly, and must include security audits.\n3.6.6.\nSoftware upgrades\nM.Software_Upgrade Software revisions must be granted security certification before they can be implemented in a motion sensor.\n4.\nSecurity enforcing functions\n4.1.\nIdentification and authentication\nThe motion sensor shall be able to establish, for every interaction, the identity of any entity it is connected to.\nThe identity of a connected entity shall consist of:\nan entity group:\nVU,\nManagement device,\nOther,\nan entity ID (VU only).\nThe entity ID of a connected VU shall consist of the VU approval number and the VU serial number.\nThe motion sensor shall be able to authenticate any VU or management device it is connected to:\nat entity connection,\nat power supply recovery.\nThe motion sensor shall be able to periodically re-authenticate the VU it is connected to.\nThe motion sensor shall detect and prevent use of authentication data that has been copied and replayed.\nAfter (TBD by manufacturer and not more than 20) consecutive unsuccessful authentication attempts have been detected, the SEF shall:\ngenerate an audit record of the event,\nwarn the entity,\ncontinue to export motion data in a non secured mode.\n4.2.\nAccess control\nAccess controls ensure that information is read from, created in, or modified into the TOE only by those authorised to do so.\n4.2.1.\nAccess control policy\nThe motion sensor shall control access rights to function and data.\n4.2.2.\nData access rights\nThe motion sensor shall ensure that motion sensor identification data can be written once only (requirement 078).\nThe motion sensor shall accept and/or store user data from authenticated entities only.\nThe motion sensor shall enforce appropriate read and write access rights to security data.\n4.2.3.\nFile structure and access conditions\nApplication and data files structure and access conditions shall be created during the manufacturing process, and then locked from any future modification or deletion.\n4.3.\nAccountability\nThe motion sensor shall hold in its memory motion sensor identification data (requirement 077).\nThe motion sensor shall store in its memory installation data (requirement 099).\nThe motion sensor shall have a capability to output accountability data to authenticated entities at their request.\n4.4.\nAudit\nThe motion sensor shall, for events impairing its security, generate audit records of the events.\nThe events affecting the security of the motion sensor are the following:\nsecurity breach attempts,\nauthentication failure,\nstored data integrity error,\ninternal data transfer error,\nunauthorised case opening,\nhardware sabotage.\nsensor fault.\nAudit records shall include the following data:\ndate and time of the event,\ntype of event,\nconnected entity identity.\nwhen required data is not available, an appropriate default indication shall be given (TBD by manufacturer).\nThe 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.\nIn 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.\n4.5.\nAccuracy\n4.5.1.\nInformation flow control policy\nThe motion sensor shall ensure that motion data may only been processed and derived from sensor mechanical input.\n4.5.2.\nInternal data transfers\nThe requirements of this paragraph apply only if the motion sensor makes use of physically separated parts.\nIf data are transferred between physically separated parts of the motion sensor, the data shall be protected from modification.\nUpon 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.\n4.5.3.\nStored data integrity\nThe motion sensor shall check user data stored in its memory for integrity errors.\nUpon detection of a stored user data integrity error, the SEF shall generate an audit record.\n4.6.\nReliability of service\n4.6.1\nTests\nAll commands, actions, or test points, specific to the testing needs of the manufacturing phase shall be disabled or removed before the end of the manufacturing phase. It shall not be possible to restore them for later use.\nThe 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).\nUpon detection of an internal fault during self-test, the SEF shall generate an audit record (sensor fault).\n4.6.2.\nSoftware\nThere shall be no way to analyse or debug the motion sensor software in the field.\nInputs from external sources shall not be accepted as executable code.\n4.6.3.\nPhysical protection\nIf 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).\nIf 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).\nThe motion sensor shall detect specified (TBD by manufacturer) hardware sabotage.\nIn the case described above, the SEF shall generate an audit record and the motion sensor shall: (TBD by manufacturer).\n4.6.4.\nPower supply interruptions\nThe motion sensor shall preserve a secure state during power supply cut-off or variations.\n4.6.5.\nReset conditions\nIn 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.\n4.6.6.\nData availability\nThe motion sensor shall ensure that access to resources is obtained when required and that resources are not requested nor retained unnecessarily.\n4.6.7.\nMultiple applications\nIf 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.\n4.7.\nData exchange\nThe 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.\n4.8.\nCryptographic support\nThe requirements of this paragraph are applicable only where needed, depending upon security mechanisms used and upon the manufacturer's solutions.\nAny cryptographic operation performed by the motion sensor shall be in accordance with a specified algorithm and a specified key size.\nIf the motion sensor generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes.\nIf the motion sensor distributes cryptographic keys, it shall be in accordance with specified key distribution methods.\nIf the motion sensor accesses cryptographic keys, it shall be in accordance with specified cryptographic keys access methods.\nIf the motion sensor destroys cryptographic keys, it shall be in accordance with specified cryptographic keys destruction methods.\n5.\nDefinition of security mechanisms\nThe security mechanisms, fulfilling the motion sensor security enforcing functions, are defined by the motion sensor manufacturers.\n6.\nMinimum strength of security mechanisms\nThe minimum strength of the motion sensor security mechanisms is High, as defined in (ITSEC).\n7.\nLevel of assurance\nThe target level of assurance for the motion sensor is ITSEC level E3, as defined in (ITSEC).\n8.\nRationale\nThe following matrixes give a rationale for the SEFs by showing:\nwhich SEFs or means counteract which threats,\nwhich SEFs fulfil which IT security objectives.\nThreats\nIT Objectives\nAccess\nFaults\nTests\nDesign\nEnvironment\nHardware\nMechanical_Origin\nMotion_Data\nPower_Supply\nSecurity_Data\nSoftware\nStored_Data\nAccess\nAudit\nAuthentication\nProcessing\nReliability\nSecured_Data_Exchange\nPhysical Personnel Procedural means\nDevelopment\nx\nx\nx\nManufacturing\nx\nx\nDelivery\nx\nx\nx\nSecurity Data Generation\nx\nSecurity Data Transport\nx\nApproved Workshops\nx\nMechanical interface\nx\nRegular Inspection\nx\nx\nx\nx\nLaw enforcement controls\nx\nx\nx\nx\nx\nx\nSoftware Upgrades\nx\nSecurity Enforcing Functions\nIdentification and authentication\nUIA_101 Entities identification\nx\nx\nx\nx\nx\nUIA_102 Entities identity\nx\nx\nx\nUIA_103 VU identity\nx\nUIA_104 Entities authentication\nx\nx\nx\nx\nx\nUIA_105 re-authentication\nx\nx\nx\nx\nx\nUIA_106 Unforgeable authentication\nx\nx\nx\nx\nUIA_107 Authentication failure\nx\nx\nx\nAccess control\nACC_101 Access control policy\nx\nx\nx\nx\nACC_102 Motion sensor ID\nx\nx\nACC_103 User data\nx\nx\nACC_104 Security Data\nx\nx\nx\nACC_105 File structure and access conditions\nx\nx\nx\nx\nAccountability\nACT_101 Motion sensor ID data\nx\nACT_102 Pairing data\nx\nACT_103 Accountability data\nx\nAudit\nAUD_101 Audit records\nx\nAUD_102 Audit events list\nx\nx\nx\nx\nx\nAUD_103 Audit data\nx\nAUD_104 Audit tools\nx\nAUD_105 Audit records storage\nx\nAccuracy\nACR_101 Information flow control policy\nx\nx\nx\nACR_102 Internal transfers\nx\nx\nACR_103 Internal transfers\nx\nACR_104 Stored data integrity\nx\nx\nACR_105 Stored data integrity\nx\nx\nReliability\nRLB_101 Manufacturing tests\nx\nx\nx\nRLB_102 Self tests\nx\nx\nx\nx\nx\nRLB_103 Self tests\nx\nx\nx\nx\nRLB_104 Software analysis\nx\nx\nx\nRLB_105 Software input\nx\nx\nx\nRLB_106 Case opening\nx\nx\nx\nx\nx\nx\nx\nRLB_107 Hardware sabotage\nx\nx\nRLB_108 Hardware sabotage\nx\nx\nRLB_109 Power supply interruptions\nx\nx\nRLB_110 Reset\nx\nx\nRLB_111 Data Availability\nx\nx\nRLB_112 Multiple Applications\nx\nData exchange\nDEX_101 Secured motion data export\nx\nx\nCryptographic support\nCSP_101 Algorithms\nx\nx\nCSP_102 key generation\nx\nx\nCSP_103 key distribution\nx\nx\nCSP_104 key access\nx\nx\nCSP_105 key destruction\nx\nx\nVEHICLE UNIT GENERIC SECURITY TARGET\n1.\nIntroduction\nThis 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.\nRequirements 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.\nAnnex I B body requirements not referred by security targets are not the subject of security enforcing functions.\nUnique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.\n2.\nAbbreviations, definitions and references\n2.1.\nAbbreviations\nPIN Personal identification number\nROM Read only memory\nSEF Security enforcing function\nTBD To be defined\nTOE Target of evaluation\nVU Vehicle Unit.\n2.2.\nDefinitions\nDigital tachograph Recording equipment\nMotion data The data exchanged with the motion sensor, representative of speed and distance travelled\nPhysically separated parts Physical components of the VU that are distributed in the vehicle as opposed to physical components gathered into the VU casing\nSecurity data The specific data needed to support security enforcing functions (e.g. crypto keys)\nSystem Equipment, people or organisations, involved in any way with the recording equipment\nUser Users are to be understood as human user of the equipment. Normal users of the VU comprise drivers, controllers, workshops and companies\nUser data Any data, other than security data, recorded or stored by the VU, required by Chapter III.12.\n2.3.\nReferences\nITSEC ITSEC Information Technology Security Evaluation Criteria 1991.\n3.\nProduct rationale\n3.1.\nVehicle unit description and method of use\nThe 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.\nIt is connected to a motion sensor with which it exchanges vehicle's motion data.\nUsers identify themselves to the VU using tachograph cards.\nThe VU records and stores user activities data in its data memory, it also records user activities data in tachograph cards.\nThe VU outputs data to display, printer and external devices.\nThe vehicle unit's operational environment while installed in a vehicle is described in the following figure:\nThe VU general characteristics, functions and mode of operations are described in Chapter II of Annex I B.\nThe VU functional requirements are specified in Chapter III of Annex I B.\nThe typical VU is described in the following figure:\nIt must be noted that although the printer mechanism is part of the TOE, the paper document once produced is not.\n3.2.\nVehicle unit life cycle\nThe typical life cycle of the VU is described in the following figure:\n3.3.\nThreats\nThis paragraph describes the threats the VU may face.\n3.3.1.\nThreats to identification and access control policies\nT.Access Users could try to access functions not allowed to them (e.g. drivers gaining access to calibration function)\nT.Identification Users could try to use several identifications or no identification.\n3.3.2.\nDesign related threats\nT.Faults Faults in hardware, software, communication procedures could place the VU in unforeseen conditions compromising its security\nT.Tests The use of non invalidated test modes or of existing back doors could compromise the VU security\nT.Design Users could try to gain illicit knowledge of design either from manufacturer's material (through theft, bribery, …) or from reverse engineering\n3.3.3.\nOperation oriented threats\nT.Calibration_Parameters Users could try to use mis-calibrated equipment (through calibration data modification, or through organisational weaknesses)\nT.Card_Data_Exchange Users could try to modify data while exchanged between VU and tachograph cards (addition, modification, deletion, replay of signal)\nT.Clock Users could try to modify internal clock\nT.Environment Users could compromise the VU security through environmental attacks (thermal, electromagnetic, optical, chemical, mechanical, …)\nT.Fake_Devices Users could try to connect fake devices (motion sensor, smart cards) to the VU\nT.Hardware Users could try to modify VU hardware\nT.Motion_Data Users could try to modify the vehicle's motion data (addition, modification, deletion, replay of signal)\nT.Non_Activated Users could use non activated equipment\nT.Output_Data Users could try to modify data output (print, display or download)\nT.Power_Supply Users could try to defeat the VU security objectives by modifying (cutting, reducing, increasing) its power supply\nT.Security_Data Users could try to gain illicit knowledge of security data during security data generation or transport or storage in the equipment\nT.Software Users could try to modify VU software\nT.Stored_Data Users could try to modify stored data (security or user data).\n3.4.\nSecurity objectives\nThe main security objective of the digital tachograph system is the following:\nO.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\nTherefore the security objectives of the VU, contributing to the global security objective, are the following:\nO.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\nO.VU_Export The VU must be able to export data to external storage media in such a way as to allow for verification of their integrity and authenticity.\n3.5.\nInformation technology security objectives\nThe specific IT security objectives of the VU contributing to its main security objectives, are the following:\nO.Access The VU must control user access to functions and data\nO.Accountability The VU must collect accurate accountability data\nO.Audit The VU must audit attempts to undermine system security and should trace them to associated users\nO.Authentication The VU should authenticate users and connected entities (when a trusted path needs to be established between entities)\nO.Integrity The VU must maintain stored data integrity\nO.Output The VU must ensure that data output reflects accurately data measured or stored\nO.Processing The VU must ensure that processing of inputs to derive user data is accurate\nO.Reliability The VU must provide a reliable service\nO.Secured_Data_Exchange The VU must secure data exchanges with the motion sensor and with tachograph cards.\n3.6.\nPhysical, personnel or procedural means\nThis paragraph describes physical, personnel or procedural requirements that contribute to the security of the VU.\n3.6.1.\nEquipment design\nM.Development VU developers must ensure that the assignment of responsibilities during development is done in a manner which maintains IT security\nM.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.\n3.6.2.\nEquipment delivery and activation\nM.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\nM.Activation Vehicle manufacturers and fitters or workshops must activate the VU after its installation before the vehicle leaves the premises where installation took place.\n3.6.3.\nSecurity data generation and delivery\nM.Sec_Data_Generation Security data generation algorithms must be accessible to authorised and trusted persons only\nM.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.\n3.6.4.\nCards delivery\nM.Card_Availability Tachograph cards must be available and delivered to authorised persons only\nM.Driver_Card_Uniqueness Drivers must possess, at one time, one valid driver card only\nM.Card_Traceability Card delivery must be traceable (white lists, black lists), and black lists must be used during security audits.\n3.6.5.\nRecording equipment installation, calibration, and inspection\nM.Approved_Workshops Installation, calibration and repair of recording equipment must be carried by trusted and approved fitters or workshops\nM.Regular_Inpections Recording equipment must be periodically inspected and calibrated\nM.Faithful_Calibration Approved fitters and workshops must enter proper vehicle parameters in recording equipment during calibration.\n3.6.6.\nEquipment operation\nM.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, …).\n3.6.7.\nLaw enforcement control\nM.Controls Law enforcement controls must be performed regularly and randomly, and must include security audits.\n3.6.8.\nSoftware upgrades\nM.Software_Upgrade Software revisions must be granted security certification before they can be implemented in a VU.\n4.\nSecurity enforcing functions\n4.1.\nIdentification and authentication\n4.1.1.\nMotion sensor identification and authentication\nThe VU shall be able to establish, for every interaction, the identity of the motion sensor it is connected to.\nThe identity of the motion sensor shall consist of the sensor approval number and the sensor serial number.\nThe VU shall authenticate the motion sensor it is connected to:\nat motion sensor connection,\nat each calibration of the recording equipment,\nat power supply recovery.\nAuthentication shall be mutual and triggered by the VU.\nThe 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 calibration of the recording equipment has not been changed.\nThe VU shall detect and prevent use of authentication data that has been copied and replayed.\nAfter (TBD by manufacturer and not more than 20) consecutive unsuccessful authentication attempts have been detected, and/or after detecting that the identity of the motion sensor has changed while not authorised (i.e. while not during a calibration of the recording equipment), the SEF shall:\ngenerate an audit record of the event,\nwarn the user,\ncontinue to accept and use non secured motion data sent by the motion sensor.\n4.1.2.\nUser identification and authentication\nThe 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.\nThe user identity shall consist of:\na user group:\nDRIVER (driver card),\nCONTROLLER (control card),\nWORKSHOP (workshop card),\nCOMPANY (company card),\nUNKNOWN (no card inserted),\na user ID, composed of:\nthe card issuing Member State code and of the card number,\nUNKNOWN if user group is UNKNOWN.\nUNKNOWN identities may be implicitly or explicitly known.\nThe VU shall authenticate its users at card insertion.\nThe VU shall re-authenticate its users:\nat power supply recovery,\nperiodically or after occurrence of specific events (TBD by manufacturers and more frequently than once per day).\nAuthentication 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.\nIn addition to the above, workshops shall be required to be successfully authenticated through a PIN check. PINs shall be at least 4 characters long.\nNote: 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.\nThe VU shall detect and prevent use of authentication data that has been copied and replayed.\nAfter 5 consecutive unsuccessful authentication attempts have been detected, the SEF shall:\ngenerate an audit record of the event,\nwarn the user,\nassume the user as UNKNOWN, and the card as non valid (definition z) and requirement 007).\n4.1.3.\nRemotely connected company identification and authentication\nCompany remote connection capability is optional. This paragraph therefore applies only if this feature is implemented.\nFor every interaction with a remotely connected company, the VU shall be able to establish the company's identity.\nThe remotely connected company's identity shall consist of its company card issuing Member State code and of its company card number.\nThe VU shall successfully authenticate the remotely connected company before allowing any data export to it.\nAuthentication shall be performed by means of proving that the company owns a valid company card, possessing security data that only the system could distribute.\nThe VU shall detect and prevent use of authentication data that has been copied and replayed.\nAfter 5 consecutive unsuccessful authentication attempts have been detected, the VU shall:\nwarn the remotely connected company.\n4.1.4.\nManagement device identification and authentication\nVU manufacturers may foresee dedicated devices for additional VU management functions (e.g. Software upgrading, security data reloading, …). This paragraph therefore applies only if this feature is implemented.\nFor every interaction with a management device, the VU shall be able to establish the device identity.\nBefore allowing any further interaction, the VU shall successfully authenticate the management device.\nThe VU shall detect and prevent use of authentication data that has been copied and replayed.\n4.2.\nAccess control\nAccess controls ensure that information is read from, created in, or modified into the TOE only by those authorised to do so.\nIt 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 (requirement 011) is not the subject of a security enforcing function.\n4.2.1.\nAccess control policy\nThe VU shall manage and check access control rights to functions and to data.\n4.2.2.\nAccess rights to functions\nThe VU shall enforce the mode of operation selection rules (requirements 006 to 009).\nThe VU shall use the mode of operation to enforce the functions access control rules (requirement 010).\n4.2.3.\nAccess rights to data\nThe VU shall enforce the VU identification data write access rules (requirement 076)\nThe VU shall enforce the paired motion sensor identification data write access rules (requirements 079 and 155)\nAfter 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 (requirements 154 and 156).\nAfter the VU activation, the VU shall enforce calibration data write and delete access rules (requirement 097).\nAfter 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).\nAfter the VU activation, the VU shall enforce time adjustment data write and delete access rules (requirement 100).\nThe VU shall enforce appropriate read and write access rights to security data (requirement 080).\n4.2.4.\nFile structure and access conditions\nApplication and data files structure and access conditions shall be created during the manufacturing process, and then locked from any future modification or deletion.\n4.3.\nAccountability\nThe VU shall ensure that drivers are accountable for their activities (requirements 081, 084, 087, 105a, 105b, 109 and 109a).\nThe VU shall hold permanent identification data (requirement 075).\nThe VU shall ensure that workshops are accountable for their activities (requirements 098, 101 and 109).\nThe VU shall ensure that controllers are accountable for their activities (requirements 102, 103 and 109).\nThe VU shall record odometer data (requirement 090) and detailed speed data (requirement 093).\nThe 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.\nThe 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.\n4.4.\nAudit\nAudit 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.\nThe VU shall, for events impairing the security of the VU, record those events with associated data (requirements 094, 096 and 109).\nThe events affecting the security of the VU are the following:\nSecurity breach attempts,\nmotion sensor authentication failure,\ntachograph card authentication failure,\nunauthorised change of motion sensor,\ncard data input integrity error,\nstored user data integrity error,\ninternal data transfer error,\nunauthorised case opening,\nhardware sabotage,\nlast card session not correctly closed,\nmotion data error event,\npower supply interruption event,\nVU internal fault.\nThe VU shall enforce audit records storage rules (requirement 094 and 096).\nThe VU shall store audit records generated by the motion sensor in its data memory.\nIt shall be possible to print, display and download audit records.\n4.5.\nObject re-use\nThe VU shall ensure that temporary storage objects can be re-used without this involving inadmissible information flow.\n4.6.\nAccuracy\n4.6.1.\nInformation flow control policy\nThe 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:\nvehicle motion data,\nVU's real time clock,\nrecording equipment calibration parameters,\ntachograph cards,\nuser's inputs.\nThe VU shall ensure that user data related to requirement 109a may only be entered for the period last card withdrawal — current insertion (requirement 050a).\n4.6.2.\nInternal data transfers\nThe requirements of this paragraph apply only if the VU makes use of physically separated parts.\nIf data are transferred between physically separated parts of the VU, the data shall be protected from modification.\nUpon 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.\n4.6.3.\nStored data integrity\nThe VU shall check user data stored in the data memory for integrity errors.\nUpon detection of a stored user data integrity error, the SEF shall generate an audit record.\n4.7.\nReliability of service\n4.7.1.\nTests\nAll commands, actions or test points, specific to the testing needs of the manufacturing phase of the VU shall be disabled or removed before the VU activation. It shall not be possible to restore them for later use.\nThe 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 executable code (if not in ROM).\nUpon detection of an internal fault during self test, the SEF shall:\ngenerate an audit record (except in calibration mode) (VU internal fault),\nPreserve the stored data integrity.\n4.7.2.\nSoftware\nThere shall be no way to analyse or debug software in the field after the VU activation.\nInputs from external sources shall not be accepted as executable code.\n4.7.3.\nPhysical protection\nIf 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 a 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).\nIf 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 inspection).\nAfter its activation, the VU shall detect specified (TBD by manufacturer) hardware sabotage.\nIn the case described above, the SEF shall generate an audit record and the VU shall: (TBD by manufacturer).\n4.7.4.\nPower supply interruptions\nThe VU shall detect deviations from the specified values of the power supply, including cut-off.\nIn the case described above, the SEF shall:\ngenerate an audit record (except in calibration mode),\npreserve the secure state of the VU,\nmaintain the security functions, related to components or processes still operational,\npreserve the stored data integrity.\n4.7.5.\nReset conditions\nIn 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.\n4.7.6.\nData availability\nThe VU shall ensure that access to resources is obtained when required and that resources are not requested nor retained unnecessarily.\nThe VU must ensure that cards cannot be released before relevant data have been stored to them (requirements 015 and 016)\nIn the case described above, the SEF shall generate an audit record of the event.\n4.7.7.\nMultiple applications\nIf the VU 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.\n4.8.\nData exchange\nThis paragraph addresses data exchange between the VU and connected devices.\n4.8.1.\nData exchange with motion sensor\nThe VU shall verify the integrity and authenticity of motion data imported from the motion sensor\nUpon detection of a motion data integrity or authenticity error, the SEF shall:\ngenerate an audit record,\ncontinue to use imported data.\n4.8.2.\nData exchange with tachograph cards\nThe VU shall verify the integrity and authenticity of data imported from tachograph cards.\nUpon detection of card data integrity or authenticity error, the VU shall:\ngenerate an audit record,\nnot use the data.\nThe 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.\n4.8.3.\nData exchange with external storage media (downloading function)\nThe VU shall generate an evidence of origin for data downloaded to external media.\nThe VU shall provide a capability to verify the evidence of origin of downloaded data to the recipient.\nThe VU shall download data to external storage media with associated security attributes such that downloaded data integrity and authenticity can be verified.\n4.9.\nCryptographic support\nThe requirements of this paragraph are applicable only where needed, depending upon security mechanisms used and upon the manufacturer's solutions.\nAny cryptographic operation performed by the VU shall be in accordance with a specified algorithm and a specified key size.\nIf the VU generates cryptographic keys, it shall be in accordance with specified cryptographic key generation algorithms and specified cryptographic key sizes.\nIf the VU distributes cryptographic keys, it shall be in accordance with specified key distribution methods.\nIf the VU accesses cryptographic keys, it shall be in accordance with specified cryptographic keys access methods.\nIf the VU destroys cryptographic keys, it shall be in accordance with specified cryptographic keys destruction methods.\n5.\nDefinition of security mechanisms\nRequired security mechanisms are specified in Appendix 11.\nAll other security mechanisms are to be defined by manufacturers.\n6.\nMinimum strength of security mechanisms\nThe minimum strength of the Vehicle Unit security mechanisms is High , as defined in (ITSEC).\n7.\nLevel of assurance\nThe target level of assurance for the Vehicle Unit is ITSEC level E3 , as defined in (ITSEC).\n8.\nRationale\nThe following matrixes give a rationale for the SEFs by showing:\nwhich SEFs or means counteract which threats,\nwhich SEFs fulfil which IT security objectives.\nThreats\nIT Objectives\nAccess\nIdentification\nFaults\nTests\nDesign\nCalibration_Parameters\nCard_Data_Exchange\nClock\nEnvironment\nFake_Devices\nHardware\nMotion_Data\nNon_Activated\nOutput_Data\nPower_Supply\nSecurity_Data\nSoftware\nStored_Data\nAccess\nAccountability\nAudit\nAuthentication\nIntegrity\nOutput\nProcessing\nReliability\nSecured_Data_Exchange\nPhysical Personnel Procedural Means\nDevelopment\nx\nx\nx\nManufacturing\nx\nx\nDelivery\nx\nActivation\nx\nx\nSecurity data generation\nx\nSecurity data transport\nx\nCard availability\nx\nOne driver card\nx\nCard traceability\nx\nApproved workshops\nx\nx\nRegular inspection calibration\nx\nx\nx\nx\nx\nFaithful workshops\nx\nx\nFaithful drivers\nx\nLaw enforcement controls\nx\nx\nx\nx\nx\nx\nx\nx\nx\nSoftware upgrade\nx\nSecurity enforcing functions\nIdentification and authentication\nUIA_201 Sensor identification\nx\nx\nx\nx\nUIA_202 Sensor identity\nx\nx\nx\nx\nUIA_203 Sensor authentication\nx\nx\nx\nx\nUIA_204 Sensor re-identification and re-authentication\nx\nx\nx\nx\nUIA_205 Unforgeable authentication\nx\nx\nx\nUIA_206 Authentication failure\nx\nx\nx\nx\nUIA_207 Users identification\nx\nx\nx\nx\nx\nx\nUIA_208 User identity\nx\nx\nx\nx\nx\nx\nUIA_209 User authentication\nx\nx\nx\nx\nx\nx\nUIA_210 User re-authentication\nx\nx\nx\nx\nx\nx\nUIA_211 Authentication means\nx\nx\nx\nx\nx\nUIA_212 PIN checks\nx\nx\nx\nx\nx\nx\nUIA_213 Unforgeable authentication\nx\nx\nx\nx\nx\nUIA_214 Authentication failure\nx\nx\nx\nx\nUIA_215 Remote user identification\nx\nx\nx\nx\nx\nUIA_216 Remote user identity\nx\nx\nx\nx\nUIA_217 Remote user authentication\nx\nx\nx\nx\nx\nUIA_218 Authentication means\nx\nx\nx\nx\nUIA_219 Unforgeable authentication\nx\nx\nx\nx\nUIA_220 Authentication failure\nx\nx\nUIA_221 Management device identification\nx\nx\nx\nx\nUIA_222 Management device authentication\nx\nx\nx\nx\nUIA_223 Unforgeable authentication\nx\nx\nx\nx\nAccess Control\nACC_201 Access control policy\nx\nx\nx\nx\nx\nx\nACC_202 Access rights to functions\nx\nx\nx\nx\nACC_203 Access rights to functions\nx\nx\nx\nx\nACC_204 VU ID\nx\nx\nACC_205 Connected sensor ID\nx\nx\nx\nACC_206 Calibration data\nx\nx\nx\nx\nACC_207 Calibration data\nx\nx\nx\nACC_208 Time adjustment data\nx\nx\nx\nACC_209 Time adjustment data\nx\nx\nx\nACC_210 Security data\nx\nx\nx\nACC_211 File structure and access conditions\nx\nx\nx\nx\nx\nAccountability\nACT_201 Drivers accountability\nx\nACT_202 VU ID data\nx\nx\nACT_203 Workshops accountability\nx\nACT_204 Controllers accountability\nx\nACT_205 Vehicle movement accountability\nx\nACT_206 Accountability data modification\nx\nx\nx\nACT_207 Accountability data modification\nx\nx\nx\nAudit\nAUD_201 Audit records\nx\nAUD_202 Audit events list\nx\nx\nx\nx\nx\nx\nx\nx\nAUD_203 Audit records storage rules\nx\nAUD_204 Sensor audit records\nx\nAUD_205 Audit tools\nx\nRe-use\nREU_201 Re-use\nx\nx\nx\nAccuracy\nACR_201 Information flow control policy\nx\nx\nx\nx\nx\nACR_202 Internal transfers\nx\nx\nx\nx\nACR_203 Internal transfers\nx\nx\nACR_204 Stored data integrity\nx\nx\nx\nACR_205 Stored data integrity\nx\nx\nReliability\nRLB_201 Manufacturing tests\nx\nx\nx\nRLB_202 Self tests\nx\nx\nx\nx\nx\nRLB_203 Self tests\nx\nx\nx\nx\nRLB_204 Software analysis\nx\nx\nx\nRLB_205 Software input\nx\nx\nx\nx\nRLB_206 Case opening\nx\nx\nx\nx\nx\nx\nx\nx\nx\nRLB_207 Hardware sabotage\nx\nx\nRLB_208 Hardware sabotage\nx\nx\nRLB_209 Power supply interruptions\nx\nx\nRLB_210 Power supply interruptions\nx\nx\nRLB_211 Reset\nx\nx\nRLB_212 Data availability\nx\nx\nRLB_213 Card release\nx\nRLB_214 Card session not correctly closed\nx\nRLB_215 Multiple applications\nx\nData exchange\nDEX_201 Secured motion data import\nx\nx\nDEX_202 Secured motion data import\nx\nx\nDEX_203 Secured card data import\nx\nx\nDEX_204 Secured card data import\nx\nx\nDEX_205 Secured data export to cards\nx\nx\nDEX_206 Evidence of origin\nx\nx\nDEX_207 Evidence of origin\nx\nx\nDEX_208 Secured export to external media\nx\nx\nCryptographic support\nCSP_201 Algorithms\nx\nx\nCSP_202 key generation\nx\nx\nCSP_203 key distribution\nx\nx\nCSP_204 key access\nx\nx\nCSP_205 key destruction\nx\nx\nTACHOGRAPH CARD GENERIC SECURITY TARGET\n1.\nIntroduction\nThis 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.\nRequirements 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.\nAnnex I B body requirements not referred by security targets are not the subject of security enforcing functions.\nA 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 incorporates only the extra security requirements needed by the tachograph application.\nUnique labels have been assigned to threats, objectives, procedural means and SEF specifications for the purpose of traceability to development and evaluation documentation.\n2.\nAbbreviations, definitions and references\n2.1.\nAbbreviations\nIC Integrated Circuit (electronic component designed to perform processing and/or memory functions)\nOS Operating system\nPIN Personal identification number\nROM Read only memory\nSFP Security functions policy\nTBD To be defined\nTOE Target of evaluation\nTSF TOE security function\nVU Vehicle unit.\n2.2.\nDefinitions\nDigital tachograph Recording equipment.\nSensitive 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.\nSecurity data The specific data needed to support security enforcing functions (e.g. crypto keys).\nSystem Equipment, people or organisations involved in any way with the recording equipment.\nUser Any entity (human user or external IT entity) outside the TOE that interacts with the TOE (when not used in the expression ‘ user data ’ ).\nUser data Sensitive data stored in the tachograph card, other than security data. User data include identification data and activity data.\nIdentification data Identification data include card identification data and cardholder identification data.\nCard identification data User data related to card identification as defined by requirements 190, 191, 192, 194, 215, 231 and 235.\nCardholder identification data User data related to cardholder identification as defined by requirements 195, 196, 216, 232 and 236.\nActivity data Activity data include cardholder activities data, events and faults data and control activity data.\nCardholder 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.\nEvents and faults data User data related to events or faults as defined by requirements 204, 205, 207, 208 and 223.\nControl activity data User data related to law enforcement controls as defined by requirements 210 and 225.\n2.3.\nReferences\nITSEC ITSEC Information Technology Security Evaluation Criteria 1991\nIC PP Smartcard Integrated Circuit Protection Profile — version 2.0 — issue September 1998. Registered at French certification body under the number PP/9806\nES PP Smart Card Integrated Circuit With Embedded Software Protection Profile — version 2.0 — issue June 99. Registered at French certification body under the number PP/9911\n3.\nProduct Rationale\n3.1.\nTachograph card description and method of use\nA 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.\nThe basic functions of the tachograph card are:\nto store card identification and card holder identification data. These data are used by the vehicle unit to identify the cardholder, provide accordingly functions and data access rights, and ensure cardholder accountability for his activities,\nto store cardholder activities data, events and faults data and control activities data, related to the cardholder.\nA 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.\nDuring 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.\nThe functional requirements for a tachograph card are specified in Annex I B body text and Appendix 2.\n3.2.\nTachograph card life cycle\nThe tachograph card life cycle conforms to smart card life cycle described in (ES PP).\n3.3.\nThreats\nIn addition to the smart card general threats listed in (ES PP) and (IC PP), the tachograph card may face the following threats:\n3.3.1.\nFinal aims\nThe final aim of attackers will be to modify user data stored within the TOE.\nT.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.\nT.Activity_Data A successful modification of activity data stored in the TOE would be a threat to the security of the TOE.\nT.Data_Exchange A successful modification of activity data (addition, deletion, modification) during import or export would be a threat to the security of the TOE.\n3.3.2.\nAttack paths\nTOE's assets may be attacked by:\ntrying 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, …),\ntaking 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, …),\nmodifying the TOE or its security functions through physical, electrical or logical attacks or combination of these.\n3.4.\nSecurity Objectives\nThe main security objective of the entire digital tachograph system is the following:\nO.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.\nTherefore the main security objectives of the TOE, contributing to this global security objective are the following:\nO.Card_Identification_Data The TOE must preserve card identification data and cardholder identification data stored during card personalisation process,\nO.Card_Activity_Storage The TOE must preserve user data stored in the card by vehicle units.\n3.5.\nInformation technology security objectives\nIn 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:\nO.Data_Access The TOE must limit user data write access rights to authenticated vehicle units,\nO.Secure_Communications The TOE must be able to support secure communication protocols and procedures between the card and the card interface device when required by the application.\n3.6.\nPhysical, personnel or procedural means\nThe physical, personnel or procedural requirements that contribute to the security of the TOE are listed in (ES PP) and (IC PP) (chapters security objectives for the environment).\n4.\nSecurity enforcing functions\nThis paragraph refines some of the permitted operations such as assignment or selection of (ES PP) and provides additional SEF functional requirements.\n4.1.\nCompliance to protection profiles\nThe TOE shall comply with (IC PP).\nThe TOE shall comply with (ES PP) as refined further.\n4.2.\nUser identification and authentication\nThe 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 whatever 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).\n4.2.1.\nUser identification\nAssignment (FIA_UID.1.1) List of TSF mediated actions : none.\nAssignment (FIA_ATD.1.1) List of security attributes :\nUSER_GROUP VEHICLE_UNIT, NON_VEHICLE_UNIT,\nUSER_ID Vehicle Registration Number (VRN) and registering Member State Code (USER_ID is known for USER_GROUP = VEHICLE_UNIT only).\n4.2.2.\nUser authentication\nAssignment (FIA_UAU.1.1) List of TSF mediated actions:\nDriver and Workshop cards: export user data with security attributes (card data download function),\nControl card: export user data without security attributes except cardholder identification data.\nAuthentication of a vehicle unit shall be performed by means of proving that it possesses security data that only the system could distribute.\nSelection (FIA_UAU.3.1 and FIA_UAU.3.2): prevent.\nAssignment (FIA_UAU.4.1) Identified authentication mechanism(s) : any authentication mechanism.\nThe 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).\n4.2.3.\nAuthentication failures\nThe following assignments describe the card reaction for each single user authentication failure.\nAssignment (FIA_AFL.1.1) Number : 1, list of authentication events : authentication of a card interface device.\nAssignment (FIA_AFL.1.2) List of actions:\nwarn the entity connected,\nassume the user as NON_VEHICLE_UNIT.\nThe following assignments describe the card reaction in the case of failure of the additional authentication mechanism required in UIA_302.\nAssignment (FIA_AFL.1.1) Number : 5, list of authentication events : PIN checks (workshop card).\nAssignment (FIA_AFL.1.2) List of actions:\nwarn the entity connected,\nblock the PIN check procedure such that any subsequent PIN check attempt will fail,\nbe able to indicate to subsequent users the reason of the blocking.\n4.3.\nAccess control\n4.3.1.\nAccess control policy\nDuring 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.\nAssignment (FDP_ACC.2.1) Access control SFP : AC_SFP.\n4.3.2.\nAccess control functions\nAssignment (FDP_ACF.1.1) Access control SFP : AC_SFP.\nAssignment (FDP_ACF.1.1) Named group of security attributes : USER_GROUP.\nAssignment (FDP_ACF.1.2) Rules governing access among controlled subjects and controlled objects using controlled operations on controlled objects :\nGENERAL_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.\nIDENTIF_WRITE Identification data may only be written once and before the end of phase 6 of card's life-cycle. No user may write or modify identification data during end-usage phase of card's life-cycle.\nACTIVITY_WRITE Activity data may be written to the TOE by VEHICLE_UNIT only.\nSOFT_UPGRADE No user may upgrade TOE's software.\nFILE_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.\n4.4.\nAccountability\nThe TOE shall hold permanent identification data.\nThere shall be an indication of the time and date of the TOE's personalisation. This indication shall remain unalterable.\n4.5.\nAudit\nThe TOE must monitor events that indicate a potential violation of its security.\nAssignment (FAU_SAA.1.2) Subset of defined auditable events:\ncardholder authentication failure (5 consecutive unsuccessful PIN checks),\nself test error,\nstored data integrity error,\nactivity data input integrity error.\n4.6.\nAccuracy\n4.6.1.\nStored data integrity\nAssignment (FDP_SDI.2.2) Actions to be taken : warn the entity connected,\n4.6.2.\nBasic data authentication\nAssignment (FDP_DAU.1.1) List of objects or information types : activity data.\nAssignment (FDP_DAU.1.2) List of subjects : any.\n4.7.\nReliability of service\n4.7.1.\nTests\nSelection (FPT_TST.1.1): during initial start-up, periodically during normal operation.\nNote: during initial start-up means before code is executed (and not necessarily during Answer To Reset procedure).\nThe TOE's self tests shall include the verification of the integrity of any software code not stored in ROM.\nUpon detection of a self test error the TSF shall warn the entity connected.\nAfter 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.\n4.7.2.\nSoftware\nThere shall be no way to analyse, debug or modify TOE's software in the field.\nInputs from external sources shall not be accepted as executable code.\n4.7.3.\nPower supply\nThe TOE shall preserve a secure state during power supply cut-off or variations.\n4.7.4.\nReset conditions\nIf 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.\n4.8.\nData exchange\n4.8.1.\nData exchange with a vehicle unit\nThe TOE shall verify the integrity and authenticity of data imported from a vehicle unit.\nUpon detection of an imported data integrity error, the TOE shall:\nwarn the entity sending the data,\nnot use the data.\nThe TOE shall export user data to the vehicle unit with associated security attributes, such that the vehicle unit will be able to verify the integrity and authenticity of data received.\n4.8.2.\nExport of data to a non-vehicle unit (download function)\nThe TOE shall be able to generate an evidence of origin for data downloaded to external media.\nThe TOE shall be able to provide a capability to verify the evidence of origin of downloaded data to the recipient.\nThe TOE shall be able to download data to external storage media with associated security attributes such that downloaded data integrity can be verified.\n4.9.\nCryptographic support\nIf 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 manufacturer and not more than 240) number of possible use.\nIf the TSF distributes cryptographic keys, it shall be in accordance with specified cryptographic key distribution methods.\n5.\nDefinition of security mechanisms\nRequired security mechanisms are specified in Appendix 11.\nAll other security mechanisms are to be defined by the TOE manufacturer.\n6.\nClaimed minimum strength of mechanisms\nThe minimum strength of mechanisms for the Tachograph Card is High as defined in (ITSEC).\n7.\nLevel of Assurance\nThe target level of assurance for the Tachograph Card is ITSEC level E3 , as defined in (ITSEC).\n8.\nRationale\nThe following matrixes give a rationale for the additional SEFs by showing:\nwhich SEFs counteract which threats,\nwhich SEFs fulfil which IT security objectives.\nThreats\nIT Objectives\nT.CLON*\nT.DIS_ES2\nT.T_ES\nT.T_CMD\nT.MOD_SOFT*\nT.MOD_LOAD\nT.MOD_EXE\nT.MOD_SHARE\nIdent_Data\nActivity_Data\nData_Exchange\nO.TAMPER_ES\nO.CLON*\nO.OPERATE*\nO.FLAW*\nO.DIS_MECHANISM2\nO.DIS_MEMORY*\nO.MOD_MEMORY*\nData_Access\nSecured_Communications\nUIA_301 Authentication means\nx\nUIA_302 PIN checks\nx\nACT_301 Identification data\nACT_302 Personalisation date\nRLB_301 Software integrity\nx\nx\nRLB_302 Self tests\nx\nx\nRLB_303 Manufacturing tests\nx\nx\nx\nx\nRLB_304 Software analysis\nx\nx\nx\nx\nx\nRLB_305 Software input\nx\nx\nx\nx\nx\nRLB_306 Power supply\nx\nx\nx\nx\nRLB_307 Reset\nx\nx\nDEX_301 Secured data import\nx\nx\nDEX_302 Secured data import\nx\nx\nDEX_303 Secured data export to VU\nx\nx\nDEX_304 Evidence of origin\nx\nx\nDEX_305 Evidence of origin\nx\nx\nDEX_306 Secured export to external media\nx\nx\nCSP_301 key generation\nx\nx\nCSP_302 key distribution\nx\nx\nAppendix 11\nCOMMON SECURITY MECHANISMS\n1.\nGENERALITIES\nThis appendix specifies the security mechanisms ensuring:\nthe mutual authentication between VUs and tachograph cards, including session key agreement,\nthe confidentiality, integrity and authentication of data transferred between VUs and tachograph cards,\nthe integrity and authentication of data downloaded from VUs to external storage media,\nthe integrity and authentication of data downloaded from tachograph cards to external storage media.\n1.1.\nReferences\nThe following references are used in this Appendix:\nSHA-1 National Institute of Standards and Technology (NIST). FIPS Publication 180-1: Secure Hash Standard. April 1995\nPKCS1 RSA Laboratories. PKCS # 1: RSA Encryption Standard. Version 2.0. October 1998\nTDES National Institute of Standards and Technology (NIST). FIPS Publication 46-3: Data Encryption Standard. Draft 1999\nTDES-OP ANSI X9.52, Triple Data Encryption Algorithm Modes of Operation. 1998\nISO/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\nISO/IEC 7816-6 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 6: Interindustry data elements. First edition: 1996 + Cor 1: 1998\nISO/IEC 7816-8 Information Technology — Identification cards — Integrated circuit(s) cards with contacts — Part 8: Security related interindustry commands. First edition 1999\nISO/IEC 9796-2 Information Technology — Security techniques — Digital signature schemes giving message recovery — Part 2: Mechanisms using a hash function. First edition: 1997\nISO/IEC 9798-3 Information Technology — Security techniques — Entity authentication mechanisms — Part 3: Entity authentication using a public key algorithm. Second edition 1998\nISO 16844-3 Road vehicles — Tachograph systems — Part 3: Motion sensor interface.\n1.2.\nNotations and abbreviated terms\nThe following notations and abbreviated terms are used in this Appendix:\n(K a , K b , K c ) a key bundle for use by the triple data encryption algorithm\nCA Certification authority\nCAR Certification authority reference\nCC Cryptographic checksum\nCG Cryptogram\nCH Command header\nCHA Certificate holder authorisation\nCHR Certificate holder reference\nD() Decryption with DES\nDE Data element\nDO Data object\nd RSA private key, private exponent\ne RSA public key, public exponent\nE() Encryption with DES\nEQT Equipment\nHash() hash value, an output of hash\nHash hash function\nKID Key identifier\nKm TDES key. Master Key defined in ISO 16844-3\nKm vu TDES key inserted in vehicle units\nKm wc TDES key inserted in workshop cards\nm message representative an integer between 0 and n -1\nn RSA keys, modulus\nPB Padding bytes\nPI Padding indicator byte (for use in cryptogram for confidentiality DO)\nPV Plain value\ns signature representative, an integer between 0 and n -1\nSSC Send sequence counter\nSM Secure messaging\nTCBC TDEA cipher block chaining mode of operation\nTDEA Triple data encryption algorithm\nTLV Tag length value\nVU Vehicle unit\nX.C the certificate of user X issued by a certification authority\nX.CA a certification authority of user X\nX.CA.PK o X.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,\nX.PK public key of a user X\nX.PK[I] RSA encipherment of some information I, using the public key of user X\nX.SK RSA private key of a user X\nX.SK[I] RSA encipherment of some information I, using the private key of user X\n′xx′ a Hexadecimal value\n|| concatenation operator.\n2.\nCRYPTOGRAPHIC SYSTEMS AND ALGORITHMS\n2.1.\nCryptographic systems\nVehicle units and tachograph cards shall use a classical RSA public-key cryptographic system to provide the following security mechanisms:\nauthentication between vehicle units and cards,\ntransport of Triple-DES session keys between vehicle units and tachograph cards,\ndigital signature of data downloaded from vehicle units or tachograph cards to external media.\nVehicle units and tachograph cards shall use a Triple DES symmetric cryptographic 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 tachograph cards.\n2.2.\nCryptographic algorithms\n2.2.1.\nRSA algorithm\nThe RSA algorithm is fully defined by the following relations:\nA more comprehensive description of the RSA function can be found in reference (PKCS1).\nPublic exponent, e, for RSA calculations will be different from 2 in all generated RSA keys.\n2.2.2.\nHash algorithm\nThe digital signature mechanisms shall use the SHA-1 hash algorithm as defined in reference (SHA-1).\n2.2.3.\nData encryption algorithm\nDES based algorithms shall be used in Cipher Block Chaining mode of operation.\n3.\nKEYS AND CERTIFICATES\n3.1.\nKeys generation and distribution\n3.1.1.\nRSA keys generation and distribution\nRSA keys shall be generated through three functional hierarchical levels:\nEuropean level,\nMember State level,\nEquipment level.\nAt 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 responsibility of the European Commission.\nAt 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 Certification 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 certification authority. A Member State may regularly change its key pair.\nAt equipment level, one single key pair (EQT.SK and EQT.PK) shall be generated and inserted in each equipment. Equipment public keys shall be certified by a Member State certification authority. These tasks may be handled by equipment manufacturers, equipment personalisers or Member State authorities. This key pair is used for authentication, digital signature and encipherement services\nPrivate keys confidentiality shall be maintained during generation, transport (if any) and storage.\nThe following picture summarises the data flow of this process:\n3.1.2.\nRSA test keys\nFor 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 which shall 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.\n3.1.3.\nMotion sensor keys\nThe confidentiality of the three TDES keys described below shall be appropriately maintained during generation, transport (if any) and storage.\nIn 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:\nThe European certification authority shall generate Km VU and Km WC , two independent and unique Triple DES keys, and generate Km as:\nThe European certification authority shall forward these keys, under appropriately secured procedures, to Member States certification authorities at their request.\nMember States certification authorities shall:\nuse Km to encrypt motion sensor data requested by motion sensor manufacturers (data to be encrypted with Km is defined in ISO 16844-3),\nforward Km VU to vehicle unit manufacturers, under appropriately secured procedures, for insertion in vehicle units,\nensure that Km WC will be inserted in all workshop cards (SensorInstallationSecData in Sensor_Installation_Data elementary file) during card personalisation.\n3.1.4.\nT-DES session keys generation and distribution\nVehicle 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.\nThis 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).\n3.2.\nKeys\nRSA keys shall have (whatever the level) the following lengths: modulus n 1024 bits, public exponent e 64 bits maximum, private exponent d 1024 bits.\nTriple DES keys shall have the form (K a , K b , K a ) where K a and K b are independent 64 bits long keys. No parity error detecting bits shall be set.\n3.3.\nCertificates\nRSA Public key certificates shall be ‘ non self-descriptive ’ ‘ Card Verifiable ’ certificates (Ref.: ISO/IEC 7816-8)\n3.3.1.\nCertificates content\nRSA Public key certificates are built with the following data in the following order:\nData\nFormat\nBytes\nObs\nCPI\nINTEGER\n1\nCertificate profile identifier (′01′ for this version)\nCAR\nOCTET STRING\n8\nCertification authority reference\nCHA\nOCTET STRING\n7\nCertificate holder authorisation\nEOV\nTimeReal\n4\nCertificate end of validity. Optional, ′FF′ padded if not used\nCHR\nOCTET STRING\n8\nCertificate holder reference\nn\nOCTET STRING\n128\nPublic key (modulus)\ne\nOCTET STRING\n8\nPublic key (public exponent)\n164\nNotes:\n1.\nThe ‘Certificate Profile Identifier’ (CPI) delineates the exact structure of an authentication certificate. It can be used as an equipment internal identifier of a relevant headerlist which describes the concatenation of Data Elements within the certificate.\nThe headerlist associated with this certificate content is as follows:\n2.\nThe ‘ Certification Authority Reference ’ (CAR) has the purpose of identifying 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).\n3.\nThe ‘ 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).\n4.\n‘ 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.\n5.\nKey Identifiers uniquely identify certificate holder or certification authorities. They are coded as follows:\n5.1. Equipment (VU or Card):\nData\nEquipment serial number\nDate\nType\nManufacturer\nLength\n4 Bytes\n2 Bytes\n1 Byte\n1 Byte\nValue\nInteger\nmm yy BCD coding\nManufacturer specific\nManufacturer code\nIn 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.\nIn 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 manufacturer must ensure that keys and certificate are inserted in the intended equipment. The Key identifier has the form shown above.\nIn 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 identification. 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:\nData\nCertificate request serial number\nDate\nType\nManufacturer\nLength\n4 Bytes\n2 Bytes\n1 Byte\n1 Byte\nValue\nBCD coding\nmm jj BCD coding\n′FF′\nManufacturer code\n5.2. Certification Authority:\nData\nAuthority identification\nKey serial number\nAdditional info\nIdentifier\nLength\n4 Bytes\n1 Byte\n2 Bytes\n1 Byte\nValue\n1 Byte nation numerical code\nInteger\nadditional coding (CA specific)\n′01′\n3 Bytes nation alphanumerical code\n′FF FF′ if not used\nThe key serial number is used to distinguish the different keys of a Member State, in the case the key is changed.\n6.\nCertificate 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).\n3.3.2.\nCertificates issued\nThe certificate issued is a digital signature with partial recovery of the certificate content in accordance with ISO/IEC 9796-2, with the ‘ Certification Authority Reference ’ appended.\nWith certificate content\nNotes:\n1.\nThis certificate is 194 bytes long.\n2.\nCAR, 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.\n3.\nThe certificate verifier shall implicitly know the algorithm used by the certification authority to sign the certificate.\n4.\nThe headerlist associated with this issued certificate is as follows:\n3.3.3.\nCertificate verification and unwrapping\nCertificate 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.PK o X.C, and verifying the validity of the certificate.\nIt involves the following steps:\nverify signature and retrieve content:\nfrom X.C retrieve Sign, C n ′ and CAR′:\nfrom CAR′ select appropriate Certification Authority Public Key (if not done before through other means)\nopen Sign with CA Public Key: Sr′ = X.CA.PK [Sign],\ncheck Sr′ starts with ′6A′ and ends with ′BC′\ncompute Cr′ and H′ from:\nRecover certificate content C′ = C r ′ || C n ′,\ncheck Hash (C′) = H′\nIf the checks are OK the certificate is a genuine one, its content is C′.\nVerify validity. From C′:\nif applicable, check End of validity date,\nRetrieve and store public key, Key Identifier, Certificate Holder Authorisation and Certificate End of Validity from C′:\nX.PK = n || e\nX.KID = CHR\nX.CHA = CHA\nX.EOV = EOV.\n4.\nMUTUAL AUTHENTICATION MECHANISM\nMutual authentication between cards and VUs is based on the following principle:\nEach 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.\nDemonstration 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.\nThe 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.\nThe following protocol shall be used (arrows indicate commands and data exchanged (see Appendix 2)):\n5.\nVU-CARDS DATA TRANSFER CONFIDENTIALITY, INTEGRITY AND AUTHENTICATION MECHANISMS\n5.1.\nSecure messaging\nVU-cards data transfers integrity shall be protected through Secure Messaging in accordance with references (ISO/IEC 7816-4) and (ISO/IEC 7816-8).\nWhen 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.\nThe 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).\nThe response status-information bytes shall be protected by a cryptographic checksum when the response contains no data field.\nCryptographic checksums shall be four bytes long.\nThe structure of commands and responses when using secure messaging is therefore the following:\nThe DOs used are a partial set of the Secure Messaging DOs described in ISO/IEC 7816-4:\nTag\nMnemonic\nMeaning\n′81′\nT PV\nPlain Value not BER-TLV coded data (to be protected by CC)\n′97′\nT LE\nValue of Le in the unsecured command (to be protected by CC)\n′99′\nT SW\nStatus-Info (to be protected by CC)\n′8E′\nT CC\nCryptographic Checksum\n′87′\nT PI CG\nPadding Indicator Byte || Cryptogram (Plain Value not coded in BER-TLV)\nGiven an unsecured command response pair:\nCommand header\nCommand body\nCLA INS P1 P2\n(L c -field) (Data field) (L e -field)\nfour bytes\nL bytes, denoted as B 1 to B L\nResponse body\nResponse trailer\n(Data field)\nSW1\nSW2\nL r data bytes\ntwo bytes\nThe corresponding secured command response pair is:\nSecured command:\nCommand header (CH)\nCommand body\nCLA INS P1 P2\n(New L c field)\n(New Data field)\n(New L e field)\n′OC′\nLength of new data field\nT PV\nL PV\nPV\nT LE\nL LE\nL e\nT CC\nL CC\nCC\n′00′\n′81′\nL c\nData field\n′97′\n′01′\nL e\n′8E′\n′04′\nCC\nData to be integrated in checksum = CH || PB || T PV || L PV || PV || T LE || L LE || L e || PB\nPB = padding bytes (80 .. 00) in accordance with ISO-IEC 7816-4 and ISO 9797 method 1.\nDOs PV and LE are present only when there is some corresponding data in the unsecured command.\nSecured response:\n1.. Case where response data field is not empty and needs not to be protected for confidentiality:\nResponse body\nResponse trailer\n(New data field)\nnew SW1 SW2\nT PV\nL PV\nPV\nT CC\nL CC\nCC\n′81′\nL r\nData field\n′8E′\n′04′\nCC\nData to be integrated in checksum = T PV || L PV || PV || PB\n2.. Case where response data field is not empty and needs to be protected for confidentiality:\nResponse body\nResponse trailer\n(New data field)\nnew SW1 SW2\nT PI CG\nL PI CG\nPI CG\nT CC\nL CC\nCC\n′87′\nPI || CG\n′8E′\n′04′\nCC\nData to be carried by CG: non BER-TLV coded data and padding bytes.\nData to be integrated in checksum = T PI CG || L PI CG || PI CG || PB\n3.. Case where response data field is empty:\nResponse body\nResponse trailer\n(New data field)\nnew SW1 SW2\nT SW\nL SW\nSW\nT CC\nL CC\nCC\n′99′\n′02′\nNew SW1 SW2\n′8E′\n′04′\nCC\nData to be integrated in checksum = T SW || L SW || SW || PB\n5.2.\nTreatment of secure messaging errors\nWhen 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:\n′66 88′ verification of cryptographic checksum failed,\n′69 87′ expected SM data objects missing,\n′69 88′ SM data objects incorrect.\nWhen the tachograph card returns status bytes without SM DOs or with an erroneous SM DO, the session must be aborted by the VU.\n5.3.\nAlgorithm to compute cryptographic checksums\nCryptographic checksums are built using a retail MACs in accordance with ANSI X9.19 with DES:\ninitial stage: the initial check block y0 is E(Ka, SSC).\nsequential stage: the check blocks y1, …, yn are calculated using Ka.\nfinal stage: the cryptographic checksum is calculated from the last check block yn as follows: E(Ka, D(Kb, yn)).\nwhere E() means encryption with DES, and D() means decryption with DES.\nThe four most significant bytes of the cryptographic checksum are transferred\nThe send sequence counter (SSC) shall be initiated during key agreement procedure to:\nInitial SSC: Rnd3 (4 least significant bytes) || Rnd1 (4 least significant bytes).\nThe 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).\nThe following figure shows the calculation of the retail MAC:\n5.4.\nAlgorithm to compute cryptograms for confidentiality DOs\nCryptograms are computed using TDEA in TCBC mode of operation in accordance with references (TDES) and (TDES-OP) and with the Null vector as Initial Value block.\nThe following figure shows the application of keys in TDES:\n6.\nDATA DOWNLOAD DIGITAL SIGNATURE MECHANISMS\nThe intelligent dedicated equipment (IDE) stores data received from an equipment (VU or card) during one download session within one physical data file. This file must contain the certificates MS i .C and EQT.C. The file contains digital signatures of data blocks as specified in Appendix 7 Data Downloading Protocols.\nDigital signatures of downloaded data shall use a digital signature scheme with appendix such, that downloaded data may be read without any decipherment if desired.\n6.1.\nSignature generation\nData signature generation by the equipment shall follow the signature scheme with appendix defined in reference (PKCS1) with the SHA-1 hash function:\nSignature = EQT.SK[′00′ || ′01′ || PS || ′00′ || DER(SHA-1(Data))]\nPS Padding string of octets with value ′FF′ such that length is 128.\nDER(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):\n′30′||′21′||′30′||′09′||′06′||′05′||′2B′||′0E′||′03′||′02′||′1A′||′05′||′00′||′04′||′14′||Hash Value.\n6.2.\nSignature verification\nData signature verification on downloaded data shall follow the signature scheme with appendix defined in reference (PKCS1) with the SHA-1 hash function.\nThe European public key EUR.PK needs to be known independently (and trusted) by the verifier.\nThe 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.\nThe equipment that has downloaded and signed the data to be analysed is denoted EQT.\n’",
  "extent": "E+W+S+N.I.",
  "status": null,
  "version": "current",
  "annotations": [
    {
      "type": "F",
      "label": "F1",
      "text": "Substituted by Commission Regulation (EC) No 1360/2002 of 13 June 2002 adapting for the seventh time to technical progress Council Regulation (EEC) No 3821/85 on recording equipment in road transport (Text with EEA relevance)."
    },
    {
      "type": "footnote",
      "label": "f1",
      "text": "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."
    },
    {
      "type": "footnote",
      "label": "f2",
      "text": "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."
    },
    {
      "type": "footnote",
      "label": "f3",
      "text": "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 )."
    },
    {
      "type": "footnote",
      "label": "f4",
      "text": "OJ L 57, 2.3.1992, p. 27 ."
    },
    {
      "type": "footnote",
      "label": "f5",
      "text": "Council Recommendation 95/144/EC of 7 April 1995 on common information technology security evaluation criteria ( OJ L 93, 26.4.1995, p. 27 )."
    },
    {
      "type": "footnote",
      "label": "f6",
      "text": "OJ L 129, 14.5.1992, p. 95 ."
    },
    {
      "type": "footnote",
      "label": "f7",
      "text": "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 )."
    },
    {
      "type": "footnote",
      "label": "f8",
      "text": "OJ L 281, 23.11.1995, p. 31 ."
    },
    {
      "type": "footnote",
      "label": "f9",
      "text": "In these situations the recording equipment shall use only the tachograph card inserted in the driver slot."
    },
    {
      "type": "footnote",
      "label": "f10",
      "text": "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."
    },
    {
      "type": "footnote",
      "label": "f11",
      "text": "These data may be recorded at power supply reconnection only, times may be known with an accuracy to the minute."
    },
    {
      "type": "footnote",
      "label": "f12",
      "text": "OJ L 266, 8.11.1995, p. 1 ."
    },
    {
      "type": "footnote",
      "label": "f13",
      "text": "OJ L 152, 6.7.1972, p. 15 ."
    },
    {
      "type": "footnote",
      "label": "f14",
      "text": "OJ L 266, 8.11.1995, p. 1 ."
    },
    {
      "type": "footnote",
      "label": "f15",
      "text": "OJ L 281, 23.11.1995, p. 31 ."
    },
    {
      "type": "footnote",
      "label": "f16",
      "text": "The card inserted will trigger the appropriate access rights to the downloading function and to the data."
    },
    {
      "type": "footnote",
      "label": "f17",
      "text": "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."
    },
    {
      "type": "footnote",
      "label": "f18",
      "text": "No symbol indicates that this service is not allowed in this diagnostic session.This symbol indicates that the service is mandatory in this diagnostic session."
    },
    {
      "type": "footnote",
      "label": "f19",
      "text": "The value inserted in byte #6 of the request message is not supported, i.e. not in Table 17."
    },
    {
      "type": "footnote",
      "label": "f20",
      "text": "The length of the message is wrong."
    },
    {
      "type": "footnote",
      "label": "f21",
      "text": "The criteria for the request StartDiagnosticSession are not met."
    }
  ],
  "outstanding_effects": [],
  "provenance": {
    "source": "legislation.gov.uk",
    "source_url": "https://www.legislation.gov.uk/eur/1998/2135/annex",
    "retrieved_at": "2026-11-01T14:58:09.732401+00:00"
  },
  "licence": "Open Government Licence v3.0",
  "licence_url": "https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/",
  "attribution": "Contains public sector information licensed under the Open Government Licence v3.0. Source: legislation.gov.uk, The National Archives."
}