Version number: Version 4 Main author



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

3.4Germany

3.4.1Short description

3.4.1.1Introduction


This report describes the detailed Hardware and Software implementation for HeERO in Germany. It also provides an implementation plan for the intended eCall pilot in Germany.

The implementation plan is based on the deliverable D2.2 (eCall Systems Functionalities’ Specification – eCall pilot Germany), which specifies the functionalities of the eCall pilot in Germany.

eCall development in Germany started in 2009, so there are currently several IVS boxes installed with earlier specification versions than the current 10.0. However, the German PSAP software will support these systems until they will have been upgraded to the latest version.

3.4.1.2eCall pilot system architecture


Unlike most other European countries, Germany has a very complicated PSAP infrastructure with currently about 270 PSAPs with big differences in technical infrastructure. The two selected PSAPs in Braunschweig and Oldenburg are well equipped but their software solution for the PSAP operators is completely different. Thus in 2010 the German HeERO team decided in preparation to the project, to develop a PSAP system that can be operated completely separately, but can be integrated during the project into existing software solutions. On the specification side, the German eCall PSAP solution is completely compliant to the latest eCall specification. It also supports earlier specifications for MSD, HLAP and 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:

firma:oecon:in arbeit:ecall_db_ordner:ecall testzentrale systembild_en.png

Figure : eCall pilot system architecture (Germany)


3.4.1.3eCall pilot system components

3.4.1.3.1eCall 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 : eCall Test and Development Centre (Germany)



The characteristics of this eCall Test and Development Centre are:

  • Supporting latest specifications in compliance with CEN and ETSI, certified by TÜV Süd Germany

  • Complete, easy-to-use interface for PSAP simulation, con- figuration and evaluation of test cases

  • Stand-alone system or integrated system – MS Windows client or web interface

  • Test cases can be selected per vehicle and per IVS. This allows to define special protocol behaviour, MSD treatment and In-band modem versions per IVS (per car)

  • Parameter set for HLAP and in-band modem for each test case variable for border and tolerance tests. This allows to modify the specified parameters but also to check whether IVS is specification compliant or not.

  • Databases for cars, telephone numbers and test cases to

  • Detailed event logs with direct link to Google maps to show eCall coordinates, instant delivery via email for success control

  • Supports up to 30 ISDN lines (depending on ISDN base interface and ISDN card)

  • Client-server based system: Linux Server, Windows or web based Client, running also in virtual machines

  • Access from public networks possible

  • eCall calls can be forwarded to existing telephone systems, VoIP phones or mobile phones, this allows completely separated instances for server and client environments. It also allows the server to run without any interference to existing 112 services in the PSAP, which is necessary until the eCall flag is established in Germany.

  • Public Safety Answering Point Controls (PSAP) for manual operation or fully automatic operation. This allows the server to run without any manual interference. After transmitting the MSD, the phone line is picked up and answered by a digital audio file. After 20 seconds the PSAP automatically hangs up the phone and ends the call.

  • MSD decoding and displaying the position in the digital map. Map data can be installed locally or accessed from Internet

  • Multilingual: Language selection at program start

The technical requirements for the this eCall Test and Development Centre are

  • ISDN standard connection or and VoIP Telephony System

  • Standard Intel computers for the Application Server (including an ISDN card and Linux operating system) and the eCall Client Application (with Windows operating system, XP SP2 or higher, or Web-based using Internet Explorer, Firefox, Chrome or Safari web browser)

  • Internet connection for access to Google Maps

To meet multi user requirements the German eCall PSAP server uses client-server architecture. The server is Linux based and uses a few existing open source software components. Asterisk is a software private branch exchange (PBX). It takes care of all ISDN call handling so that no CAPI programming is necessary in the development of new system components. Furthermore Asterisk provides an advanced rule based call forwarding system so it is possible to transfer calls to nearly arbitrary locations. That means it is possible to use either ISDN or IP phones for operator workstations. It is even possible to use mobile phones, though not recommended for obvious reasons.

