oSIST prEN 16405:2022
(Main)Intelligent transport systems - ECall - Additional data concept specification for cargo in vehicles
Intelligent transport systems - ECall - Additional data concept specification for cargo in vehicles
This Standard defines an additional data concept that may be transferred as an ‘optional additional data concept’ as defined in EN 15722 eCall MSD, that may be transferred from a goods carrying vehicle to a PSAP in the event of a crash or emergency via an eCall communication session. Two variants are provided, one (schema A) for use where information about the goods (ADR classified or not) is known in the eCall device; the second variant (schema B) is for use where such information is to be fetched from elsewhere.
NOTE: This Standard is complementary and additional to EN 15722; and contains as little redundancy as possible.
The communications media protocols and methods for the transmission of the eCall message are not specified in this Standard. Its contents are independent of the protocols and methods used.
Other additional data concepts may also be transferred, and any such data concepts should be registered using a data registry as defined in EN ISO 24978. See www.esafetydata.com for an example.
Intelligente Verkehrssysteme - eCall - Zusätzliches Datenkonzeptspezifikation für Fracht in Fahrzeugen
Inteligentni transportni sistemi - E-klic - Koncept specifikacij za dodatne podatke za tovor v vozilih
General Information
Relations
Standards Content (Sample)
SLOVENSKI STANDARD
oSIST prEN 16405:2022
01-julij-2022
Inteligentni transportni sistemi - E-klic - Koncept specifikacij za dodatne podatke
za tovor v vozilih
Intelligent transport systems - ECall - Additional data concept specification for cargo in
vehicles
Intelligente Verkehrssysteme - eCall - Zusätzliches Datenkonzeptspezifikation für Fracht
in Fahrzeugen
Ta slovenski standard je istoveten z: prEN 16405
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
oSIST prEN 16405:2022 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 16405:2022
---------------------- Page: 2 ----------------------
oSIST prEN 16405:2022
DRAFT
EUROPEAN STANDARD
prEN 16405
NORME EUROPÉENNE
EUROPÄISCHE NORM
May 2022
ICS 03.220.20; 35.240.60 Will supersede CEN/TS 16405:2017
English Version
Intelligent transport systems - ECall - Additional data
concept specification for cargo in vehicles
Intelligente Verkehrssysteme - eCall - Zusätzliches
Datenkonzeptspezifikation für Fracht in Fahrzeugen
This draft European Standard is submitted to CEN members for enquiry. It has been drawn up by the Technical Committee
CEN/TC 278.
If this draft becomes a European Standard, 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.
This draft European Standard was established by CEN 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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway,
Poland, Portugal, Republic of North Macedonia, Romania, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland, Turkey and
United Kingdom.
Recipients of this draft are invited to submit, with their comments, notification of any relevant patent rights of which they are
aware and to provide supporting documentation.
Warning : This document is not a European Standard. It is distributed for review and comments. It is subject to change without
notice and shall not be referred to as a European Standard.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION
EUROPÄISCHES KOMITEE FÜR NORMUNG
CEN-CENELEC Management Centre: Rue de la Science 23, B-1040 Brussels
© 2022 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 16405:2022 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
Contents Page
Foreword . Error! Bookmark not defined.
Introduction . Error! Bookmark not defined.
5.1 General . Error! Bookmark not defined.
5.2 eCall Requirements for cargo information . Error! Bookmark not defined.
5.2.1 PSAP requirements . Error! Bookmark not defined.
5.2.2 Information providers requirements . Error! Bookmark not defined.
5.3 Concepts and formats . Error! Bookmark not defined.
5.3.1 MSD data concepts . Error! Bookmark not defined.
5.3.2 Representation of MSD data concepts . Error! Bookmark not defined.
5.3.3 Distribution of MSD data . Error! Bookmark not defined.
5.3.4 Commercial vehicles cargo additional data concept ‘Object Identifier’ . Error!
Bookmark not defined.
5.3.5 Commercial vehicles cargo additional data concept ‘data’ Error! Bookmark not defined.
5.4 Contents of the ‘Minimum Set of Data’ (MSD) . Error! Bookmark not defined.
5.4.1 Basic contents of MSD . Error! Bookmark not defined.
5.4.2 Contents of the optionalAdditionalData for Schema A . Error! Bookmark not defined.
5.4.3 Contents of the optionalAdditionalData for Schema B . Error! Bookmark not defined.
Annex A (normative) ASN.1 definition of additional data concept for cargo . Error! Bookmark
not defined.
A.1 General . Error! Bookmark not defined.
A.2 Definition of Schema A additional data concept . Error! Bookmark not defined.
A.2.1 ASN.1 definition . Error! Bookmark not defined.
A.2.2 Syntax check of ASN.1 definition . Error! Bookmark not defined.
A.2.3 Example . Error! Bookmark not defined.
A.3 Definition of Schema B additional data concept . Error! Bookmark not defined.
A.3.1 General . Error! Bookmark not defined.
A.3.2 ASN.1 definition . Error! Bookmark not defined.
A.3.3 Syntax check . Error! Bookmark not defined.
A.3.4 Example . Error! Bookmark not defined.
Annex B (informative) ASN.1 definition of complete MSD message with cargo info . Error!
Bookmark not defined.
B.1 General . Error! Bookmark not defined.
B.2 ASN.1 definition of complete extended MSD message, cargo Schema A . Error!
Bookmark not defined.
B.3 Example . Error! Bookmark not defined.
Annex C (informative) Schema B use case scenario . Error! Bookmark not defined.
Bibliography . Error! Bookmark not defined.
2
---------------------- Page: 4 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
European foreword
This document (prEN 16405:2021) has been prepared by Technical Committee CEN/TC 278 “Intelligent
transport systems”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document supersedes CEN/TS 16405:2017.
A Technical Report on this subject, proposing these specifications, was approved in 2012
(CEN/TR 16405), for field testing. The proposed specifications have subsequently been tested in the field
(by EC Project HeERO and others). This resulted in a Technical Specification (CEN/TS 16405) in 2017 of
which the semantic content remained unchanged. However as the parent Standard EN 15722 (eCall
Minimum Set of Data) had been revised and updated, the Technical Specification was made consistent
with the layout and specifications of the revised EN 15722.
The 2017 Technical Specification has been used in several other pilot projects and part of the analysis
undertaken by the 2018 special project team that delivered Technical Reports 17249-X. The input of the
pilot projects and the project team resulted in revisions to the Technical Specification, allowing it to be
promoted to a standard. As such this document describes the first version of EN 16405.
3
---------------------- Page: 5 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
Introduction
An eCall is an emergency call generated either automatically via activation of in-vehicle sensors or
manually by the vehicle occupants; when activated, to provide notification and relevant location
information to the most appropriate ‘Public Safety Answering Points’ (PSAP), by means of mobile wireless
communications networks and carries a defined standardized ‘Minimum Set of Data’ (MSD), notifying that
there has been an incident that requires response from the emergency services and establishes an audio
channel between the occupants of the vehicle and the most appropriate PSAP.
The MSD (specified in EN 15722) contains static information regarding the vehicle, dynamic information
regarding its location, direction of travel etc., at the time of the incident, and makes provision for
additional data to be provided.
This document provides specification for an additional data concept for (commercial) vehicles to provide
dynamic data about the cargo that it is carrying at the time of the incident that triggered the eCall, with
specific emphasis on identification of dangerous goods. Two variants are provided, one (schema A) for
use if information about the goods (ADR classified or not) is known in the eCall device; the second variant
(schema B) is for use if information about the load has to be fetched from other sources.
The preceding Technical Specification was tested in demonstration projects (such as HeERO) and further
elaborated by a technical project team delivering TS 17429-2. Results of these are incorporated in this
document, now becoming a European Standard.
In order to claim conformance with this document, communication is to be established using accepted
wireless communication standards, and it is to be able to demonstrate that the MSD transferred together
with any standardized data elements defined herein comply with the specifications of this document, to
the extent that such data are available from the vehicle.
Revisions in regards to the preceding Technical Specification (TS16405:2017) are:
— Addition of requirements clauses (5.2)
— Corrections made in paragraph 5.4.2 (Table 2) to properly reflect ASN.1 recipe ;
— Extended the allowed types of transport;
— Extended usability of the phone number supplied;
— Added a version number to the OID;
— Improvements in the precision of technical description and update of references;
— Creation of EN;
4
---------------------- Page: 6 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
1 Scope
This document defines an additional data concept that can be transferred as an additional data concept
as defined in EN 15722 eCall MSD, that can be transferred from a goods carrying vehicle to a PSAP in the
event of a crash or emergency via an eCall communication session. Two variants are provided, one
(schema A) for use where information about the goods (ADR classified or not) is known in the eCall
device; the second variant (schema B) is for use where such information is fetched from elsewhere.
NOTE This document is complementary and additional to EN 15722; and contains as little redundancy as
possible.
The communications media protocols and methods for the transmission of the eCall message are not
specified in this document. Its contents are independent of the protocols and methods used.
Other additional data concepts can also be transferred, and any such data concepts are registered using
a data registry, see EN ISO 24978 for additional information, and www.esafetydata.com for an example.
2 Normative References
The following documents are referred to in the text in such a way that some or all of their content
constitutes requirements 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.
EN 15722, Intelligent transport systems - ESafety - ECall minimum set of data
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules — Part 2: Specification of Packed
Encoding Rules (PER)
EN ISO 24978, Intelligent transport systems - ITS Safety and emergency messages using any available
wireless media - Data registry procedures (ISO 24978)
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
3.1
112
single European emergency call number supporting Teleservice 12
[SOURCE: ETSI/TS 122 003]
3.2
ADR
United Nations treaty that governs transnational transport of hazardous materials, known as Agreement
of 30 September 1957 concerning the international carriage of Dangerous goods by Road or Accord relatif
au transport international des marchandises Dangereuses par Route
3.3
ASN.1
Abstract Syntax Notation One
notation that describes rules and structures for representing, encoding, transmitting, and decoding data
enabling representation of objects that are independent of machine-specific encoding techniques
5
---------------------- Page: 7 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
3.4
commercial vehicle
mechanically propelled road vehicle (mostly vehicle type N1, N2 or N3) that is of a construction primarily
suited for the carriage of goods or burden of any kind (not including people) and travelling on a road
laden
Note 1 to entry: This explicitly excludes busses or other vehicles designed and constructed for the carriage of
passengers (ie. vehicle types M1, M2 or M3). It however includes vehicles designed or adapted to carry goods in
other vehicle types (like: O). Any such vehicle may or may not have a maximum weight exceeding 3,500 tonnes
3.5
dangerous goods
categories of goods carried by road characterised as articles or substances which are capable of posing a
significant risk to health, safety or to property when transported
3.6
eCall
emergency call generated either automatically via activation of in-vehicle sensors or manually by the
vehicle occupants
Note 1 to entry: When activated it provides notification and relevant location information to the most
appropriate 'Public Safety Answering Point’, by means of mobile wireless communications networks, carries a
defined standardized ‘Minimum Set of Data’ notifying that there has been an incident that requires response from
the emergency services, and establishes an audio channel between the occupants of the vehicle and the most
appropriate 'Public Safety Answering Point'
3.7
Kemler code
code describing the hazards of a chemical in transport, also known as Hazard Identification Number
(HIN)
3.8
uniform resource identifier
URI
string of characters used to identify a name or a resource on the Internet
3.9
uniform resource locator
URL
URI that, in addition to identifying a resource, provides a means of locating the resource by describing its
primary access mechanism
EXAMPLE Its network location
4 Symbols and abbreviations
ETSI European Telecommunications Standards Institute
M Mandatory
MSD Minimum set of data
O Optional
PER Packed Encoding Rules (ASN.1)
6
---------------------- Page: 8 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
PSAP Public Safety Answering Point
UPER Unaligned Packed Encoding Rules (ASN.1)
5 Requirements
5.1 General
This document describes an addendum to the standard defined in EN 15722 for the coding of the MSD
message. Any requirement from EN 15722 shall be met for the exchange of information about cargo in
the additional data block.
5.2 eCall Requirements for cargo information
5.2.1 PSAP requirements
Previous research has laid down some ground rules for information that is exchanged within the eCall
paradigm. Basically, any information should adhere to these requirements:
• Information shall be ‘machine interpretable’
• Information shall either be sent in human readable form, or automatically be translated into this
• Information shall be concise and well structured
• Information shall be accurate and up to date
Focussing on the emergency process, research has shown that PSAPs and emergency services need
specific information in case of an accident with the commercial vehicle, vital in ensuring that the right
resources are dispatched. Obviously, a large part of this need overlaps with what is already implemented
with the basic eCall mechanism, these elements are marked with an asterisk:
1. Exact location of incident/collision/vehicle including direction of travel, prior to the collision or
*
incident
2. Vehicle Information:
*
• VIN
* (via EUCARIS, local registry or VIN decoder)
• Make, Model, Type (Rigid, Articulated)
* (via EUCARIS or local registry)
• Type of fuel (Diesel/LPG/Electric)
* (via EUCARIS or local registry)
• Registration number
3. Vehicle Cargo
• For any Dangerous Goods in the cargo:
o UN-Number
o Quantity
o Packaging danger level code (optional)
o Kemmler Code (optional)
7
---------------------- Page: 9 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
• For other, non dangerous, Goods:
o Quantity
o Type of good (optional)
• Regardless of cargo type:
o Phone number of Expert (optional)
o Sender details (optional)
o Receiver details (optional)
5.2.2 Information providers requirements
The information providers (mostly transport companies) benefit from a speedy emergency and recovery
process but do have requirements as well. They obviously want to limit the resources spent to be able to
share information with the PSAPs. But perhaps more important is the security and confidentiality of the
data.
It is a necessity that only certified PSAPs are allowed to use the interface for eCall and that a request for
data can only be made when an eCall was received. Any (exchange) protocol should ensure both
requirements. The first condition can be met by several security mechanisms including the exchange of
keys or based on private connections.
To ensure that a request is only made in case an eCall was received, the exchange protocol should involve
one or more key elements that come from the MSD provided by an IVS in a vehicle and are not otherwise
known, other than by the freight information service provider. A random number serves this purpose,
whereas well-known keys like VIN or the license plate number cannot be used as a key (although the key
can be the VIN encrypted with the private key of the service provider).
5.3 Concepts and formats
5.3.1 MSD data concepts
The MSD as defined in EN 15722 is a direct, timely message to the PSAP operator receiving the emergency
call.
The MSD has an optional additional data block that will be used to add information elements containing
information about the load of the vehicle involved.
The information elements in the additional data block of the MSD have been selected on the basis of their
relevance in an emergency rescue situation.
5.3.2 Representation of MSD data concepts
The MSD is represented in ‘Abstract Syntax Notation’ (ASN.1) using the ‘Unaligned Packed Encoding
Rules’ (UPER) as defined in ISO/IEC 8825-2 using the ASN1 definitions defined in Annex A of EN 15722.
The message shall be sent in the sequence defined in that same Annex.
The information about the cargo of the vehicle sending the MSD shall be represented in ASN.1 UPER as
well, following the provision made in above named Annex.
5.3.3 Distribution of MSD data
The MSD shall be transmitted as described in EN 15722.
5.3.4 Commercial vehicles cargo additional data concept ‘Object Identifier’
The object identifier uniquely identifies the format and meaning of the data which follows in the
additional data concept.
8
---------------------- Page: 10 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
Both the syntax of the data structure and the semantic meaning of the content is referenced via this
identifier so that it can be usefully applied.
The uniqueness of each specific relative identifier is ensured by a specific international standardizations
body, and maintained in a data registry operated in accordance with EN ISO 24978. These identifiers are
all relative to a specific root. And the root of all eCall relative OID's shall be the same.
eCall has been allocated the OID 1.0.14817.106.2.1. Within this, arc ‘.2’ has been defined to contain ‘eCall
Additional Data concepts’. The OID for this deliverable shall be 1.0.14817.106.2.1.2.1.
This deliverable defines two schemes that each have their own unique OID:
Schema A: 1.0.14817.106.2.1.2.1.1.1
Schema B: 1.0.14817.106.2.1.2.1.2.1
The OID for ‘eCall Additional Data concepts’ (1.0.14817.106.2.1.2) is fixed and shall not be transmitted
over the air as part of the additional data. The MSD data element ‘oid’ is defined as RELATIVE-OID and
shall contain 1.1 if Schema A is used, or 1.2 if Scheme B is used. In order to be able to discriminate between
this and future versions, an additional .1 is added.
For further detail regarding the use of OIDs in eCall, see EN 15722.
5.3.5 Commercial vehicles cargo additional data concept ‘data’
The objective of the cargo data concept is to provide the PSAP with data concerning the load of the
affected vehicle transmitting the MSD.
Two variants are provided, one (schema A) for use where information about the goods (ADR classified or
not) is known in the eCall device; the second variant (schema B) is for use where load information should
be fetched from elsewhere.
Paramount priority is given to the transmission of data relating to dangerous/dangerous goods Provision
is also made to transfer data concerning other (non ADR) cargos. While these cargoes may not be
classified as dangerous/dangerous, in the event of an accident they may cause increased risk of accident
or problems for the emergency services – for example livestock; small materials such as ball bearings,
liquids, manure or other materials likely to affect the surface tension of the roadway surface or present
obstacles on the roadway.
The data concept will take up slightly less than the amount of bytes available for the additional data in
the MSD, using the maximum message length limit as defined in EN 15722 (140 bytes). As such there is
no risk of the complete MSD to exceed the maximum number of bytes allowed by using this data concept.
5.4 Contents of the ‘Minimum Set of Data’ (MSD)
5.4.1 General
The following subclauses provide the definition of the minimum set of data that shall be sent from the
vehicle in case of an emergency call.
5.4.2 Basic contents of MSD
Table 1 provides a summary of the semantic contents of the MSD, for a full description please refer to
EN 15722.
9
---------------------- Page: 11 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
Table 1 — Contents/format of the MSD data concept
MSD
msdVersion INTEGER - M
(1.255)
msd
msdStructure
optionalAdditionalData O
oid RELATIVE-
OID
data OCTET
STRING
M: Mandatory data field (ie. mandatory if this encoding scheme is used)
O: Optional data field
This document describes the contents of the optionalAdditionalData block.
5.4.3 Contents of the optionalAdditionalData for Schema A
Table 2 provides a summary of the semantic contents of the optionalAdditionalData part of the MSD for
Schema A.
The sequence of data presentation shall be as specified in Table 2, represented as described in this clause
and distributed as described in this clause.
For clarity the ‘type’ used in Table 2 is a semantic representation of the type used in the ASN.1 definition.
The exact representation is found in Annex A.
The real position of the element in the data-stream is defined by the ASN.1 ‘unaligned packet encoding
rules (UPER), following the definition in Annex A. Elements therefore do not necessarily start or end on
a byte boundary.
10
---------------------- Page: 12 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
Table 2 — Contents/format of Commercial vehicle additional data Schema A
optionalAdditionalData
oid RELATIVE OID M Fixed value: 1.1
data encoded as OCTET STRING
commercialVehicle ENUM M The supported types are:
Type
- unknown
- tanker, one compartment
- tanker, more compartments
- rigid truck
- rigid truck with towing capability
- prime mover
- van
- van, with towing capability
- other
contactPhoneNumbe Numerical M Contact telephone number in case of
r emergency.
String
NOTE: the number should be specified as
international number, thus including the
country- and areacode (without zero)
contactType ENUM M Type of contact reached through
phonenumber:
- driver
- transport company
- consignor
- other
alarmInfo O Information about sensors present is
encoded. Each sensor is optional and
should be left out if not present. If a sensor
is generating an alarm its value should be
set to true, if a sensor is available but not
generating an alarm its value is false
IMPORTANT NOTE: Emergency services
need to be aware that the absence of an
alarm indicates only that there was no
alarm showing as activated at the time of
compiling the data. Alarms raised post the
population of/sending of the MSD will not
be transmitted. These codes therefore
only indicate status before or at the point
of the incident, and cannot be taken as the
current status post incident.
11
---------------------- Page: 13 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
leakageAlarm BOOLEAN O True if leakage has been detected
fireAlarm BOOLEAN O True if fire has been detected
highTempAlarm BOOLEAN O True if high temperature has been detected
lowTempAlarm BOOLEAN O True if low temperature has been detected
shockAlarm BOOLEAN O True if shock has been detected
highPressureAlar BOOLEAN O True if high pressure has been detected
m
lowPressureAlarm BOOLEAN O True if low pressure has been detected
orientationAlarm BOOLEAN O True if abnormal orientation has been det.
otherAlarm BOOLEAN O True if any other alarm was raised
goodsADR O Up to 7 goods (most dangerous based on
response code, within same response code
prioritised to most impact in fire or largest
volume) can be fully defined.
definedGoodsADR[1] O Each defined good has its own container
with:
cargoUNCode INTEGER M UNCode (max. value: 9999)
1
kemlerCode KemlerCode M Kemler Code of cargo, up to 3 digits
packageGroup INTEGER M Package group (1, 2 or 3)
quantity INTEGER M The quantity of the cargo.
Possible values are:
0: empty but uncleaned,
1 – 98: the quantity as expressed
99: 99 tonnes / 99 m3 or more
quantityUnit ENUM M Quantity is given in:
- tonnes (net)
- tonnes (gross)
- cubic metres
- units
- other
definedGoodsADR [2] O
cargoUNCode See above
kemlerCode
packageGroup
quantity
quantityUnit
1
The Kemler Code is encoded in a defined type that takes the Kemler Code constraints into account
12
---------------------- Page: 14 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
definedGoodsADR [3] O
…
definedGoodsADR [7]
numberOfUndefin INTEGER M Number of ADR goods in the vehicle not
ed… fully defined in this section.
…GoodsADR Possible values:
0: no other ADR goods in vehicle,
1–9: specified number of other ADR goods
in vehicle
10: 10 or more ADR goods in vehicle
15: unknown number of (other) ADR
goods in vehicle
goodsNonADR O Up to 6 materials of significant quantity
(significant defined at the discretion of
consignor) can be defined
NOTE: definition should be in decreasing
order of quantity.
definedGoodsNonADR[1] O Each defined good has its own container
with:
cargoSPSCode INTEGER M The SPC code (can be obtained from
www.unspsc.org)
containerType ENUM M The container type code (according to
ISO 6346)
definedGoodsNonADR[2]
cargoSPSCode
See above
containerType
definedGoodsNonADR[3] O
…
definedGoodsNonADR[6]
numberOfUndefin INTEGER M Number of non ADR goods in the vehicle
ed… not fully defined in this section.
…GoodsNonADR Possible values:
0: no other non ADR goods in vehicle,
1–9: specified number of other non ADR
goods in vehicle
10: 10 or more non ADR goods in vehicle
15: unknown number of (other) non ADR
goods in vehicle
M: Mandatory data field (ie. mandatory if this encoding scheme is used)
O: Optional data field
5.4.4 Contents of the optionalAdditionalData for Schema B
Table 3 provides a summary of the semantic contents of the optionalAdditionalData part of the MSD for
Schema B.
13
---------------------- Page: 15 ----------------------
oSIST prEN 16405:2022
prEN 16405:2022 (E)
The sequence of data presentation shall be as specified in Table 3, represented as described in this clause
and distributed as described in this clause.
For clarity the ‘type’ used in Table 3 is a semantic representation of the type used in the ASN.1 definition.
The exact representation is found in Annex B.
The real position of the element in the data-stream is defined by the ASN.1 ‘unaligned packet encoding
rules (UPER), following the definition in Annex A. Elements therefore do not n
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.