17/02/2012
D3.1 Pilot operation preparation report
Version number:
Main author:
Dissemination level:
Lead contractor:
Due date:
Delivery date:
Delivery date updated document
Version 0.4
PU
ERTICO – ITS Europe
29.02.2012
Information and Communications Technologies Policy
Support Programme (the “ICT PSP”)
Information Society and Media Directorate-General
Grant agreement no.: 270906
Pilot type A
Page left intentionally blank
D3.1 Pilot operation preparation report
Control sheet
Version history
Version
Date
Main author
Summary of changes
0.4
Name
Date
Prepared
Reviewed
Andy Rooke
12/03/2016
Authorized
Circulation
Recipient
Date of submission
Project partners
European Commission
12/03/2016
3
Version 0.4
D3.1 Pilot operation preparation report
TABLE OF CONTENTS
1
TERMS AND ABBREVIATIONS ................................................................................................................... 8
2
INTRODUCTION ....................................................................................................................................... 9
3
2.1
PURPOSE OF DOCUMENT........................................................................................................................ 9
2.2
STRUCTURE OF DOCUMENT.................................................................................................................... 9
2.3
HEERO CONTRACTUAL REFERENCES ....................................................................................................... 9
NATIONAL PILOT STRUCTURE ................................................................................................................ 11
3.1
CROATIA ................................................................................................................................................ 11
3.1.1
SHORT DESCRIPTION ..................................................................................................................... 11
3.1.2
INVOLVED PARTIES ........................................................................................................................ 11
3.2
CZECH REPUBLIC ................................................................................................................................... 14
3.2.1
SHORT DESCRIPTION ..................................................................................................................... 14
3.2.2
INVOLVED PARTIES ........................................................................................................................ 16
3.3
FINLAND ................................................................................................................................................ 16
3.3.1
SHORT DESCRIPTION ..................................................................................................................... 16
3.3.2
INVOLVED PARTIES ........................................................................................................................ 21
3.4
GERMANY .............................................................................................................................................. 22
3.4.1
SHORT DESCRIPTION ..................................................................................................................... 22
3.4.2
INVOLVED PARTIES ........................................................................................................................ 33
3.5
GREECE .................................................................................................................................................. 34
3.5.1
SHORT DESCRIPTION ..................................................................................................................... 34
3.5.2
INVOLVED PARTIES ........................................................................................................................ 35
3.6
ITALY ...................................................................................................................................................... 36
3.6.1
SHORT DESCRIPTION ..................................................................................................................... 36
3.6.2
INVOLVED PARTIES ........................................................................................................................ 37
3.7
ROMANIA .............................................................................................................................................. 37
3.7.1
SHORT DESCRIPTION ..................................................................................................................... 37
3.7.2
INVOLVED PARTIES ........................................................................................................................ 41
3.8
NETHERLANDS ....................................................................................................................................... 42
3.8.1
3.9
4
INVOLVED PARTIES ........................................................................................................................ 42
SWEDEN ................................................................................................................................................ 43
3.9.1
SHORT DESCRIPTION ..................................................................................................................... 43
3.9.2
INVOLVED PARTIES ........................................................................................................................ 43
CASE FILE DATA ...................................................................................................................................... 43
12/03/2016
4
Version 0.4
D3.1 Pilot operation preparation report
5
4.1
CROATIA ................................................................................................................................................ 43
4.2
CZECH REPUBLIC ................................................................................................................................... 44
4.3
FINLAND ................................................................................................................................................ 44
4.4
GERMANY .............................................................................................................................................. 45
4.5
GREECE .................................................................................................................................................. 45
4.6
ITALY ...................................................................................................................................................... 46
4.7
NETHERLANDS ....................................................................................................................................... 47
4.8
ROMANIA .............................................................................................................................................. 48
4.9
SWEDEN ................................................................................................................................................ 48
GENERAL WORKFLOW ........................................................................................................................... 49
5.1
CROATIA ................................................................................................................................................ 49
5.1.1
LABORATORY ECALL T&V .............................................................................................................. 51
5.1.2
ECALL COMMUNICATION T&V ...................................................................................................... 51
5.1.3
SOP TESTING AND VERIFICATION .................................................................................................. 52
5.1.4
POSITION ESTIMATION FOR ECALL T&V ........................................................................................ 53
5.2
CZECH REPUBLIC ................................................................................................................................... 54
5.2.1
ECALL RECEPTION AND VISUALISATION ........................................................................................ 54
5.2.2
EVENT FORM OPENING ................................................................................................................. 55
5.2.3
PROPOSAL OF DATA INTERPRETATION ......................................................................................... 55
5.2.4
PROCESS AUTOMATION ................................................................................................................ 55
5.2.5
GIS VISUALISATION ........................................................................................................................ 56
5.2.6
MANUAL CLASSIFICATION ............................................................................................................. 56
5.2.7
EVENT POSITION DETERMINATION ............................................................................................... 56
5.2.8
REGIONALISATION ......................................................................................................................... 56
5.2.9
ADDITIONAL INFORMATION.......................................................................................................... 56
5.2.10
EVENT SAVING AND DISPATCH ..................................................................................................... 56
5.2.11
REQUEST SEND MSD ..................................................................................................................... 57
5.2.12
PSAP CALL BACK ............................................................................................................................ 57
5.3
FINLAND ................................................................................................................................................ 60
5.4
GERMANY .............................................................................................................................................. 61
5.5
GREECE .................................................................................................................................................. 63
5.6
ITALY ...................................................................................................................................................... 65
5.7
NETHERLANDS ....................................................................................................................................... 65
5.8
ROMANIA .............................................................................................................................................. 67
5.8.1
ECALL RECEPTION AND VISUALISATION ........................................................................................ 67
5.8.2
EVENT FORM OPENING (CASE FOLDER) ........................................................................................ 68
12/03/2016
5
Version 0.4
D3.1 Pilot operation preparation report
5.8.3
COLLECTING SUPPLEMENTARY DATA............................................................................................ 68
5.8.4
TRANSFER THE ECALL TO AGENCIES .............................................................................................. 68
5.8.5
REQUEST SEND MSD ..................................................................................................................... 68
5.8.6
PSAP CALL-BACK ............................................................................................................................ 69
5.9
6
7
SWEDEN ................................................................................................................................................ 69
OPERATION TIMETABLE ......................................................................................................................... 69
6.1
CROATIA ................................................................................................................................................ 69
6.2
CZECH REPUBLIC ................................................................................................................................... 71
6.3
FINLAND ................................................................................................................................................ 72
6.4
GERMANY .............................................................................................................................................. 73
6.5
GREECE .................................................................................................................................................. 73
6.6
ITALY ...................................................................................................................................................... 74
6.7
NETHERLANDS ....................................................................................................................................... 75
6.8
ROMANIA .............................................................................................................................................. 76
6.9
SWEDEN ................................................................................................................................................ 76
ANNEX 1 ................................................................................................................................................ 77
7.1
CROATIA ................................................................................................................................................ 78
7.2
CZECH REPUBLIC ................................................................................................................................... 79
7.3
FINLAND ................................................................................................................................................ 81
7.4
GERMANY .............................................................................................................................................. 82
7.5
GREECE .................................................................................................................................................. 84
7.6
ITALY ...................................................................................................................................................... 85
7.7
NETHERLANDS ....................................................................................................................................... 87
7.8
ROMANIA .............................................................................................................................................. 89
7.9
SWEDEN ................................................................................................................................................ 91
12/03/2016
6
Version 0.4
D3.1 Pilot operation preparation report
Figures
FIGURE 1: ECALL PILOT SITE ARCHITECTURE (CZECH REPUBLIC)
14
FIGURE 2: PILOT SYSTEM ARCHITECTURE
18
FIGURE 3: INDAGON MTT 130 IVS
21
FIGURE 4: ECALL PILOT SYSTEM ARCHITECTURE (GERMANY)
23
FIGURE 5: ECALL TEST AND DEVELOPMENT CENTRE (GERMANY)
23
FIGURE 6: ECALL SERVER SYSTEM OVERVIEW (GERMANY)
26
FIGURE 7: DETAILED DATABASE STRUCTURE (GERMANY)
27
FIGURE 8: CONTINENTAL IVS BLOCK DIAGRAM WITH INTERFACES (GERMANY)
31
FIGURE 9: S1NN IVS SYSTEM OVERVIEW (GERMANY)
32
FIGURE 10: S1NN IVS MODULE (GERMANY)
33
FIGURE 11: ECALL PILOT ARCHITECTURE (GREECE)
35
FIGURE 12: ECALL PILOT ARCHITECTURE (ROMANIA)
39
FIGURE 13: ECALL PILOT ARCHITECTURE (NETHERLANDS)
42
FIGURE 14: ECALL OPERATIONAL WORKFLOW (CROATIA)
50
FIGURE 15: LABORATORY T&V WORKFLOW (CROATIA)
51
FIGURE 16: ECALL COMMUNICATION T&V WORKFLOW (CROATIA)
52
FIGURE 17: POSITION ESTIMATION FOR ECALL T&V (CROATIA)
54
FIGURE 18: ECALL OPERATIONAL WORKFLOW (CZECH REPUBLIC)
58
FIGURE 19: ECALL RECEPTION AND HANDLING – DETAILED DESCRIPTION (CZECH REPUBLIC)
59
FIGURE 20: PSAP STRUCTURE (FINLAND)
60
FIGURE 21: ECALL OPERATION WORKFLOW (GERMANY)
62
FIGURE 22: ECALL OPERATIONAL WORKFLOW (GREECE)
64
FIGURE 23: ECALL OPERATIONAL WORKFLOW (ITALY)
65
FIGURE 24: ECALL OPERATIONAL WORKFLOW (NETHERLANDS)
66
FIGURE 25: ECALL OPERATIONAL WORKFLOW (ROMANIA)
67
FIGURE 26: OPERATIONAL TIMETABLE (CROATIA)
71
FIGURE 27: OPERATIONAL TIMETABLE (CZECH REPUBLIC)
71
FIGURE 28: OPERATIONAL TIMETABLE (FINLAND)
72
FIGURE 29: OPERATIONAL TIMETABLE (GERMANY)
73
FIGURE 30: OPERATIONAL TIMETABLE (GREECE)
73
FIGURE 31: OPERATIONAL TIMETABLE (ITALY)
74
FIGURE 32: OPERATIONAL TIMETABLE (NETHERLANDS)
75
FIGURE 33: HAZARDOUS GOODS VEHICLES TIMETABLE (NETHERLANDS)
75
12/03/2016
7
Version 0.4
D3.1 Pilot operation preparation report
Tables
TABLE 1: INVOLVED PARTIES (FINLAND)
21
TABLE 2: TEST PARAMETERS THAT CAN BE CONFIGURED (GERMANY)
29
TABLE 3: INVOLVED PARTIES (GERMANY)
33
TABLE 4: INVOLVED PARTIES (GREECE)
35
TABLE 5: INVOLVED PARTIES (ROMANIA)
41
TABLE 6: CASE FILE DATA (CROATIA)
43
TABLE 7: CASE FILE DATA (CZECH REPUBLIC)
44
TABLE 8: CASE FILE DATA (FINLAND)
45
TABLE 9: CASE FILE DATA (GERMANY)
45
TABLE 10: CASE FILE DATA (GREECE)
45
TABLE 11: CASE FILE DATA (ITALY)
46
TABLE 12: CASE FILE DATA (NETHERLANDS)
47
TABLE 13: CASE FILE DATA (ROMANIA)
48
TABLE 14: LABORATORY ECALL T&V (CROATIA)
51
TABLE 15: ECALL COMMUNICATION T&V (CROATIA)
52
TABLE 16: ECALL SOP T&V (CROATIA)
53
1 Terms and abbreviations
Abbreviation
Definition
CIP
EC
Competitiveness and Innovation Framework Programme
European Commission
Term
Definition
Process
The method of operation in any particular stage of development of the
material part, component or assembly involved.
12/03/2016
8
Version 0.4
D3.1 Pilot operation preparation report
2 Introduction
2.1
Purpose of Document
The purpose of this document is to describe the Pilot operation in each Members State, what
will be tested and who is involved.
2.2
Structure of Document
2.3
HeERO Contractual References
HeERO is a Pilot type A of the ICT Policy Support Programme (ICT PSP), Competitiveness
and Innovation Framework Programme (CIP). It stands for Harmonised eCall European Pilot.
The Grant Agreement number is 270906 and project duration is 36 months, effective from 01
January 2011 until 31 December 2013. It is a contract with the European Commission, DG
INFSO.
The principal EC Project Officer is:
Emilio Davila-Gonzalez
EUROPEAN COMMISSION
DG INFSO
Office: BU 31 – 4/50
B - 1049 Brussels
Tel: +32 296 2188
E-mail: Emilio.Davila-Gonzalez@ec.europa.eu
Two other Project Officer will follow the HeERO project:

Eva Boethius
(eva.boethius@ec.europa.eu)

Pierpaolo Tona
(Pierpaolo.TONA@ec.europa.eu)
Address to which all deliverables and reports have to be sent:
Emilio Davila-Gonzalez
EUROPEAN COMMISSION
DG INFSO
BU 31 – 4/50
B - 1049 Brussels
Tel: +32 296 2188
12/03/2016
9
Version 0.4
D3.1 Pilot operation preparation report
by mail: Emilio.Davila-Gonzalez@ec.europa.eu
Any communication or request concerning the grant agreement shall identify the grant
agreement number, the nature and details of the request or communication and be submitted
to the following addresses:
European Commission
Information Society and Media Directorate-General
B-1049 Brussels
Belgium
by electronic mail:
INFSO-ICT-PSP-270906@ec.europa.eu
12/03/2016
10
Version 0.4
D3.1 Pilot operation preparation report
3 National pilot structure
3.1
3.1.1
Croatia
Short description
Please give a short description of your national pilot structure, concentrating on the
operational aspect, with only a high level description of your HW and SW architecture. You
should also mention what type of platform you will use for operation: integrated in the current
112 system, dedicated test site, simulated test site etc.
3.1.2
Involved parties
3.1.2.1 National Protection and Rescue Directorate (NPRD)
The National Protection and Rescue Directorate is an independent, professional and
administrative organization, working on behalf of the Ministry of Interior of Republic of
Croatia. It is tasked with preparing plans and managing operational forces as well as
coordinating the activities of all participants in the protection and rescue system. The basic
tasks of the National Protection and Rescue Directorate are stipulated by the Law on
protection and rescue. The most important tasks are risk and vulnerability assessment,
drafting measures aimed at preventing crises and accidents, ensuring that these measures
are implemented, and effective emergency management in case of major disasters. The
functionality of the Directorate is ensured through its territorial organization i.e. each County
has a County Protection and Rescue Office consisting of Prevention, Planning and
Supervision Department and the County 112 centre. In County Offices of the four biggest
cities Zagreb, Rijeka, Osijek and Split there are Protection and Rescue Departments, while in
the County Offices on the coast (Zadar, Šibenik, Split and Dubrovnik) there are also State
Intervention Units.
Main tasks
In the pilot NPRD will act as PSAP operator, SOPs, emergency service (fire brigade), and
will also contribute to the performance validation and verification.
3.1.2.2 Croatian Automobile Club (HAK)
“Hrvatski autoklub" - HAK is the Croatian National Automobile Club, an association of drivers
and local automobile clubs, a non-profit and nongovernmental organization. It was
established in 1906 and its activities focus conditions, providing touring information, driver
education, motor vehicle inspection etc. HAK has been a pioneer in introducing road and
travel information in the South East Europe region. At this moment, there are more than
12/03/2016
11
Version 0.4
D3.1 Pilot operation preparation report
170.000 members of HAK, or, approximately 8% of the Croatian drivers' population, and 106
local automobile clubs who are associated. For more than 40 years, HAK is involved in roadassistance and is the absolute leader in this field in Croatia when it comes to volume, service
quality and brand recognition.
As a member of the Fédération Internationale de l'Automobile – FIA, HAK is also actively
involved in the global public policy, covering the following areas: road safety, consumer
protection, environment, sustainable mobility, tourism. Also, HAK is a member and actively
participates in work of several international professional organizations, namely CIECA –
Commission Internationale des Examens de Conduite Automobile, CITA – International
Motor Vehicle Inspection Committee, IVV - International Association for Driver Education. As
a member of ERIC - European Road Information Centre, HAK participates in pan-European
touring and road information distribution.
Main tasks
HAK will provide IVS-equipped vehicles for the Croatian pilot. They will also participate to the
verification tasks and to the integration of eCall to the road assistance.
3.1.2.3 Ericsson Nikola Tesla (ENT)
Ericsson Nikola Tesla (ENT) is a Croatian company, and the largest specialised provider of
telecommunications products, solutions and services in Central and Eastern Europe. The
company employees more than 1600 people and has been in business for sixty successful
years. Today, more than fourteen years after Ericsson became its major share-holder, ENT
is an expert centre in the field of information and communications technology and a
significant constituent part of Ericsson in the market unit Central Europe. ENT is mainly
focused on design and development of innovative ICT solutions and services, including
design, planning, and engineering of multi-service, mobile (GSM, GPRS and UMTS
systems), transport and business communication networks, as well as application and
service development based on mobile Internet for regional and global fixed and mobile
telephony operators. ENT is developer and provider of e-systems (mainly in e-health, but
also in transport, public safety and location-based services domains) solutions as well as
system integrator in the ICT domain. The ENT has been participating in several EU R&D
projects in the ICT Work programme, mainly in technical roles.
Main tasks
During the pilot, ENT will participate to the system integration activities by taking care of the
network and PSAP adjustments in support of eCall and for the advanced services as well as
12/03/2016
12
Version 0.4
D3.1 Pilot operation preparation report
providing laboratory for eCall verification. ENT will also contribute to the verification activities
and to the certification analysis.
3.1.2.4 Other parties involved
Other parties involved include other members of Croatian eCall pilot consortium as it follows:

Ministry of Sea, Transport and Infrastructure and Croatian Post and Electronic
Communications Agency will contribute to the pilot with the preparation of the
regulatory framework for the eCall implementation.

Ministry of Interior is responsible for the emergency service (police) and the
implementation of the eCall regulatory framework.

Ministry of Tourism will provide the assistance in integration of the eCall service with
traffic and tourist information services.

Central State Administrative Office for e-Croatia will contribute with activities related
to advanced service development and the eCall integration with the other eGovernment systems.

Renault SA (France), SkyMeter Corp (not member of consortium) and Provatis Corp
(not member of consortium) will provide the IVS-equipped vehicles, validate the eCall
service and participate in evaluation methodology development and data analysis.
There is a possibility that other IVS manufacturers also participate in WP3 Operations
by providing their IVS units for test.

MNOs Tele2 and VIPNET will support the pilot by provision of mobile communication
network support to eCall.

Hrvatske autoceste is a Croatian motorway operator, responsible for operating and
maintenance. The company will contribute to the pilot by participating in SOP and
methodology development, and eCall validation.

Fakultet elektrotehnike i računarstva will participate in evaluation methodology
development, and eCall performance validation.

P. Z. Auto, the Croatian representative of Volkswagen AG, will provide the IVSequipped vehicles and participate in eCall validation.

Institut prometa i veza will participate in the eCall performance validation and the
eCall evaluation methodology development, providing its road traffic expertise.
12/03/2016
13
Version 0.4
D3.1 Pilot operation preparation report
3.2
3.2.1
Czech Republic
Short description
HeERO pilot project in Czech Republic will test IVS from two vendors - Sherlog Trace and
Telematix. ECall is transmitted through Telefónica Mobile Network specially adjusted by
eCall Flag functionality and eCall reception will be realised in the PSAP “testing platform”
which truly simulates the PSAP 112 operating system and is usually used for the new PSAP
SW / functions verification. TPS interface as well as data flow towards Traffic management
system will be tested.
Figure 1: eCall Pilot Site Architecture (Czech Republic)
3.2.1.1 eCall project architectural overview
eCall will be in general routed to the appropriate PSAP based on caller location at the time of
emergency set up activation - origin dependent routing. Basic routing parameter is so called
Network Routing Number (NRN). NRN is generated by origin mobile exchange that handle
emergency set up of the caller and it corresponds to the region where the caller is located
and appropriate PSAP centre should receive and handle the call. During HeERO project
eCall will be routed via mobile and fixed network to the local exchange, where the PSAP
12/03/2016
14
Version 0.4
D3.1 Pilot operation preparation report
testing platform is connected via ISDN 30 link. NRN will be in the future also used by PSAP
CCD (Call Centre Distribution) part for automatic call distribution to the call taker in
respective region.
eCall solution will be integrated to the existing system for reception and handling of E112 in
Czech Republic.
3.2.1.2 PSAP testing platform integrates:

2 OmniPCX Enterprise PBX (R 10) of Alcatel Lucent

CCD (Call Centre Distribution)

Genesys solution - TServer (R 7.6.003.08)

1 CCIVR server on Windows 2008 Server

1 PSAP Application Server on Linux Red Hat 6

Call taker application for 7 operators

VIN decoder

Communication module with interfaces to external systems

