1 Pilot operation preparation report Version number


eCall pilot system components



Download 6.16 Mb.
Page5/29
Date08.05.2018
Size6.16 Mb.
#48528
1   2   3   4   5   6   7   8   9   ...   29

eCall pilot system components

  1. eCall Test and Development server (PSAP)

Due to the different standards in the German PSAPs, there are many different software solutions installed in the PSAPs. To avoid dealing with special interfaces and interests, Germany decided to develop special PSAP eCall software to allow a detailed testing concerning all levels of communication. The software was also designed as a test platform for vehicle manufacturers, OEMs and in- vehicle system (IVS) developers for developing and testing of eCall Vehicle Components.

Figure 5: eCall Test and Development Centre (Germany)



The characteristics of this eCall Test and Development Centre are:

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

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

  • 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 6: eCall Server system overview (Germany)


          1. Database Structure

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

Figure 7: Detailed Database Structure (Germany)

One basic procedure while accessing the database is to never delete data. That’s why many tables contain a column “visible”, which acts as a flag to hide entries that the user has chosen to remove.

What follows is a rundown of all tables in the database and a coarse overview on what data they contain.


            1. calls

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

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

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

This table saves links between phones and vehicles.
            1. phones

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

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

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

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

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

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

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

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

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

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

The following test parameters can be configured per test case.

Table 2: Test parameters that can be configured (Germany)



Parameter name

Type

Legal values

Default value

Remarks

Accept call

bool

True / False

True

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

Hang up call after

int

0 – 3600 seconds

0, means never

Hang up after X seconds

AL-Ack value

int

0 – 15

0, means „Positive Ack“




Request MSD after

int

0 – 3600 seconds

0, means never

Measured from call begin

Abort after initiation

bool

True / False

False

Disconnects in-band modem upon INITIATION signal

Number of LL-Acks

int

0 – 20

4

0 implies deactivation of in-band modem

Number of AL-Acks

int

0 – 20

4

0 implies deactivation of in-band modem

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.


        1. Download 6.16 Mb.

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



The database is protected by copyright ©ininet.org 2024
send message
    Main page
Guide
Instructions
Report
Request
Review