Real Time Vehicle Tracking System

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011

Muhammad Adnan Elahi

Department of Electrical Engineering COMSATS Institute of Information Technology Lahore, Pakistan aelahi@ciitlahore.edu.pk Institute of Information & Communication Tech. University of Sindh, Jamshoro, Pakistan lachhman@usindh.edu.pk

Institute of Mathematics & Computer Science University of Sindh, Jamshoro, Pakistan yasir.malkani@usindh.edu.pk

Yasir Arfat Malkani

Lachhman Das Dhomeja

Department of Electrical Engineering COMSATS Institute of Information Technology Lahore, Pakistan mfraz@ciitlahore.edu.pk

Muhammad Faraz

Shahzad Memon, Member IEEE

Centre for Electronics Systems Electronics and Computer Engineering Brunel University, London, UK Shahzad.memon@ymail.com

AbstractTracking systems were first developed for the

shipping industries to determine the position of ships and boats in the sea. Initially passive systems were developed to support in tracking and navigation for location-based applications. For the applications that require real time location information of the vehicle, these systems cannot be employed, because they store the location information in the internal storage that can only be accessed when vehicle is available. Recently, Automatic Vehicle Location (AVL) systems are developed and deployed in numerous environments. These systems are capable of transmitting vehicles location information in real time. In these systems, the device installed in the vehicle can transmit the location information in real time to a remote data centre, instead of storing into local storage, using some radio network. In this paper, we present the design and implementation of a real time AVL system that incorporates a hardware device installed in the vehicle and a remote Tracking Server (TS). Key wordsautomatic vehicle tracking, GSM/GPRS, positioning

Figure 1: Automatic Vehicle Location (AVL) system

I.

INTRODUCTION

Most of the modern vehicles tracking systems belong to the category of Automatic-Vehicle-Location (AVL) systems. Figure 1 illustrates the generic architecture of an AVL system.

AVL systems aid in determining the geographic positioning information of vehicles and transmitting it to a remotely located server. The vehicles location is determined using GPS, while the transmission mechanism can be satellite, terrestrial radio or cellular connection from the vehicle to a radio receiver, satellite or nearby cell tower. There may also exist some other alternatives for determining the location in the environments where GPS signal strength is poor, such as

Special Issue

Page 6 of 69

ISSN 2229 5208

dead reckoning [1], i.e. inertial navigation, active RFID systems [2] or cooperative RTLS systems [3]. After collecting positioning data, it is transmitted using some kind of telemetry or wireless communications systems. GSM is the most common used service for this purpose [4, 5]. In this paper, we are presenting our experience of developing an AVL system using GPS for positioning information and GSM/GPRS for information transmission. The design and implementation of the system includes acquisition and transmission of vehicles location information along with ignition and doors status information to the monitoring station/tracking server. Additionally, system also provides a web based interface to display all transmitted information to end user along with location of vehicle on a map. There are two basic components of the system: a hardware device called In-Vehicle-Unit (IVU) and a remote Tracking Server (TS). IVU has GPS receiver that receives signals from GPS satellites and calculates its position. This information is transmitted to TS using GSM/GPRS modem on GSM network. The information can be transmitted using SMS on GSM network or using direct TCP/IP connection with TS through GPRS. TS also has GSM/GPRS modem that receives vehicles location information via GSM network and stores this information in a database. This information is available to authorized users of the system via website over the internet. The rest of this paper is organised as follows: Section II describes the design and implementation details of the proposed system. It covers the hardware and software design of devices developed to determine and transmit the vehicles information, such as its location, to the remote TS. It also discusses the design of hardware used on the TS side, and the design of web based interface for user interaction. Section III discusses system testing and results. Section IV presents future work and concludes the paper.

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 IVU is designed using OEM module Telit GM862-GPS GSM/GPRS modem and microcontroller PIC18F248 manufactured by Microchip. Figure 3 shows the internal architecture of IVU. IVU would be installed into the vehicle. It is responsible for capturing the current location of vehicle, speed of vehicle, doors and ignition status. IVU is also responsible for transmitting this information to TS located anywhere in the world using SMS service available in GSM network or through GPRS. SMS is preferred for data transmission, since it does not require dedicated connection to the TS [6]. To achieve these functionalities IVU uses several modules, which are described below.

