EN 16312:2013

2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.HOHNWURQVNHWXQJVUHJLVWULHUXQJURQLVFKH1DKEHUHLFKVNRPPXQLNDWLRQIntelligent transport systems - Automatic Vehicle and Equipment Registration (AVI/AEI) - Interoperable application profile for AVI/AEI and Electronic Register Identification using dedicated short range communication35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and tradeICS:Ta slovenski standard je istoveten z:EN 16312:2013SIST EN 16312:2013en,fr,de01-april-2013SIST EN 16312:2013SLOVENSKI
STANDARD
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 16312
January 2013 ICS 35.240.60 English Version
Intelligent transport systems - Automatic Vehicle and Equipment Registration (AVI/AEI) - Interoperable application profile for AVI/AEI and Electronic Register Identification using dedicated short range communication
Systèmes de transport intelligents - Identification automatique des véhicules et des équipements (AVI/AEI) -Profil d'application d'interopérabilité pour AVI/AEI et identification d'enregistrement électronique en utilisant des systèmes de communication dédiés à courte portée
Intelligente Transportsysteme - Automatische Fahrzeug und Ausstattungsregistrierung (AVI/AEI) - Interoperables Anwendungsprofil für AVI/AEI und elektronische Registrierungsidentifikation unter Verwendung von dedizierter Nahbereichskommunikation This European Standard was approved by CEN on 27 October 2012.
CEN members are bound to comply with the CEN/CENELEC Internal Regulations which stipulate the conditions for giving this European Standard the status of a national standard without any alteration. Up-to-date lists and bibliographical references concerning such national standards may be obtained on application to the CEN-CENELEC Management Centre or to any CEN member.
This European Standard exists in three official versions (English, French, German). A version in any other language made by translation under the responsibility of a CEN member into its own language and notified to the CEN-CENELEC Management Centre has the same status as the official versions.
CEN members are the national standards bodies of Austria, Belgium, Bulgaria, Croatia, Cyprus, Czech Republic, Denmark, Estonia, Finland, Former Yugoslav Republic of Macedonia, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2013 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 16312:2013: ESIST EN 16312:2013

Data specification . 18 A.1 General . 18 A.2 Data tables . 18 Annex B (normative)
ICS proforma . 23 B.1 General . 23 B.2 Guidance for completing the ICS proforma . 23 B.2.1 Purposes and structure . 23 B.2.2 Abbreviations and conventions . 23 B.3 Instructions for completing the ICS proforma . 25 B.4 ICS proforma for ERT . 26 B.4.1 Identification implementation . 26 B.4.2 Identification of the standard . 26 B.4.3 Global statement of conformance . 26 B.4.4 ICS proforma for ERT . 27 B.4.5 Profile requirement list for ERT . 28 B.5 ICS proforma for ERR . 32 B.5.1 Identification implementation . 32 B.5.2 Identification of the standard . 32 B.5.3 Global statement of conformance . 32 B.5.4 ICS proforma for ERR . 33 B.5.5 Profile requirement list for ERR . 34 Annex C (normative)
IAP taxonomy and numbering for AVI/AEI . 38 C.1 General . 38 C.2 Contents of an Interoperable Application Profile (IAP) . 38 C.3 IAP referencing and numbering . 39 C.3.1 IAP numbering . 39 SIST EN 16312:2013