GIS
The PSAP eCall modem is a component designed to be one element of the PSAP system. It
is an Application Server (AS) designed to be integrated into the Alcatel SIP Network and run
on a Linux platform. This component is connected to the PABX via SIP Trunk. External calls
received from IVS through the PSTN network are routed to this external AS. The PABX
forwards the call and, if required, converts the voice format using its interval media gateway.
The eCall modem accepts incoming calls only in G711 codec format.
As soon as the RTP channel is started, an eCall voice dialog with the IVS system starts. The
normal issue is the reception of a 140 bytes data frame of MSD. When this reception is OK,
the eCall modem initiates a dialog with an external component named CCIVR. The role of
the CCIVR is to attach the received data to the call using the Genesys 'Attach Data' concept
and routes the call to the agent group – pilot CCD.
When operator takes the call, its call taker application is in charge to get attached data – all
information provided in the MSD. Then the operator is in audio communication with the
occupants of the vehicle.
Application superstructure – Call Taker application of Vitkovice IT Solutions, is responsible
for:
12/03/2016
15
Version 0.4
D3.1 Pilot operation preparation report

MSD handling

presentation and visualization of MSD and decoded VIN in call taker application

visualization of incident location in GIS

implementation of VIN decoder interface

transmission of MSD and VIN data to the Emergency Rescue systems (Fire Rescue
Service, Police and Ambulance)

transmission of eCall data into the Traffic Management System

implementation of TPS interface
Functional modules:

eCall handling (call reception, resend MSD, call-back)

eCall data distribution

eCall data visualisation (Event form, GIS map)

VIN decoder interface

Traffic mgt interface

TPS interface

TDS handling
3.2.2
3.3
3.3.1
Involved parties
Finland
Short description
3.3.1.1 Introduction
Finland has a single-layered PSAP system, which now has 15 PSAPs (In Finland referred as
Emergency Rescue Centres) which all use the same central emergency situation handling
system with connections to police and rescue forces systems and databases. So when there
is an incident on the road and someone phones to the PSAP/ERC from the scene, it is
directed to the nearest PSAP which takes care of dispatching the help to the spot. Currently
the location of the incident is either given by the informer (address) or via mobile network
12/03/2016
16
Version 0.4
D3.1 Pilot operation preparation report
cell-id. eCall handling procedure will work in a similar manner; the novelty will be the MSD
bringing the exact GNSS coordinates of the location which will speed up the process.
The system for eCall piloting is built to simulate this straight-forward one-number emergency
handling. The testing is done in simulated PSAP environment, and the experiences from the
test bed are exploited in updating the real PSAP system.
PSAP (Emergency Rescue Centre Administration) is currently renewing its central system,
the provider has just been selected and the work has begun. The new system will be
functioning by 2015 in the same time as the organisational consolidation from 15 ERCs into
6. eCall will be included in the new system and all eCall related specifications and standards
can be taken into account. First modules will be tested by 2013. As for the current system the
discussions have begun with the system provider Siemens.
As for MSD mediating, as it is, to other officials’ databases (police, rescue forces, border
guard etc.) it will not happen. PSAP/ERC will handle the MSD (extract it) and mediate the
location data to other systems if needed. ERC takes care that all relevant information is
mediated to the police and rescue forces as in current situation.
3.3.1.2 eCall pilot system architecture overview
Finnish eCall pilot system includes test bed, clients and IVS which use standardised in-band
modem. Flag tests will be done with Finnish MNO’s (at least one) own laboratory.
Pilot testing environment is run completely separated from real PSAP system, but tests are
going to be done also in PSAP environment when the necessary upgrading is done in the
existing PSAP system.
12/03/2016
17
Version 0.4
D3.1 Pilot operation preparation report
Figure 2: Pilot System Architecture
The main parts of the system include:

eCall client simulator (eCall IVS)

PSAP simulator, which consists of eCall test bed system, and APIs to related test
systems

eCall pilot system control and administrator’s UI.
3.3.1.2.1 eCall client simulator (IVS)
The eCall client (IVS) simulator include functionality for generating and combining eCall
message data content, encoding the message data for data transfer, opening phone call and
using in-band modem for sending eCall messages.
It will include a user interface for
configuring and generating eCall messages.
The generated MSD data is encoded for the data transfer according to the standard CEN EN
15722 (eCall minimum set of data). The client will use the eCall standardized in-band modem
data transfer for sending messages.
The messages (opened voice call) are targeted to the configured phone number of the eCall
receiver side (PSAP simulator). For testing purposes, the number is other than 112.
12/03/2016
18
Version 0.4
D3.1 Pilot operation preparation report
In addition to the client simulator, several client IVS prototypes will be used during the pilot
phases (cf. Section 3.1.2.4 and 3.1.3).
3.3.1.2.2 eCall test bed
The eCall test bed is the eCall message receiver part of the system. It includes functionality
for handling incoming eCall phone calls. It receives and decodes eCall message data,
includes interfaces for PSAP subsystems, provides logs for analysing results and includes
facility for configuring the operation of the system.
A test phone number (other than 112) is configured for test bed to receive eCall phone calls.
The test bed uses the standardized in-band modem to extract eCall data from the call.
The test bed decodes and validates incoming MSD messages. For analysing results, there is
a log facility included into the system that provides information about received messages and
error cases. In particular, it is used to validate the operation of the system as well as eCall
clients. The logs generated by the test bed have a particular importance in validation of the
system operation.
3.3.1.2.3 eCall pilot system control and administrator’s UI
During the tests, a Web user interface for managing the operation of the test bed will be used
It provides configurations for the test users, possibility to register the eCall clients (e.g. client
phone numbers) used in the tests. Also, the pilot system operation can be managed via the
user interface. It will also provide views to result logs.
The log facility of the test bed will provide information about received messages (e.g. call
time, modem session, duration, MSD information, warnings) and error cases. In particular, it
will be used to validate the operation of the system as well as eCall clients.
3.3.1.2.4 eCall clients to be used in the tests, first phase requirements
The clients include functionality for generating and combining eCall message data content,
encoding the message data for data transfer, opening phone call and using in-band modem
for sending eCall messages to the test number of the eCall test bed. In addition, clients
should be able to assign eCall flag for the call.
The minimum requirements for the IVS device prototypes are as follows:

generating eCall message data content (initiation of eCall). The required data content
including location data is specified in the MSD specification CEN EN 15722.

encoding the message data for data transfer according to the MSD specification CEN
EN 15722
12/03/2016
19
Version 0.4
D3.1 Pilot operation preparation report

opening voice call and using eCall in-band modem for data transfer according to
eCall in-band modem specifications ETSI TS 126 267, ETSI TS 126 268 .

to implement eCall flag, which is specified in ETSI TS 124 008 (eCall Discriminator
Table 10.5.135d)
In addition, the generic eCall operating and high level application requirements described in
the specifications CEN 16062 and CEN 16072 are to be followed.
Device prototypes could be installed in vehicles. Optionally, they will be configurable to
automatically initiate calls and in-band MSD transmission with predefined interval to the
predefined number of the test bed.
3.3.1.3 eCall IVS systems
At least two different domestic IVS prototypes will be tested, and probably couple of foreign.
3.3.1.3.1 Gecko systems / www.geckosystems.fi
System description
Tokay is a multi-constellation tracking device compatible with all current and upcoming global
navigation satellite systems. It has a quad-frequency GSM modem and support for two SIM
cards for flexible cellular connectivity.
Functions supported

32 channel GPS/GLONASS/GALILEO/COMPASS/SBAS and Mobile (Cell ID)

tracking

Quad-band modem with 2 SIM card places, upgraded to standard in-band modem

Customizable firmware (Python)

10 I/O ports for telemetry (analogue/digital)

Internal backup battery (optional)

RS-232 output for NMEA 0183 data

Operating temperature from -40 to +85 °C

Robust aluminium casing
3.3.1.3.2 Indagon / www.indagon.fi
Indagon MTT 130A, MTT 130T, MTT 130F are tracking devices compatible with DGPS
positioning and UMTS/HDSPA 900/2100 MHz and GSM/GPRS/EDGE 850/900/1800 MHZ
12/03/2016
20
Version 0.4
D3.1 Pilot operation preparation report
mobile communication. They have aluminium casing, Operative temperature -40 to +65 °C.
Positioning accuracy is <2 m.
Figure 3: Indagon MTT 130 IVS
3.3.2
Involved parties
Table 1: Involved Parties (Finland)
HeERO
Consortium
Name
Role
Ministry of Transport and
Communications
MS leader
Yes
Emergency Rescue Centre
Administration
Responsible of PSAP system development,
PSAP training, PSAP test environment
Yes
VTT
Responsible for operating the Finnish
National Pilot, test bed functions and tests
Yes
Gecko Systems
IVS vendor
subcontractor
Indagon
IVS vendor
subcontractor
Digia
PSAP software developer
subcontractor
Elisa
MNO flag tests
No (National
associated
partner)
Sonera
MNO flag tests
No (National
associated
partner)
FICORA
MNO authority
No (National
associated
partner)
Traffic Safety Agency
VIN
No (National
associated
partner)
Siemens
PSAP software vendor (ELS system)
No
12/03/2016
21
Version 0.4
D3.1 Pilot operation preparation report
3.4
3.4.1
Germany
Short description
3.4.1.1 Introduction
This report describes the detailed Hardware and Software implementation for HeERO in
Germany. It also provides an implementation plan for the intended eCall pilot in Germany.
The implementation plan is based on the deliverable D2.2 (eCall Systems Functionalities’
Specification – eCall pilot Germany), which specifies the functionalities of the eCall pilot in
Germany.
eCall development in Germany started in 2009, so there are currently several IVS boxes
installed with earlier specification versions than the current 10.0. However, the German
PSAP software will support these systems until they will have been upgraded to the latest
version.
3.4.1.2 eCall pilot system architecture
Unlike most other European countries, Germany has a very complicated PSAP infrastructure
with currently about 270 PSAPs with big differences in technical infrastructure. The two
selected PSAPs in Braunschweig and Oldenburg are well equipped but their software
solution for the PSAP operators is completely different. Thus in 2010 the German HeERO
team decided in preparation to the project, to develop a PSAP system that can be operated
completely separately, but can be integrated during the project into existing software
solutions. On the specification side, the German eCall PSAP solution is completely compliant
to the latest eCall specification. It also supports earlier specifications for MSD, HLAP and InBand modem to allow comparisons between the different specifications. This will help to
decide if later specifications bring a progress or maybe a drawback at some point.
The PSAP system is not integrated into the 112 call in the first step (2011/12). This is
because of a missing implementation of the eCall flag in all German Mobile networks. This
means that eCalls will be processed over a long number.
On the other side, the German IVS for eCall equipped cars are completely comparable to the
IVS in other countries. However, they need to be configured to use a long number instead of
112 because of the missing eCall flag in the first step of the project to operate properly. The
following picture shows the complete structure between the IVS and the eCall PSAP centre:
12/03/2016
22
Version 0.4
D3.1 Pilot operation preparation report
Figure 4: eCall pilot system architecture (Germany)
3.4.1.3 eCall pilot system components
3.4.1.3.1 eCall Test and Development server (PSAP)
Due to the different standards in the German PSAPs, there are many different software
solutions installed in the PSAPs. To avoid dealing with special interfaces and interests,
Germany decided to develop special PSAP eCall software to allow a detailed testing
concerning all levels of communication. The software was also designed as a test platform
for vehicle manufacturers, OEMs and in- vehicle system (IVS) developers for developing and
testing of eCall Vehicle Components.
Figure 5: eCall Test and Development Centre (Germany)
The characteristics of this eCall Test and Development Centre are:

Supporting latest specifications in compliance with CEN and ETSI, certified by TÜV
Süd Germany

Complete, easy-to-use interface for PSAP simulation, con- figuration and evaluation
of test cases
12/03/2016
23
Version 0.4
D3.1 Pilot operation preparation report

Stand-alone system or integrated system – MS Windows client or web interface

Test cases can be selected per vehicle and per IVS. This allows to define special
protocol behaviour, MSD treatment and In-band modem versions per IVS (per car)

Parameter set for HLAP and in-band modem for each test case variable for border
and tolerance tests. This allows to modify the specified parameters but also to check
whether IVS is specification compliant or not.

Databases for cars, telephone numbers and test cases to

Detailed event logs with direct link to Google maps to show eCall coordinates, instant
delivery via email for success control

Supports up to 30 ISDN lines (depending on ISDN base interface and ISDN card)

Client-server based system: Linux Server, Windows or web based Client, running
also in virtual machines

Access from public networks possible

eCall calls can be forwarded to existing telephone systems, VoIP phones or mobile
phones, this allows completely separated instances for server and client
environments. It also allows the server to run without any interference to existing 112
services in the PSAP, which is necessary until the eCall flag is established in
Germany.

Public Safety Answering Point Controls (PSAP) for manual operation or fully
automatic operation. This allows the server to run without any manual interference.
After transmitting the MSD, the phone line is picked up and answered by a digital
audio file. After 20 seconds the PSAP automatically hangs up the phone and ends
the call.

MSD decoding and displaying the position in the digital map. Map data can be
installed locally or accessed from Internet

Multilingual: Language selection at program start
The technical requirements for the this eCall Test and Development Centre are

ISDN standard connection or and VoIP Telephony System

Standard Intel computers for the Application Server (including an ISDN card and
Linux operating system) and the eCall Client Application (with Windows operating
12/03/2016
24
Version 0.4
D3.1 Pilot operation preparation report
system, XP SP2 or higher, or Web-based using Internet Explorer, Firefox, Chrome or
Safari web browser)

Internet connection for access to Google Maps
To meet multi user requirements the German eCall PSAP server uses client-server
architecture. The server is Linux based and uses a few existing open source software
components. Asterisk is a software private branch exchange (PBX). It takes care of all ISDN
call handling so that no CAPI programming is necessary in the development of new system
components. Furthermore Asterisk provides an advanced rule based call forwarding system
so it is possible to transfer calls to nearly arbitrary locations. That means it is possible to use
either ISDN or IP phones for operator workstations. It is even possible to use mobile phones,
though not recommended for obvious reasons.
There are three components that have to be developed to make the system work. The eCall
test centre client is running at every operator’s workstation. It represents the main user
interface to the whole system. The client gets all data from the server and sends all requests
to the server as well. Main tasks are display of MSD values and configuration of test cases.
The client is not responsible for the voice call. That means the transmission of audio data is
completely delegated to either an actual hardware telephone or a soft phone running on the
operator’s computer. This is one of main differences between the eCall test centre and the
eCall demonstrator where one software component handled everything.
The other two components are called eCall-Master and eCall-Worker and are running on the
server. The master is the system’s main component. When started it spawns a number of
eCall-Worker processes that are responsible for call handling and operation of the eCall inband modem. Each worker handles only one call at a time. So for n calls at least n worker
processes are required.
The master maintains an inter process communication channel to each worker it has started.
This channel is used in both directions. For instance the master can send a request to a
worker to establish a MSD transmission from an IVS while a call is active after the operator
gave the order by clicking a button in the test centre client. The worker on the other side
primarily sends status updates concerning the current call that the worker is handling.
Besides taking care of the worker processes the master communicates with one or more test
centre clients. A message passing system is used for this purpose. It is provided by
RabbitMQ which is an open source implementation of the AMQP specification.
12/03/2016
25
Version 0.4
D3.1 Pilot operation preparation report
1. Call
ISDN
CAPI
Asterisk PBX
2. Call
SIP
SIP//ISDN
ISDNPhone
Phone
2. Call
2. Call
Local Loopback
eCall-Worker
Asterisk
Asterisk
C
LAN
pipe[0]
pipe[1]
IPC
eCall-Master
Ruby
eCall Events
Request
Local Loopback
RabbitMQ (AMQP Broker)
eCall Test Centre
Client
eCall Events
Call Back Request, MSD Request
C# .NET
Linux
Windows XP
Figure 6: eCall Server system overview (Germany)
3.4.1.3.2 Database Structure
All information that has to be persistent stored in a MySQL database. The only component
accessing the database is the eCall master. Other components have to use the previously
described interfaces to get data into or out of the database.
12/03/2016
26
Version 0.4
D3.1 Pilot operation preparation report
Figure 7: Detailed Database Structure (Germany)
One basic procedure while accessing the database is to never delete data. That’s why many
tables contain a column “visible”, which acts as a flag to hide entries that the user has
chosen to remove.
What follows is a rundown of all tables in the database and a coarse overview on what data
they contain.
12/03/2016
27
Version 0.4
D3.1 Pilot operation preparation report
3.4.1.3.2.1 calls
For every call one entry is saved in this table. Data includes beginning and end of call as well
as to which vehicle the call is attributed.
3.4.1.3.2.2 data_sets
Because more than one MSD can be transmitted in the course of one call this table is
necessary to carry all MSD data. A MSD is saved in raw format as well as decoded.
3.4.1.3.2.3 logs
Every log message by any eCall worker is saved to this table.
3.4.1.3.2.4 phone_vehicle_links
This table saves links between phones and vehicles.
3.4.1.3.2.5 phones
This tables saves data about phones, most notably the MSISDN and whether the phone is
currently active or not.
3.4.1.3.2.6 preferences
This table normally has only one entry that contains all global preferences that can be
changed in the eCall test centre client UI. Columns contain email addresses to which call
logs are being forwarded, the system’s call acceptance mode and the telephone numbers of
the operator telephones.
3.4.1.3.2.7 test_case_vehicle_links
This table saves links between test cases and vehicles.
3.4.1.3.2.8 test_cases
This table contains all user defined test cases with names.
3.4.1.3.2.9 test_parameters
This table contains all test parameters that were set by a user. Every parameter has a link to
the containing test case in the test case table.
3.4.1.3.2.10
vehicles
This table contains all vehicles that were either created by a user or were created
automatically by the system because of an incoming call from that vehicle.
12/03/2016
28
Version 0.4
D3.1 Pilot operation preparation report
3.4.1.3.3 Implementation Details of Software Components
Because of different requirements the software components use quite varying technologies
when compared to each other.
3.4.1.3.3.1 eCall master
Implementation language is Ruby. Uses threads to handle multiple worker processes
simultaneously. Uses the ActiveRecord ORM framework to access the database.
3.4.1.3.3.2 eCall worker
Implementation language is C. Uses a combination of SIP and RTP to transmit audio data to
and from Asterisk. Integrated is the reference eCall in-band modem.
3.4.1.3.3.3 eCall test centre client
Implementation language is C#- using the .NET framework.
3.4.1.3.3.4 List of Available Test Parameters
The following test parameters can be configured per test case.
Table 2: Test parameters that can be configured (Germany)
Parameter
name
Accept call
Type
bool
Default
value
Legal values
True / False
True
Remarks
If this is set to true, a caller gets
busy signal
Hang up call
int
after
AL-Ack value
int
0 – 3600
0, means
seconds
never
0 – 15
0, means
Hang up after X seconds
„Positive
Ack“
Request MSD
int
after
Abort after
bool
0 – 3600
0, means
seconds
never
True / False
False
initiation
Number of LL-
12/03/2016
Disconnects in-band modem
upon INITIATION signal
int
0 – 20
4
Acks
Number of AL-
Measured from call begin
0 implies deactivation of in-band
modem
int
0 – 20
4
29
0 implies deactivation of in-band
Version 0.4
D3.1 Pilot operation preparation report
Parameter
name
Type
Default
value
Legal values
Acks
Timer T4 (wait
Remarks
modem
int
0 – 20 seconds
2
for INITIATION
According to CEN/TC-278
(HLAP) Annex A
signal)
Timer T8 (MSD
int
0 – 120 seconds 20
max reception
According to CEN/TC-278
(HLAP) Annex A
time)
Call back after
int
0 – 3600
0, means
X seconds after hang up a call
seconds
never
back to IVS is automatically
established. Upon call back all
other test parameters are getting
ignored.
This description is an extract from the document “eCall Test Centre Server – Software
Specification V0.9”, which describes the interfaces between Broker, Master and Client in
detail.
3.4.1.4 eCall IVS systems
In Germany, IVS systems will be handled as “black boxes”. This means the systems will
undergo a validation, but the internal structure is not of interest.
However, the German system consists of either a NXP chipset (S1nn) or a Sagem chipset
(Continental). The following two sections show the principle block structure of the S1nn and
the Continental IVS. Further details are on behalf of Continental and S1nn.
3.4.1.4.1 Continental
Block Diagram with Interfaces
The block diagram gives an overview of Continental’s solution of an eCall-module.
12/03/2016
30
Version 0.4
D3.1 Pilot operation preparation report
Figure 8: Continental IVS Block Diagram with interfaces (Germany)
The HW of the eCall-module is grouped into the sections Vehicle Interface / Communication,
Network Access Device (NAD), Power and SIM. Network access will be realized on GSMbasis (2G).
Dimensions of the Modules
Not yet defined
User Interface
The modules will be connected to the cigarette lighter socket in the car for 12V power-supply
and placed on the dashboard to get GPS-reception. For deploying eCalls it will be possible to
send a configuration-SMS to the module. Thereby the module can be enabled to send
automatic calls to PSAPs in determined intervals. Information about the calls will be stored in
internal flash-memory. This data can be used for analysis-purposes. The modules can be
stopped sending eCalls with another configuration-SMS.
As a second possibility single eCalls can be deployed by pressing a button on the module.
The status of the module can be recognized by means of the lighting schema of 2 LEDs.
12/03/2016
31
Version 0.4
D3.1 Pilot operation preparation report
3.4.1.4.2 S1nn
S1nn ECall System: Technical Overview