Ignition
Interface to vehicle

Data Transceiver GSM/GPRS Modem CPU/8-Bit Microcontroller

RS232

GSM Antenna

Door Status Vehicle I/O

PIC18F248

SiRF Star III GPS Receiver

GPS Antenna

GM862-GPS

Figure 3: Architecture of In-Vehicle-Unit (IVU)

1)

GPS Receiver

II. A.

SYSTEM DESIGN AND IMPLEMENTATION

System Architecture Figure 2 illustrates the high-level architecture of the system. Overall system is partitioned into two major design units: InVehicle-Unit (IVU) and Tracking Server/Monitoring Station (TS).
RS232 Wireless Transceiver Server Database

IVU uses GPS receiver to capture the current location and speed of the vehicle. Location and speed data provided by GPS is not in human understandable format. This raw data needs to be processed so that it can be converted into useful information, and then displayed on the map. CPU is required to perform the necessary calculations to achieve this goal. SiRF Star III single-chip GPS receiver [7] is used for this purpose, which comes integrated with GM862-GPS modem. GPS receiver can also provide information of altitude, time of GPS fix, status of GPS fix, and number of satellite used to compute current location information along with speed data. GPS fix means last reported location. For tracking purpose, only location and speed data is required; while the other data provided by GPS receiver can be used to determine the validity of location information. 2) Central Processing Unit (CPU)

Monitoring Station

Wireless Link

Internet

RS232 Wireless Transceiver CPU

RS232 GPS Receiver

In-Vehicle Unit

Figure 2: High-level architecture of the system

The raw data provided by the GPS receiver is captured by the CPU and processed to extract the required location and speed information. CPU is also responsible for monitoring the doors status and controlling the ignition status of the vehicle. CPU holds all the required information that is to be transmitted to remote TS. It also controls data transmission module to exchange information with remote TS. It actually acts as a bridge between GPS receiver, vehicle, and remote TS. It receives commands sent by server through data transmission/receiving module and performs corresponding action required by the server. The processing required in the IVU is not computationally intensive; therefore any low-end microcontroller can be used as a CPU. Microchips

Special Issue

Page 7 of 69

ISSN 2229 5208

PIC18F248 [8] is selected to serve as the CPU for IVU. This is an 8-bit microcontroller and runs at the speed of 20 MHz, which is enough speed for the system to operate smoothly. 3) Data Transceiver

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011

When all required information is extracted and processed, it needs to be transmitted to remote TS. TS is responsible for providing this information to the end user or application. We have used wireless network to transmit vehicles information to remote TS. Existing GSM network is selected to transmit vehicles information to remote TS, since it has wide coverage. It is also less expensive approach as compared to deploying our own network for transmission of vehicles information. GSM modem is required for data transmission over GSM network. It aids in the process of sending and receiving SMS text messages and other GPRS data over GSM network. GM862-GPS GSM/GPRS modem [9] is used for this purpose. GM862-GPS provides AT commands interface, i.e. all functions can be accessed using AT commands [10, 11]. AT commands can be sent to it using serial interface. It has built in UART that accepts the AT commands, and modem performs the function as described in received valid AT commands. B. GM862-GPS Interface Board Design and Testing

Figure 4: Interface board power supply schematic

First step in circuit design of IVU is to design interface circuit for Telit GM862-GPS so that it can be interfaced with microcontroller. Telit GM862-GPS provides several features including GSM Antenna connector, board-to-board interface connector, SIM card reader and GPS antenna connector. GSM, GPS antennas and SIM card are not important from design point of view, since these simply require to be installed into connectors. The important thing is board-to-board interface connector, which provides interface for external devices to the modem. The details of GM862-GPS can be found in [12]. Power supply circuit for GM862-GPS is designed by considering worst-case maximum current consumptions of GM862-GPS (i.e. 430mA) during GPRS data send operation; while the normal maximum current consumption is expected to be 187mA. The circuit shown in figure 4 is designed assuming +5V input source. LT1528 low dropout regulator [13] is used to convert +5V to 3.8V required by GM862-GPS. The regulator is optimized to handle the large load current transients associated with the current generation of OEM module. The detailed technical discussion of circuit designs for IVU is out of the scope of this paper.

