ABSTRACT

A system to track the location and performance data is being developed to further the advancement in fleet management and emergency responders. This design is reliant on three major technologies: GSM/GPRS, GPS, and ODB-II.

1. INTRODUCTION

Global Positioning System (GPS), which made its start as a military application, has become a viable tool for many commercial and personal applications. One such application has been a vehicle location tracking system (VLTS). These tracking systems incorporate a GPS receiver and a wireless transceiver that allow a remote unit to track the vehicles position [1]. The wireless communication network has been evolving to help with network traffic and effective throughput. An emerging standard for wireless communication is the Global System for Mobile Communication (GSM) technology. Figure 1 shows that many systems today use these technologies together to create a service for individual motorists, fleet operators, and

emergency responders. The need for a vehicle performance tracker has

been expressed [2]. Also emergency responders

could better handle a situation if they know what the circumstances are. A performance tracker coupled with the VLTS would give valuable information not only about where the vehicle is located but also how fast it is traveling, what is the engine RPMs, what is the oil pressure, and even what gear the vehicle is in. These statistics are just a few that could be captured with the OBD-II system, which is installed on most vehicles manufactured from 1996.

In this paper a VPPTS called “Bully’s Bus Tracker” is implemented. A background of the used technologies will be given in section 2. Section 3 will describe the implementation of the VPPTS. Section 3 will also describe the testing results and optimizations made. Section 4 will compare and contrast this system with other VLTS. Finally, Section 5 will consist of the concluding statements and future possibilities that could be extended to the current VPPTS.

2. BACKGROUND

This section gives a brief description of the underlining technologies used to implement the VPPTS.

2.1. GPS

GPS was developed by the U.S. Department of Defense. It consists of a constellation of 24 satellites, shown in Figure 2, orbiting around 11,000

Figure 1: Network Applications

Figure 2: GPS Constellation

A RELIABLE LOW-COST IMPLEMENTATION OF A VEHICLE POSITION AND PERFORMANCE TRACKING SYSTEM (VPPTS)

William Jenkins, Ron Lewis, Georgios Lazarou, Joseph Picone, Zachary Rowland

Center for Advanced Vehicular Systems, Mississippi State University

{wjenkins, lewis, glaz, picone, zrowland}@cavs.msstate.edu

miles above the Earth’s surface [3]. GPS was dedicated solely for military use and has recently been declassified for civilian use. GPS can be used for a variety of land, sea, and air applications. The main use is highly accurate position information [4].

GPS technology has increased its accuracy, using clever techniques and mathematical models, to within centimeters [3]. This accuracy can increase the effectiveness of a GPS-enabled device and the cooresponding application.

2.2. GSM/GPRS

GSM has become the world’s fastest growing mobile communication standard. It allows for seamless and secure connectivity between networks on a global scale. It uses digital encoding for voice communication and time division multiple access (TDMA) transmission methods to achieve such a reliable network [5]. While GSM was becoming the standard for person-to-person communication, the circuit switched network limited data transmission. General Packet Radio Service (GPRS) was developed to relieve this limitation.

GPRS is a data communication layer built over the GSM wireless communication layer. It has a theoretical max speed of 171.2 Kbps making it a viable choice for wireless data usage [5]. GPRS the remaining capacity leftover from GSM voice communication [6]. GPRS uses a packet format for data transmission. This allows for full compatibility with existing Internet services such as HTTP, FTP, email, instant messaging, and more. This

architecure can be summed up with Figure 3.

2.3. ODB-II

On-board diagnostic (OBD) systems are currently in most cars today. These systems were put into place to help manufacturers ensure their vehicles meet emission standards set forth by the Clean Air Act in 1970 and the Environmental Protection Agency (EPA). The Society of Automotive Engineers developed a set of standards and practices that standardizes the development of these diagnostic systems. The SAE expanded on that set to create the OBD-II standards. The EPA and the California Air Resources Board (CARB) adopted these standards.

OBD-II systems allows for monitoring of most electrical systems on the vehicle. Monitored items include speed, rpm, ignition voltage, and coolant temperature. This system can also tell an engineer when an individual cylinder has a misfire. The SAE recognized three communication patterns described in Table 1.

Protocols Type Manufacturer

SAE J1850 VPW

Variable Pulse Width GM

SAE J1850 PWM

Pulse Width Modulation Ford

ISO 9141 Two Serial Lines: Omnidirectional Multidirecitonal

European, Asia, and Chrysler

