Version number: Version 4 Main author



Download 387.63 Kb.
Page10/10
Date29.04.2017
Size387.63 Kb.
#16653
1   2   3   4   5   6   7   8   9   10

5.2Czech Republic

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

5.2.2Event 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.3Proposal 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.4Process automation


Operator can take control of status of all started automatisms.

5.2.4.1Automatic matching caller position with event position


Control bits:

Automatic activation = Yes

Position Can Be Trusted = True

5.2.4.2Automatic 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”.

5.2.4.3Automatic 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.5GIS visualisation


Call taker application sends position and direction information to the GIS.

5.2.6Manual classification


In case that process of automatic classification is deactivated, operator takes out the classification manually from the menu.

5.2.7Event 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.8Regionalisation


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.9Additional 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.10Event 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.

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

  1. Operator notifies the caller in distress to restore voice communication.

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

Figure : eCall Operational Workflow (Czech Republic)



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




5.3Finland


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 : PSAP Structure (Finland)


5.4Germany


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:

  1. Emergency Medical Dispatcher of the Emergency Medical Service,

  2. Operational Communications Centre of the Police Administration,

  3. Operational centre of the legal entity in charge of maintenance and management of the highway section on which the accident happened,

  4. Competent fire fighting unit.

  5. TMC

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

  2. In case of road accidents involving a large number of fatalities, victims and major damage, the PSAP notifies other PSAPs.

  3. 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 : eCall Operation Workflow (Germany)


5.5Greece


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.

greek_workflow_wp3

Figure : eCall Operational Workflow (Greece)


5.6Italy


c:\users\rares\documents\italy.bmp

Figure : eCall Operational Workflow (Italy)


5.7Netherlands


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.



Figure : eCall Operational Workflow (Netherlands)


5.8Romania


Figure : eCall Operational Workflow (Romania)


5.8.1eCall 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 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.2Event 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.3Collecting 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.4Transfer 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.5Request 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.

  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.6PSAP 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.9Sweden

6Operation 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.1Croatia


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



Figure : Operational timetable (Croatia)


6.2Czech Republic


c:\users\rares\desktop\image001.png

Figure : Operational timetable (Czech Republic)


6.3Finland


Figure : Operational timetable (Finland)



6.4Germany


Figure : Operational timetable (Germany)


6.5Greece


Figure : Operational timetable (Greece)



6.6Italy


Figure : Operational timetable (Italy)



6.7Netherlands


Figure : Operational timetable (Netherlands)



Figure : Hazardous Goods Vehicles Timetable (Netherlands)



6.8Romania


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




7Annex 1



7.1

7.2Croatia



7.3Czech Republic



7.4Finland



7.5Germany



7.6Greece




7.7Italy


c:\users\rares\documents\italy.bmp

7.8Netherlands



7.9Romania


c:\users\rares\desktop\ro workflow.jpg

7.10Sweden




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

Information and Communications Technologies Policy Support Programme (the “ICT PSP”)

Information Society and Media Directorate-General

Grant agreement no.: 270906



Pilot type A



Download 387.63 Kb.

Share with your friends:
1   2   3   4   5   6   7   8   9   10




The database is protected by copyright ©ininet.org 2024
send message

    Main page