Based on NXP ATOP Telematics Module

Interface- and application processor

Runs latest ECall modem

GPS and GSM connectivity

Internal GSM + GPS antenna

Automotive grade power supply
Figure 9: S1nn IVS System Overview (Germany)

Fakra interface for external antennas

SIM slot

Car interface including:

Microphone input

Speaker output

LED outputs

Button input (for manual ECall)
12/03/2016
32
Version 0.4
D3.1 Pilot operation preparation report


Voltage supply

CAN interface

Debug interfaces
Compact design

Approx. 13cm by 6.5cm by 4cm

Rigid housing
Figure 10: S1nn IVS module (Germany)

3.4.2
User Interface for HeERO:

Button module for manual ECall and status LEDs

Speaker and microphone
Involved parties
Table 3: Involved parties (Germany)
HeERO
Consortium
Name
Role
ITS Niedersachsen GmbH
Project Management (acts for the German
Ministry of Transport)
Yes
OECON Products &
Services GmbH
Responsible for operating the German
National Pilot, PSAP assistance and
training, Field test assistance
Yes
ADAC e.V.
PSAP assistance and training, Field test
assistance
Yes
S1nn GmbH
IVS vendor
Yes
12/03/2016
33
Version 0.4
D3.1 Pilot operation preparation report
HeERO
Consortium
Name
Role
NXP
Chipset Vendor, IVS prototypes
Yes
Continental GmbH
OVS vendor
Yes
Flughafentransfer
Hannover GmbH
Test Fleet operator
Yes
NavCert GmbH
Test Suites, Validation of Field Test Results
Yes
Leitstelle Oldenburg
PSAP
No
(Associated
Partner)
Leitstelle Braunschweig
PSAP
No
(Associated
Partner)
3.5
3.5.1
Greece
Short description
The envisaged architecture for the Greek pilot site is shown below. Two vehicles will be
equipped with an IVS. The IVS will be able to initiate an eCall to the 112 with the eCall flag
activated.
The MNO and fixed line operator will make use of this flag, so as to route the eCall to one
dedicated Call Centre, for eCalls only. The location of the eCall Call Centre will be decided in
cooperation with the General Secretariat of Civil Protection.
All the hardware and software will be acquired through a public tender procedure. For the
scope of HeERO there will be two working places for two operators of the eCall Call Centre.
The PSAP software will be able to query the Greek VIN database and retrieve data relevant
to the vehicle involved in the incident.
12/03/2016
34
Version 0.4
D3.1 Pilot operation preparation report
Figure 11: eCall Pilot Architecture (Greece)
3.5.2
Involved parties
Table 4: Involved parties (Greece)
HeERO
Consortium
Name
Role
Hellenic Ministry of
Infrastructure, Transport
and Networks
Project Management
Yes
Institute of Communication
and Computer Systems
Consultant, Technical Specifications for the
tender procedures, Will overview the field
trials
No
General Secretariat of Civil
Protection
Responsible for PSAP and emergency
services operation
No
Hellenic MNOs
They are going to route the eCalls to the
appropriate destination point
No
Hellenic
Telecommunications
Organisation (fixed line
operator)
It will the eCalls within the PSTN to the
appropriate destination point (Call Centre)
No
Hellenic Police
Will participate in the field trial
No
Hellenic Fire Brigade
Will participate in the field trial
No
Hellenic Emergency
Will participate in the field trial
No
12/03/2016
35
Version 0.4
D3.1 Pilot operation preparation report
Name
HeERO
Consortium
Role
Medical Help Services
(EKAB)
3.6
Italy
3.6.1
Short description
Italian pilot site is located in Varese, Lombardy. It covers a population of 1.1M, serving near
700K calls per year.
The 1st level PSAP receives calls from all Italian national emergency numbers (118 EMS,
113 Police, 115 Fire brigade, 112 Carabinieri) in Varese area on specific queues, in order for
the operators to understand in advance what could be the nature of the emergency,
according to the called number. Operators can record forms with the description of the
emergency and the details of the caller, plus they have the location of the call, thanks to the
interoperation with the National Police Database (CED Interforze).
When an emergency is categorized, the operator contacts the corresponding 2nd level
PSAP(s), describes shortly the event, forwards the event form and then connects the 2nd
level PSAP operators with the caller.
The system includes:

a PBX that manages the incoming and outgoing calls, model Siemens HiPath 4000;

a CTI server that manages the call queues to the operators and conveys information
included in the call signalling. The CTI server is composed by a PBX interface by
Siemens and an operator console interface by Beta 80 Group;

The PSAP event manager, a client-server infrastructure that includes, among its
services, cartography, user interface to create event forms, phone call agents
towards the CTI server. The event manager system, called “emma”, is provided by
Beta 80 Group.
For eCall pilot purposes, a first stage simulated test site is being used, sharing technologies
from Siemens, who is developing the MSD de-modulation HW/SW part, and Beta 80 Group,
who is developing the new MSD information manager and the Operator’s interface (new call
queues indicators, new event forms, new interoperability functions with EUCARIS and
A.C.I.). During the final release of the eCall functions, the real PSAP site in Varese will be
used. For this purpose, the national telco provider, Telecom Italia, will configure its landline
12/03/2016
36
Version 0.4
D3.1 Pilot operation preparation report
routing, in order to provide information to the PSAP about the origin of the call (manual eCall,
automatic eCall, traditional emergency call). On the other hand, Telecom Italia, with its
mobile division, will update its base station software, in a selected area around Varese, in
order to be able to manage the new eCall flag, as indicated by the European standards.
3.6.2
Involved parties
Name
HeERO
Consortium
Role
Presidenza del Consiglio
dei Ministri (PCM)
Magneti Marelli S.P.A.
(MM)
Centro Ricerche FIAT
S.C.p.A. (CRF)
Automobile Club d'Italia
(ACI)
TELECOM ITALIA S.p.A
(TI)
National Administration & coordination
Partner
IVS
Partner
IVS and car
Partner
User added service & Road Operator
Partner
MNO & 112 fixed network
Partner
PSAP – Current EU 112 in Varese
Partner
Azienda Regionale
Emergenza Urgenza
(AREU)
3.7
Romania
3.7.1
Short description
The organization structure of 112 Romania consists of:

One Primary Public Safety Answering Points (P-PSAP) in each of the 40 counties
and 2 (primary and backup) in Bucharest;

One Secondary Public Safety Answering Points (S-PSAP) for each of the 4 agencies
(Ambulance, Police, Fire Brigade and Gendarmerie) in each of the 40 counties;

One Secondary Public Safety Answering Points (S-PSAP) for MESRE (Mobile
Emergency Service for Resuscitation and Extrication) in almost each counties and
Bucharest;
12/03/2016
37
Version 0.4
D3.1 Pilot operation preparation report

One Secondary Public Safety Answering Points (S-PSAP) for each agency that
function at national level (ex. RRA – Romanian Railway Authority) with PSAP only in
Bucharest.

One Secondary Public Safety Answering Points (S-PSAP) for each emergency
agency of Ambulance, Police and Fire Brigade in each major city working as substations for the county’s S-PSAPs
All the centres are interconnected and are working on the same software and hardware
platforms, exchanging data and calls as needed.
Voice and data communication are
integrated and synchronized on the whole process of handling an emergency call (from the
time the call is received until the resources are dispatched). It consists of the following
subsystems for the 112 emergency calls management:

112 Application (data and VoiP);

F2CA ver. 1.3 (GIS system);

APD Coordinator 7 (AVLS);

SL ver. 1.0 (mobile positioning).
3.7.1.1 eCall project architectural overview
For the eCall solution, Romania implemented the pilot in a centralized manner, all eCalls
(data and voice) are forwarded to a central PSAP located in Bucharest, whose operators will
process the call and will contact directly the necessary emergency services (also referred as
“agencies”) from the county the incident has occurred).
The eCall solution is fully integrated in the existing platforms, and was designed as additional
functions, not modifying but adding new functionalities to existing.
12/03/2016
38
Version 0.4
D3.1 Pilot operation preparation report
Figure 12: eCall Pilot Architecture (Romania)
3.7.1.2 Operational environment for supporting eCall
The operational environment consists of:

112 Application – added new data block in case folder to present to the operators
the MSD and EUCARIS data, developed solution to transfer data and voice between
counties (from PSAP Bucharest to the counties agencies);

F2CA ver. 1.3 – added several blocks and functions in GIS client interface (case lists,
MSD and Eucaris view, notification about eCall);

MSD processing servers (redundant in Bucharest and Brasov counties);

MSD decoding servers (redundant in Bucharest and Brasov counties);

21 eCall modems – responsible for receiving MSD data from IVS (redundant in
Bucharest
and
Brasov
counties),
each
supporting
8
MSD
transactions
simultaneously;

5 IVS – AH3-W based on DSB75 equipment (used only in lab environment and
generating MSD through a interface app on a PC).
12/03/2016
39
Version 0.4
D3.1 Pilot operation preparation report
IVS generic schema
The PSAP eCall modem is a component designed to be the entry point of the PSAP system.
It extracts the MSD and forwards the call to the other communication components (Eones,
MD110 and CXE server - VoiP communication). Tests were performed with several SIM
cards from main Mobile Telephone Operators, but with a specific long B-number to be able to
route the call because the mobile operators still don’t have solutions for implementing eCall
flag. Application structure – Call Taker applications consist of the two main client interfaces,
112 Application and GIS and are responsible for:
GIS client interface:

presentation and visualization of MSD and decoded VIN;

visualization of incident location;

implementation of VIN decoder interface;
112 Application client interface:

presentation and visualization of MSD and decoded VIN;
12/03/2016
40
Version 0.4
D3.1 Pilot operation preparation report

transmission of MSD and VIN data to the Emergency Rescue agencies (Fire Brigade,
Police and Ambulance);

transmission of voice communication to the Emergency Rescue agencies (Fire
Brigade, Police and Ambulance);

3.7.2
transmission of eCall data to the third party systems;
Involved parties
Table 5: Involved parties (Romania)
Name
HeERO
Consortium
Role
STS (Special
Telecommunication
Administrator of 112 system
Yes
Project Coordinator
Yes
Third Party System
Yes
Service)
ITS Romania (Intelligent
Transport System)
RNCMNR (National
Company of Motorways
and National Roads in
Romania)
UTI Systems SA
Rohde&Schwarz Topex SA
ELSOL (Electronic
Solution)
TeamNet International SA
12/03/2016
MSD decoding interface, VIN decoder and
the interface with EUCARIS
eCall Modem developer and telephony
integration in the existing system
Yes
No
Operational procedures, NCMNRR interface
Yes
MSD processing interface, 3rd party
interface, eCall solution integrator
No
41
Version 0.4
D3.1 Pilot operation preparation report
3.8
Netherlands
3.7.1
Short description
In the Netherlands the HeERO project partners are Ministry of Transport, Rijkswaterstaat
(RWS) and the National Police Agency (NPA). Both organisations have separate
responsibilities for implementing the pan EU-eCall in their processes. RWS is involved in
Traffic-Management and Transport of Hazardous Goods. NPA is responsible for 112. The
pilot will be realized in a look-a-like standalone simulation system. It is planned that the eCall functionalities will be implemented in the current 112-Avaya communication system in
2013.
Figure 13: eCall Pilot Architecture (Netherlands)
3.8.1 Involved parties

