LegalizeCommission Implementing Regulation (EU) 2016/799 of 18 March 2016 implementing Regulation (EU) No 165/2014 of the European Parliament and of the Council laying down the requirements for the construction, testing, installation, operation and repair of tachographs and their components (Text with EEA relevance)
It does not specify card manufacturer dependent internal structures, such as e.g. file headers, nor storage and handling of data elements needed for internal use only such as Image omitted; see official source,Image omitted; see official source,Image omitted; see official source orImage omitted; see official source.
- TCS_140A generation 2 tachograph card shall host the Master File MF and a generation 1 and a generation 2 tachograph application of the same type (e.g. driver card applications).
- TCS_141A tachograph card shall support at least the minimum number of records specified for the corresponding applications and shall not support more records than the maximum number of records specified for the corresponding applications.
- The maximum and minimum numbers of records are specified in this chapter for the different applications. In version 2 of generation 2 driver and workshop cards, the generation 1 application shall support the maximum number of records specified in TCS_150 and TCS_158.
- For the security conditions used in the access rules throughout this chapter please refer to chapter 3.3. In general the access mode ‘read’ denotes the READ BINARY command with even and if supported odd INS byte with the exception of the EF Sensor_Installation_Data on the workshop card, see TCS_156 and TCS_160. The access mode ‘update’ denotes the Update Binary command with even and if supported odd INS byte and the access mode ‘select’ the SELECT command.
4.1. Master File MF
- TCS_142After its personalisation, the master file MF shall have the following permanent file structure and file access rules:
Note: The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary.
- The following abbreviation for the security condition is used in this table:
- SC1 ALW OR SM-MAC-G2
- TCS_143All EF structures shall be transparent.
- TCS_144The Master File MF shall have the following data structure:
- TCS_145The elementary file EF DIR shall contain the following application related data objects: ‘61 08 4F 06 FF 54 41 43 48 4F 61 08 4F 06 FF 53 4D 52 44 54’
- TCS_146The elementary file EF ATR/INFO shall be present if the tachograph card indicates in its ATR that it supports extended length fields. In this case the EF ATR/INFO shall contain the extended length information data object (DO‘7F66’) as specified in ISO/IEC 7816-4:2013 clause 12.7.1.
- TCS_147The elementary file EF Extended_Length shall be present if the tachograph card indicates in its ATR that it supports extended length fields. In this case the EF shall contain the following data object: ‘02 01 xx’ where the value ‘xx’ indicates whether extended length fields are supported for the T = 1 and / or T = 0 protocol.
- The value ‘01’ indicates extended length field support for the T = 1 protocol.
- The value ‘10’ indicates extended length field support for the T = 0 protocol.
- The value ‘11’ indicates extended length field support for the T = 1 and the T = 0 protocol.
4.2. Driver card applications
4.2.1 Driver card application generation 1
- TCS_148After its personalisation, the driver card application generation 1 shall have the following permanent file structure and file access rules:
- The following abbreviations for the security conditions are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
- SC3 SM-MAC-G1 OR SM-MAC-G2
- TCS_149All EF structures shall be transparent.
- TCS_150The driver card application generation 1 shall have the following data structure:
- TCS_151The 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 for a generation 1 application:
4.2.2 Driver card application generation 2
- TCS_152After its personalisation, the driver card application generation 2 shall have the following permanent file structure and file access rules:
Notes:
- — The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary.
- — EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF VU_Configuration and EF Load_Type_Entries are only present in version 2 of the generation 2 driver card.
- — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 driver card, while it was equal to {01 00} for version 1 of the generation 2 driver card.
- The following abbreviations for the security condition are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported): NEV
- TCS_153All EF structures shall be transparent.
- TCS_154The driver card application generation 2 shall have the following data structure:
- TCS_155The 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 for a generation 2 application:
| Min | Max | ||
| n1 | NoOfEventsPerType | 12 | 12 |
| n2 | NoOfFaultsPerType | 24 | 24 |
| n3 | NoOfCardVehicleRecords | 200 | 200 |
| n4 | NoOfCardPlaceRecords | 112 | 112 |
| n6 | CardActivityLengthRange | 13776 Bytes (56 days * 117 activity changes) | 13776 Bytes (56 days * 117 activity changes) |
| n7 | NoOfCardVehicleUnitRecords | 200 | 200 |
| n8 | NoOfGNSSADRecords | 336 | 336 |
| n9 | NoOfSpecificConditionRecords | 112 | 112 |
| n10 | NoOfBorderCrossingRecords | 1120 | 1120 |
| n11 | NoOfLoadUnloadRecords | 1624 | 1624 |
| n12 | NoOfLoadTypeEntryRecords | 336 | 336 |
| n13 | VuConfigurationLengthRange | 3072 Bytes | 3072 Bytes |
4.3. Workshop card applications
4.3.1 Workshop card application generation 1
- TCS_156After its personalisation, the workshop card application generation 1 shall have the following permanent file structure and file access rules:
- The following abbreviations for the security conditions are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
- SC3 SM-MAC-G1 OR SM-MAC-G2
- SC4 For the READ BINARY command with even INS byte:
(SM-C-MAC-G1 AND SM-R-ENC-MAC-G1) OR
(SM-C-MAC-G2 AND SM-R-ENC-MAC-G2)
For the READ BINARY command with odd INS byte (if supported): NEV
- TCS_157All EF structures shall be transparent.
- TCS_158The workshop card application generation 1 shall have the following data structure:
- TCS_159The 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 for a generation 1 application:
4.3.2 Workshop card application generation 2
- TCS_160After its personalisation, the workshop card application generation 2 shall have the following permanent file structure and file access rules.
Notes:
- — The short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary.
- — EF Application_Identification_V2, EF Places_Authentication, EF GNSS_Places_Authentication, EF Border_Crossings, EF Load_Unload_Operations, EF Load_Type_Entries, EF VU_Configuration and EF Calibration_Add_Data are only present in version 2 of the generation 2 workshop card.
- — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 workshop card, while it was equal to {01 00} for version 1 of the generation 2 workshop card.
- The following abbreviations for the security conditions are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported): NEV
- TCS_161All EFs structures shall be transparent.
- TCS_162The workshop card application generation 2 shall have the following data structure:
- TCS_163The 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 for a generation 2 application:
| Min | Max | ||
| n1 | NoOfEventsPerType | 3 | 3 |
| n2 | NoOfFaultsPerType | 6 | 6 |
| n3 | NoOfCardVehicleRecords | 8 | 8 |
| n4 | NoOfCardPlaceRecords | 8 | 8 |
| n5 | NoOfCalibrationRecords | 255 | 255 |
| n6 | CardActivityLengthRange | 492 bytes (1 day * 240 activity changes) | 492 bytes (1 day * 240 activity changes) |
| n7 | NoOfCardVehicleUnitRecords | 8 | 8 |
| n8 | NoOfGNSSADRecords | 24 | 24 |
| n9 | NoOfSpecificConditionRecords | 4 | 4 |
| n10 | NoOfBorderCrossingRecords | 4 | 4 |
| n11 | NoOfLoadUnloadRecords | 8 | 8 |
| n12 | NoOfLoadTypeEntryRecords | 4 | 4 |
| n13 | VuConfigurationLengthRange | 3072 Bytes | 3072 Bytes |
4.4. Control card applications
4.4.1 Control Card application generation 1
- TCS_164After its personalisation, the control card application generation 1 shall have the following permanent file structure and file access rules:
- The following abbreviations for the security conditions are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
- SC3 SM-MAC-G1 OR SM-MAC-G2
- SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
- TCS_165All EF structures shall be transparent.
- TCS_166The control card application generation 1 shall have the following data structure:
- TCS_167The 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 for a generation 1 application:
4.4.2 Control card application generation 2
- TCS_168After its personalisation, the control card application generation 2 shall have the following permanent file structure and file access rules.
Notes:
- — the short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary,
- — EF Application_Identification_V2, and EF VU_Configuration are only present in version 2 of the generation 2 control card,
- — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 control card, while it was equal to {01 00} for version 1 of the generation 2 control card.
Image omitted; see official source
The following abbreviations for the security condition are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported): NEV
- TCS_169All EF structures shall be transparent.
- TCS_170The control card application generation2 shall have the following data structure:
- TCS_171The 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 for a generation 2 application:
| Min | Max | ||
| n7 | NoOfControlActivityRecords | 230 | 520 |
| n13 | VuConfigurationLengthRange | 3072 Bytes | 3072 Bytes |
4.5. Company card applications
4.5.1 Company card application generation 1
- TCS_172After its personalisation, the company card application generation 1 shall have the following permanent file structure and file access rules:
- The following abbreviations for the security conditions are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC2 ALW OR SM-MAC-G1 OR SM-MAC-G2
- SC3 SM-MAC-G1 OR SM-MAC-G2
- SC6 EXT-AUT-G1 OR SM-MAC-G1 OR SM-MAC-G2
- TCS_173All EF structures shall be transparent.
- TCS_174The company card application generation 1 shall have the following data structure:
- TCS_175The 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 for a generation 1 application:
4.5.2 Company card application generation 2
- TCS_176After its personalisation, the company card application generation 2 shall have the following permanent file structure and file access rules.
Notes:
- — the short EF identifier SFID is given as decimal number, e.g. the value 30 corresponds to 11110 in binary,
- — EF Application_Identification_V2, and EF VU_Configuration are only present in version 2 of the generation 2 company card,
- — cardStructureVersion in EF Application_Identification is equal to {01 01} for version 2 of the generation 2 company card, while it was equal to {01 00} for version 1 of the generation 2 company card.
Image omitted; see official source
The following abbreviations for the security condition are used in this table:
- SC1 ALW OR SM-MAC-G2
- SC5 For the Read Binary command with even INS byte: SM-C-MAC-G2 AND SM-R-ENC-MAC-G2
For the Read Binary command with odd INS byte (if supported):NEV
- TCS_177All EF structures shall be transparent.
- TCS_178The company card application generation 2 shall have the following data structure:
- TCS_179The 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 for a generation 2 application:
| Min | Max | ||
| n8 | NoOfCompanyActivityRecords | 230 | 520 |
| n13 | VuConfigurationLengthRange | 3072 Bytes | 3072 Bytes |
Appendix 3
PICTOGRAMS
- PIC_001The tachograph may optionally use the following pictograms and pictogram combinations (or pictograms and combination similar enough to be unambiguously identifiable with these):
-
- BASIC PICTOGRAMS People Actions Modes of operation Image omitted; see official source Company
Company mode Image omitted; see official source Controller Control Control mode Image omitted; see official source Driver Driving Operational mode Image omitted; see official source Workshop/test station Inspection/calibration Calibration mode Image omitted; see official source Manufacturer Activities Duration Image omitted; see official source Available Current availability period Image omitted; see official source Driving Continuous driving time Image omitted; see official source Rest Current rest period Image omitted; see official source Other Work Current work period Image omitted; see official source Break Cumulative break time Image omitted; see official source Unknown Equipment Functions Image omitted; see official source Driver slot Image omitted; see official source Co-driver slot Image omitted; see official source Card Image omitted; see official source Clock Image omitted; see official source Display Displaying Image omitted; see official source External storage Downloading Image omitted; see official source Power supply Image omitted; see official source Printer/printout Printing Image omitted; see official source Sensor Image omitted; see official source Tyre size Image omitted; see official source Vehicle/vehicle unit Image omitted; see official source GNSS facility Image omitted; see official source Remote Detection facility Image omitted; see official source ITS interface Specific conditions, manual entries Image omitted; see official source Out of scope Image omitted; see official source Ferry/train crossing Image omitted; see official source Load operation Image omitted; see official source Unload operation Image omitted; see official source Simultaneous load/unload operation Image omitted; see official source Load type: passengers Image omitted; see official source Load type: goods Image omitted; see official source Load type: undefined load type Miscellaneous Image omitted; see official source Events Image omitted; see official source Faults Image omitted; see official source Start of daily work period Image omitted; see official source End of daily work period Image omitted; see official source Location Image omitted; see official source Manual entry of driver activities
Image omitted; see official source Security/authenticated data/seals
Image omitted; see official source
Speed Image omitted; see official source Time Image omitted; see official source Total/summary
Image omitted; see official source
Digital map/border crossing Qualifiers 24h Daily Image omitted; see official source Weekly Image omitted; see official source Two weeks Image omitted; see official source From or to
-
- PICTOGRAM COMBINATIONS Miscellaneous Image omitted; see official source Control place Image omitted; see official source Location start of daily work period Image omitted; see official source Location end of daily work period
Image omitted; see official source
Position after 3 hours accumulated driving time
Image omitted; see official source From time Image omitted; see official source To time Image omitted; see official source From vehicle Image omitted; see official source Out of scope begin Image omitted; see official source Out of scope end
Image omitted; see official source Position where the vehicle has crossed the border between two countries Image omitted; see official source Position where a load operation has occurred Image omitted; see official source Position where an unload operation has occurred Image omitted; see official source Position where a simultaneous load/unload operation has occurred Cards Image omitted; see official source Driver card Image omitted; see official source Company card Image omitted; see official source Control card Image omitted; see official source Workshop card Image omitted; see official source No card Driving Image omitted; see official source Crew driving Image omitted; see official source Driving time for one week Image omitted; see official source Driving time for two weeks Printouts Image omitted; see official source Driver activities from card daily printout Image omitted; see official source Driver activities from VU daily printout Image omitted; see official source Events and faults from card printout Image omitted; see official source Events and faults from VU printout Image omitted; see official source Technical data printout Image omitted; see official source Over speeding printout
Image omitted; see official source Historic of inserted cards printout Events Image omitted; see official source Insertion of a non valid card Image omitted; see official source Card conflict Image omitted; see official source Time overlap Image omitted; see official source Driving without an appropriate card Image omitted; see official source Card insertion while driving Image omitted; see official source Last card session not correctly closed Image omitted; see official source Over speeding Image omitted; see official source Power supply interruption Image omitted; see official source Motion data error Image omitted; see official source Vehicle motion conflict Image omitted; see official source Security breach
Image omitted; see official source Time conflict or time adjustment (by workshop)
Image omitted; see official source Over speeding control
Image omitted; see official source Absence of position information from GNSS receiver or Communication error with the external GNSS facility Image omitted; see official source Communication error with the remote communication facility
Image omitted; see official source GNSS anomaly Faults Image omitted; see official source Card fault (driver slot) Image omitted; see official source Card fault (co-driver slot) Image omitted; see official source Display fault Image omitted; see official source Downloading fault Image omitted; see official source Printer fault Image omitted; see official source Sensor fault Image omitted; see official source VU internal fault Image omitted; see official source GNSS fault Image omitted; see official source Remote Detection fault Manual entries procedure Image omitted; see official source Still same daily work period ? Image omitted; see official source End of previous work period ? Image omitted; see official source Confirm or enter location of end of work period Image omitted; see official source Enter start time Image omitted; see official source Enter location of start of work period.
Note: Additional pictogram combinations to form printout blocks or record identifiers are defined in Appendix 4.
Appendix 4
PRINTOUTS
| TABLE OF CONTENT | TABLE OF CONTENT |
| 1. | GENERALITIES |
| 2. | DATA BLOCKS SPECIFICATION |
| 3. | PRINTOUT SPECIFICATIONS |
| 3.1. | Driver Activities from Card Daily Printout |
| 3.2. | Driver Activities from VU Daily Printout |
| 3.3. | Events and Faults from Card Printout |
| 3.4. | Events and Faults from VU Printout |
| 3.5. | Technical data Printout |
| 3.6. | Over speeding Printout |
| 3.7 | History of inserted cards |
GENERALITIES
Each printout is built up by chaining various data blocks, possibly identified with a block identifier.
A data block contains one or more records, possibly identified with a record identifier.
- PRT_001 When a block identifier immediately precedes a record identifier, the record identifier is not printed.
- PRT_002 In the case where a data item is unknown, or must not be printed for data access rights reasons, spaces are printed instead.
- PRT_003 If the content of a complete line is unknown, or need not to be printed, then the complete line is omitted.
- PRT_004 Numerical data fields are printed right aligned, with a space separator for thousands and millions, and without leading zeros.
- PRT_005 String data fields are printed left aligned and filled up with spaces to data item length, or truncated to data item length when needed. Names and addresses may be printed in two lines.
- PRT_006 In case of a line-break due to a long text a special character (dot at middle line-height, ‘•’) should be printed as first character in the new line.
DATA BLOCKS SPECIFICATION
In this chapter the following format notation conventions have been used:
- — Characters printed in bold denote plain text to be printed (printing remains in normal characters),
- — Normal characters denote variables (pictograms or data) to be replaced by their values for printing,
- — Variable names have been padded with underscores to show the data item length available for the variable,
- — Dates are specified with a ‘dd/mm/yyyy’ (day, month, year) format. A ‘dd.mm.yyyy’ format may also be used,
- — The term ‘card identification’ denotes the composition of: the type of card through a card pictograms combination, the card issuing Member State code, a forward slash character and the card number with the replacement index and the renewal index separated with a space: P Image omitted; see official source x x x / x x x x x x x x x x x x x x
x
x Card Pictogram combination Issuing Member State code
First 14 characters of card number (possibly including a consecutive index)
Replacement index
Renewal index
- — In a data block, the text after ‘pi=’ refers to the corresponding pictogram or pictogram combination defined in Appendix 3,
- — When printed after the longitude and the latitude of a recorded position, or after the timestamp when the position was determined, the Image omitted; see official source pictogram indicates that this position has been computed from authenticated navigation messages,
- — * data only available in GEN2 tachographs (all versions),
- — ** data only available in GEN2 version 2.
- PRT_007Printouts shall use the following data blocks and/or data records, in accordance with the following meanings and formats:
Image omitted; see official source
Image omitted; see official source
Image omitted; see official source Image omitted; see official source
Image omitted; see official source Image omitted; see official source
PRINTOUT SPECIFICATIONS
In this chapter the following notation conventions have been used:
| N | Print block or record number N |
| N | Print block or record number N repeated as many times as necessary |
| X/Y | Print blocks or records X and/or Y as needed, and repeating as many times as necessary. |
3.1. Driver Activities from Card Daily Printout
- PRT_008The driver activities from card daily printout shall be in accordance with the following format:
3.2. Driver Activities from VU Daily Printout
- PRT_009The driver activities from VU daily printout shall be in accordance with the following format:
- Image omitted; see official source
3.3. Events and Faults from Card Printout
- PRT_010The events and faults from card printout shall be in accordance with the following format:
| 1 | Date and time at which the document is printed |
| 2 | Type of printout |
| 3 | Controller identification (if a control card is inserted in the VU + GEN) |
| 3 | Driver identification (from card subject of the printout) |
| 4 | Vehicle identification (vehicle from which printout is taken) |
| 12.2 | Events delimiter |
| 12.4 | Event records (all events stored on the card) |
| 12.3 | Faults delimiter |
| 12.4 | Fault records (all faults stored on the card) |
| 22.1 | Control place |
| 22.2 | Controller's signature |
| 22.5 | Driver's signature |
3.4. Events and Faults from VU Printout
- PRT_011The events and faults from VU printout shall be in accordance with the following format:
| | |
| --- | --- | | 1 | Date and time at which the document is printed | | 2 | Type of printout | | 3 | Card holder identification (for all cards inserted in VU + GEN) | | 4 | Vehicle identification (vehicle from which printout is taken) | | 13.2 | Events delimiter | | 13.4 | Event records (All Events stored or on-going in the VU) | | 13.3 | Faults delimiter | | 13.4 | Fault records (All Faults stored or on-going in the VU) | | 22.1 | Control place | | 22.2 | Controller's signature | | 22.5 | Driver's signature |
3.5. Technical data Printout
- PRT_012The technical data printout shall be in accordance with the following format:
- Image omitted; see official source
3.6. Over speeding Printout
- PRT_013The over speeding printout shall be in accordance with the following format:
| 1 | Date and time at which the document is printed |
| 2 | Type of printout |
| 3 | Card holder identification (for all cards inserted in VU + GEN) |
| 4 | Vehicle identification (vehicle from which printout is taken) |
| 20 | Over speeding control information |
| 21.1 | Over speeding data identifier |
| 21.4/21.5 | First over speeding after the last calibration |
| 21.2 | Over speeding data identifier |
| 21.4/21.5 | The 5 most serious over speeding events over the last 365 days |
| 21.3 | Over speeding data identifier |
| 21.4/21.5 | The most serious over speeding for each of the last 10 days of occurrence |
| 22.1 | Control place |
| 22.2 | Controller's signature |
| 22.5 | Driver's signature |
3.7. Historic of inserted cards
- PRT_014The historic of inserted cards printout shall be in accordance with the following format:
- Image omitted; see official source
Appendix 5
DISPLAY
In this appendix the following format notation conventions have been used:
- — characters printed in bold denote plain text to be displayed (display remains in normal character),
- — normal characters denote variables (pictograms or data) to be replaced by their values for displaying: — dd mm yyyy: day, month, year, — hh: hours, — mm: minutes, — D: duration pictogram, — EF: event or fault pictograms combination, — O: mode of operation pictogram.
- DIS_001The tachograph shall display data using the following formats:
| Data | Format |
|---|---|
| Default display | Default display |
| Local time | Image omitted; see official source |
| Mode of operation | Image omitted; see official source |
| Information related to the driver | Image omitted; see official source |
| Information related to the co-driver | Image omitted; see official source |
| Out of scope condition opened | Image omitted; see official source |
| Warning display | Warning display |
| Exceeding continuous driving time | Image omitted; see official source |
| Event or fault | Image omitted; see official source |
| Other displays | Other displays |
| UTC date | Image omitted; see official source |
| time | Image omitted; see official source |
| Driver's continuous driving time and cumulative break time | Image omitted; see official source |
| Co-driver's continuous driving time and cumulative break time | Image omitted; see official source |
| Driver's cumulated driving time for the previous and the current week | Image omitted; see official source |
| Co-driver's cumulated driving time for the previous and the current week | Image omitted; see official source |
Appendix 6
FRONT CONNECTOR FOR CALIBRATION AND DOWNLOAD
| | |
| --- | --- | | TABLE OF CONTENT | TABLE OF CONTENT | | 1. | HARDWARE | | 1.1. | Connector | | 1.2. | Contact allocation | | 1.3. | Block diagram | | 2. | DOWNLOADING INTERFACE | | 3. | CALIBRATION INTERFACE |
HARDWARE
1.1. Connector
- INT_001The downloading/calibration connector shall be a 6 pin connector, accessible on the front panel without the need to disconnect any part of the tachograph, and shall comply with the following drawing (all dimensions in millimetres):
- The following diagram shows a typical 6 pin mating plug:
1.2. Contact allocation
- INT_002Contacts shall be allocated in accordance with the following table:
| Pin | Description | Remark |
|---|---|---|
| 1 | Battery minus | Connected to the battery minus of the vehicle |
| 2 | Data communication | K-line (ISO 14230-1) |
| 3 | RxD — Downloading | Data input to tachograph |
| 4 | Input/output signal | Calibration |
| 5 | Permanent power output | The voltage range is specified to be that of the vehicle power minus 3V to allow for the voltage drop across the protective circuitry Output 40 mA |
| 6 | TxD — Downloading | Data output from tachograph |
1.3. Block diagram
- INT_003The block diagram shall comply with the following:
2. DOWNLOADING INTERFACE
- INT_004The downloading interface shall comply to RS232 specifications.
- INT_005The downloading interface shall use one start bit, 8 data bits LSB first, one even parity bit and 1 stop bit.
- Image omitted; see official source
Data byte organisation
| | | |
| --- | --- | --- | | Start bit | : | one bit with logic level 0; | | | | | | --- | --- | --- | | Data bits | : | transmitted with LSB first; | | | | | | --- | --- | --- | | Parity bit | : | even parity | | | | | | --- | --- | --- | | Stop bit | : | one bit with logic level 1 |
When numerical data composed by more than one byte are transmitted, the most significant byte is transmitted first and the least significant byte last.
- INT_006Transmission 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.
CALIBRATION INTERFACE
- INT_007The data communication shall comply to ISO 14230-1 Road vehicles — Diagnostic systems — Keyword protocol 2000 — Part 1: Physical layer, First edition: 1999.
- INT_008The input/output signal shall comply with the following electrical specification:
| Parameter | Minimum | Typical | Maximum | Remark |
|---|---|---|---|---|
| U low (in) | 1,0 V | I = 750 μA | ||
| U high (in) | 4 V | I = 200 μA | ||
| Frequency | 4 kHz | |||
| U low (out) | 1,0 V | I = 1 mA | ||
| U high (out) | 4 V | I = 1 mA |
- INT_009The input/output signal shall comply with the following timing diagrams:
- Image omitted; see official source
Appendix 7
DATA DOWNLOADING PROTOCOLS
| TABLE OF CONTENT | TABLE OF CONTENT |
| 1. | INTRODUCTION |
| 1.1. | Scope |
| 1.2. | Acronyms and notations |
| 2. | V.U. DATA DOWNLOADING |
| 2.1. | Download procedure |
| 2.2. | Data download protocol |
| 2.2.1 | Message structure |
| 2.2.2 | Message types |
| 2.2.2.1 | Start Communication Request (SID 81) |
| 2.2.2.2 | Positive Response Start Communication (SID C1) |
| 2.2.2.3 | Start Diagnostic Session Request (SID 10) |
| 2.2.2.4 | Positive Response Start Diagnostic (SID 50) |
| 2.2.2.5 | Link Control Service (SID 87) |
| 2.2.2.6 | Link Control Positive Response (SID C7) |
| 2.2.2.7 | Request Upload (SID 35) |
| 2.2.2.8 | Positive Response Request Upload (SID 75) |
| 2.2.2.9 | Transfer Data Request (SID 36) |
| 2.2.2.10 | Positive Response Transfer Data (SID 76) |
| 2.2.2.11 | Request Transfer Exit (SID 37) |
| 2.2.2.12 | Positive Response Request Transfer Exit (SID 77) |
| 2.2.2.13 | Stop Communication Request (SID 82) |
| 2.2.2.14 | Positive Response Stop Communication (SID C2) |
| 2.2.2.15 | Acknowledge Sub Message (SID 83) |
| 2.2.2.16 | Negative Response (SID 7F) |
| 2.2.3 | Message flow |
| 2.2.4 | Timing |
| 2.2.5 | Error handling |
| 2.2.5.1 | Start Communication phase |
| 2.2.5.2 | Communication phase |
| 2.2.6 | Response Message content |
| 2.2.6.1 | Positive Response Transfer Data Download Interface Version |
| 2.2.6.2 | Positive Response Transfer Data Overview |
| 2.2.6.3 | Positive Response Transfer Data Activities |
| 2.2.6.4 | Positive Response Transfer Data Events and Faults |
| 2.2.6.5 | Positive Response Transfer Data Detailed Speed |
| 2.2.6.6 | Positive Response Transfer Data Technical Data |
| 2.3. | ESM File storage |
| 3. | TACHOGRAPH CARDS DOWNLOADING PROTOCOL |
| 3.1. | Scope |
| 3.2. | Definitions |
| 3.3. | Card Downloading |
| 3.3.1 | Initialisation sequence |
| 3.3.2 | Sequence for un-signed data files |
| 3.3.3 | Sequence for Signed data files |
| 3.3.4 | Sequence for resetting the calibration counter. |
| 3.4. | Data storage format |
| 3.4.1 | Introduction |
| 3.4.2 | File format |
| 4. | DOWNLOADING A TACHOGRAPH CARD VIA A VEHICLE UNIT. |
INTRODUCTION
This appendix specifies the procedures to follow in order to perform the different types of data download to an External Storage Medium, together with the protocols that must be implemented to assure the correct data transfer and the full compatibility of the downloaded data format to allow any controller to inspect these data and be able to control their authenticity and their integrity before analysing them.
1.1. Scope
Data may be downloaded to an ESM:
- — from a Vehicle Unit by an Intelligent Dedicated Equipment (IDE) connected to the VU,
- — from a tachograph card by an IDE fitted with a card interface device (IFD),
- — from a tachograph card via a vehicle unit by an IDE connected to the VU.
To give the possibility to verify the authenticity and integrity of downloaded data stored on an ESM, data is downloaded with a signature appended in 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.
Data downloaded from a VU are signed using Appendix 11 Common Security Mechanisms Part B (Second-generation tachograph system), except when drivers' control is performed by a non EU control authority, using a first generation control card, in which case data are signed using Appendix 11 Common Security Mechanisms Part A (First-generation tachograph system), as requested by Appendix 15 Migration, requirement MIG_015.
This Appendix specifies therefore two types of data downloads from the VU:
- — Generation 2 type of VU data download, providing the generation 2 data structure, signed using Appendix 11 Common Security Mechanisms Part B,
- — Generation 1 type of VU data download, providing the generation 1 data structure, signed using Appendix 11 Common Security Mechanisms Part A.
Similarly, there are two types of data downloads from second generation driver cards inserted in a VU, as specified in paragraphs 3 and 4 of this Appendix.
1.2. Acronyms and notations
The following acronyms are used in this appendix:
- AID Application Identifier
- ATR Answer To Reset
- CS Checksum byte
- DF Dedicated File
- DS_ Diagnostic Session
- EF Elementary File
- ESM External Storage Medium
- FID File Identifier (File ID)
- FMT Format Byte (first byte of message header)
- ICC Integrated Circuit Card
- IDE Intelligent Dedicated Equipment: The equipment used to perform data downloading to the ESM (e.g. Personal Computer)
- IFD Interface Device
- KWP Keyword Protocol 2000
- LEN Length Byte (last byte of message header)
- PPS Protocol Parameter Selection
- PSO Perform Security Operation
- SID Service Identifier
- SRC Source byte
- TGT Target Byte
- TLV Tag Length Value
- TREP Transfer Response Parameter
- TRTP Transfer Request Parameter
- VU Vehicle Unit
V.U. DATA DOWNLOADING
2.1. Download procedure
In order to carry on a VU data download, the operator must perform the following operations:
- — Insert his tachograph card inside a card slot of the VU ([^E0013]);
- — Connect the IDE to the VU download connector;
- — Establish the connection between the IDE and the VU;
- — Select on the IDE the data to download and send the request to the VU;
- — Close the download session.
2.2. Data download protocol
The protocol is structured on a master-slave basis, with the IDE playing the master role and the VU playing the slave role.
The message structure, types and flow are principally based on the Keyword Protocol 2000 (KWP) (ISO 14230-2 Road vehicles — Diagnostic systems — Keyword protocol 2000 — Part2: Data link layer).
The application layer is principally based on the current draft to date of ISO 14229-1 (Road vehicles — Diagnostic systems — Part 1: Diagnostic services, version 6 of 22 February 2001).
2.2.1 Message structure
- DDP_002All the messages exchanged between the IDE and the VU are formatted with a structure consisting of three parts:
- — Header composed by a Format byte (FMT), a Target byte (TGT), a Source byte (SRC) and possibly a Length byte (LEN),
- — Data field composed by a Service Identifier byte (SID) and a variable number of data bytes, which can include an optional diagnostic session byte (DS_) or an optional transfer parameter byte (TRTP or TREP).
- — Checksum composed by a Checksum byte (CS).
| Header | Header | Header | Header | Data field | Data field | Data field | Data field | Data field | Checksum |
|---|---|---|---|---|---|---|---|---|---|
| FMT | TGT | SRC | LEN | SID | DATA | … | … | … | CS |
| 4 bytes | 4 bytes | 4 bytes | 4 bytes | Max 255 bytes | Max 255 bytes | Max 255 bytes | Max 255 bytes | Max 255 bytes | 1 byte |
- The 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.
- The LEN byte is the length of the Data field part.
- The Checksum byte is the 8 bit sum series modulo 256 of all the bytes of the message excluding the CS itself.
- FMT, SID, DS_, TRTP and TREP bytes are defined later in this document.
- DDP_003In 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 sub messages. Each sub message bears a header, the same SID, TREP and a 2-byte sub message counter indicating the sub message number within the total message. To enable error checking and abort the IDE acknowledges every sub message. The IDE can accept the sub message, ask for it to be re-transmitted, request the VU to start again or abort the transmission.
- DDP_004If the last sub message contains exactly 255 bytes in the data field, a final sub message with an empty (except SID TREP and sub message counter) data field must be appended to show the end of the message.
- Example:
| Header | SID | TREP | Message | CS |
|---|---|---|---|---|
| 4 Bytes | Longer than 255 Bytes | Longer than 255 Bytes | Longer than 255 Bytes |
- Will be transmitted as:
| Header | SID | TREP | 00 | 01 | Sub message 1 | CS |
|---|---|---|---|---|---|---|
| 4 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | |
| Header | SID | TREP | 00 | 02 | Sub message 2 | CS |
| --- | --- | --- | --- | --- | --- | --- |
| 4 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes |
- …
| Header | SID | TREP | xx | yy | Sub message n | CS |
|---|---|---|---|---|---|---|
| 4 Bytes | Less than 255 Bytes | Less than 255 Bytes | Less than 255 Bytes | Less than 255 Bytes | Less than 255 Bytes |
- or as:
| Header | SID | TREP | 00 | 01 | Sub message 1 | CS |
|---|---|---|---|---|---|---|
| 4 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | |
| Header | SID | TREP | 00 | 02 | Sub message 2 | CS |
| --- | --- | --- | --- | --- | --- | --- |
| 4 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes |
- …
| Header | SID | TREP | xx | yy | Sub message n | CS |
|---|---|---|---|---|---|---|
| 4 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | 255 Bytes | |
| Header | SID | TREP | xx | yy + 1 | CS | |
| --- | --- | --- | --- | --- | --- | |
| 4 Bytes | 4 bytes | 4 bytes | 4 bytes | 4 bytes |
2.2.2 Message types
The communication protocol for data download between the VU and the IDE requires the exchange of 8 different message types.
The following table summarises these messages.
| Message Structure | Message Structure | Max 4 Bytes | Max 4 Bytes | Max 4 Bytes | Max 4 Bytes | Max 255 Bytes | Max 255 Bytes | Max 255 Bytes | 1 Byte |
|---|---|---|---|---|---|---|---|---|---|
| Header | Header | Header | Header | Data | Data | Data | CheckSum | ||
| IDE -> | <- VU | FMT | TGT | SRC | LEN | SID | DS_ / TRTP | DATA | CS |
| Start Communication Request | Start Communication Request | 81 | EE | F0 | 81 | E0 | |||
| Positive Response Start Communication | Positive Response Start Communication | 80 | F0 | EE | 03 | C1 | EA, 8F | 9B | |
| Start Diagnostic Session Request | Start Diagnostic Session Request | 80 | EE | F0 | 02 | 10 | 81 | F1 | |
| Positive Response Start Diagnostic | Positive Response Start Diagnostic | 80 | F0 | EE | 02 | 50 | 81 | 31 | |
| Link Control Service | Link Control Service | ||||||||
| Verify Baud Rate (stage 1) | Verify Baud Rate (stage 1) | ||||||||
| 9 600 Bd | 9 600 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,01 | EC |
| 19 200 Bd | 19 200 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,02 | ED |
| 38 400 Bd | 38 400 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,03 | EE |
| 57 600 Bd | 57 600 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,04 | EF |
| 115 200 Bd | 115 200 Bd | 80 | EE | F0 | 04 | 87 | 01 | 01,05 | F0 |
| Positive Response Verify Baud Rate | Positive Response Verify Baud Rate | 80 | F0 | EE | 02 | C7 | 01 | 28 | |
| Transition Baud Rate (stage 2) | Transition Baud Rate (stage 2) | 80 | EE | F0 | 03 | 87 | 02 | 03 | ED |
| Request Upload | Request Upload | 80 | EE | F0 | 0A | 35 | 00,00,00,00,00,FF,FF, FF,FF | 99 | |
| Positive Response Request Upload | Positive Response Request Upload | 80 | F0 | EE | 03 | 75 | 00,FF | D5 | |
| Transfer Data Request | Transfer Data Request | ||||||||
| Download interface version | Download interface version | 80 | EE | F0 | 02 | 36 | 00 | 96 | |
| Overview | Overview | 80 | EE | F0 | 02 | 36 | 01, 21 or 31 | CS | |
| Activities | Activities | 80 | EE | F0 | 06 | 36 | 02, 22 or 32 | Date | CS |
| Events & Faults | Events & Faults | 80 | EE | F0 | 02 | 36 | 03, 23 or 33 | Date | CS |
| Detailed Speed | Detailed Speed | 80 | EE | F0 | 02 | 36 | 04 or 24 | Date | CS |
| Technical Data | Technical Data | 80 | EE | F0 | 02 | 36 | 05, 25 or 35 | Date | CS |
| Card download | Card download | 80 | EE | F0 | 02 or 03 | 36 | 06 | Slot | CS |
| Positive Response Transfer Data | Positive Response Transfer Data | 80 | F0 | EE | Len | 76 | TREP | Data | CS |
| Request Transfer Exit | Request Transfer Exit | 80 | EE | F0 | 01 | 37 | 96 | ||
| Positive Response Request Transfer Exit | Positive Response Request Transfer Exit | 80 | F0 | EE | 01 | 77 | D6 | ||
| Stop Communication Request | Stop Communication Request | 80 | EE | F0 | 01 | 82 | E1 | ||
| Positive Response Stop Communication | Positive Response Stop Communication | 80 | F0 | EE | 01 | C2 | 21 | ||
| Acknowledge sub message | Acknowledge sub message | 80 | EE | F0 | Len | 83 | Data | CS | |
| Negative responses | Negative responses | ||||||||
| General reject | General reject | 80 | F0 | EE | 03 | 7F | Sid Req | 10 | CS |
| Service not supported | Service not supported | 80 | F0 | EE | 03 | 7F | Sid Req | 11 | CS |
| Sub function not supported | Sub function not supported | 80 | F0 | EE | 03 | 7F | Sid Req | 12 | CS |
| Incorrect Message Length | Incorrect Message Length | 80 | F0 | EE | 03 | 7F | Sid Req | 13 | CS |
| Conditions not correct or Request sequence error | Conditions not correct or Request sequence error | 80 | F0 | EE | 03 | 7F | Sid Req | 22 | CS |
| Request out of range | Request out of range | 80 | F0 | EE | 03 | 7F | Sid Req | 31 | CS |
| Upload not accepted | Upload not accepted | 80 | F0 | EE | 03 | 7F | Sid Req | 50 | CS |
| Response pending | Response pending | 80 | F0 | EE | 03 | 7F | Sid Req | 78 | CS |
| Data not available | Data not available | 80 | F0 | EE | 03 | 7F | Sid Req | FA | CS |
Notes:
- — Sid Req = the Sid of the corresponding request.
- — TREP = the TRTP of the corresponding request.
- — Dark cells denote that nothing is transmitted.
- — The term upload (as seen from the IDE) is used for compatibility with ISO 14229. It means the same as download (as seen from the VU).
- — Potential 2-byte sub message counters are not shown in this table.
- — Slot is the slot number, either ‘1’ (card on driver slot) or ‘2’ (card on co-driver slot).
- — In case the slot is not specified, the VU shall select slot 1 if a card is inserted in this slot and it shall select slot 2 only in case it is specifically selected by the user.
- — TRTP 24 is used for Generation 2, for version 1 and version 2 type of VU data download requests.
- — TRTP 00, 31, 32, 33 and 35 are used for Generation 2 version 2 type of VU data download requests.
- — TRTP 21, 22, 23, and 25 are used for Generation 2 version 1 type of VU data download requests.
- — TRTP 01 to 05 are used for Generation 1 type of VU data download requests. They can optionally be accepted by Generation 2 type of VU, but only in the frame of drivers' control performed by a non-EU control authority, using a first generation control card.
- — TRTP 11 to 1F are reserved for manufacturer specific download requests.
2.2.2.1 Start Communication Request (SID 81)
- DDP_005This message is issued by the IDE to establish the communication link with the VU. Initial communications are always performed at 9 600 baud (until baud rate is eventually changed using the appropriate Link control services).
2.2.2.2 Positive Response Start Communication (SID C1)
- DDP_006This message is issued by the VU to answer positively to a start communication request. It includes the 2 key bytes ‘EA’‘8F’ indicating that the unit supports protocol with header including target source and length information.
2.2.2.3 Start Diagnostic Session Request (SID 10)
- DDP_007The Start Diagnostic Session request message is issued by the IDE in order to request a new diagnostic session with the VU. The sub function ‘default session’ (81 Hex) indicates a standard diagnostic session is to be opened.
2.2.2.4 Positive Response Start Diagnostic (SID 50)
- DDP_008The Positive Response Start Diagnostic message is sent by the VU to answer positively to Diagnostic Session Request.
2.2.2.5 Link Control Service (SID 87)
- DDP_052The Link Control Service is used by the IDE to initiate a change in baud rate. This takes place in two steps. In step one the IDE proposes the baud rate change, indicating the new rate. On receipt of a positive message from the VU the IDE sends out confirmation of the baud rate change to the VU (step two). The IDE then changes to the new baud rate. After receipt of the confirmation the VU changes to the new baud rate
2.2.2.6 Link Control Positive Response (SID C7)
- DDP_053The Link Control Positive Response is issued by the VU to answer positively to Link Control Service request (step one). Note that no response is given to the confirmation request (step two).
2.2.2.7 Request Upload (SID 35)
- DDP_009The Request Upload message is issued by the IDE to specify to the VU that a download operation is requested. To meet the requirements of ISO14229 data is included covering address, the size and format details for the data requested. As these are not known to the IDE prior to a download, the memory address is set to 0, format is unencrypted and uncompressed and the memory size is set to the maximum.
2.2.2.8 Positive Response Request Upload (SID 75)
- DDP_010The Positive Response Request Upload message is sent by the VU to indicate to the IDE that the VU is ready to download data. To meet the requirements of ISO 14229 data is included in this positive response message, indicating to the IDE that further Positive Response Transfer Data messages will include 00FF hex bytes maximum.
2.2.2.9 Transfer Data Request (SID 36)
- DDP_011The Transfer Data Request is sent by the IDE to specify to the VU the type of data that are to be downloaded. A one byte Transfer Request Parameter (TRTP) indicates the type of transfer.
- There are seven types of data transfer. For VU data download, two different TRTP values can be used for each transfer type:
| Data transfer type | TRTP value for generation 1 type of VU data download | TRTP value for generation 2, version 1 type of VU data download | TRTP value for generation 2, version 2 type of VU data download |
|---|---|---|---|
| Download interface version | Not used | Not used | 00 |
| Overview | 01 | 21 | 31 |
| Activities of a specified date | 02 | 22 | 32 |
| Events and faults | 03 | 23 | 33 |
| Detailed speed | 04 | 24 | 24 |
| Technical data | 05 | 25 | 35 |
| --- | --- | ||
| Data transfer type | TRTP value | ||
| Card download | 06 |
- DDP_054It is mandatory for the IDE to request the overview data transfer (TRTP 01, 21 or 31) during a download session as this only will ensure that the VU certificates are recorded within the downloaded file (and allow for verification of digital signature).
- In the third case (TRTP 02, 22 or 32) the Transfer Data Request message includes the indication of the calendar day (TimeReal format) to be downloaded.
2.2.2.10 Positive Response Transfer Data (SID 76)
- DDP_012The 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.
- DDP_055In the first case (TREP 01, 21 or 31), the VU will send data helping the IDE operator to choose the data he wants to download further. The information contained within this message is:
- — Security certificates,
- — Vehicle identification,
- — VU current date and time,
- — Min and Max downloadable date (VU data),
- — Indication of cards presence in the VU,
- — Previous download to a company,
- — Company locks,
- — Previous controls.
2.2.2.11 Request Transfer Exit (SID 37)
- DDP_013The Request Transfer Exit message is sent by the IDE to inform the VU that the download session is terminated.
2.2.2.12 Positive Response Request Transfer Exit (SID 77)
- DDP_014The Positive Response Request Transfer Exit message is sent by the VU to acknowledge the Request Transfer Exit.
2.2.2.13 Stop Communication Request (SID 82)
- DDP_015The Stop Communication Request message is sent by the IDE to disconnect the communication link with the VU.
2.2.2.14 Positive Response Stop Communication (SID C2)
- DDP_016The Positive Response Stop Communication message is sent by the VU to acknowledge the Stop Communication Request.
2.2.2.15 Acknowledge Sub Message (SID 83)
- DDP_017The Acknowledge Sub Message is sent by the IDE to confirm receipt of each part of a message that is being transmitted as several sub messages. The data field contains the SID received from the VU and a 2-byte code as follows:
- — MsgC+1 Acknowledges correct receipt of sub message number MsgC.
Request from the IDE to the VU to send next sub message
- — MsgC indicates a problem with the receipt of sub message number MsgC. Request from the IDE to the VU to send the sub message again.
- — FFFF requests termination of the message. This can be used by the IDE to end the transmission of the VU message for any reason.
- The last sub message of a message (LEN byte < 255) may be acknowledged using any of these codes or not acknowledged.
- The VU responses that will consist of several sub messages are:
- — Positive Response Transfer Data (SID 76)
2.2.2.16 Negative Response (SID 7F)
- DDP_018The Negative Response message is sent by the VU in response to the above request messages when the VU cannot satisfy the request. The data fields of the message contains the SID of the response (7F), the SID of the request, and a code specifying the reason of the negative response. The following codes are available:
- — 10 general reject The action cannot be performed for a reason not covered below.
- — 11 service not supported The SID of the request is not understood.
- — 12 sub function not supported The DS_ or TRTP of the request is not understood, or there are no further sub messages to be transmitted.
- — 13 incorrect message length The length of the received message is wrong.
- — 22 conditions not correct or request sequence error The required service is not active or the sequence of request messages is not correct.
- — 31 Request out of range The request parameter record (data field) is not valid.
Reading this document does not replace reading the official text published in the Official Journal of the European Union. We assume no responsibility for any inaccuracies arising from the conversion of the original to this format.
This text is published under EUR-Lex's own terms of reuse, not a Legalize or public-domain licence.
EUR-Lex
Creative Commons Attribution 4.0 International (CC BY 4.0)
© European Union, https://eur-lex.europa.eu — Source: EUR-Lex (Publications Office of the European Union). Reused under the Creative Commons Attribution 4.0 International (CC BY 4.0) licence. Only EU legislation published in the printed Official Journal of the European Union is deemed authentic; consolidated texts are reproduced here for documentation purposes and have been reformatted to Markdown.