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

Status
Withdrawn
Public Enquiry End Date
30-Oct-2014
Publication Date
02-Jul-2015
Withdrawal Date
08-Sep-2020
Technical Committee
ITC - Information technology
Current Stage
9900 - Withdrawal (Adopted Project)
Start Date
09-Sep-2020
Due Date
02-Oct-2020
Completion Date
09-Sep-2020

Relations

Effective Date
29-Apr-2015
Effective Date
01-Nov-2020

Frequently Asked Questions

SIST EN 15722:2015 is a standard published by the Slovenian Institute for Standardization (SIST). Its full title is "Intelligent transport systems - ESafety - ECall minimum set of data". This standard covers: 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.

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.

SIST EN 15722:2015 is classified under the following ICS (International Classification for Standards) categories: 13.200 - Accident and disaster control; 35.240.60 - IT applications in transport; 43.040.15 - Car informatics. On board computer systems. The ICS classification helps identify the subject area and facilitates finding related standards.

SIST EN 15722:2015 has the following relationships with other standards: It is inter standard links to SIST EN 15722:2011, SIST EN 15722:2020. Understanding these relationships helps ensure you are using the most current and applicable version of the standard.

SIST EN 15722:2015 is associated with the following European legislation: EU Directives/Regulations: 2010/40/EU. When a standard is cited in the Official Journal of the European Union, products manufactured in conformity with it benefit from a presumption of conformity with the essential requirements of the corresponding EU directive or regulation.

