eCall to reduce roadway deaths

The European Union is promoting eCall to reduce the number of roadway fatalities by minimizing the response time when an accident has occurred. eCall is a combination of an In Vehicle System (IVS), a device with a GSM cell phone and GPS location capability, and a corresponding infrastructure of Public Safety Answering Points (PSAPs). When the device detects an accident it calls a PSAP, transmits the vehicle location and other data, and leaves a voice connection established.
eCall may be mandatory by 2010 for all new cars sold in the EU. Over the longer term, the project is expected to drive the introduction of GSM-enabled equipment in all cars, making possible new services ranging from simple hands-free car kits to remote diagnostics, fleet management, Pay-as-You-Drive insurance options, stolen vehicle tracking (SVT) and electronic fee/toll collection (EFC) to name a few applications.

A Pan-European Initiative

eCall is part of an initiative to establish a Europe-wide location-enhanced emergency-response network based on the emergency phone number 112. It is contributing to the goal of reducing the number of highway fatalities in the European Union by one half by the year 2010. The 112 number is accessible from most wired and mobile phones in Europe. In most places it is accessible from GSM phones without a SIM card.

The PSAP will receive the call and dispatch response units. A study has concluded that “an eCall system that relays the accurate location of the accident to the PSAP and the emergency services will allow a reduction of response time to the accident of about 50% in rural areas and up to 40% in urban areas.”
Functional architecture

The eCall IVS function is to:

    Collect data from the vehicle network and from vehicle sensors, and maintain an up-to-date GPS-fix of the vehicle’s location

    Automatically detect a crash based on car-sensor information

    Call a PSAP automatically when a crash is detected, or when the driver presses a dedicated eCall button.

    Each call has 2 main parts – establish voice contact between the car’s occupant and a PSAP operator to provide assistance to the driver; and transmit a Minimum Set of Data (MSD) to the PSAP, including the current GPS position and direction the car was heading.

Previously, each functional block in Figure 2 typically required its own separate hardware module, each with its own clock, processor, flash and random-access memories (RAM):

Application Module: A typical processor for such an application is an ARM7 or ARM9.
GPS Module: The GPS module computes the vehicle position. 

GSM/GPRS Module: The GSM/GPRS module typically hosts an ARM7/ARM9 processor for managing the GSM/GPRS stacks. GSM modules also embed an audio front-end to convert the digital audio signal to analog for speakers and microphones. 

In-band Modem Module: In-band modem technology will likely be used to send crash data to the PSAP. In-band modem functionality is typically performed by a processor external to the GSM module with a link carrying pulse-code modulation (PCM) audio samples. 

Connectors: GSM/GPRS and in-band modems modules are typically subassemblies fastened to a motherboard and connected electrically through (mechanical) connectors. GPS functions may be available with a chip that can be soldered in place. 

Elimination of components

Examining the reference architecture with a cost focus, the following opportunities appear readily: 

    Chipset evolution allows for embedding more and more powerful CPUs. Typically just one provides more than sufficient power for all four applications. Each processor eliminated also eliminates a crystal.

    Each processor uses a separate Flash and RAM. Because these chips can rarely be sized exactly (available as 2 Mbits, 4 Mbits, 8 Mbits, etc.), memory would be wasted in each module. Therefore, savings usually can be derived if all applications share a single Flash and a single RAM. 

Eliminating components also reduces the size and weight of the unit and its housing.

Packaging the opportunities

A package like Wavecom’s Wireless Microprocessor exploits all these cost-saving opportunities. The cost savings of the architecture relative to the ‘Reference eCall Application’ depends on parameters including the types of microprocessor and GPS chipset, the size of Flash / RAM, connectors, etc.

Signal Reception Sensitivity

The eCall IVS is intended to be in a hidden location inside the vehicle – under the dashboard or seats, in the trunk or glove compartment. In addition, it cannot rely on an external antenna, because a crash may break it. Therefore the eCall IVS may need to cope with reduced GSM signal strength relative to an outdoor receiver and its receiver sensitivity becomes an issue. Poor reception may cause bit errors sufficient to require retransmission of some messages. During call establishment, retransmitted signaling messages increase the call setup time. Once the call is established, the MSD will be sent to the PSAP, probably with an in-band modem in the voice channel. The modem may be sensitive to Bit Error Rate (BER) also, leading again to increased transmission time, or, for a poor quality RF link, even transmission failure. This could cause a problem in the eCall application, since the GSM Europe (GSME) interest group recommends the message transfer time be less than four seconds. Wavecom’s C-GPS Plug-In provides some of the highest reception sensitivity available on the mrket today.

Power Consumption

Power consumption by the eCall IVS is a concern when a car is parked for a long time (months). Low power consumption could be achieved by shutting down the eCall IVS while the car is parked, but it must be awakened if activity is detected in the car, either through the vehicle bus or through some external sensor. This requires the CPU to keep running in a low power mode to detect events and wake up the IVS software application.

Software Integration Requirements

Designing the most efficient eCall IVS requires integrating core competencies from different industries onto a single processor. Third party applications to be embedded in the platform are typically developed in the C language on a light real-time operating system. They use basic multi-tasking functions. The software platform must have these functions to allow easy porting.

The eCall IVS must be GSM-capable, requires in-band modem software, must read the vehicle CAN bus, and needs accurate GPS positioning. These distinct functions, typically coming from different suppliers, must be integrated to work smoothly together.

Wavecom Wireless Microprocessors provide these software capabilities through the Open AT OS. The Wavecom Open AT IDE, an Eclipse-Ready integrated development environment, facilitates integration, allowing third-party applications to be run directly on the Wavecom processor. All of the Real Time Operating System capabilities are available to third-party applications. The Wavecom Wireless CPU integrates the aqLink in-band modem software from Airbiquity.
Real-Time Requirements

The main eCall IVS processor will likely host software applications developed by different sources, each having specific constraints.  

Easy Software Upgrades

In the future, a software modification may be required in every car, e.g., because of new legislation. Additionally, new applications may be introduced. Ideally, to save costs, the eCall IVS platform should provide the ability to upgrade software remotely through a Download Over The Air (DOTA) service.

Automotive Requirements

The eCall IVS will be embedded into the car and must meet the stringent requirements of the automotive industry with respect to both its design and manufacture. Conformance to requirements for temperature and humidity, mechanical vibration and shock, and emission of and sensitivity to electromagnetic radiation must be checked in detail for a new product design.

Software must be developed according to a detailed and widely-accepted methodology. Tools (like FMEA : Failure Mode & Effect Analysis) are to be used during the product design stage. “Return of experiment” data must be gathered during the design and manufacturing introduction phases and fed back into the design and manufacturing process to qualify the development as defined by the automotive industry requirements. Additionally, these results will allow defining the right control plans for the maintenance phase so the product will comply with automotive reliability expectations. Finally, a traceability process shall be put in place for these products in order to support the car manufacturers in a timely manner if and when problems are detected in the field.