Security computation examples . 40 D.1 General . 40 D.2 Computation of Attribute Authenticator . 40 D.3 Computation of Access Credentials . 41 D.4 Key derivation . 42 D.4.1 Authenticator Key . 42 D.4.2 Access Key . 42 Annex E (informative)
Security considerations . 43 E.1 General . 43 E.2 Specific security recommendations . 43 Annex F (informative)
Using this European Standard for other DSRC-based transactions . 45 F.1 General . 45 F.2 Specific purposes for data attributes and the transactions . 45 F.2.1 Access control applications . 45 F.2.2 Private freight management applications . 45 F.2.3 Simple traffic management applications . 45 F.2.4 Dangerous good tracking application . 45 Bibliography . 46
This European Standard defines an Interoperable Application Profile for AVI/AEI and electronic registration identification (ERI) using CEN DSRC-. The main objective is to support technical interoperability between ERI systems within the scope of the standard (as defined in Clause 1 below). This includes equipment compatibility between equipment suppliers and technical compatibility between different AVI/AEI systems compliant with this standard. This Standard is based on AVI/AEI standards such as ISO 14816, ISO 17264 and ISO 24534. Therefore, this Interoperable Application Profile enables other AVI/AEI application implementations to use the elements of this Standard as a basis for technical interoperability. In order to enable multipurpose equipment where AVI/AEI applications share resources with other applications such as EFC, this standard is patterned on EN 15509:2007, which is the interoperability application profile for EFC over CEN DSRC. This ensures that the AVI/AEI application implementations feature equivalent services as EFC.
This European Standard only defines a basic level of technical interoperability for ERI equipment, i.e. Electronic Registration Tag (ERT) and ERI Reader/Writer (ERR) using DSRC. It does not provide a full solution for interoperability, and it does not define other parts of the EFC-system, other services, other technologies and non-technical elements of interoperability. Although there are already numerous existing base standards and specifications, there are specific needs that motivate this Interoperable Application Profile standard. This standard:  defines the necessary and sufficient -DSRC requirements to support technical interoperability;  enables multi-application equipment;  fulfils the necessary additional DSRC-requirements;  provides a choice of data elements including vehicle data;  gives an extended definition of the use of some data elements, including semantics and coding;  lays down clear choices for security implementation;  facilitates a complementing test specification (with clear relations between the conformance requirements; and evaluation tests);  provides good support for procurements.
The Application Profile is described using the concept of "International Standardised Profiles (ISP)" as defined in ISO/IEC TR 10000-1. The ISP-concept is specifically suited for defining interoperability specifications where a set of base standards can be used in different ways. This is exactly the case in AVI/AEI, where a set of toolbox base standards allows for different choices that are not interoperable. The principles of the ISP-concept can be summarised as follows: SIST EN 16312:2013

Figure 1 — Scope for this European Standard
It is outside the scope of this European Standard to define:  contractual and procedural interoperability requirements;  provisions for electronic payments such as EFC;  conformance procedures and test specification;  setting-up of operating organisations (e.g. application service provider, issuing, trusted third party etc.); SIST EN 16312:2013

Figure 2 — Relations between this European Standard and DSRC-stack elements
NOTE For interlayer management, see EN 15509:2007, Annex G. This European Standard defines an Application Profile based on the ISP-concept. The base standards that this Application Profile is based upon are:  EN ISO 14906:2011 and ISO 17264:2009 on ERI application interface definition for DSRC (this implies indirect references to EN ISO 14816 on Numbering and data structures);  EN 12834: on DSRC application layer (L7);  EN 13372 on DSRC profiles (this implies indirect references to the DSRC L1, L2 and L7 standards:
EN 12253, EN 12795 and EN 12834);  EN 15509:2007: Interoperable Application Profile for EFC using CEN DSRC;  ISO 24534 on ERI application. SIST EN 16312:2013

Figure 3 — Relation and references between base standards and EN 16312 (this European Standard)
2 Normative references The following documents, in whole or in part, are normatively referenced in this document and are indispensable for its application. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. EN 12834, Road transport and traffic telematics — Dedicated Short Range Communication (DSRC) — DSRC application layer EN 13372, Road Transport and Traffic Telematics (RTTT) — Dedicated short-range communication — Profiles for RTTT applications EN 15509:2007, Road transport and traffic telematics — Electronic fee collection — Interoperability application profile for DSRC EN ISO 14816, Road transport and traffic telematics — Automatic vehicle and equipment identification — Numbering and data structure (ISO 14816) EN ISO 14906:2011, Electronic fee collection — Application interface definition for dedicated short-range communication (ISO 14906:2011:2011) EN ISO 17264:2009, Intelligent transport systems - Automatic vehicle and equipment identification — Interfaces (ISO 17264:2009) ISO/IEC 9646-7, Information technology — Open Systems Interconnection — Conformance testing methodology and framework — Part 7: Implementation Conformance Statements SIST EN 16312:2013

