D3.1 · Web viewSiemens HiPath 4000; a CTI server that manages the call queues to the operators and...

17/02/2012

D3.1 Pilot operation preparation report

Information and Communications Technologies Policy Support Programme (the “ICT PSP”)Information Society and Media Directorate-GeneralGrant agreement no.: 270906Pilot type A

Version number: Version 0.4Main author:Dissemination level: PULead contractor: ERTICO – ITS EuropeDue date: 29.02.2012Delivery date:Delivery date updated document

Page left intentionally blank


Control sheet

Version history

Version Date Main author Summary of changes

0.4

Name Date

Prepared

Reviewed Andy Rooke 09/05/2023

Authorized

Circulation

Recipient Date of submission

Project partners

European Commission

09/05/2023 3 Version 0.4


TABLE OF CONTENTS1 TERMS AND ABBREVIATIONS................................................................................................................. 8

2 INTRODUCTION..................................................................................................................................... 9

2.1 PURPOSE OF DOCUMENT.......................................................................................................................9

2.2 STRUCTURE OF DOCUMENT...................................................................................................................9

2.3 HEERO CONTRACTUAL REFERENCES.......................................................................................................9

3 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.3 FINLAND...............................................................................................................................................16



3.4 GERMANY.............................................................................................................................................22



3.5 GREECE.................................................................................................................................................34



3.6 ITALY.....................................................................................................................................................36



3.7 ROMANIA.............................................................................................................................................37



3.8 NETHERLANDS......................................................................................................................................42


3.9 SWEDEN...............................................................................................................................................43



4 CASE FILE DATA................................................................................................................................... 43

09/05/2023 4 Version 0.4


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

5 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

09/05/2023 5 Version 0.4


5.8.2 EVENT FORM OPENING (CASE FOLDER)........................................................................................68

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

6 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

7 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

09/05/2023 6 Version 0.4


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

09/05/2023 7 Version 0.4


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 Competitiveness and Innovation Framework ProgrammeEC European Commission

Term Definition

Process The method of operation in any particular stage of development of the material part, component or assembly involved.

09/05/2023 8 Version 0.4


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 COMMISSIONDG INFSO Office: BU 31 – 4/50B - 1049 BrusselsTel: +32 296 2188 E-mail: [email protected]

Two other Project Officer will follow the HeERO project:

Eva Boethius ([email protected])

Pierpaolo Tona ([email protected])

Address to which all deliverables and reports have to be sent:

Emilio Davila-GonzalezEUROPEAN COMMISSIONDG INFSO BU 31 – 4/50B - 1049 BrusselsTel: +32 296 2188

09/05/2023 9 Version 0.4

mailto:[email protected]




by mail: [email protected]

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 CommissionInformation Society and Media Directorate-GeneralB-1049 BrusselsBelgium

by electronic mail:

[email protected]

09/05/2023 10 Version 0.4




3 National pilot structure

3.1 Croatia

3.1.1 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

09/05/2023 11 Version 0.4


travel information in the South East Europe region. At this moment, there are more than

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

assistance 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

09/05/2023 12 Version 0.4


providing laboratory for eCall verification. ENT will also contribute to the verification activities

and to the certification analysis.

3.1.2.4 Other parties involvedOther 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 e-

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

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

09/05/2023 13 Version 0.4


3.2 Czech Republic


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

09/05/2023 14 Version 0.4


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:

09/05/2023 15 Version 0.4


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


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

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.

09/05/2023 16 Version 0.4


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

09/05/2023 17 Version 0.4


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.

09/05/2023 18 Version 0.4


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

09/05/2023 19 Version 0.4


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

09/05/2023 20 Version 0.4

http://www.geckosystems.fi/


mobile communication. They have aluminium casing, Operative temperature -40 to +65 °C.

Positioning accuracy is <2 m.

Figure 3: Indagon MTT 130 IVS


Table 1: Involved Parties (Finland)

Name Role HeERO Consortium

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 testsNo (National associated partner)

Sonera MNO flag testsNo (National associated partner)

FICORA MNO authorityNo (National associated partner)

