Introduction
The Communication Infrastructure
The SafeTRIP Middleware
The On-Board Unit (OBU)
Case Studies
Business Models for SafeTRIP Platform
The application described by this case study aims at collecting traffic monitoring data for further processing by a control service centre. These data will include position, speed, direction of travel of the vehicles.
Data will be automatically collected by an application running on the OBU which will retrieve them from the SafeTRIP middleware.
The application makes use of the following enabling services provided by the SafeTRIP Platform:
- Position and map data – required to detect position, speed and direction of the vehicle
- DMP messaging – required for messaging from the OBU to the service centre
- IP gateway and vertical handover – required to relay the message via satellite or through an alternative ground network, depending on availability
Figure 20: Traffic monitoring components
The application runs on the OBU and is implemented as a standalone service which interacts with the Service Enabling Layer. No interaction is needed with the driver or passengers.
Standard APIs are used so that the developer does not have to handle the low-level details of communications directly. UDP is used to retrieve the OBU position from the positioning and map data subsystem. The message format used in this case is based on standard NMEA sentences encapsulated into GPSD UDP datagrams [gpsd11], while the Messaging enabling service makes use of SOAP calls to send messages.
The E-SSA waveform according to the S-MIM standard is used in the communication from the OBU to the service centre (return link). Protocol details will be transparent for the application which will only have to use the SOAP interface for message exchanges.
Message delivery is performed in the background by the SafeTRIP infrastructure. It could happen that the satellite link is not active (e.g. not under the coverage area). In this case the alternative ground networks could be used to deliver the messages or the messages can be stored locally and delivered at a later time as the connectivity becomes available. The routing strategy is decided by the IP gateway and is completely transparent to the end-user service.
On the service centre side an application server receives messages from SafeTRIP Service Enabling Layer, and stores them in a database for further processing. Messages arriving in the Service Enabling Layer are dispatched to application servers that are subscribed to receive them. This means that the “traffic flow control” application server has to subscribe itself before receiving any message.
Developers willing to implement SafeTRIP services can make use of the OBU virtual image to validate their application. This system is a custom Linux based distribution. Service Enabling Layer components can be run on the virtual machine and the SafeTRIP network infrastructure can be emulated (including losses, delays, etc.). Details on the OBU virtual machine and available software modules can be found on demand in [D4.4.3]. Software components (e.g. web server) to be installed on the OBU have to be packaged and released according to the guidelines provided in [D4.4.3].
When developing a messaging application for SafeTRIP it is important to consider that the size of a PDU (a measuring unit) on the E-SSA return link is limited to maximum 200 bytes. Messages larger than this size need to be fragmented. Fragmentation increases the message loss probability (messages are received correctly only when all fragments are received) and the delivery time. On the forward link the fragments size follows standard UDP-IP rules and fragmentation is handled by the middleware. This last aspect is very important for messaging services that require low latency.