Note 1 to entry: The access credentials carry information needed to fulfil access conditions in order to perform the operation on the addressed element in the OBE. The access credentials can carry passwords as well as cryptographic based information such as authenticators. [SOURCE: EN ISO 14906:2011, definition 3.1] 3.2 action function that an application process resident at the ERI Reader/Writer can invoke in order to make the on-board equipment execute a specific operation during the transaction [SOURCE: adapted from EN ISO 14906:2011, definition 3.2]
3.3 attribute application information formed by one or by a sequence of data elements, and is managed by different actions used for implementation of a transaction
[SOURCE: EN ISO 14906:2011, definition 3.3] 3.4 authenticator data appended to, or a cryptographic transformation of, a data unit that allows a recipient of the data unit to prove the source and/or the integrity of the data unit and protect against forgery
[SOURCE: EN ISO 14906:2011, definition 3.4] 3.5 AVI/AEI attribute an attribute specifically defined for the AVI/AEI application [SOURCE: adapted from ISO 17264:2009, definition 4.3] 3.6 base standard an approved international standard or ITU-T Recommendation
[SOURCE: ISO/IEC TR 10000:1998] 3.7 CEN DSRC profile a set of parameters constituting a certain international standardised profile of the DSRC protocol stack (L1, L2 and L7) [SOURCE: EN 13374] SIST EN 16312:2013

[SOURCE: EN ISO 14906:2011, definition 3.8] 3.9 data group collection of closely related ERI data attributes which together describe a distinct part of an ERI transaction
[SOURCE: adapted from EN ISO 14906:2011:2011, definition 3.9] 3.10 data integrity property that data has not been altered or destroyed in an unauthorised manner
[SOURCE: EN ISO 14906:2011, definition 3.10] 3.11 Electronic Registration Reader / Writer ERR
device used to read/write data from or to an ‘Electronic Registration Tag’ [SOURCE: ISO 24534-1:2010, definition 2.7] 3.12 ERI Operator
entity responsible for facilitating the ERR for a defined purpose 3.13 Electronic Registration Tag ERT
onboard ERI device that contains the ERI data, including relevant secuirty promisions and one or more interfaces to access that data [SOURCE: ISO 24534-1:2010, definition 2.8] 3.14 element in the context of DSRC, a directory containing application information in form of attributes
[SOURCE: adapted from EN ISO 14906:2011, definition 3.11] 3.15 international standardised profile an internationally agreed-to, harmonised document which describes one or more profiles
[SOURCE: ISO/IEC TR 10000:1998] 3.16 interoperability the ability of two or more IT systems to exchange information and to make mutual use of the information that has been exchanged [SOURCE: ISO/IEC TR 10000:1998] SIST EN 16312:2013

entity responsible for issuing the ERI application including personalisation of mandatory AVI/AEI attributes in the ERT 3.18 profile a set of one or more base standards and/or ISP, and where applicable, the identification of chosen classes, conforming subsets, options and parameters of those base standards, or ISPs necessary to accomplish a particular function [SOURCE: ISO/IEC TR 10000:1998] 3.19 ERI session an instance of a ’Vehicle Identification’ using a harmonised air interface protocol known as ‘CEN DSRC profile’, using a distinct set of ‘AVI/AEI attributes’, retrieved by ‘service primitives (communication)’ and ‘security mechanisms’ defined in Annex B of this Standard 3.20 session counter
data value in the on-board unit that is incremented by the ERI Reader/Writer at each ERI session 3.21 user vehicle/equipment or person carrying the OBE though the point of identification with the objective of unambiguous identification of the OBE being carried [SOURCE: EN ISO 14814:2006, definition 3.28] 3.22 vehicle identification
action or act of establishing the identity of a vehicle [SOURCE: EN ISO 24534-1:2010, definition 2.15] 4 Abbreviations For the purpose of this document, the following abbreviations apply throughout the document unless otherwise specified. AcK
Access Key AC_CR
Access Credentials
[EN ISO 14906:2011] ADU
Application Data Unit [EN ISO 14906:2011] APDU
Application Protocol Data Unit [EN ISO 14906:2011] AP
Application Process [EN ISO 14906:2011] ASN.1
Abstract Syntax Notation One [ISO/IEC 8824-1:2008] AuK
AuKEY BST
Beacon Service Table [EN ISO 14906:2011] SIST EN 16312:2013

