ISO 14816:2005
(Main)Road transport and traffic telematics — Automatic vehicle and equipment identification — Numbering and data structure
Road transport and traffic telematics — Automatic vehicle and equipment identification — Numbering and data structure
ISO 14816:2005 establishes a common framework data structure for unambiguous identification in RTTT/ITS systems. It excludes any physical aspects such as interfaces. It is neither frequency- nor air interface protocol-specific. Data elements that form part of transmission or storage protocols such as headers, frame markers and checksums are thus excluded. The specifications for protecting against changes, classifying and qualifying security aspects of the data structure elements are not included within ISO 14816:2005. The principles of data element structure and description determined in ISO/IEC 8824, ISO/IEC 8825-1 and ISO/IEC 8825-2 have been adopted to provide an interoperable architecture within a standard framework according to guidelines from ISO/TC 204 and CEN/TC 278. ISO 14816:2005 defines data structures based on the ISO/IEC 8824-1 ASN.1 UNIVERSAL CLASS types that may be directly IMPORTED to other application standards that would need only subsets of the full APPLICATION CLASS types. These UNIVERSAL CLASS and APPLICATION CLASS types are uniquely defined as an ASN.1 module in Annex B. This module may be directly linked into an application data definition. ISO 14816:2005 defines default encoding for simple AVI/AEI applications where no other relevant application standard exists. This definition forms Clause 4.
Télématique de la circulation et du transport routier — Identification automatique des véhicules et des équipements — Codification et structure des données
La présente Norme internationale établit une structure de données au cadre commun permettant une identification univoque au sein de systèmes RTTT/ITS. Elle exclut tous les aspects physiques tels que les interfaces. Elle ne se rapporte à aucun protocole d'interface radio-fréquence. Les éléments de données faisant partie des protocoles de transmission ou de stockage tels que les en-têtes, les repères de trame et les sommes de contrôle en sont donc exclus. Les spécifications relatives à la protection contre les changements, la classification et la qualification des aspects relatifs à la sécurité des éléments de structures de données ne sont pas couvertes par la présente Norme internationale. Les principes relatifs à la structure des éléments de données et à leur description déterminés dans l'ISO/IEC 8824, l'ISO/IEC 8825‑1 et l'ISO/IEC 8825‑2 ont été adoptés afin de fournir une architecture interopérable au sein d'un cadre normalisé selon les consignes des ISO/TC 204 et CEN/TC 278. La présente Norme internationale définit des structures de données fondées sur les types CLASSE UNIVERSELLE (universal class) de l'ASN.1 de l'ISO/IEC 8824‑1 qui peuvent être directement IMPORTÉS vers d'autres normes d'application et nécessiteraient uniquement des sous-ensembles des types complets de CLASSE APPLICATION (application class). Ces types UNIVERSAL CLASS et APPLICATION CLASS sont définis de manière univoque en tant que module de l'ASN.1 à l'Annexe B. Ce module peut être directement associé à une définition de données d'application. La présente Norme internationale définit un codage par défaut pour les applications AVI/AEI simples, lorsqu'aucune norme d'application pertinente n'existe. Cette définition fait l'objet de l'Article 4.
General Information
Relations
Standards Content (Sample)
INTERNATIONAL ISO
STANDARD 14816
First edition
2005-11-01
Road transport and traffic telematics —
Automatic vehicle and equipment
identification — Numbering and data
structure
Télématique de la circulation et du transport routier — Identification
automatique des véhicules et équipements — Codification et structure
des données
Reference number
©
ISO 2005
PDF disclaimer
This PDF file may contain embedded typefaces. In accordance with Adobe's licensing policy, this file may be printed or viewed but
shall not be edited unless the typefaces which are embedded are licensed to and installed on the computer performing the editing. In
downloading this file, parties accept therein the responsibility of not infringing Adobe's licensing policy. The ISO Central Secretariat
accepts no liability in this area.
Adobe is a trademark of Adobe Systems Incorporated.
Details of the software products used to create this PDF file can be found in the General Info relative to the file; the PDF-creation
parameters were optimized for printing. Every care has been taken to ensure that the file is suitable for use by ISO member bodies. In
the unlikely event that a problem relating to it is found, please inform the Central Secretariat at the address given below.
© ISO 2005
All rights reserved. Unless otherwise specified, no part of this publication may be reproduced or utilized in any form or by any means,
electronic or mechanical, including photocopying and microfilm, without permission in writing from either ISO at the address below or
ISO's member body in the country of the requester.
ISO copyright office
Case postale 56 • CH-1211 Geneva 20
Tel. + 41 22 749 01 11
Fax + 41 22 749 09 47
E-mail copyright@iso.org
Web www.iso.org
Published in Switzerland
ii © ISO 2005 – All rights reserved
Contents Page
Foreword. iv
Introduction . v
1 Scope . 1
1.1 Overall numbering scheme. 1
1.2 AVI/AEI numbering scheme. 1
2 Normative references . 2
3 Terms, definitions and notations . 3
4 Requirements . 3
4.1 Overall coding structure . 3
4.2 General requirements. 3
4.3 Data structure. 4
4.4 Residency of data . 4
4.5 Table of coding structure identifiers . 5
4.6 Coding structure data elements (AVI/AEI applications) . 5
4.7 CS1- AVI/AEI Numbering scheme . 6
4.8 CS2-Manufacturers numbering . 7
4.9 CS3 – Validity limitation . 7
4.10 CS4 – Vehicle license number coding. 10
4.11 CS5 – Vehicle Identification Number (VIN).11
4.12 CS6 – Reserved for CEN/ISO . 12
4.13 CS7 – Freight container numbering. 12
4.14 CS8 – Tax authority code. 13
Annex A (normative) Management and general rules for the administration of coding structures
CS1, CS2 and CS8. 14
Annex B (normative) A summary of CS definitions. 24
Annex C (informative) Examples on the use of AVI/AEI coding structures . 28
Bibliography . 35
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards bodies
(ISO member bodies). The work of preparing International Standards is normally carried out through ISO
technical committees. Each member body interested in a subject for which a technical committee has been
established has the right to be represented on that committee. International organizations, governmental and
non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely with the
International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
International Standards are drafted in accordance with the rules given in the ISO/IEC Directives, Part 2.
The main task of technical committees is to prepare International Standards. Draft International Standards
adopted by the technical committees are circulated to the member bodies for voting. Publication as an
International Standard requires approval by at least 75 % of the member bodies casting a vote.
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights.
ISO 14816 was prepared by Technical Committee ISO/TC 204, Intelligent transport systems, in collaboration
with Technical Committee CEN/TC 278, Road transport and traffic telematics.
This first edition cancels and replaces (ISO/TS 14816:2000).
iv © ISO 2005 – All rights reserved
Introduction
This International Standard specifies a data structure that enables upwards integration and expansion from
the simplest low-cost AVI/AEI system to more complex functions. The structure is designed to be flexible and
enabling rather than prescriptive.
This International Standard has been designed to provide for the differing requirements of AVI and AEI by the
use of separate application specifics. By retaining these differing requirements within one supervisory
document, the interoperability is maximized, particularly in the case where both AVI and AEI are required at
the same time in the road environment.
In order to support systems using both active and passive On Board Equipment (OBE), the basic data
structures have been minimized. This enables any manufacturer/operator with an OBE with a user
addressable memory of only 56 bits to be able to conform to a full core identification according to this
International Standard.
Abstract Syntax Notation One (ASN.1) is widely applied. Its usage provides maximum interoperability and
conformance to existing International Standards, and meets the specifically defined requirements for a generic
standard model for RTTT in that it:
⎯ Uses existing standard Syntax Notation and Encoding Rules,
⎯ Is adaptable and expandable,
⎯ Does not include unnecessary information for a specific system, and
⎯ Incurs a minimum of overhead in storage and transmission.
Readers who are unfamiliar with ASN.1 are advised to read ANNEX C before reading the main body of this
International Standard. Readers are also advised to read ISO/IEC 8824, ISO/IEC 8825-1, ISO/IEC 8825-2 and
ISO/IEC 8825-3 and other published work on ASN.1 before reading the main body of this International
Standard.
ISO 14814 provides a reference architecture model for AVI/AEI systems.
Sections 4.1-4.6 of ISO 14816 provide a standardized yet flexible and interoperable framework for numbering
schemes. A structure for AVI/AEI unambiguous identification and several numbering schemes associated with
AVI/AEI systems are determined in this International Standard.
The core AVI/AEI numbering scheme, central to the effective use of many of the constructs, is a structure to
provide unambiguous identification. 4.7 of this International Standard provides a data element coding for
Automatic Vehicle and Equipment Identification (AVI/AEI) in RTTT applications. This coding provides a
structure with the possibility of 2 (in excess of 72 million billions) unique identifiers, provided within a 56-bit
code structure when ISO/IEC 8825-2 (PER) is used, i.e. no overhead is incurred.
INTERNATIONAL STANDARD ISO 14816:2005(E)
Road transport and traffic telematics — Automatic vehicle and
equipment identification — Numbering and data structure
1 Scope
1.1 Overall numbering scheme
This International Standard establishes a common framework data structure for unambiguous identification in
RTTT/ITS systems. It excludes any physical aspects such as interfaces. It is neither frequency- nor air
interface protocol-specific.
Data elements that form part of transmission or storage protocols such as headers, frame markers and
checksums are thus excluded.
The specifications for protecting against changes, classifying and qualifying security aspects of the data
structure elements are not included within this International Standard.
The principles of data element structure and description determined in ISO/IEC 8824, ISO/IEC 8825-1 and
ISO/IEC 8825-2 have been adopted to provide an interoperable architecture within a standard framework
according to guidelines from ISO/TC 204 and CEN/TC 278.
This International Standard defines data structures based on the ISO/IEC 8824-1 ASN.1 UNIVERSAL CLASS
types that may be directly IMPORTED to other application standards that would need only subsets of the full
APPLICATION CLASS types. These UNIVERSAL CLASS and APPLICATION CLASS types are uniquely
defined as an ASN.1 module in Annex B. This module may be directly linked into an application data definition.
This International Standard defines default encoding for simple AVI/AEI applications where no other relevant
application standard exists. This definition forms Clause 4.
1.2 AVI/AEI numbering scheme
The principal registered schemes for AVI/AEI are determined in 4.7 and 4.8 of this International Standard.
Other relevant and interoperable schemes are detailed in subsequent clauses and subclauses.
The structures defined in this International Standard provide interoperability, not only between simple AVI/AEI
and more complex RTTT/ITS functions, but also with pre-existing International Standards (e.g. ISO 10374).
There is one Central Registration Authority that administers the AVI numbering scheme according to the rules
of CEN and ISO (see Annex A).
The choices available to the issuer to operate its structure include, amongst others:
⎯ simple identification, in which case the separate identities may be openly available, at the discretion of the
issuer or nation state;
⎯ an alias basis, in which case the “identities” are known, but secured under provisions of data protection to
maintain privacy and therefore not available; and
⎯ dynamically encrypted identities in an anonymous system.
2 Normative references
The following referenced documents are indispensable for the application of this document. For dated
references, only the edition cited applies. For undated references, the latest edition of the referenced
document (including any amendments) applies.
ISO 3166-1, Codes for the representation of names of countries and their subdivisions — Part 1: Country
codes
ISO 3779, Road vehicles — Vehicle identification number (VIN) — Content and structure
ISO 3780, Road vehicles — World manufacturer identifier (WMI) code
ISO 6346, Freight containers — Coding, identification and marking
ISO/IEC 8824-1, Information technology — Abstract Syntax Notation One (ASN.1) — Part 1: Specification of
basic notation
ISO/IEC 8825-1, Information technology — ASN.1 encoding rules — Part 1: Specification of Basic Encoding
Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules — Part 2: Specification of Packed Encoding
Rules (PER)
ISO/IEC 8859-1, Information technology — 8-bit single-byte coded graphic character sets — Part 1: Latin
alphabet No.1
ISO/IEC 8859-2, Information technology — 8-bit single-byte coded graphic character sets — Part 2: Latin
alphabet No. 2
ISO/IEC 8859-3, Information technology — 8-bit single-byte coded graphic character sets — Part 3: Latin
alphabet No. 3
ISO/IEC 8859-4, Information technology — 8-bit single-byte coded graphic character sets — Part 4: Latin
alphabet No. 4
ISO/IEC 8859-5, Information technology — 8-bit single-byte coded graphic character sets — Part 5:
Latin/Cyrillic alphabet
ISO/IEC 8859-6, Information technology — 8-bit single-byte coded graphic character sets — Part 6:
Latin/Arabic alphabet
ISO/IEC 8859-7, Information technology — 8-bit single-byte coded graphic character sets — Part 7:
Latin/Greek alphabet
ISO/IEC 8859-8, Information technology — 8-bit single-byte coded graphic character sets — Part 8:
Latin/Hebrew alphabet
ISO/IEC 8859-9, Information technology — 8-bit single-byte coded graphic character sets — Part 9: Latin
alphabet No. 5
ISO/IEC 8859-10, Information technology — 8-bit single-byte coded graphic character sets — Part 10: Latin
alphabet No. 6
ISO 10374, Freight containers — Automatic identification
ISO/IEC 10646-1, Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 1:
Architecture and Basic Multilingual Plane
2 © ISO 2005 – All rights reserved
ISO/TR 14813-3, Transport information and control systems — Reference model architecture(s) for the TICS
sector — Part 3: Example elaboration
ISO 14814, Road transport and traffic telematics — Automatic vehicle and equipment identification —
Reference architecture and terminology
3 Terms, definitions and notations
For the purposes of this document, the terms and definitions given in ISO 14814 apply.
The term “Issuer” applies to any of the coding schemes CS1, CS2 and CS8.
Numerical notations are represented as follows:
⎯ Decimal (“normal”) notation has no subscript.
EXAMPLE 127.
⎯ Hexadecimal numbers are noted by subscript 16.
EXAMPLE Example: 7F .
⎯ Binary numbers are noted by subscript 2.
EXAMPLE Example: 01111111 .
Characters are represented as follows:
⎯ Characters have no subscript or quotes.
EXAMPLE ABC5EFD.
4 Requirements
4.1 Overall coding structure
The AVI/AEI coding structure determined in this International Standard:
⎯ is unambiguous and flexible enough to include relevant transport related numbering schemes,
⎯ follows relevant International Standards, available at the time of writing,
⎯ provides an exact coding of the data elements,
⎯ is extendible to enable future expansion, and
⎯ is able to accommodate private structures.
4.2 General requirements
The coding structure determined in this International Standard is an “enabling” structure. It is designed to
accommodate, within its framework, coding structures for a variety of RTTT/ITS systems from simple AVI/AEI
to more complex transactions with a wide variety of uses, and to allow combinations of data elements to be
used in a composite data construct. It is designed to allow as much interoperability of the data elements within
an EDI/EDT environment as is possible, and provide capability for a significant expansion of the number of
RTTT/ITS applications in the future.
This International Standard recognizes and accommodates the operation of systems of different capabilities. It
shall enable, within its structure, the interoperability of one OBE in any country so long as there is a common
air interface and protocol, even though the operator systems themselves may be significantly different. Even
where information has to be collected by a separate interrogator because air interface compatibility does not
exist, the data, once collected, is in a commonly interoperable format, and may thus be used accurately and
effectively within an EDI/EDT environment.
The data structures defined in this International Standard enable “tree and branch” or “cascade” structures,
with the ability to build complex data element constructs.
This International Standard has been optimized for ISO/IEC 8825-2 as recommended by ISO/TS 14813-3.
It uses ISO/IEC 8824-1 in all its syntax descriptions.
By adopting the ISO/IEC 8824, ISO/IEC 8825-1, ISO/IEC 8825-2 and ISO/IEC 8825-3 Abstract Syntax
Notation (ASN.1), the flexibility is provided for data elements of any length and combination to be supported.
Also, this data structure standard is itself given a migration path so that, as technological developments allow
further capabilities, subsequent International Standards may provide additional data fields for use in all, or
some, sector-specific applications, whilst maintaining the upwards compatibility from and to this document.
The ASN.1 encoding rules enable the chaining of multiple data elements from different application sectors to
build complex data element constructs. (See examples in Annex C.)
4.3 Data structure
The data structuring requirements as defined in ISO/IEC 8824, ISO/IEC 8825-1, ISO/IEC 8825-2 and
ISO/IEC 8825-3 apply, and in particular ISO/TS 14813-3.
4.4 Residency of data
The data construct is designed to be free-standing and independent of the media. It therefore normally resides
in the OBE.
In specific cases, such as the standardized European DSRC 5.8 GHz link, where part of the message is
already known because of L7 services, the use of ASN.1Packed Encoding Rules (PER) proposed within this
International Standard enables only the unknown part of the message to be transferred, thus achieving
minimum redundancy.
The examples given in the remainder of this International Standard assume the use of ASN.1 PER. Where
Basic Encoding Rules (BER) are used, there is additional overhead as defined in ISO/IEC 8825-1. See
Annex C for implementation examples.
4 © ISO 2005 – All rights reserved
4.5 Table of coding structure identifiers
Table 1 — Coding structure identifiers
Coding Structure RTTT/ITS Coding Structure
Identifier (CSI) Number
0 Reserved for CEN/ISO
1 AVI/AEI for use in RTTT applications
2 RTTT Manufacturer Serial Number
3 RTTT Validity Limitation (Time and Place)
4 Licence Plate
5 Vehicle (VIN) Chassis Number
6 Reserved for CEN/ISO
7 Freight Container Numbering
8 Tax Authority Code
9 Reserved for CEN/ISO
... ...
30 Reserved for CEN/ISO
31 Reserved for CEN/ISO (Extension)
4.6 Coding structure data elements (AVI/AEI applications)
Table 2 shows the seven defined CS in a short form table detailing the primitive elements (UNIVERSAL
TYPES). The definitions are given in 4.7 and Annex C.
Table 2 — Minimum size of data elements
CSI Length Coding Structure Data Field
1 7 Octets / Country Code Issuer Identifier Service Number
56 bits 10 14 32
2 6 Octets / Manufacturer Identifier Service Number
48 bits 16 32
3 22 Octets / Start Time Stop Time Geographic Limit Application Limit
176 bits 80 80 8 8
4 Variable Country Code Alphabet Indicator Licence Plate Number
10 6 Not defined
5 17 Octets / Vehicle Identification (Chassis) Number
136 bits 136
6 Variable Reserved for CEN/ISO
Not defined
7 Freight Container Numbering
93 bits 93
8 Variable Country Code Tax Code
10 Not defined
NOTE 1 The overhead of each coding structure data field is excluded from the table. The numbers of bits in the data
fields are only indications when using PER as the coding rules.
NOTE 2 When the term “Service Number” is used in this International Standard, it indicates both “Service Code” and
“Unique Number”.
4.7 CS1- AVI/AEI Numbering scheme
4.7.1 General requirements
This AVI/AEI numbering scheme provides an unambiguous identification element of 56 bits (PER encoding) to
be held on the OBE. This data structure is designed to be used for simple AVI/AEI, and may also be used to
form the AVI/AEI element of RTTT messages where AVI/AEI is a component.
Registration procedures including the structures that are with National Issuing Authorities are mandatory for
this structure. Provisions for registration can be found in Annex A.
4.7.2 Data structure
4.7.2.1 Data structure elements
The format provides a “read only” On Board Equipment Permanent Code Mandatory Field providing specific
adaptation to the requirements for AVI/AEI in the RTTT/ITS environment.
Operators who wish to provide additional data fields, of read only or read/write nature, can do so by adding
additional ASN.1 identifier sets as described in Annex C.
4.7.2.2 ASN.1 Data type definitions
4.7.2.2.1 CS1 Definition
CS1::= SEQUENCE {
countryCode CountryCode,
issuerIdentifier IssuerIdentifier,
serviceNumber ServiceNumber
}
4.7.2.2.2 CountryCode definition
CountryCode::= BIT STRING(Size(10))
Value assignment is done in accordance with ISO 3166-1 and by using the ITA.2 alphabet. For value
assignment, please refer to: http://www.nen.nl/cen278/14816_NRAI_register_by_country.html.
4.7.2.2.3 IssuerIdentifier definition
IssuerIdentifier::= INTEGER(0 . 16383)
See Annex A for registration.
4.7.2.2.4 ServiceNumber definition
ServiceNumber::= BIT STRING(Size(32))
6 © ISO 2005 – All rights reserved
4.8 CS2-Manufacturers numbering
4.8.1 General requirements
Manufacturers numbering enables manufacturers to provide, if they so choose, a numbering system that is
independent of a particular country. It is expected that this numbering scheme will primarily be used as an
electronic serial number in systems requiring direct knowledge of manufacturer and equipment versions
(e.g. for QA/QC purposes). This number may also be used as a cryptographic hidden identity in systems with
a combination of anonymity and strong security requirements.
The following structure details the content of the manufacturers numbering data “primitive” and is to be read in
conjunction with the notes shown below the structure.
Registration procedures are similar to the procedures of CS1, with the exception that the structures are not
registered with any National Issuing Authority. Provisions for registration can be found in Clause 5.
4.8.2 Data structure
4.8.2.1 Data structure elements
Operators who wish to provide additional data fields, of read only or read/write nature, can do so by adding
additional ASN.1 identifier sets as described in Annex C.
4.8.2.2 Detailed data structure
The numbering scheme views the ID as a data element, and the common basic data structure is only a data
identifier code.
The framework of this data structure, into which the manufacturers numbering data field fits, follows the
principles defined in CS1 (AVI/AEI numbering scheme), and is applied in this structure as follows:
4.8.2.2.1 CS2 Definition
CS2::= SEQUENCE {
issuerIdentifier ManufacturerIdentifier,
serviceNumber ServiceNumber
}
4.8.2.2.2 ManufacturerIdentifier definition
ManufacturerIdentifier::= INTEGER(0 . 65535)
4.8.2.2.3 ServiceNumber definition
ServiceNumber is defined in 4.7.2.2.4.
4.9 CS3 – Validity limitation
4.9.1 General requirements
The validity limitation structure is a data element structure that specifies value(s) to provide limits, either in
time, geography or application.
The time limitation provides a starting or issuing date/time group formatted according to a UNIVERSAL ASN.1
TYPE, and an expiration date/time group formatted the same way. This type is referenced to universal
coordinated time (UTC, Z).
The geographical limitation restricts the use of the referenced number to the issuer area, district, country or
continent. It shall use the bit field described in 4.9.2.3.1.
Application or service limitation is to restrict the type of service for which this validity limitation number is
issued: post-payment, pre-payment, access control, fleet control, etc. The use of this parameter is valid for
issuers providing more than one service, and for users that want to avoid responsibility for a certain set of
these services. It shall use the bit field described in 4.9.2.3.2.
Registration procedures are not applicable in this case.
4.9.2 Data structure
4.9.2.1 Data structure elements
Operators who wish to provide additional data fields, of read only or read/write nature, can do so by adding
additional ASN.1 identifier sets as described in an example of Annex C.
4.9.2.2 Detailed data structure
4.9.2.2.1 CS3 Definition
CS3::= SEQUENCE {
startTime StartTime,
stopTime StopTime,
geographLimit GeoGraphicalLimit,
serviceAppLimit ServiceApplicationLimit
}
4.9.2.2.2 StartTime definition
StartTime::= UTCtime
Recommended format is YYMMDDhhmmZ.
NOTE Due care should be taken when implementing the applications to avoid the Year 2000 problems. As the
century component (CC) is not transferred, its value is inferred from the value of the year component (YY) by e.g. the
following rules:
⎯ if 80 <= YY <= 99 then CC = 19;
⎯ if 00 <= YY <= 50 then CC = 20.
4.9.2.3 StopTime definition
StopTime::= UTCtime
Recommended format is YYMMDDhhmmZ.
8 © ISO 2005 – All rights reserved
4.9.2.3.1 GeoGraphicalLimit definition
GeoGraphicalLimit::= BIT STRING {
globalRestriction (0),
regionalRestriction (1),
nationalRestriction (2),
district (3),
issuerCoverageRestriction (4),
reservedForCEN/ISO1 (5),
reservedForCEN/ISO2 (6),
issuerSpecificRestriction (7)
}
The restriction shall be active if bit position is set to 1 . If all bits are 0 , then there is no geographic restriction.
2 2
4.9.2.3.2 ServiceApplicationLimit definition
ServiceApplicationLimit::= BIT STRING {
notForPostpayment (0),
notForPrepayment (1),
notForVehicleaccess (2),
notForFleetcontrol (3),
issuerSpecificRestriction1 (4),
issuerSpecificRestriction2 (5),
issuerSpecificRestriction3 (6),
issuerSpecificRestriction4 (7)
}
The restriction shall be active if bit position is set to 1 . If all bits are 0 , then there is no restriction.
2 2
The lower order bits (0-3) are of a general nature and sets restrictions outside the area of the issuer. The
higher order bits (4-7) are for specific limitations inside the operator area.
EXAMPLE The following lines and show how the Validity Limitation value may be encoded:
⎯ Start/Issue Time : 93-01-01 (date), 12:00 (time);
⎯ Stop/Expire Time : 94-12-31 (date), 23:59 (time);
Geographical Limit : 01001011 ;
⎯ 2
Application Limit : 11111000
⎯ 2.
NOTE The Z-indicator is not used.
Table 3 — Example of validity limitation encoding
Start//Issue Time Stop//Expire Time Geographic Limit Application Limit
01001011 11111000
9301011200 9412312359
2 2
4.10 CS4 – Vehicle license number coding
4.10.1 General requirements
In some systems, there is a requirement to represent the vehicle licence plate number electronically. This
must be achieved unambiguously, and as the licence numbers in different nations/states/countries may be the
same, there is also a need to include a country identifier.
Because several nations/states/countries issue licence plates with non-Latin characters (such as Cyrillic or
Greek) there is a need to identify which character set is used. These two requirements are combined in this
CS4 vehicle licence number coding.
4.10.2 Data structure
4.10.2.1 Data structure elements
Authorities who wish to provide additional data fields, of read only or read/write nature, can do so by adding
additional ASN.1 identifier sets as described in Annex C.
4.10.2.2 ASN.1 Data type specifications
4.10.2.2.1 CS4 Definition
CS4::= SEQUENCE {
countryCode CountryCode,
alphabetIndicator AlphabetIndicator,
licPlateNumber OCTET STRING
}
4.10.2.2.2 CountryCode definition
CountryCode is defined in 4.7.2.2.2.
4.10.2.2.3 AlphabetIndicator definition
AlphabetIndicator::= ENUMERATED {
latinAlphabetNo1 (1), -- encoded as 00 00 00’B
latinAlphabetNo2 (2), -- encoded as 00 00 01’B etc
latinAlphabetNo3 (3),
latinAlphabetNo4 (4),
latinCyrillicAlphabet (5),
latinArabicAlphabet (6),
latinGreekAlphabet (7),
latinHebrewAlphabet (8),
latinAlphabetNo5 (9),
latinAlphabetNo6 (10),
twoOctetBMP (11),
fourOctetCanonical (12),
reservedForUse1 (13),
10 © ISO 2005 – All rights reserved
reservedForUse2 (14),
reservedForUse3 (15),
reservedForUse4 (16),
reservedForUse5 (17),
reservedForUse6 (18),
reservedForUse7 (19),
reservedForUse8 (20),
reservedForUse9 (21),
reservedForUse10 (22),
reservedForUse11 (23),
reservedForUse12 (24),
reservedForUse13 (25),
reservedForUse14 (26),
reservedForUse15 (27),
reservedForUse16 (28),
reservedForUse17 (29),
reservedForUse18 (30),
reservedForUse19 (31),
reservedForUse20 (32),
reservedForUse21 (33)
} -- 6 bits, latinAlphabetNo1 recommended -- ,
ISO/IEC 8859 parts 1 to 10 and ISO/IEC 10646-1 define the characters of the different alphabets included in
the AlphabetIndicator type.
4.10.2.2.4 LicPlateNumber definition
LicPlateNumber::= OCTET STRING
LicPlateNumber is short form for License Plate Number.
4.11 CS5 – Vehicle Identification Number (VIN)
4.11.1 General requirements
The Vehicle Identification Number (VIN) defined in ISO 3779 and ISO 3780 is a structured combination of
characters assigned to a vehicle by its manufacturer for identification purposes. The manufacturer is
responsible for the uniqueness of the VIN.
The VIN defined in ISO 3779 and ISO 3780 shall consist of three sections: the World Manufacturer Identifier
(WMI) section, the Vehicle Descriptor Section (VDS), and the Vehicle Indicator Section (VIS).
4.11.2 Data structure
4.11.2.1 Data structure elements
Operators who wish to provide additional data fields can do so by adding additional ASN.1 identifier sets as
described in Annex C.
4.11.2.2 ASN.1 Data type specifications
The numbering scheme views the ID as a data element, and the common basic data structure is only a data
identifier code.
4.11.2.2.1 CS5 Definition
CS5::= VISIBLE STRING
4.12 CS6 – Reserved for CEN/ISO
CS6 is reserved for future use in International Standards.
4.13 CS7 – Freight container numbering
4.13.1 General requirements
The freight container data shall be based on ISO 10374 and consist of the following:
⎯ owner code, in accordance with ISO 6346;
⎯ serial number, in accordance with ISO 6346;
⎯ check digit, in accordance with ISO 6346;
⎯ length (in centimetres);
⎯ height (in centimetres);
⎯ width (in centimetres);
⎯ container type code, in accordance with ISO 6346;
⎯ maximum gross mass (in hundreds of kilograms);
⎯ tare mass (in hundreds of kilograms);
Where rounding is required, data shall be rounded down to the closest whole number allowed within the
permitted bit space.
4.13.2 Data structure
4.13.2.1 Data structure elements
Operators who wish to provide additional data fields can do so by adding additional ASN.1 identifier sets as
described in Annex C.
4.13.2.2 ASN.1 Data type definitions
4.13.2.2.1 CS7 Definition
CS7::= FreightContainerData
12 © ISO 2005 – All rights reserved
4.13.2.2.2 FreightContainerData definition
FreightContainerData::= SEQUENCE {
OwnerCode BIT STRING(SIZE(19)), -- 19bits
serialNumber INTEGER(0 . 1000000), -- 20bits
checkDigit INTEGER(0 . 10), -- 4bits
length INTEGER(1 . 2000), -- 11bits
height INTEGER(1 . 500), -- 9bits
width INTEGER(200 . 300), -- 7bits
containerTypeCode INTEGER(0 . 127), -- 7bits
maximumGrossMass INTEGER(19 . 500), -- 9bits
tareMass INTEGER(0 . 99) -- 7bits
}
4.14 CS8 – Tax authority code
4.14.1 General requirements
The Tax Authority Code shall normally be used to determine an electronic vignette in licence, taxation and
classification related applications. It shall normally be used in combination with CS3.
4.14.2 Data structure
4.14.2.1 Data structure elements
Authorities who wish to provide additional data fields such as CS3 can do so by adding additional ASN.1
identifier sets as described in the examples given in Annex C.
4.14.2.2 ASN.1 Data type definitions
4.14.2.2.1 CS8 Definition
CS8::= SEQUENCE {
countryCode CountryCode,
taxCode TaxCode
}
4.14.2.2.2 CountryCode definition
CountryCode is defined in 4.7.2.2.2.
4.14.2.2.3 TaxCode definition
TaxCode::= OCTET STRING
Annex A
(normative)
Management and general rules for the administration of coding
structures CS1, CS2 and CS8
A.1 General rules
This annex describes the administration procedure for numbers issued under the coding structure for CS1,
CS2 and CS8.
In order to ensure interoperability, it is essential that the coding structures defined in this International
Standard be applied in a consistent manner. The structures of this International Standard are so constructed
that they may be administered at a local level without danger of ambiguity of number series. In general terms,
this allows the (political) principles of subsidiarity to be followed. However, there is a requirement for central
maintenance of issuer identifiers. It is up to Nation States to determine which issuers will be authorized in
respect of nationally determined schemes, and the role of the CRA shall be limited to registering such
decisions.
Management procedures for the structures shall be minimized and shall be restricted to simple recording and
registration of local systems.
The Central and all National Registration Authorities shall conform to all regional and national legislative
requirements with respect to data protection and privacy within the domain of the scheme.
14 © ISO 2005 – All rights reserved
A.1.1 Registration hierarchy
Figure A.1 depicts the layout of the registration hierarchy.
Figure A.1 — Layout of the registration hierarchy
A.1.2 Definition of actors
A.1.2.1 Central Registration Administrator (CRA)
A body which maintains the registers of National Registration Administrators (NRA/I and NRA/T), and the
Register of Manufacturers. See A.1.3.
NOTE At the date of publication of this document, the ISO 14816 CRA was:
Nederlands Normalisatie-instituut (NEN)
P.O. Box 5059
NL-2600 GB Delft
The Netherlands
A.1.2.2 National Registration Administrator for Issuers (NRA/I)
A body appointed by the nation state to authorize CS1 issuers and to issue CS1 issuer identifiers at nation
state level. NRA/I is registered by the CRA, and it is expected that this will normally be the national
standardization body or its appointee.
A.1.2.3 Issuer
A body authorized by the NRA/I to issue a CS1 service code/unambiguous number and identified by a unique
identifier (issuer identifier) within a country in accordance with this International Standard.
A.1.2.4 Issuer register
The NRA/I shall maintain a register of all issuers and structure details on a national level. The NRA/I shall
provide a copy of its register of issuers at agreed intervals to the CRA, who shall maintain and make available
a copy of the full register of issuers. The issuer register shall not contain any personal information.
A.1.2.5 National Registration Administration for Tax authorities (NRA/T)
A body appointed by the nation state to register tax authorities and issue CS8 tax authority identifiers at the
national/federal level. NRA/T shall be registered by the CRA, and it is expected that it will normally be the
national standardization body or the national tax authority.
A.1.2.6 Tax authority register
The NRA/T shall maintain a register of all issued tax authorities and their tax codes on a national level.
The NRA/T shall provide a copy of its register of tax authorities at agreed intervals to the CRA, which shall
maintain and make available this register.
A tax authority may request several tax codes, which may be granted by the NRA/T.
NOTE It is recognized that the handling of taxation and its legislation is solely a nation state responsibility. A.3 and
data type CS8 are therefore intentionally kept more open than CS1 and CS2. NRA/Ts are advised to adopt the parts of
A.2 that apply in their case.
The terms may be understood as follows: A tax authority that together with the identification of (one of) its
transport tax(es) is identified by a tax code. (The combination in one identifier is done to give maximal
flexibility to nation states) See also the example under A.3.
A.1.3 Central Registration Administrator (CRA)
A.1.3.1 General
The Central Registration Administrator has been appointed in the first place by agreement of the plenary of
the technical committees (ISO TC204 and CEN TC278) and any replacement shall be managed by the ISO
Central Secretariat in accordance with ISO rules.
A.1.3.2 Responsibilities
The responsibilities of the CRA shall be:
a) to maintain a register of NRA/Is and NRA/Ts;
b) to compile, collate and issue a register of all NRA/I registers and to circulate a copy of this register to all
NRA/Is in an agreed format;
c) to compile, collate and issue a register of all NRA/T registers and to circulate a copy of this register to all
NRA/Ts in an agreed format;
d) to maintain a register of manufacturers according to the rules in A.4;
e) to keep CS1, CS2 and CS8 registers on a central level, and to make these registers available to the
public. The preferred method would be free public Internet access.
NOTE The home page of the CRA is: http://www.nen.nl/cen278/14816main.html.
At this Web site, more information can be found and application forms can be downloaded.
16 © ISO 2005 – All rights reserved
A.2 Application and registration procedures for CS1: issuers
A.2.1 Issuer
A.2.1.1 Application procedure for assignment of an issuer identifier.
The “applicant” issuer shall apply in writing to its National Registration Administrator for Issuers (NRA/I) for the
assignment of an issuer identifier. The NRA/I shall satisfy itself of the status of the applicant and shall assign
an unused issuer identifier.
In unforeseen cases, an issuer may wish to appeal against the decision of its NRA/I. In this case, the issuer
should lodge a written appeal with the CRA. The CRA shall immediately notify ISO/TC 204 of any appeal
lodged. In cases where the CRA cannot solve the issue, it may request guidance from CEN/TC 278 or
ISO/TC 204.
An issuer may request several Issuer Identifiers. This may be granted by the NRA/I. Each Issuer Identifier
shall then be handled as belonging to a separate issuer.
The reuse of issued identifiers should be avoided, and in any case expired identifiers shall not be reused until
3 years after their expiration period.
A.2.1.2 Criteria for approval of an application for a CS1 Issuer Identifier
Applications for an Issuer Identifier shall meet the criteria for approval below:
a) The applicant shall be a single entity with a legal status.
b) The applicant shall use the Issuer Identifier for an agreed use within the intended scope.
c) The applicant shall pay any fees required by the NRA/I based on the guidelines in A.5
d) The Issuer Identifier shall only be issued by the NRA/I when there is expected to be an immediate use, or
when the NRA/I considers that such requirement is imminent.
e) The NRA/I may request a national service code/unambiguous coding structure. The details that the NRA/I
may request shall be the details of his local numbering sub structures within his service
code/unambiguous number structure, but the unambiguous identification codes shall not be revealed to
the NRA/I.
Multinational companies or similarly a group of mutually independent Issuers in several member countries
may agree to form an alliance under a single entity to use a single issuer identification (CS1). Where such
companies already hold an Issuer Identifier in one country, they may apply for the issue of a similar number in
another country, which may be issued out of sequence, so long as that number is not already in use. Where
the number is already in use, the applicant may request a new number in the first country, which may be
granted at the discretion of the NRA/I.
A.2.1.3 Responsibilities of the issuer
The responsibilities of the issuer are the following:
a) to comply fully with the numbering system and the requirements of this International Standard and its
annexes (An Issuer may not issue a number that has not been formally allocated to it by the relevant
NRA/I.);
b) to retain the letter of authorization of its Issuer Identifier by the NRA/I;
c) to issue service codes/unambiguous numbers using the issuer identifier number assigned by the NRA/I,
in accordance with the requirements of this International Standard;
d) to communicate to the NRA/I any proposed changes that would alter material facts contained within the
original registration;
e) to keep a register of issued service codes/unambiguous numbers within the limits of its intended use, and
to maintain such records in a secure place and in accordance with the requirements for data protection in
the country/countries of their sphere of operation;
f) where the issuer is required to provide an anonymous mode, to maintain a service code/unambiguous
coding structure that will enable this in an efficient manner;
g) to pay fees in accordance with agreements with the NRA/I based on the guidelines in A.5;
h) where the issuer wants to terminate the issuing operation, to give three months notice to the NRA/I.
All privacy related m
...
NORME ISO
INTERNATIONALE 14816
Première édition
2005-11-01
Télématique de la circulation et du
transport routier — Identification
automatique des véhicules et des
équipements — Codification et
structure des données
Road transport and traffic telematics — Automatic vehicle and
equipment identification — Numbering and data structure
Numéro de référence
©
ISO 2005
DOCUMENT PROTÉGÉ PAR COPYRIGHT
© ISO 2005
Tous droits réservés. Sauf prescription différente ou nécessité dans le contexte de sa mise en œuvre, aucune partie de cette
publication ne peut être reproduite ni utilisée sous quelque forme que ce soit et par aucun procédé, électronique ou mécanique,
y compris la photocopie, ou la diffusion sur l’internet ou sur un intranet, sans autorisation écrite préalable. Une autorisation peut
être demandée à l’ISO à l’adresse ci-après ou au comité membre de l’ISO dans le pays du demandeur.
ISO copyright office
Case postale 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Genève
Tél.: +41 22 749 01 11
Fax: +41 22 749 09 47
E-mail: copyright@iso.org
Web: www.iso.org
Publié en Suisse
ii © ISO 2005 – Tous droits réservés
Sommaire Page
Avant-propos .iv
Introduction .v
1 Domaine d’application . 1
1.1 Schéma de codification global. 1
1.2 Schéma de codification AVI/AEI . 1
2 Références normatives . 2
3 Termes, définitions et notations . 3
4 Exigences . 3
4.1 Structure de codage globale . 3
4.2 Exigences générales . 3
4.3 Structures de données . 4
4.4 Résidence des données . 4
4.5 Tableau des identifiants de structure de codage . 4
4.6 Éléments de données de la structure de codage (applications AVI/AEI) . 5
4.7 CS1- Schéma de codification AVI/AEI . 5
4.7.1 Exigences générales . 5
4.7.2 Structures de données . 6
4.8 CS2-Codification des constructeurs . 6
4.8.1 Exigences générales . 6
4.8.2 Structures de données . 7
4.9 CS3 – Limitation de validité . 7
4.9.1 Exigences générales . 7
4.9.2 Structures de données . 7
4.10 CS4 – Codage de numéro de plaque de véhicule . 9
4.10.1 Exigences générales . 9
4.10.2 Structures de données . 9
4.11 CS5 – Numéro d’identification de véhicule (VIN) .10
4.11.1 Exigences générales .10
4.11.2 Structures de données .10
4.12 CS6 – Réservé au CEN/ISO .11
4.13 CS7 – Codification de conteneur pour le transport .11
4.13.1 Exigences générales .11
4.13.2 Structures de données .11
4.14 CS8 – Code de l’administration fiscale .12
4.14.1 Exigences générales .12
4.14.2 Structures de données .12
Annexe A (normative) Gestion et règles générales relatives à l’administration des
structures de codage CS1, CS2 et CS8 .13
Annexe B (normative) Récapitulatif des définitions des CS .23
Annexe C (informative) Exemples d’utilisation des structures de codage AVI/AEI .26
Bibliographie .32
Avant-propos
L’ISO (Organisation internationale de normalisation) est une fédération mondiale d’organismes
nationaux de normalisation (comités membres de l’ISO). L’élaboration des Normes internationales est
en général confiée aux comités techniques de l’ISO. Chaque comité membre intéressé par une étude
a le droit de faire partie du comité technique créé à cet effet. Les organisations internationales,
gouvernementales et non gouvernementales, en liaison avec l’ISO, participent également aux travaux.
L’ISO collabore étroitement avec la Commission électrotechnique internationale (IEC) en ce qui
concerne la normalisation électrotechnique.
Les Normes internationales sont rédigées conformément aux règles données dans les Directives ISO/
IEC, Partie 2.
Les comités techniques ont pour rôle principal de préparer les Normes internationales. Les projets de
Normes internationales adoptés par les comités techniques sont soumis aux comités membres pour
vote. La publication sous forme de Norme internationale nécessite une approbation par au minimum
75 % des comités membres participant au vote.
L’attention est attirée sur le fait que certains des éléments du présent document peuvent faire l’objet de
droits de propriété intellectuelle ou de droits analogues. L’ISO ne saurait être tenue pour responsable
de ne pas avoir identifié de tels droits de propriété et averti de leur existence.
L’ISO 14816 a été préparée par le comité technique ISO/TC 204, Systèmes intelligents de transport, en
collaboration avec le comité technique CEN/TC 278, Application télématique pour le transport routier et
la circulation routière.
La présente première édition annule et remplace (ISO/TS 14816:2000).
iv © ISO 2005 – Tous droits réservés
Introduction
La présente Norme internationale spécifie une structure de données qui permet une intégration
ascendante et une extension du système peu onéreux AVI/AEI vers des fonctions plus complexes. Cette
structure est conçue pour être flexible et dynamique plutôt que normative.
La présente Norme internationale a été conçue pour pourvoir aux exigences diverses des AVI et AEI
à travers l’utilisation de particularités de leurs applications distinctes. La réunion de ces différentes
exigences au sein d’un unique document maître permet de maximiser l’interopérabilité, en particulier
lorsque des AVI et AEI sont exigées simultanément dans l’environnement routier.
Afin de pouvoir prendre en charge des systèmes utilisant des équipements embarqués (OBE) actifs
comme passifs, les structures de données fondamentales ont été réduites au minimum. Cela permet à
tout constructeur/opérateur d’un OBE doté d’une mémoire adressable de seulement 56 bits d’être en
mesure de se conformer à une identification complète en accord avec la présente Norme internationale.
La Notation de Syntaxe Abstraite numéro un (ASN.1) est largement utilisée. Son utilisation assure
une interopérabilité et une conformité maximales vis-à-vis des normes internationales en vigueur, et
respecte les exigences définies spécifiquement pour un modèle normalisé générique des applications
télématiques pour le transport routier et la circulation routière (RTTT) en ce qu’elle:
— Utilise des règles de notation de syntaxe et de codage normalisées existantes,
— Peut être adaptée et étendue,
— Ne comporte aucune information non nécessaire pour un système particulier, et
— Impose un surdébit minimal en termes de stockage et de transmission.
Nous recommandons aux lecteurs qui ne sont pas familiers de l’ASN.1 de commencer par lire l’Annexe C
avant de lire le corps de la présente Norme internationale. Nous recommandons également aux lecteurs
de lire les normes ISO/IEC 8824, ISO/IEC 8825-1, ISO/IEC 8825-2 et ISO/IEC 8825-3 ainsi que d’autres
travaux publiés sur l’ASN.1 avant de lire le corps de la présente Norme internationale.
L’ISO 14814 fournit un modèle d’architecture de référence pour les systèmes AVI/AEI.
Les sections 4.1-4.6 de l’ISO 14816 fournissent un cadre normalisé et néanmoins flexible et interopérable
pour la codification des schémas. La présente Norme internationale détermine une structure
permettant une identification non ambiguë AVI/AEI et plusieurs schémas de codification associés aux
systèmes AVI/AEI.
Le principal schéma de codification AVI/AEI, fondamental pour une utilisation efficace de nombreuses
constructions, est une structure destinée à fournir une identification non ambiguë. Le paragraphe 4.7
de la présente Norme internationale fournit un codage d’élément d’information destiné à l’identification
automatique de véhicule et d’équipement (AVI/AEI) dans des applications de RTTT. Ce codage fournit
une structure offrant 256 possibilités (plus de 72 millions de milliards) d’identifiants uniques, selon une
structure de code à 56-bits lorsque l’ISO/IEC 8825-2 (PER) est utilisée, c.-à-d. n’impose aucun surdébit.
NORME INTERNATIONALE ISO 14816:2005(F)
Télématique de la circulation et du transport routier —
Identification automatique des véhicules et des
équipements — Codification et structure des données
1 Domaine d’application
1.1 Schéma de codification global
La présente Norme internationale établit une structure de données au cadre commun permettant une
identification univoque au sein de systèmes RTTT/ITS. Elle exclut tous les aspects physiques tels que
les interfaces. Elle ne se rapporte à aucun protocole d’interface radio-fréquence.
Les éléments de données faisant partie des protocoles de transmission ou de stockage tels que les en-
têtes, les repères de trame et les sommes de contrôle en sont donc exclus.
Les spécifications relatives à la protection contre les changements, la classification et la qualification
des aspects relatifs à la sécurité des éléments de structures de données ne sont pas couvertes par la
présente Norme internationale.
Les principes relatifs à la structure des éléments de données et à leur description déterminés dans
l’ISO/IEC 8824, l’ISO/IEC 8825-1 et l’ISO/IEC 8825-2 ont été adoptés afin de fournir une architecture
interopérable au sein d’un cadre normalisé selon les consignes des ISO/TC 204 et CEN/TC 278.
La présente Norme internationale définit des structures de données fondées sur les types CLASSE
UNIVERSELLE (universal class) de l’ASN.1 de l’ISO/IEC 8824-1 qui peuvent être directement IMPORTÉS
vers d’autres normes d’application et nécessiteraient uniquement des sous-ensembles des types
complets de CLASSE APPLICATION (application class). Ces types UNIVERSAL CLASS et APPLICATION
CLASS sont définis de manière univoque en tant que module de l’ASN.1 à l’Annexe B. Ce module peut
être directement associé à une définition de données d’application.
La présente Norme internationale définit un codage par défaut pour les applications AVI/AEI simples,
lorsqu’aucune norme d'application pertinente n’existe. Cette définition fait l’objet de l’Article 4.
1.2 Schéma de codification AVI/AEI
Les principaux schémas enregistrés pour l’AVI/AEI sont déterminés aux paragraphes 4.7 et 4.8 de la
présente Norme internationale. D’autres schémas pertinents et interopérables sont détaillés dans les
articles et paragraphes suivants.
Les structures définies dans la présente Norme internationale assurent une interopérabilité, non
seulement entre des fonctions AVI/AEI simples et RTTT/ITS plus complexes, mais également avec des
normes internationales antérieures (par ex. l’ISO 10374).
Il existe une autorité d’enregistrement centralisée qui administre le schéma de codification AVI selon
les règles du CEN et de l’ISO (voir l’Annexe A).
Les choix proposés à l’émetteur pour le fonctionnement de sa structure sont, entre autres:
— identification simple, auquel cas les identités séparées peuvent être ouvertement disponibles, à la
discrétion de l’émetteur ou de l’État-nation;
— fondé sur un alias, auquel cas les « identités » sont connues, mais sécurisées par des dispositions
visant à protéger les données et la vie privée et ne sont par conséquent pas disponibles; et
— identités cryptées de manière dynamique au sein d’un système anonyme.
2 Références normatives
Les documents suivants sont indispensables à l’application du présent document. Pour les références
datées, seule l’édition citée s’applique. Pour les références non datées, la dernière édition du document
de référence s’applique (y compris les éventuels amendements).
ISO 3166-1, Codes pour la représentation des noms de pays et de leurs subdivisions — Partie 1: Codes de pays
ISO 3779, Véhicules routiers — Numéro d'identification des véhicules (VIN) — Contenu et structure
ISO 3780, Véhicules routiers — Code d'identification mondiale des constructeurs (WMI)
ISO 6346, Conteneurs pour le transport de marchandises — Codage, identification et marquage
ISO/IEC 8824-1, Technologies de l'information — Notation de syntaxe abstraite numéro un (ASN.1):
Spécification de la notation de base — Partie 1
ISO/IEC 8825-1, Technologies de l'information — Règles de codage ASN.1: Spécification des règles de
codage de base (BER), des règles de codage canoniques (CER) et des règles de codage distinctives (DER) —
Partie 1
ISO/IEC 8825-2, Technologies de l'information — Règles de codage ASN.1: Spécification des règles
de codage compact (PER) — Partie 2
ISO/IEC 8859-1, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 1: Alphabet latin no. 1
ISO/IEC 8859-2, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 2: Alphabet latin no 2
ISO/IEC 8859-3, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 3: Alphabet latin no 3
ISO/IEC 8859-4, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 4: Alphabet latin no 4
ISO/IEC 8859-5, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 5: Alphabet latin/cyrillique
ISO/IEC 8859-6, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 6: Alphabet latin/arabe
ISO/IEC 8859-7, Technologies de l'information — Jeux de caractères graphiques codés sur un octet
— Partie 7: Alphabet latin/grec
ISO/IEC 8859-8, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 8: Alphabet latin/hébreu
ISO/IEC 8859-9, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 9: Alphabet latin no 5
ISO/IEC 8859-10, Technologies de l'information — Jeux de caractères graphiques codés sur un seul octet
— Partie 10: Alphabet latin no 6
ISO 10374, Conteneurs pour le transport de marchandises — Identification automatique
ISO/IEC 10646-1, Technologies de l’information— Jeu universel de caractères codés sur plusieurs
octets (JUC) — Partie 1: Architecture et table multilingue
ISO/TR 14813-3, Systèmes de commande et d’information des transports — Architecture(s) du modèle
de référence pour le secteur des TICS — Partie 3: exemple de mise au point
ISO 14814, Télématique du transport routier et de la circulation routière — Identification automatique des
véhicules et des équipements — Architecture de référence et terminologie
2 © ISO 2005 – Tous droits réservés
3 Termes, définitions et notations
Pour les besoins du présent document, les termes et définitions donnés dans l'ISO 14814 s’appliquent.
Le terme « émetteur » s’applique à tous les schémas de codage CS1, CS2 et CS8.
Les notations numériques sont représentées comme suit:
— Notation décimale (« normale ») ne comportent pas d'indice.
EXEMPLE 127.
— Les nombres hexadécimaux sont caractérisés par l’indice 16.
EXEMPLE Exemple: 7F16.
— Les nombres binaires sont caractérisés par l’indice 2.
EXEMPLE Exemple: 011111112.
Les caractères sont représentés comme suit:
— Les caractères ne comportent ni indice ni guillemets.
EXEMPLE ABC5EFD.
4 Exigences
4.1 Structure de codage globale
La structure de codage AVI/AEI déterminée dans la présente Norme internationale:
— est univoque et suffisamment flexible pour inclure des schémas de codification pertinents relatifs
au transport,
— respecte les normes internationales pertinentes, disponibles au moment de la rédaction,
— fournit un codage exact des éléments de donnée,
— est extensible afin de permettre une future extension, et
— est à même de prendre en compte des structures privées.
4.2 Exigences générales
La structure de codage déterminée dans la présente Norme internationale est une structure
« dynamique ». Elle est conçue pour recevoir, au sein de son cadre, des structures de codage se
rapportant à une variété de systèmes RTTT/ITS depuis une simple AVI/AEI jusqu’à des transactions
plus complexes avec une grande variété d’applications, et pour permettre des combinaisons d’éléments
de données à utiliser au sein d’une construction de données composite. Elle est conçue pour permettre
l’interopérabilité maximale possible entre les éléments de données au sein d’un environnement EDI/
EDT, et permettre une extension importante du nombre d’applications RTTT/ITS à l’avenir.
La présente Norme internationale reconnaît et prend en compte le fonctionnement de systèmes aux
capacités différentes. Elle doit permettre, au sein de sa structure, l’interopérabilité d’un OBE dans
un pays quelconque aussi longtemps qu’il existe une interface radio et un protocole communs, même
si les systèmes de l’opérateur eux-mêmes peuvent être significativement différents. Même lorsque
l’information doit être collectée par un interrogateur distinct en raison d’une absence de compatibilité
d'interface radio, les données, une fois collectées, sont dans un format interopérable commun, et
peuvent donc être utilisées avec précision et efficacité au sein d’un environnement EDI/EDT.
Les structures de données définies dans la présente Norme internationale permettent des structures en
« arborescence » ou en « cascade », avec la possibilité de bâtir des constructions d’élément de données
complexes.
La présente Norme internationale a été optimisée pour l’ISO/IEC 8825-2 ainsi que cela est recommandé
dans l’ISO/TS 14813-3.
Elle utilise l’ISO/IEC 8824-1 pour toutes les descriptions syntaxiques.
Le fait d’adopter la notation de syntaxe abstraite (ASN.1) des ISO/IEC 8824, ISO/IEC 8825-1, ISO/
IEC 8825-2 et ISO/IEC 8825-3, assure de la flexibilité aux éléments de données de toute longueur et
combinaison devant être pris en charge. De plus, cette structure de données a elle-même reçu un chemin
de migration, de sorte que, au fur et à mesure que les développements technologiques permettent des
capacités supplémentaires, les normes internationales subséquentes pourront fournir des champs de
données supplémentaires pouvant être utilisés dans toutes ou dans certaines applications propres à
certains secteurs, tout en maintenant la compatibilité ascendante depuis et vers le présent document.
Les règles du codage ASN.1 permettent l’enchaînement de plusieurs éléments de données provenant de
secteurs d’application différents pour bâtir des constructions d’élément de données complexes. (Voir
les exemples de l’Annexe C.)
4.3 Structures de données
Les exigences en matière de structuration des données telles qu’elles sont définies dans les ISO/
IEC 8824, ISO/IEC 8825-1, ISO/IEC 8825-2 et ISO/IEC 8825-3 s’appliquent, et en particulier l’ISO/
TS 14813-3.
4.4 Résidence des données
La construction de données est conçue pour être autonome et indépendante du média. Elle réside donc
normalement dans l’OBE.
Dans certains cas particuliers, tels que la liaison européenne normalisée DSRC à 5,8 GHz, dans laquelle
une partie du message est déjà connue du fait des services L7, l’utilisation des règles de codage
compactes (PER) de l’ASN.1 proposées dans la présente Norme internationale permet de ne transférer
que la partie inconnue du message, permettant ainsi d’atteindre une redondance minimale.
Les exemples donnés dans la suite de la présente Norme internationale supposent l'utilisation des PER
de l’ASN.1. Lorsque les règles de codage de base (BER) sont utilisées, un surdébit supplémentaire tel que
défini dans l’ISO/IEC 8825-1 est présent. Voir l’Annexe C pour des exemples de mise en œuvre.
4.5 Tableau des identifiants de structure de codage
Tableau 1 — Identifiants de structure de codage
Numéro d’identi- Structure de codage RTTT/ITS
fiant de structure de
codage (CSI)
0 Réservé au CEN/ISO
1 AVI/AEI pour utilisation dans des applications RTTT
2 Numéro de série constructeur de RTTT
3 Limite de validité RTTT (temps et lieu)
4 Plaque d'immatriculation
5 Numéro de châssis de véhicule (VIN)
6 Réservé au CEN/ISO
7 Codification de conteneur pour le transport
4 © ISO 2005 – Tous droits réservés
Tableau 1 (suite)
Numéro d’identi- Structure de codage RTTT/ITS
fiant de structure de
codage (CSI)
8 Code de l’administration fiscale
9 Réservé au CEN/ISO
... ...
30 Réservé au CEN/ISO
31 Réservé au CEN/ISO (extension)
4.6 Éléments de données de la structure de codage (applications AVI/AEI)
Le Tableau 2 donne les sept CS définies dans un tableau au format abrégé détaillant les éléments
primitifs (UNIVERSAL TYPES). Les définitions sont données en 4.7 et à l’Annexe C.
Tableau 2 — Taille minimale des éléments de données
CSI Longueur Champ de données de la structure de codage
1 7 octets / Code de pays Identifiant de l’émetteur Numéro de service
56 bits 10 14 32
2 6 octets / Identifiant du constructeur Numéro de service
48 bits 16 32
3 22 octets / Temps de début Temps de fin Limite géographique Limite de l’application
176 bits 80 80 8 8
4 Variable Code de pays Indicateur alphabétique Numéro de plaque d'imma-
triculation
10 6 Non défini
5 17 octets / Numéro d’identification de véhicule (châssis)
136 bits 136
6 Variable Réservé au CEN/ISO
Non défini
7 Codification de conteneur pour le transport
93 bits 93
8 Variable Code de pays Code fiscal
10 Non défini
REMARQUE 1 Le surdébit de chaque champ de données de la structure de codage est exclu du tableau. Les
nombres de bits des champs de données ne sont qu’indicatifs lorsque les PER sont utilisées comme règles de codage.
REMARQUE 2 Lorsque le terme « Numéro de service » est utilisé dans la présente Norme internationale, il
désigne à la fois le « Code service » et le « Numéro unique ».
4.7 CS1- Schéma de codification AVI/AEI
4.7.1 Exigences générales
Ce schéma de codification AVI/AEI fournit un élément d'identification univoque à 56 bits (codage selon
les PER) qui doit être conservé sur l’OBE. Cette structure de données est conçue pour être utilisée pour
un AVI/AEI simple, et peut également être utilisée pour former un élément AVI/AEI des messages RTTT
dont l’AVI/AEI constitue un composant.
Les procédures d’enregistrement incluant les structures qui relèvent des autorités d’émission nationales
sont obligatoires pour cette structure. Les dispositions relatives à l’enregistrement sont données à
l’Annexe A.
4.7.2 Structures de données
4.7.2.1 Éléments de structures de données
Le format fournit un champ de code permanent de l’équipement embarqué en « lecture seule » assurant
une adaptation spécifique aux équipements pour l’AVI/AEI au sein de l’environnement RTTT/ITS.
Les opérateurs qui souhaitent fournir des champs de données supplémentaires, de nature lecture seule
ou en lecture/écriture, peuvent le faire en ajoutant des jeux d'identifiants ASN.1 supplémentaires tels
que ceux décrits à l’Annexe C.
4.7.2.2 Définitions du type de données selon ASN.1
4.7.2.2.1 Définition CS1
CS1::= SEQUENCE {
countryCode CountryCode,
issuerIdentifier IssuerIdentifier,
serviceNumber ServiceNumber
}
4.7.2.2.2 Définition de CountryCode
CountryCode::= BIT STRING(Size(10))
L’attribution de la valeur est réalisée conformément à l’ISO 3166-1 et en utilisant l’alphabet ITA.2. Pour
l’attribution d’une valeur, veuillez vous référer à: http: //www .nen .nl/cen278/14816 _NRAI _register _by
_country .html.
4.7.2.2.3 Définition de UssuerIdentifier
IssuerIdentifier::= INTEGER(0 . 16383)
Pour l’enregistrement, voir l’Annexe A.
4.7.2.2.4 Définition de ServiceNumber
ServiceNumber::= BIT STRING(Size(32))
4.8 CS2-Codification des constructeurs
4.8.1 Exigences générales
La codification des constructeurs permet aux constructeurs de fournir, s’ils le souhaitent, un
système de codification indépendant de tout pays. On s’attend à ce que ce schéma de codification soit
principalement utilisé en tant que numéro de série électronique dans des systèmes ayant besoin de
connaître de manière directe le constructeur et les versions de l’équipement (par ex. à des fins de QA/
QC). Ce numéro pourrait également être utilisé comme une identité masquée cryptée dans des systèmes
présentant une combinaison d’exigences d’anonymat et de sécurité élevée.
La structure suivante détaille le contenu des données de codification du constructeur « primitives »,
qui doit être lu conjointement avec les notes présentées sous la structure.
Les procédures d’enregistrement sont similaires aux procédures de CS1, à l’exception que les structures
ne sont pas enregistrées avec une quelconque autorité émettrice nationale. Les dispositions relatives à
l’enregistrement sont disponibles à l’Article 5.
6 © ISO 2005 – Tous droits réservés
4.8.2 Structures de données
4.8.2.1 Éléments de structures de données
Les opérateurs qui souhaitent fournir des champs de données supplémentaires, de nature lecture seule
ou en lecture/écriture, peuvent le faire en ajoutant des jeux d'identifiants ASN.1 supplémentaires tels
que ceux décrits à l’Annexe C.
4.8.2.2 Structure de données détaillée
Le schéma de codification considère l’ID comme un élément de données, et la structure de données de
base commune est uniquement un code d'identification de données.
Le cadre de cette structure de données, dans lequel s’insère le champ de données de codification des
constructeurs, respecte les principes définis en CS1 (schéma de codification AVI/AEI), et est appliqué
dans cette structure comme suit:
4.8.2.2.1 Définition CS2
CS2::= SEQUENCE {
issuerIdentifier ManufacturerIdentifier,
serviceNumber ServiceNumber
}
4.8.2.2.2 Définition de ManufacturerIdentifier
ManufacturerIdentifier::= INTEGER(0 . 65535)
4.8.2.2.3 Définition de ServiceNumber
ServiceNumber est défini en 4.7.2.2.4.
4.9 CS3 – Limitation de validité
4.9.1 Exigences générales
La structure de limitation de validité est une structure d’élément de données qui spécifie une ou
plusieurs valeurs pour fournir des limites, dans le temps, géographiques ou sur l’application.
La limitation dans le temps fournit un groupe de date/heure de départ ou d’émission formaté selon un
TYPE UNIVERSEL ASN.1, et un groupe de date/heure d’expiration formaté de la même manière. Ce type
est appelé temps universel coordonné (UTC, Z).
La limitation géographique restreint l'usage du numéro référencé à la zone, au quartier, au pays ou au
continent de l’émetteur. Il doit utiliser le champ de bit décrit en 4.9.2.3.1.
La limitation d’une application ou d'un service est destinée à restreindre le type de service pour lequel
ce numéro de limitation de validité est émis; après paiement, avant paiement, contrôle d’accès, contrôle
de flotte, etc. L’utilisation de ce paramètre est valide pour les émetteurs qui fournissent plusieurs
services, et pour les utilisateurs qui souhaitent éviter une responsabilité vis-à-vis d'une série de ces
services. Il doit utiliser le champ de bit décrit en 4.9.2.3.2.
Les procédures d’enregistrement ne s’appliquent pas à ce cas.
4.9.2 Structures de données
4.9.2.1 Éléments de structures de données
Les opérateurs qui souhaitent fournir des champs de données supplémentaires, de nature lecture seule
ou en lecture/écriture, peuvent le faire en ajoutant des jeux d'identifiants ASN.1 supplémentaires tels
que ceux décrits dans un exemple de l’Annexe C.
4.9.2.2 Structure de données détaillée
4.9.2.2.1 Définition CS3
CS3::= SEQUENCE {
startTime StartTime,
stopTime StopTime,
geographLimit GeoGraphicalLimit,
serviceAppLimit ServiceApplicationLimit
}
4.9.2.2.2 Définition de StartTime
StartTime::= UTCtime
Le format recommandé est YYMMDDhhmmZ.
REMARQUE Le soin nécessaire doit être porté lors de la mise en œuvre des applications afin d’éviter les
problèmes associés à l’année 2000. Comme la composante relative au siècle (CC) n’est pas transférée, sa valeur
est déduite de la composante année (YY) par ex. à l’aide des règles suivantes:
— si 80 < = YY < = 99 alors CC = 19;
— si 00 < = YY < = 50 alors CC = 20.
4.9.2.3 Définition StopTime
StopTime::= UTCtime
Le format recommandé est YYMMDDhhmmZ.
4.9.2.3.1 Définition de GeoGraphicalLimit
GeoGraphicalLimit::= BIT STRING {
globalRestriction (0),
regionalRestriction (1),
nationalRestriction (2),
district (3),
issuerCoverageRestriction (4),
reservedForCEN/ISO1 (5),
reservedForCEN/ISO2 (6),
issuerSpecificRestriction (7)
}
La restriction doit être active si la position du bit est définie à 12. Si tous les bits sont 02, alors il n’y a
aucune restriction géographique.
4.9.2.3.2 Définition de ServiceApplicationLimit
ServiceApplicationLimit::= BIT STRING {
notForPostpayment (0),
notForPrepayment (1),
notForVehicleaccess (2),
notForFleetcontrol (3),
issuerSpecificRestriction1 (4),
issuerSpecificRestriction2 (5),
issuerSpecificRestriction3 (6),
issuerSpecificRestriction4 (7)
}
La restriction doit être active si la position du bit est définie à 12. Si tous les bits sont 02, alors il n’y a
aucune restriction.
Les bits d'ordre inférieur (0-3) sont de nature générale et définissent des restrictions hors de la zone
de l’émetteur. Les bits d’ordre élevé (4-7) sont destinés à des limitations particulières à l'intérieur de la
zone de l’opérateur.
EXEMPLE Les lignes suivantes montrent comment peut être codée la limitation de validité:
8 © ISO 2005 – Tous droits réservés
— Temps de début/émission: 93-01-01 (date), 12:00 (heure);
— Temps d’arrêt/expiration: 94-12-31 (date), 23:59 (heure);
Limite géographique: 010010112;
—
Limite de l’application: 111110002.
—
REMARQUE L'indicateur Z n’est pas utilisé.
Tableau 3 — Exemple de codage de limitation de validité
Temps de début/ Temps d’arrêt/ Limite de l’applica-
Limite géographique
émission expiration tion
9301011200 9412312359 010010112 111110002
4.10 CS4 – Codage de numéro de plaque de véhicule
4.10.1 Exigences générales
Dans certains systèmes, il existe une exigence de représentation électronique du numéro de plaque
d'immatriculation du véhicule. Cela doit être réalisé de manière univoque, et puisque les numéros de
plaque peuvent être identiques dans des nations/états/pays différents, il est également nécessaire
d’inclure un identifiant de pays.
Comme les plaques d’immatriculation sont dans plusieurs nations/états/pays émises avec des
caractères non latins (par ex. en cyrillique ou en grec) il est nécessaire d'identifier le jeu de caractères
utilisé. Ces deux exigences sont combinées dans ce codage de numéro de plaque de véhicule CS4.
4.10.2 Structures de données
4.10.2.1 Éléments de structures de données
Les autorités qui souhaitent fournir des champs de données supplémentaires, de nature lecture seule
ou en lecture/écriture, peuvent le faire en ajoutant des jeux d'identifiants ASN.1 supplémentaires tels
que ceux décrits à l’Annexe C.
4.10.2.2 Spécifications du type de données selon ASN.1
4.10.2.2.1 Définition CS4
CS4::= SEQUENCE {
countryCode CountryCode,
alphabetIndicator AlphabetIndicator,
licPlateNumber OCTET STRING
}
4.10.2.2.2 Définition de CountryCode
CountryCode est défini en 4.7.2.2.2.
4.10.2.2.3 Définition de AlphabetIndicator
AlphabetIndicator::= ENUMERATED {
latinAlphabetNo1 (1), -- codé en 00 00 00’B
latinAlphabetNo2 (2), -- codé en 00 00 00’B etc
latinAlphabetNo3 (3),
latinAlphabetNo4 (4),
latinCyrillicAlphabet (5),
latinArabicAlphabet (6),
latinGreekAlphabet (7),
latinHebrewAlphabet (8),
latinAlphabetNo5 (9),
latinAlphabetNo6 (10),
twoOctetBMP (11),
fourOctetCanonical (12),
reservedForUse1 (13),
reservedForUse2 (14),
reservedForUse3 (15),
reservedForUse4 (16),
reservedForUse5 (17),
reservedForUse6 (18),
reservedForUse7 (19),
reservedForUse8 (20),
reservedForUse9 (21),
reservedForUse10 (22),
reservedForUse11 (23),
reservedForUse12 (24),
reservedForUse13 (25),
reservedForUse14 (26),
reservedForUse15 (27),
reservedForUse16 (28),
reservedForUse17 (29),
reservedForUse18 (30),
reservedForUse19 (31),
reservedForUse20 (32),
reservedForUse21 (33)
} -- 6 bits, latinAlphabetNo1 recommandé --,
Les Parties 1 à 10 de l’ISO/IEC 8859 et l’ISO/IEC 10646-1 définissent les caractères des différents
alphabets inclus dans le type AlphabetIndicator.
4.10.2.2.4 Définition de LicPlateNumber
LicPlateNumber::= OCTET STRING
LicPlateNumber est un abrégé de License Plate Number, c.-à-d. numéro de plaque d'immatriculation.
4.11 CS5 – Numéro d’identification de véhicule (VIN)
4.11.1 Exigences générales
Le numéro d’identification de véhicule (VIN) défini dans l’ISO 3779 et l’ISO 3780 est une combinaison
structurée de caractères affectée à un véhicule par son constructeur à des fins d’identification. Le
constructeur est responsable de l’unicité du VIN.
Le VIN défini dans l’ISO 3779 et l’ISO 3780 doit consister en trois sections: la section du code
d’identification mondiale des constructeurs (WMI), la section du descripteur du véhicule (VDS), et la
section d’indicateur de véhicule (VIS).
4.11.2 Structures de données
4.11.2.1 Éléments de structures de données
Les opérateurs qui souhaitent fournir des champs de données supplémentaires peuvent le faire en
ajoutant des jeux d'identifiants ASN.1 supplémentaires tels que ceux décrits à l’Annexe C.
4.11.2.2 Spécifications du type de données selon ASN.1
Le schéma de codification considère l’ID comme un élément de données, et la structure de données de
base commune est uniquement un code d'identification de données.
4.11.2.2.1 Définition CS5
CS5::= VISIBLE STRING
10 © ISO 2005 – Tous droits réservés
4.12 CS6 – Réservé au CEN/ISO
Le CS6 est réservé à un usage futur dans les normes internationales.
4.13 CS7 – Codification de conteneur pour le transport
4.13.1 Exigences générales
Les données de conteneur de transport doivent être fondées sur l’ISO 10374 et doivent être constituées
des éléments suivants:
— code propriétaire, conformément à l’ISO 6346;
— numéro de série, conformément à l’ISO 6346;
— chiffre de contrôle, conformément à l’ISO 6346;
— longueur (en centimètres);
— hauteur (en centimètres);
— largeur (en centimètres);
— code de type de conteneur, conformément à l’ISO 6346;
— masse brute maximale (en quintaux);
— tare (en quintaux).
Lorsqu’il est nécessaire de les arrondir, ces données doivent être arrondies à la valeur entière inférieure
la plus proche permise selon l'intervalle de bit permis.
4.13.2 Structures de données
4.13.2.1 Éléments de structures de données
Les opérateurs qui souhaitent fournir des champs de données supplémentaires peuvent le faire en
ajoutant des jeux d'identifiants ASN.1 supplémentaires tels que ceux décrits à l’Annexe C.
4.13.2.2 Définitions du type de données selon ASN.1
4.13.2.2.1 Définition CS7
CS7::= FreightContainerData
4.13.2.2.2 Définition de FreightContainerData
FreightContainerData::= SEQUENCE {
OwnerCode BIT STRING(SIZE(19)), -- 19bits
serialNumber INTEGER(0 . 1000000), -- 20bits
checkDigit INTEGER(0 . 10), -- 4bits
length INTEGER(1 . 2000), -- 11bits
height INTEGER(1 . 500), -- 9bits
width INTEGER(200 . 300), -- 7bits
containerTypeCode INTEGER(0 . 127), -- 7bits
maximumGrossMass INTEGER(19 . 500), -- 9bits
tareMass INTEGER(0 . 99) -- 7bits
}
4.14 CS8 – Code de l’administration fiscale
4.14.1 Exigences générales
Le code de l’administration fiscale doit normalement être utilisé pour déterminer une vignette
électronique lors des demandes se rapportant aux permis, à la taxation et à la classification. Il doit
normalement être utilisé en combinaison avec la CS3.
4.14.2 Structures de données
4.14.2.1 Éléments de structures de données
Les autorités qui souhaitent fournir des champs de données supplémentaires tels que CS3 peuvent le
faire en ajoutant des jeux d'identifiants ASN.1 supplémentaires tels que ceux décrits dans les exemples
donnés à l’Annexe C.
4.14.2.2 Définitions du type de données selon ASN.1
4.14.2.2.1 Définition CS8
CS8::= SEQUENCE {
countryCode CountryCode,
taxCode TaxCode
}
4.14.2.2.2 Définition de CountryCode
CountryCode est défini en 4.7.2.2.2.
4.14.2.2.3 Définition de TaxCode
TaxCode::= OCTET STRING
12 © ISO 2005 – Tous droits réservés
Annexe A
(normative)
Gestion et règles générales relatives à l’administration des
structures de codage CS1, CS2 et CS8
A.1 Règles générales
La présente annexe décrite la procédure d’administration des codes émis par la structure de codage
selon CS1, CS2 et CS8.
Afin d’assurer l’interopérabilité, il est essentiel que les structures de codage définies dans la présente
Norme internationale soient appliquées de manière cohérente. Les structures de la présente Norme
internationale sont construites de sorte qu’elles peuvent être administrées à un niveau local sans
risque d'ambiguïté au niveau des séries de nombres. De manière générale, ceci permet de respecter
les principes (politiques) de subsidiarité. Toutefois, il existe une exigence de maintenance centralisée
des identifiants des émetteurs. Il revient aux États-nations de déterminer qui sont les émetteurs qui
seront autorisés au regard de schémas déterminés au niveau national, et le rôle du CRA doit être limité
à l’enregistrement de ces décisions.
Les procédures de gestion des structures doivent être réduites au minimum et doivent être limitées à
un simple enregistrement et à l’enregistrement des systèmes locaux.
L’autorité d’enregistrement centrale et toutes les autorités d’enregistrement nationales doivent se
conform
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.
Loading comments...