You can purchase SIST EN 15722:2015 directly from iTeh Standards. The document is available in PDF format and is delivered instantly after payment. Add the standard to your cart and complete the secure checkout process. iTeh Standards is an authorized distributor of SIST standards.

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

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

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

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
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 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

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

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

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

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
electricEnergyStorage BOOLEAN
hydrogenStorage BOOLEAN
otherPropulsionStorage BOOELAN
timeStamp INTEGER (0.232-1) sec M Timestamp of the initial data message generation within the current eCall incident event. NOTE 1 The timestamp is represented in seconds elapsed since midnight January 1st, 1970 UTC. NOTE 2 The initial message generation immediately follows the eCall generation sequence subsequent to a (confirmed) trigger. NOTE 3 Subsequent transmissions within the given incident use the same timestamp, but the messageIdentifier changes. NOTE 4 Failure value for time stamp set to “0”
1.The field is named vehicleIdentificationNumber in the ASN.1 definition. The ASN.1 type VIN is defined in Annex A and codes for a correct representation of the World Manufacturer Index (WMI), the Vehicle Type Descriptor (VDS) and the Vehicle Identification Sequence (VIS) that make up a VIN number, taking into account the preconditions of each part.
positionLatitude INTEGER (-231.231-1) milliarcsec
Position latitude (WGS84) calculation example: 48.3003333 = 48°18'1.20" N = 48*60*60.000” + 18*60.000” + 1.20” = 173881.200” = 173881200 milliarcsec maximum value: 90°00'00.000” = 324000000 minimum value: -90°00'00.000” = -324000000
If latitude is invalid or unknown, the representation of value 2147483647 shall be transmitted.
If both latitude and longitude have value 0 then the location shall also be interpreted as invalid/unknown. If the transmitter determines either latitude or longitude to be invalid/unknown, then it is recommended to transmit both longitude and latitude as unknown.
If the receiver determines either latitude or longitude to be invalid/unknown, then it is recommended to interpret both longitude and latitude as invalid/unknown positionLongitude INTEGER (-231.231-1) milliarcsec Position longitude (WGS84) maximum value: 180°00'00.000'' = 648 000 000 minimum value: -180°00'00.000'' = -648 000 000 See latitude for calculation example and notes. vehicleDirection INTEGER (0.255) 2° (2 degree) M The vehicle’s last known real direction of travel (expressed in 2°-degrees steps from magnetic north (0– 358, clockwise) determined at the latest moment possible before message generation. calculation example: due North
= 0°
= 0 * 2°
due East
= 90°
= 45 * 2° => 45 due South
= 180°
= 90 * 2°
= 270°
= 135 * 2°
The direction shall be unaffected by random fluctuations of GNSS signals.
If direction of travel is invalid or unknown, the representation of value 255 shall be transmitted recentVehicleLocationN1 O Known location of the vehicle some time before the generation of the data for the MSD message.
The recent location shall be chosen such that they could normally assist the receiving party to confirm the current location of the vehicle in different driving environments such as city or motorway.
latitudeDelta INTEGER (-512.511) 100 milliarcsec
Latitude Delta (+ for North and – for South; WGS84) with respect to vehicleLocation. 1 Unit = 100 miliarcseconds,
which is approximately 3m (on Earth) maximum value: 511 = 0°0'51.100'' (±1580m) minimum value: -512 = -0°0'51.200'' (± -1583m)
longitudeDelta INTEGER (-512.511) 100 milliarcsec Longitude Delta (+ for East and – for West; WGS84) with respect to vehicleLocation. See latitudeDelta for details recentVehicleLocationN2 O Known location of the vehicle some time before recentVehicleLocationN1.
The recent location shall be chosen such that they could normally assist the receiving party to confirm the current location of the vehicle in different driving environments such as city or motorway.
latitudeDelta INTEGER (-512.511) 100 milliarcsec
Latitude Delta (+ for North and – for South) with respect to recentVehicleLocationN1. See recentVehicleLocationN1. latitudeDelta for details longitudeDelta INTEGER 100 Longitude Delta (+ for East and – for SIST EN 15722:2015

O Number of occupants in the vehicle according to available information.
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).
If no information about the number of occupants is available, this parameter needs to be omitted or filled with the representation of value 255 optionalAdditionalData O
oid RELATIVE-OID
See 6.1.5 data OCTET STRING
See 6.1.5 6.3.3 Previous versions of MSD message 6.3.3.1 General Previous versions of the MSD message shall be supported by PSAPs to ensure proper handling of legacy systems. Such versions shall be described below with a table described and defined in the same way as Table 1. 6.3.3.2 MSD message version 1 MSD message version 1 has been withdrawn due to an erroneous ASN.1 data representation which might cause disruption in the handling of eCalls by PSAP systems. As a result this version shall not be supported by PSAPs and shall not be used by an IVS as of publication of this standard. 6.3.4 Future versions of MSD message Future versions of the MSD message shall be described below with a table described and defined in the same way as Table 1. SIST EN 15722:2015

ASN.1 definition of MSD A.1 ASN.1 definition of MSD This module definition is appropriate for transmission of MSD via Pan-European eCall (EN 16072/EN 16062) and may be used for transmission of MSD via EN 16102(Operating requirements for third party support).
MSD_ASN1_V2
-- Definition of the eCall related MSD message in ASN.1 -- Any MSD message will encoded using this scheme, following the -- UPER encoding rules. -- -- The MSD message is defined in CEN standard EN 15722.
-- Comments in this definition are taken from that standard. In -- case of inconsistency in the comment, the text of EN 15722 -- prevails.
DEFINITIONS
AUTOMATIC TAGS ::=
BEGIN
-- Version of this ASN.1 MSD specification
-- (inclusion of this element allows software developers to
-- automatically read out the current version number from the ASN.1
-- compilation for automatic inclusion into the msdVersion parameter
-- of the MSD message, i.e. can reduce the chance of using an ASN.1
-- description of one version but saying it is another) CurrentVersion::= INTEGER (2)
-- 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
-- msdVersion (message format version) can be extracted directly.
-- Elements:
--
msdVersion:
MSD format version --
The format described in this document carries version 1 --
msd:
Minimum Set Of Data uplink from vehicle -- -- The OCTET STRING (CONTAINING .) construct is used to ensure that any -- implementation can extract the msdVersion value from any version,
-- without decoding errors. ECallMessage ::= SEQUENCE {
msdVersion
INTEGER(0 . 255),
msd OCTET STRING (CONTAINING MSDMessage) }
-- The main uplink msd message from the vehicle (excluding msdVersion)
-- Elements:
--
msdStructure: The main MSD structure
--
optionalAdditionalData: Additional 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 transaction 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
--
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 255 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: Number of occupants in the vehicle according
--
to available information.
--
NOTE 1 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). --
NOTE 2 If no information about the number of
--
occupants is available, this parameter needs
--
to be omitted or filled with the representation
--
of value 255 -- 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 “Low confidence in position”
--
shall mean that there is less than 95%
--
confidence that exact position is
--
within the limits of a radius of ±150m --
of reported position --
vehicleType:
see VehicleType
-- ControlType ::= SEQUENCE {
automaticActivation
BOOLEAN,
testCall
BOOLEAN,
positionCanBeTrusted BOOLEAN,
vehicleType
VehicleType
}
-- Definiton of the vehicle type reporting the incident.
-- 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")), SIST EN 15722:2015