Data Encryption Algorithm DES
Data Encryption Standard DSRC
Dedicated Short-Range Communication [EN ISO 14906:2011] e [key] (value) encryption of the value using the key [EN 15509:2007] ede [key] (value) chained encryption, decryption and encryption of the value using the key [EN 15509:2007] EID
Element Identifier [EN ISO 14906:2011] ERI
Electronic Registration Identification [EN ISO 24534-1:2010] IAP
Interoperable Application Profile [EN 15509:2007] ICS
Implementation Conformance Statement [ISO/IEC TR 10000:1998] ISP
International Standardised Profile [ISO/IEC TR 10000:1998] IUT
Implementaton Under Test [CEN ISO/TS 14907-1:2010] L1
Layer 1 of DSRC (Physical Layer) [EN ISO 14906:2011] L2
Layer 2 of DSRC (Physical Layer) [EN ISO 14906:2011] L7
Layer 7 of DSRC (Application Layer Core of DSRC) [EN ISO 14906:2011] LLC
Logical Link Control [EN ISO 14906:2011] LID
Logical Link Control identifier [EN ISO 14906:2011] MAC
Media Access Control [EN ISO 14906:2011] T-APDU
Transfer-Application Protocol Data Unit [EN ISO 14906:2011] VST
Vehicle Service Table [EN ISO 14906:2011] 5 Conformance 5.1 ERT requirements 5.1.1 General This clause contains the normative conformance requirements on the ERT in terms of OBU requirements from the base standards. 5.1.2 DSRC requirements The ERT shall comply with EN 15509:2007, 5.1.2. 5.1.3 DSRC L7 and ERI functions The ERT shall comply with EN 15509:2007, 5.1.3.
ATTRIBUTES (EID>0) AttrId Length a (in
Read b Write b Remarks APPLICATION CONTEXT
This attribute is defined in EN 12834.
ApplicationContextMark N/A 16 Yes No Data that is sent from the ERT in the Initialisation phase (VST) that contains the identification of a specific DSRC application context.
The elements carried by the ApplicationContextMark are: AVI-ContextMark
CS1
AC_CR_Keyreference
RndOBU
ERI Application Data
CS2 2 6 Yes No RTTT Manufacturer Serial Number.
CS3 3 22 Yes No Validity Information.
CS4 4 17
Yes No License Plate Number, with fixed length
CS5 5 17 Yes No VIN Number with fixed length
OperatorData
OperatorData 40 1+20 Yes Yes General ERI Data structure to be read and written.
Security
SessionCounter 41 1+2 Yes Yes Usage see 5.2.5
a Including any length determinant as defined in ISO/IEC 8825-2 (packed encoding rules for ASN.1 is used in EN ISO 17264:2009 Container).
b The read and write columns denotes read and write operations in an ERI Vehicle Identification (not other possible situations)
5.1.5 Security requirements 5.1.5.1 General This European Standard defines security features and mechanisms based on the general security framework defined in EN ISO 14906:2011, 7.1.4. NOTE See Annex D for further details and explanation. 5.1.5.2 Security data requirements The security related data elements listed in Table 2, shall be implemented in the ERT: SIST EN 16312:2013

KeyRef value for Authentication Key1 is 111. KeyRef value for Authentication Key2 is 112.
RndRSE 5 = 1+4 Random number from ERR used for the computation of Authenticator. AccessKey 8 Private. AC_CR 5 = 1+4 Access credentials calculated by the ERR and the ERT using RndOBU and the AccessKey
AC_CR-KeyReference 2 Reference to the key generation and the Diversifier for the computation of AccessKey RndOBU 5 = 1+4 Random number (nonce) used together with AccessKey (referenced through AC_CR-KeyReference) to calculate the Access credentials (AC_CR).
The ERT shall be able to calculate an Authenticator (i.e. support the GET_STAMPED function operating on an attribute list considering that the response shall fit into one EN 12795 / DSRC Layer 2 frame) to validate data integrity and origin of the application data. These calculations shall be performed according to EN 15509. NOTE The ERT also supports the SessionCounter functionality (see 5.2.5.3).
The ERT shall support calculation of Access Credentials for protection of user related data on the ERT. These calculations shall be performed according to EN 15509:2007, 5.2.5.2. 5.1.6 ERI session requirements An ERT compliant with this European Standard shall be able to perform an ERI session as defined in ISO 17264:2009, Annex A. The ERT shall use AVIContextMark with an aVIProfile equal to value 12 “isoEriProfileAttrPointer”. NOTE
The ERT AVIContextMark – profileVersion is to be coded at the ERI application provider’s discretion. 5.2 ERR requirements 5.2.1 General This subclause contains the normative conformance requirements on the ERI Reader/Writer (ERR) in terms of requirements for RSE in EN 15509. 5.2.2 DSRC requirements The ERR shall support any ERT complying with 5.1.2. NOTE This implies that the ERR needs to comply with the DSRC-standards for Profiles, L1, L2 and L7
[EN 13372, EN 12253, EN 12795 and EN 12834]. SIST EN 16312:2013

5.2.5 Security requirements 5.2.5.1 General A general framework and toolbox for security is given in EN ISO 14906:2011, 7.1.4. This European Standard defines security features and mechanisms based on this framework. NOTE See Annex D for further details and explanation. 5.2.5.2 Mandatory Security requirements The ERR shall be able to calculate Authenticators to validate data integrity and origin of the application data. These calculations shall be performed according to EN 15509. The ERR shall perform key derivation of authentication keys according to the procedures defined in EN 15509. For key derivation the following diversifier value (VAL) shall be used: Compute VAL concatenating CS2-ServiceNumber, CS1-CountryCode, CS1-IssuerIdentifier and 00H:
VAL = CS2-ServiceNumber || CS1-CountryCode || CS1-IssuerIdentifier || 00H The ERR shall perform key derivation of access credential keys according to the procedures defined in EN 15509.
The ERR shall calculate Access Credentials (AC_CR) for access to protected ERI data on the ERT. These calculations shall be performed according to EN 15509.
5.2.5.3 Optional Security requirements The ERR may update the SessionCounter according to the following procedures: a) get the ERI attribute SessionCounter from the ERT ; b) increase the SessionCounter by 1 Modulo 65.536;
c) insert the changed SessionCounter value into the ERI attribute; d) send the updated SessionCounter value to the ERT (SET.Request). NOTE The Session Counter may provide additional security to an operator, if the values are collected and checked in a back-office.
Data specification A.1 General The specification and use of data elements is defined in EN ISO 17264:2009, EN ISO 14816 and in EN 12834. This annex includes ERI attribute and security related data requirements that restrict choices of or which are more specific and limited in scope than those of base standards. A.2 Data tables Tables with ERI attributes are included below. The tables describe the attributes in terms of name, definition, usage. NOTE The length column in the tables below includes the length determinant as defined in ISO/IEC 8825-2 (packed encoding rules for ASN.1 is used in EN ISO 17264:2009). Consider general purpose container for read/write access.
Table A.1 — Application related data (defined in EN 12834) Name / Data element
Definition & remarks
Usage Length In octets ApplicationContextMark Encoded data that is sent from the ERT in the Initialisation phase (VST) that contains the identification of a specific DSRC application context. For ERI the first 3 octets always will contain the AVI-ContextMark. The formal ASN.1 definition of ApplicationContextMark is:
ApplicationContextMark ::= SEQUENCE { aContextMark
AVI-ContextMark, cs1
CS1, --ISO14816 accr-key-ref
AC-CR-KeyReference,
rndOBU
OCTET STRING(SIZE(4))
} AC-CR-KeyReference ::= SEQUENCE { keyreference
INTEGER (0.255), diversifier
INTEGER (0.255) }
The ApplicationContextMark is the concatenation of:
AVI-ContextMark, CS1, AC_CR_Keyreference, RndOBU
EXAMPLE ’00 12 01 01 02 03 11 22 33 44 01 02 12 34 56 78’H
where:
- AVI-ContextMark: ’00 12 01’H - CS1: ’01 02 03 11 22 33 44’H - AC_CR_Keyreference: ’01 02’H - RndOBU: ’12 34 56 78’H
Definition & remarks
Usage Length In octets CS1 CS1 – AVI/AEI for use in RTTT application Usage according to EN ISO 14816 but more specific and limited in scope: CountryCode and IssuerIdentifier shall indentify the ERI Application ProviderServiceNumber shall be an ERI Application Provider specific designation of rules or context applying to the ERI Data
NOTE CS1 is not intended to uniquely identify an ERT 7 CS2 CS2 – RTTT Manufacturer Serial Number Usage according to EN ISO 14816 but more specific and limited in scope: ServiceNumber shall be a BIT STRING containing a biunique identification number of the ERT. Therefore ServiceNumber shall be sub typed as BIT STRING (CONTAINING INTEGER (0.4294967295)). This identification number shall be available during the entire lifetime of the ERT. In case the ERT is used for multiple applications, the identification number should be harmonised across all applications. 6 CS3 CS3 – RTTT Validity Limitation
Usage according to EN ISO 14816 but more specific: Zero values for single data elements shall indicate that a data element is not defined. 22 CS4 CS4 - LicencePlate Usage according to EN ISO 14816 but more specific and limited in scope: CS4 (WITH COMPONENTS {., licPlateNumber (SIZE(14))}) Zero values shall indicate that the data attribute is not defined. 17 CS5 CS5- Vehicle Identification Number (VIN) Usage according to EN ISO 14816 but more specific and
limited in size
scope: Zero values shall indicate that the data attribute is not defined. 17 SIST EN 16312:2013

