SIST-TS CEN/TS 16405:2017

SLOVENSKI STANDARD
SIST-TS CEN/TS 16405:2017
01-julij-2017
1DGRPHãþD
SIST-TP CEN/TR 16405:2013
Inteligentni transportni sistemi - E-klic - Koncept specifikacij za dodatne podatke
za težka tovorna vozila
Intelligent transport systems - Ecall - Additional data concept specification for heavy
goods vehicles
Intelligente Verkehrssysteme - E-Sicherheit - Zusätzliche Datenkonzept-Spezifikation für
Lastkraftwagen
Systèmes de transports intelligents - Sécurité - Spécification de conception de données
additionnelles pour les poids lourds
Ta slovenski standard je istoveten z: CEN/TS 16405:2017
ICS:
03.220.20 Cestni transport Road transport
35.240.60 Uporabniške rešitve IT v IT applications in transport
prometu
SIST-TS CEN/TS 16405:2017 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

---------------------- Page: 1 ----------------------

SIST-TS CEN/TS 16405:2017

---------------------- Page: 2 ----------------------

SIST-TS CEN/TS 16405:2017


CEN/TS 16405
TECHNICAL SPECIFICATION

SPÉCIFICATION TECHNIQUE

January 2017
TECHNISCHE SPEZIFIKATION
ICS 03.220.20; 35.240.60 Supersedes CEN/TR 16405:2013
English Version

Intelligent transport systems - Ecall - Additional data
concept specification for heavy goods vehicles
Systèmes de transports intelligents - Sécurité - Intelligente Verkehrssysteme - E-Sicherheit -
Spécification de conception de données additionnelles Zusätzliche Datenkonzept-Spezifikation für
pour les poids lourds Lastkraftwagen
This Technical Specification (CEN/TS) was approved by CEN on 13 October 2014 for provisional application.

The period of validity of this CEN/TS is limited initially to three years. After two years the members of CEN will be requested to
submit their comments, particularly on the question whether the CEN/TS can be converted into a European Standard.

CEN members are required to announce the existence of this CEN/TS in the same way as for an EN and to make the CEN/TS
available promptly at national level in an appropriate form. It is permissible to keep conflicting national standards in force (in
parallel to the CEN/TS) until the final decision about the possible conversion of the CEN/TS into an EN is reached.

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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and United Kingdom.





EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION

EUROPÄISCHES KOMITEE FÜR NORMUNG

CEN-CENELEC Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2017 CEN All rights of exploitation in any form and by any means reserved Ref. No. CEN/TS 16405:2017 E
worldwide for CEN national Members.

---------------------- Page: 3 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
Contents Page
Foreword . 3
Introduction . 4
1 Scope . 5
2 Normative References . 5
3 Terms and definitions . 5
4 Symbols and abbreviations . 6
5 Requirements . 7
5.1 General . 7
5.2 Concepts and formats . 7
5.2.1 MSD data concepts . 7
5.2.2 Representation of MSD data concepts . 7
5.2.3 Distribution of MSD data . 7
5.2.4 Commercial vehicles optional additional data concept ‘Object Identifier’ . 7
5.2.5 Commercial vehicle optional additional data concept ‘data’ . 8
5.3 Contents of the ‘Minimum Set of Data’ (MSD) . 8
5.3.1 Basic contents of MSD . 8
5.3.2 Contents of the optionalAdditionalData for Schema A . 9
5.3.3 Contents of the optionalAdditionalData for Schema B . 13
Annex A (normative) ASN.1 definition of optional datablock . 16
A.1 General . 16
A.2 Definition of contents of optionalAdditionalData.data Schema A . 16
A.2.1 ASN.1 definition . 16
A.2.2 Syntax check of ASN.1 definition . 18
A.2.3 Example . 18
A.3 Definition of contenst of optionalAdditionalData.data Schema B . 19
A.3.1 General . 19
A.3.2 ASN.1 definition . 19
A.3.3 Syntax check . 20
A.3.4 Example . 20
Annex B (informative) ASN.1 definition of complete MSD message with HGV info . 22
B.1 General . 22
B.2 ASN.1 definition of complete extended MSD message, HGV Schema A . 22
B.3 Example . 29
Bibliography . 32