isovisSeqPlant
PrintableString (SIZE(7)) (FROM("A"."H"|"J"."N"|"P"|"R"."Z"|"0"."9"))
}
-- VehiclePropulsionStorageType is a collection of elements -- that contain information about the presence of propulsion -- storage inside the vehicle sending the MSD.
-- -- 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
--
other storage -- If the type of energy storage is unknown, then all elements -- shall be set to false. -- Extendible in future versions for new fuel storage types
VehiclePropulsionStorageType ::= SEQUENCE {
gasolineTankPresent
BOOLEAN DEFAULT FALSE,
dieselTankPresent
BOOLEAN DEFAULT FALSE,
compressedNaturalGas
BOOLEAN DEFAULT FALSE,
liquidPropaneGas
BOOLEAN DEFAULT FALSE,
electricEnergyStorage BOOLEAN DEFAULT FALSE,
hydrogenStorage
BOOLEAN DEFAULT FALSE,
otherStorage
BOOLEAN DEFAULT FALSE,
...
}
-- VehicleLocation:
-- The current location of the vehicle
-- Elements: --
Position latitude (WGS84) in milliarcsec --
32 bits (4 octets) allocated to make signed value handling easier
--
Real latitude values in 1 milli-arc-second units
--
Valid value range (-324000000 to 324000000)
--
calculation example: --
48.3003333 = 48°18'1.20" N
--
= 48*60*60.000” + 18*60.000” + 1.20”
--
= 173881.200”
--
= 173881200 milliarcsec -- --
maximum value: --
90°00'00.000"
= 324000000 --
minimum value: --
-90°00'00.000" = -324000000 -- --
NOTE 1: if latitude is invalid or unknown,
--
the representation of value 2147483647 shall
--
be transmitted. --
NOTE 2: if both latitude and longitude have
--
value 0 then the location shall also be
--
interpreted as invalid/unknown. --
NOTE 3: if the transmitter determines either
--
latitude or longitude to be invalid/unknown,
then it is recommended to transmit both
--
longitude and latitude as unknown. --
NOTE 4: if the receiver determines either
--
latitude or longitude to be invalid/unknown,
--
then it is recommended to interpret both
--
longitude and latitude as invalid/unknown
--
Position longitude (WGS84)
--
32 bits (4 octets) allocated to make signed value handling easier
--
Real longitude values in 1 milli-arc-second units
--
Valid value range (-648000000 to 648000000) -- --
see 'Position latitude'
-- VehicleLocation
::= SEQUENCE {
positionLatitude
INTEGER(-2147483648.2147483647),
positionLongitude INTEGER(-2147483648.2147483647)
}
-- VehicleLocationDelta:
-- Description of (the delta of) a recent vehicle locatation
-- before the incident
--
Latitude Delta (+ for North and – for South)
--
with respect to vehicleLocation. --
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 reference position
--
Longitude Delta (+ for East and – for West)
--
with respect to vehicleLocation. --
1 Unit = 100 miliarcseconds, which is approximately 3m
--
Coded value range (-512.511)
--
representing -51200 to +51100 miliarcsecon
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...

SIST EN 15722:2015 표준은 지능형 교통 시스템(ITS)와 관련하여, eCall 통신 거래를 통해 차량에서 공공 안전 응답 지점(PSAP)으로 전송될 "최소 데이터 집합"(MSD)에 포함될 표준 데이터 개념을 정의합니다. 이는 차량 사고 또는 비상사태 발생 시 필수적인 데이터 전송을 위한 기준을 마련하며, 안전성과 신속한 응답을 보장하는 데 기여합니다. 이 표준의 범위는 긴급 상황에서의 즉각적인 반응을 위한 최소 데이터 세트를 명확히 규정하고 있지만, 선택적으로 추가 데이터 개념도 전송할 수 있도록 하고 있어 유연성을 제공합니다. 이는 다양한 상황에 대응할 수 있는 가능성을 열어주며, eCall 시스템의 효율성을 극대화하는 데 도움을 줍니다. SIST EN 15722:2015의 강점은 특히 공공 안전을 증진시키기 위한 명확한 지침과 데이터 요구사항을 제공한다는 점입니다. 이를 통해 구조 요청 시 필요한 정보가 신속하게 PSAP에 전송되어, 사고 대응 시간을 단축시키고 생명을 구하는 데 결정적인 역할을 할 수 있습니다. 또한, 이 표준은 eCall 시스템의 호환성을 보장하여 유럽 전역에서 통일된 데이터 전송이 이루어질 수 있도록 합니다. 현재의 교통 시스템에서 eCall은 더욱 중요한 역할을 할 것으로 예상되며, SIST EN 15722:2015 표준은 이러한 변화를 효과적으로 관리하는 데 매우 적합한 기준으로 기능하고 있습니다. 이 표준의 적용은 모든 관련 이해관계자에게 데이터의 표준화 및 효율성을 보장함으로써, 사고 발생 시 필수적인 승객 안전을 향상시키는 데 기여합니다.