Attribute Id / Name Data element
Definition & remarks
Usage Length In octets OperatorData ERI Operator specific data ERI Operator specific application data which can be written and read-out by the ERR depending on the operator’s needs 21 = 1+20
Table A.4 — Security data
Attribute Id / Name Data element
Definition & remarks
Usage Length In octets SessionCounter Session Counter Session counter, updated by the ERR according to 5.2.5.3. 3 = 1+2
Data element
Definition & remarks
Usage Length In octets AuthenticationKey1 Private A key used to compute authenticators (see 5.2.5.2). 8 AuthenticationKey2 Private Idem 8 AccessKey Private. The access key is the key used to compute AC_CR (see 5.2.5.2). 8 AC_CR Access credentials calculated by the ERR and the ERT using RndOBU and the Access Key. INTEGER (0.4'294'967'295).
AC_CR = DES. Compute AC_CR(k) according to the DES algorithm [DEA], see also Annex E. 5 = 1+4 AC_CR-KeyReference Reference to the key generation and the Diversifier for the computation of AC_CRKey. Key reference (k): Integer (0.255) (8 bits) Diversifier: Integer (0.255). (8 bits)
EXAMPLE Key reference (# 1) and Diversifier (# 2) : 0000 0001’B (Key reference (1)): 0000 0010’B (Diversifier (2)). 2 KeyRef Reference to AuKey used for the computation of the Authenticators, e.g. Issuer and Operator Authenticators. The Application provider/Issuer decides which keys are kept by him and which keys are shared with other entities. INTEGER (0.255).
EXAMPLE AuthenticationKey1 reference (=11110) 1 RndOBU Random number (nonce) used together with AccessKey (referenced through AC_CR-KeyReference) to calculate the Access credentials. OCTET STRING (SIZE4)) 4 RndRSE Random number, from ERR used for the computation of Authenticator. INTEGER(0.4’294’967’295) 5 = 1+4
ICS proforma B.1 General To evaluate conformance of a particular implementation, it is necessary to have a statement of which capabilities and options have been implemented. Such a statement is called an Implementation Conformance Statement (ICS). This annex provides proforma ICS templates, to be filled in by equipment suppliers. The actual ICS proforma to be filled in by a supplier, claiming conformity for a product to this European Standard, shall be technically equivalent to the text of the ICS proforma given in this annex, and shall preserve the numbering, naming and ordering of the proforma items. The forms in this annex shall be completed by the supplier of the item under test (IUT, i.e. the ERT or ERR ). B.2 Guidance for completing the ICS proforma B.2.1 Purposes and structure The purpose of this ICS proforma is to provide a mechanism whereby a supplier of an implementation of the requirements defined in this European Standard may provide information about the implementation in a standardised manner. The ICS proforma is subdivided into clauses for the following categories of information:  guidance for completing the ICS proforma;  identification of the implementation;  identification of the protocol;  global statement of conformance;  ICS proforma tables. B.2.2 Abbreviations and conventions B.2.2.1 General The ICS proforma contained in this annex is comprised of information in tabular form in accordance with the guidelines presented in ISO/IEC 9646-7. B.2.2.2 Item column The item column contains a number which identifies the item in the table. SIST EN 16312:2013
...