Rijkswaterstaat: project leader

Korps landelijke politiediensten (NPA): project partner

KPN n.v.: subcontractor

Voorziening tot samenwerking Politie Nederland: subcontractor

Veiligheidsregio Rotterdam-Rijnmond: pilot region

Rijksdienst voor het Wegverkeer: EUCARIS VIN supplier
12/03/2016
42
Version 0.4
D3.1 Pilot operation preparation report

3.9
Fleet-owners: to be selected.
Sweden
3.9.1
Short description
3.9.2
Involved parties
4 Case file data
The scope of this is section is to give an overview of the data that is currently available in the
PSAP for every 112 call. Based on this information and where it’s gathered and processed,
every country will design the operational workflow by identifying the mandatory actions that
must be taken by the operator.
Data
112 PSAP
Name
X
Telephone number
Police
Fire brigade
Ambulance
X
Address
Etc.
4.1
Croatia
Data which is currently being collected by the 112 PSAP call taker and by the Emergency
Agencies in case of traffic accident is listed in following table:
Table 6: Case file data (Croatia)
Data
Name
Telephone number
Description
12/03/2016
112 PSAP
Police
Fire brigade
Ambulance
X
X
X
X
X
X
X
X
X
X
43
X
Version 0.4
D3.1 Pilot operation preparation report
Data
112 PSAP
Accident location
Vehicle orientation
Number
injured
Fire
of
people
Are injured people
trapped in vehicle
Dangerous goods
Fire brigade
Ambulance
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Number of vehicles
involved
4.2
Police
X
X
X
X
X
X
X
X
X
Czech Republic
Table 7: Case file data (Czech Republic)
Data
112 PSAP
Police
Fire brigade
Ambulance
Name
X
X
X
X
Telephone number – X
X
X
X
X
caller contact
Location of the caller
X
Event location
X
X
X
Car data – type, model, X
X
X
year of production
Accident severity
4.3
X
X
Finland
Finnish PSAPs collect the following data from the caller:
12/03/2016
44
Version 0.4
D3.1 Pilot operation preparation report
Table 8: Case File Data (Finland)
From caller
Name, location of the accident, description of the accident,
involved vehicle(s) information, passengers etc.
Identified from the
Phone number, address (personal identification number), location
system
of the cell phone
4.4
Germany
In Germany with it’s over 250 different PSAPs, it is currently unclear what data is exactly
collected. Depending on the local authority, PSAPs often integrate Ambulance and Fire
Brigade, but not Police (which is in Germany a 110 call and is completely separated from the
112 process). However, all PSAPs collect usual address information and additional
descriptions from 112 calls. This data will also be collected for 112 eCalls (which only are of
interest in this document).
The PSAPs in Germany currently collect the following accident-related data:
Table 9: Case file Data (Germany)
Caller
Name, Address, telephone number
Car
Sign, Model, Colour, damage
Accident
Location, situation description, Risk (gasoline running out etc.), Number
of affected cars
Car occupants
4.5
Injuries, pre-existing conditions, pregnancy
Greece
Table 10: Case file Data (Greece)
Data
Voice communication
Telephone number
12/03/2016
112 PSAP
Police
Fire
brigade
Emergency
Medical Help
X
X
45
Version 0.4
D3.1 Pilot operation preparation report
Data
112 PSAP
Emergency Agency called
X (if another
one is
needed)
X
Location of the telephone
(antenna coordinates,
azimuth, estimated distance
from antenna)
Names and IDs of involved
persons
Complete vehicle data
(number of plates, model,
colour, number of licence)
Accident location and date
Accident type and description
Injuries per involved person
Damages
Data for accident
reconstruction (liability,
diagram with cars, braking
distance, testimonies from
drivers and from witnesses if
needed, alcohol test in minor
injuries, drugs test at a
hospital in severe injury or
death)
Transfer point of involved
persons
4.6
Fire
brigade
Police
Emergency
Medical Help
X (if another
one is needed)
X
X
Χ
X
X
X
X
X
X
X
X
X
X
X
Italy
Table 11: Case File Data (Italy)
Data
12/03/2016
112 PSAP
Police
46
Fire brigade
Ambulance
Version 0.4
D3.1 Pilot operation preparation report
Data
112 PSAP
Police
Fire brigade
Ambulance
Name
X
X
X
X
Telephone number
X
X
X
X
Address
X
X
X
X
Event Category
X
X
X
X
Brief Event Description
X
X
X
X
Geographical Position
X
X
X
X
Clinical Data
X
Casualty Description
4.7
X
X
Netherlands
In the current PSAP voice and data are recorded. Actual operational data can be viewed by a
supervisor or real time on performance monitors. Historical data is available in a
management information system. At the 112 PSAP data is logged automatically. Police, Fire
Brigade and Ambulance have to log manual in their incident report system.
The data collected by the 112 PSAP call taker and by the Emergency Agencies (relevant
only for mobile calls):
Table 12: Case file Data (Netherlands)
Data
112 PSAP
Police
Fire brigade
Ambulance
Name
1
X
X
X
Telephone number
X
X
X
X
X
X
X
X
X
X
Address
Location-information
Call-history
Cell-ID
X
1 In 2012 a digital network will be realized to transfer data from PSAP 1st level to PSAP 2nd level (Police-Fire brigadeAmbulance)
12/03/2016
47
Version 0.4
D3.1 Pilot operation preparation report
4.8
Romania
Table 13: Case file Data (Romania)
Data
Role
112 PSAP
Police
Fire
brigade
Ambulance
Free text
Short
description
of incident
X
X
X
X
Incident address
Locality,
municipality,
Street, street
no.
X
X
X
X
Responsibility area
Agencies
responsibility
area
X
X
X
Caller information
Name,
Surname,
telephone
number,
address
X
X
X
X
Victim information
Name,
Surname,
age, sex,
X
X
X
X
Telephone location
Cell id,
Sector id
position
X
X
X
X
Case index
Incident
Classification
X
X
X
X
Case questions
Help
operator to
understand
the incident
type
X
X
X
MSD
All fields
according to
standards
X
X
X
X
EUCARIS
All fields
according to
standards
X
X
X
X
4.9
Sweden
To be added
12/03/2016
48
Version 0.4
D3.1 Pilot operation preparation report
5 General workflow
Please describe the general operational workflow for handling an eCall. This workflow should
be done from an operational point of view, describing actions done by the call-taker. This
general workflow should cover only a “basic” eCall, without mentioning any exceptions (call
drops because a weak signal). All the exceptions will be covered in the operational
procedures in a decision workflow.
Your input should be composed of a graphic representation of the workflow and a text
description for all the steps in the workflow.
As example you can use the attached Romanian workflow.
5.1
Croatia
12/03/2016
49
Version 0.4
D3.1 Pilot operation preparation report
Figure 14: eCall Operational Workflow (Croatia)
12/03/2016
50
Version 0.4
D3.1 Pilot operation preparation report
5.1.1
Laboratory eCall T&V
Laboratory testing of eCall includes 7 different scenarios. Four scenarios include on site IVS
units tested against mobile network infrastructure which includes eCall flag feature and
PSAP, and additional three scenarios which includes remote testing from various IVS units
against PSAP solution. In remote testing MNO eCall flag feature is not being tested.
Table 14: Laboratory eCall T&V (Croatia)
Code
No. of IVS units No. of IVS units eCall
involved
in roaming
initiation
No. of repeated
initiations
No. of
tests
L1
1
0
A
0
> 1000
L2
1
1
A
0
> 1000
L3
1
0
M
0
> 1000
L4
1
1
M
0
> 1000
L5
1
0
M
3
> 1000
L6
1
1
M
3
> 1000
L7
1
0
A
3
> 1000
Figure 15: Laboratory T&V Workflow (Croatia)
5.1.2
eCall communication T&V
Group testing of eCall includes four different scenarios which include eCall testing in urban
and rural environment. Test will include variations in number of vehicles involved, will
12/03/2016
51
Version 0.4
D3.1 Pilot operation preparation report
different eCall initiation type, and will monitor the signal strength. All data including IVS
provided date besides MSD, mobile network data and PSAP logs data will be monitored and
examined according to KPIs defined in D4.1.
Table 15: eCall Communication T&V (Croatia)
No. of
No. of
vehicles vehicles in
involved roaming
eCall
No. of
initiation tests
Code
Location
R1
Zagreb Centre - urban
2
1
M
> 100
R2
Zagreb Ring/Motorway rural
3
1
M
> 100
R3
Zagreb Ring/Motorway rural
1
0
A
> 1000
R4
Local road (near
Zagreb) - rural
1
0
A
> 1000
Figure 16: eCall Communication T&V Workflow (Croatia)
5.1.3
SOP testing and verification
SOP testing and verification includes testing of whole eCall chain with information being
forwarded to 2nd level PSAP which includes all involved emergency services as well as traffic
information provider. Since this scenario is identical to General eCall workflow, figure 5.1
applies.
12/03/2016
52
Version 0.4
D3.1 Pilot operation preparation report
Table 16: eCall SOP T&V (Croatia)
5.1.4
No. of
No. of
vehicles vehicles in
involved roaming
eCall
No. of
initiation tests
Code
Location
S1
Zagreb Centre – urban
3
1
M
4
S2
Zagreb Ring/Motorway
– rural
3
1
A
4
Position estimation for eCall T&V
There will be seven eCall equipment-independent tests of GPS vs GPS/GLONASS vs
GPS/EGNOS performance in Zagreb City Centre (2), on the Zagreb - Bjelovar route
(combination of motorway and local roads - 1), and Rijeka - Zagreb motorway (partially
mountainous terrain, with tunnels - 4). Position samples to be taken continuously every 2 s
for at least one hour.
12/03/2016
53
Version 0.4
D3.1 Pilot operation preparation report
Figure 17: Position estimation for eCall T&V (Croatia)
5.2
5.2.1
Czech Republic
eCall reception and visualisation
eCall is automatically picked up due to the auto answer function. On the operator screen
calling line number and eCall icon is displayed. Special acoustic notification can be
configured.
12/03/2016
54
Version 0.4
D3.1 Pilot operation preparation report
5.2.2
Event form opening
Operator opens on the screen the form for new event data entry. In the sub-form of
“telephone detail” call info and MSD are displayed. Location and vehicle direction are handed
over to the GIS client. GIS displays these data and recent vehicle location n-1 (n-2) as well.
5.2.3
Proposal of data interpretation
Operator is notified of eCall data quality and credibility by means of key MSD value
(automatic activation, test call, trusted position).
Even in case that this information cannot be confirmed by voice communication with
passengers, interpretation is as follows:

eCall was activated automatically – it is probably a traffic collision

eCall was activated manually – it can be ether traffic collision or other type of incident

eCall is test call – event classification is predefined as technological test

if position credibility is impeached, then automatisms are stopped
5.2.4
Process automation
Operator can take control of status of all started automatisms.
5.2.4.1 Automatic matching caller position with event position
Control bits:
Automatic activation = Yes
Position Can Be Trusted = True
5.2.4.2 Automatic classification
Control bits:
Automatic activation = Yes
Test call = No
System automatically set up predefined classification “traffic accident” for all rescue forces
(Fire Rescue, Ambulance, and Police)
Automatic activation = Yes
Test call = Yes
System automatically set up predefined classification “technological test”.
12/03/2016
55
Version 0.4
D3.1 Pilot operation preparation report
5.2.4.3 Automatic regionalisation
If caller position is matched with event positron, system finds out regionalisation rule for the
road (road + km + direction) that has been found as probable road where vehicle was
moving. In case that the rule doesn’t exist or such a road is not found, system takes a
nearest urban area accordingly to GPS position and offers regionalisation rule based on a
real regionalisation.
5.2.5
GIS visualisation
Call taker application sends position and direction information to the GIS.
5.2.6
Manual classification
In case that process of automatic classification is deactivated, operator takes out the
classification manually from the menu.
5.2.7
Event position determination

By means of line topography if probable road is known

If probable road is not found, then event position is determined as a call position point
+ urban area, to which the call position point belongs – it means determination by the
help of address topography

Call taker application switches over topography folds according to the event position
determination
5.2.8
Regionalisation
After event positron is fixed a regionalisation can start. If road number+ km + direction is
available then line regionalisation is done. If t is not available, then areal regionalisation
based on urban area is used.
5.2.9
Additional information
If vehicle occupants communicate, operator completes information as follows:

communication level (communicates / doesn’t communicate)

call back number (alternative to IVS number)

other remarks (e.g. caller name)
5.2.10 Event saving and dispatch
Operator saves an event and system automatically sends data record to the Emergency
Control Centre system of rescue forces and to the Traffic Management System.
12/03/2016
56
Version 0.4
D3.1 Pilot operation preparation report
5.2.11 Request SEND MSD
Procedure description:
1. Operator evaluates the data in the MSD are inadequate, or otherwise applying the update
(e.g. corrupted data, the position is marked as unreliable).
2. Operator notifies the caller that voice communication will be interrupted.
3. Operator presses "Request MSD" button.

In call sub-form a running MSD query is signalised

call is automatically routed to the IVR (disappears from the phone software)

after MSD is received, call is routed back to the operator workplace, where the
call was originally handled - in SW phone call is ringing

this call is indicated by the Call Agent as a call from the previously adopted
and broken eCall

data from the IVR are processed by eCall Centre module meanwhile, this
module informs dispatching application which reads the updated data