Der Standard SIST EN 15722:2015 befasst sich mit den intelligenten Verkehrssystemen und insbesondere mit dem eSafety-Mechanismus, der als lebensrettende Maßnahme bei Verkehrsunfällen dient. Dieser Standard legt die grundlegenden Datenkonzepte fest, die als "Minimum Set of Data" (MSD) von einem Fahrzeug an einen 'Public Safety Answering Point' (PSAP) übertragen werden müssen, wenn ein eCall aktiviert wird. Der in diesem Dokument festgelegte Rahmen ist von zentraler Bedeutung, da er die strukturellen Vorgaben für die Datensammlung und -übertragung im Notfall definiert. Dies gewährleistet eine schnelle und effiziente Kommunikation zwischen dem Fahrzeug und den Notdiensten, was im Ernstfall entscheidend für die Rettung von Leben sein kann. Die Kraft der standardisierten Datenübertragung sorgt dafür, dass die Informationen einheitlich sind und von den PSAPs einfach interpretiert werden können, unabhängig von deren Standort oder den verwendeten Technologien. Ein weiterer bemerkenswerter Aspekt des Standards ist die Möglichkeit, optionale zusätzliche Datenkonzepte zu übertragen. Diese Erweiterbarkeit ermöglicht eine flexible Anpassung an die sich kontinuierlich ändernden Anforderungen im Unfallmanagement und in der Notfallkommunikation. So können zum Beispiel spezielle Daten zur Fahrzeugidentität oder zum Zustand der Insassen hinzugefügt werden, was die Reaktionszeit der Rettungsdienste weiter optimieren kann. Obwohl dieses Dokument keine spezifischen Kommunikationsprotokolle und -methoden für den Versand der eCall-Nachricht festlegt, bleibt es dennoch äußerst relevant. Die Offenheit für verschiedene technische Lösungen sorgt dafür, dass der Standard zukunftssicher ist, da er leicht an die neuesten technologischen Entwicklungen angepasst werden kann, ohne die Grundprinzipien der Datensicherung und -integrität zu gefährden. Insgesamt bietet der Standard SIST EN 15722:2015 eine solide Grundlage für die Implementierung von eCall-Systemen binnen der EU, was nicht nur die Verkehrssicherheit erhöht, sondern auch das Vertrauen in intelligente Verkehrsansätze stärkt. Die klare Definition des Minimum Set of Data und die Möglichkeit zur Übertragung zusätzlicher Informationen stellen sicher, dass in kritischen Situationen schnell und effizient gehandelt werden kann.

SIST EN 15722:2015は、インテリジェント交通システムにおけるESafetyの一環として、事故や緊急時に車両から「公衆安全応答点」(PSAP)に転送される「最小データセット」(MSD)を詳細に規定した欧州規格です。この標準は、自動車の安全性向上に寄与するため、重要な役割を果たします。 この標準の範囲は明確であり、必要最小限の情報を確実に提供するために設計されています。データ概念が標準化されているため、異なる車両メーカーやモデル間で、一貫した情報伝達が可能になります。これにより、事故現場での迅速な対応が促進されるため、非常に重要です。 SIST EN 15722:2015の強みは、その柔軟性にもあります。基本的な情報の他にも、オプションの追加データ概念を転送することができるため、個々の状況に応じてデータのカスタマイズが可能です。この点は、さまざまな緊急対応シナリオに対応するうえで非常に有用です。 さらに、この標準は、eCallメッセージの通信メディアプロトコルや伝送方法に関する具体的な規定は含まれていないため、技術の進化に応じて柔軟に適応できる余地を持っています。これにより、業界の変化に対応しつつ、効果的なデータ通信が実現できる点でも評価されます。 SIST EN 15722:2015は、道路交通の安全性向上において極めて重要な役割を果たす標準であり、eCallシステムの効果的な運用を支援するデータ概念の整備に寄与しています。そのため、事故発生時における迅速かつ正確な情報提供が可能となり、結果として人命を守ることにつながります。この標準の導入は、交通の安全性向上と効率的な緊急対応に貢献するものです。

