eeTimes
eeTimes
eeTimes eeTimes
Forgot password Register
Print - Send - -

Infotainment

Low-Cost Driver Assistance Using ZigBee/IEEE 802.15.4

March 07, 2010 | Suhas Chakravarty, Varun Jain, Nakul Midha and Prashant Bhargava | 222900702
According to investigations, intelligent driver assistance systems can prevent 20 to 30 percent [3,4] of road accidents. In the years to come, driver assistance systems will be required safety features rather than options. The main challenge for the automotive industry is how to make these systems cost-effective so they can be embedded into small and mid-segment cars as well as high-end models.

Current driver assistance systems are based on a number of technologies, such as radar, computer vision and sensors. Integrating all of these technologies into a single system is normally a costly and complex solution. We propose a complete ZigBee based driver assistance system solution that leverages the cost-effective, low-power and secure wireless networking features of the ZigBee protocol.

The solution seeks to alert and inform the driver whenever the vehicle approaches a preset waypoint on the road. A ZigBee-based unit is installed at each waypoint, broadcasting relevant information to corresponding ZigBee units embedded in approaching vehicles. Such a system significantly reduces the reliance on human vision and on-road lighting conditions.

This highly flexible concept can perform the following functions:

•   Alert the driver to approaching traffic, stretches of road under maintenance, school and hospital zones, vehicles approaching around a blind corner and many other hazardous conditions.

•   Serve as milestones, road signs and simple advertisements, such as the menu of a nearby drive-in restaurant.

•   Be used as waypoint nodes to record and transmit traffic statistics, such as the number of vehicles passing through an intersection. These nodes can be linked to sensors measuring air quality, temperature or humidity at important locations in the city, and all readings can then be broadcast through a mesh network of various waypoint nodes to in-car units and a central gateway node for further processing.

•   Be used for automated, unmanned toll collection for parking lots and toll roads where a secure ZigBee link can help carry out toll transactions before the vehicle reaches the entry point.

In summary, any application that requires car-to-road communication, with a moderate amount of data involved, would benefit from the solution.

 The ZigBee network

 The ZigBee networking stack is built upon the IEEE 802.15.4 standard that defines the physical (PHY) and medium access control (MAC) layers for a low-data-rate, low-power network. ZigBee adds network (NWK) and application (APL) layer specifications on top of 802.15.4 to complete what is called the full ZigBee stack.

The solution network has the following types of ZigBee nodes:

•  Gateway Node: This node in traffic control or police stations synchronizes and collects information from waypoint nodes in the vicinity. Each gateway node would connect with the Internet through an Ethernet connection. Thus, the Internet serves as a backbone, connecting all gateway nodes together. Traffic data logging applications and, in general, any sort of application that falls within the purview of the city administration and requires extensive coverage, needs a network of waypoint nodes. This is to facilitate central data collection and analysis as well as remote node updating and maintenance.

•  Waypoint Nodes: There are two types of waypoint nodes: networked and stand-alone. Networked nodes perform heavy data logging operations and are permanently linked with a gateway node. Such nodes could be placed along major thoroughfares, freeway entrances and exits and at major intersections. In addition to capturing and transmitting traffic information, these nodes could broadcast useful driver information, such as nearby gas stations or hospitals, to car unit nodes. These waypoint nodes should be capable of handling traffic on either side of the road. Thus, each car unit would inform the waypoint node about its heading and the waypoint node would respond with pertinent information. Since these nodes are mesh networked with the gateway node, they can be updated with information on new landmarks and utilities in their vicinity.

 • Stand-alone nodes are temporarily deployed and may or may not be linked to gateway nodes in the area. They can be used as emergency notification nodes that warn approaching traffic about accidents, construction in progress and other road hazards. These would be removed once the hazard has been resolved. Stand-alone waypoints can also serve as advertisements, which would not require a connection to the city administration waypoint network.

•        Car Unit Nodes: These are the nodes placed in each car to communicate with waypoint nodes. These nodes would have a human interface, such as a keypad, LED display or LCD, for user-friendly access to the system.

 

 In Figure 1, the waypoint nodes marked 1–4 could effectively:

1. Provide alerts about traffic at potential blind spots

2. Provide information on various landmarks, such as gas stations, malls and hospitals

3. Provide information about approaching trains at a railroad crossing

4. Temporarily provide a warning about construction and other traffic obstructions

In the next sections we will see how all the nodes working together can collectively support multiple applications.

 Setup

 Every ZigBee car unit node has a unique ID assigned to it, much like the vehicle’s registration number. At periodic intervals, the car unit sends out a “ping” packet that includes the ID. On receiving a ping, a waypoint unit will transmit a particular message in return.

 Application

 On a broad level, the applications can be classified in the following three categories:

1.   Alert scenarios

2.   Information broadcasting

3.   Data logging

 Alert scenarios

 These scenarios use the information to alert drivers to hazardous situations on the road ahead. A waypoint unit

detects an approaching vehicle and transmits an alert message that identifies upcoming hazards, such as:

•  Speed bumps or breakers

•  Blind turns

•  Road maintenance

•  No parking, no entry or speed limit changes such as school zone

•  Pedestrian crossings and hospital or fire statio entry and exit points

•  Approaching vehicles on single lane curved roads, especially in hilly areas


 Figure 2 shows how waypoint units are placed to give the automobile driver advanced warning in time to take corrective actions. The process for warning vehicles in a blind turn vicinity could be as follows:

 

•   In Figure 2, the waypoint node detects car A approaching the intersection (receives the car’s ping).

•   The waypoint node logs car A’s ID and transmits a “blind corner” alert.

•    On receiving this warning packet, the car unit in car A will give the driver both an audio and visual warning of the “blind corner” alert.

•   Now, while car A is still within the range of the waypoint node, car B comes within range of the waypoint node.

•   The waypoint node detects car B and changes its broadcast message to “multiple cars approaching blind turn.” Because it is a broadcast, it is received by both cars.

•   Again, car units of both cars sound warnings and light up a red LED. A warning message is also displayed on each car’s LCD.

•   The drivers of both cars can slow or stop as required.

•  When both cars leave the range of the waypoint node, the node stops broadcasting.

For all alert scenarios, the placement of the waypoint units must allow the alert message to be sent out early enough to give the driver enough time to react. The correct placement of the unit depends on the following factors:

Factor 1: The broadcast range of the waypoint unit or the car unit (whichever is shorter)

Factor 2: The data rate of the ZigBee link between the car and the waypoint unit

Factor 3: The average human reaction time

Factor 4: The posted speed limit, which helps determine the average distance it takes for the car to come to a halt

Let’s assume a case where car A and car B are approaching the blind turn at 70 Km/h (19.44 m/s), simultaneously, which is the posted speed limit (Factor 4). Factor 1 equals 50m (conservative estimate), and the data rate is 50 Kbps (Factor 2). At 70 Km/h, the approximate stopping distance is 43m, which includes driver reaction time. Let’s say the alert message is 800 bits long.

A and B would be detected at a distance of 50m from the waypoint node, and at 50 Kbps, 16 ms elapse in transmitting an 800-bit alert message, within which time the cars travel a distance of around 32 cms. Subtracting this figure from 50m still leaves us comfortably placed within the 43m stopping distance.

 Information broadcasting

 This category of applications provides the driver with information that ranges from one level below safety-critical to simple advertisements for various commercial establishments. Some examples are:

•  Road signs

•  Nearest petrol/gas filling stations

•  Nearest hospitals, hotels, markets, car service stations and landmark information

•  Directional guides, such as destination A is 2 km straight, destination B is 3 km right and destination C is 3 km left from the present location

•  Advertisements for roadside eateries

 

Data logging

 Each waypoint unit at major intersections and on major freeway entry and exit points can maintain a log of passing vehicle IDs plus a timestamp. Nodes can timestamp the entry and exit of vehicles in their hearing range and log the duration spent within this range. This can help the city planners profile the traffic patterns and volumes.

In a given location, a few dozen waypoint units could be connected through a mesh network to a gateway node, which, in turn could be integrated with an administration office LAN. The gateway node would update its master log by regularly querying each waypoint unit in the mesh network. The information from the master log could be pulled to create a consolidated report on a daily or monthly basis. By integrating air quality, temperature and humidity sensors with the same waypoint units, the locality’s air quality can also be effectively monitored. Since these applications will require intensive data logging, fast, high-endurance, non-volatile memory with error correction capability should be included in the waypoint units.

The solution could also be used to track stolen or fugitive vehicles via the following steps:

•   Once an alert for a particular vehicle has been issued, every gateway node is sent the vehicle’s ZigBee unit’s ID.

•   The gateway nodes then pass it on to their respective waypoint units, along with a “red alert” packet.

•   The waypoint units then enter a special mode where they compare each vehicle ID they log with the “red alert” ID. When a waypoint unit finds a match, it alerts the gateway node.

•   A rough route of the vehicle can be tracked, including the time each waypoint unit identified the vehicle.

 

 System details

