Intelligent transportation systems (ITS) are usually approached by exhaustive measuring and complex signal processing including medium-high cost hardware deployment. In this paper, a novel design of a wireless sensor network system using magnetometers and microphones for the detection and avoidance of traffic jams is described and analyzed. The system, which can also be used for traffic monitoring and surveillance, is simple, energy efficient, and accurate which allows to be implemented with a reduced hardware cost. In order to reduce the maintenance tasks, mini solar panels would also be installed for powering up the motes in the near future.
Smart cities are one of the hot topics nowadays. One of the most relevant aspects in a city with this consideration, especially in a big city, is the traffic management and surveillance. In [
The common approach to tackle the traffic surveillance is an exhaustive monitoring of vehicles [
Recently, in the last decade, nonintrusive sensors are being used because of their flexibility and their low-medium cost. Examples are acoustic [
There are also other kinds of systems that need some extra hardware at the vehicles such as the global position systems (GPS), mobile-based systems [
Focusing now on the application of ITS, users usually only need to know a coarse estimation of the traffic, for example, four-level information: no traffic, low density, medium density, and high density or traffic jam. In these cases, most of the systems already proposed are too much complex and expensive because they are aware of vehicle detection, counting, and the estimation of other parameters that are not used in here. In order to avoid crowded roads or congestions, with these simple 4 levels of information would be enough to be able to make a correct decision on which road to take and thus obtain the final goal of congestions’ avoidance. If more levels of information were required, the system could be straightforwardly adapted. The key idea in this paper is to provide a simple yet efficient WSN-based system for giving useful real-time information to prevent congestions and reduce delays.
The rest of the paper is organized as follows. In Section
In this section, the main scenario will be described. Besides, the main parameters and technical considerations will also be covered.
As it has been mentioned above, a common scenario is when users have a couple of alternative routes for arriving to the destination. For example, one person might have from two to five different paths for traveling from home to the job, and the decision on which one is the best will depend on the traffic conditions. However, most of the times, the decision has to be made without knowledge of the traffic and once it has been chosen there is no way to return. Moreover, the chosen path can actually be changed or adapted according to the estimation of traffic conditions. If we have extra information about how much traffic there is in the near future it will be very helpful in taking the decision. For example, the decision on whether taking one exit or another will depend on how much traffic there is at the roundabout that follows the exit, but usually you do not have this information. However, for taking a proper decision, you only need to know roughly the amount of vehicles but not their exact number.
In these scenarios, a simple vehicles’ detection system is enough. Moreover, the speed or other parameters that are more complicated to be estimated are not required, and, thus, a simpler design is enough for our purposes which impacts the cost yet obtains similar results to other much more complicated schemes.
In Figure
Typical scenario with a roundabout where 4 traffic sensors and the access point are placed.
The central application will be the sink for all the measurements from every road and will run a server so users can access the information. The user part is a very simple Android application where you can specify the roads that you want to know. The application connects to the server and obtains the results in real-time. If the mobile has the global positioning system (GPS) available, you can also define the position where you want to know the information and when you get to this location, the application will show you the road’s state so your decision on next step in your path will be taken with this useful knowledge. Thus, route’s decision is taken in a much smarter way and minimizing the traffic jams. If the mobile device does not have GPS or it is not activated, the request must be carried out directly by the user when he/she wants to know the road’s state. It should be noted that the server constantly knows the road’s state for all the roads being monitored, and, thus, the request from the user only takes a couple of seconds to be ready at the user’s terminal.
An example of this scenario is illustrated in Figure
Example of two possible roads.
First road
Alternative road
Once the scenario has been briefly drawn, in this section, the hardware/software scheme proposed for obtaining these coarse estimations, with a simple architecture and design, is described. The architecture is divided into three parts, namely, the wireless sensor network, the central point, and the mobile part. In this paper, the focus is on the wireless sensor network part because the central point is only a piece of hardware/software that receives all the measurements from different access points and runs a server that sends the requested information by the users when it is inquired. The mobile part is a simple Android interface that allows the user to introduce his/her requirements and request the adequate information from the server. Thus, in the following, the paper will describe only the WSN, which is composed of both a hardware part and a software part.
As it has been indicated, a wireless sensor network has been used for the proposal, specifically, the MICAz motes from Crossbow. These very simple motes are composed of three parts, namely, (1) the MICAz OEM reference board where the radio frequency and signal processing modules are allocated, (2) the MTS310 sensor board, where several sensors are available, and (3) the power supply, which in this prototype is AA batteries but in the near future will be a small yet power efficient solar panel to provide enough energy to the mote.
The MICAz OEM reference board allows IEEE 802.15.4/ZigBee compliant wireless mesh networking nodes in the 2.4 GHz band with up to 250 kbps. In our prototype, a physical layer with less than 1 kbps is enough. The board provides a 128 Kb programmable flash memory where our algorithm and system can be allocated along with a 512 Kb memory for storing measurements. Actually, our implementation only needs less than 1 Kb of storage. The board also has 8 channels analog to digital converter (ADC) of 10-bit resolution for acquiring data from the different sensors. The maximum transmit power is 3 dBm and the sensibility is −94 dBm.
Connected to this reference board, there is a MTS310 sensor board. This MTS10 provides different sensors such as a microphone, a sounder, a light sensor based on a simple CdSe photocell, a thermistor from Panasonic (ERT-J1VR103J) for temperatures in the range from −40° to 70°, a 2-axis accelerometer from Analog Devices (ADXL202JE) with a range of
Finally, the 2-axis accelerometer is used to detect if the motes are being stolen. Since these systems are deployed through the roads without supervision, although they will be hidden, one could realize their presence and try to steal them. In this case, the mote detects the movement and activates an alarm. At the central point, the server could establish a mechanism for informing about this issue and the timing reference. With the traffic cameras and the time and direction obtained from the 2-axis accelerometer the thief could be located.
In Figure
The MICAz motes for vehicles’ detection.
MICAz mote
Installed MICAz motes
The other important part of the scheme is the software and the signal processing associated. The software at the motes has been programmed using the TinyOS, and the state diagram can be seen in Figure
State diagram at the motes.
The normal sequence for a mote is the following. The mote starts in
In Figure
Timing schedule for scenario in Figure
In the
The analysis of measurements at the motes is very simple. The magnetometer’s measurements are compared to a threshold estimated during the calibration of the system. This simple comparison is enough to estimate the presence or absence of a vehicle close to the mote. It should be noted here that this calibration procedure is simple and can be carried out before deployment.
As mentioned before, in order to reduce errors, an auxiliary measurement from a microphone is also acquired. The idea is to register the sounds in the surroundings of the mote to evaluate whether it is likely that a stopped vehicle is present or not. The signal analysis is also very simple. If the recorded signal is
Spectrum of a recorded 1 second of sounds from vehicles.
Slow motion vehicle
Moving vehicle
The data to be sent in a message will be the information received from the previous adjacent mote (this length will be different if the mote is number 2 or if it is number 3) and the information measured in the current mote: one bit per measurement from the magnetometer indicating if there is a vehicle or not and then one bit per measurement from the microphone indicating if there is a vehicle or not. This message is protected by using a parity check bit per measurement. Besides, each hour, the battery level is also sent once by the motes in their messages. In this way, the AP has an estimation about the battery level from all the motes. At the AP, all the measurements are received and processed to evaluate what the traffic level is. Some incoherent measurements or false positives or negatives can be solved. For example, if motes 1, 3, and 4 estimate that there is a stopped vehicle but mote 2 does not, it is easy to find that the estimation from mote 2 was erroneous, because it is highly likely that the queue reaches mote number 4 and, thus, also mote number 2.
The same principle holds for other situations or scenarios. For example, a vehicle crashes near the mote but the engine still runs although the vehicle is stopped and is outside the road. In this case, it does not interfere with the traffic and other vehicles can continue their trip. In this scenario, even though the mote will indicate that there is traffic jam until this point, since the other ones will not, this situation will be treated by the postprocessing as false positive and it will be automatically corrected and the given answer will be that there is no traffic jam, which is the correct one, indeed.
All the information from the AP is transmitted to the server to provide the service to the end users.
Although this system is focused on intersections or roundabout-like scenarios, if there is a congested long road, for sure it will collapse one or more closely placed roundabouts or intersections too, where our system can be installed, and, hence, those scenarios are also covered by this proposal, saving a lot of resources and obtaining similar results as other more complex systems.
The ITS is a hot topic nowadays in big cities and in particular when defining the future smart cities. There is large literature on proposals for dealing with this problem. However, in most of the cases, the proposals are too much complex and sophisticated providing much more information than required. In this paper, a simple yet low cost and energy efficient scheme is proposed to tackle the problem of avoidance of traffic jams. The proposed scheme is simple and only needs low cost hardware to be implemented. It is also energy efficient since the number of transmissions and the amount of information bits are significantly low, and the system has proven to work properly in a small-scale scenario. The future work is the deployment of a large-scale experiment with more roads being analyzed and a more powerful software at the server. Also, in order to reduce the battery drain, mini solar panels will be installed into each mote to supply the energy. In this case, the system maintenance is very low. Besides, a more sophisticated and complex mobile application could be designed based on these coarse estimations of the amount of vehicles.
Time between collecting messages—this is the time between two periods of collecting messages from other adjacent motes
Collecting time—this is the duration of the collecting time
Measuring time—his is the duration of a period of measuring
Time between measurements—this is the time between two periods of measurements
Updating time—this is the time between two updates in information per mote, that is, this time indicates how fast motes update their information.
The authors declare that there is no conflict of interests regarding the publication of this paper.
This work has been partially funded by the Spanish National Projects GRE3N-SYST (TEC2011-29006-C03-03) and COMONSENS (CSD2008-00010).