Safe driving using wireless monitoring units.
Nasui, Dorel Vasile ; Rancea, Irina ; Sgarciu, Valentin 等
1. INTRODUCTION
The system target is to connect all trailers of a company in order
to have a better management of their delivers. The necessity of such a
system is driven by reasons like meeting timetables for delivering
products, have a real-time overview of the location of all vehicles
equipped with such a system. (Cui & Ge, 2003) Our experimental model
consists of a number of ten trailers equipped with SafeMobile units.
These trailers have to be delivered in five different locations from our
country.
The principle goal of our project is to create semiautonomous
robots that can deliver the products on a large roadmap with small human
interaction from a central command center. The purpose of this paper is
to create the software framework for such a system and make simulations.
The wireless monitoring system can control and monitor the mobile
assets from a command center through a software application called
SafeDispatch that is part of the SafeMobile's Asset Management
System line of business products. (Mahmood, 2006) With SafeDispatch the
human user can obtain real-time information about the monitored
vehicles, such as location, driver tracking information, performed
routes vs. planned routes and a lot of information from the sensors
connected to the unit--radiation detectors, smoke detectors, gas
detectors, anthrax detectors, temperature detectors, pressure sensors,
temperature sensors, proximity sensors and video images from the
video-camera installed on the unit.
2. SYSTEM ARCHITECTURE
Each vehicle is equipped with a SafeMobile unit. All the sensors
are connected and available to send their data. The units can receive
commands from command center and can communicate with the command center
sending their status information.
[FIGURE 1 OMITTED]
[FIGURE 2 OMITTED]
SafeMobile Asset Management System (Fig. 1) consists of three main
components: the Remote Unit, the Communication Platform and the Software
Application (SafeNet/ SafeDispatch). The Remote Units are available for
transmission over a variety of wireless network.
2.1 Remote Unit
For our experiment we have chosen Open Enterprise AVL solution--the
most complete information management solution tat offers a very robust
platform for any type of vehicle location and sensors.
The unit allows connecting the largest variety of sensors. Sensors
can be connected to all the other units that have at least one
RS232/analog/digital input. The technical specifications for Open
Enterprise AVL (Fig. 2) are:
* Computing platform--Intel ARM9 PXA270
* OS/Software framework--Windows: CE, XP Embedded or Linux: Debian
* Digital signal processing--Freescale 56F83xx
* Interfaces--2 x External Analogical Inputs, 8 x Digital Inputs, 2
x Digital Outputs, CAN Interfacing, 2 x RS232, 2 x USB, Ethernet 100 MB
* Location technology--16 channels/SiRF-III GPS The communication
platform can be: Cellular GSM, Cellular eDEN, WiFi, TETRA, Ethernet,
Bluetooth.
2.2 Sensor Network
Open Enterprise AVL can be connected to any type of sensor if the
sensor has an analog/digital/RS232 output. For RS232 output, the unit is
performing an internal unpacking of the data. For digital output the
threshold voltage is 7V. For analogical output the value is read from
the pins and converted through a CAN.
The data received from the sensors is packed into a message that is
sent to the central gateway through a wireless communication platform.
On the Gateway the message is unpacked and then packed in an XML format
that is sent to the software application through SSL protocol. In Fig. 3
there are represented different types of sensors that can be connected
to the Open Enterprise AVL Unit.
2.3 Communication Platform
The communication platform is represented by the following states:
* The GPS module sends its data to the processor
* The processor collects data sensors and processes them
* All the data are packed and sent through the communication
platform to the central Gateway
* The Gateway unpacks the data and loads them in databases
[FIGURE 3 OMITTED]
2.4 Gateway Architecture
The Gateway is a software application capable of receiving data
from units and unpacked them for loading in the SafeMobile databases.
The Gateway has a backup module--if one connection to a Gateway cannot
be established, then the backup module is used. When the Gateway is
trying to establish a connection to the servers, it selects from a
priority list (three of them can be set). (Dobrescu et al., 2008)
Our solution is proposing a distributed star topology for the
Gateways (Fig. 4). All the computers in the star topologies are
connected to central devices like hub, switch or router.
A star network generally requires more cable than a bus topology,
but a failure in a star network will only take down one computer's
network access, and not the entire network. On the other hand, if the
hub fails, the entire network will also fail. In order to avoid a
general crash because of the router's failure, two routers
connected in a parallel scheme are used. (Chisalita
& Shahmenhri, 2002)
3. SOFTWARE APPLICATION
The final user is monitoring all the SafeMobile units with a
software application called SafeDispatch/SafeNet. SafeNet is
SafeMobile's web-hosted application which allows users to access
their fleet via an Internet connection. Some of the features offered by
SafeNet are: excessive speed monitoring, event recording, historical
position reports, vehicle poling, alarms. SafeNet is using Oracle
Application Server Grid.
SafeDispatch is SafeMobile's client hosted application; it
provides a rich graphical user interface to the dispatch and
automatically plots units' positions using Microsoft MapPoint. The
major features for SafeDispatch are: creating tabs to track vehicles,
checking the speed vehicle and monitoring different routes that the
vehicle performs; information about routes performed vs. routes planned;
driver tracking information; map interactive features such as driver
directions based on vehicle current location, finding nearby vehicles
and place of interest
SafeDispatch allows tracking units through different tracking tabs;
live tab displays real-time information about the mobile assets; history
tabs show history information on selected units. SafeDispatch has a
module alarm that is activated by an extern event sent by the unit.
Units can generate events such as: changing the state for an analogical
input (opened/closed door, panic button on/off), passing a threshold
speed. The available reports in SafeDispatch are: Speeding Report, End
of Day Report, Stops/Stops with Engine on, Fleet Report and Geo-fencing
Report.
[FIGURE 4 OMITTED]
4. EXPERIMENTAL RESULTS
Our experiments were made inside of a laboratory where we create a
small roadmap. We used ten cars equipped with SafeMobile units. The cars
could be turned on/off manually and they are using batteries as supply
power. (Huang, 2006)
From the command center we send messages to the SafeMobile units
containing the map created on the laboratory and the planned route. The
component en charge with moving the car is collecting the information
sent through the wireless network, unpacked them in a more appropriate
format for a machine and then execute them.
We test a part of the sensors in order to see the car's
behavior in an emergency situation. We put a small burning candle inside
the car. The behavior was the expected one: the car stops and sends an
alarm signal to the command center.
The major problems that we noticed are related to crossing streets.
Every car has his own command component that is not communicating with
the other command components of the others cars. The car is able to stop
at the crossing streets but it's not able to let other car to pass
if the driving rules impose it. The both cars stop with engine on in
such a situation. As future work we are planning to enlarge the cars
capabilities of taking decisions at crossing streets. At this moment
when the cars cannot make a decision an alarm signal is sent to the
command center and the human user is taking that decision and passing it
to the cars.
Another problem of our system is the reduced life-time of the
supply batteries. We have to change them very often.
5. FUTURE WORK
As future work we are going to implement the following features for
our system:
* Improve taking decisions algorithm especially for the crossing
streets
* Add traffic roundabout capabilities
* Use the video camera as image recognition system for driving
indicators and semaphores
The next experiment for our system will consist in a real car
equipped with SafeMobile unit and the decisions component. We will make
a roadmap with our university campus and let the car running on this
map.
6. REFERENCES
Chisalita, I.; Shahmenhri, N. (2002). A Peer-to-Peer Approach to
Vehicular Communication for the Support of Traffic Safety Application,
The 5th IEEE Conference on Intelligent Transportation Systems,, pp.
336-341, Singapore, 2002
Cui, Y.; Ge, S.S. (2003). Autonomous vehicle positioning with GPS
in urban environments. Robotics and Automation IEEE Transaction, Vol.
19, page numbers 15-25, ISSN:1042-296X
Dobrescu, R.; Taralunga, S.; Mocanu, S. (2008). Parallel Internet
Traffic Simulator with Self-Similar Scale-Free Network Models, WSEAS Transactions on Advance in Engineering Education, pp. 61-68, ISSN
1790-1979, vol.5, 2008
Huang, G. (2006). Control the vehicle flow via GPS monitor centre,
Proceedings of the 6th WSEAS International Conference on Signal
Processing, Computational Geometry & Artificial Vision, World
Scientific and Engineering Academy and Society (WSEAS) (Ed.), pp.
174-181, ISBN 1790-5117, ISSN 960-8457-51-3, Elounda, Greece
Mahmood, F. (2006). GPS and Remote Sensing for Emergency Vehicle
Navigation and Communication, Conf. Advances in Space Technologies, pp.
33-36, ISBN 1-4244-0515-7, DIO 10.1109/ICAST.2006.313793