SIST EN 15722:2015
(Main)Intelligent transport systems - ESafety - ECall minimum set of data
Intelligent transport systems - ESafety - ECall minimum set of data
This European Standard specifies the standard data concepts that comprise the "Minimum Set of Data" (MSD) to be transferred from a vehicle to a 'Public Safety Answering Point' (PSAP) in the event of a crash or emergency via an 'eCall' communication transaction.
Optional additional data concepts may also be transferred.
The communications media protocols and methods for the transmission of the eCall message are not specified in this European Standard.
Strassenverkehrstelematik - eSafety - Minimaler Datensatz für den elektronischen Notruf
Systèmes de transport intelligents - ESafety - Ensemble minimal de données (MSD) pour l'eCall
La présente Norme Européenne définit les concepts de données normalisés inclus dans l'ensemble minimal de données (MSD) à transmettre d'un véhicule à un centre de réception des appels d'urgence (PSAP) en cas d'accident ou d'urgence, au cours d'une transaction de communication eCall.
D'autres concepts de données peuvent également être transmis.
La présente Norme européenne ne spécifie ni les protocoles des supports de communication ni les moyens de transmission du message eCall.
Inteligentni transportni sistemi - e-Varnost - Minimalni nabor podatkov za elektronski klic v sili
Ta evropski standard določa standardne podatkovne koncepte, ki sestavljajo »minimalni nabor podatkov« (MSD), ki se prenese od vozila do »odzivne točke javne varnosti« (PSAP), če pride do trka ali nujnega primera, prek komunikacijskega prenosa v okviru elektronskega klica v sili.
Prenesti je mogoče tudi izbirne dodatne podatkovne koncepte.
Komunikacijski medijski protokoli in metode za prenos sporočila elektronskega klica v sili niso opredeljeni v tem evropskem standardu.
General Information
Relations
Standards Content (Sample)
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.Inteligentni transportni sistemi - e-Varnost - Minimalni nabor podatkov za elektronski klic v siliStrassenverkehrstelematik - eSafety - Minimaler Datensatz für den elektronischen NotrufSystèmes de transport intelligents - ESafety - Ensemble minimal de données (MSD) pour l'eCallIntelligent transport systems - ESafety - ECall minimum set of data43.040.15Car informatics. On board computer systems35.240.60Uporabniške rešitve IT v transportu in trgoviniIT applications in transport and trade13.200NDWDVWURIAccident and disaster controlICS:Ta slovenski standard je istoveten z:EN 15722:2015SIST EN 15722:2015en,fr,de01-september-2015SIST EN 15722:2015SLOVENSKI
STANDARDSIST EN 15722:20111DGRPHãþD
SIST EN 15722:2015
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15722
April 2015 ICS 35.240.60 Supersedes EN 15722:2011English Version
Intelligent transport systems - ESafety - ECall minimum set of data
Systèmes de transport intelligents - ESafety - Ensemble minimal de données (MSD) pour l'eCall
Intelligente Transportsysteme - ESicherheit - Minimaler Datensatz für den elektronischen Notruf eCall This European Standard was approved by CEN on 1 February 2015.
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
CEN-CENELEC Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2015 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15722:2015 ESIST EN 15722:2015
EN 15722:2015 (E) 2 Contents Page Foreword . 4 Introduction . 5 1 Scope . 6 2 Normative references . 6 3 Terms and definitions . 6 4 Symbols and abbreviated terms . 7 5 Conformance . 7 6 Requirements . 7 6.1 Concepts and formats . 7 6.1.1 MSD data concepts. 7 6.1.2 Representation of MSD data concepts . 8 6.1.3 Different versions of MSD data . 8 6.1.4 Distribution of MSD data . 8 6.1.5 Additional data . 9 6.2 ISO Object identifier . 9 6.3 Contents of the ‘Minimum Set of Data’ (MSD) . 10 6.3.1 General . 10 6.3.2 Basic contents of MSD version 2 . 10 6.3.3 Previous versions of MSD message . 15 6.3.4 Future versions of MSD message . 15 Annex A (normative)
ASN.1 definition of MSD . 16 A.1 ASN.1 definition of MSD . 16 A.2 Syntax check of ASN.1 definition of MSD . 21 A.3 Examples of ASN.1 encoded MSD . 21 Annex B (informative)
ASN.1 Data representation PER and BER explained . 23 B.1 What is ASN.1 . 23 B.2 Encoding data using ASN.1 . 23 B.2.1 General . 23 B.2.2 Basic Encoding Rules (BER) . 24 B.2.3 Distinguished Encoding Rules (DER). 24 B.2.4 Packed Encoding Rules (PER/UPER) . 24 B.2.5 XML Encoding Rules (XER) . 25 B.3 Examples . 25 B.3.1 General . 25 B.3.2 ASN.1 example definition . 25 B.3.3 Encoding using BER or DER . 25 B.3.4 Encoding using PER . 26 B.3.5 Encoding using XER and E-XER . 26 Annex C (informative)
Formal XML format description (XSD) for the MSD . 28 SIST EN 15722:2015
EN 15722:2015 (E) 3 Annex D (informative)
Explanation of rationale for MSD data concept elements . 33 Annex E (informative)
Object Identifiers (OID) . 35 E.1 Formal definition of OID . 35 E.2 What is an object identifier? . 35 E.3 Object Identifiers and ISO standards . 35 E.4 OID for eCall data concepts . 35 Bibliography . 36
SIST EN 15722:2015
EN 15722:2015 (E) 4 Foreword This document (EN 15722:2015) has been prepared by Technical Committee CEN/TC 278 “Intelligent Transport Systems”, the secretariat of which is held by NEN. This European Standard shall be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by October 2015, and conflicting national standards shall be withdrawn at the latest by October 2015. Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. CEN [and/or CENELEC] shall not be held responsible for identifying any or all such patent rights. This document supersedes EN 15722:2011. This revision is designed to solve ambiguities, provide clarity and improve consistency throughout the document. A significant part of Clause 6 has been reformatted, some parts have been rewritten. None of the proposed changes breaks compatibility with the superseded version. The ASN.1 specifications have been updated to the current most efficient options. Subclause 6.1 now completely describes the information around the concepts, formats and data-encoding, directly relating it to the chosen encoding rules (ASN.1 UPER). The table describing the components of the MSD (6.2) has been revised. The rationale behind this was to remove inconsistencies between the encoding rules and the description. Comments made by Member States have been incorporated. Removed reference to the number of Member States of the European Union. The ASN.1 definition of the MSD has been revised and updated. A syntax check result has been added. An example message with its UPER encoding was also added. Specification of the concept of a data registry to which the ‘oid’ data element refers, and an explanatory Annex (E) explaining the concept of OIDs to has been added. According to the CEN-CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: 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 the United Kingdom. SIST EN 15722:2015
EN 15722:2015 (E) 5 Introduction The scale of death and injury on roads in Europe needs to be fully comprehended to understand the need for "Emergency Call" (eCall). In 2008 there were 38 900 fatalities in the EU Member States. The provisional figure for 2009 is around 34 500 fatalities. The trend 2001-2008 is around 5 % reduction annually. Road accident injuries are in the region of 1,7 million (2007). Roads remain unsafe, and further efforts are needed. The pan-European in-vehicle emergency call, 'eCall', is estimated to have the potential to save up to 2 500 fatalities annually in the EU when fully deployed, and furthermore to reduce the severity of injuries, to bring significant savings to the society in and to reduce human suffering. Emergency calls made from vehicles or mobile telephones using wireless technologies, can assist with the objectives of significantly reducing road deaths and injuries, but drivers often have poor (imprecise) location awareness, especially on interurban roads or abroad. Additionally, in many situations the car occupants may not be in a position to call using a normal mobile phone. The situation is worse for those travelling abroad. A high (and increasing) number of vehicles travelling outside their home country is thus also contributing to the need for automated emergency call system in vehicles. In EU there are over 100 million trips to another EU country per year, 65 % of the people feel less protected while abroad and most do not know which number to call in an emergency (in some countries over 60 %). Language problems are pertinent and may render proper communication difficult.Yet, in the most crucial cases, the victim(s) may not be able to call because they have been injured/trapped, do not know the local number to call, and in many cases, particularly in rural situations and late at night, there may be no witnesses who happen to have a mobile phone and a sense of community. eCall, in the context of "Intelligent Transport Systems" or "ITS",(previously known as "Road Traffic and Transport Telematics") can be described as a "user instigated or automatic system to provide notification to public safety answering points, by means of wireless communications, that a vehicle has crashed, and to provide coordinates and a defined minimum set of data, and where possible a voice link to the PSAP”. The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate the notification of a traffic accident, wherever in the European Union and associated countries, with the same technical standards and the same quality of services objectives of other emergency services (for example the TS12 emergency call of GSM/UMTS). This European Standard specifies the "Minimum Set of Data" (MSD) to be transferred by such an in-vehicle eCall system in the event of a crash or emergency. NOTE
The communications media and means of transferring the eCall MSD are not defined in this European Standard. See list of referenced Standards. SIST EN 15722:2015
EN 15722:2015 (E) 6 1 Scope This European Standard specifies the standard data concepts that comprise the "Minimum Set of Data" (MSD) to be transferred from a vehicle to a 'Public Safety Answering Point' (PSAP) in the event of a crash or emergency via an 'eCall' communication transaction. Optional additional data concepts may also be transferred. The communications media protocols and methods for the transmission of the eCall message are not specified in 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 16062, Intelligent transport systems — ESafety — ECall high level application requirements (HLAP) EN 16072, Intelligent transport systems — ESafety — Pan-European eCall operating requirements EN 16102, Intelligent transport systems — ECall — Operating requirements for third party support ISO 3779, Road vehicles — Vehicle identification number (VIN) — Content and structure ISO/IEC 8825, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) NOTE Communications Standards required for transmission of eCall using GSM/UMTS wireless communications networks are referenced in EN 16062 and EN 16072. 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 ASN.1/Abstract Syntax Notation 1. 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; See Annex B 3.2 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.3 minimum set of data (MSD) direct, timely data content of an eCall message to the PSAP operator receiving the emergency call containing information about the location of the incident, providing detail characterising the vehicle, and potentially sometimes also providing additional data that is deemed relevant 3.4 public safety answering point ‘first level’ responder to whom an emergency call/eCall is directed SIST EN 15722:2015
EN 15722:2015 (E) 7 4 Symbols and abbreviated terms ASN.1 abstract syntax notation one (ISO 8824/ISO 8825) 3G third generation mobile cellular network system, defined by 3GPP standards 3GPP third generation partnership protocol BCD binary coded decimal BER basic encoding rules (ASN.1) CNG compressed natural gas ETSI European telecommunications standards institute EC European Commission EU European Union GSM global system mobile GNSS global navigation satellite system ID identity IP Internet protocol IVS in-vehicle system LPG liquid propane gas M mandatory MSD minimum set of data O optional OID object identifier (ISO/IEC 8824:1994)-see Annex E PER packed encoding rules (ASN.1) PSAP public safety answering point UMTS universal mobile telecommunications system UPER unaligned packet encoding rules (ASN.1) 5 Conformance In order to claim conformance with this European Standard, communication shall be established using accepted wireless communication standards, and it shall be able to demonstrate that the minimum set of data (MSD) transferred together with any standardized optional data elements defined herein comply with the specifications of this European Standard, to the extent that such data is available from the vehicle. 6 Requirements 6.1 Concepts and formats 6.1.1 MSD data concepts NOTE The minimum set of data is important information to assist the provision of the most appropriate services to the crash or emergency site and to speed up the response. The minimum set of data makes it possible for the PSAP operator to respond to the eCall even without the voice connection. The "Minimum Set of Data" shall be a direct, timely message to the PSAP operator receiving the emergency call. The information elements in the MSD have been selected on the basis of their relevance in an emergency rescue situation. SIST EN 15722:2015
EN 15722:2015 (E) 8 The MSD has an ‘optional additional data’ block that can be used to add information elements that are relevant to a specific situation. See 6.1.5. 6.1.2 Representation of MSD data concepts The message shall be sent in the sequence defined within the ASN.1 definition defined in Annex A. The transfer of the MSD for Pan-European eCall using GSM/UMTS (EN 16072/EN 16062) shall be 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 found in Annex A. See also 6.1.4. The transfer of the MSD for Pan-European eCall using other wireless communications media (for example E-UTRAN) may be specified in future standards for ‘high level application protocols’ for that wireless media. NOTE 1
An XML encoding of the MSD data representation may be used in TPSP-to-PSAP applications (EN 16102). Annex C contains the derived XSD for such encoding. NOTE 2 In order to implement presentation in ASN.1 UPER, readers are advised to also read Annex B "ASN.1 Data Representation PER and BER explained"; and also the relevant normative referenced documents. 6.1.3 Different versions of MSD data It is foreseen that, over time, new versions of the MSD data definition will occur. Wherever possible, later versions of the MSD shall be backwards compatible with existing versions. If a future version of the MSD is defined which is not backwards compatible (i.e. cannot be automatically interpreted by receiving systems) then its deployment shall be coordinated to ensure that all receiving systems are ready before IVS adopt this new MSD format. The main structure of an MSD shall, in any version, contain two elements, the first of which is known as the MSD version (msdVersion) which designates the encoding rules that have been used to create the second element. Systems receiving an MSD shall support all standardized MSD versions, which are each uniquely identified using this msdVersion parameter. 6.1.4 Distribution of MSD data The MSD shall be transmitted using one or more communications media as defined in other eCall Standards In order to enable interpretation by the PSAP, the MSD shall always be presented in an ASN.1 encoded module: either ASN.1 ‘Unaligned Packet Encoding Rules’ (UPER) or ASN.1 ‘Extended XML Encoding Rules’ (EXER) encoding shall be used. The ASN.1 module shall contain the MSD as defined in this European Standard plus none or more ‘optional additional data’ concepts presented as defined in 6.1.5 and whose name, content and presentation has been made available in a data registry as required by this European Standard (See 6.1.5). In the case of an MSD for pan-European eCall sent via GSM/UMTS (EN 16072/EN 16062), the MSD shall be encoded using ‘Unaligned Packed Encoding Rules’ (UPER) as defined in ISO/IEC 8825-2. The length of this encoded MSD (including any ‘optional additional data’) shall not exceed 140 bytes (as specified in EN 16062). Any payload bytes received outside of the ASN.1 message length shall be ignored by the receiving entity. The maximum length of data presented by an MSD for pan-European eCall sent via another wireless media shall be defined in the eCall “High Level Application Protocol” standard for that specific wireless media NOTE 1 It is assumed that the integrity of the transmitted data is assured by the underlying communication interface standard used. SIST EN 15722:2015
EN 15722:2015 (E) 9 NOTE 2 For example EN 16072 which defines the operating requirements for the transmission of Pan-European eCall and EN 16062 (eCall high level application protocols for GSM/UMTS) which provide the high level application protocols for sending a Pan-European eCall via a circuit switched GSM/UMTS wireless phone network. EN 16102 defines provisions for Third Party supported eCall. NOTE 3 If the MSD is transferred using another means of communication that has no, or less stringent, data limits, XML encoding rules may be used if preferred. Annex C contains the derived XSD for such encoding. 6.1.5 Additional data The MSD message has a provision for ‘optional’ additional data. This European Standard specifies the presentation of any such data within an MSD message. The nature and content of such additional data is not part of this standard. Examples: Additional data may contain a reference to an external source of relevant information (such as a phone number, a website URL, etc. where further information may be found, or additional data specific to the vehicle or incident (e.g. battery temperature in the case of an electric or hybrid vehicle; number of rollovers; URL to the technical specifications to a particular vehicle model; etc.) Optional additional data shall not include any data concerning or identifying a person (personal data) unless the transfer of such data has been explicitly and expressly prior instructed and authorized by the person who is identified by the data and its provision shall in any event only be provided only in accordance with European Union and National privacy regulations pertaining at the time of the transfer of any such personal data. Any additional data element(s) shall each consist of two parts: a) A relative ‘object identifier’ (OID) b) the data content. The relative OID shall be allocated by CEN TC278 WG15 or a body nominated by it. For further information see annex E. CEN TC278 WG15 or a body nominated by it shall allocate an ‘Object Identifier’ (OID) for each ‘Optional Additional Data concept’. Within the MSD the ‘Optional Additional Data concept’ used shall be identified by a ‘relative OID’, i.e. it will only contain the arcs of the object identifier of the concept starting below the eCall MSD ‘Optional Additional Data concept’ object identifier. See 6.2 below. Additional data shall be represented using an ASN.1representation definition that itself is made available to emergency services/PSAPs. When sending an MSD containing this additional data, using GSM/UMTS (EN 16062), the addition of such data shall never cause the total (UPER encoded) MSD message length to exceed the maximum available number of bytes (total message length = 140 bytes). NOTE in order to ensure that the above requirement is met with any combination of optional parameters within the main MSD message, the total length of additional data concepts may not exceed 94 bytes of data encoded in ASN.1 UPER. 6.2 ISO Object identifier ISO/ITU “Object Identifiers” are explained in informative Annex E. The full eCall MSD, or any optional additional data concept, is preceded by its ISO object identifier. When eCall data is stored or used outside of the eCall context this OID shall be prefixed onto all representations of the MSD or any eCall data concept. SIST EN 15722:2015
EN 15722:2015 (E) 10 In eCall context, when data is being sent to a specific receiver (e.g. PSAP), the OID may be assumed to be known and is not transmitted. Thus the OID is not transferred over the air between the IVS and PSAP. eCall has been allocated the OID: 1.0.14817.106.2.1 NOTE
1.
identifies the data concept as an ISO parent route standard 0.
identifies the arc as being identified by a Standards reference number. 14817 In this case ISO 14817 being the parent standard for ITS data registry 106
emergency-service
2 pre-harmonisation-automated-calls
1 cen-15722 Below this OID three nodes are defined:
1.0.14817.106.2.1.1
for ‘Mandatory Data Concepts’
1.0.14817.106.2.1.2
for ‘Optional Data Concepts’
1.0.14817.106.2.1.3
for eCall data elements 6.3 Contents of the ‘Minimum Set of Data’ (MSD) 6.3.1 General The following sub-clauses provide the definition of the minimum set of data that shall be sent from the vehicle in case of an emergency call. 6.3.2 Basic contents of MSD version 2 Table 1 provides a summary of the semantic contents of the MSD. The sequence of data presentation shall be as specified in Table 1, represented as described in 6.1.2 and distributed as described in 6.1.3. For clarity the ‘type’ used in Table 1 is a semantic representation of the type used in the ASN.1 definition. The exact representation is defined 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. SIST EN 15722:2015
EN 15722:2015 (E) 11 Table 1 — Contents/format of the MSD data concept M – Mandatory data field O – Optional data field. MSD
msdVersion INTEGER (1.255) - M MSD format version The format described in this document carries version 2 See 6.1.3 for detailed information. Msd
msdStructure
messageIdentifier INTEGER (1.255)
M Message identifier, starting with 1 for each new eCall transaction and to be incremented with every application layer MSD retransmission following a new ‘Send MSD’ request after the incident event Control M
automaticActivation BOOLEAN
true = Automatic activation false = Manual activation testCall BOOLEAN
true = Test call false = Emergency positionCanBeTrustd BOOLEAN
true = Position can be trusted false = Low confidence in position
“Low confidence in position” shall mean that there is less than 95 % confidence that exact position is within a radius of ± 150 m of reported position
vehicleType ENUM
The supported vehicle types are as follows: - passenger vehicle (Class M1) - buses and coaches (Class M2) - buses and coaches (Class M3) - light commercial vehicles (Class N1) - heavy duty vehicles (Class N2) - heavy duty vehicles (Class N3) - motorcycles (Class L1e) - motorcycles (Class L2e) - motorcycles (Class L3e) SIST EN 15722:2015
EN 15722:2015 (E) 12 - motorcycles (Class L4e) - motorcycles (Class L5e) - motorcycles (Class L6e) - motorcycles (Class L7e)
Vehicle definitions class M, N according to directive 2007/46/EC; class L according directive 2002/24/EC.
VIN1 VIN1
M VIN number according to ISO 3779 vehiclePropulsionStorageType M Contains information about the presence of propulsion storage inside the vehicle sending the MSD.
gasolineTankPresent BOOLEAN
true = present; false = not present
If no information about the propulsion storage is known, all elements should be set to FALSE. dieselTankPresent BOOLEAN
compressedNaturalGas BOOLEAN
liquidPropaneGas BOOLEAN
electricEnergySt
...
SLOVENSKI STANDARD
kSIST FprEN 15722:2014
01-oktober-2014
Inteligentni transportni sistemi - e-Varnost - Minimalni nabor podatkov za
elektronski klic v sili
Intelligent transport systems - ESafety - ECall minimum set of data
Strassenverkehrstelematik - eSafety - Minimaler Datensatz für den elektronischen Notruf
Systèmes de transport intelligents - ESafety - Ensemble minimal de données (MSD) pour
l'eCall
Ta slovenski standard je istoveten z: FprEN 15722
ICS:
13.200 3UHSUHþHYDQMHQHVUHþLQ Accident and disaster control
NDWDVWURI
35.240.60 Uporabniške rešitve IT v IT applications in transport
transportu in trgovini and trade
43.040.15 $YWRPRELOVNDLQIRUPDWLND Car informatics. On board
9JUDMHQLUDþXQDOQLãNLVLVWHPL computer systems
kSIST FprEN 15722:2014 en,fr,de
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
kSIST FprEN 15722:2014
---------------------- Page: 2 ----------------------
kSIST FprEN 15722:2014
EUROPEAN STANDARD
FINAL DRAFT
FprEN 15722
NORME EUROPÉENNE
EUROPÄISCHE NORM
July 2014
ICS 35.240.60 Will supersede EN 15722:2011
English Version
Intelligent transport systems - ESafety - ECall minimum set of
data
Systèmes de transport intelligents - ESafety - Ensemble Strassenverkehrstelematik - eSafety - Minimaler Datensatz
minimal de données (MSD) pour l'eCall für den elektronischen Notruf
This draft European Standard is submitted to CEN members for unique acceptance procedure. 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, 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.
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: Avenue Marnix 17, B-1000 Brussels
© 2014 CEN All rights of exploitation in any form and by any means reserved Ref. No. FprEN 15722:2014 E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
Contents Page
Foreword . 3
Introduction . 4
1 Scope . 5
2 Normative references . 5
3 Terms and definitions . 5
4 Symbols and abbreviated terms . 5
5 Conformance . 6
6 Requirements . 6
6.1 Concepts and formats . 6
6.1.1 MSD data concepts. 6
6.1.2 Representation of MSD data concepts . 7
6.1.3 Different versions of MSD data . 7
6.1.4 Distribution of MSD data . 7
6.1.5 Additional data . 8
6.2 ISO Object identifier . 8
6.3 Contents of the ‘Minimum Set of Data’ (MSD) . 9
6.3.1 Basic contents of MSD version 2 . 9
6.3.2 Previous versions of MSD message . 14
6.3.3 Future versions of MSD message . 14
Annex A (normative) ASN.1 definition of MSD . 15
A.1 ASN.1 definition of MSD . 15
A.2 Syntax check of ASN.1 definition of MSD . 20
A.3 Examples of ASN.1 encoded MSD . 20
Annex B (informative) ASN.1 Data representation PER and BER explained . 22
B.1 What is ASN.1 . 22
B.2 Encoding data using ASN.1 . 22
B.2.1 Basic Encoding Rules (BER) . 22
B.2.2 Distinguished Encoding Rules (DER). 23
B.2.3 Packed Encoding Rules (PER/UPER) . 23
B.2.4 XML Encoding Rules (XER) . 24
B.3 Examples . 24
B.3.1 ASN.1 example definition . 24
B.3.2 Encoding using BER or DER . 24
B.3.3 Encoding using PER . 25
B.3.4 Encoding using XER and E-XER . 25
Annex C (informative) Formal XML format description (XSD) for the MSD . 26
Annex D (informative) Explanation of rationale for MSD data concept elements . 31
Annex E (informative) Object Identifiers (OID) . 33
E.1 Formal definition of OID . 33
E.2 What is an object identifier? . 33
E.3 Object Identifiers and ISO standards . 33
E.4 OID for eCall data concepts . 33
Bibliography . 34
2
---------------------- Page: 4 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
Foreword
This document (EN 15722:2014) 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 Unique Acceptance Procedure.
This document supersedes EN 15722:2011.
This revision is designed to solve ambiguities, provide clarity and improve consistency throughout the
document. A significant part of chapter 6 has been reformatted, some parts have been rewritten. None of the
proposed changes breaks compatibility with the superseded version. The ASN.1 specifications have been
updated to the current most efficient options.
Paragraph 6.1 now completely describes the information around the concepts, formats and data-encoding,
directly relating it to the chosen encoding rules (ASN.1 UPER). The table describing the components of the
MSD (paragraph 6.2) has been revised. The rationale behind this was to remove inconsistencies between the
encoding rules and the description.
Comments made by Member States have been incorporated. Removed reference to the number of Member
States of the European Union.
The ASN.1 definition of the MSD has been revised and updated. A syntax check result has been added. An
example message with its UPER encoding was also added.
Specification of the concept of a data registry to which the ‘oid’ data element refers, and an explanatory Annex
(E) explaining the concept of OIDs to has been added.
3
---------------------- Page: 5 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
Introduction
The scale of death and injury on roads in Europe needs to be fully comprehended to understand the need for
"Emergency Call" (eCall). In 2008 there were 38 900 fatalities in the EU- Member States. The provisional
figure for 2009 is around 34 500 fatalities. The trend 2001-2008 is around 5% reduction annually. Road
accident injuries are in the region of 1,7 million (2007). Roads remain unsafe, and further efforts are needed.
The pan-European in-vehicle emergency call, 'eCall', is estimated to have the potential to save up to 2 500
fatalities annually in the EU when fully deployed, and furthermore to reduce the severity of injuries, to bring
significant savings to the society in and to reduce human suffering.
Emergency calls made from vehicles or mobile telephones using wireless technologies, can assist with the
objectives of significantly reducing road deaths and injuries, but drivers often have poor (imprecise) location
awareness, especially on interurban roads or abroad. Additionally, in many situations the car occupants may
not be in a position to call using a normal mobile phone.
The situation is worse for those travelling abroad. A high (and increasing) number of vehicles travelling
outside their home country is thus also contributing to the need for automated emergency call system in
vehicles. In EU there are over 100 million trips to another EU country per year, 65 % of the people feel less
protected while abroad and most do not know which number to call in an emergency (in some countries over
60 %). Language problems are pertinent and may render proper communication difficult .Yet, in the most
crucial cases, the victim(s) may not be able to call because they have been injured/trapped, do not know the
local number to call, and in many cases, particularly in rural situations and late at night, there may be no
witnesses who happen to have a mobile phone and a sense of community.
eCall, in the context of "Intelligent Transport Systems" or "ITS",(previously known as "Road Traffic and
Transport Telematics") can be described as a "user instigated or automatic system to provide notification to
public safety answering points, by means of wireless communications, that a vehicle has crashed, and to
provide coordinates and a defined minimum set of data, and where possible a voice link to the PSAP”.
The objective of implementing the pan-European in-vehicle emergency call system (eCall) is to automate the
notification of a traffic accident, wherever in the European Union and associated countries, with the same
technical standards and the same quality of services objectives of other emergency services (for example the
TS12 emergency call of GSM/UMTS).
This European Standard specifies the "Minimum Set of Data" (MSD) to be transferred by such an in-vehicle
eCall system in the event of a crash or emergency.
NOTE The communications media and means of transferring the eCall MSD are not defined in this European
Standard. See list of referenced Standards.
4
---------------------- Page: 6 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
1 Scope
This European Standard specifies the standard data concepts that comprise the "Minimum Set of Data"
(MSD) to be transferred from a vehicle to a 'Public Safety Answering Point' (PSAP) in the event of a crash or
emergency via an 'eCall' communication transaction.
Optional additional data concepts may also be transferred.
The communications media protocols and methods for the transmission of the eCall message are not
specified in 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. ISO/IEC 8825
Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)
EN 16062, Intelligent transport systems - eSafety - eCall high level application requirements (HLAP)
EN 16072, Intelligent transport systems - eSafety - Pan-European eCall operating requirements
EN 16102, Intelligent transport systems - eCall - Operating requirements for third party support
NOTE: Communications Standards required for transmission of eCall using GSM/UMTS wireless communications
networks are referenced in EN 16062 and EN 16072.
3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
ASN.1/Abstract Syntax Notation 1.
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; See Annex
B
4.2
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
standardised ‘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'
4.3
minimum set of data (MSD)
direct, timely data content of an eCall message to the PSAP operator receiving the emergency call containing
information about the location of the incident, providing detail characterising the vehicle, and potentially
sometimes also providing additional data that is deemed relevant
4.4
public safety answering point
‘first level’ responder to whom an emergency call/eCall is directed
4 Symbols and abbreviated terms
ASN.1 abstract syntax notation one (ISO 8824/ISO 8825)
5
---------------------- Page: 7 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
3G third generation mobile cellular network system, defined by 3GPP standards
3GPP
third generation partnership protocol
BCD binary coded decimal
BER basic encoding rules (ASN.1)
CNG compressed natural gas
ETSI European telecommunications standards institute
EC European Commission
EU
European Union
GSM global system mobile
GNSS global navigation satellite system
ID identity
IP
Internet protocol
IVS in-vehicle system
LPG
liquid propane gas
M mandatory
MSD minimum set of data
O optional
OID
object identifier (ISO/IEC 8824:1994)-see Annex E
PER packed encoding rules (ASN.1)
PSAP
public safety answering point
UMTS universal mobile telecommunications system
UPER unaligned packet encoding rules (ASN.1)
5 Conformance
In order to claim conformance with this European Standard, communication shall be established using
accepted wireless communication standards, and it shall be able to demonstrate that the minimum set of data
(MSD) transferred together with any standardised optional data elements defined herein comply with the
specifications of this European Standard, to the extent that such data is available from the vehicle.
6 Requirements
6.1 Concepts and formats
6.1.1 MSD data concepts
NOTE The minimum set of data is important information to assist the provision of the most appropriate services to
the crash or emergency site and to speed up the response. The minimum set of data makes it possible for the PSAP
operator to respond to the eCall even without the voice connection.
The "Minimum Set of Data" shall be a direct, timely message to the PSAP operator receiving the emergency
call.
The information elements in the MSD have been selected on the basis of their relevance in an emergency
rescue situation.
6
---------------------- Page: 8 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
The MSD has an ‘optional additional data’ block that can be used to add information elements that are
relevant to a specific situation. See 6.1.5.
6.1.2 Representation of MSD data concepts
The message shall be sent in the sequence defined within the ASN.1 definition defined in Annex A.
The transfer of the MSD for Pan-European eCall using GSM/UMTS (EN 16072/EN 16062) shall be
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 found in Annex A. See also 6.1.4.
The transfer of the MSD for Pan-European eCall using other wireless communications media (for example E-
UTRAN) may be specified in future standards for ‘high level application protocols’ for that wireless media.
NOTE 1 An XML encoding of the MSD data representation may be used in TPSP-to-PSAP applications (EN 16102).
Annex C contains the derived XSD for such encoding.
NOTE 2 In order to implement presentation in ASN.1 UPER, readers are advised to also read Annex B "ASN.1 Data
Representation PER and BER explained"; and also the relevant normative referenced documents.
6.1.3 Different versions of MSD data
It is foreseen that, over time, new versions of the MSD data definition will occur. Wherever possible, later
versions of the MSD shall be backwards compatible with existing versions.
If a future version of the MSD is defined which is not backwards compatible (i.e. cannot be automatically
interpreted by receiving systems) then its deployment shall be coordinated to ensure that all receiving systems
are ready before IVS adopt this new MSD format.
The main structure of an MSD shall, in any version, contain two elements, the first of which is known as the
MSD version (msdVersion) which designates the encoding rules that have been used to create the second
element.
Systems receiving an MSD shall support all standardised MSD versions, which are each uniquely identified
using this msdVersion parameter.
6.1.4 Distribution of MSD data
The MSD shall be transmitted using one or more communications media as defined in other eCall Standards
In order to enable interpretation by the PSAP, the MSD shall always be presented in an ASN.1 encoded
module: either ASN.1 ‘Unaligned Packet Encoding Rules’ (UPER) or ASN.1 ‘Extended XML Encoding Rules’
(EXER) encoding shall be used.
The ASN.1 module shall contain the MSD as defined in this European Standard plus none or more ‘optional
additional data’ concepts presented as defined in 6.1.5 and whose name, content and presentation has been
made available in a data registry as required by this European Standard (See 6.1.5).
In the case of an MSD for pan-European eCall sent via GSM/UMTS (EN 16072/EN 16062), the MSD shall be
encoded using ‘Unaligned Packed Encoding Rules’ (UPER) as defined in ISO/IEC 8825-2. The length of this
encoded MSD (including any ‘optional additional data’) shall not exceed 140 bytes (as specified in EN 16062).
Any payload bytes received outside of the ASN.1 message length shall be ignored by the receiving entity.
The maximum length of data presented by an MSD for pan-European eCall sent via another wireless media
shall be defined in the eCall “High Level Application Protocol” standard for that specific wireless media
NOTE 1 It is assumed that the integrity of the transmitted data is assured by the underlying communication interface
standard used.
7
---------------------- Page: 9 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
NOTE 2 For example EN 16072 which defines the operating requirements for the transmission of Pan-European eCall
and EN 16062 (eCall high level application protocols for GSM/UMTS) which provide the high level application protocols for
sending a Pan-European eCall via a circuit switched GSM/UMTS wireless phone network.
EN 16102 defines provisions for Third Party supported eCall.
NOTE 3 If the MSD is transferred using another means of communication that has no, or less stringent, data limits,
XML encoding rules may be used if preferred. Annex C contains the derived XSD for such encoding.
6.1.5 Additional data
The MSD message has a provision for ‘optional’ additional data. This European Standard specifies the
presentation of any such data within an MSD message. The nature and content of such additional data is not
part of this standard.
Examples: Additional data may contain a reference to an external source of relevant information (such as a
phone number, a website URL, etc. where further information may be found, or additional data specific to the
vehicle or incident (e.g. battery temperature in the case of an electric or hybrid vehicle; number of rollovers;
URL to the technical specifications to a particular vehicle model; etc.)
Optional additional data shall not include any data concerning or identifying a person (personal data) unless
the transfer of such data has been explicitly and expressly prior instructed and authorised by the person who
is identified by the data and its provision shall in any event only be provided only in accordance with European
Union and National privacy regulations pertaining at the time of the transfer of any such personal data.
Any additional data element(s) shall each consist of two parts:
a) A relative ‘object identifier’ (OID)
b) the data content.
The relative OID shall be allocated by CEN TC278 WG15 or a body nominated by it. For further information
see annex E.
CEN TC278 WG15 or a body nominated by it shall allocate an ‘Object Identifier’ (OID) for each ‘Optional
Additional Data concept’. Within the MSD the ‘Optional Additional Data concept’ used shall be identified by a
‘relative OID’, i.e. it will only contain the arcs of the object identifier of the concept starting below the eCall
MSD ‘Optional Additional Data concept’ object identifier. See 6.2 below.
Additional data shall be represented using an ASN.1representation definition that itself is made available to
emergency services/PSAPs.
When sending an MSD containing this additional data, using GSM/UMTS (EN 16062), the addition of such
data shall never cause the total (UPER encoded) MSD message length to exceed the maximum available
number of bytes (total message length = 140 bytes).
NOTE: in order to ensure that the above requirement is met with any combination of optional parameters within the main
MSD message, the total length of additional data concepts may not exceed 94 bytes of data encoded in ASN.1 UPER.
6.2 ISO Object identifier
ISO/ITU “Object Identifiers” are explained in informative Annex E.
The full eCall MSD, or any optional additional data concept, is preceded by its ISO object identifier. When
eCall data is stored or used outside of the eCall context this OID shall be prefixed onto all representations of
the MSD or any eCall data concept.
In eCall context, when data is being sent to a specific receiver (e.g. PSAP), the OID may be assumed to be
known and is not transmitted. Thus the OID is not transferred over the air between the IVS and PSAP.
8
---------------------- Page: 10 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
eCall has been allocated the OID: 1.0.14817.106.2.1
NOTE:
1. identifies the data concept as an ISO parent route standard
0. identifies the arc as being identified by a Standards reference number.
14817 In this case ISO 14817 being the parent standard for ITS data registry
106 emergency-service
2 pre-harmonisation-automated-calls
1 cen-15722
Below this OID three nodes are defined:
1.0.14817.106.2.1.1 for ‘Mandatory Data Concepts’
1.0.14817.106.2.1.2 for ‘Optional Data Concepts’
1.0.14817.106.2.1.3 for eCall data elements
6.3 Contents of the ‘Minimum Set of Data’ (MSD)
6.3.1 General
The following sub-clauses provide the definition of the minimum set of data that shall be sent from the vehicle
in case of an emergency call.
6.3.2 Basic contents of MSD version 2
Table 1 provides a summary of the semantic contents of the MSD.
The sequence of data presentation shall be as specified in Table 1, represented as described in 6.1.2 and
distributed as described in 6.1.3.
For clarity the ‘type’ used in Table 1 is a semantic representation of the type used in the ASN.1 definition. The
exact representation is defined 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 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
Table 1 — Contents/format of the MSD data concept
M – Mandatory data field
O – Optional data field.
MSD
msdVersion INTEGER - M MSD format version
(1.255) The format described in this
document carries version 2
See 6.1.3 for detailed information.
Msd
msdStructure
messageIdentifier INTEGER M Message identifier, starting with 1
for each new eCall transaction and
(1.255)
to be incremented with every
application layer MSD
retransmission following a new
‘Send MSD’ request after the
incident event
Control M
automaticActivation BOOLEAN true = Automatic activation
false = Manual activation
testCall BOOLEAN true = Test call
false = Emergency
positionCanBeTrustd BOOLEAN true = Position can be trusted
false = Low confidence in position
“Low confidence in position” shall
mean that there is less than 95%
confidence that exact position is
within a radius of ± 150 m of
reported position
vehicleType ENUM The supported vehicle types are as
follows:
- passenger vehicle (Class M1)
- buses and coaches (Class M2)
- buses and coaches (Class M3)
- light commercial vehicles (Class
N1)
- heavy duty vehicles (Class N2)
- heavy duty vehicles (Class N3)
- motorcycles (Class L1e)
- motorcycles (Class L2e)
- motorcycles (Class L3e)
- motorcycles (Class L4e)
- motorcycles (Class L5e)
10
---------------------- Page: 12 ----------------------
kSIST FprEN 15722:2014
FprEN 15722:2014 (E)
- motorcycles (Class L6e)
- motorcycles (Class L7e)
Vehicle definitions class M, N
according to directive 2007/46/EC;
class L according directive
2002/24/EC.
1 1
VIN VIN M VIN number according to ISO 3779
vehiclePropulsionStorageType M Contains information about the
presence of propulsion storage
inside the vehicle sending the MSD.
gasolineTankPresent BOOLEAN
dieselTankPresent BOOLEAN
compressedNaturalG BOOLEAN
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.