Table 1: SAE Recognized Protocols

3. VPPTS

Off-the-shelf items were used to assemble the VPPTS. A Garmin GPS 35-PC receiver was used. To gather OBD-II data a BR-3 OBD-II Interface, which uses BR16F84-1.07 microcontroller from Microchip, was used. A laptop equipped with two serial ports and a PCMCIA port was needed. A Sony Ericsson GC-82 EDGE PC card was used to access the Cingular Wireless GSM/GPRS network.

The data collecting software was developed with Microsoft C# using a Visual Basic 6 serial port class. All of the preceding items were used inside the monitored vehicle. Tomcat web server and MySQL were used to act as the gateway for the users to view the location and performance data of each vehicle. The user interface or applet was developed with JAVA SDK 1.4.2_05.

Detailed specifications on the data collector, server, and applet software will be discussed in the

Figure 3: GSM/GPRS Architecture

next sub-sections.

3.1. Data Collector

The data collector software combines the GPS coordinates and the OBD-II data into a single data stream that is sent to the server via GSM/GPRS network. The data retrieved from the OBD-II system is individually polled. This is done continuously. The transmission of data to the server is triggered by a received event from the GPS device, which is connected to a serial port. This allows for a one second maximum resolution.

The BR-3 OBD-II interface is connected to the vehicle via the SAE J1962 connector located within 3 feet of the steering column [7]. The BR-3 is connected to a serial port on the laptop. Figure 4 shows this connection diagram. The baud rate between the BR-3 and the laptop was 19200 with no handshaking. A CRC byte, specified by SAE J1850, is checked to confirm a successful transmission. All three communication protocols specified by SAE J1850 standard can be accessed with the BR-3 [8]. The performance parameters are specified as parameter identification (PID). The VPPTS uses generic PIDs specified in SAE J1979 [9]. These PIDs include vehicle speed, engine rpms, calculated throttle position sensor (TPS), engine load, engine coolant temperature, and air intake pressure. Car manufacturers such as GM and Ford have enhanced PIDs that are specific to their vehicles. A flowchart of communication is shown in Figure 6.

First the BR-3 must be initialized and, depending on the make of the vehicle, a proper protocol must be set. Once these are established polling for data will commence on a continuous basis. The GPS data comes as character arrays known as sentences. These sentences correspond to

the NMEA standard for GPS data [10]. The “GPRMC” sentence is grabbed which contains the

time, date, longitude, and latitude. The software parses the sentence and prepares the GPS data along with the current OBD-II data. The data is then sent to the server via GSM/GPRS.

3.2. Server

The server is a combination of services running on a dual processor PC. Tomacat, mysql, and apache make up the software needed to server the data and the applet. There are five Tomcat httpservlets that maintain the flow of data. Mysql is the chosen database manament service. Apache serves all the http pages and images.

The httpservlets handle all the connections made to the database server (MySQL). There are two servlets that receive data from the collector through an http post. The data is then updated to the database. The other servelets make querys to the database package the data into specialized classes and send the classes to the applet when the data is requested. Figure 5 shows the data flow to and from the server.

There are several tables in the database. The

Figure 4: OBD-II Connection Diagram

Figure 5: Server Data Flow

Figure 6: Data Collector Communication Flow

stops table contains a label and gps coordinates for each bus stop on all routes. The routes table contains a list of the routes and the order at which the stops are traversed. The buses table contains the current location and route information for each bus. The gauges database contains the telemetry data from each bus. There is also a table for each bus that contains all the past telemetry readings for that specific bus. This data will be kept for one month so it can be retrived for anaysis.

Apache is the portal to the World Wide Web. With this implementation the public can view the buses’ progress on their route.

3.3. Applet

The applet puts all the data together so that it can be viewed from the Internet. The applet is the user portal into the system. The applet displays the buses’ location on a digital map. The stops and the routes are also displayed onto the map. When a bus is selected the user can view the current vehicle gauge data via graphical gauges such as in Figure 7.

3.4. Testing and Optimization

Initially figuring out how to communicate with the BR-3 OBD-II interface was frustrating. It was later realized the data sent to the device should be byte arrays instead of character arrays, which is how the GPS data was formatted.

Another problem faced was a timing issue. A system timer was initially used to trigger an event that would send the GPS and current OBD-II data. The intervals that were wanted were between ¼ and 5 seconds. This small resolution could not be achieved because polling at least 6 PIDs took longer than ¼ seconds. To keep an accurate resolution the GPS signal was used as an event trigger. This kept the resolution at multiplesof one second.