Traffic Safety Agency VINNo (National associated partner)

Siemens PSAP software vendor (ELS system) No

09/05/2023 21 Version 0.4


3.4 Germany


3.4.1.1 IntroductionThis 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 architectureUnlike 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 In-

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

09/05/2023 22 Version 0.4


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, configuration and evaluation

of test cases

09/05/2023 23 Version 0.4


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

09/05/2023 24 Version 0.4


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

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

09/05/2023 25 Version 0.4


ISDN

CAPI

LAN

Asterisk PBX

Asterisk

eCall-Master

AsteriskeCall-Worker

Local Loopback

IPC

1. Call

2. Call

C

pipe[1]

eCall Test Centre Client

SIP / ISDN PhoneSIP / ISDN Phone

LinuxWindows XP

2. Call

C# .NET

Ruby

RabbitMQ (AMQP Broker)eCall Events

Call Back Request, MSD Request

Local Loopback

Request

2. Call

pipe[0]eC

all Events

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.

09/05/2023 26 Version 0.4


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.

09/05/2023 27 Version 0.4


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.

09/05/2023 28 Version 0.4


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 Type Legal values Default value Remarks

Accept call bool True / False True If this is set to true, a caller gets

busy signal

Hang up call after int 0 – 3600 seconds 0, means

never

Hang up after X seconds

AL-Ack value int 0 – 15 0, means

„Positive

Ack“

Request MSD

after

int 0 – 3600 seconds 0, means

never

Measured from call begin

Abort after

initiation

bool True / False False Disconnects in-band modem upon

INITIATION signal

Number of LL-

Acks

int 0 – 20 4 0 implies deactivation of in-band

modem

Number of AL-

Acks

int 0 – 20 4 0 implies deactivation of in-band

modem

09/05/2023 29 Version 0.4


Parameter name Type Legal values Default value Remarks

Timer T4 (wait for

INITIATION

signal)

int 0 – 20 seconds 2 According to CEN/TC-278 (HLAP)

Annex A

Timer T8 (MSD

max reception

time)

int 0 – 120 seconds 20 According to CEN/TC-278 (HLAP)

Annex A

Call back after int 0 – 3600 seconds 0, means

never

X seconds after hang up a call 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 systemsIn 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.

09/05/2023 30 Version 0.4


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

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

09/05/2023 31 Version 0.4


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)

Voltage supply

09/05/2023 32 Version 0.4


CAN interface

Debug interfaces

Compact design

Approx. 13cm by 6.5cm by 4cm

Rigid housing

Figure 10: S1nn IVS module (Germany)

User Interface for HeERO:

Button module for manual ECall and status LEDs

Speaker and microphone


Table 3: Involved parties (Germany)


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

NXP Chipset Vendor, IVS prototypes Yes

Continental GmbH OVS vendor Yes

09/05/2023 33 Version 0.4



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 Greece


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.

09/05/2023 34 Version 0.4


Figure 11: eCall Pilot Architecture (Greece)


Table 4: Involved parties (Greece)


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 Medical Help Services (EKAB)

Will participate in the field trial No

09/05/2023 35 Version 0.4


3.6 Italy


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

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.

09/05/2023 36 Version 0.4




Presidenza del Consiglio dei

Ministri (PCM)National Administration & coordination Partner

Magneti Marelli S.P.A. (MM) IVS Partner

Centro Ricerche FIAT

S.C.p.A. (CRF)IVS and car Partner

Automobile Club d'Italia (ACI) User added service & Road Operator Partner

TELECOM ITALIA S.p.A (TI) MNO & 112 fixed network Partner

Azienda Regionale

Emergenza Urgenza (AREU)PSAP – Current EU 112 in Varese Partner

3.7 Romania


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;

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

stations 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

09/05/2023 37 Version 0.4


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

09/05/2023 38 Version 0.4


Figure 12: eCall Pilot Architecture (Romania)

3.7.1.2 Operational environment for supporting eCallThe 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).

09/05/2023 39 Version 0.4


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;

09/05/2023 40 Version 0.4


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

transmission of eCall data to the third party systems;