It is not possible to build simulation model for the circuit designed for IVU, since there is no simulation model available for GM862-GPS in any EDA tool. It is also not possible to bread-boarding the whole design because GM862-GPS has board-to-board (SMD) molex connecter, and it is not possible to insert it into bread board. Therefore only few parts of the design are tested by breadboarding. Power supply circuit and level translation circuit are tested independently. All voltages and currents are measured and verified at input output pins. Communication interface board for GM862-GPS has an RS232 serial interface. It can be connected directly with any external device, which has RS232 interface. In this part of the design, PIC18F248 needs to be connected with GM862-GPS board so that it can operate the GM862-GPS GSM/GPRS modem by sending AT commands to GM862-GPS via serial interface. PIC18F248 has built in USART that operates on TTL logic levels. Using level translation circuitry TTL levels can be translated to RS232 levels. Microcontroller board is obtained off the shelf. PIC-P28 microcontroller has RS232 driver on the board, and In-Circuit-Serial-Programming (ICSP) circuitry that eliminates the need of comparatively expensive external programming task. Another RS232 driver is added to the microcontroller board for debugging purposes. Interface board is connected to the monitoring device (i.e. PC) using this RS232 driver to view the communication messages to and from GM862-GPS. C. Microcontroller Board

Figure 5 shows the circuit diagram of the microcontroller board. As it is clear from figure that RS232 level converter is not connected with any pin of microcontroller. These pins were manually connected through wires to the microcontroller UART pins. Pin 17(RC6) & 18(RC7) are dedicated pins for PIC18F248 hardware UART. 20MHz crystal oscillator is connected with microcontroller. Board was connected to GM862-GPS interface board using male-to-male serial cable as microcontroller board also has female DB-9 connector. Another RS232 driver was added to the microcontroller board for debugging purposes. Using this RS232 interface board was connected to PC to view the commands sent and response received from GM862-GPS. HyperTerminal software of Windows was used to view the debugging information sent by microcontroller. Same level translation circuit was used for RS232 interface as described in section 3.3-4 but MAX3232CPE was replaced with MAX232 and power supply

Special Issue

Page 8 of 69

ISSN 2229 5208

provided to MAX232 was +5V. Pin 13(RC2) & 14(RC3) pins are used for TX and RX respectively.

1)

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 Send AT Command

This subroutine is the basic routine, which handles all the communication with GM82-GPS. This routine accepts the string containing AT command input in its parameters and sends this string character by character to module. GM862GPS accepts carriage return (\r) as a command terminating character. As this character is received it sends back the response to microcontroller. This routine checks each character of string, if the character is not null, it will check the transmit buffer, which is hardware register of UART, contents. If transmit buffer is empty, it will write new character into the buffer. As soon as an 8-bit data is written into the transmit buffer, UART hardware transmits that character at the specified baud rate. Each character of the command string is sent by this way. When null character is found, which specifies the end of string, routine terminates by sending carriage return to the module. Response received from the module is handled in another subroutine. 2) Subroutine- Startup

Figure 5: Circuit Diagram for PIC18F248 board

Pin 21(RB0) is designated for vehicles ignition status. This pin will be connected to Vehicles ignition in order to monitor and control the ignitions status. Pin 22(RB1) is designated for vehicles door status. It will be connected to vehicles door circuitry in order to monitor weather doors are close or open. Board has a push button connected to pin 7(RA5) that is used as an emergency button. If this is pressed an emergency message will be sent to remote tracking server. D. In-Vehicle-Unit (IVU) Software Design