There are three components that have to be developed to make the system work. The eCall test centre client is running at every operator’s workstation. It represents the main user interface to the whole system. The client gets all data from the server and sends all requests to the server as well. Main tasks are display of MSD values and configuration of test cases. The client is not responsible for the voice call. That means the transmission of audio data is completely delegated to either an actual hardware telephone or a soft phone running on the operator’s computer. This is one of main differences between the eCall test centre and the eCall demonstrator where one software component handled everything.

The other two components are called eCall-Master and eCall-Worker and are running on the server. The master is the system’s main component. When started it spawns a number of eCall-Worker processes that are responsible for call handling and operation of the eCall in-band modem. Each worker handles only one call at a time. So for n calls at least n worker processes are required.

The master maintains an inter process communication channel to each worker it has started. This channel is used in both directions. For instance the master can send a request to a worker to establish a MSD transmission from an IVS while a call is active after the operator gave the order by clicking a button in the test centre client. The worker on the other side primarily sends status updates concerning the current call that the worker is handling.

Besides taking care of the worker processes the master communicates with one or more test centre clients. A message passing system is used for this purpose. It is provided by RabbitMQ which is an open source implementation of the AMQP specification.

Figure : eCall Server system overview (Germany)


3.4.1.3.2Database Structure

All information that has to be persistent stored in a MySQL database. The only component accessing the database is the eCall master. Other components have to use the previously described interfaces to get data into or out of the database.

ecall_db

Figure : 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.


3.4.1.3.2.1calls

For every call one entry is saved in this table. Data includes beginning and end of call as well as to which vehicle the call is attributed.
3.4.1.3.2.2data_sets

Because more than one MSD can be transmitted in the course of one call this table is necessary to carry all MSD data. A MSD is saved in raw format as well as decoded.
3.4.1.3.2.3logs

Every log message by any eCall worker is saved to this table.
3.4.1.3.2.4phone_vehicle_links

This table saves links between phones and vehicles.
3.4.1.3.2.5phones

This tables saves data about phones, most notably the MSISDN and whether the phone is currently active or not.
3.4.1.3.2.6preferences

This table normally has only one entry that contains all global preferences that can be changed in the eCall test centre client UI. Columns contain email addresses to which call logs are being forwarded, the system’s call acceptance mode and the telephone numbers of the operator telephones.
3.4.1.3.2.7test_case_vehicle_links

This table saves links between test cases and vehicles.
3.4.1.3.2.8test_cases

This table contains all user defined test cases with names.
3.4.1.3.2.9test_parameters

This table contains all test parameters that were set by a user. Every parameter has a link to the containing test case in the test case table.
3.4.1.3.2.10vehicles

This table contains all vehicles that were either created by a user or were created automatically by the system because of an incoming call from that vehicle.
3.4.1.3.3Implementation Details of Software Components

Because of different requirements the software components use quite varying technologies when compared to each other.
3.4.1.3.3.1eCall master

Implementation language is Ruby. Uses threads to handle multiple worker processes simultaneously. Uses the ActiveRecord ORM framework to access the database.
3.4.1.3.3.2eCall worker

Implementation language is C. Uses a combination of SIP and RTP to transmit audio data to and from Asterisk. Integrated is the reference eCall in-band modem.
3.4.1.3.3.3eCall test centre client

Implementation language is C#- using the .NET framework.
3.4.1.3.3.4List of Available Test Parameters

The following test parameters can be configured per test case.

Table : Test parameters that can be configured (Germany)



Parameter name

Type

Legal values

Default value

Remarks

Accept call

bool

True / False

True

If this is set to true, a caller gets busy signal

Hang up call after

int

0 – 3600 seconds

0, means never

Hang up after X seconds

AL-Ack value

int

0 – 15

0, means „Positive Ack“




