Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
DESIGN AND IMPLEMENTATION OF A J2EE PLATFORM TO HANDLE STANDARDISED
         TELEMATICS EMERGENCY CALLS ORIGINATED FROM VE...
It is a step forward that E-MERGE is the first automotive
application to adopt the GTP protocol.


            III. THE E-...
A Model – View – Controller pattern has been followed for         and latitude GPS coordinates (in milliarcseconds units) ...
chain and considering that the technological solutions of the    and model of the vehicle, driver name (matched in the DB
...
only the FSD’s with PSAPPDG status will appear listed in              call once and again. Only when the PSAP operator
the...
X. CONCLUSION

In order to secure the building of a common European
vehicle E-Call solution a European approach is needed ...
Upcoming SlideShare
Loading in …5
×

Design and implementation of a J2EE platform to handle standardised telematics emergency calls originated from vehicles

2,289 views

Published on

This paper describes the first standardised, technical, functional and organisational solution of a pan-European handling of a telematics based emergency call from the vehicle, involving all the stakeholders of the rescue service chain. It covers a common system specification and communication protocol definition together with operational procedures and the architecture of the vehicle E-Call system, describes the compliant solution developed by the Spanish partners of the project (RACC Automobile Club, playing the role of the SP and Seat, as the vehicle manufacturer) and focuses on the PSAP/SP receiving platform, which has been developed based on Java 2 (J2EE) technology.

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

Design and implementation of a J2EE platform to handle standardised telematics emergency calls originated from vehicles

  1. 1. DESIGN AND IMPLEMENTATION OF A J2EE PLATFORM TO HANDLE STANDARDISED TELEMATICS EMERGENCY CALLS ORIGINATED FROM VEHICLES Josep Laborda Luque1, Xavier Castells Ferrer2, Xavier Hesselbach Serra3 1,2 Royal Automobile Club of Catalonia (RACC) Technical Department, International Network, Avda Diagonal 687, 08028, Barcelona, Spain, josep_laborda@yahoo.es, xavier.castells@racc.es 3 Universitat Politècnica de Catalunya, C/Jordi Girona 1-3 08034 Barcelona, Spain, xavier.hesselbach@mat.upc.es Abstract - Given the large number of motor vehicles arbitration and access to all signals generated by the devices of the vehicle. Signals are simulated in the CAN bus through travelling within and between European countries, and the fact that more than 45,000 people die on Europe's roads each the CANalizer tool. The validation of a minimum of two year, there has clearly arisen a urgent need for a Europe- critical sensors (airbag deployment and rollover sensor, for example) automatically triggers the E-Call. The E-Call can wide, in-vehicle emergency call solution that can secure that a manually or automatic E-Call originated from a vehicle be as well manually initiated by pushing a telematics SOS can reach the nearest Public Service Answering Point button. In both cases, a voice call is established with the nearest PSAP 1-1-2 international European emergency (PSAP) and the private Service Provider (SP), in case the driver has subscribed such an added value service, in a fast service and data collected from the car sensors in the CAN and reliable way and that the proper actions will be taken bus of the vehicle regarding the emergency is sent to the PSAP and the private SP of the driver, which is used to thereafter to assure that the most appropriate assistance is dispatched to the vehicle with the minimum delay. better determine the severity of it. The project [1] therefore describes the first standardised, technical, functional and organisational solution of a pan- European handling of a telematics based emergency call from the vehicle, involving all the stakeholders of the rescue service chain. This paper covers a common system specification and communication protocol definition together with operational procedures and the architecture of the vehicle E-Call system, describes the compliant solution developed by the Spanish partners of the project (RACC Automobile Club, playing the role of the SP and Seat, as the vehicle manufacturer) and focuses on the PSAP/SP receiving platform, which has been developed based on Java Fig. 1 Telematics buttons: SOS / Cancel 2 (J2EE) technology. Keywords – E-Call, GTP, SMS, MSD, FSD, J2EE. II. THE COMMON PROTOCOL: GTP Since it is the aim of the E-MERGE project to define a standardised pan-European solution for road emergency I. INTRODUCTION management, a strategy for the communication link among the IVS and the PSAP/SP has been accorded, so that data The work reported in this paper is part of the E-MERGE transmission is based on SMS and the coding and transport european project and has been coordinated by ERTICO and layer are covered by the GTP protocol. GTP has been co-financed by the European Comission DG Information defined by a working group of the Telematics Forum [2] and Society under the IST Programme (IST-2001-34061). has been chosen after a benchmarking through the available Following the E-MERGE specifications, a vehicle is solutions. The activity started from the existent ACP equipped with an on-board telematics terminal, as known as (Application Communication Protocol) and GATS (Global In-Vehicle System (IVS). The IVS is physically connected Automotive Telematics Standard) automotive telematics to the CAN (Controller Area Network) bus of the vehicle, a protocols (in which the already existent proprietary solutions simple two-wire differential serial bus system that for telematics-based onboard emergency systems by some efficiently supports distributed real-time control with a very car manufacturers were based) and merged the main features high level of data integrity. It provides high-speed but low of the mentioned protocols into the new GTP specification. cost multiplex wiring between nodes, automatic bus
  2. 2. It is a step forward that E-MERGE is the first automotive application to adopt the GTP protocol. III. THE E-CALL: VOICE + DATA The call generated by the IVS becomes an extended E-Call, which is composed by two parts: Voice call and Data call. Fig. 2 MSD Message flowchart Voice call is established with the nearest PSAP. Data splits into three SMS’s [3]: the so called Minimum Set of Data In case the driver would be a SP subscriber the IVS starts (MSD), which is sent in one SMS to the nearest PSAP and two E-Calls: one directed to the PSAP (voice call + MSD) the Full Set of Data (FSD), which is sent in two SMS’s to and one directed to the private SP, composed by the FSD. the private SP of the driver. The set of information sent to the SP is more detailed and so is more complex in message exchange (see Fig. 3). The FSD Data sent in the E-Call includes: is updated in the SP DataBase and matched with the static personal data of the driver (with use of the CLI as primary Vehicle data: car manufacturer and model, model year, key). CLI goes for Customer Line Identification or GSM colour, license plate number, temperature inside the number of the IVS SIM card. The PSAP that has handled vehicle, temperature of the engine, IVS serial number the MSD has the possibility to access the personal data of and manufacturer ID, VIN (Vehicle Identification the customers implied in an emergency afterwards, when Number), IMEI (International Mobile Equipment needed. The data stored in the SP DB regarding the E- Identificator), fuel type, number of occupants, child MERGE customers includes medical data (blood group, seat, type of E-Call (manual / automatic), insurance special medications, allergies, etc), private health policy data. organisation info, personal contacts data (relatives, friends, etc) and other data that may be very helpful in case of an Vehicle heading and GPS location (with Dead emergency. SP provides translation assistance as well in Reckoning location data). case the driver and the PSAP operator don’t speak the same Vehicle status: Crash Intensity Data. language, by establishing a conference call. [0] No data available [1] No crash [2] Low impact [3] Medium impact [4] Severe impact Activation data or critical sensors that activated the automatic E-Call: rollover, airbag deployment (driver, passenger, side, back), crash sensor (frontal, back, side). Fig. 3 FSD Message flowchart Subscriber data: SP phone number, IP address and country code. V. PSAP AND SP COMMON INFRASTRUCTURE RACC Automobile Club has developed a compliant solution IV. COMMUNICATION OVERVIEW based on a J2EE platform using Java Servlets and JSP (JavaServer Pages) technology. As the business logic and When an E-Call event occurs, a MSD is sent to the nearest operational procedures for the MSD and FSD regarding the PSAP (see Fig. 2) and a voice call is automatically same emergency are very similar, the PSAP application established with the 1-1-2 international emergency call becomes a subset of the SP application. Portability through number and connected using the hands-free system of the all the Spanish network of 112 Public Emergency Centres vehicle. This let the PSAP operator have a clearer idea of (PSAP’s) is guaranteed due to the web approach of the what has happened and give a feedback to the user. In case designed platform. the voice call is interrupted (by lack of GSM coverage, for example) the IVS is programmed to automatically trying to The whole designed software application (PSAP and SP) re-establish it. When the conversation ends, the PSAP runs on a BEA Weblogic Application Server v8.2 and the operator manually sends an EOS (End Of Service) message data is stored and maintained by an Oracle DataBase Server to the IVS, which closes the voice channel. v9.2. The application is protected by the CheckPoint FW-1 Firewall.
  3. 3. A Model – View – Controller pattern has been followed for and latitude GPS coordinates (in milliarcseconds units) and the software architecture (see Fig.4). The Model Layer triggers that validated in the E-Call (notified by a “!” icon). represents the data, which is stored and maintained in a DB. We distinguish between dynamic data (MSD and FSD) and static data (customers’ personal data). At application level, data is organised in Java bean objects. A bean is a Java object that encapsulates data. There is a direct correspondence between DB table fields and the Java bean objects. For example, a vehicle is treated as a bean, and it encapsulates related data such as license plate number, make, model and colour, etc. Standard SQL sentences are used to query the DB, with the use of the JDBC (Java DataBase Connectivity ) API. The View Layer or Graphical User Interface is composed by JSP web pages. The JSP user web pages interact with the DB with the help of Java Servlets. The Controller Layer is integrated by classes that implement the business logic of the application. That is: monitoring the incoming new messages, parsing them, updating the DB, generating and sending the ACK and EOS Fig. 5 PSAP interface: List of MSD’s pending to be served confirmation messages, treating the error cases and managing the administrator actions (sign up of new E- MERGE customers and users of the application). Every row has its corresponding “View” link. Clicking on this link leads to another screen with the full data about the MODEL MSD together with a pop-up window with a digital cartography application that situates the vehicle in a map DB (see Fig. 6). Zoom functions are available in the map to better localise the vehicle. The name of the road, highway or street (or the nearest one) in which the vehicle is located and the nearest Points of Interest are as well provided. VIEW JSP’s CONTROLLER Servlets Fig 4. Software architecture: MVC pattern All the incoming SMS’s are stored in a DB table called SMS. The application is configured to monitor this table every 10 seconds for new messages. In case there are any new SMS’s in the system, these are stored in a temporal vector. This is done at server-side. At client-side, it is the responsibility of the JSP pages to update the data they present when needed by adding to the present data the list of new alarms as contained in this temporal vector. Fig. 6 MSD complete info screen and pop-up window with localisation of the vehicle VI. PSAP APPLICATION The PSAP application lists the received MSD’s that are pending to be served by a PSAP operator. Every row (see Next to the “View” link, a “FSD” labelled button can be Fig. 5) represents a MSD and contains the essential info pushed to lead to the matching FSD of the present alarm. about it, so as for the PSAP operator to get a first impression For a car driving outside its own country, note that this FSD of the severity of the accident. This info is: time stamp of will be stored by the driver’s private SP DB. Once more, the alarm, make, model and colour of the vehicle, longitude with the aim to standardise the communication procedures between all the stakeholders among the emergency call
  4. 4. chain and considering that the technological solutions of the and model of the vehicle, driver name (matched in the DB different countries may differ, a simple standard way of with the CLI), customer number, location of the accident, retrieving the FSD has been defined by the use of the triggers that validated in the E-Call and status of the FSD. Webservices technology. Pushing the “FSD” button sends an XML-formed message through a SOAP (Simple Object Every row has its corresponding “View&Proc” link. Access Protocol) Request to the listener URL at server-side Clicking on this link leads to another screen with the full of the corresponding SP that has this information. The bean data about the FSD together with a pop-up window with the object representing the MSD stores a country code ID, same digital cartography application of the PSAP which is used by the application to correctly deal with the application that situates the vehicle in a map. right webservice. A common structure of this request message has been accorded so that username, password and The status of a FSD when entering the system is SP Pending CLI are provided within it. SOAP module has been (SPPDG), that is, the FSD is to be processed by the RACC implemented with use of the SAAJ (SOAP with operator. The detailed FSD screen (see Fig. 8) lets the user Attachements Java) API, which follows the SOAP 1.1 validate the victims of the accident, add them to the list of specification. victims and consult their personal data (medical data, private insurance organisation info, personal contacts to be called in A list of the Webservices listener URL’s of the different case of emergency, etc) in the DB. The application offers SP’s around Europe among valid username and password is the possibility to add a text field with additional comments, maintained in a configuration file. After a validation add a Location field (more accurate, after validation) and process, the server-side SOAP component of the SP checks mark the FSD as False Alarm. It is a subjective decision of if there is any FSD for the provided CLI and returns a “null” the operator whether the FSD should be treated by the PSAP object (the driver has not subscribed a private service with a operator as a False Alarm based on the previous validation SP) or an XML-formed message with the FSD data. process. VII. SP APPLICATION The SP application lists the received FSD’s that are pending to be processed by a SP operator. A search engine in the top frame of the page lets the user search the alarms stored in the DB by the following criterions: date, CLI number, make and model of the vehicle, license plate number, location of the accident, status (see Fig. 9) and name, passport number and customer number (RACC Automobile Club member ID) of the vehicle owner. Fig. 8 FSD complete info screen with process functionalities Finally, by pushing the “Process Alarm” labelled button the FSD status changes to PSAP Pending (PSAPPDG). In the PSAPPDG status, a FSD can be retrieved by a PSAP operator from his own application by sending a SOAP Request. The RACC application can receive SOAP requests from any European PSAP system. RACC has gone further than the E-MERGE common specifications and has implemented an extended additional/optional process Fig. 7 RACC Automobile Club interface: Alarms Search procedure, in an effort to help the PSAP’s to better Engine and list of FSD’s pending to be served understand what has happened within the accident. If the PSAP operator needs to retrieve more information than the Every row (see Fig. 7) represents a FSD and informs about: provided in the FSD, he can login into the RACC time stamp of the alarm, CLI, license plate number, make application as a user with PSAP profile. This means that
  5. 5. only the FSD’s with PSAPPDG status will appear listed in call once and again. Only when the PSAP operator the main screen and the Alarms Search Engine will not manually sent the EOS to the IVS (by pushing the available for a user with this profile. The process procedure “EOS” button in the application), the E-Call was is the same as for the SP operator, but without the validation terminated. A situation in which the driver would be functionalities (already performed by the RACC operator). able to speak but could not move due to the severity of The PSAP operator can add a text comments field and the accident is solved with this functionality. process the FSD. This action will lead the FSD to its final status, Processed (PROCES). FSD was retrieved by the Spanish PSAP operator from the Italian SP DB as an XML file. Conference call between the Italian driver, the local PSAP operator and SPPDG PSAP PROCES the Italian SP operator was established. Complete PDG assistance to a foreigner driver was successfully tested. FA Among the previous situations, several consecutive manual and automatically initiated E-Calls were simulated by both vehicles (only GPS data was real), demonstrating the stability of the system. A delay of around 3 minutes in Fig. 9 Status of a FSD average between the E-Call start and the reception of the EOS for the FSD by the IVS was observed, proving that SMS’s fit well for the designed emergency service. VIII. TESTING Tests have been conducted in the participant countries IX. DEVIATIONS AND FUTURE UPGRADES Spain, Italy, Sweden, Germany, England, Belgium and Holland and have demonstrated that such a system can The pan-European approach of the E-MERGE project has dramatically reduce the response time of the emergency revealed some technical incompatibilities between the authorities and SP’s in case of a road accident. In Spain, different countries. Among these, some deviations on the E- RACC Automobile Club has assumed the responsibility to MERGE concept are to be considered in the Spanish Test be the Test Site leader and has tested its system with Seat, Site. Volvo and Fiat respective IVS’s with success. Different test scenarios have been carried out, simulating various The 1-1-2 service has special features in Spain. While situations. making a voice call to the 1-1-2 the signalling layer is disabled. This means that no SMS can be received nor A situation in which the Fiat Stilo Italian test car driving in sent by the IVS. A dedicated telephone number was Spain generated a manual E-Call and a few minutes later the used in the tests. Seat Leon Cupra test car simulated the deployment of the driver’s and passenger’s airbag and the front crash sensor The 1-1-2 service is not yet prepared to handle data validation was tested, and both E-Calls were correctly calls. Once again, different GSM Modem numbers were managed by the PSAP and RACC operators, proving the used in every Test Site. viability of the system in the most realistic situation. On the other hand, the Seat Leon Cupra travelled to Italy and Roaming problems have been observed. The Dutch SIM generated several E-Calls. FSD was correctly received by cards don’t provide their CLI when roaming. The CLI is RACC and retrieved from the RACC listening SOAP used to match the voice call with the data call received module by the local Italian PSAP. Additional specific use by the PSAP. cases were performed in both cars: Lack of GSM coverage can make a voice call to fail. The driver initiated a manual E-Call and pushed the IVS will try to re-establish the voice call, anyway. For “Cancel” button before 6 seconds. This correctly the data sending, SMS is a good option, because it uses aborted the E-Call, and no data was sent nor voice call no bandwidth, as it travels in the signalling layer. This established, demonstrating that a wrong use of the SOS means that, even if all the channels in a cell are button (by children, for example) can be avoided. occupied and the voice call is not possible, the SMS’s will be sent and the emergency will be notified. The PSAP operator interrupted the voice call, simulating a lack of GSM coverage situation. The IVS For all this, UMTS would be the best technological option automatically re-established the voice call with the for future upgrades of E-MERGE, as it is the technology PSAP. Several times the PSAP operator repeated this that best fits the concept of E-Call considered as a procedure and the IVS managed to establish the voice multimedia call.
  6. 6. X. CONCLUSION In order to secure the building of a common European vehicle E-Call solution a European approach is needed and the right stakeholders need to agree together on common standards and procedures. E-MERGE has aimed at ensuring that current E-Call systems are harmonised across Europe and that the additional information that can be retrieved from vehicles can be used in case of emergency. The Spanish partners, RACC Automobile Club and Seat, have developed a compliant and complete solution following the E-MERGE guidelines. The UK partner ACPO (Association of Chief Police Officers of England, Wales and N. Ireland) has estimated that about 10 minutes of time saving in the response would be possible with E-MERGE. ERTICO believes that if EU states are willing to fund the necessary infrastructure, E-MERGE could be working by 2008. REFERENCES [1] http://www.e-merge.org [2]http://www.telematicsforum.com/document/acp_gats/acp _gats.htm [3] M.Leandro, P.Lindgren, J.Laborda “E-MERGE GTP data coding”, version 1.5 [4] E-MERGE Consortium “Specifications of the European In Vehicle Emergency Call”, version 1.5

×