We introduce the terms “mobile unit” and “static unit” here. The ZigBee unit installed in the vehicle is called the mobile unit, while a waypoint unit on the road is the static unit.

In a mobile unit, an LCD screen and an array of LEDs on a vehicle’s dashboard serve to display the messages and alert the driver along with audio warnings. The kind of LCD used (segmented or color) depends on the kind of MCU used and the cost of the unit. If the MCF1322x Platform in a Package™ (PiP)[1] is used, then the LCD can be connected via SPI. LEDs can be applied through GPIOs or RGPIOs and can be used in a low-cost solution in place of an LCD. Also, waypoint nodes and gateway nodes do not require LCDs, as a technician can connect the node to a laptop to view its information during debug and maintenance. Audio alerts are a must for all mobile nodes.

To conserve power, the static unit is in sleep mode most of the time, waking up when it detects an approaching vehicle. Solar energy can also be used to power the waypoint and recharge its batteries for enhanced 24-hour energy efficiency.

 


 

The Freescale advantage

Freescale provides all the building blocks used to develop a complete ZigBee-compliant platform solution, including hardware, software, tools and reference designs. Freescale offers hardware solutions ranging from a single-chip advanced ZigBee-compliant PiP[1] to a simplified two-chip solution with a ZigBee transceiver (radio) and a low-power microcontroller (MCU). In a two-chip solution, the MCU should include an LCD controller or two or more SPI interfaces. ZigBee features, such as the ability to securely transfer messages over a channel without interfering with other wireless networks[5], ensures that the data is delivered intact.

All modules would include a Freescale MC1322x MCU, featuring:

•   128 KB serial flash

•   96 KB static RAM

•   80 KB ROM

•   Hardware acceleration for IEEE 802.15.4

Car units have these extra onboard components:

•   LED panel to indicate alerts and other vital information

•   LCD panel (optional) to display the messages transmitted by waypoint nodes

Waypoint nodes with data logging capability will also have SPI flash, which can be interfaced with the SPI on board the MC1322x MCU.

Freescale also provides a full integrated development environment (IDE) for developing embedded applications. The IDE is complemented by the BeeKit™ Wireless Connectivity Toolkit, a comprehensive package of wireless networking libraries, application templates and sample applications.

Summary

In this article we discussed the importance of an efficient driver assistance system and how it can help us improve safety standards on the road. The solution can significantly reduce the risk to drivers and enable better traffic management. Our ZigBee-based driver assistance system provides a very cost-effective alternative to more expensive commercially adopted systems like GPS, which provide navigation but do not have any fore-warning capabilities. Further details on the comparison of ZigBee with other wireless protocols can found in the additional Beyond Bits 4 article, Location Monitoring Using ZigBee/IEEE 802.15.4.

We showcased a number of ZigBee-enabled application scenarios related to automotive and road safety, such as data logging, information broadcasting and driver alerts. In today’s market, where many solutions are emerging that are related to vehicle-to-vehicle and vehicle-to-road communications, we believe Freescale’s ZigBee solutions can play a larger role in promoting a safer, more informative driver experience.

References

[1]     MC1322x Advanced ZigBee-Compliant SoC Platform

for the 2.4 GHz IEEE 802.15.4 Standard Reference Manual, www.freescale.com/files/rf_if/doc/data_sheet/MC1322x.pdf

[2]     www.freescale.com/zigbee

[3]     Research On The Road To Intelligent Cars, ScienceDaily (Mar. 11, 2006), www.sciencedaily.com/releases/2006/03/060311090833.htm

[4]     Concept of an Intelligent Adaptive Vehicle Front-Lighting Assistance System, H. Shadeed, J. Wallaschek; Proceedings of the 2007 IEEE Intelligent Vehicles Symposium

[5]     Zonal Location and Asset Tracking with ZigBee Technology (using RSSI), Cambridge Consultants (Oct. 12, 2006), www.zigbee.org/imwp/idms/popups/pop_download.asp?contentID=9567

Nakul Midha, Varun Jain, Prashant Bhargava and Suhas Chakravarty are design engineers at Freescale’s India Design Center. Nakul and Varun have performed verification and validation of various SoC projects. Prashant has worked in design, architecture and verification of SoC and IP projects while Suhas has been working in SoC architecture and design. All hold bachelor of engineering degrees in electronics and communication.

 








Please login to post your comment - click here
Technical papers
Poll
What are today's biggest challenges in Automotive electronics?

All material on this site Copyright © 2009 - 2010 European Business Press SA. All rights reserved.
This site contains articles under license from EETimes Group , a division of United Business Media LLC.