Request MSD after

int

0 – 3600 seconds

0, means never

Measured from call begin

Abort after initiation

bool

True / False

False

Disconnects in-band modem upon INITIATION signal

Number of LL-Acks

int

0 – 20

4

0 implies deactivation of in-band modem

Number of AL-Acks

int

0 – 20

4

0 implies deactivation of in-band modem

Timer T4 (wait for INITIATION signal)

int

0 – 20 seconds

2

According to CEN/TC-278 (HLAP) Annex A

Timer T8 (MSD max reception time)

int

0 – 120 seconds

20

According to CEN/TC-278 (HLAP) Annex A

Call back after

int

0 – 3600 seconds

0, means never

X seconds after hang up a call back to IVS is automatically established. Upon call back all other test parameters are getting ignored.

This description is an extract from the document “eCall Test Centre Server – Software Specification V0.9”, which describes the interfaces between Broker, Master and Client in detail.

3.4.1.4eCall IVS systems


In Germany, IVS systems will be handled as “black boxes”. This means the systems will undergo a validation, but the internal structure is not of interest.

However, the German system consists of either a NXP chipset (S1nn) or a Sagem chipset (Continental). The following two sections show the principle block structure of the S1nn and the Continental IVS. Further details are on behalf of Continental and S1nn.


3.4.1.4.1Continental

Block Diagram with Interfaces

The block diagram gives an overview of Continental’s solution of an eCall-module.



Figure : Continental IVS Block Diagram with interfaces (Germany)

The HW of the eCall-module is grouped into the sections Vehicle Interface / Communication, Network Access Device (NAD), Power and SIM. Network access will be realized on GSM-basis (2G).

Dimensions of the Modules

Not yet defined



User Interface

The modules will be connected to the cigarette lighter socket in the car for 12V power-supply and placed on the dashboard to get GPS-reception. For deploying eCalls it will be possible to send a configuration-SMS to the module. Thereby the module can be enabled to send automatic calls to PSAPs in determined intervals. Information about the calls will be stored in internal flash-memory. This data can be used for analysis-purposes. The modules can be stopped sending eCalls with another configuration-SMS.

As a second possibility single eCalls can be deployed by pressing a button on the module.

The status of the module can be recognized by means of the lighting schema of 2 LEDs.


3.4.1.4.2S1nn

S1nn ECall System: Technical Overview

  • Based on NXP ATOP Telematics Module

    • Interface- and application processor

    • Runs latest ECall modem

    • GPS and GSM connectivity

  • Internal GSM + GPS antenna

  • Automotive grade power supply

Figure : S1nn IVS System Overview (Germany)



  • Fakra interface for external antennas

  • SIM slot

  • Car interface including:

    • Microphone input

    • Speaker output

    • LED outputs

    • Button input (for manual ECall)

  • Compact design

  • Approx. 13cm by 6.5cm by 4cm

  • Rigid housing

Figure : S1nn IVS module (Germany)



  • User Interface for HeERO:

    • Button module for manual ECall and status LEDs

    • Speaker and microphone

3.4.2Involved parties


Table : Involved parties (Germany)

Name

Role

HeERO Consortium

ITS Niedersachsen GmbH

Project Management (acts for the German Ministry of Transport)

Yes

OECON Products & Services GmbH

Responsible for operating the German National Pilot, PSAP assistance and training, Field test assistance

Yes

ADAC e.V.

PSAP assistance and training, Field test assistance

Yes

S1nn GmbH

IVS vendor

Yes

NXP

Chipset Vendor, IVS prototypes

Yes

Continental GmbH

OVS vendor

Yes

Flughafentransfer Hannover GmbH

Test Fleet operator

Yes

NavCert GmbH

Test Suites, Validation of Field Test Results

Yes

Leitstelle Oldenburg

PSAP

No (Associated Partner)

Leitstelle Braunschweig

PSAP

No (Associated Partner)




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