La norme SIST EN 15722:2015 est une référence essentielle dans le domaine des systèmes de transport intelligents, en particulier pour l'eSafety. Elle définit un ensemble de données minimum (Minimum Set of Data - MSD) qui est critique pour la communication entre un véhicule impliqué dans un accident et un point d'appel de sécurité publique (Public Safety Answering Point - PSAP). L'une des forces majeures de cette norme réside dans sa capacité à standardiser les concepts de données qui doivent être transmis lors d'une situation d'urgence. En garantissant une communication efficace et rapide, cette norme contribue à améliorer la sécurité routière et à accéléra la réponse des services d'urgence. La standardisation de ces données minimales assure également l'uniformité des informations reçues par les PSAP, ce qui facilite le traitement des appels d'urgence. Un autre point fort de la norme est sa flexibilité. Bien que le MSD soit clairement défini, la norme permet également le transfert de concepts de données supplémentaires en option, ce qui peut enrichir les informations fournies et ainsi optimiser les interventions d'urgence. Cette approche modulable garantit que la norme reste pertinente face à l'évolution technologique et aux besoins en matière de sécurité. Cependant, il est important de noter que, bien que la norme SIST EN 15722:2015 se concentre sur le contenu des données, elle ne détaille pas les protocoles de communication ou les méthodes de transmission de l'eCall. Cela peut représenter un défi pour les développeurs et les intégrateurs de systèmes, qui doivent s'assurer que leurs solutions respectent non seulement les contenus standardisés mais aussi les exigences de communication efficaces. En somme, la norme SIST EN 15722:2015 est une pièce maîtresse dans la mise en œuvre d'eCall, car elle garantit que les informations essentielles sont transmises de manière standardisée et efficace, tout en laissant la possibilité d'ajouter des données selon les besoins spécifiques des situations d'urgence. Son rôle dans la sécurité routière et l'amélioration de la réponse aux accidents est indéniable, faisant de cette norme un outil d'une grande pertinence dans le paysage des systèmes de transport intelligents contemporains.

The SIST EN 15722:2015 standard provides a comprehensive framework concerning the intelligent transport systems with a specific focus on eSafety through the establishment of a "Minimum Set of Data" (MSD) that must be transmitted during an eCall communication event. The scope of this standard is crucial, as it delineates the essential data concepts that must be communicated from a vehicle to a Public Safety Answering Point (PSAP), particularly in the context of crash or emergency situations. One of the notable strengths of the SIST EN 15722:2015 standard lies in its clear definitions and requirements for the MSD. By standardizing the data transferred during an eCall, the document ensures that emergency services receive timely and relevant information, which can significantly enhance response times and improve outcomes for individuals involved in incidents. The inclusion of optional additional data concepts further adds to the flexibility of the standard, allowing for additional layers of information that may be beneficial in specific emergency scenarios. The relevance of this standard cannot be overstated within the realm of intelligent transport systems and vehicle safety. As eCall technology becomes increasingly prevalent across Europe, compliance with SIST EN 15722:2015 is essential for manufacturers and service providers aiming to improve road safety and enhance the efficiency of emergency response services. The standard not only contributes to the protection of lives but also aligns with broader EU objectives to create a safer transport environment. However, it is important to note that while this standard articulates the data concepts for eCall communications, it does not specify the protocols or methods of transmission for the eCall message. This aspect highlights a potential area for further development, as the effectiveness of the MSD's implementation is ultimately dependent on the robustness of the underlying communication infrastructure. In summary, the SIST EN 15722:2015 standard plays a pivotal role in facilitating effective communication during emergencies through the standardization of critical data. Its strengths, particularly in defining minimum requirements while allowing for additional data and its critical relevance to enhancing public safety, mark it as a significant document within the framework of intelligent transport systems and eCall technologies.