Table 5: Involved parties (Romania)


STS (Special

Telecommunication Service)Administrator of 112 system Yes

ITS Romania (Intelligent

Transport System)Project Coordinator Yes

RNCMNR (National Company

of Motorways and National

Roads in Romania)

Third Party System Yes

UTI Systems SAMSD decoding interface, VIN decoder and the

interface with EUCARISYes

Rohde&Schwarz Topex SAeCall Modem developer and telephony

integration in the existing system No

ELSOL (Electronic Solution) Operational procedures, NCMNRR interface Yes

TeamNet International SA MSD processing interface, 3rd party interface, eCall solution integrator No

09/05/2023 41 Version 0.4


3.8 Netherlands


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

Call functionalities will be implemented in the current 112-Avaya communication system in

2013.

Figure 13: eCall Pilot Architecture (Netherlands)


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

09/05/2023 42 Version 0.4


Fleet-owners: to be selected.

3.9 Sweden



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 Police Fire brigade Ambulance

Name X

Telephone number 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)


Name X X X

Telephone number X X X X

Description X X X X

09/05/2023 43 Version 0.4



Accident location X X X X

Vehicle orientation X X X X

Number of people injured X X X

Fire X X X X

Are injured people trapped in vehicle X X X

Dangerous goods X X X

Number of vehicles involved X X

4.2 Czech Republic

Table 7: Case file data (Czech Republic)


Name X X X X

Telephone number –

caller contact

X X X X

Location of the caller X

Event location X X X X

Car data – type, model,

year of production

X X X

Accident severity X X

4.3 Finland

Finnish PSAPs collect the following data from the caller:

09/05/2023 44 Version 0.4


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 system

Phone number, address (personal identification number), location

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 Injuries, pre-existing conditions, pregnancy

4.5 Greece

Table 10: Case file Data (Greece)

Data 112 PSAP Police Fire brigade

Emergency Medical Help

Voice communication XTelephone number X

09/05/2023 45 Version 0.4


Data 112 PSAP Police Fire brigade

Emergency Medical Help

Emergency Agency called X

X (if another one is

needed)

X (if another one is needed)

Location of the telephone (antenna coordinates, azimuth, estimated distance from antenna)

X

Names and IDs of involved persons X Χ X

Complete vehicle data (number of plates, model, colour, number of licence)

X X

Accident location and date X X XAccident type and description XInjuries per involved person XDamages XData 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)

X

Transfer point of involved persons X

4.6 Italy

09/05/2023 46 Version 0.4


Table 11: Case File Data (Italy)


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

4.7 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):

09/05/2023 47 Version 0.4


Table 12: Case file Data (Netherlands)


Name 1 X X X


Address X X X

Location-information Cell-ID X X X

Call-history X

4.8 Romania

Table 13: Case file Data (Romania)

Data Role 112 PSAP Police Fire brigade Ambulance

Free textShort description of incident

X X X X

Incident address

Locality, municipality, Street, street no.

X X X X

Responsibility areaAgencies responsibility area

X X X

Caller information

Name, Surname, telephone number, address

X X X X

Victim informationName, Surname, age, sex,

X X X X

Telephone locationCell id, Sector id position

X X X X

1 In 2012 a digital network will be realized to transfer data from PSAP 1st level to PSAP 2nd level (Police-Fire brigade-

Ambulance)

09/05/2023 48 Version 0.4


Data Role 112 PSAP Police Fire brigade Ambulance

Case index Incident Classification X X X X

Case questions

Help operator to understand the incident type

X X X

MSDAll fields according to standards

X X X X

EUCARISAll fields according to standards

X X X X

4.9 Sweden

To be added

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

09/05/2023 49 Version 0.4


Figure 14: eCall Operational Workflow (Croatia)

09/05/2023 50 Version 0.4


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 involved

No. of IVS units in roaming

eCall 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

09/05/2023 51 Version 0.4


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)

Code LocationNo. of vehicles involved

No. of vehicles in roaming

eCall initiation

No. of tests

R1 Zagreb Centre - urban 2 1 M > 100