operator will answer call automatically – thus voice communication with the
caller will be restored
4. Operator notifies the caller in distress to restore voice communication.
5.2.12 PSAP Call back
This is a situation where the call is interrupted or there is need from another reason to join
the car crew. If the operator uses PSAP call back function (i.e. for call back is used a number
which came from the initial call) he will be able to request for delivery of MSD.
Procedure description:
1. Operator uses the option from the context menu item above telephone number in the
property grid with call properties and chooses "Call back" option.
2. After creating a connection is set up, application automatically connects an outgoing call
to the event.
3. Operator has dispatcher has now again possibility to seek re-sending MSD.
4. MSD received will be appended to the original call.
12/03/2016
57
Version 0.4
D3.1 Pilot operation preparation report
Figure 18: eCall Operational Workflow (Czech Republic)
12/03/2016
58
Version 0.4
D3.1 Pilot operation preparation report
Figure 19: eCall reception and handling – detailed description (Czech Republic)
12/03/2016
59
Version 0.4
D3.1 Pilot operation preparation report
5.3
Finland
In Finland, eCalls will not be making any new workflow efforts, the exact location coming with
the MSD will speed the process.
The following steps will be performed during an eCall reception
1. The PSAP receives an incoming Call with the eCall flag
2. The PSAP eCall switch hardware receives the MSD and sends it to the system
3. The system decodes the MSD [and adds VIN information]
4. The PSAP Operator accepts the call on the phone
5. The operator’s PSAP software retrieves the MSD information which is displayed on the
screen
6. The operator talks to the caller to find out additional information about injuries and other
background information
7. The PSAP immediately notifies of the accident for the needed rescue forces and medical
units and police
8. Emergency services notify the PSAP of the course and end of the operation, as well as
consequences of the accident. The PSAP creates a comprehensive report.
Figure 20: PSAP Structure (Finland)
12/03/2016
60
Version 0.4
D3.1 Pilot operation preparation report
5.4
Germany
In Germany, eCalls will be processed by over 250 PSAPs. Using the eCall flag, they all have
separate telephone line connections for receiving eCalls. This makes the technical handling
of incoming eCalls much easier.
The following steps will be performed during an eCall reception
1. The PSAP receives an incoming Call at the eCall phone line
2. The PSAP eCall switch hardware receives the MSD and sends it to the eCall Centre
3. The eCall Centre decodes the MSD and adds EUCARIS and VIN information
4. In the PSAP, the voice call is transmitted to the internal PBX
5. The PSAP Operator accepts the call on the phone
6. The operator’s PSAP software retrieves the MSD information from the eCall Centre and
displays it on the screen
7. The operator talks to the caller to find out additional information about injuries (how badly,
is it possible to reach the injured, can they be taken out of the vehicle), situation ((short
description of the accident, who is involved?), environment (Is any vehicle on fire and
how many), passengers (preconditions, pregnancy)
8. The Centre immediately notifies of the accident the following:
a. Emergency Medical Dispatcher of the Emergency Medical Service,
b. Operational Communications Centre of the Police Administration,
c. Operational centre of the legal entity in charge of maintenance and management of
the highway section on which the accident happened,
d. Competent fire fighting unit.
e. TMC
9. When the forces in the field cannot cope with the situation, they may require additional
teams either through their internal communications or through the Centre.
10. In case of road accidents involving a large number of fatalities, victims and major
damage, the PSAP notifies other PSAPs.
11. Emergency services notify the PSAP of the course and end of the operation, as well as
consequences of the accident. The PSAP creates a comprehensive report.
12/03/2016
61
Version 0.4
D3.1 Pilot operation preparation report
Figure 21: eCall Operation Workflow (Germany)
12/03/2016
62
Version 0.4
D3.1 Pilot operation preparation report
5.5
Greece
The eCalls will be processed by the dedicated eCall Call Centre. The MNOs and fixed line
operator will route the eCalls to this Call Centre.
The following steps will be performed during an eCall reception:
1. The eCall Call Centre receives an incoming eCall
2. The PSAP software decodes the MSD and queries the VIN database.
3. The voice call is transferred to a PSAP operator and the decoded MSD data and relevant
vehicle data are displayed at the screen.
4. If communication with a vehicle passenger is feasible, the PSAP operator evaluates
which Emergency Services are needed and notifies them.
5. If communication with a vehicle passenger is not feasible, the PSAP operator notifies all
emergency services. If there is communication established until the time of arrival of the
first rescuer at the incident location, the PSAP operator evaluates which Emergency
Services are actually needed and notifies the rest ones to return back.
6. After the first rescuer arrives at the incident location, he/she estimates the severity and
informs the Emergency Service Centre.
7. The rescue operation is performed and the Emergency Service Centre is notified about
the result.
8.
Emergency forces return to their Operation Centres.
12/03/2016
63
Version 0.4
D3.1 Pilot operation preparation report
Figure 22: eCall Operational Workflow (Greece)
12/03/2016
64
Version 0.4
D3.1 Pilot operation preparation report
5.6
Italy
Figure 23: eCall Operational Workflow (Italy)
5.7
Netherlands
This figure shows the call flow to be tested in the project. Important detail is the difference in
routing between a manual and an automatic e-Call.
To save time an automatic eCall will be directly routed to the call taker in PSAP 2nd level.
The manual call is routed to the PSAP 1st lever to be validated before transferring.
12/03/2016
65
Version 0.4
D3.1 Pilot operation preparation report
Figure 24: eCall Operational Workflow (Netherlands)
12/03/2016
66
Version 0.4
D3.1 Pilot operation preparation report
5.8
Romania
Figure 25: eCall Operational Workflow (Romania)
5.8.1
eCall reception and visualisation
eCall is automatically routed to the Bucharest PSAP’s operators in the same manner as a
regular 112 emergency call. eCall is transported through the same communication
infrastructure but is answered by different 112 operators (there are specific operators with
the role of handling eCall). eCall is received in the 112 Application. When the call is
answered, a voice message is played, alerting the operator that a MSD is transferred. After
the MSD is transferred, an acoustic message alerts the operator that the voice channel is
12/03/2016
67
Version 0.4
D3.1 Pilot operation preparation report
opened and she can try to communicate with the passengers in the vehicle. The voice
message can be configured and is implemented on the eCall PSAP modem level.
5.8.2
Event form opening (case folder)
When the call is answered, the form for new event data entry (case folder) is automatically
opened and presented to the 112 eCall operator in 112 Application and a notification window
on the GIS client interface is shown. When the MSD data is received, a button on the
notification block become active (allowing to the operator to view the MSD data in the GIS
client interface) and the case folder is automatic filled with all the MSD data. In the same
time, the location incident (GPS coordinates) is positioned on the GIS client interface. Based
on GPS position the GIS send to 112 Application the Incident Address (Street, Street no,
Locality, Municipality).
5.8.3
Collecting supplementary data
After the initial data (MSD) is displayed in GIS and 112 Application interfaces, the 112 eCall
operator is responsible to collect supplementary data (if is possible from the interview) and to
classify the incident according to the incidents list (INDEX OF INCIDENTS – commonly
agreed with the specialized intervention agencies). All data are introduced in 112 Application
client interface. EUCARIS data is presented to the operator only at his own request (done
from a button in GIS client – available both PSAP and agencies operators).
5.8.4
Transfer the eCall to agencies
After collecting all the necessary data (MSD and interview), the 112 eCall operator ensure
that the relevant data information of the case (incident case file) and the associated voice
communication are transferred to the responsible agencies from the area where the incident
has occurred. In the same time a notification is sent to the PSAP operators from the county
where the incident occurred. This notification is sent in order to alert the PSAP operators that
an eCall was already sent to the county agencies as a measure to prevent multiple alerts for
the same incident that can occur on regular 112 emergency calls.
5.8.5
Request SEND MSD
Procedure description:
1. Operator evaluates the data in the MSD as inadequate, corrupted data, position not
presented, position changed.
2. Operator notifies the caller that the voice communication will be interrupted.
3. Operator presses "Request MSD" button from the GIS client interface.
12/03/2016
68
Version 0.4
D3.1 Pilot operation preparation report
4. A new MSD is received and during that, the alert voice message is played.
5. Operator notifies the caller that the voice communication is restored.
5.8.6
PSAP Call-back
This is a situation where the call is interrupted or from another reason is needed to call the
car passengers. The operator uses contact book from 112 Application client interface
(copy/paste the number from the case folder associated with the initial call) and push the
contact button.
Procedure description:
1. Operator uses the option call from contact book in the 112 Application client interface.
2. IVS answer.
3. Operator has now again possibility to seek re-sending MSD.
5.9
Sweden
6 Operation timetable
Please give an overview of your timetable for national operation activities, indicating the most
important milestones. This was already presented by all of you at the KoM in Bucharest so
you can include here.
6.1
Croatia
Operational timetable of Croatian eCall pilot is presented on Figure 6.1¸Operations will
consist of two different phases, laboratory testing and field testing. Laboratory testing will
take part in M10 & M11 of the project, and field testing will take part in two different time
slots, from M11-M24 and from M24-M36.
Laboratory testing
In Croatian eCall pilot IVSs are to be examined against the emulated mobile network with
limited radio coverage and the full eCall flag feature deployed. The emulated mobile network
resembles the real network of one of Croatian eCall Pilot MNO partners. Both long numbers
and 112 number are to be utilised. Calls will terminate at the real PSAP (not a simulator),
12/03/2016
69
Version 0.4
D3.1 Pilot operation preparation report
where the appropriate eCall event log will be managed (in a manner described in WP4 and
WP3 deliverables). The ENT PSAP applied is an Ericsson commercial product with the same
features and architecture as those already deployed in Croatian 112 system.
During the laboratory testing phase, the IVSs are not to be installed in vehicles, but to be
kept in laboratory, situated as to provide the appropriate GPS/Glonass signal reception
quality. Both manual and automatic eCall initiations are to be performed.
Testing and validation in real network in limited spatial and technological environment
The eCall flag feature will be implemented in mobile network of HeERO partners. During this
testing phase, the IVSs will be tested in real environment, according to defined scenarios (do
refer to WP4 deliverables). Only 112 number dial examinations are to be performed to
ensure that eCall terminates at the eCall-enabled PSAP, operated by National Protection and
Rescue Directorate (a HeERO partner, and Croatian eCall Pilot national co-ordinator). A
separate (log-based) report is to be issued for every series of tests.
12/03/2016
70
Version 0.4
D3.1 Pilot operation preparation report
Figure 26: Operational timetable (Croatia)
6.2
Czech Republic
Figure 27: Operational timetable (Czech Republic)
12/03/2016
71
Version 0.4
D3.1 Pilot operation preparation report
6.3
Finland
Figure 28: Operational timetable (Finland)
12/03/2016
72
Version 0.4
D3.1 Pilot operation preparation report
6.4
Germany
Figure 29: Operational timetable (Germany)
6.5
ID
Greece
Task Name
2011
1
2012
2013
May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb
Public procurement for the acquisition of equipment for the PSAP centre
2
Public procurement for the acquisition of modems for the pilot test vehicles
3
Organisational arrangements
4
Installation and intiial functional testing of the equipment
5
Public procurement for the software customisation
6
Software customisation
7
System implementation
8
Training of PSAP operators
9
Operations
Figure 30: Operational timetable (Greece)
12/03/2016
73
Version 0.4
D3.1 Pilot operation preparation report
6.6
Italy
T1 11
ID
Nome attività
Inizio
gen
1
2
Core functionality: eCall development and test (no eCall flag)
01/06/2011
31/05/2012
01/06/2011
31/05/2012
3
PSAP1 hw upgrade
01/09/2011
31/01/2012
4
MEB prototyping
01/09/2011
08/12/2011
5
MEB development
09/12/2011
30/12/2011
6
Tlab (Turin) MEB installation & integration
02/01/2012
31/01/2012
01/11/2011
30/04/2012
7
Development
PSAP1 sw upgrade
8
Requirement analisys
01/11/2011
31/01/2012
9
Sw development and test
01/02/2012
30/04/2012
01/11/2011
30/04/2012
10
VIN Decoder & Eucaris
11
Requirement analisys
01/11/2011
31/01/2012
12
Sw development and test
02/02/2012
30/04/2012
18/10/2011
30/05/2012
13
IVS - MM
14
T-Box firmware customization - eCall management
18/10/2011
29/02/2012
15
T-Box firmware customization - bCall management
01/03/2012
18/04/2012
16
T-Box firmware customization - eCall flag management
11/05/2012
30/05/2012
01/06/2011
31/05/2012
17
IVS - CRF
18
Agreement with IVS suppliers
01/06/2011
30/12/2011
19
Compliance verification to eCall std & requirements
03/10/2011
18/01/2012
20
On board installation impact analisys
01/12/2011
31/05/2012
21
Design & development of IVS - car network integration
18/01/2012
31/05/2012
03/10/2011
31/05/2012
22
Mobile and Fixed networks upgrade
23
Mobile Network - Impact analysis & deployment requirement
03/10/2011
19/12/2011
24
Mobile Network - eCall discriminator signalling patch provision by Ericsson
01/12/2011
16/01/2012
25
Mobile Network - eCall discriminator signalling patch pre-deployment test
17/01/2012
15/03/2012
26
Mobile Network - eCall discriminator deployment in the Varese MSC and testing
02/04/2012
18/05/2012
27
Fixed Network - Impact Analysis & Deployment requirements
03/10/2011
19/12/2011
28
Fixed Network - Deployment of the selected eCall routing in the fixed network
30/01/2012
20/04/2012
29
End-to End eCall Routing mobile/fixed networks test
21/05/2012
31/05/2012
01/02/2012
31/05/2012
30
Component and Integration test
31
MSD extraction & voice tests
01/02/2012
29/02/2012
32
MSD decoding & voice tests
01/03/2012
30/03/2012
33
Varese (PSAP) MEB installation & integration
02/04/2012
30/04/2012
34
Varese (PSAP) sw & network integration + IVS tests + operator training
01/05/2012
31/05/2012
01/03/2012
28/02/2013
01/03/2012
28/02/2013
35
36
Test main functionality
Development
37
ACI bCall service provider customization
02/03/2012
18/04/2012
38
MM T-Box bCall tests with ACI provider
19/04/2012
15/05/2012
39
ACI fleet recruitment
01/03/2012
31/10/2012
40
MM T-Box ACI cars installation
01/11/2012
28/02/2013
41
Training for ACI drivers
01/11/2012
28/02/2013
01/06/2012
30/11/2012
42
Operational tests
43
Automatic & manual eCall - CRF cars
01/06/2012
31/07/2012
44
Manual eCall & bCall + EGNOS - MM car
01/06/2012
29/06/2012
45
Processing results & KPI of operational tests
01/08/2012
30/11/2012
46
Test add functionality
03/09/2012
30/09/2013
47
Development
03/09/2012
28/02/2013
48
RTTI Centre Simulator development
03/09/2012
30/11/2012
49
PSAP sw development for Interaction with the RTTI Centre
03/12/2012
28/02/2013
03/01/2013
30/09/2013
50
Operational tests
T2 11
T3 11
T4 11
T1 12
T2 12
T3 12
T4 12
T1 13
T2 13
T3 13
T4 13
Fine
51
Automatic & manual eCall - CRF cars
03/01/2013
28/02/2013
52
Interoperable eCall with DE & CZ cars
03/01/2013
28/02/2013
53
Manual eCall + EGNOS - ACI cars
01/03/2013
31/05/2013
54
Manual bCall + EGNOS - ACI cars
01/03/2013
31/05/2013
55
Processing results & KPI of operational tests
01/03/2013
30/09/2013
feb
mar
apr
mag
giu
lug
ago
set
ott
nov
dic
gen
feb
mar
apr
mag
giu
lug
ago
set
ott
nov
dic
gen
feb
mar
apr
mag
giu
lug
ago
set
ott
nov
dic
Figure 31: Operational timetable (Italy)
12/03/2016
74
Version 0.4
D3.1 Pilot operation preparation report
6.7
Netherlands
Figure 32: Operational timetable (Netherlands)
Figure 33: Hazardous Goods Vehicles Timetable (Netherlands)
12/03/2016
75
Version 0.4
D3.1 Pilot operation preparation report
6.8
Romania
December 2011 – start operating
January 2012 – analyze / collecting data
February 2012 – adaptation / modification of the current work procedures
March – April 2012 – operating
June 2012 - analyze / collecting data
July 2012 – analyze KPI
August 2012 – optimize workflow
September 2012 – finalizing the work methodology and work procedures
6.9
Sweden
12/03/2016
76
Version 0.4
D3.1 Pilot operation preparation report
7 Annex 1
12/03/2016
77
Version 0.4
D3.1 Pilot operation preparation report
7.1
Croatia
12/03/2016
78
Version 0.4
D3.1 Pilot operation preparation report
7.2
Czech Republic
12/03/2016
79
Version 0.4
D3.1 Pilot operation preparation report
12/03/2016
80
Version 0.4
D3.1 Pilot operation preparation report
7.3
Finland
12/03/2016
81
Version 0.4
D3.1 Pilot operation preparation report
7.4
Germany
12/03/2016
82
Version 0.4
D3.1 Pilot operation preparation report
12/03/2016
83
Version 0.4
D3.1 Pilot operation preparation report
7.5
Greece
12/03/2016
84
Version 0.4
D3.1 Pilot operation preparation report
7.6
Italy
12/03/2016
85
Version 0.4
D3.1 Pilot operation preparation report
12/03/2016
86
Version 0.4
D3.1 Pilot operation preparation report
7.7
Netherlands
12/03/2016
87
Version 0.4
D3.1 Pilot operation preparation report
12/03/2016
88
Version 0.4
D3.1 Pilot operation preparation report
7.8
Romania
12/03/2016
89
Version 0.4
D3.1 Pilot operation preparation report
12/03/2016
90
Version 0.4
D3.1 Pilot operation preparation report
7.9
Sweden
12/03/2016
91
Version 0.4