Startup routine is executed only when device is powered on. It initializes all hardware of the In-Vehicle unit and configures GM862-GPS. It performs various tests to ensure the GM862GPS is working properly and is ready to use. This subroutine starts with initializing peripherals of the microcontroller. All peripherals in use need to be initialized in this step. Direction of I/O ports is set here. RB0 pin controls the ignition therefore its direction is initialized to output. RB1 monitors the door status; its direction is initialized to input. RA5 has push button for emergency input; its direction is initialized to input. RC6 and RC7 are assigned to hardware UART as TX and RX. Baud rate for hardware UART is set to 115200 bps because it is connected to serial port of GM862-GPS. RC2 and RC3 are assigned to software UART used for debugging. Baud rate is initialized to 115200 bps. Timer is also initialized that will be used for timeout delays. After initializations of local peripherals, GM862-GPS needs to be tested. Microcontroller sends AT command to GSM module using subroutine Send AT Command. All commands sent to module are sent using this subroutine. If the device responds with OK, it means microcontroller can communicate with module. If device doesnt respond after expiry of timeout routine is restarted. If problem persists, definitely something in hardware is damaged. After receiving OK response from module various parameters of module need to be initialized. First of all local echo of module is disabled because module echoes back every character it receives. Local echo can be disabled using command ATE=0 and module responds with OK. Baud rate is specified using AT+IPR=115200 and expected response is OK. Extended error codes are enabled using AT+CMEE=1 and device responds with OK. SIM presence is checked by sending command AT+CPIN? If

Microcontroller is acting as processing unit for IVU and controls all of its operations. Microcontroller needs software to operate the whole system. We have written the code for software and burnt it into its flash memory. Software code is broken down into small modules as shown in figure 6. Excluding In-Vehicle Unit Software box, that is the main routine; all other boxes are representing a module. These modules are implemented as subroutines of main routine. Each subroutine performs series of its designated tasks. Main routine only calls the subroutines, as required. All subroutines are implemented in C language. Compiler used to generate machine language code for PIC18F248 is CCS PICC. The detail of each subroutine is described below.
In-Vehicle Unit Software

Configure InVehicle Unit

Startup

Send AT Command

SMS Configuration

Read GPS Data

Send SMS

GPRS Configuration

Send Information using GPRS

Figure 6: Breakdown of In-Vehicle Unit software.

Special Issue

Page 9 of 69

ISSN 2229 5208

device responds with +CPIN: READY message, SIM is ready to use. Any other response message will be considered as an error and routine will be restarted after expiry of timeout. When SIM card is ready, it is important to test whether module is connected to network or not. Network status can be tested with command AT+CREG? If module responds with +CREG: 0, 1 module is connected to network and data can be sent over network. If any other response is received module keeps on checking for network status until it connects to network. Once it makes sure that module is connected to network, subroutine is terminated. 3) Subroutine- Read GPS Data

GPS controller is by default powered on when module is switched on. This subroutine first of all checks whether GPS controller is powered on. To check this AT$GPSP? is sent to the module. If it responds with $GPSP: 0 it is not powered up. If it is not already powered up; it can be switched on by sending AT$GPSP=1. Once GPS controller is powered up location information can be read from it by sending AT$GPSACP. The module responds with a long NMEA sentence. The information of interest is latitude, longitude, speed, number of satellites used in calculating latitude and longitude. This information is extracted from the received response and saved in formatted string. This string can be later on passed to Send SMS subroutine to send it to remotely located Tracking Server. 4) Subroutine- Send SMS

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 This subroutine checks the SMS service centre number by sending the command AT+CSCA? Service centre number is required because SMS is routed to destination via SMS service centre. The module responds with +CSCA: number. If no number is present it can be saved in module by sending the command AT+CSCA= number, type type could be 145 if number is in international number format (i.e. it begins with +) or it could be 129 if number is in national format. When new message is received by module, an unsolicited indication is generated. This indication may be sent to microcontroller, and buffered if microcontroller is busy or discarded. In this case new message must be immediately sent to microcontroller or buffered if microcontroller is busy. This configuration can be done by sending command AT+CNMI=1, 1, 0, 0, 0 when GSM modem receives a new message it will send +CMTI: SM, message index no where message index no is location of message in memory and it can be then read by sending command AT+CMGR=message index no. After configuring new message behavior module is set to Text mode for SMS. It can be done by sending command AT+CMGF=1. All configuration related to SMS is finished and subroutine terminates. 6) Subroutine- Configure GPRS