2

---------------------- Page: 4 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
Foreword
This document (CEN/TS 16405:2017) has been prepared by Technical Committee CEN/TC 278
“Intelligent transport systems”, the secretariat of which is held by NEN.
Attention is drawn to the possibility that some of the elements of this document may be the subject of
patent rights. CEN shall not be held responsible for identifying any or all such patent rights.
This document supersedes CEN/TR 16405:2013.
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). The semantic content of this Technical Specification remains
unchanged. However the parent Standard EN 15722 (eCall Minimum Set of Data) has been revised and
updated, and this Technical Specification is consistent with the layout and specifications of the revised
EN 15722.
According to the CEN/CENELEC Internal Regulations, the national standards organisations of the
following countries are bound to announce this Technical Specification: 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, Serbia, Slovakia, Slovenia, Spain, Sweden, Switzerland,
Turkey and the United Kingdom.
3

---------------------- Page: 5 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (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 Technical Specification provides specification for an optional additional data concept for
commercial vehicles to provide dynamic data about the load 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 where information about the goods (ADR classified or not) is known
in the eCall device; the second variant (schema B) is for use where information about the load has to be
fetched from other sources.
It is the intention that this Technical Specification is tested in demonstration projects (such as HeERO)
with a view to becoming the basis for a future European or International Standard.
In order to claim conformance with this Technical Specification, 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 optional data elements defined herein comply with the
specifications of this Technical Specification, to the extent that such data are available from the vehicle.
4

---------------------- Page: 6 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
1 Scope
This Technical Specification 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
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 Technical Specification 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 Technical Specification.
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.
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.
EN 15722, Intelligent transport systems - ESafety - ECall minimum set of data
ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules
(PER) — Part 2
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 [ETSI/TS 122 003]
3.2
ASN.1
abstract syntax notation one as specified in the various parts of ITU Recs 8824 and 8825 (ISO 8824 and
ISO 8825 various parts)
5

---------------------- Page: 7 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
3.3
commercial vehicle
mechanically propelled road vehicle (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 includes vehicles designed or adapted to have a maximum weight exceeding 3,500 tonnes,
but explicitly excludes busses or other vehicles designed and constructed for the carriage of passengers (ie.
vehicle types M1, M2 or M3)
3.4
dangerous goods
categories of goods carried by road defined by the ‘European Agreement concerning the ‘International
Carriage of Dangerous Goods by Road’ (ADR) as dangerous; these are characterised as articles or
substances which are capable of posing a significant risk to health, safety or to property when
transported
3.5
eCall
emergency call generated either automatically via activation of in-vehicle sensors or manually by the
vehicle occupants; 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.6
Kemler code
ADR Hazard Identification Number (HIN), carried on placards on tank cars and tank containers running
by road under international ADR regulations
3.7
uniform resource identifier
URI
string of characters used to identify a name or a resource on the Internet
3.8
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
ADR Accord européen relative au transport international des marchandises Dangereuses
par Route
ETSI European Telecommunications Standards Institute
M Mandatory
MSD Minimum set of data
6

---------------------- Page: 8 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
O Optional
PER Packed Encoding Rules (ASN.1)
PSAP Public Safety Answering Point
UPER Unaligned Packed Encoding Rules (ASN.1)
5 Requirements
5.1 General
This Technical Specification 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 loads in the additional data block
5.2 Concepts and formats
5.2.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.2.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 load of the vehicle sending the MSD shall be represented in ASN.1 UPER as
well, following the provision made in above named Annex.
5.2.3 Distribution of MSD data
The MSD shall be transmitted as described in EN 15722.
5.2.4 Commercial vehicles optional additional data concept ‘Object Identifier’
The object identifier uniquely identifies the format and meaning of the data which follows in the
optional additional data concept.
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
‘Optional Additional Data concepts’. The OID for this deliverable shall be 1.0.14817.106.2.1.2.1.
7

---------------------- Page: 9 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
This deliverable defines two schemes that each have their own unique OID:
Schema A: 1.0.14817.106.2.1.2.1.1
Schema B: 1.0.14817.106.2.1.2.1.2
The OID for ‘Optional Additional Data concepts’ (1.0.14817.106.2.1.2) is fixed and shall not be
transmitted over the air as part of the optional 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.
For further detail regarding the use of OIDs in eCall, see EN 15722.
5.2.5 Commercial vehicle optional additional data concept ‘data’
The objective of the commercial vehicle 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 optional additional
data, using the GSM/UMTS maximum message length limit as defined in EN 16062 (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.3 Contents of the ‘Minimum Set of Data’ (MSD)
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.3.1 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.
8

---------------------- Page: 10 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
Table 1 — Contents/format of the MSD data concept
M Mandatory data field  ___________________________________________________________________
O Optional data field    ___________________________________________________________________
MSD
 msdVersion INTEGER - M
(1.255)
msd
  msdStructure

 optionalAdditionalData O
  oid RELATIVE-
OID
  data OCTET
STRING
This document describes the contents of the optionalAdditionalData block.
5.3.2 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.
9

---------------------- Page: 11 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
Table 2 — Contents/format of Commercial vehicle additional data Schema A
M Mandatory data field (ie. mandatory if this encoding scheme is used)
O Optional data field
optionalAdditionalData
 oid RELATIVE  M Fixed value: 1.1
OID
data encoded as OCTET STRING
commercialVehicleTyp
 ENUM  M The supported types are:
e
- unknown
- tanker, one compartment
- tanker, more compartments
- piece cargo
consignorPhone NumericalS M Consignor contact telephone number or
tring telephone number displayed on goods
container as contact number in case of
emergency.
NOTE: the number should be specified
as international number, thus including
the country- and area code (without
zero)
 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.
  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
10

---------------------- Page: 12 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
lowTempAlarm BOOLEAN  O True if low temperature has been
detected
shockAlarm BOOLEAN  O True if shock has been detected
highPressureAlarm
BOOLEAN  O True if high pressure has been detected
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)
kemlerCode KemlerCod M Kemler Code of cargo, up to 3 digits
1
e
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
quantityInTonnes
BOOLEAN  M True: quantity is given in tonnes
False: quantity is given in m3 (rounded
up)
quantityIsGross BOOLEAN  M True: quantity is gross weight/volume
definedGoodsADR [2] O
cargoUNCode
 See above
kemlerCode
packageGroup
quantity
quantityInTonnes
quantityIsGross

definedGoodsADR [3] O
…

1
The Kemler Code is encoded in a defined type that takes the Kemler Code constraints into account
11

---------------------- Page: 13 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
definedGoodsADR [7]
numberOfUndefined
 INTEGER  M Number of ADR goods in the vehicle not
…
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]
numberOfUndefined
INTEGER  M Number of non ADR goods in the vehicle
…
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
12

---------------------- Page: 14 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
5.3.3 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.
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 necessarily start or end on
a byte boundary.
Table 3 — Contents/format of Commercial vehicle additional data Schema B
M Mandatory data field (i.e. mandatory if this encoding scheme is used)
O Optional data field
optionalAdditionalData
 oid RELATIVE  M Fixed value: 1,2
OID
data encoded as OCTET STRING
 commercialVehicleT ENUM  M The supported types are:
ype
- unknown
- tanker, one compartment
- tanker, more compartments
- truck, (stukvracht)
consignorPhone NumericalS M Consignor contact telephone number or
tring telephone number displayd on goods
container as contact number in case of
emergency.
NOTE: the number should be specified as
international number, thus including the
country- and areacode (without zero)
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
13

---------------------- Page: 15 ----------------------

SIST-TS CEN/TS 16405:2017
CEN/TS 16405:2017 (E)
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.
 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
lowPressureAlar BOOLEAN  O True if low pressure has been detected
m
orientationAlarm BOOLEAN  O True if abnormal orientation has been
det.
otherAlarm BOOLEAN  O True if any other alarm was raised
numberOfGoodsAD INTEGER  M Number of ADR goods in the vehicle not
R fully defined in this secti
...