This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.
Vehicle Diagnostic Monitoring System is a new dimension in the field of Automobiles. It consists of an On-Board Diagnostic System which is a core element of all the modern day vehicles, and a communication system.
The proposed system collects the data from the vehicle's On-Board Computer and sends it to a remote server through a wireless modem on request, to monitor the performance and maintenance statistics.
This system can enhance Vehicle's performance by periodic inspections from remote locations.
On-Board Diagnostics, or OBD, is used to monitor vehicle's self-diagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access to state of health information for various vehicle sub-systems. The amount of diagnostic information available via OBD has varied widely since the introduction in the early 1980s of on-board vehicle computers, which made OBD possible. Early instances of OBD would simply illuminate a malfunction indicator light, or MIL, if a problem was detected-but would not provide any information as to the nature of the problem. Modern OBD implementations use a standardized fast digital communications port to provide realtime data in addition to a standardized series of diagnostic trouble codes, or DTCs, which allow one to rapidly identify and remedy malfunctions within the vehicle.
The proposed project is to design a system which extract data from a vehicle's On-Board Diagnostic System through CAN Interface and then sends it to a remote server through GSM Modem.
The LCD attached with the proposed device will help to display the data on spot, but the proposed system will take this data along with vehicle's identification to a remote server for storage and statistical analysis received from all other vehicles.
The information of the vehicle e.g. model, engine number, registration number and chassis number will be configured on the device which will be sent along with the error code every time.
On the remote server we will develop an application which will store and integrate the information coming from different vehicles and analyze the performance on base of these statistics.
Vehicle Side Hardware:
Interfacing with OBD-II.
Interfacing with GSM Modem.
Interfacing with LCD.
Vehicle Side Software:
Communication on CAN Bus.
Information Display on LCD.
Communication on RS-232 protocol.
Server Side Software:
Receiving of Information from vehicle through Internet.
Database design to store vehicle information and engine codes.
Web base GUI to display this information.
Vehicles can be self-monitored and problems can be easily diagnosed. Self-diagnosis by users is possible using hand held devices, which is cost-effective and easy to use.
It reduces the cost as we can use desktop computers instead of PDA's and specially designed hand held devices to get data from vehicle remotely.
Data from different parts of a vehicle can be brought to a remote server and can be analyzed in various forms e.g. graphs, charts etc.
Vehicle Manufacturers can analyze the performance of their new models remotely and can improve features in their upcoming models.
CHAPTER # 2: TECHNICAL BACKGROUND
On-Board Diagnostics, or OBD, in used to monitor vehicle's self-diagnostic and reporting capability. OBD systems give the vehicle owner or a repair technician access to state of health information for various vehicle sub-systems e.g.: temperature,fuel,speed,rpm etc.
1969: Volkswagen introduced the first on-board computer system with scanning capabilities.
1975: Datsun 280Z introduced the on-board computer for real-time tuning of fuel injection systems. Simple OBD implementations appear, but there was no standardization of the vehicle monitoring.
1980: General Motors implemented an interface and protocol for testing of the Engine Control Module (ECM) on the vehicle assembly line.
1986: An advanced version of the ALDL protocol appeared on vehicles which communicated at 8192 baud with half-duplex UART signaling.
1987: OBD-I was invented: OBD-I was largely unsuccessful, because the reporting emissions-specific diagnostic information was not standarized.
1988: The Society of Automotive Engineers (SAE) recommended a standardized diagnostic connector and set of diagnostic test signals.
1994: OBD-II was invented: The diagnostic trouble codes and connector suggested by the SAE(society of automotive engineers) are incorporated into this specification.
1996: The OBD-II specification was made mandatory for all cars sold in the United States.
2001: The European Union makes EOBD mandatory for all petrol vehicles sold in the European Union.
2008: All the cars which were sold in the United States required to use the ISO 15765-4 signaling standard.
2010: HDOBD (heavy duty) specification is made mandatory for all the selected commercial (non-passenger car) engines sold in the United States.
The purpose of OBD-I was to encourage auto manufacturers to design reliable emission control systems for the vehicle's "useful life". OBD-I was unsuccessful, because the reporting emissions-specific diagnostic information was not standardized.
OBD 1.5 is the partial implementation of OBD-II which General Motors used on some of the vehicles in 1994 and 1995.
An OBD 1.5 scan tool is required to read codes generated by OBD 1.5.
OBD-II Signal Protocols
SAE J1850 PWM (pulse-width modulation - 41.6 kB/sec,)
SAE J1850 VPW (variable pulse width - 10.4/41.6 kB/sec,)
ISO 9141-2. This protocol has an asynchronous serial data rate of 10.4 kBaud.
ISO 14230 KWP2000 (Keyword Protocol 2000)
ISO 15765 CAN (250 kBit/s or 500 kBit/s).
Pin 2 - J1850 Bus+
Pin 4 - Chassis Ground
Pin 5 - Signal Ground
Pin 6 - CAN High (J-2284)
Pin 7 - ISO 9141-2 K Line
Pin 10 - J1850 Bus
Pin 14 - CAN Low (J-2284)
Pin 15 - ISO 9141-2 L Line
Pin 16 - Battery Power
OBD-II CODES GENERATED BY MODERN VEHICLES:-
OBD-II codes consist of a number of parts. Here is a sample OBD2 code:
Here is a breakdown of what each digit of the code means:
First Character - System
The first character identifies identifies the system related to the trouble code.
P = Powertrain
B = Body
C = Chassis
U = Undefined
Second Digit - Code Type
The second digit identifies whether the code is a generic code (same on all OBD-II equpped vehicles), or a manufacturer specific code.
0 = Generic (this is the digit zero -- not the letter "O")
1 = Enhanced (manufacturer specific)
Third Digit - Sub-System
The third digit denotes the type of sub-system that pertains to the code
1 = Emission Management (Fuel or Air)
2 = Injector Circuit (Fuel or Air)
3 = Ignition or Misfire
4 = Emission Control
5 = Vehicle Speed & Idle Control
6 = Computer & Output Circuit
7 = Transmission
8 = Transmission
9 = SAE Reserved
0 = SAE Reserved
Fourth and Fifth Digits
These digits, along with the others, are variable, and relate to a particular problem. For example,a P0171 code means P0171 - System Too Lean (Bank 1).
In February of 1986, Robert Bosch GmbH introduced the serial bus system Controller Area Network (CAN) at the Society of Automotive Engineers (SAE) congress for use in cars, to provide a cost-effective communications bus for in-car electronics and as alternative to expensive, cumbersome and unreliable wiring looms and connectors.
The goal was to make automobiles more reliable, safe and fuel efficient while decreasing wiring harness weight and complexity.
History of CAN
1983: Start of the Bosch internal project to develop an in-vehicle network
1986: Official introduction of CAN protocol
1987: First CAN controller chips from Intel and Philips Semiconductors
1991: Bosch's CAN specification 2.0 published
1991: CAN Kingdom CAN-based higher-layer protocol introduced by Kvaser
1992: CAN in Automation (CiA) international users and manufacturers group established
1992: CAN Application Layer (CAL) protocol published by CiA
1992: First cars from Mercedes-Benz used CAN network
1993: ISO 11898 standard published
1994: 1st international CAN Conference (iCC) organized by CiA
1994: DeviceNet protocol introduction by Allen-Bradley
1995: ISO 11898 amendment (extended frame format) published
1995: CANopen protocol published by CIA 
Introduction to CAN
CAN is a serial bus protocol to connect individual systems and sensors as a substitute to conventional multi-wire looms. It allows automotive components to communicate on a single or dual-wire networked data bus up to 1Mbps. 
CAN protocols types:
There are basically two types of CAN protocols: 2.0A and 2.0B`.
CAN 2.0A is the earlier standard with 11 bits of identifier, while CAN 2.0B is the new extended standard with 29 bits of identifier. 2.0B controllers are completely backward-compatible with 2.0A controllers and can receive and transmit messages in either format.
There are two types of 2.0A controllers. The first is capable of sending and receiving 2.0A messages only and reception of a 2.0B message will flag an error. The second type of 2.0A controller (known as 2.0B passive) sends and receives 2.0A messages but will also acknowledge receipt of 2.0B messages and then ignore them.
CAN Basic Features
CAN has the following properties
Based on a bus topology
Prioritization of messages
Carrier-Sense Multiple-Access (CSMA) protocol
Error detection and signalling
Multicast reception with time synchronization
Automatic retransmission of corrupted messages as soon as the bus is idle again
Distinction between temporary errors and permanent failures of nodes and autonomous switching off of defect nodes
CAN bus offers remote transmit request (RTR) 
How CAN works
CAN bus is not addresses based but each message contains a unique identifier ,so data messages transmitted from any node on a CAN bus do not contain addresses of either the transmitting node, or of any desired receiving node.
All nodes on the network receive the message and each performs an acceptance test on the identifier to check if the message is relevant to that particular node or not. If the message is relevant, it will be accepted and processed; otherwise it is rejected. The unique identifier also determines the priority of the message. The lower the numerical value of the identifier, the higher the priority. When two or more nodes attempt to transmit at the same time, a non-destructive arbitration technique guarantees that messages are sent in order of priority and that no messages are lost.
Depending on the operational speed devices are connected to the bus, as in a typical vehicle application usually more than one CAN bus and their operational speed is different. Slower devices, such as door control, climate control, and driver information modules, can be connected to a slow speed bus. Devices that require faster response, such as the ABS antilock braking system, the transmission control module, and the electronic throttle module, are connected to a faster CAN bus.
Figure 2.1 How CAN Works
CAN logic states
The data on CAN bus is differential and can be in two states: dominant and recessive. Figure 1.4 shows the state of voltages on the bus. The bus defines a logic bit 0 as a dominant bit and a logic bit 1 as a recessive bit. When there is arbitration on the bus, a dominant bit state always wins out over a recessive bit state.
Figure 2.2 CAN logic states
The 1st version of the CAN standards, ISO 11519 (Low-Speed CAN) is for applications up to 125 kbps with a standard 11-bit identifier. The 2nd version, ISO 11898 (1993), also with 11-bit identifier offers signalling rates from 125 kbps to 1 Mbps and the more recent ISO 11898 amendment (1995) introduces the extended 29-bit identifier.
Table 1: CAN versions 
The ISO 11898 11-bit versions is referred to as Standard CAN Version 2.0A and the ISO 11898 amendment is referred to as Extended CAN Version 2.0B. Also Standard CAN Version 2.0A is occasionally referred to as Basic CAN, and Extended CAN Version 2.0B is occasionally referred to as Full CAN.
The Standard CAN 11-bit identifier field in Figure 2 provides for 2^11 or 2048 different message identifiers, while the Extended CAN 29-bit identifier in Figure 3 provides for 2^29, or 537 million identifiers.
The Bit Fields of Standard CAN and Extended CAN:
Figs 2.3a Standard CAN 
The meaning of the bit fields of Figure 2.3a are:
SOF-the single dominant start of frame (SOF) bit marks the start of a message, and is used to synchronize the nodes on a bus after being idle.
Identifier-The Standard CAN 11-bit identifier sets the priority of the message.
RTR-the single remote transmission request (RTR) bit is dominant when information is required from another node. All nodes receive the request, but the identifier determines the desired node. The responding data is also received by all nodes and used by any nod interested. In this way all data being used in a system is uniform.
IDE-a dominant single identifier extension (IDE) bit means that a standard CAN identifier with no extension is being transmitted.
r0-Reserved bit (for possible use by future standard amendment).
DLC-The 4-bit data length code (DLC) contains the number of bytes of data being transmitted. Data-Up to 64 bits of application data may be transmitted.
CRC-The 16-bit cyclic redundancy check (CRC) contains the `checksum (number of bits transmitted) of the preceding application data for error detection.
ACK-every node receiving an accurate message overwrites this recessive bit in the original message with a dominate bit, indicating an error-free message has been sent. Receiving node detects an error and leaves this bit recessive, it discards the message and the sending node repeats the message after re-arbitration.
EOF-this end-of-frame (EOF) 7-bit field marks the end of a CAN frame (message) and disables bit-stuffing, indicating a stuffing error when dominant. When 5 bits of the same logic level occur in succession during normal operation, a bit of the opposite logic level is stuffed into the data.
IFS-This 7-bit inter-frame space (IFS) contains the amount of time required by the controller to move a correctly received frame to its proper position in a message buffer area.
Fig2.3b Extended CAN 
As shown in Figure 2.3b, the Extended CAN message is the same as the Standard message with the addition of:
SRR-the substitute remote request (SRR) bit replaces the RTR bit in the standard message location as a placeholder in the extended format.
IDE-a recessive bit in the identifier extension (IDE) indicates that there are more identifier bits to follow. The 18-bit extension follows IDE.
r1-Following the RTR and r0 bits, an additional reserve bit has been included ahead of the
There are four different message types, or frames (Figures 2.3a and 2.3b) that can be transmitted on a CAN BUS:
the data frame
the remote frame
the error frame
the overload frame
A message is considered to be error free when the last bit of the ending EOF field of a message is received in the error-free recessive state. A dominant bit in the EOF field causes the transmitter to repeat a transmission.
The Data Frame
The data frame is made up by the arbitration field, the CRC field, the acknowledgement field and the data field. The arbitration field tells the priority of a message when two or more nodes are struggling for the bus. The arbitration field consists of an 11-bit identifier for CAN 2.0A in Figure 2.3a and the RTR bit, which is dominant for data frames. For CAN 2.0B in Figure 2.3b it consist the 29-bit identifier and the RTR bit. The data field contains zero to eight bytes of data and the CRC field contains the 16-bit checksum used for error detection. At the end there is the acknowledgement field. Any CAN controller which is able to receive a message correctly sends a dominant ACK bit that overwrites the transmitted recessive bit at the end of correct message transmission. The transmitter checks for the dominant ACK bit and retransmits the message if no acknowledge is detected.
The Remote Frame
The desired purpose of the remote frame is to obtain the transmission of data from another node. The remote frame is same as the data frame but with two important differences. First, this type of message is explicitly marked as a remote frame by a recessive RTR bit in the arbitration field. Secondly there is no data.
The Error Frame
This frame is a special message that breaks the formatting rules of a CAN message. It is transmitted when a node finds an error in a message, and causes all other nodes in the network to send an error frame as well. The original transmitter then automatically retransmits the message. There is a careful system of error counters in the CAN controller which ensures that a node cannot tie up a bus by repeatedly transmitting error frames.
The Overload Frame
The frame is similar to the error frame with regard to the format, and it is transmitted by a node that becomes too busy. It is basically used to provide for an extra delay between messages. 
Error Checking and Fault Confinement
The CAN protocol implements five methods of error checking: three at the message level and two at the bit level.
The CRC and the ACK slots are at the message level as displayed in Figures 2.3a and 2.3b.The CRC which is 16-bit contains the checksum of the preceding application data for error detection with a 15-bit checksum and 1-bit delimiter. The 2-bit ACK field consists of the acknowledge bit and an acknowledge delimiter bit. The form check is also at the message level. It looks for fields in the message which must always be recessive bits. If a dominant bit is detected, an error is generated. The SOF, EOF, ACK delimiter, and the CRC delimiter are the checked bits.
At the bit level the transmitter of the message is monitoring each transmitted bit. If a data bit (not arbitration bit) is written onto the bus and its opposite is read, an error is generated. The message identifier field which is used for arbitration, and the acknowledge slot which requires a recessive bit to be overwritten by a dominant bit are the only exceptions to this. The bit stuffing rule is the final method of error detection where after five consecutive bits of the same logic level if the next bit is not a compliment then an error is generated. It ensures rising edges available for on-going synchronization of the network, and that streams of recessive bits are not mistaken for an error frame, or the seven-bit interface space that signifies the end of a message. Stuffed bits are removed by a receiving node's controller before the data is forwarded to the application. 
With any one of these error detection methods if a message fails then it is not accepted and an error frame is generated from the receiving nodes causing the transmitting node to resend the message until it is received correctly. But if a faulty node hangs up a bus by continuously repeating an error, its transmit capability is removed by its controller after an error limit is reached. 
GSM (GLOBAL SYSTEM FOR MOBILE COMMUNICATION)
GSM is the world's most popular standard for mobile telephony systems. GSM differs from its predecessor technologies in that both signaling and speech channels are digital, and thus GSM is considered a second generation (2G) mobile phone system. This also facilitates the wide-spread implementation of data communication applications into the system.
What is a Subscriber Identity Module (SIM)?
The Subscriber Identity Module (SIM) is a small smart card which contains both programming and information.
The A3 and A8 algorithms are implemented in the Subscriber Identity Module (SIM).
Subscriber information, such as the IMSI (International Mobile Subscriber Identity), is stored in the Subscriber Identity Module (SIM).
The Subscriber Identity Module (SIM) is used to store user-defined information such as phonebook entries.
ADVANTAGE OF GSM ARCHITECTURE:
The advantage of the GSM architecture is that the SIM may be moved from one Mobile Station to another. This makes upgrades very simple for the GSM telephone user
SIM300 is a Tri-band GSM/GPRS engine that works on frequencies
EGSM 900 MHz, DCS 1800 MHz and PCS1900 MHz. SIM300 provides GPRS multi-slot class
10 capability and support the GPRS coding schemes CS-1, CS-2, CS-3 and CS-4.
With a tiny configuration of 40mm x 33mm x 2.85 mm , SIM300 can fit almost all the space
requirement in your application, such as Smart phone, PDA phone and other mobile device.
The physical interface between SIM300 and the mobile application is through a 60 pins
board-to-board connector, which provides all hardware interfaces from module to customers'
boards except the RF antenna interface.
1. The keypad and SPI LCD interface will give you the flexibility to develop customized
2. Two serial ports can help you easily develop your applications.
3. Two audio channels include two microphones inputs and two speaker outputs. These
audio interfaces can be easily configured by AT command.
4. One ADC input.
5. Two GPIO ports and SIM card detection port.