When GPRS service is available, it is cost effective and more efficient to transmit vehicle information through GPRS. In order to connect to GPRS, it needs to be configured. Figure 7 shows the steps required to configure the GMS module for GPRS data transmission.
Start

This subroutine accepts message string as input parameter which needs to be transmitted. Subroutine adds a terminating character Ctrl-Z at the end of message string. Then it checks whether module is in Text SMS mode. It can be checked by sending command AT+CMGF? If module responds with +CMGF: 0 it is in PDU mode. Mode can be changed to text by sending command AT+CMGF=1. To send an SMS module requires destination phone number that is sent to module using command AT+CMGS= da where da represents the destination phone number. This phone number will be read from microcontroller internal memory, which is stored during programming. After sending destination number, module waits for prompt >. When prompt appears, message string is sent using Send AT Command subroutine. If message is sent successfully, module responds with +CMGS: <mr> where mr is a message reference number. If any error occurs, subroutine tries to resend the message until it is successfully sent. 5) Subroutine- SMS Configuration

Define GPRS context

Setup Quality of Service

Configure TCP/IP Stack

Allow server to connect to module

Activate GPRS context

SMS configuration subroutine is called after startup routine. It is basically called once after powering up the In-Vehicle unit like startup routine. It can be part of startup routine but it is separated because it does configuration of the module related to SMS only.

End
Figure 7: Flow chart of subroutine configure GPRS

First step in configuration of GPRS is to define GPRS context. It is set of information to identify the internet entry point interface provided by the ISP. With these parameters, the GPRS network identifies the ISP to be used to gain access to

Special Issue

Page 10 of 69

ISSN 2229 5208

the internet and defines the value of IP address of the GPRS device once connected. The command sent for defining GPRS context is AT+CGDCONT=1, IP, payandgo.o2.co.uk, 0.0.0.0, 0, 0. First parameters is context id, it is possible to define up to 5 contexts. Next parameter is protocol used for communication, third parameter is APN assigned by network server provider. In next step subroutine sets the parameters for Quality of service. Commands used are AT+CGQMIN= 1,0,0,0,0,0 and AT+CGREQ=1,0,0,3,0,0. These parameters are recommended by manufacturer of the GSM module. Along with APN network service provider also provides user name and password to connect to ISP. Next step is to set user name and password for current GPRS context. Commands used are AT#USERID=payandgo and AT#PASSW=password. Next step configures the TCP/IP stack. It basically sets the minimum packet size, data sending timeout and socket inactivity timeout. Command used for configuring TCP/IP stack is AT#SCFG=1,1,140,30,300,100. First parameter of command is connection identifier, next parameter is context identifier for which stack is being configured. 300 is the minimum number of bytes that will be sent in one packet. Next parameters are inactivity timeout, connection timeout, and data sending timeout. Next step of the subroutine is to configure the firewall settings. It allows certain computers to connect to module. In this case, server IP address will be provided to firewall so that tracking server (TS) can connect to In-Vehicle unit. Command used for firewall settings is AT#FRWL=1,server ip, subnet mask. Server IP address will be the IP address of Tracking server and subnet mask can be provided to allow access to range of computers. Last step is activate current GPRS context. Command is AT#SGACT=1, 1. First parameter is context id to be activated and next parameter is status i.e. 1 for activation and 0 for deactivation. 7) Subroutine-Send Information Using GPRS

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 Read GPS data subroutine is appended with status of I/O ports. Socket connection is resumed and information is sent to Tracking server on this socket. If In-Vehicle unit is configured for continuous transmission of vehicle information after regular intervals, all above steps are repeated otherwise module waits for incoming requests from Tracking server. If location request is received above steps are repeated and if any other command is sent by the server, an action is taken accordingly. Server can send request for vehicle shutdown, changing the data transmission from GPRS to SMS or changing the continuous transmission to polling or vice versa, restart the In-Vehicle unit. This subroutine ends only when InVehicle unit is restarted by Tracking server. 8) Main Routine of In-Vehicle Unit

