EN 15722:2015

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