SIST EN 15722:2011
(Main)Intelligent transport systems - eSafety - eCall minimum set of data (MSD)
Intelligent transport systems - eSafety - eCall minimum set of data (MSD)
This Technical Specification defines the standard data concepts that comprise the "Minimum Set of Data" 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 session.
NOTE 1 The communications protocols and methods for the transmission of the eCall message are not specified in this Technical Specification.
NOTE 2 Additional data concepts may also be transferred, and any such data concepts should be registered using a data registry as defined in CEN ISO/TS 24978
Straßenverkehrstelematik - eSicherheit - Minimaler Datensatz für den elektronischen Notruf
Diese Europäische Norm legt die Normdatenkonzepte für den „minimalen Datensatz“ (MSD) fest, welcher, im
Rahmen des fahrzeuggebundenen Notrufs (eCall) bei einem Verkehrsunfall oder sonstigen Notfall, an eine
Rettungsleitstelle (PSAP) übertragen werden muss.
ANMERKUNG 1 Die Kommunikationsmedienprotokolle und die Verfahren für die Übertragung der eCall-Nachricht sind
in der vorliegenden Norm nicht festgelegt.
ANMERKUNG 2 Es können auch noch weitere Datenkonzepte übertragen werden, es gilt jedoch als Empfehlung, dass
diese Datenkonzepte mit Hilfe eines Datenverzeichnisses, wie in EN ISO 24978 festgelegt, registriert werden sollten.
Télématique de la circulation et du transport routier - 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 qui incluent l'ensemble
minimal de données (MSD) à transférer 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 session de communication eCall.
NOTE 1 Cette norme ne spécifie ni les protocoles des supports de communication, ni les méthodes de
transmission du message eCall.
NOTE 2 D'autres concepts de données peuvent également être transférés. Dans ce cas, il convient d'enregistrer
ces concepts en utilisant un registre de données tel que défini dans l'EN ISO 24978.
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 prenaša iz vozila do »odzivne točke javne varnosti« (PSAP) ob nesreči ali nujnem dogodku prek komunikacije z elektronskim klicem.
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 siliStraßenverkehrstelematik - eSicherheit - Minimaler Datensatz für den elektronischen NotrufTélématique de la circulation et du transport routier - ESafety - Ensemble minimal de données (MSD) pour l'eCallIntelligent transport systems - eSafety - eCall minimum set of data (MSD)43.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:2011SIST EN 15722:2011en01-september-2011SIST EN 15722:2011SLOVENSKI
STANDARDSIST-TS CEN/TS 15722:20091DGRPHãþD
SIST EN 15722:2011
EUROPEAN STANDARD NORME EUROPÉENNE EUROPÄISCHE NORM
EN 15722
June 2011 ICS 03.220.20; 35.240.60 Supersedes CEN/TS 15722:2009English Version
Intelligent transport systems - eSafety - eCall minimum set of data (MSD)
Télématique de la circulation et du transport routier - ESafety - Ensemble minimal de données (MSD) pour l'eCall
Straßenverkehrstelematik - eSicherheit - Minimaler Datensatz für den elektronischen Notruf This European Standard was approved by CEN on 11 May 2011.
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, France, Germany, Greece, Hungary, Iceland, Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom.
EUROPEAN COMMITTEE FOR STANDARDIZATION
COMITÉ EUROPÉEN DE NORMALISATION EUROPÄISCHES KOMITEE FÜR NORMUNG
Management Centre:
Avenue Marnix 17,
B-1000 Brussels © 2011 CEN All rights of exploitation in any form and by any means reserved worldwide for CEN national Members. Ref. No. EN 15722:2011: ESIST EN 15722:2011
EN 15722:2011 (E) 2 Contents Page Foreword .3Introduction .41 Scope .62 Normative reference .63 Conformance .64 Terms and definitions .65 Symbols and abbreviated terms .76 Requirements .76.1 Concepts and formats .76.1.1 MSD data concepts .76.1.2 Format definition of MSD data concepts .76.1.3 Sequence of MSD data concepts .76.1.4 Data presentation of MSD .86.2 Minimum set of data (MSD) .86.2.1 Order of bits and bytes .86.2.2 Contents of MSD .8Annex A (normative)
ASN.1 PER representation of MSD . 13Annex B (informative)
ASN.1 Data representation PER and BER explained . 21B.1 Introduction to ASN.1 and the 'Packed Encoding Rules' . 21B.2 Basic encoding rules . 22B.3 Packed encoding rules . 23Annex C (normative)
Formal XML format description for the MSD . 24Annex D (informative)
Explanation of rationale for MSD data concept elements . 29Bibliography . 32 SIST EN 15722:2011
EN 15722:2011 (E) 3 Foreword This document (EN 15722:2011) has been prepared by Technical Committee CEN/TC 278 “Road transport and traffic telematics”, 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 December 2011, and conflicting national standards shall be withdrawn at the latest by December 2011. This document supersedes CEN/TS 15722:2009. The main changes compared to the previous edition are: change of ISO 6709 reference into WGS84; minor corrections to the ASN.1 scripts; change of deliverable from Technical Specification into European Standard. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to announce this Technical Specification: 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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and the United Kingdom. SIST EN 15722:2011
EN 15722:2011 (E) 4 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 EU-27. 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
EU-27 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 (EU-15), 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 "Road Traffic and Transport Telematics" (otherwise known as "Intelligent Transport Systems" or "ITS"), 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 (TS12) services. 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. The European Committee for Standardization (CEN) draws attention to the fact that it is claimed that compliance with this European Standard may involve the use of a patent concerning eCall given in this European Standard. CEN takes no position concerning the evidence, validity and scope of this patent right. SIST EN 15722:2011
EN 15722:2011 (E) 5 The holder of this patent right has assured to CEN that he/she is willing to negotiate licenses under reasonable and non-discriminatory terms and conditions with applicants throughout the world. In this respect, the statement of the holder of this patent right is registered with CEN. Information may be obtained from: Mr. Thomas R. Rouse VP QTL Patent Counsel QUALCOMM Incorported 5775 Morehouse Drive San Diego, California 92121 Phone: +1-858-587-1121 Fax: +1-858-658-2503 Email: trouse@qualcomm.com URL: www.qualcomm.com Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights other than those identified above. CEN shall not be held responsible for identifying any or all such patent rights.
SIST EN 15722:2011
EN 15722:2011 (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 session. NOTE 1 The communications media protocols and methods for the transmission of the eCall message are not specified in this European Standard. NOTE 2 Additional data concepts may also be transferred, it is recommended any such data concepts should be registered using a data registry as defined in EN ISO 24978. 2 Normative reference The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. ISO/IEC 8825-2, Information technology — ASN.1 encoding rules: Specification of Packed Encoding Rules (PER) prEN 16062, Intelligent transport systems — eSafety — eCall high level application requirements (HLAP) prEN 16072, Intelligent transport systems — eSafety — Pan-European eCall operating requirements prEN 16102, Intelligent transport systems — eCall — Operating requirements for third party support 3 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. 4 Terms and definitions For the purposes of this document, the following terms and definitions apply. 4.1 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'
SIST EN 15722:2011
EN 15722:2011 (E) 7 5 Symbols and abbreviated terms 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
EU-27 27 countries that formed the European Union from 2007 GSM global system mobile GNSS global navigation satellite system ID identity IP Internet protocol LPG liquid propane gas M mandatory MSD minimum set of data O optional PER packed encoding rules (ASN.1) PSAP public safety answering point
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. 6.1.2 Format definition of MSD data concepts The definitions shown in this standard are shown below in semantic representation. Data presentation shall be as determined in 6.1.4. The real position of the element in the data-stream is defined by the ASN1 definition in Annex A; elements therefore do not necessarily start or end on a byte boundary. NOTE The information elements in the minimum set of data have been selected on the basis of their relevance in an emergency rescue situation. 6.1.3 Sequence of MSD data concepts The sequence of data presentation shall be as specified in 6.2, presented as defined in 6.1.4.
SIST EN 15722:2011
EN 15722:2011 (E) 8 6.1.4 Data presentation of MSD The MSD shall be transmitted using one or more wireless communications media as defined in prEN 16072 which defines one or more ETSI air interface standards suitable for the transmission of eCall and prEN 16062 (eCall high level application protocols), and shall be presented in Abstract Syntax Notation, ASN.1 Packed encoding rules (PER unaligned) as defined in ISO/IEC 8825-2 using the ASN1 definitions defined in Annex A. The MSD is also referred to in prEN 16102. NOTE 1 In order to implement presentation in ASN.1 PER, readers are advised to also read Annex B "ASN.1 Data Representation PER and BER explained "; and also the relevant normative referenced documents. NOTE 2 It is assumed that the integrity of the transmitted data is assured by the underlying communication interface standard used. 6.2 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. 6.2.1 Order of bits and bytes The message shall be sent in the sequence defined within the ASN.1 definition determined herein. 6.2.2 Contents of MSD Table 1 provides a summary of the semantic contents of the MSD. The real position and type of the elements in the data stream is defined by the formal ASN1 definition in Annex A. Table 1 — Contents/format of the MSD data concept M – Mandatory data field O – Optional data field. Block No. Name Type UnitDescription 1 ID Integer M MSD format version set to 1 to discriminate from later MSD formats. Later versions have to be backwards compatible with existing versions. Systems receiving an MSD shall support all standardised MSD versions, which are each uniquely identified using an MSD format version parameter which shall always be contained in the first byte of all (current and future) MSD versions. 2 Message Identifier Integer M Message identifier, starting with 1 for each new eCall session and has to be incremented with every application layer MSD retransmission following a new ‘Send MSD’ request after the incident event. SIST EN 15722:2011
EN 15722:2011 (E) 9 Block No. Name Type UnitDescription 3 Control Bit sequence M AutomaticActivation: true = Automatic activation false = Manual activation
TestCall type: true = Test call false = Emergency
PositionCanBeTrusted: true = Position can be trusted false = Low confidence in position Precise vehicle type encoding is defined in Annex A. 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) motorcycles (Class L6e) motorcycles (Class L7e) NOTE 1
Vehicle definitions class M, N according to directive 2007/46/EC; class L according directive 2002/24/EC. NOTE 2
The position confidence bit is to be set to “Low confidence in position” if the position is not within the limits of ± 150 m with 95 % confidence. 4 Vehicle identification String M VIN number according to ISO 3779
World Manufacturer Index (WMI) Vehicle Type Descriptor (VDS) Vehicle Identification Sequence (VIS)
SIST EN 15722:2011
EN 15722:2011 (E) 10 Block No. Name Type UnitDescription 5 Vehicle propulsion storage type Integer M These parameters identify the type of vehicle energy storage(s) present. For each storage type the following coding applies:
false
= indicates a type of storage not present true = indicates type of storage which is present
The following storage types are supported:
Gasoline tank Diesel tank Compressed natural gas (CNG) liquid propane gas (LPG) Electric energy storage (with more than 42 v and 100 Ah) Hydrogen storage
All bits shall be set to zero to indicate an unknown or other type of energy storage. NOTE 1
This information may be unreliable if there has been a change of vehicle propulsion type (e.g. from gasoline to CNG). NOTE 2
More than one bit may be set if there is more than one type of energy storage present.
6 Time stamp Integer UTC sec M Timestamp of incident event
As seconds elapsed since midnight January 1st, 1970 UTC.
Failure value for time stamp set to “0”.
7 Vehicle Location Integer milliarcsec M Position latitude (WGS84) Value range (-324000000 to 324000000)
Maximum value Latitude = 90°00'00.000''
= 90*60*60.000'' = 324000.000''
= 324 000 000 Miliarcseconds = 0x134FD900 Minimum value Latitude = -90°00'00.000''
= -90*60*60.000'' = -324000.000''
= -324 000 000 Miliarcseconds = 0xECB02700
EXAMPLE 48°18'1.20" N = 48.3003333 lat = (48*3600)+(18*60)+1.20}’’ = 173881,200’’ which encodes to the following value:
= 173881200d = 0x0A5D3770 If latitude is invalid or unknown, the value SIST EN 15722:2011
EN 15722:2011 (E) 11 Block No. Name Type UnitDescription 0x7FFFFFFF shall be transmitted.
Integer milliarcsec M Position longitude (WGS84) Value range (-648000000 to 648000000) Maximum value Longitude = 180°00'00.000''
= 180*60*60.000'' = 648000.000''
= 648 000 000 Miliarcseconds = 0x269FB200
Minimum value Longitude = -180°00'00.000''
= -180*60*60.000'' = -648000.000''
= -648 000 000 Miliarcseconds = 0xD9604E00
EXAMPLE. 11°37'2.52" E = 11.6173666 long = (11*3600)+(37*60)+2.52}’’ = 41822.520’’ which encodes to the following value:
= 41822520d = 0x027E2938
If longitude is invalid or unknown, the value 0x7FFFFFFF shall be used.
8 Vehicle direction Integer 2°-Degree M Direction of travel in 2°-degrees steps from magnetic north (0– 358, clockwise).
If direction of travel is invalid or unknown, the value 0xFF shall be used. 9 Recent Vehicle Location n-1 Integer 100 milliarcsec O Latitude Delta (+ for North and – for South) with respect to Current Vehicle location in Block 7.
1 Unit = 100 miliarcseconds (WGS84),
which is approximately 3m. Coded value range (-512.511)
representing - 51 200 to + 51 100 miliarcseconds, or from 51,2’’S to 51,1’’N from the current position.
Integer 100 milliarcsec O Longitude Delta (+ for East and – for West) with respect to Current Vehicle location in Block 7.
1 Unit = 100 miliarcseconds (WGS84)
Coded value range (-512.511)
representing - 51 200 to + 51 100 miliarcseconds, or from 51,2’’W to 51,1’’E from the current position.
SIST EN 15722:2011
EN 15722:2011 (E) 12 Block No. Name Type UnitDescription 10 Recent Vehicle Location n-2 Integer 100 milliarcsec O Latitude Delta (+ for North and – for South) with respect to Recent Vehicle Location n-1 in Block 9.
1 Unit = 100 miliarcseconds (WGS84) which is approximately 3m.
Coded value range -512.511)
representing -51200 to +51100 miliarcseconds, or from 51,2’’S to 51,1’’N from the location represented by Recent Vehicle Location n-1.
Integer 100 milliarcsec O Longitude Delta (+ for East and – for West) with respect to Recent Vehicle Location n-1 in Block 9,
Coded value range (-512.511)
representing - 51 200 to + 51 100 miliarcseconds, or from 51,2’’W to 51,1’’E from the location represented by Recent Vehicle Location n-1
11 No. of passengers Integer O Minimum known number of fastened seatbelts, may be set to 0xFF or the optional parameter omitted if no information is available.
NOTE This information is indicative only as it may be not always be reliable in providing exact information about the number of passengers (e.g. because seatbelts may not be fastened by passengers or seatbelts may be fastened for other reasons).
12 Optional additional data String As specified O Further 103 bytes of data encoded as in ASN.1 definition.
NOTE 1
ASN.1 provides already the indication of whether optional data is included by simply identifying the optional additional data field as optional.
NOTE 2
Additional Data field may include an address where other relevant related data or functions are available. NOTE 3
The framework format of this field is defined in the ASN1 definition later in this document, which includes a method to uniquely identify the exact format of the data and may also be found in a data registry that is compliant to EN ISO 24978.
NOTE Except where explicitly specified or determined in a reference standard, negative values are not allowed. SIST EN 15722:2011
EN 15722:2011 (E) 13 Annex A (normative)
ASN.1 PER representation of MSD MSDASN1Module
DEFINITIONS AUTOMATIC TAGS ::= BEGIN
-- Version of this ASN.1 MSD specification CurrentId::= INTEGER (1)
-- ECallMessage is the top level information element -- The ECallMessage structure supports only one message type (msd)
-- Extendibility at this level is not allowed, thus ensuring that the -- ID (message format version) can be extracted directly. -- Elements: --
id:
MSD format version set to 1 to discriminate from later
--
MSD formats (CurrentId can be used).
--
Later versions to be backwards compatible with existing --
versions.
--
Systems receiving an MSD shall support all standardised MSD --
versions, which are each uniquely identified using --
an MSD format version parameter which shall always be --
contained in the first byte of all[current and future]
--
MSD versions. --
msd:
Minimum Set Of Data uplink from vehicle,
--
excluding ID ECallMessage ::= SEQUENCE {
id
INTEGER(0 . 255),
msd MSDMessage
}
-- The main uplink msd message from the vehicle (excluding ID) -- Elements: --
msdStructure: The main MSD structure --
optionalAdditionalData: Additional data -- Extendable in future versions at this level e.g. to add extra data MSDMessage ::= SEQUENCE {
msdStructure
MSDStructure,
optionalAdditionalData AdditionalData OPTIONAL,
...
}
-- The main MSD structure, excluding additional data -- Elements: --
messageIdentifier: Message identifier, starting with 1 for each --
new eCall session and to be incremented with --
every application layer MSD retransmission --
following a new ‘Send MSD’ request after the --
incident event
--
control: see ControlType --
vehicleIdentificationNumber: see VIN --
vehiclePropulsionStorageType: see VehiclePropulsionStorageType SIST EN 15722:2011
EN 15722:2011 (E) 14 --
timestamp: Timestamp of incident event --
As seconds elapsed since midnight January 1st, 1970 UTC. --
Failure value for time stamp set to “0” --
vehicleLocation: see VehicleLocation --
vehicleDirection: Direction of travel
--
in 2°-degrees steps from magnetic north
--
(0– 358, clockwise) --
If direction of travel is invalid or unknown, --
the value 0xFF shall be used --
Only values from 0 to 179 are valid. --
recentVehicleLocationN1: location delta with respect to --
vehicleLocation --
see VehicleLocationDelta --
recentVehicleLocationN2: location deltat with respect to --
recentVehicleLocationN1 --
see VehicleLocationDelta --
numberOfPassengers: Minimum known number of fastened seatbelts, --
may be set to 0xFF or the optional parameter --
omitted if no information is available
--
NOTE: This information is indicative only as --
it may be not always be reliable in providing --
exact information about the number --
of passengers (e.g. because seatbelts may not --
be fastened by passengers or seatbelts may be --
fastened for other reasons) MSDStructure
::= SEQUENCE {
messageIdentifier
INTEGER(0 . 255),
control
ControlType,
vehicleIdentificationNumber
VIN,
vehiclePropulsionStorageType
VehiclePropulsionStorageType,
timestamp
INTEGER(0 . 4294967295),
vehicleLocation
VehicleLocation,
vehicleDirection
INTEGER(0 . 255),
recentVehicleLocationN1
VehicleLocationDelta OPTIONAL,
recentVehicleLocationN2
VehicleLocationDelta OPTIONAL,
numberOfPassengers
INTEGER(0 . 255) OPTIONAL,
... }
-- The ControlType is a collection of the following elements: -- Elements: --
automaticActivation:
true = Automatic activation,
--
false = Manual activation
--
testCall:
true = Test call, false = Emergency --
positionCanBeTrusted: true = Position can be trusted, --
false = low confidence in position --
NOTE: The position confidence bit is to be --
set to “Low confidence in position” --
if the position is not within the limits
--
of +-150m with 95% confidence --
vehicleType:
see VehicleType ControlType ::= SEQUENCE {
automaticActivation
BOOLEAN,
testCall
BOOLEAN,
positionCanBeTrusted BOOLEAN,
vehicleType
VehicleType }
-- Definiton of the vehicle type reporting the incident. SIST EN 15722:2011
EN 15722:2011 (E) 15 -- NOTE: Vehicle definitions class M, N according directive 2007/46/EC; --
class L according directive 2002/24/EC
-- Extendable in future versions for new vehicle types VehicleType ::= ENUMERATED{
passengerVehicleClassM1 (1),
busesAndCoachesClassM2 (2),
busesAndCoachesClassM3 (3),
lightCommercialVehiclesClassN1 (4),
heavyDutyVehiclesClassN2 (5),
heavyDutyVehiclesClassN3 (6),
motorcyclesClassL1e (7),
motorcyclesClassL2e (8),
motorcyclesClassL3e (9),
motorcyclesClassL4e (10),
motorcyclesClassL5e (11),
motorcyclesClassL6e (12),
motorcyclesClassL7e (13),
...
}
-- VIN (vehicle identification number) according ISO 3779 --
isowmi: World Manufacturer Index (WMI) --
isovds: Vehicle Type Descriptor (VDS) --
Vehicle Identifier Section (VIS) consisting of
--
isovisModelyear: Modelyear from Vehicle Identifier Section (VIS)
--
isovisSeqPlant:
Plant code + sequential number
--
from Vehicle Identifier Section (VIS)
VIN ::= SEQUENCE {
isowmi
PrintableString (SIZE(3)) (FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9")),
isovds
PrintableString (SIZE(6)) (FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9")),
isovisModelyear PrintableString (SIZE(1)) (FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9")),
isovisSeqPlant
PrintableString (SIZE(7)) (FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9"))
}
-- VehiclePropulsionStorageType: -- These parameters identify the type of
-- vehicle energy storage(s) present.
-- For each storage type the following coding applies: --
false
= indicates a type of storage not present --
true = indicates type of storage which is present -- The following storage types are supported: --
Gasoline tank --
Diesel tank --
Compressed natural gas (CNG) --
Liquid propane gas (LPG) --
Electric energy storage (with more than 42v and 100Ah) --
Hydrogen storage -- All bits shall be set to zero to indicate an unknown
-- or other type of energy storage.
-- NOTE: This information may be unreliable if there has been a
-- change of vehicle propulsion type (e.g. from gasoline to CNG) -- NOTE: More than one bit may be set
...
SLOVENSKI STANDARD
oSIST prEN 15722:2010
01-april-2010
Cestna transportna in prometna telematika - E-Safety - Minimalni nabor podatkov
za elektronski klic v sili
Road transport and traffic telematics - ESafety - ECall minimum set of data
Intelligente Transportsysteme - Elektronische Sicherheit - Minimaler Datensatz für
Notrufe (MSD)
Systèmes de transport intelligente - ESafety - ECall ensemble minimum de données
(MSD)
Ta slovenski standard je istoveten z: prEN 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
oSIST prEN 15722:2010 en
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.
---------------------- Page: 1 ----------------------
oSIST prEN 15722:2010
---------------------- Page: 2 ----------------------
oSIST prEN 15722:2010
EUROPEAN STANDARD
DRAFT
prEN 15722
NORME EUROPÉENNE
EUROPÄISCHE NORM
February 2010
ICS 03.220.20; 35.240.60 Will supersede CEN/TS 15722:2009
English Version
Road transport and traffic telematics - ESafety - ECall minimum
set of data
Systèmes de transport intelligente - ESafety - ECall Intelligente Transportsysteme - Elektronische Sicherheit -
ensemble minimum de données (MSD) Minimaler Datensatz für Notrufe (MSD)
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 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, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland 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
Management Centre: Avenue Marnix 17, B-1000 Brussels
© 2010 CEN All rights of exploitation in any form and by any means reserved Ref. No. prEN 15722:2010: E
worldwide for CEN national Members.
---------------------- Page: 3 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Contents Page
Foreword 3
Introduction 3
1 Scope 4
2 Conformance 4
3 Normative reference 4
4 Terms and definitions 5
5 Symbols and abbreviated terms 5
6 Requirements 5
6.1 Concepts and formats 5
6.1.1 MSD data concepts 5
6.1.2 Format definition of MSD data concepts 5
6.1.3 Sequence of MSD data concepts 6
6.1.4 Data presentation of MSD 6
6.2 Minimum set of data (MSD) 6
6.2.1 Order of bits and bytes 6
6.2.2 Contents of MSD 7
6.2.3 MSD acknowledgement and requests 12
Annex A (normative) ASN.1 PER representation of MSD 13
Annex B (informative) ASN.1 Data representation PER and BER explained 17
B.1 Introduction to ASN.1 and the 'Packed Encoding Rules' 17
B.2 Basic encoding rules 18
B.3 Packed encoding rules 19
Annex C (informative) Formal XML format description for the MSD 20
Bibliography 27
2
---------------------- Page: 4 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Foreword
This document (prEN 15722:2010) has been prepared by Technical Committee CEN/TC 278
“Road transport and traffic telematics”, the secretariat of which is held by NEN.
This document is currently submitted to the CEN Enquiry.
This document will supersede CEN/TS 15722:2009.
Introduction
The scale of death and injury on roads around the world needs to be fully comprehended to
understand the need for "Emergency Call" (eCall). There are around 41,600 deaths and
more than 1.7 million injured in 2005. 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 EU-25 when fully deployed, and furthermore to
reduce the severity of injuries, to bring significant savings to the society in healthcare and
other costs 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 a normal mobile phone may not be available for use, or the
car occupants may not be in a position to call.
The situation is worse for those travelling abroad: For example, in EU there are over 100
million trips to another EU country per year (EU-15) -65 % 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 prohibit proper communication.
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 "Road Traffic and Transport Telematics" (otherwise known as
"Intelligent Transport Systems" or "ITS") , 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 ". This Technical Specification defines 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.
3
---------------------- Page: 5 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
1 Scope
This European Standard defines the standard data concepts that comprise the "Minimum
Set of Data" 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 session.
NOTE 1 The communications media protocols and methods for the transmission of the eCall
message are not specified in this Standard.
NOTE 2 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.
2 Conformance
In order to claim conformance with this Technical Specification, 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
Technical Specification, to the extent that such data is available from the vehicle.
3 Normative reference
This European Standard incorporates by dated or undated reference, provisions from other
publications. These normative references are cited at the appropriate places in the text and
the publications are listed hereafter. For dated references, subsequent amendments to or
revisions of any of these publications apply to this European Standard only when
incorporated in it by amendment or revision. For undated references the latest edition of the
publication referred to applies (including amendments).
ISO 6709; Standard representation of latitude, longitude and altitude for geographic point
locations
ISO/IEC 8825-2; Information technology - ASN.1 encoding rules: Specification of Packed
Encoding Rules (PER)
1
prEN 278220 ; Intelligent transport systems - Pan European eCall - Operating
requirements
2
prEN 278244 ; Intelligent transport systems - eCall - Operating requirements for third party
support
1
Under development
2
Under development
4
---------------------- Page: 6 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
4 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
4.1
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'
5 Symbols and abbreviated terms
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
EU-27 27 countries that formed the European Union from 2007
GSM global standard mobile
GNSS global navigation satellite system
ID identity
IP Internet protocol
LPG liquid propane gas
M mandatory
MSD minimum set of data
O optional
PER packed encoding rules (ASN.1)
PSAP public safety answering point
6 Requirements
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.
6.1 Concepts and formats
6.1.1 MSD data concepts
The "Minimum Set of Data" shall be a direct, timely message to the PSAP operator
receiving the emergency call.
6.1.2 Format definition of MSD data concepts
The definitions shown in this Standard are shown below in semantic representation. Data
presentation shall be as determined in 6.1.4.
5
---------------------- Page: 7 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
The real position of the element in the data-stream is defined by the ASN1 definition in
Annex A. Elements therefore do not necessarily start or end on a byte boundary.
NOTE The information elements in the minimum set of data have been selected on the basis of
their relevance in an emergency rescue situation.
6.1.3 Sequence of MSD data concepts
The sequence of data presentation shall be as specified in 6.2, presented as defined in
6.1.4
6.1.4 Data presentation of MSD
The MSD shall be transmitted using one or more wireless communications media as
defined in prEN 278220 (under development) which defines one or more ETSI air interface
Standards suitable for the transmission of eCall, and shall be presented in Abstract Syntax
Notation, ASN.1 Packed encoding rules (PER unaligned) as defined in ISO 8825-2 using
the ASN1 definitions defined in Annex A.
The MSD is also referred to in prEN 278244 (under development).
NOTE In order to implement presentation in ASN.1 PER, readers are advised to also read Annex B
"ASN.1 Data Representation PER and BER explained "; and also [1], [2], [3], [4].
NOTE It is assumed that the integrity of the transmitted data is assured by the underlying
communication interface standard used.
6.2 Minimum set of data (MSD)
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.2.1 Order of bits and bytes
The message shall be sent in the sequence defined within these sub-Clauses
The "Minimum Set of Data" (MSD) and the acknowledgment shall be transmitted by the
network access device according to agreed European Standards. Figure 1 provides the
order of the bits and bytes in the MSD frame.
Byte Byte Byte Byte Byte Byte Byte Byte
1 2 3 4 97 98 99 100
t
Bit Bit Bit Bit Bit Bit Bit Bit
7 6 5 4 3 2 1 0
Figure 1 — Order of bits and bytes in MSD frame
6
---------------------- Page: 8 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
6.2.2 Contents of MSD
Table 1 provides a summary of the semantic contents of the MSD.
The real position and type of the elements in the data stream is defined by the formal ASN1
definition in Annex A.
Table 1 — Contents/format of the MSD data concept
M – Mandatory data field
O – Optional data field, must be included even if no information is included.
Type Unit Description
Block Name
No.
1 ID Integer M MSD format version set to 1 to
discriminate from later MSD formats
Integer M Message identifier, starting with 1 and
to be incremented with every MSD
retransmission after the incident event
2 Control Bit M activation:
sequence 1 = Automatic activation
0 = Manual activation
call type:
1 = Test call
0 = Emergency
position confidence:
1= Low confidence in position
0 = Position can be trusted
vehicle type encoding:
0001= passenger vehicle (Class
M1)
0010= buses and coaches
(Class M2)
0011= buses and coaches
(Class M3)
0100= light commercial vehicles
(Class N1)
0101= heavy duty vehicles
(Class N2)
0110= heavy duty vehicles
(Class N3)
0111= motorcycles (Class L1e)
1000= motorcycles (Class L2e)
1001= motorcycles (Class L3e)
1010= motorcycles (Class L4e)
1011= motorcycles (Class L5e)
1100= motorcycles (Class L6e)
1101= motorcycles (Class L7e)
NOTE: Vehicle definitions class M, N
according directive 2007/46/EC; class L
according directive 2002/24/EC
NOTE: The position confidence bit is to be
set to “Low confidence in position” if the
7
---------------------- Page: 9 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Type Unit Description
Block Name
No.
position is not within the limits of +-150m
with 95% confidence
3 Vehicle String M VIN number according ISO 3779
identifica
tion
World Manufacturer Index (WMI)
Vehicle Type Descriptor (VDS)
Vehicle Identification Sequence (VIS)
4 Vehicle Integer M These parameters identify the type of
propulsio vehicle energy storage(s) present:
n
storage 0 = indicates a type of storage not
type present
1 = indicates type of storage which is
present
All bits set to zero indicates an
unknown type of energy storage
hydrogen storage present
electric energy storage present
(with more than 42v and 100Ah
liquid propane gas (LPG) present
compressed natural gas (CNG)
present
diesel tank present
gasoline tank present
NOTE: This information may be unreliable
if there has been a change of vehicle
propulsion type (e.g. from gasoline to
CNG)
NOTE: More than one bit may be set if
there is more than one type of energy
storage present
5 Time Integer UTC sec M Timestamp of incident event
stamp
As seconds elapsed since
st
midnight January 1 , 1970 UTC.
6 Vehicle Integer milliarcsec M Position latitude (ISO 6709)
Location
Value range (-324000000 to
324000000)
Maximum value Latitude =
90°00'00.000''
= 90*60*60.000'' = 324000.000''
= 324 000 000 Miliarcseconds
= 0x134FD900
Minimum value Latitude = -
90°00'00.000''
= -90*60*60.000'' = -324000.000''
= -324 000 000 Miliarcseconds
= 0xECB02700
8
---------------------- Page: 10 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Type Unit Description
Block Name
No.
EXAMPLE 48°18'1.20" N = 48.3003333
lat
= (48*3600)+(18*60)+1.20}’’ =
173881,200’’
which encodes to the following value:
= 173881200d = 0x0A5D3770
If latitude is invalid or unknown, the
value 0xFFFFFFFF shall be
transmitted
Integer milliarcsec M Position longitude (ISO 6709)
Value range (-648000000 to
648000000)
Maximum value Longitude =
180°00'00.000''
= 180*60*60.000'' = 648000.000''
= 648 000 000 Miliarcseconds
= 0x269FB200
Minimum value Longitude = -
180°00'00.000''
= -180*60*60.000'' = -
648000.000''
= -648 000 000 Miliarcseconds
= 0xD9604E00
EXAMPLE. 11°37'2.52" E =
11.6173666 long
= (11*3600)+(37*60)+2.52}’’ =
41822.520’’
which encodes to the following
value:
= 41822520d = 0x027E2938
If longitude is invalid or unknown,
the value 0xFFFFFFFF shall be
used
Vehicle Integer 2°-Degree M Direction of travel in 2°-degrees
direction steps from magnetic north (0–
358, clockwise)
7 Recent Integer 100 O Latitude Delta (+ for North and –
Vehicle milliarcsec for South) with respect to Current
Location Vehicle position in Block 6.
n-1
1 Unit = 100 miliarcseconds,
which is approximately 3m
Coded value range -512.511)
representing -51200 to +51100
miliarcseconds, or from 51,2’’S
to 51,1’’N from the current
position
Integer 100 O Longitude Delta (+ for East and –
for West) with respect to Current
9
---------------------- Page: 11 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Type Unit Description
Block Name
No.
milliarcsec Vehicle position in Block 6.
Coded value range -512.511)
representing -51200 to +51100
miliarcseconds, or from 51,2’’W
to 51,1’’E from the current
position
8 Recent Integer 100 O Latitude Delta (+ for North and –
Vehicle milliarcsec for South) with respect to Recent
Location Vehicle Location n-1 in Block 7
n-2
1 Unit = 100 miliarcseconds
which is approximately 3m
Coded value range -512.511)
representing -51200 to +51100
miliarcseconds, or from 51,2’’S
to 51,1’’N from the location
represented by Recent Vehicle
Location n-1
Integer 100 O Longitude Delta (+ for East and –
milliarcsec for West) with respect to Recent
Vehicle Location n-1in Block 7,
Coded value range -512.511)
representing -51200 to +51100
miliarcseconds, or from 51,2’’W
to 51,1’’E from the location
represented by Recent Vehicle
Location n-1
9 No. of Integer O Minimum known number of
passeng fastened seatbelts, to be set to
ers 255 if no information is available
NOTE This information is only
relevant for automatic initiated
eCalls and is indicative only as it
may be not always be reliable in
providing exact information about
the number of passengers (e.g.
because seatbelts may not be
fastened by passengers or seatbelts
may be fastened for other reasons)
10 Service String IPv6 O Service provider IPv6 address in
provider standard text representation, i.e.
using up to eight groups of up to
four characters “0-9”, or “a-f” to
represent hexadecimal digits
with each group separated by a
colon (:) character.
If one or more four-digit group(s)
is 0000, the zeros may be
10
---------------------- Page: 12 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Type Unit Description
Block Name
No.
omitted and replaced with two
colons(::).
Following this rule, any number
of consecutive 0000 groups may
be reduced to two colons, as
long as there is only one double
colon used in an address.
It is this (::) notation which allows
typical addresses to be sent with
much fewer bytes in the MSD.
For example,
“2001:0db8:85a3:08d3:1319:8a2e:0
370:7334“ or
“2001:0db8:0000:0000:0000:0000:1
428:57ab” or
“2001:0db8::1428:57ab” [equivalent
to previous] or
“::ffff:c000:280”
11 Format Integer M Format of the following optional
field additional data:
0 = No optional additional data*
1 = Binary data
2 = BCD
3 = XML encoded data
4 = ASN.1 BER defined data
5 = ASN.1 PER defined data
6 = ASCII encoded data
7 = (unallocated)
* If the value for field 11 is 0 (no
additional data) then the
message may be truncated
(block 12 should not be present)
12 Optional String As specified O Further 32 bytes of data encoded
additiona according to format field 11 to be
l data used by service providers.
Unused bytes shall be filled with
blank characters (zeros).
NOTE The format of such
optional data concepts may be
provided in a subsequent version of
this Technical Specification or may
be found in a data registry that is
compliant to CEN ISO/TS 24978.
NOTE Except where explicitly specified or determined in a reference standard, negative values
are not allowed
11
---------------------- Page: 13 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
6.2.3 MSD acknowledgement and requests
Table 2 provides the possible responses and requests which can be sent by a PSAP
The data format for these responses and requests is not defined by this standard, but it is
required that each of them is individually supported by the communication interface
Standard used for the transmission of eCall, and can therefore unambiguously be
transmitted from a PSAP to the application responsible for MSD transmission.
Table 2 — MSD-Acknowledgement and requests
M – Mandatory data field
Name Description
positive M Positive application layer acknowledgement
acknowledgement (AL-ACK) that an MSD has been received at
the PSAP and that the format of the received
data was consistent with this standard.
SEND MSD M The application responsible for sending the
MSD is requested to send (or resend) an MSD
to the PSAP
cleardown M The eCall application is informed that the eCall
session is completed and that it should clear
down the call.
Note: It is assumed that each of the above is supported in the link layer in the normatively
referenced ETSI standards.
12
---------------------- Page: 14 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Annex A
(normative)
ASN.1 PER representation of MSD
MSDASN1Module
DEFINITIONS
AUTOMATIC TAGS ::=
BEGIN
ECallMessage ::=CHOICE {
msd MSDMessage, -- Minimum Set Of Data uplink from vehicle
...
-- By using ASN.1 definitions as above, a frame and delimiter are not
required.
-- The ECallMessage structure above supports only one message type
(msd) but allows extendibility
-- Thus further message types might be added later in future versions
}
-- The "uplink" msd message from the vehicle follows, using elements
defined below
MSDMessage ::= SEQUENCE {
msdStructure MSDStructure,
optionalAdditionalData UTF8String (SIZE(1.32)) OPTIONAL,
... -- Extendible in future versions here e.g. to add extra
optional data
}
-- The main MSD structure follows, using elements described below
MSDStructure ::= SEQUENCE {
formatVersion INTEGER(0 . 255),
messageIdentifier INTEGER(0 . 255),
control ControlType,
vehicleIdentificationNumber VIN,
vehiclePropulsionStorageType VehiclePropulsionStorageType,
timestamp INTEGER(0 . 4294967295),
--Number of seconds since 1970:00:00:00
vehicleLocation VehicleLocation,
vehicleDirection INTEGER(0 . 255),
-- Clockwise heading in 2 degree units
-- Coded values of 0.179
-- represent headings from 0.358 deg
-- Value 255 represents "unknown"
-- other values are invalid
recentVehicleLocationN1 VehicleLocationDelta OPTIONAL,
recentVehicleLocationN2 VehicleLocationDelta OPTIONAL,
numberOfPassengers INTEGER(0 . 255) OPTIONAL,
serviceProvider AddressIPV6 OPTIONAL,
additionalDataFormatField INTEGER(0 . 255),
13
---------------------- Page: 15 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
. -- Extendible in future versions here e.g. to add new data
elements to MSD
}
-- The following basic elements are used in the main MSD structure
MSDStructure
ControlType ::= SEQUENCE {
activation BOOLEAN, -- manualActivation (0) /
automaticActivation (1),
callType BOOLEAN, -- emergency (0)/ testCall (1),
positionconfidence BOOLEAN, -- positionCanBeTrusted (0) /
lowConfidenceInPosition (1),
vehicleType VehicleType
}
VehicleType ::= ENUMERATED{
passengerVehicleClassM1 (1),
busesAndCoachesClassM2 (2),
busesAndCoachesClassM3 (3),
lightCommercialVehiclesClassN1 (4),
heavyDutyVehiclesClassN2 (5),
heavyDutyVehiclesClassN3 (6),
motorcyclesClassL1e (7),
motorcyclesClassL2e (8),
motorcyclesClassL3e (9),
motorcyclesClassL4e (10),
motorcyclesClassL5e (11),
motorcyclesClassL6e (12),
motorcyclesClassL7e (13),
. -- Extendible in future versions here for new vehicle types
}
--NOTE: Vehicle definitions class M, N according directive 2007/46/EC;
--class L according directive 2002/24/EC
VIN ::= SEQUENCE {
isowmi PrintableString (SIZE(3))
(FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9")),
-- World Manufacturer Index
isovds PrintableString (SIZE(6))
(FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9")),
-- Vehicle Descriptor Section
isovisModelyear PrintableString (SIZE(1))
(FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9")),
-- Modelyear in Vehicle Identifier Section
isovisSeqPlant PrintableString (SIZE(7))
(FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9"))
-- plant code + sequential number in Vehicle Identifier Section
}
VehiclePropulsionStorageType ::= SEQUENCE {
gasolineTankPresent BOOLEAN DEFAULT FALSE,
dieselTankPresent BOOLEAN DEFAULT FALSE,
compressedNaturalGas BOOLEAN DEFAULT FALSE,
liquidPropaneGas BOOLEAN DEFAULT FALSE,
electricEnergyStorage BOOLEAN DEFAULT FALSE, --with more than 42v and
100Ah
hydrogenStorage BOOLEAN DEFAULT FALSE,
. -- Extendible in future versions here for new fuel storage types
14
---------------------- Page: 16 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
-- Instead of defining "not used"
-- Extendability Marker, for new version put a "," behind the "."
and add new elements
-- Example: hydrogenStorage BOOLEAN DEFAULT FALSE,
-- .,
-- xyzStorage BOOLEAN DEFAULT FALSE (here no "," if end of
list)
}
VehicleLocation ::= SEQUENCE {
positionLatitude INTEGER(-2147483648.2147483647),
-- 32 bits (4 octets) allocated to make signed value handling easier
-- Real latitude values in 1mas units
-- from -324000000 to 324000000
-- representing -90° to +90°
-- 0xFFFFFFF means value not available
positionLongitude INTEGER(-2147483648.2147483647)
-- 32 bits (4 octets) allocated to make signed value handling easier
-- Real longitude values in 1mas units
-- from -648000000 to 648000000
-- representing -180° to +180°
-- 0xFFFFFFF means value not available
}
VehicleLocationDelta ::= SEQUENCE {
latitudeDelta INTEGER (-512.511),
-- 100 miliarcsecond resolution
-- allows range 51.2''S to 51.1''N
longitudeDelta INTEGER (-512.511)
-- 100 miliarcsecond resolution
-- allows range 51.2''W to +51.1''E
}
AddressIPV6 ::= PrintableString (SIZE(0.39))
(FROM("a"."f"|":"|"0"."9"))
END
15
---------------------- Page: 17 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
-- An examples for the MSD structure follows
-- This examples does NOT form part of the formal ASN1 definition
msdexample MSDMessage ::= {
msdStructure {
formatVersion 1,
messageIdentifier 1,
control {
activation automaticActivation, --01110000=70
callType emergency,
positionconfidence positionCanBeTrusted,
vehicleType passengerVehicleClassM1
},
vehicleIdentificationNumber "WMIVDSVDSYA123456",
vehiclePropulsionStorageType {gasolineTankPresent TRUE}, --
10000000=80
timestamp 123456789,
vehicleLocation {positionLatitude 173881200, positionLongitude
41822520},
vehicleDirection 14,
recentVehicleLocationN1 {latitudeDelta 10, longitudeDelta -10},
recentVehicleLocationN2 {latitudeDelta 10, longitudeDelta -10},
numberOfPassengers 2,
serviceProvider “::ffff:c000:280”,
additionalDataFormatField 0,
},
}
END
16
---------------------- Page: 18 ----------------------
oSIST prEN 15722:2010
prEN 15722:2010 (E)
Annex B
(informative)
ASN.1 Data representation PER and BER explained
B.1 Introduction to ASN.1 and the 'Packed Encoding Rules'
Source ;Public information from http://www.w3.org/Protocols/HTTP-NG/asn1.html
Prepared by Simon E Spero (ses@tipper.oit.unc.edu)
(Quick overview of ASN.1, BER, and PER adapted by Dave Raggett from an email message by
Simon. S)
ASN.1 is a notation for describing data structures; it's very much like a type declaration in C or
C++. Let's start with a C++ structure and create the appropriate ASN.1 Data structure. I'll use a
simplified form of the the GET request from FHTTP to start with.
struct GetRequest {
int headerOnly; // flag: do we only want headers?
int lock; // flag: should we checkout the object?
string url; // the url to fetch
AcceptTypes* acceptTypes; // Optional list of accept types that only
apply
// to this request
};
struct AcceptTypes {
List* standardTypes; // list of bitmaps indicating which
// preference order for standard types
List* otherTypes; // nonstandard types in preference order
};
GetRequest ::= [APPLICATION 0
...
Questions, Comments and Discussion
Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.