Main routine just calls the subroutines described in previous sections. With the start of main routine, call is made to Startup routine that initializes all peripherals and In-Vehicle unit configurations. It checks for stored configuration to decide whether data transmission should be through GPRS or SMS. If configuration says for GPRS, call is made to GPRS configuration routine and then GPRS data sending routine is run. If configuration is for SMS, configuration is done and InVehicle unit starts sending the vehicle information to Tracking server via SMS either continuously after regular intervals or it waits for commands from Tracking server as SMS. GM862GPS is configured in such way that whenever new SMS arrives, an indication is received by microcontroller with message identifier. This message is read by the microcontroller and corresponding action is performed. E. Design of Tracking Server (TS) Figure 8 illustrates the architecture of TS. TS maintains the information received from all of the IVUs installed in different vehicles in a database. This database is accessible from internet to authorized users through a web interface. Authorized users can track their vehicle and view all of the legitimate information stored in the database. TS has a GSM/GPRS modem attached to it that receives SMS messages from IVUs and sends them to the TS through serial port. Design of TS can be divided into four major parts: Hardware design for GSM/GPRS modem (GM862-GPS), communication software for GM862-GPS, database design & management, and web interface.

Once In-Vehicle unit is configured to send information using GPRS, all its activities are controlled by this subroutine. In order to send data over IP network application needs an interface to physical layer. This interface is named as socket. This subroutine starts with opening socket for currently configured TCP/IP stack. Command used to open socket for configured embedded TCP/IP stack is AT#SD=1, 1, 6534, www.comsian.net. First parameter is connection identifier of TCP/IP stack, 2nd is protocol i.e. 0 for TCP and 1 for UDP. Next two parameters are port number and IP address/host name of Tracking server respectively. If command returns the response CONNECT; this means connection is accepted and data can be sent now. After getting connection, socket is suspended using escape sequence +++ to bring module in command mode. Socket remains connected while it is suspended. When GPRS connection is alive, module cant accept AT commands and GPS data cant be read from module. Once module is in command mode this subroutine calls the routine Read GPS data which provides the information string that is to be sent to Tracking Server. Next step is to read I/O ports of microcontroller to get vehicles door and ignition status. Information string received from

Internet Database

Data Transceiver GSM/GPRS Modem

RS232

GSM Antenna

Server

Computer

SiRF Star III GPS Receiver (Not in use)

GM862-GPS

Figure 8: Architecture of Tracking Server (TS)

Special Issue

Page 11 of 69

ISSN 2229 5208

GM862-GPS is the same GSM/GPRS modem that is used in IVU. It is used on server side to exchange information with IVUs through SMS. Vehicles information sent by IVU through SMS is received by this modem on TS. TS can also send commands to IVUs using this modem. GM862-GPS interface board is connected to the serial (COM) port of server and server can communicate with modem using AT commands. To send and receive data using this modem communication software is required. The communication software provides communication interface to the GM862GPS modem attached to the computers serial port. It is responsible for communicating and controlling the operations of GM862-GPS. Figure 9 shows the data flow of the communication software. Main program listens for SMS messages. It handles all of the communication with IVUs using SMS. It creates a separate thread for listening to TCP/IP connections, which receives incoming connections from IVUs and creates a separate thread for each incoming connection. It allows any number of IVUs to connect the remote TS.

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011 microcontroller during its operation. It is noted that the laptop is used only for debugging and testing purposes. After connecting the GSM and GPS antenna to the IVU, the system is powered on. When powered on, it executes Startup routine. Figure 10 shows the execution of Startup routine. It reads and displays the existing configuration of the system. Messages as shown in figure 9 describe that transmission method for this configuration is SMS and mode of transmission is dependent on received command from TS.