Also the data collector would freeze up if a null byte was transmitted to the laptop. The data collector had to check for this string and disregard it to continue execution.

Origionally the server was a single processor Sun sparc. This server made debugging the communication very difficult. Our solution was to upgrade to a dual processor Intel architecure server. All of the services, which are open source, were installed and configure. The change was dramatic the errors in the code became obvious. The main problem was a class UID mismatch. This error was fixed by creating a data class that would be sent from the server to the applet. These classes, six in all, are faily simple in design.

The next major debug issue was drawing the buses and the stops on the map accurately use only the gps cordanates. A simple algorithm that uses the gps coordanites of the map corners was developed to translate the buses gps coordinates into a point on the map. The coordinates of the map corners where very hard to get exactly right. A best guess approach was taken. The approach was changing the

coordinates and checking the position of known points on the map.

Several bugs developed in the process of testing. On such problem was the data not being retrive upon initialization of the applet. This problem was found to be in relations to the number of allowed simultaneous connections to the database. This bug was

minized by manually closing the connections on the sever side and reconfigurein the database daemon to allow more simulatious connections. After this error was resolve a similar is arose from the maximum number of tomcat threads being exceeded. Tomcat was reconfigured to allow more threads. After another testing phase this bug seems to be resolved.

During thourgh testing of the system minor cosmetic and functionality bugs arose these bugs where traced and resoulved with minor code changes.

4. RELATED WORK

Many companies have put together similar systems that offer vehicle security and tracking. Systems

Figure 7: Performance Gauges

such as Trackn, OnStar, and TrimTrac offer remote lock mechanisms and roadside assistance. These companies provide this at a price. The VPPTS offers vehicle tracking using a well-established GSM/GPRS network. It also offers performance tracking for your vehicle. This is something unique to the VPPTS implementation.

The VPPTS is also extensible to many other applications. It could be used to help fleet managers know where and how there trucks, buses, or taxis are performing. This information could also be a warning system to fleet operators that their vehicle is operating in a compromised state. The OBD-II network could tell the owner where a problem exists in their vehicle.

Application related to emergency responders could use this system to know the condition of a vehicle before they reach the scene. This information could be sent to them via wireless network from the same database that holds the performance data retrieved by the VPPTS. This would help the responders make educated decisions as to how handle a certain situation.

5. CONCLUSION

In this paper a VPPTS was implemented. It uses existing technology to create a unique system. With GPS a vehicle’s location can be pin pointed to within centimeters. With GSM/GPRS network this location can be made available to a remote unit with access to the Internet. The preceding two technologies have made there way into many existing systems, which require a price for service. With the addition of performance data added to the system, the data increased its value tremendously. Now vehicle performance and location can be analyzed to help a company or individual with maintenance and efficient routing needs.

6. REFERENCES

1 . A. Wahab, T. Chong, N. Wah, O. Eng, W. Keong, “A Low-Cost Yet Accurate Approach to a Vehicle Location Tracking System,” IEEE ICICS, September 1997, pp 461-465.

2 . “’Black Boxes’ urged for cars,” http://www.cnn.com/2004/US/South/08/03/vehicle.black.boxes.ap/index.html, CNN.com, August 3, 2004.

3 . “All About GPS,” http://www.trimble.com/gps/, Trimble, 2004 August 4.

4 . “What is GPS,” http://www.garmin.com/ aboutGPS/, Garmin, 2004 August 4.

5 . http://www.gsmworld.com/technology/faq.shtml, GSMWorld, 2004 August 1.

6 . S. Ni, “GPRS Network Planning on the Existing GSM System,” IEEE GLOBECOM, Nov.-1 Dec. 2000, pp 1432-1438.

7 . SAE J 1962 April 2002, “Diagnostic Connector Equivalent to ISO/DIS 15031-3:December 14, 2001,” 2004 SAE Handbook, SAE international, 2004.

8 . SAE J 1850 May 2001, “Class B Data Communication Network Interface,” 2004 SAE Handbook, SAE international, 2004.

9 . SAE J 1979 April 2002, “E/E Diagnostic Test Modes Equivalent to ISO/DIS 15031:April 30, 2002,” 2004 SAE Handbook, SAE international, 2004.

10 . NMEA 0183 “Standard for Interfacing Marine Electronic Devices,” Version 2.0, National Marine Electronics Association, Mobile, AL, January 1992.