1、raising standards worldwideNO COPYING WITHOUT BSI PERMISSION EXCEPT AS PERMITTED BY COPYRIGHT LAWBSI Standards PublicationBS EN 16102:2011Intelligent transport systems eCall Operating requirements for third party supportBS EN 16102:2011 BRITISH STANDARDNational forewordThis British Standard is the U
2、K implementation of EN 16102:2011. The UK participation in its preparation was entrusted to T e c h n i c a l Committee EPL/278, Road transport informatics.A list of organizations represented on this committee can be obtained on request to its secretary.This publication does not purport to include a
3、ll the necessary provisions of a contract. Users are responsible for its correct application. The British Standards Institution 2012Published by BSI Standards Limited 2012ISBN 978 0 580 70717 9 ICS 35.240.60 Compliance with a British Standard cannot confer immunity from legal obligations.This Britis
4、h Standard was published under the authority of the Standards Policy and Strategy Committee on 29 February 2012.Amendments issued since publicationDate T e x t a f f e c t e dBS EN 16102:2011EUROPEAN STANDARD NORME EUROPENNE EUROPISCHE NORM EN 16102 December 2011 ICS 35.240.60 English Version Intell
5、igent transport systems - eCall - Operating requirements for third party support Systmes de transport intelligents - eCall - Exigences oprationnelles des services eCall de fournisseurs privs Intelligente Verkehrssysteme - Notruf - Betriebsanforderungen fr die Notruf-Untersttzung durch Dritte This Eu
6、ropean Standard was approved by CEN on 22 October 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
7、 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 memb
8、er 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,
9、 Ireland, Italy, Latvia, Lithuania, Luxembourg, Malta, Netherlands, Norway, Poland, Portugal, Romania, Slovakia, Slovenia, Spain, Sweden, Switzerland and United Kingdom. EUROPEAN COMMITTEE FOR STANDARDIZATION COMIT EUROPEN DE NORMALISATION EUROPISCHES KOMITEE FR NORMUNG Management Centre: Avenue Mar
10、nix 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 16102:2011: EBS EN 16102:2011EN 16102:2011 (E) 2 Contents Page FOREWORD .4INTRODUCTION 51 SCOPE 62 NORMATIVE REFERENCES 63 TERMS AND DEFINITIONS 64 SYMBOL
11、S AND ABBREVIATED TERMS 105 HIGH LEVEL FUNCTIONAL REQUIREMENTS 115.1 General high level functional requirements . 115.2 TPS-eCall generic architecture 125.3 TPS-eCall operation sequence 125.4 Privacy aspects . 136 TRANSMISSION FROM VEHICLE ASPECTS 136.1 General requirements for the transmission from
12、 vehicle 136.2 Dual-channel transmission 146.3 Performance of the transmission 146.3.1 Performance criteria for the TPS-eCall service chain . 146.3.2 Performance criteria for additional data 146.4 Routing of a TPS-eCall . 146.5 Call back to vehicle 146.6 Termination of the voice call . 146.7 Priorit
13、isation of a TPS-eCall 146.8 Failure situations 157 DATA 157.1 Generic requirements for TPS-eCall data 157.2 Location data . 157.2.1 Generic requirements for location data . 157.2.2 Insufficient data provided by the GNSS system 157.2.3 Vehicle location. 167.3 Optional additional data . 167.4 Data to
14、 transmit to PSAP: TPS-eCall set of data . 167.4.1 General . 167.4.2 TPS-eCall-UID definition 177.4.3 TPS-eCall-SID definition . 178 TPS IN-VEHICLE SYSTEM REQUIREMENTS . 178.1 General TPS-IVS requirements 178.2 Modes of operation . 178.3 Triggering 188.3.1 Triggering overview 188.3.2 Automatic trigg
15、ering strategy . 188.3.3 Manual triggering strategy . 188.4 Termination of an in progress TPS-eCall . 188.5 Set-up of the voice call . 188.6 Call back function . 198.7 Automatic voice call retry 198.8 Post crash performance of TPS in-vehicle equipment . 198.9 Energy supply . 208.10 In-vehicle Human
16、Machine Interface (HMI) aspects 20BS EN 16102:2011EN 16102:2011 (E) 3 8.10.1 General . 208.10.2 HMI aspects in the case of manual triggering 208.10.3 Alert of the vehicle occupants (automatically or manually triggered) . 208.11 Antenna 209 SERVICE PROVIDER . 219.1 Generic TPSP requirements . 219.2 O
17、perators 219.3 Automatic Call Distribution 219.4 Map accuracy at TPSP 219.5 Test of the data link between the carrier delivering the IVS dataset and the TPSP eCall receiver 219.6 Answering time 219.7 Reception of data without voice call . 219.8 Procedures for answering the voice calls 229.9 Notifyin
18、g the emergency services for their intervention . 229.10 Linguistic aspects . 229.11 TPSP call back number . 229.12 Filing . 239.13 Backup systems 239.14 Availability of the technical chain 239.15 Technical quality management procedures . 2310 TRANSMISSION OF THE EMERGENCY TO THE PSAPS . 2310.1 Gene
19、ral requirements . 2310.2 Relevant contact details . 2410.3 Voice communication . 2410.4 Push transfer of a TPS-eCall set of data (TSD) 2410.5 Transitional arrangements . 2511 TEST AND CONFORMANCE REQUIREMENTS. 2612 MARKING, LABELLING AND PACKAGING . 26ANNEX A (NORMATIVE) STANDARDISED DATA INTERFACE
20、 BETWEEN TPSP AND PSAP . 27A.2 FUNCTIONALITIES . 27A.2.1 The application acknowledgement (ack) . 28A.2.2 Authorization 29A.2.3 The TPS-eCall messages . 31A.2.3.1 Push-INITIATION . 31A.2.3.2 Request emergency data . 31A.2.3.3 Push emergency data 32A.2.3.4 Clear down 32A.2.3.5 Communication control (P
21、ing) 32A.2.4 The PSAP web server wsdl file reference implementation 33A.2.5 The TPSP web server wsdl file as reference implementation 37A.2.6 XML codes of the TPS-eCall set of data for the TPSP/PSAP transmission 40A.3 EUECALL_TPSECALL.XSD . 41ANNEX B (INFORMATIVE) TRANSITIONAL ARRANGEMENTS 44ANNEX C
22、 (INFORMATIVE) XML CODE FOR ADDITIONAL INFORMATION . 48BIBLIOGRAPHY 53BS EN 16102:2011EN 16102:2011 (E) 4 Foreword This document (EN 16102:2011) has been prepared by Technical Committee CEN/TC “Road transport and traffic telematics”, the secretariat of which is held by NEN. This European Standard sh
23、all be given the status of a national standard, either by publication of an identical text or by endorsement, at the latest by June 2012, and conflicting national standards shall be withdrawn at the latest by June 2012. Attention is drawn to the possibility that some of the elements of this document
24、 may be the subject of patent rights. CEN and/or CENELEC shall not be held responsible for identifying any or all such patent rights. According to the CEN/CENELEC Internal Regulations, the national standards organizations of the following countries are bound to implement this European Standard: Aust
25、ria, 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.
26、BS EN 16102:2011EN 16102:2011 (E) 5 Introduction The scale of death and injury on roads in Europe needs to be fully comprehended to understand the need for an automated method to alert about accidents. In 2008, there were 38 900 fatalities in the EU-27. The figure for 2009 is around 34 500 fatalitie
27、s. The trend for 2001 to 2008 is around a 5 % annual reduction. Road accident Injuries are in the region of 1,7 million (2008). An automated method of accident notification has been estimated to have the potential to save up to 2 500 fatalities annually in the EU-27 when fully deployed, and reduce t
28、he severity of injuries in order to bring significant savings to society in terms of reduced costs and human suffering. Emergency calls made from vehicles can assist with the objectives of significantly reducing road deaths and injuries, but drivers often have poor (imprecise) location awareness, es
29、pecially 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 and this is t
30、herefore also contributing to the need for an automated emergency call system in vehicles. In the EU there are over 100 million trips to another EU country per year (EU-15). 65 % of people feel less protected while abroad and most do not know which number to call in an emergency (in some countries o
31、ver 60 %). Language problems are pertinent and may render communication difficult. In the most crucial cases, the victim(s) may not be able to call because they have been injured and/or trapped, do not know the local number to call, and in many cases, particularly in rural situations and late at nig
32、ht, there may be no witnesses who happen to have a mobile phone or a sense of community. The objective of implementing an in-vehicle emergency call system is to automate the notification of a traffic accident. One major benefit is to transmit data from the vehicle. There are two means to provide an
33、eCall from a vehicle: One method is to use the pan-European eCall, which sends the voice call and the data directly to the PSAP, using the emergency number 112. Another method consists of using a third party services supported eCall, referred to as TPS-eCall in this document. This is an eCall varian
34、t which includes the transmission of data to a Third Party Service Provider or TPSP, and the establishment of a voice call with this TPSP. In the case of an emergency likely to require assistance from the emergency services, the TPSP establishes a voice connection with the most appropriate PSAP. The
35、 TPSP also forwards all relevant information concerning the event, including the information specified as mandatory by the MSD standard (EN 15722) as a minimum, to the most appropriate PSAP. The TPSP also provides voice communication between the PSAP and the vehicle occupants by setting up a confere
36、nce call for example, if this is required by any of the parties involved and allowed by the PSAP. This European Standard specifies the generic operational requirements for the TPS-eCall. BS EN 16102:2011EN 16102:2011 (E) 6 1 Scope The objective of implementing a Third Party emergency call is to prov
37、ide emergency assistance and an automated notification of a traffic accident, using Third Party Services packages where such services are supported between the vehicle and a Third Party Service Provider in countries where such notification of an emergency are supported by PSAPs. The first objective
38、of this TPS-eCall is to transfer an emergency message from a vehicle to a Third Party Service Provider (TPSP) in the event of a crash or an emergency, and to establish a voice channel between the in-vehicle equipment and the TPSP. The second objective of this TPS-eCall is, in case of an emergency li
39、kely to require assistance from the emergency services, for the TPSP to transfer an emergency message including the data of the Minimum Set of Data (MSD) (as defined in EN 15722) from the TPSP to the most appropriate PSAP and to make best efforts to establish a direct voice contact between that PSAP
40、 and the occupants of the vehicle if required by the PSAP. This European Standard specifies the general operating requirements and intrinsic procedures for an in-vehicle eCall via the services of a Third Party Service Provider (TPSP). This European Standard also provides definition of the service(s)
41、 provided to the PSAP and the method and form of service delivery. NOTE An important part of the TPS-eCall is the Minimum Set of Data (MSD). The operating requirements for the MSD are determined in this European Standard, but the form and data content of the MSD is not defined herein. The common Eur
42、opean MSD for eCall is determined in EN 15722. Additional data concepts may also be transferred, and it is recommended that any such data concepts be registered using a data registry as defined in EN ISO 24978 to ensure that they can be understood by the recipient. 2 Normative references The followi
43、ng referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies. EN 15722:2011, Intelligent transport systems eSafety eCall m
44、inimum set of data (MSD) 3 Terms and definitions For the purposes of this document, the following terms and definitions apply. 3.1 112 single European emergency call number 3.2 data representations of static or dynamic objects in a formalized manner suitable for communication, interpretation, or pro
45、cessing by humans or by machines 3.3 data concept any of a group of data structures (i.e. object class, property, value domain, data elements, message, interface dialogue, association) referring to abstractions or things in the natural world that can be identified with explicit boundaries and meanin
46、g and whose properties and behaviour all follow the same rules BS EN 16102:2011EN 16102:2011 (E) 7 3.4 data dictionary organized and constructed (electronic database) compilation of descriptions of data concepts that provides a consistent means for documenting, storing and retrieving the syntactical
47、 form (i.e. representational form) and the meaning and connotation of eCall data concept NOTE A data registry provides definition of the metadata concept, it does not store the values of individual instances. For example, a data registry with a data concept registration plate identification of a veh
48、icle defines how the identification numbers/letters are represented. It does not contain a list of particular licence plates. 3.5 data element single unit of information of interest (such as a fact, proposition, observation, etc.) about some (entity) class of interest (e.g. a person, place, process, property, concept, association, state, event) considered to be indivisible in a particular context 3.6 data registry registration process to store data definitions, characterized in a consistent manner,