SMS

GM862-GPS

Class COMPort
Command

SMS

Internet

Figure 10: Results of execution of Startup routine.

Command

Class Modem
SMS

Vehicle Info

Command

Vehicle Info

Vehicle Info

Class VehicleInfo

Class TCPIP

Web Front End Database

Command

Figure 9: Data flow of communication software

Database is designed to store all of the relevant information of vehicles, such as In-Vehicle units and users of the system. To display this information to the end-users a front end application/software is required. End-user is the user of the system who has installed the IVU in his/her vehicle. The administrator of the system, who is responsible for all the activities going on in the tracking system, also requires access to this information. This is achieved by developing a web interface for end-users and administrator. III. SYSTEM TESTING AND RESULTS System design needs to be verified by testing after integration of all components of the system. PCB is designed for IVU and hardware required for the server to communicate with IVU has been integrated with the server. After integrating all the components, system is tested and successful working of the system has been observed. GM862-GPS interface board is connected to microcontroller board through a serial cable. Debugging serial port of IVU is connected to the laptops COM port to observe the debugging messages generated by the

Figure 11: Results of execution of SMS configure routine.

Figure 11 shows the execution of SMS configuration subroutine. After SMS configuration, it reads the GPS data from module, extracts/processes information and starts sending it to the remote TS. Figure 12 and 13 demonstrates the whole process, including commands and responses, generated during the first cycle of execution of the implemented system. +CMGS: 15 response in figure 11 shows that SMS is successfully sent.

Special Issue

Page 12 of 69

ISSN 2229 5208

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011

Figure 12: Result of execution of SendSMS and ReadGPS routine (waiting for command from server) Figure 15: Pointing out current location of vehicle.

It shows the information after successful log-in operation by a valid user. Map is indicating the location of MSc. Lab 4B12 in Engg II building at University of Sussex, where this whole system is tested. The information displayed is real time information excluding the speed, direction, door and ignition status information, because these tests are not performed by installing the IVU into a vehicle. IV. CONCLUSION AND FUTURE WORK

Figure 13: Sending information on request from server.

In order to test TS, laptop is configured to act as a server. GM862-GPS COM is connected to COM port of the laptop. Apache web server is running and MySQL DBMS is installed on the laptop. Figure 14 demonstrates the successful execution of communication software for GM862-GPS. It shows that communication software, after opening the communication port, configures the server module. After successful configuration, it sends location request to the IVU with SIM card no 07874838126. Finally, it receives the location information sent by the IVU.

Real time vehicle tracking system is successfully implemented using SMS of GSM network, and GPRS as transport channel to achieve the desired properties of Automatic Vehicle Location (AVL) system. Currently, InVehicle-Unit (IVU) is implemented with two boards. Microcontroller board is externally connected to GM862-GPS interface board. Single board can be designed to incorporate microcontrollers circuitry on the GM862-GPS interface board. It will reduce the overall size of IVU. It will also reduce the number of components, so the cost as well. Currently both boards have RS232 level converter circuit, which is not required when microcontroller will be directly interfaced with GM862-GPS. Further, an advanced user interaction will be employed into IVU to allow drivers to exchange information with the remote TS during driving the vehicle. For example, a driver should be able to send an emergency message or guidance request to the remote TS. Our future work also includes remote vehicles diagnostics. It will be provided through vehicles on board diagnostic system, which helps in controlling the vehicle (e.g. doors, engine and other possible systems) from a remote location.

Figure 14: Logs of TS.

ACKNOWLEDGEMENTS This paper is extended version of the paper appeared in the IEEE proceedings of 2nd International Conference on Computer, Control and Communication (IC4-09), February 2009.

Figure 15 shows the web interface designed as a part of system implementation.

Special Issue

Page 13 of 69

ISSN 2229 5208

