D3.1 - Europa



Version number:Version 0.4Main author:Dissemination level:PULead contractor:ERTICO – ITS EuropeDue date:29.02.2012Delivery date:Delivery date updated documentleftcenterD3.1 Pilot operation preparation report Page left intentionally blankControl sheet Version historyVersion DateMain authorSummary of changes0.4NameDatePreparedReviewedAndy Rooke DATE \@ "dd/MM/yyyy" 21/02/2012AuthorizedCirculationRecipientDate of submissionProject partnersEuropean CommissionTable of contents TOC \o "1-3" \h \z \u 1Terms and abbreviations PAGEREF _Toc317610259 \h 82Introduction PAGEREF _Toc317610260 \h 92.1Purpose of Document PAGEREF _Toc317610261 \h 92.2Structure of Document PAGEREF _Toc317610262 \h 92.3HeERO Contractual References PAGEREF _Toc317610263 \h 93National pilot structure PAGEREF _Toc317610264 \h 113.1Croatia PAGEREF _Toc317610265 \h 113.1.1Short description PAGEREF _Toc317610266 \h 113.1.2Involved parties PAGEREF _Toc317610267 \h 113.2Czech Republic PAGEREF _Toc317610268 \h 143.2.1Short description PAGEREF _Toc317610269 \h 143.2.2Involved parties PAGEREF _Toc317610270 \h 163.3Finland PAGEREF _Toc317610271 \h 163.3.1Short description PAGEREF _Toc317610272 \h 163.3.2Involved parties PAGEREF _Toc317610273 \h 213.4Germany PAGEREF _Toc317610274 \h 223.4.1Short description PAGEREF _Toc317610275 \h 223.4.2Involved parties PAGEREF _Toc317610276 \h 333.5Greece PAGEREF _Toc317610277 \h 343.5.1Short description PAGEREF _Toc317610278 \h 343.5.2Involved parties PAGEREF _Toc317610279 \h 353.6Italy PAGEREF _Toc317610280 \h 363.6.1Short description PAGEREF _Toc317610281 \h 363.6.2Involved parties PAGEREF _Toc317610282 \h 373.7Romania PAGEREF _Toc317610283 \h 373.7.1Short description PAGEREF _Toc317610284 \h 373.7.2Involved parties PAGEREF _Toc317610285 \h 413.8Netherlands PAGEREF _Toc317610286 \h 423.8.1Involved parties PAGEREF _Toc317610287 \h 423.9Sweden PAGEREF _Toc317610288 \h 433.9.1Short description PAGEREF _Toc317610289 \h 433.9.2Involved parties PAGEREF _Toc317610290 \h 434Case file data PAGEREF _Toc317610291 \h 434.1Croatia PAGEREF _Toc317610292 \h 434.2Czech Republic PAGEREF _Toc317610293 \h 444.3Finland PAGEREF _Toc317610294 \h 444.4Germany PAGEREF _Toc317610295 \h 454.5Greece PAGEREF _Toc317610296 \h 454.6Italy PAGEREF _Toc317610297 \h 464.7Netherlands PAGEREF _Toc317610298 \h 474.8Romania PAGEREF _Toc317610299 \h 484.9Sweden PAGEREF _Toc317610300 \h 485General workflow PAGEREF _Toc317610301 \h 495.1Croatia PAGEREF _Toc317610302 \h 495.1.1Laboratory eCall T&V PAGEREF _Toc317610303 \h 515.1.2eCall communication T&V PAGEREF _Toc317610304 \h 515.1.3SOP testing and verification PAGEREF _Toc317610305 \h 525.1.4Position estimation for eCall T&V PAGEREF _Toc317610306 \h 535.2Czech Republic PAGEREF _Toc317610307 \h 545.2.1eCall reception and visualisation PAGEREF _Toc317610308 \h 545.2.2Event form opening PAGEREF _Toc317610309 \h 555.2.3Proposal of data interpretation PAGEREF _Toc317610310 \h 555.2.4Process automation PAGEREF _Toc317610311 \h 555.2.5GIS visualisation PAGEREF _Toc317610312 \h 565.2.6Manual classification PAGEREF _Toc317610313 \h 565.2.7Event position determination PAGEREF _Toc317610314 \h 565.2.8Regionalisation PAGEREF _Toc317610315 \h 565.2.9Additional information PAGEREF _Toc317610316 \h 565.2.10Event saving and dispatch PAGEREF _Toc317610317 \h 565.2.11Request SEND MSD PAGEREF _Toc317610318 \h 575.2.12PSAP Call back PAGEREF _Toc317610319 \h 575.3Finland PAGEREF _Toc317610320 \h 605.4Germany PAGEREF _Toc317610321 \h 615.5Greece PAGEREF _Toc317610322 \h 635.6Italy PAGEREF _Toc317610323 \h 655.7Netherlands PAGEREF _Toc317610324 \h 655.8Romania PAGEREF _Toc317610325 \h 675.8.1eCall reception and visualisation PAGEREF _Toc317610326 \h 675.8.2Event form opening (case folder) PAGEREF _Toc317610327 \h 685.8.3Collecting supplementary data PAGEREF _Toc317610328 \h 685.8.4Transfer the eCall to agencies PAGEREF _Toc317610329 \h 685.8.5Request SEND MSD PAGEREF _Toc317610330 \h 685.8.6PSAP Call-back PAGEREF _Toc317610331 \h 695.9Sweden PAGEREF _Toc317610332 \h 696Operation timetable PAGEREF _Toc317610333 \h 696.1Croatia PAGEREF _Toc317610334 \h 696.2Czech Republic PAGEREF _Toc317610335 \h 716.3Finland PAGEREF _Toc317610336 \h 726.4Germany PAGEREF _Toc317610337 \h 736.5Greece PAGEREF _Toc317610338 \h 736.6Italy PAGEREF _Toc317610339 \h 746.7Netherlands PAGEREF _Toc317610340 \h 756.8Romania PAGEREF _Toc317610341 \h 766.9Sweden PAGEREF _Toc317610342 \h 767Annex 1 PAGEREF _Toc317610343 \h 777.1Croatia PAGEREF _Toc317610344 \h 787.2Czech Republic PAGEREF _Toc317610345 \h 797.3Finland PAGEREF _Toc317610346 \h 817.4Germany PAGEREF _Toc317610347 \h 827.5Greece PAGEREF _Toc317610348 \h 847.6Italy PAGEREF _Toc317610349 \h 857.7Netherlands PAGEREF _Toc317610350 \h 877.8Romania PAGEREF _Toc317610351 \h 897.9Sweden PAGEREF _Toc317610352 \h 91Figures TOC \h \z \c "Figure" Figure 1: eCall Pilot Site Architecture (Czech Republic) PAGEREF _Toc317610353 \h 14Figure 2: Pilot System Architecture PAGEREF _Toc317610354 \h 18Figure 3: Indagon MTT 130 IVS PAGEREF _Toc317610355 \h 21Figure 4: eCall pilot system architecture (Germany) PAGEREF _Toc317610356 \h 23Figure 5: eCall Test and Development Centre (Germany) PAGEREF _Toc317610357 \h 23Figure 6: eCall Server system overview (Germany) PAGEREF _Toc317610358 \h 26Figure 7: Detailed Database Structure (Germany) PAGEREF _Toc317610359 \h 27Figure 8: Continental IVS Block Diagram with interfaces (Germany) PAGEREF _Toc317610360 \h 31Figure 9: S1nn IVS System Overview (Germany) PAGEREF _Toc317610361 \h 32Figure 10: S1nn IVS module (Germany) PAGEREF _Toc317610362 \h 33Figure 11: eCall Pilot Architecture (Greece) PAGEREF _Toc317610363 \h 35Figure 12: eCall Pilot Architecture (Romania) PAGEREF _Toc317610364 \h 39Figure 13: eCall Pilot Architecture (Netherlands) PAGEREF _Toc317610365 \h 42Figure 14: eCall Operational Workflow (Croatia) PAGEREF _Toc317610366 \h 50Figure 15: Laboratory T&V Workflow (Croatia) PAGEREF _Toc317610367 \h 51Figure 16: eCall Communication T&V Workflow (Croatia) PAGEREF _Toc317610368 \h 52Figure 17: Position estimation for eCall T&V (Croatia) PAGEREF _Toc317610369 \h 54Figure 18: eCall Operational Workflow (Czech Republic) PAGEREF _Toc317610370 \h 58Figure 19: eCall reception and handling – detailed description (Czech Republic) PAGEREF _Toc317610371 \h 59Figure 20: PSAP Structure (Finland) PAGEREF _Toc317610372 \h 60Figure 21: eCall Operation Workflow (Germany) PAGEREF _Toc317610373 \h 62Figure 22: eCall Operational Workflow (Greece) PAGEREF _Toc317610374 \h 64Figure 23: eCall Operational Workflow (Italy) PAGEREF _Toc317610375 \h 65Figure 24: eCall Operational Workflow (Netherlands) PAGEREF _Toc317610376 \h 66Figure 25: eCall Operational Workflow (Romania) PAGEREF _Toc317610377 \h 67Figure 26: Operational timetable (Croatia) PAGEREF _Toc317610378 \h 71Figure 27: Operational timetable (Czech Republic) PAGEREF _Toc317610379 \h 71Figure 28: Operational timetable (Finland) PAGEREF _Toc317610380 \h 72Figure 29: Operational timetable (Germany) PAGEREF _Toc317610381 \h 73Figure 30: Operational timetable (Greece) PAGEREF _Toc317610382 \h 73Figure 31: Operational timetable (Italy) PAGEREF _Toc317610383 \h 74Figure 32: Operational timetable (Netherlands) PAGEREF _Toc317610384 \h 75Figure 33: Hazardous Goods Vehicles Timetable (Netherlands) PAGEREF _Toc317610385 \h 75Tables TOC \h \z \c "Table" Table 1: Involved Parties (Finland) PAGEREF _Toc317610386 \h 21Table 2: Test parameters that can be configured (Germany) PAGEREF _Toc317610387 \h 29Table 3: Involved parties (Germany) PAGEREF _Toc317610388 \h 33Table 4: Involved parties (Greece) PAGEREF _Toc317610389 \h 35Table 5: Involved parties (Romania) PAGEREF _Toc317610390 \h 41Table 6: Case file data (Croatia) PAGEREF _Toc317610391 \h 43Table 7: Case file data (Czech Republic) PAGEREF _Toc317610392 \h 44Table 8: Case File Data (Finland) PAGEREF _Toc317610393 \h 45Table 9: Case file Data (Germany) PAGEREF _Toc317610394 \h 45Table 10: Case file Data (Greece) PAGEREF _Toc317610395 \h 45Table 11: Case File Data (Italy) PAGEREF _Toc317610396 \h 46Table 12: Case file Data (Netherlands) PAGEREF _Toc317610397 \h 47Table 13: Case file Data (Romania) PAGEREF _Toc317610398 \h 48Table 14: Laboratory eCall T&V (Croatia) PAGEREF _Toc317610399 \h 51Table 15: eCall Communication T&V (Croatia) PAGEREF _Toc317610400 \h 52Table 16: eCall SOP T&V (Croatia) PAGEREF _Toc317610401 \h 53Terms and abbreviationsAbbreviationDefinitionCIPCompetitiveness and Innovation Framework ProgrammeECEuropean CommissionTermDefinitionProcessThe method of operation in any particular stage of development of the material part, component or assembly involved.IntroductionPurpose of DocumentThe purpose of this document is to describe the Pilot operation in each Members State, what will be tested and who is involved.Structure of DocumentHeERO Contractual ReferencesHeERO 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-GonzalezEUROPEAN COMMISSIONDG INFSO Office: BU 31 – 4/50B - 1049 BrusselsTel: +32 296 2188 E-mail: Emilio.Davila-Gonzalez@ec.europa.euTwo other Project Officer will follow the HeERO project:Eva Boethius (eva.boethius@ec.europa.eu)Pierpaolo Tona (Pierpaolo.TONA@ec.europa.eu)Address to which all deliverables and reports have to be sent: Emilio Davila-GonzalezEUROPEAN COMMISSIONDG INFSO BU 31 – 4/50B - 1049 BrusselsTel: +32 296 2188by mail: Emilio.Davila-Gonzalez@ec.europa.euAny 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 BrusselsBelgiumby electronic mail: INFSO-ICT-PSP-270906@ec.europa.euNational pilot structureCroatiaShort descriptionPlease 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.Involved partiesNational 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.Croatian Automobile Club (HAK)“Hrvatski autoklub" - HAK is the Croatian National Automobile Club, an association of drivers and local automobile clubs, a non-profit and nongovernmental organization. It was established in 1906 and its activities focus conditions, providing touring information, driver education, motor vehicle inspection etc. HAK has been a pioneer in introducing road and travel information in the South East Europe region. At this moment, there are more than 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 tasksHAK 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.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 tasksDuring 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 providing laboratory for eCall verification. ENT will also contribute to the verification activities and to the certification analysis.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.Czech RepublicShort descriptionHeERO 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 SEQ Figure \* ARABIC 1: eCall Pilot Site Architecture (Czech Republic)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 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.PSAP testing platform integrates:2 OmniPCX Enterprise PBX (R 10) of Alcatel LucentCCD (Call Centre Distribution)Genesys solution - TServer (R 7.6.003.08)1 CCIVR server on Windows 2008 Server1 PSAP Application Server on Linux Red Hat 6Call taker application for 7 operatorsVIN decoderCommunication module with interfaces to external systemsGISThe 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:MSD handlingpresentation and visualization of MSD and decoded VIN in call taker applicationvisualization of incident location in GISimplementation of VIN decoder interfacetransmission of MSD and VIN data to the Emergency Rescue systems (Fire Rescue Service, Police and Ambulance) transmission of eCall data into the Traffic Management Systemimplementation of TPS interfaceFunctional modules:eCall handling (call reception, resend MSD, call-back)eCall data distributioneCall data visualisation (Event form, GIS map)VIN decoder interfaceTraffic mgt interfaceTPS interfaceTDS handlingInvolved partiesFinlandShort descriptionIntroductionFinland 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. 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.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. Figure SEQ Figure \* ARABIC 2: Pilot System ArchitectureThe 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 systemseCall pilot system control and administrator’s UI.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. 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). 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. eCall pilot system control and administrator’s UIDuring 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.eCall clients to be used in the tests, first phase requirementsThe 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 15722opening 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. eCall IVS systemsAt least two different domestic IVS prototypes will be tested, and probably couple of foreign. Gecko systems / geckosystems.fiSystem descriptionTokay 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 supported32 channel GPS/GLONASS/GALILEO/COMPASS/SBAS and Mobile (Cell ID)trackingQuad-band modem with 2 SIM card places, upgraded to standard in-band modemCustomizable firmware (Python)10 I/O ports for telemetry (analogue/digital)Internal backup battery (optional)RS-232 output for NMEA 0183 dataOperating temperature from -40 to +85 °CRobust aluminium casingIndagon / indagon.fiIndagon 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 mobile communication. They have aluminium casing, Operative temperature -40 to +65 °C. Positioning accuracy is <2 m.Figure SEQ Figure \* ARABIC 3: Indagon MTT 130 IVSInvolved partiesTable SEQ Table \* ARABIC 1: Involved Parties (Finland)NameRoleHeERO ConsortiumMinistry of Transport and CommunicationsMS leaderYesEmergency Rescue Centre AdministrationResponsible of PSAP system development, PSAP training, PSAP test environmentYesVTTResponsible for operating the Finnish National Pilot, test bed functions and testsYesGecko SystemsIVS vendorsubcontractorIndagonIVS vendorsubcontractorDigiaPSAP software developersubcontractorElisaMNO flag testsNo (National associated partner)SoneraMNO flag testsNo (National associated partner)FICORAMNO authorityNo (National associated partner)Traffic Safety AgencyVINNo (National associated partner)SiemensPSAP software vendor (ELS system)No GermanyShort descriptionIntroductionThis 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.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:Figure SEQ Figure \* ARABIC 4: eCall pilot system architecture (Germany)eCall pilot system componentseCall 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 SEQ Figure \* ARABIC 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 GermanyComplete, easy-to-use interface for PSAP simulation, con- figuration and evaluation of test casesStand-alone system or integrated system – MS Windows client or web interfaceTest 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 controlSupports 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 machinesAccess from public networks possibleeCall 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 InternetMultilingual: Language selection at program start The technical requirements for the this eCall Test and Development Centre areISDN standard connection or and VoIP Telephony SystemStandard Intel computers for the Application Server (including an ISDN card and Linux operating system) and the eCall Client Application (with Windows operating system, XP SP2 or higher, or Web-based using Internet Explorer, Firefox, Chrome or Safari web browser)Internet connection for access to Google MapsTo 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. Figure SEQ Figure \* ARABIC 6: eCall Server system overview (Germany)Database StructureAll 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. Figure SEQ Figure \* ARABIC 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. callsFor 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. data_setsBecause 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. logsEvery log message by any eCall worker is saved to this table. phone_vehicle_linksThis table saves links between phones and vehicles. phonesThis tables saves data about phones, most notably the MSISDN and whether the phone is currently active or not. preferencesThis 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. test_case_vehicle_linksThis table saves links between test cases and vehicles. test_casesThis table contains all user defined test cases with names. test_parametersThis 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. vehiclesThis 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. Implementation Details of Software ComponentsBecause of different requirements the software components use quite varying technologies when compared to each other. eCall masterImplementation language is Ruby. Uses threads to handle multiple worker processes simultaneously. Uses the ActiveRecord ORM framework to access the database. eCall workerImplementation 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. eCall test centre clientImplementation language is C#- using the .NET framework. List of Available Test ParametersThe following test parameters can be configured per test case. Table SEQ Table \* ARABIC 2: Test parameters that can be configured (Germany)Parameter nameTypeLegal valuesDefault valueRemarksAccept callboolTrue / FalseTrueIf this is set to true, a caller gets busy signal Hang up call afterint0 – 3600 seconds0, means neverHang up after X secondsAL-Ack valueint0 – 15 0, means ?Positive Ack“Request MSD afterint0 – 3600 seconds0, means neverMeasured from call beginAbort after initiationboolTrue / FalseFalseDisconnects in-band modem upon INITIATION signal Number of LL-Acksint0 – 20 40 implies deactivation of in-band modemNumber of AL-Acksint0 – 20 40 implies deactivation of in-band modemTimer T4 (wait for INITIATION signal)int0 – 20 seconds2According to CEN/TC-278 (HLAP) Annex ATimer T8 (MSD max reception time)int0 – 120 seconds20According to CEN/TC-278 (HLAP) Annex ACall back afterint0 – 3600 seconds0, means neverX 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.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.ContinentalBlock Diagram with InterfacesThe block diagram gives an overview of Continental’s solution of an eCall-module.Figure SEQ Figure \* ARABIC 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 ModulesNot yet definedUser InterfaceThe 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.S1nnS1nn ECall System: Technical OverviewBased on NXP ATOP Telematics Module Interface- and application processorRuns latest ECall modemGPS and GSM connectivityInternal GSM + GPS antennaAutomotive grade power supplyFigure SEQ Figure \* ARABIC 9: S1nn IVS System Overview (Germany)Fakra interface for external antennasSIM slotCar interface including: Microphone inputSpeaker outputLED outputsButton input (for manual ECall)Voltage supplyCAN interfaceDebug interfacesCompact design Approx. 13cm by 6.5cm by 4cm Rigid housingFigure SEQ Figure \* ARABIC 10: S1nn IVS module (Germany)User Interface for HeERO:Button module for manual ECall and status LEDsSpeaker and microphoneInvolved partiesTable SEQ Table \* ARABIC 3: Involved parties (Germany)NameRoleHeERO ConsortiumITS Niedersachsen GmbHProject Management (acts for the German Ministry of Transport)YesOECON Products & Services GmbHResponsible for operating the German National Pilot, PSAP assistance and training, Field test assistanceYesADAC e.V.PSAP assistance and training, Field test assistanceYesS1nn GmbHIVS vendorYesNXPChipset Vendor, IVS prototypesYesContinental GmbHOVS vendorYesFlughafentransfer Hannover GmbHTest Fleet operatorYesNavCert GmbHTest Suites, Validation of Field Test ResultsYesLeitstelle OldenburgPSAPNo (Associated Partner)Leitstelle BraunschweigPSAPNo (Associated Partner)GreeceShort descriptionThe 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.Figure SEQ Figure \* ARABIC 11: eCall Pilot Architecture (Greece)Involved partiesTable SEQ Table \* ARABIC 4: Involved parties (Greece)NameRoleHeERO ConsortiumHellenic Ministry of Infrastructure, Transport and NetworksProject Management YesInstitute of Communication and Computer Systems Consultant, Technical Specifications for the tender procedures, Will overview the field trialsNoGeneral Secretariat of Civil ProtectionResponsible for PSAP and emergency services operation NoHellenic MNOsThey are going to route the eCalls to the appropriate destination pointNoHellenic Telecommunications Organisation (fixed line operator)It will the eCalls within the PSTN to the appropriate destination point (Call Centre)NoHellenic PoliceWill participate in the field trialNoHellenic Fire BrigadeWill participate in the field trialNoHellenic Emergency Medical Help Services (EKAB)Will participate in the field trialNoItalyShort descriptionItalian 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.Involved partiesNameRoleHeERO ConsortiumPresidenza del Consiglio dei Ministri (PCM)National Administration & coordinationPartnerMagneti Marelli S.P.A. (MM)IVSPartnerCentro Ricerche FIAT S.C.p.A. (CRF)IVS and carPartnerAutomobile Club d'Italia (ACI)User added service & Road OperatorPartnerTELECOM ITALIA S.p.A (TI)MNO & 112 fixed networkPartnerAzienda Regionale Emergenza Urgenza (AREU)PSAP – Current EU 112 in VaresePartnerRomaniaShort descriptionThe 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-PSAPsAll the centres are interconnected and are working on the same software and hardware platforms, exchanging data and calls as needed. Voice and data communication are integrated and synchronized on the whole process of handling an emergency call (from the time the call is received until the resources are dispatched). It consists of the following subsystems for the 112 emergency calls management:112 Application (data and VoiP);F2CA ver. 1.3 (GIS system);APD Coordinator 7 (AVLS);SL ver. 1.0 (mobile positioning).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.Figure SEQ Figure \* ARABIC 12: eCall Pilot Architecture (Romania)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).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;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;Involved partiesTable SEQ Table \* ARABIC 5: Involved parties (Romania)NameRoleHeERO ConsortiumSTS (Special Telecommunication Service)Administrator of 112 systemYesITS Romania (Intelligent Transport System)Project CoordinatorYesRNCMNR (National Company of Motorways and National Roads in Romania)Third Party SystemYesUTI Systems SAMSD decoding interface, VIN decoder and the interface with EUCARISYesRohde&Schwarz Topex SAeCall Modem developer and telephony integration in the existing system NoELSOL (Electronic Solution)Operational procedures, NCMNRR interfaceYesTeamNet International SAMSD processing interface, 3rd party interface, eCall solution integratorNoNetherlands3.7.1Short descriptionIn 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 SEQ Figure \* ARABIC 13: eCall Pilot Architecture (Netherlands)Involved partiesRijkswaterstaat: project leaderKorps landelijke politiediensten (NPA): project partnerKPN n.v.: subcontractorVoorziening tot samenwerking Politie Nederland: subcontractorVeiligheidsregio Rotterdam-Rijnmond: pilot region Rijksdienst voor het Wegverkeer: EUCARIS VIN supplierFleet-owners: to be selected.SwedenShort descriptionInvolved partiesCase file dataThe 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.Data112 PSAPPoliceFire brigadeAmbulanceNameXTelephone numberXAddressEtc.CroatiaData 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 SEQ Table \* ARABIC 6: Case file data (Croatia)Data112 PSAPPoliceFire brigadeAmbulanceName XXXTelephone numberXXXXDescriptionXXXXAccident locationXXXXVehicle orientationXXXXNumber of people injuredXXXFireXXXXAre injured people trapped in vehicleXXXDangerous goodsXXXNumber of vehicles involvedXXCzech RepublicTable SEQ Table \* ARABIC 7: Case file data (Czech Republic)Data112 PSAPPoliceFire brigadeAmbulanceNameXXXXTelephone number – caller contact XXXXLocation of the callerXEvent locationXXXXCar data – type, model, year of productionXXXAccident severityXXFinlandFinnish PSAPs collect the following data from the caller:Table SEQ Table \* ARABIC 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 systemPhone number, address (personal identification number), location of the cell phoneGermanyIn 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 SEQ Table \* ARABIC 9: Case file Data (Germany)CallerName, Address, telephone numberCarSign, Model, Colour, damageAccidentLocation, situation description, Risk (gasoline running out etc.), Number of affected carsCar occupantsInjuries, pre-existing conditions, pregnancyGreeceTable SEQ Table \* ARABIC 10: Case file Data (Greece)Data112 PSAPPoliceFire brigadeEmergency Medical HelpVoice communicationXTelephone numberXEmergency Agency called XX (if another one is needed)X (if another one is needed)Location of the telephone (antenna coordinates, azimuth, estimated distance from antenna)XNames and IDs of involved personsXΧXComplete vehicle data (number of plates, model, colour, number of licence)XXAccident location and dateXXXAccident type and descriptionXInjuries per involved personXDamagesXData 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)XTransfer point of involved personsXItalyTable SEQ Table \* ARABIC 11: Case File Data (Italy)Data112 PSAPPoliceFire brigadeAmbulanceNameXXXXTelephone numberXXXXAddressXXXXEvent CategoryXXXXBrief Event DescriptionXXXXGeographical PositionXXXXClinical DataXCasualty DescriptionXXNetherlandsIn the current PSAP voice and data are recorded. Actual operational data can be viewed by a supervisor or real time on performance monitors. Historical data is available in a management information system. At the 112 PSAP data is logged automatically. Police, Fire Brigade and Ambulance have to log manual in their incident report system.The data collected by the 112 PSAP call taker and by the Emergency Agencies (relevant only for mobile calls):Table SEQ Table \* ARABIC 12: Case file Data (Netherlands)Data112 PSAPPoliceFire brigadeAmbulanceNameXXXTelephone numberXXXXAddressXXXLocation-informationCell-IDXXXCall-historyXRomaniaTable SEQ Table \* ARABIC 13: Case file Data (Romania)DataRole112 PSAPPoliceFire brigadeAmbulanceFree textShort description of incidentXXXXIncident addressLocality, municipality, Street, street no. XXXXResponsibility areaAgencies responsibility areaXXXCaller informationName, Surname, telephone number, addressXXXXVictim informationName, Surname, age, sex, XXXXTelephone locationCell id, Sector id positionXXXXCase indexIncident Classification XXXXCase questionsHelp operator to understand the incident typeXXXMSDAll fields according to standardsXXXXEUCARISAll fields according to standardsXXXXSwedenTo be addedGeneral workflowPlease 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.CroatiaFigure SEQ Figure \* ARABIC 14: eCall Operational Workflow (Croatia)Laboratory eCall T&VLaboratory 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 SEQ Table \* ARABIC 14: Laboratory eCall T&V (Croatia)CodeNo. of IVS units involvedNo. of IVS units in roamingeCall initiationNo. of repeated initiationsNo. of testsL110A0> 1000L211A0> 1000L310M0> 1000L411M0> 1000L510M3> 1000L611M3> 1000L710A3> 1000Figure SEQ Figure \* ARABIC 15: Laboratory T&V Workflow (Croatia)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 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 SEQ Table \* ARABIC 15: eCall Communication T&V (Croatia)CodeLocationNo. of vehicles involvedNo. of vehicles in roamingeCall initiationNo. of testsR1Zagreb Centre - urban21M> 100R2Zagreb Ring/Motorway -rural31M> 100R3Zagreb Ring/Motorway - rural10A> 1000R4Local road (near Zagreb) - rural10A> 1000Figure SEQ Figure \* ARABIC 16: eCall Communication T&V Workflow (Croatia)SOP testing and verificationSOP 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.Table SEQ Table \* ARABIC 16: eCall SOP T&V (Croatia)CodeLocationNo. of vehicles involvedNo. of vehicles in roamingeCall initiationNo. of testsS1Zagreb Centre – urban31M4S2Zagreb Ring/Motorway – rural31A4Position estimation for eCall T&VThere 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.Figure SEQ Figure \* ARABIC 17: Position estimation for eCall T&V (Croatia)Czech RepubliceCall reception and visualisationeCall 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. Event form openingOperator 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.Proposal of data interpretationOperator 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 collisioneCall was activated manually – it can be ether traffic collision or other type of incident eCall is test call – event classification is predefined as technological testif position credibility is impeached, then automatisms are stoppedProcess automation Operator can take control of status of all started automatisms. Automatic matching caller position with event positionControl bits:Automatic activation = Yes Position Can Be Trusted = True Automatic classificationControl bits:Automatic activation = Yes Test call = NoSystem automatically set up predefined classification “traffic accident” for all rescue forces (Fire Rescue, Ambulance, and Police)Automatic activation = Yes Test call = YesSystem automatically set up predefined classification “technological test”.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.GIS visualisation Call taker application sends position and direction information to the GIS.Manual classificationIn case that process of automatic classification is deactivated, operator takes out the classification manually from the menu.Event position determination By means of line topography if probable road is knownIf 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 topographyCall taker application switches over topography folds according to the event position determination RegionalisationAfter 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.Additional informationIf 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)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.Request SEND MSDProcedure description:Operator evaluates the data in the MSD are inadequate, or otherwise applying the update (e.g. corrupted data, the position is marked as unreliable).Operator notifies the caller that voice communication will be interrupted.Operator presses "Request MSD" button.In call sub-form a running MSD query is signalisedcall 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 ringingthis call is indicated by the Call Agent as a call from the previously adopted and broken eCalldata 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 restoredOperator notifies the caller in distress to restore voice communication.PSAP Call backThis 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:Operator uses the option from the context menu item above telephone number in the property grid with call properties and chooses "Call back" option.After creating a connection is set up, application automatically connects an outgoing call to the event. Operator has dispatcher has now again possibility to seek re-sending MSD.MSD received will be appended to the original call.Figure SEQ Figure \* ARABIC 18: eCall Operational Workflow (Czech Republic)Figure SEQ Figure \* ARABIC 19: eCall reception and handling – detailed description (Czech Republic) FinlandIn 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 The PSAP receives an incoming Call with the eCall flagThe PSAP eCall switch hardware receives the MSD and sends it to the system The system decodes the MSD [and adds VIN information]The PSAP Operator accepts the call on the phoneThe operator’s PSAP software retrieves the MSD information which is displayed on the screenThe operator talks to the caller to find out additional information about injuries and other background informationThe PSAP immediately notifies of the accident for the needed rescue forces and medical units and police 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 SEQ Figure \* ARABIC 20: PSAP Structure (Finland)GermanyIn 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 The PSAP receives an incoming Call at the eCall phone lineThe PSAP eCall switch hardware receives the MSD and sends it to the eCall CentreThe eCall Centre decodes the MSD and adds EUCARIS and VIN informationIn the PSAP, the voice call is transmitted to the internal PBXThe PSAP Operator accepts the call on the phoneThe operator’s PSAP software retrieves the MSD information from the eCall Centre and displays it on the screenThe 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)The Centre immediately notifies of the accident the following:Emergency Medical Dispatcher of the Emergency Medical Service,Operational Communications Centre of the Police Administration,Operational centre of the legal entity in charge of maintenance and management of the highway section on which the accident happened,Competent fire fighting unit.TMCWhen the forces in the field cannot cope with the situation, they may require additional teams either through their internal communications or through the Centre.In case of road accidents involving a large number of fatalities, victims and major damage, the PSAP notifies other PSAPs.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 SEQ Figure \* ARABIC 21: eCall Operation Workflow (Germany)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: The eCall Call Centre receives an incoming eCallThe PSAP software decodes the MSD and queries the VIN database. The voice call is transferred to a PSAP operator and the decoded MSD data and relevant vehicle data are displayed at the screen. If communication with a vehicle passenger is feasible, the PSAP operator evaluates which Emergency Services are needed and notifies them.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.After the first rescuer arrives at the incident location, he/she estimates the severity and informs the Emergency Service Centre.The rescue operation is performed and the Emergency Service Centre is notified about the result. Emergency forces return to their Operation Centres.Figure SEQ Figure \* ARABIC 22: eCall Operational Workflow (Greece)Italy Figure SEQ Figure \* ARABIC 23: eCall Operational Workflow (Italy)NetherlandsThis 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 SEQ Figure \* ARABIC 24: eCall Operational Workflow (Netherlands)RomaniaFigure 25: eCall Operational Workflow (Romania)eCall reception and visualisationeCall 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. 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).Collecting supplementary dataAfter 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).Transfer the eCall to agenciesAfter 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.Request SEND MSDProcedure description:Operator evaluates the data in the MSD as inadequate, corrupted data, position not presented, position changed.Operator notifies the caller that the voice communication will be interrupted.Operator presses "Request MSD" button from the GIS client interface.A new MSD is received and during that, the alert voice message is played.Operator notifies the caller that the voice communication is restored.PSAP Call-backThis 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:Operator uses the option call from contact book in the 112 Application client interface.IVS answer.Operator has now again possibility to seek re-sending MSD.SwedenOperation 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.CroatiaOperational 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 testingIn 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 SEQ Figure \* ARABIC 26: Operational timetable (Croatia)Czech RepublicFigure 27: Operational timetable (Czech Republic)FinlandFigure SEQ Figure \* ARABIC 28: Operational timetable (Finland)GermanyFigure SEQ Figure \* ARABIC 29: Operational timetable (Germany)Greece Figure SEQ Figure \* ARABIC 30: Operational timetable (Greece)Italy Figure SEQ Figure \* ARABIC 31: Operational timetable (Italy)NetherlandsFigure SEQ Figure \* ARABIC 32: Operational timetable (Netherlands)Figure SEQ Figure \* ARABIC 33: Hazardous Goods Vehicles Timetable (Netherlands)RomaniaDecember 2011 – start operatingJanuary 2012 – analyze / collecting dataFebruary 2012 – adaptation / modification of the current work proceduresMarch – April 2012 – operatingJune 2012 - analyze / collecting dataJuly 2012 – analyze KPIAugust 2012 – optimize workflowSeptember 2012 – finalizing the work methodology and work proceduresSwedenAnnex 1CroatiaCzech RepublicFinlandGermanyGreeceItalyNetherlandsRomaniaSweden ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download