R2Zagreb Ring/Motorway -rural 3 1 M > 100

R3Zagreb Ring/Motorway - rural 1 0 A > 1000

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

09/05/2023 52 Version 0.4


Table 16: eCall SOP T&V (Croatia)

Code LocationNo. of vehicles involved

No. of vehicles in roaming

eCall initiation

No. of tests

S1 Zagreb Centre – urban 3 1 M 4

S2Zagreb Ring/Motorway – rural 3 1 A 4

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

09/05/2023 53 Version 0.4


Figure 17: Position estimation for eCall T&V (Croatia)

5.2 Czech Republic

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

09/05/2023 54 Version 0.4


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 positionControl bits:

Automatic activation = Yes

Position Can Be Trusted = True

5.2.4.2 Automatic classificationControl bits:


Test call = No

System automatically set up predefined classification “traffic accident” for all rescue forces

(Fire Rescue, Ambulance, and Police)


Test call = Yes

System automatically set up predefined classification “technological test”.

09/05/2023 55 Version 0.4


5.2.4.3 Automatic regionalisationIf 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.

09/05/2023 56 Version 0.4


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.


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.

09/05/2023 57 Version 0.4


Figure 18: eCall Operational Workflow (Czech Republic)

09/05/2023 58 Version 0.4


Figure 19: eCall reception and handling – detailed description (Czech Republic)

09/05/2023 59 Version 0.4


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)

09/05/2023 60 Version 0.4


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.

09/05/2023 61 Version 0.4


Figure 21: eCall Operation Workflow (Germany)

09/05/2023 62 Version 0.4


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.

09/05/2023 63 Version 0.4


Figure 22: eCall Operational Workflow (Greece)

09/05/2023 64 Version 0.4


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.

09/05/2023 65 Version 0.4


09/05/2023 66 Version 0.4


Figure 24: eCall Operational Workflow (Netherlands)

09/05/2023 67 Version 0.4


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

09/05/2023 68 Version 0.4


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


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.

09/05/2023 69 Version 0.4


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.


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

09/05/2023 70 Version 0.4


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.

09/05/2023 71 Version 0.4


Figure 26: Operational timetable (Croatia)

6.2 Czech Republic

Figure 27: Operational timetable (Czech Republic)

09/05/2023 72 Version 0.4


6.3 Finland

Figure 28: Operational timetable (Finland)

09/05/2023 73 Version 0.4


6.4 Germany

Figure 29: Operational timetable (Germany)

6.5 Greece

ID Task Name

1 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

May Jun Jul Aug Sep Oct Nov Dec Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec Jan Feb2011 2012

Figure 30: Operational timetable (Greece)

09/05/2023 74 Version 0.4


6.6 Italy

Figure 31: Operational timetable (Italy)

09/05/2023 75 Version 0.4


6.7 Netherlands

Figure 32: Operational timetable (Netherlands)

Figure 33: Hazardous Goods Vehicles Timetable (Netherlands)

09/05/2023 76 Version 0.4


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

09/05/2023 77 Version 0.4


7 Annex 1

09/05/2023 78 Version 0.4


7.1 Croatia

09/05/2023 79 Version 0.4


7.2 Czech Republic

09/05/2023 80 Version 0.4


09/05/2023 81 Version 0.4


7.3 Finland

09/05/2023 82 Version 0.4


7.4 Germany

09/05/2023 83 Version 0.4


09/05/2023 84 Version 0.4


7.5 Greece

09/05/2023 85 Version 0.4


7.6 Italy

09/05/2023 86 Version 0.4


09/05/2023 87 Version 0.4


7.7 Netherlands

09/05/2023 88 Version 0.4


09/05/2023 89 Version 0.4


7.8 Romania

09/05/2023 90 Version 0.4


09/05/2023 91 Version 0.4


7.9 Sweden

09/05/2023 92 Version 0.4

D3.1 · Web viewSiemens HiPath 4000; a CTI server that manages the call queues to the operators and...

Documents

Transcript of D3.1 · Web viewSiemens HiPath 4000; a CTI server that manages the call queues to the operators and...