REFERENCES
[1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] S. Ritier and J. MCCoy (1977). Automatic Vehicle Location: An overview. Vehicular Technology, IEEE Transactions, Vol. 26 Issue 1. Pg. 7-11 RFID: An Introduction (2008). http://msdn.microsoft.com/enus/library/aa479355.aspx Automatic vehicle location (2008). Wikipedia http://en.wikipedia.org/wiki/Automatic_vehicle_location Transportation District's Automatic Vehicle Location System (2008) http://www.itsdocs.fhwa.dot.gov//JPODOCS/REPTS_TE/13589.html Vehicle Tracking Systems Overview (2008) http://www.roseindia.net/technology/vehicletracking/VehicleTrackingSystems.shtml N. papadoglou and E. Stipidis (2001). Investigation for a global system. IEEE transactions on Intelligent Transportation Systems (ITS), Vol. 2, Issue 3, pp121-126. SiRF Star III GSD3tw High Performance, Satellite Signal Processor, Host Coupled Single Die. 1065-0185 (July 2008). SiRF Technology Inc. PIC18F2480/2580/4480/4580 Data Sheet. DS39637C (2007). Microchip Technology Inc. GSM/GPRS Module GM862-GPS v4.0 (2006). Round Solutions. AT Commands Reference Guide. 80000ST10025a (2007). Telit Wireless Solutions. GM862-GPS Software User Guide. 1vv0300729 (2007). Telit Wireless Solutions. J.B. TSUI (2000) Fundamentals of Global Positioning System Receivers. 1st Edition. John Willey & Sons Inc. Low Dropout Regulator for Microprocessor Applications. LT0508 (2007). Linear Technology Corporation. Easy GPRS User Guide. 80000ST10028 (2007). Telit Wireless Solutions.

International Journal of Computer Information Systems, Vol. 3, No. 3, 2011

AUTHORS PROFILE

Muhammad Adnan Elahi is a Lecture in the COMSATS Institute of Information Technology, Lahore Campus, Pakistan. He is also working as a Research staff in Computer Vision Research Group of the COMSATS. He received his MSc degree in Embedded Digital Systems from University of Sussex, United Kingdom in 2009. His research interests include Microprocessor & FPGA based design, GPS based Tracking & Navigation systems. Dr. Yasir Arfat Malkani is a Lecturer at the Institute of Mathematics and Computer Science (IMCS), University of Sindh, Jamshoro, Pakistan. He go his Masters degree in Computer Science from University of Sindh, Jamshoro (Pakistan) in 2003 and PhD from University of Sussex, Brighton, UK in 2011. His main area of research is Pervasive Computing. His research is focused on secure device/service discovery and access control mechanisms using policies and location/proximity data/information. He is also interested in sensor networks, wireless networks (including WiFi, Bluetooth, WiMAX, etc), and solutions to various issues in distributed and pervasive computing systems through the integration of tools and techniques from distinct disciplines/areas Dr. Lachhman Das Dhomeja is an Assistant Professor at the Institute of Information & Technology (IICT), University of Sindh, Jamshoro, Pakistan. He has done his PhD from University of Sussex, UK in 2011. His main research area is Pervasive Computing in general and policy-based context-awareness in particular. His other research interests include Distributed Computing and Information Systems. Muhammad Fraz is a Lecturer in the COMSATS Institute of Information Technology, Lahore Campus, Pakistan. He is also working as a Research staff in Computer Vision Research Group of the COMSATS. He received his MSc degree in Embedded Digital Systems from University of Sussex, United Kingdom in 2009. His main area of research interest is Video Processing on DSPs. Shahzad Memon is a member of IEEE. He is an Assistant Profeor at Institute of Information and Communication Technology at University of Sindh, Pakistan. He is doing his PhD in Electronics and Computer Engineering at Brunel University, London, UK. His research interests are Information Systems Engineering, wireless communication, Systems Security, Biometrics, Multimedia Systems & Design, eLearing and eGovernment. Mr. Memon is also member of IEEE, USA. IET,UK. and IAENG, USA.

Special Issue

Page 14 of 69

ISSN 2229 5208