ON-BOARD DIAGNOSTIC SYSTEM FOR VEHICLES

ABSTRACT

On-board diagnostic framework assume a significant job in the present age of vehicles and will

assume an inexorably significant job in the following future. This paper proposes the

improvement of ON-BOARD DIAGNOSTIC SYSTEM for vehicles utilizing remote sensor

organize. This OBD framework comprises of Arduino Board which has an ATMEGA

microcontroller that goes about as a handling unit where the program is composed utilizing

ARDUINO programming, sensors, LCD and keypad as UI. The vehicle parameters, for example,

fuel level, temperature, voltage are detected and those outcomes are seen from LCD show. At

first, the sensors are introduced at various pieces of the vehicle to detect different vehicle

parameters. For remote information transmission, zigbee is utilized. KEY WORDS:

Arduino,OBD, Sensor, Zigbee.

 CHAPTER ONE

INTRODUCTION

On-board diagnostics (OBD) is a car term alluding to a vehicle's self-indicative and detailing

ability. OBD framework give the vehicle proprietor or fix specialist access to the status of the

different vehicle sub-framework. The measure of indicative data accessible by means of OBD

has differed generally since its presentation in the mid 1980s' variants of on-board vehicle PCs.

Early forms of OBD would essentially enlighten a glitch pointer light or "imbecile light" if an

issue was identified yet would not give any data with regards to the idea of the issue. Current

OBD executions utilize an institutionalized computerized correspondences port to give ongoing

information notwithstanding an institutionalized arrangement of demonstrative issue codes, or

DTCs, which enable an individual to quickly recognize and cure breakdowns inside the vehicle.

On-board analytic framework assume a significant job in the presentation of vehicles. Typically

it requires some investment to analyze an issue in vehicle than to redress it. So these framework

analyze the shortcomings as well as spare us a great deal of time. Parameters watched and

analyzed by OBD framework are utilized by the Electronic Control Unit (ECU) of vehicle which

thus controls the motor's primary operation (like sparkle timing control, air fuel blend, fuel

injectors showering period etc.).Combination of these two framework guarantees security and

efficient vehicle operation.

1.1 BACKGROUND OF THE STUDY

The inceptions of OBD started in 1982 when the California Air Resources Board (CARB) started

guidelines which would require all vehicles sold in California, beginning in 1988, to have an on-

board diagnostic framework to identify discharge disappointments. This framework would later
be alluded to as OBD-I. OBD-I was a basic ECU framework that checked different sensors and

applied revisions to a guide esteem dependent on motor conditions.

This framework changed the auto fix industry by making it simple to recognize broken segments,

in any case, it gave no understanding into the conditions that lead to the issue. Another downside

was non-existent institutionalization between various makes and models of vehicles and the

accessibility of moderate check apparatuses for these restrictive framework. In view of that, the

cutting edge OBD-II framework depended on new measures beginning in 1994 with a total stage

in for California vehicles by 1996. Presently, all vehicles must be OBD-II agreeable and have an

institutionalized 16-stick information interface connector (DLC) with explicit pins assignments,

institutionalized correspondence conventions, institutionalized indicative issue codes (DTC) and

institutionalized wording. Before 2008, five convention types were being used; J1850-PWM,

J1850-VPW, ISO 9141, KWP2000 and CAN.

Beginning in 2008, all vehicles sold in the US should now be CAN-BUS agreeable. Flow OBD-

II framework accomplish something other than electrically check segments for short or open

circuits, OBD-II screens any segment that can affect outflows by contrasting the sensor yield

with a normal range. In the event that breaking down or out-of-run, an indicative code number is

put away which must be perused utilizing a Code Reader or Scan Tool. Not all blunders will

cause the (MIL) "Breakdown Indicator Lamp" or "Check Engine Lamp" to light up. Be that as it

may, in the event that it does, this is a reason for worry to recognize the issue before expensive

harm can happen. At times, it tends to be something straightforward, for example, a free or

missing gas top which caused an "Evaporative Emission Control" mistake.

The Californian State director of the air quality (California State, United States of America)

acknowledged how significant the condition checking of the vehicle is. This state was the
principal which one made the use of condition checking framework compulsory for the vehicles.

The emanation vacillations shows a ton of specialized blunders [4][9][12].

So every new vehicles need to meet severe necessities and the operation of vehicles need to

checked in a customary interim. Different specialists can check the vehicles' fumes outflow on a

straightforward street check [4][9][12].

The primary standard demonstrative framework was the OBD I.. All vehicles needed to utilize

such a framework in the State of California since the model year of 1988. Another framework

needed to offered an explanation to the new models. Each vehicle producer utilized OBD II in

1994.

1.2 STATEMENT OF PROBLEM

In spite of the fact that OBD II checks are currently required to be remembered for I/M program

in the USA, there are concerns identified with those checks or tests. The OBD Workgroup

surveyed the latest data on three regions of concern brought up in the July, 2001 National

Research Council (NRC)/National Academy of Sciences (NAS) report, Evaluating Vehicle

Emissions Inspection and Maintenance Programs. These worries were identified with the:

(Sosnowski 2001)

• Effectiveness of 'contamination aversion' approach of OBD. That is the distinction between an

OBD II cross examination and a tailpipe discharges test;

• The identification of an absence of cover in certain vehicles that bomb the conventional tailpipe

test and vehicles that come up short OBD checks; and

• OBD disappointment criteria and possibly high disappointment rates for maturing vehicles

furnished with OBDII (1996 and fresher vehicles).

Different worries as to OBD II testing in I/M programs incorporate the physical use of the OBD

II test, including the operation of the Malfunction Indicator Lamp (MIL) and the understanding

of the Readiness Monitor codes. Another issue with respect to the utilization of OBD II in I/M

programs concerns potential troubles in assessing OBD II test program adequacy.

1.3 PURPOSE OF THE STUDY

The reason for this examination study is to carry decrease to the presumption of issue in a

vehicle by knowing the precise flaw the vehicle is having and furthermore to make a gadget that

will function as the shortcoming finder approached BOARD DIAGNOSTIC SYSTEM for

vehicles utilizing remote sensor arrange.

1.4 AIMS AND OBJECTIVES

On-board diagnostics, likewise called self-diagnostics, implies for us characterizing indicative

capacities that are incorporated legitimately with the vehicle. The points and goal of the

exploration work "vehicle locally available diagnostics" are as recorded in the accompanying

things:

 Putting a conclusion to the demonstration of simply discovering deficiencies before

fixing the shortcomings, especially during improvement

 To quit questioning highlights, for instance when stacking new programming

 To quit questioning estimation information for the assessment

 To quit recording prerequisites, for instance when discarding autos

 Detecting abandons in the vehicle with the goal of empowering quick fix and wiping out

defective capacities

 Satisfying lawful necessities, specifically OBD (On-Board Diagnostics) and EOBD

(European On-Board Diagnostics).

1.5 SIGNIFICANT OF STUDY

1. Inexpensive alternative rather than GPS following programming: With the execution of

the OBD-ll framework in the armada the executives programming, in any case the size of armada

business, you can oversee armada vehicle support and analyze armada vehicle motor remotely

nearby following mileage, overseeing drivers and producing different reports from the solace of

the lounge chair.

2. Enhance armada and driver's wellbeing: Tracking vehicle's security and driver execution

and personal conduct standards are all-basic to relieve the dangers of fast increasing speed,

speeding or forceful braking which in future become the business obligation. The armada the

board programming with OBD-II unit screens and make a report on the driver execution, and

furthermore structure a security profile for every driver which fills in as a standard for them

separately.

3. Early Diagnosing of breaking down gets convenient: Detecting the little issues before

they start displaying the manifestations is almost unimaginable for the drivers to discover. In

some cases, a little deferral in fixing the issues make the issue unpredictable and a major total of

dollars must be spent on the vehicles.

4. Increase the likelihood of DIY fix: Before the command execution of OBD-ll, the drivers

need to encounter the desolation of taking the vehicle to the carport and burn through a great deal

of time in getting fixed even the little blames. It diminishes the productivity of the armada tasks.

5. Easiness and adaptability that accompanies establishment: Connecting and introducing

GPS beacon with the OBD-ll indicative port isn't a bother. It's much the same as attachment and

play, and you can begin diagnosing close by monitoring your armadas remotely.
Notwithstanding effortlessness, the extraordinary length of adaptability works incredible for the

armada the board organizations.

6. High similarity crosswise over vehicles: Although the OBD-ll framework shift as per

distinctive vehicle types, the code scanners don't as the scanners are stuffed with a large number

of codes. Along these lines obtaining a solitary scanner, the drivers can analyze any of the

vehicles they are given to get and drop the travelers. It dispenses with the need to purchase new

scanners to analyze the soundness of each new armada you purchase.

7. Reduce contamination: How about when your cloud-based dispatch arrangement go

greener? It's unquestionably stunning. The OBD-ll framework encourages you in realizing that

armada is getting weakening with age and emanation control is in the need of fix.
 CHAPTER TWO

LITERATURE REVIEW

2.1 LITERATURE SURVEY

From "Leaving vehicle situating framework dependent on ZigBee", Jia Huiqin1 Xi'an Shiyou

University, China, it is seen that ZigBee is another sort of short separation, low power utilization,

minimal effort, low rate and low unpredictability remote system innovation. It takes all points of

interest of IEEE802.15.4. In this paper ,we use ZigBee innovation to build a remote

correspondence arrange, setting a full capacity ZigBee module as a facilitator in the correct spot

of the parking area, it discuss legitimately with the host PC. Introduce a few ZigBee switches as

per the separation need, and record their position data. Since this framework is coordinated to

card clients, so every vehicle is required to introduce a ZigBee module.

From "Producing on-board diagnostics of dynamic car framework dependent on subjective

models" Centro Ricerche Fiat, Strada Torino 50; Dip. Informatica, University di Torino, it is

comprehended that offboard conclusion can exploit the model-based methodology, on-board

finding requires some further contemplations and considering some significant handy limitations.

As a matter of first importance, in the on-board case the indicative framework must respond

expeditiously to peculiarities and must run quick so as to decipher the oddities and, which is

generally significant, so as to make a proper recuperation move . This implies additionally that

the on-board diagnostics ought to be centered uniquely around performing recuperation

activities, as opposed to on the real confinement of the fault(s) . Notwithstanding, monitoring

progressively point by point data about the fault(s) that happened can be critical, as it is a

significant data to be passed to the analytic framework that will be utilized in the workshop to
really find and distinguish the deficiency . Besides, just a couple of estimations can be accessible

locally available and the plausibility of performing tests/tests is exceptionally constrained .

From "ZigBee-based Vehicle Access Control System" by Rong Zhou, Chunyue Zhao, Lili Fu,

Ao Chen and Meiqian Ye College of Information and Electronic Engineering Zhejiang

Gongshang University Hangzhou, China following is comprehended. at the point when a vehicle

evaluate to the passageway, the transmitter introduced in the vehicle sends related data, through

the radio transmitter module in CC2430 chip, to the collector which is set in the entrance control

office. After effectively got the vehicle's data, the recipient passes the information to

microcontroller to decipher them. The control framework will get this data and store it in the

database. The supervisor can question all the data in database, including tag number, driver

number, etc.

From "Vehicle On-Board Diagnostics Added Values" Technical Paper by J.- F. Hétu, S. Plante

we comprehended that Today's vehicles have increasingly more hardware, and this prompts a

more prominent abundance of data accessible on a vehicle's correspondence organize. This paper

will address the additional benefit of approaching this data. Regardless of whether you are the

advancement engineer, the business technician or the end-client, the data accessible to the

various people has gotten fundamental. Quick diagnostics of occasions and blames, programmed

restorative connection of vehicle hardware to repay disappointments, just as preventive upkeep

cautions of explicit vehicle segments are largely activities that are helping the different people all

through the vehicle's presence. These activities are sparing time, increment diagnostics exactness

and make the vehicles for the most part more secure. This paper will give insights concerning

various occasions and likely situations to show the additional benefit of approaching the vehicle's

correspondence organize.
From "A Study on Remote On-Line Diagnostic System for Vehicles" by Integrating the

Technology of OBD, GPS, and 3G" by Jyong Lin, Shih-Chang Chen, Yu-Tsen Shih, and Shi-

Huang Chen it is cleared When the OBD framework identifies a glitch, OBD guidelines require

the Electronic Control Unit (ECU) of the vehicle to spare an institutionalized Diagnostic Trouble

Code (DTC) about the data of breakdown in the memory. An OBD Scan Tool for the servicemen

can get to the DTC from the ECU rapidly and precisely to affirm the breaking down attributes

and area as per the prompts of DTC that abbreviates the administration time to a great extent.

Besides, as of now the quantity of thing for the constant driving status that OBD can screen is as

high as up to 80 things

2.2 STANDARD INTERFACES

2.2.1 ALDL

GM's ALDL (Assembly Line Diagnostic Link) is now and then alluded as an ancestor to, or a

maker's exclusive variant of, an OBD-I demonstrative. This interface was made in various

assortments and changed with control train control modules (otherwise known as PCM, ECM,

ECU). Various forms had slight contrasts in stick outs and baud rates. Prior forms utilized a 160

baud rate, while later forms went up to 8192 baud and utilized bi-directional interchanges to the

PCM.[7][8]

2.2.2 OBD-I

The administrative expectation of OBD-I was to urge automobile producers to structure solid

discharge control framework that stay powerful for the vehicle's "valuable life".[citation needed]

The expectation was that by constraining yearly outflows testing for California,[citation needed]

and denying enrollment to vehicles that didn't pass, drivers would will in general buy vehicles

that would all the more dependably breeze through the assessment. OBD-I was generally
unsuccessful,[citation needed] as the methods for revealing discharges explicit diagnostic data

was not institutionalized. Specialized challenges with acquiring institutionalized and solid

emanations data from all vehicles prompted a failure to actualize the yearly testing project

effectively.[citation needed] The Diagnostic Trouble Codes (DTC's) of OBD-I vehicles can as a

rule be found without a costly 'filter instrument'. Every maker utilized their very own Diagnostic

Link Connector (DLC), DLC area, DTC definitions, and strategy to peruse the DTC's from the

vehicle. DTC's from OBD-I vehicles are regularly perused the squinting examples of the 'Check

Engine Light' (CEL) or 'Administration Engine Soon' (SES) light. By associating certain pins of

the demonstrative connector, the 'Check Engine' light will squint out a two-digit number that

compares to a particular mistake condition. The DTC's of some OBD-I vehicles are translated in

various manners, be that as it may. Cadillac (gas) fuel-infused vehicles are furnished with

genuine on-board diagnostics, giving issue codes, actuator tests and sensor information through

the new advanced Electronic Climate Control show. Holding down 'Off' and 'Hotter' for a few

seconds initiates the indicative mode without the requirement for an outside output apparatus.

Some Honda motor PCs are furnished with LED's that light up in a particular example to

demonstrate the DTC. General Motors, some 1989-1995 Ford vehicles (DCL), and some 1989-

1995 Toyota/Lexus vehicles have a live sensor information stream accessible, in any case,

numerous other OBD-I prepared vehicles don't. OBD-I vehicles have less DTC's accessible than

for OBD-II prepared vehicles.

2.2.3 OBD-1.5

OBD 1.5 alludes to a fractional execution of OBD-II which General Motors utilized on certain

vehicles in 1994, 1995, and 1996. (GM didn't utilize the term OBD 1.5 in the documentation for
these vehicles — they basically have an OBD and an OBD-II segment in the administration

manual.)

For instance, the 94–95 Corvettes have one post-impetus oxygen sensor (in spite of the fact that

they have two exhaust systems), and have a subset of the OBD-II codes actualized. For a 1994

Corvette the executed OBD-II codes are P0116-P0118, P0131-P0135, P0151-P0155, P0158,

P0160-P0161, P0171-P0175, P0420, P1114-P1115, P1133, P1153 and P1158.[9]

This mixture framework was available on the GM H-body autos in 94-95, W-body vehicles

(Buick Regal, Chevrolet Lumina ('95 in particular), Chevrolet Monte Carlo ('95 in particular),

Pontiac Grand Prix, Oldsmobile Cutlass Supreme) in 94-95, L-body (Chevrolet Beretta/Corsica)

in 94-95, Y-body (Chevrolet Corvette) in 94-95, on the F-body (Chevrolet Camaro and Pontiac

Firebird) in 95 and on the J-Body (Chevrolet Cavalier and Pontiac Sunfire) and N-Body (Buick

Skylark, Oldsmobile Achieva, Pontiac Grand Am) in 95 and 96 and furthermore on '94-'95 Saab

vehicles with the normally suctioned 2.3.

1 2 3 4 5 6 7 8

9 10 11 12 13 14 15 16

Table: The pinout for the ALDL connection on these cars

For ALDL connections, pin 9 is the data stream, pins 4 and 5 are ground, and pin 16 is battery

voltage.

An OBD 1.5 compatible scan tool is required to read codes generated by OBD 1.5.

Additional vehicle-specific diagnostic and control circuits are also available on this connector.

For instance, on the Corvette there are interfaces for the Class 2 serial data stream from the

PCM, the CCM diagnostic terminal, the radio data stream, the airbag system, the selective ride

control system, the low tire pressure warning system, and the passive keyless entry system.[10]
An OBD 1.5 has also been used on Mitsubishi cars of '95 '97 vintage,[citation needed]

some[which?] 1995 Volkswagen VR6's[citation needed] Buick Riviera of 1995 vintage and in

the Ford Scorpio since 95.[11]

2.2.4 OBD-II

OBD-II is an improvement over OBD-I in both capability and standardization. The OBD-II

standard specifies the type of diagnostic connector and its pinout, the electrical signalling

protocols available, and the messaging format. It also provides a candidate list of vehicle

parameters to monitor along with how to encode the data for each. There is a pin in the connector

that provides power for the scan tool from the vehicle battery, which eliminates the need to

connect a scan tool to a power source separately. However, some technicians might still connect

the scan tool to an auxiliary power source to protect data in the unusual event that a vehicle

experiences a loss of electrical power due to a malfunction. Finally, the OBD-II standard

provides an extensible list of DTCs. As a result of this standardization, a single device can query

the on-board computer(s) in any vehicle. This OBD-II came in two models OBD-IIA and OBD-

IIB. OBD-II standardization was prompted by emissions requirements, and though only

emission-related codes and data are required to be transmitted through it, most manufacturers

have made the OBD-II Data Link Connector the only one in the vehicle through which all

systems are diagnosed and programmed. OBD-II Diagnostic Trouble Codes are 4-digit, preceded

by a letter: P for engine and transmission (powertrain), B for body, C for chassis, and U for

network.

2.2.5 OBD-II DIAGNOSTIC CONNECTOR

The OBD-II specification provides for a standardized hardware interface—the female 16-pin

(2x8) J1962 connector. Unlike the OBD-I connector, which was sometimes found under the
hood of the vehicle, the OBD-II connector is required to be within 2 feet (0.61 m) of the steering

wheel (unless an exemption is applied for by the manufacturer, in which case it is still

somewhere within reach of the driver). SAE J1962 defines the pinout of the connector as:

1 Manufacturer discretion. 9 Manufacturer discretion.GM: 8192 baud

GM: J2411 GMLAN/SWC/Single-Wire ALDL where fitted.

CAN.

VW/Audi: Switched +12 to tell a scan tool

whether the ignition is on.

2 Bus positive Line of SAE J1850 PWM and 1 Bus negative Line of SAE J1850 PWM

VPW 0 only (not SAE 1850 VPW)

3 Ford DCL(+) Argentina, Brazil (pre OBD- 1 Ford DCL(-) Argentina, Brazil (pre OBD-

II) 1997-2000, USA, Europe, etc. Chrysler 1 II) 1997-2000, USA, Europe, etc. Chrysler

CCD Bus(+) CCD Bus(-)

4 Chassis ground 1 Not connected

5 Signal ground 1 Manufacturer discretion Ford: FEPS -

3 Programming PCM voltage

6 CAN high (ISO 15765-4 and SAE J2284) 1 CAN low (ISO 15765-4 and SAE J2284)

7 K line of ISO 9141-2 and ISO 14230-4 1 L line of ISO 9141-2 and ISO 14230-4

8 Manufacturer discretion. 1 Battery voltage

Many BMWs: A second K-Line for non 6

 OBD-II (Body/Chassis/Infotainment)

systems.

The task of unknown pins is left to the vehicle maker's tact.

EOBD

The EOBD (European On Board Diagnostics) guidelines are what could be compared to OBD-II,

and apply to all traveler autos of class M1 (without any than 8 front seats and a Gross Vehicle

Weight rating of 2500 kg or less) first enlisted inside EU part states since January 1, 2001 for oil

(fuel) engined autos and since January 1, 2004 for diesel engined cars.[12]

For recently presented models, the guideline dates applied a year sooner - January 1, 2000 for oil

and January 1, 2003 for diesel.

For traveler autos with a Gross Vehicle Weight rating of more noteworthy than 2500 kg and for

light business vehicles, the guideline dates applied from January 1, 2002 for petroleum models,

and January 1, 2007 for diesel models.

The specialized execution of EOBD is basically equivalent to OBD-II, with the equivalent SAE

J1962 analytic connection connector and sign conventions being utilized.

With Euro V and Euro VI discharge models, EOBD outflow limits will be lower than past Euro

III and IV.

2.2.6 EOBD FAULT CODES

Every one of the EOBD shortcoming codes comprises of five characters: a letter, trailed by four

numbers. The letter alludes to the framework being cross examined for example Pxxxx would

allude to the powertrain framework. The following character would be a 0 if goes along to the

EOBD standard. So it should look like P0xxx.

The following character would allude to the sub framework.

 P00xx - Fuel and Air Metering and Auxiliary Emission Controls.

 P01xx - Fuel and Air Metering.

 P02xx - Fuel and Air Metering (Injector Circuit).

 P03xx - Ignition System or Misfire.

 P04xx - Auxiliary Emissions Controls.

 P05xx - Vehicle Speed Controls and Idle Control System.

 P06xx - Computer Output Circuit.

 P07xx - Transmission.

 P08xx - Transmission.

The following two characters would refer to the individual fault within each subsystem.[13]

2.2.7 EOBD2

The expression "EOBD2" is showcasing talk utilized by some vehicle makers to allude to

producer explicit highlights that are not very of the OBD or EOBD standard. For this situation

"E" represents Enhanced.

2.2.8 JOBD

i. JOBD is a form of OBD-II for vehicles sold in Japan.

ii. ADR 79/01 and 79/02 (AUSTRALIAN OBD STANDARD)

iii. The ADR 79/01 (Vehicle Standard (Australian Design Rule 79/01 – Emission Control for

Light Vehicles) 2005) standard is what might be compared to OBD-II.

iv. It applies to all vehicles of class M1 and N1 with a Gross Vehicle Weight rating of 3500

kg or less, enlisted from new inside Australia and created since January 1, 2006 for

petroleum (fuel) engined autos and since January 1, 2007 for diesel engined cars.[14]

v. For recently presented models, the guideline dates applied a year sooner - January 1,

2005 for petroleum and January 1, 2006 for diesel.

vi. The ADR 79/01 standard was enhanced by the ADR 79/02 standard which forced more

tightly discharges limitations, appropriate to all vehicles of class M1 and N1 with a Gross

Vehicle Weight rating of 3500 kg or less, from July 1, 2008 for new models, July 1, 2010

for all models.[15]

vii. The specialized execution of this standard is basically equivalent to OBD-II, with the

equivalent SAE J1962 demonstrative connection connector and sign conventions being

utilized.

2.3 OBD-II SIGNAL PROTOCOLS

There are five flagging conventions that are allowed with the OBD-II interface. Most vehicles

execute just one of the conventions. It is frequently conceivable to derive the convention utilized

dependent on which pins are available on the J1962 connector:SAE J1850 PWM (pulse-width

modulation — 41.6 kB/sec, standard of the Ford Motor Company)

 pin 2: Bus+

 pin 10: Bus–

 High voltage is +5 V

 Message length is restricted to 12 bytes, including CRC

 Employs a multi-master arbitration scheme called 'Carrier Sense Multiple Access with

Non-Destructive Arbitration' (CSMA/NDA)

SAE J1850 VPW (variable pulse width — 10.4/41.6 kB/sec, standard of General Motors)

 pin 2: Bus+

 Bus idles low

 High voltage is +7 V

 Decision point is +3.5 V

 Message length is restricted to 12 bytes, including CRC

 Employs CSMA/NDA

ISO 9141-2. This protocol has an asynchronous serial data rate of 10.4 kBaud. It is somewhat

similar to RS-232; however, the signal levels are different, and communications happens on a

single, bidirectional line without additional handshake signals. ISO 9141-2 is primarily used in

Chrysler, European, and Asian vehicles.

 pin 7: K-line

 pin 15: L-line (optional)

 UART signaling

 K-line idles high, with a 510 ohm resistor to Vbatt

 The active/dominant state is driven low with an open-collector driver.

 Message length is Max 260Bytes. Data field MAX 255.

ISO 14230 KWP2000 (Keyword Protocol 2000)

 pin 7: K-line
 pin 15: L-line (optional)

 Physical layer identical to ISO 9141-2

 Data rate 1.2 to 10.4 kBaud

 Message may contain up to 255 bytes in the data field

ISO 15765 CAN (250 kBit/s or 500 kBit/s). The CAN protocol was developed by Bosch for

automotive and industrial control. Unlike other OBD protocols, variants are widely used outside

of the automotive industry. While it did not meet the OBD-II requirements for U.S. vehicles

prior to 2003, as of 2008 all vehicles sold in the US are required to implement CAN as one of

their signaling protocols.

 pin 6: CAN High

 pin 14: CAN Low

All OBD-II pinouts use the same connector, but different pins are used with the exception of pin

4 (battery ground) and pin 16 (battery positive).

2.3.1 OBD-II DIAGNOSTIC DATA AVAILABLE

OBD-II gives access to information from the motor control unit (ECU) and offers a significant

wellspring of data while investigating issues inside a vehicle. The SAE J1979 standard

characterizes a strategy for mentioning different diagnostic information and a rundown of

standard parameters that may be accessible from the ECU. The different parameters that are

accessible are tended to by "parameter ID numbers" or PIDs which are characterized in J1979.

For a rundown of essential PIDs, their definitions, and the recipe to change over crude OBD-II

yield to significant demonstrative units, see OBD-II PIDs. Makers are not required to actualize

all PIDs recorded in J1979 and they are permitted to incorporate restrictive PIDs that are not
recorded. The PID solicitation and information recovery framework offers access to continuous

execution information just as hailed DTCs. For a rundown of conventional OBD-II DTCs

recommended by the SAE, see Table of OBD-II Codes. Singular producers regularly upgrade the

OBD-II code set with extra exclusive DTCs.

2.3.2 MODE OF OPERATION

Here is a basic introduction to the OBD communication protocol according to ISO 15031:

i. Mode $01 is used to identify what powertrain information is available to the scan tool.

ii. Mode $02 displays Freeze Frame data.

iii. Mode $03 lists the emission-related "confirmed" diagnostic trouble codes stored. It

displays exact numeric, 4 digit codes identifying the faults.

iv. Mode $04 is used to clear emission-related diagnostic information. This includes clearing

the stored pending/confirmed DTCs and Freeze Frame data.

v. Mode $05 displays the oxygen sensor monitor screen and the test results gathered about

the oxygen sensor.

1. $01 Rich-to-Lean O2 sensor threshold voltage

2. $02 Lean-to-Rich O2 sensor threshold voltage

3. $03 Low sensor voltage threshold for switch time measurement

4. $04 High sensor voltage threshold for switch time measurement

5. $05 Rich-to-Lean switch time in ms

6. $06 Lean-to Rich switch time in ms

7. $07 Minimum voltage for test

8. $08 Maximum voltage for test

9. $09 Time between voltage transitions in ms

vi. Mode $06 is a Request for On-Board Monitoring Test Results for Continuously and Non-

ContinuouslyMonitored System. There are typically a minimum value, a maximum

value, and a current value for each non-continuous monitor.

vii. Mode $07 is a Request for emission-related diagnostic trouble codes detected during

current or last completed driving cycle. It enables the external test equipment to obtain

"pending" diagnostic trouble codes detected during current or last completed driving

cycle for emission-related components/systems. This is used by service technicians after

a vehicle repair, and after clearing diagnostic information to see test results after a single

driving cycle to determine if the repair has fixed the problem.

viii. Mode $08 could enable the off-board test device to control the operation of an on-board

system, test, or component.

ix. Mode $09 is used to retrieve vehicle information. Among others, the following

information is available:

1. VIN (Vehicle Identification Number): Vehicle ID

2. CALID (Calibration Identification): ID for the software installed on the ECU

3. CVN (Calibration Verification Number): Number used to verify the integrity of

the vehicle software. The manufacturer is responsible for determining the method

of calculating CVN(s), e.g. using checksum.

4. In-use performance counters

 Gasoline engine : Catalyst, Primary oxygen sensor, Evaporating system,

EGR system, VVT system, Secondary air system, and Secondary oxygen

sensor
  Diesel engine : NMHC catalyst, NOx reduction catalyst, NOx absorber

Particulate matter filter, Exhaust gas sensor, EGR system, VVT system,

Boost pressure control, Fuel system.

x. Mode $0A lists emission-related "permanent" diagnostic trouble codes stored. As per

CARB, any diagnostic trouble codes that is commanding MIL on and stored into non-

volatile memory shall be logged as a permanent fault code.

2.4 OBD APPLICATIONS

Various tools are available that plug into the OBD connector to access OBD functions. These

range from simple generic consumer level tools to highly sophisticated OEM dealership tools to

vehicle telematic devices.

2.4.1 HAND-HELD SCAN TOOLS

A range of rugged hand-held scan tools is available.

i. Simple fault code readers/reset tools are mostly aimed at the consumer level.

ii. Professional hand-held scan tools may possess more advanced functions

iii. Access more advanced diagnostics

iv. Set manufacturer- or vehicle-specific ECU parameters

v. Access and control other control units, such as air bag or ABS

vi. Real-time monitoring or graphing of engine parameters to facilitate diagnosis or tuning

2.4.2 MOBILE DEVICE BASED TOOLS AND ANALYSIS

Mobile device applications allow mobile devices such as cell phones and tablets to display and

manipulate the OBD-II data accessed via USB adaptor cables or bluetooth adapters plugged into

the car's OBD II connector.

2.4.3 PC-BASED SCAN TOOLS AND ANALYSIS PLATFORMS

A PC-based OBD analysis tool that converts the OBD-II signals to serial data (USB or serial

port) standard to PCs or Macs. The software then decodes the received data to a visual display.

Many popular interfaces are based on the ELM or STN1110[17] OBD Interpreter ICs, both of

which read all five generic OBD-II protocols. Some adapters now use the J2534 API allowing

them to access OBD-II Protocols for both cars and trucks.

In addition to the functions of a hand-held scan tool, the PC-based tools generally offer:

i. Large storage capacity for data logging and other functions

ii. Higher resolution screen than handheld tools

iii. The ability to use multiple software programs adding flexibility

The extent that a PC tool may access manufacturer or vehicle-specific ECU diagnostics varies

between software products as it does between hand-held scanners.

2.4.4 DATA LOGGERS

Data loggers are designed to capture vehicle data while the vehicle is in normal operation, for

later analysis.

Data logging uses include:

I. Engine and vehicle monitoring under normal operation, for the purpose of diagnosis or

tuning.
II. Some US auto insurance companies offer reduced premiums if OBD-II vehicle data

loggers[18][19] or cameras[20] are installed - and if the driver's behaviour meets

requirements. This is a form of auto insurance risk selection

III. Monitoring of driver behaviour by fleet vehicle operators.

Analysis of vehicle black box data may be performed on a periodic basis, automatically

transmitted wirelessly to a third party or retrieved for forensic analysis after an event such as an

accident, traffic infringement or mechanical fault.

2.4.5 EMISSION TESTING

In the United States, numerous states currently use OBD-II testing rather than tailpipe testing in

OBD-II agreeable vehicles (1996 and more up to date). Since OBD-II stores inconvenience

codes for discharges gear, the testing PC can inquiry the vehicle's installed PC and confirm there

are no outflow related issue codes and that the vehicle is in consistence with emanation measures

for the model year it was produced.

In the Netherlands, 2006 and later vehicles get a yearly EOBD discharge check.[21]

2.4.6 DRIVER'S SUPPLEMENTARY VEHICLE INSTRUMENTATION

Driver's strengthening vehicle instrumentation will be instrumentation introduced in a vehicle

notwithstanding that gave by the vehicle producer and proposed for show to the driver during

typical operation. This is against scanners utilized principally for dynamic flaw determination,

tuning, or concealed information logging.

Auto aficionados have customarily introduced extra measures, for example, complex vacuum,

battery current and so forth. The OBD standard interface has empowered another age of lover

instrumentation getting to the full scope of vehicle information utilized for diagnostics, and

determined information, for example, prompt mileage.

Instrumentation may appear as committed excursion computers,[22] carputer or interfaces to

PDAs,[23] cell phones, or a Garmin route unit.

As a carputer is basically a PC, a similar programming could be stacked with respect to PC-

based sweep instruments and the other way around, so the differentiation is just in the purpose

behind utilization of the product.

These aficionado framework may likewise incorporate some usefulness like the other output

instruments.

2.4.7 VEHICLE TELEMATICS

OBD II is never again just utilized by experts and specialists to fix vehicles. OBD II data is

usually utilized by vehicle telematics gadgets that perform armada following, screen eco-

friendliness, anticipate dangerous driving, just as for remote diagnostics and by Pay-As-You-

Drive protection. Albeit initially not expected for the above purposes, regularly upheld OBD II

information, for example, Vehicle Speed, RPM, and Fuel Level permit GPS based armada GPS

beacons to screen vehicle sitting occasions, speeding, and over-firing up. By checking OBD II

DTCs an organization can know quickly in the event that one of its vehicles has a motor issue

and by deciphering the code the idea of the issue. OBD II is additionally checked to square cell

phones when driving and to record trip information for protection purposes.[24]

Measures reports

2.5 SECURITY ISSUES

Analysts at the University of Washington and University of California analyzed the security

around OBD, and found that they had the option to deal with numerous vehicle segments through

the interface. Moreover, they had the option to transfer new firmware into the motor control
units. Their decision is that vehicle implanted framework are not structured with security in

mind.[25][26][27]

There have been reports of thieves using specialist OBD reprogramming devices to enable them

to steal cars without the use of a key.[28] The primary causes of this vulnerability lie in the

tendency for vehicle manufacturers to extend the bus for purposes other than those for which it

was designed, and the lack of authentication and authorization in the OBD specifications, which

instead rely largely on security through obscurity.[29]

2.6 REVIEW OF EXISTING SYSTEM

In 1996, OBD-II framework was created by SAE (U.S.society of car engineers), EPA

(Environment insurance office U.S.) and CARB (California air assets board). Larger part of

autos that were presented in U.S.A. after 1996 had this framework. This framework has become

a standard for all vehicles. These framework screen various parameters of vehicle and store data

in memory however don't have any interface for client. At whatever point a shortcoming emerges

in the vehicle, the framework detects it and tells the client of alerts utilizing a breakdown sign

light (MIL). Glimmering of MIL in various successions tells client nature of issue ; This, be that

as it may, isn't a viable method for notice sign as should be obvious which part has deficiency,

what the issue is and when it happened.

(1) Occasional blazing: flitting breakdown.

(2) Constantly on: major issue influencing the wellbeing of vehicle or discharge yield.

(3) Constant blazing: serious issue and genuine harm if motor not halted right away.

This, in any case, isn't a viable method for notice sign as should be obvious which part has issue,

what the flaw is and when it happened.

These framework have a DLC (information interface connecter) as a rule at the base of run board

to which a hand-held output instrument can be associated. The output device speaks with the

OBD framework utilizing inconvenience codes and afterward shows the data on its LCD. The

constraint of these hand-held devices is that at whatever point they speak with the OBD

framework, they send the issue codes and consequently get data which was recently put away by

the framework. It doesn't give ongoing qualities and doesn't make reference to when the data,

being shown, had happened in the vehicle. It doesn't give any fix direction. Each time MIL

shows an admonition, the handheld OBD scanner must be utilized to analyze the issue. The

OBD scanner is an expensive gadget and is predominantly claimed by workshops. The proposed

structure incorporates this scanner in the framework, permitting ongoing sign of flaws, without

visiting a workshop each time the MIL sign turns ON.

CHAPTER THREE

METHODOLOGY

3.1 SYSTEM OVERVIEW

An essential outline of the framework is given in Figure 3.1. The ECU of the vehicle is

interfaced with different sensors (subsystem 1), from which vehicle parameters can be estimated.

The OBD II peruser (subsystem 2) will be microcontroller based and will in this way be

answerable for the control of the general framework. The handled information from subsystem 2

will be transmitted remotely to a remote server (subsystem 3) for information stockpiling and

show. The itemized elements of the subsystems are appeared in Figure 3.2.
Information procurement is performed by the vehicle ECU for estimation of the speed,

separation voyaged and fuel utilization (FU 1.1-1.2). The product to recreate the ECUis

structured and actualized on off-the rack equipment. The information interface connector (FU

1.3) is a standard connector in the vehicle to which the OBD II peruser is associated. The OBD II

convention interface (FU 2.1) identifies and translates the ECU information as indicated by the

executed OBD II convention. Change of information in content configuration to voltage levels

(FU 2.2) from the processor to the on-board framework and the other way around is performed.

PID information is mentioned and plays out the handling of the information got from the ECU by

means of the OBD II convention interface (FU 2.3). It is additionally answerable for controlling

the GPS (FU 2.6) and the remote correspondence modules (FU 2.5). The server is a PC from

which a database the board framework (FU 3.1) and a GUI (FU 3.2) is run. Discrete segments

and controllers are utilized (FU 2.7) to scale the 12 V yield from the OBD II information
interface connector down to voltage levels appropriate for driving other framework segments.

Fig 3.1: the functional units of the subsystems

3.2 SYSTEM DESIGN

3.2.1 ELM327 INTEGRATED CIRCUIT

The ELM327 is an OBD II translator IC. It is a microcontroller intended to naturally translate all

OBD II flagging conventions. It would thus be able to be interfaced with the electronic hardware

required to set up correspondence with the vehicle ECU by means of the OBD II port. The

conventions executed in this investigation were the ISO 15765 (CAN), ISO 9141-2 and ISO

14230-4.
An AT Command set predefined for the ELM327 was utilized to speak with the IC through

RS232. The order set took into account setting up the IC to change its conduct to suit the

necessities of the framework. This included setting up the Baud rate for RS232 correspondence,

arrangement of the got information from the ECU and initialisation of the sort of OBD II

convention executed on the vehicle.

A different direction set alluded to as OBD directions, was utilized to speak with the ECU from

the ELM327.

Directions from this set comprise of just hexadecimal characters as characterized in the SAE

J1979 standard. Each direction from this set is a mix of either a PID or a DTC and a worth that

demonstrates a method of operation. The ELM327 has ten indicative methods of operation which

are characterized in the SAE J1979 standard. The operation of every mode relies upon the kind

of data required from the ECU. Mode one was fundamentally utilized in the execution of the

OBD II peruser subsystem is for mentioning and demonstrating current ongoing vehicle

information and mode two for instance is for diagnosing motor glitches. The SAEJ1979 standard

likewise characterizes equations to be utilized to translate messages got from the ECU to acquire

real parameter estimations and the structure of reaction message from the ECU.

OBD directions are commonly two bytes in length, anyway they are sent to the vehicle ECU as a

major aspect of a more extended message. The byte structure of this message is appeared in

Figure 3.3.

Messages are doled out needs which are utilized to decide the request for sending messages if

more than one message is sent simultaneously.The recipient and transmitter bytes are the source

and goal addresses. The vehicle ECU is an addressable electrical transport, the source and goal

address are in this manner essential for use in the location line of the transport.
OBD II directions are typified as a major aspect of the payload area which can be up to 7 bytes.

The last field of the message is a checksum which is answerable for identifying mistakes in

messages got from the vehicle ECU. The ISO 9141-2 and ISO 14230-4 measures both utilize a

similar message structure, CAN messages are anyway somewhat extraordinary. The structure of

reaction messages from the ECU is appeared in Figure 3.4. The principal byte shows the method

of operation. The hexadecimal worth '1' in the '41' demonstrates mode 1. On the off chance that a

DTC was sent under mode two, at that point estimation of the main byte would be '42'. The

subsequent byte is the PID which was sent with the solicitation message. Position A to D is the

information bytes which contain the mentioned parameter esteem from the vehicle.

Fig. 3.3. The OBD II Message Format.

Fig. 3.4. The OBD II Response Message Format.

Figure 3.5 shows a case of a solicitation and a reaction message sent by the ELM327 and ECU

individually when vehicle speed estimation is mentioned. The solicitation message is "01 0D"

which demonstrates that the PID "0D" was sent to the ECU under mode one which is shown by

"01".
The reaction message from the ECU is "41 0D 32" which compares to the configuration

appeared in Figure 3.4. The initial two bytes demonstrate the mode and the PID. The last byte

which is "32" for this situation, is the information byte An in Figure 3.4. The genuine speed

esteem is acquired by changing byte A, which is 3216 to decimal. The speed worth will in this

way be 50 Km/h.

Fig. 3.5. An Example of Request and Response Message Sent for Measuring Speed.

Fig. 3.6. An Example of Request and Response Message Sent for Measuring MAF.

Thus the equation are used for calculating Speed is:

Speed = ((ByteA)16)10 (1)

An example of the send and request message for MAF is shown in Figure 6. The decoding of the

data bits is different from the previous example in that the formula used two data bytes, namely

A and B.
Computation of the MAF value is done by first converting byte A which is 0116 to a decimal

value which is 1. Similarly byte B which is 7C16 works out to be 124. Thus the equation for

calculating MAF is:

10 10
( Byte 16) × 256+(Byte 16 )
MAF= (2)
100

The ELM327 requires a 5 V power source to function correctly. Messages are sent and received

using UART. The ELM327 in essence acts as terminal interface. On power up the IC returns a

string with the characters ”ELM327 v1.4b” followed by a prompt character ’>’. The prompt

character signals that the IC is ready to send OBD II or AT commands. A baud rate of 38400 bits

per second (bps) was used. Establishing communication with the ECU was done by first sending

the command ATZ followed by ATSP0 and then finally 0100.The ATZ command resets the IC.

It was sent to verify that the IC functions correctly and to check if it was ready to send messages.

Command Description

1 ATZ Reset

2 ATSP0 Set protocol to auto

3 ATE0 Echo off

4 ATFE Forgot events

5 ATS0 Print spaces off

6 0100 Search for set protocol

7 010D Speed PID

8 0110 MAF PID

TABLE 4.1: THE OBDII AND AT COMMANDS SENT FROM THE ELM 327.

Table 4.1 is a summary of the commands used and sent from the ELM327. All commands sent

from the ELM327 were appended with a carriage return character.

The OBD II standard does not define standard PIDs for some vehicle parameters such as fuel

consumption. A method proposed in [4] was used in this project to calculate the fuel

consumption of a vehicle from OBD II. Fuel consumption is a measure of the fuel that a vehicle

consumes in litres per kilometre (L/Km). Fuel flow is a measure of the litres of fuel burnt by a

vehicle measured in litres per hour (L/h). It can be used to calculate the instantaneous fuel

consumption if divided by the current driving speed in kilometres per hour (Km/h).

This is shown in equation below.

Fuelflow
Fuel Consumption= (3)
Speed

Speed can be obtained from OBD II however even though fuel flow has a defined OBD II PID of

5E, it is not available on most cars. This problem can be bypassed by using the MAF given in

grams of air per second (g/s) to calculate fuel consumption. This method takes into account the

ratio of the mass of air in grams to one gram of fuel in an engine which is referred to as air to

fuel ratio (AFR) and the density of the fuel in grams per cubic decimetre (g/dm3) or equivalently

grams per litre (g/L). The AFR of is 14.7:1 and it’s density (D) is 820 g/dm3. If the speed of the

vehicle (V), is given in (Km/h) then the instantaneous fuel consumption can be calculated as in

equation below:

MAF
Fue l Consumption= ×3600 (4)
AFR × D ×V

Where 3600 is a conversion factor from seconds to hours.

If the type of fuel used by a vehicle is diesel as opposed to fuel consumption, air to fuel ratio will

be 14.5:1 and the density will be 750 g/dm3. Equation 4 was used in this study to calculate the

fuel consumption of a vehicle.

3.2.2 INTERFACE PROTOCOLS

The CAN, ISO 9141-2 and ISO 14230-4 communication protocols were implemented in this

study. The output of the interface circuits were connected to the OBD II 16-pin connector shown

in Figure 7. The pins which were utilised were pin 6 and pin 14 for CAN, pin 7 and 15 for both

ISO 9141-2 and ISO 14230-4. Pin 5 and pin 16 were connected to the ground and voltage

supply.

Fig. 3.7. The OBD II Port.

Fig. 3.8. The CAN Data Bus Lines.

1) CAN Protocol interface: The CAN standard was created by an organization called Bosch

for car applications.

It was considered compulsory for all vehicles fabricated from 2008 to actualize CAN as the

standard OBD II convention.

There are two arrangements of the CAN convention with 125 kbps and 500 kbps information

transmission rates. The 125 kbps design is alluded to as low speed and the 500 kbps as fast.
The CAN transport standard characterizes diverse CAN transport structures which incorporate a

solitary line and two line transport design.

Car applications, including OBD II for the most part utilize the twofold line CAN transport

engineering. The twofold line engineering has transmit and get lines which interface with various

hubs on the transport line, as appeared in Figure 3.8. Hubs are the various subsystems which can

be tended to. The two lines of correspondence are additionally alluded to as CAN high and CAN

low which are described by a differential voltage of 5 V and an end input impedance of 120.

The structure of CAN messages is not quite the same as other OBD II messages. CAN messages

additionally come in two organizations relying upon the quantity of identifier bits as appeared in

Figure 3.9. The identifier bits characterize the message need and distinguishing proof of the

message stream. A CAN message can either have 11 identifier bits, which is for low speed CAN

that works at a transmission pace of 250 kbps or 29 identifier bits for fast CAN working at 500

kbps. The information field which contains the real information being transmitted on the

transport is 8 bytes in length lastly checksum bits are characterized. CAN characterizes states for

signals transmitted on the transport line. These sign are simply successions of rationale high and

rationale low voltages likewise alluded to as ones and zeroes separately. The CAN convention

characterizes a sensible high as a passive state while a legitimate low is alluded to as prevailing

state. The meaning of these states depends on the estimation of the differential voltage between

CAN high and CAN low information lines. A prevailing state is commonly when the differential

voltage is less that 0 V and a passive state is the point at which the differential voltage is more

prominent than 1.2 V.

Fig. 3.9. The Structure of a CAN Message.

Fig. 3.10. OBD II Communication Protocol Circuitry.

2) OBD II ISO 9141-2 interface: The ISO 9141-2 convention takes a shot at a 10.4 kbps

rate. A transmission to the ECU is introduced by sending a 0x33 code at 5 bps. This is alluded to

as moderate initialisation rather than quick initialisation utilized by ISO 14230-4. ISO 9141-2

chips away at a high 12 V dynamic voltage and a low 0 V inactive voltage. It has a solitary line

of correspondence alluded to as K line, where all vehicle ECUs are associated in car

applications. There may alternatively be an extra L line. The K line is gotten to through stick 7 of

the OBD II connector. The greatest information length is 12 bytes. ISO 14230-4 is comparable
however varies in information length and initialisation as referenced already. The greatest

information length is 255 bytes [9].

The CAN convention interface circuit is associated with stick 23 (CAN TX) and stick 24 (CAN

RX) of the ELM327 by means of the MCP2551 which is a CAN handset IC. The trans collector

goes about as an interface between the vehicle CAN transport and the ELM327 which is

answerable for controlling the CAN transport. Controlling the CAN transport involves the

transmission and gathering of information on the transport. The trans collector has CAN high

and CAN low sticks which are associated comparatively to the physical vehicle transport by

means of stick 6 stick and stick 14 of the OBD II connector as appeared in Figure 3.10. Resistors

R1 and R2 both of significant worth 100, are associated with CAN high and CAN low in light of

the fact that the ISO 15765-4 necessitates that an end impedance somewhere in the range of 90

and 110 on both CAN high and CAN low lines. Likewise an end capacitance of 470 pF to 640 pF

is required. It is thus that the estimations of C2 and C3 were picked as 560 pF. Resistor R3 is

associated with stick RS of the MCP2551 to control the progress CAN line. A 0.1 F capacitor

was associated between the positive stockpile and ground for decoupling and sifting clamor in

the electrical cable.

The interface circuits for the ISO 9141-2 and ISO 14230-4 conventions are constrained by two

NPN transistors which are designed as switches. This is a direct result of the way that vehicle

electronic transports or ECUs that hold fast to both of these two norms work at intelligent high

and coherent low voltage levels of 12 V and 0 V separately. The authority terminals of the two

transistors are consequently associated with the vehicle battery voltage of 12 V by means of

draw up resistors, R4 and R7 of worth 510.

The estimation of the draw up resistor is picked as indicated in the measures of the concerned

correspondence conventions. The operation of the transistor switches when speaking with the

ECU is clarified further.

At the point when the voltage VB at the base of the transistor is 0 V, the base current IB will

likewise be zero. The connection between the base current and the authority current IC is given

by:

IC = βIB (5)

where β is the transistor current gain. If IB is 0 A then the equation implies that the collector

current will also be zero and the transistor will act as an open switch resulting in pin 7 and pin 14

of the OBD II connector being at 12 V. When the transistor is however forward biased with a

base voltage of 5 V from the ISO pins of the ELM327, the base current will be:

V b −0.7 5−0.7
I B= = =1.95 mA (6)
R7 2200

where 0.7 is the transistor breakout voltage.

If the supply voltage is VCC, the maximum collector current is given by:

Vcc 12
I BC = = =23.5 mA (7)
R 4 510

which would then result in transistor saturating and acting as a closed switch.

The output voltage is given by:

Vout = Vcc - R4IC = 12 - (510 × 0:0235) = 0:2V (8)

Counts performed in Equations 5 to 8 were determined with reference to Q2, anyway it must be

noticed that a similar thinking likewise applies to transistor T1 as the arrangement of the two

transistor circuits is the equivalent.

Transistor T1 which was associated with the ISOL line isn't required for most vehicles as it is

just required during the initialisation procedure of the transport for certain vehicles. Information

was transmitted and got on the K line of the vehicle transport and was perused stick 12 (ISOIN)

of the ELM327 from the yield of the transistor. A voltage divider circuit with an opposition R8

of 33 K

also, R9 of 47 K was utilized to drop down 12 V, the most extreme voltage from the transistor

yield to 5 V to be utilized by the ELM327.

The estimation of the voltage divider yield can be legitimized in the condition underneath where

Vout and Vin are the voltage divider yield and the transistor yield individually.

R8 3300
V out = ×V ¿ = ×12=4.95 v ≈ 5V (9)
R 8+ R 9 3300+4700

Fig. 3.11. The MCU and WiFi Module Connection Circuit.

C. Wireless Communication Module

A WiFi arrange was set up between a Carambola2 WiFi module associated with a PC and one

incorporated with the OBD II subsystem. The Carambola2 module which was interfaced with the

OBD II subsystem was associated with the MCU through RS232. The MCU transmitted the

procured OBD II and GPS information to the module so it could be sent remotely to the remote

WiFi module associated with a PC. The Carambola2 works at a baud pace of 115200 kbps.

Figure 11 beneath delineates the availability between the WiFi module and the MCU.

The WiFi module was worked from a 3.3 V supply and the most extreme operation voltage of

the module's RS232 lines was 2.6 V. Voltage division was consequently used to drop the 5 V

from the MCU's TX line to 2.5 V appropriate for the RX line of the WiFi module. Two

equivalent resistors R12 and R13 of 10 K were picked to understand a voltage level of 2.5 V. A

level moving IC, for example, ADuM1201 could have been utilized as an option in contrast to

voltage division anyway voltage division was decided on since it was a less expensive

arrangement and demonstrated to be effective. The module utilizes a 2.4 GHz WiFi reception

apparatus for WiFi availability and examining of reachable WiFi systems.

A RJ45 MagJack breakout board appeared in Figure 3.12 was associated with the Ethernet

interface pins of the Carambola2 to take into account sharing of source code records from the PC

to the module. The board had eight breakout tracks from the stick contacts of the RJ45 to the

bind side associations.

The MagJack RJ45 was furnished with a transformer whose essential side was associated with

the patch side of the eight pins of the breakout board. The auxiliary side of the transformer was

associated with the pins of the RJ45 port.

Associations made between the RJ45 breakout board and the LAN interface of the Carambola2

are appeared in Figure 3.13. The segment SV4 was a PCB connector to which the breakout board
was associated. Capacitors C7 and C8 of worth 100 nF were associated between the stockpile

and ground as recommended in the information sheet for decoupling. A draw down resistor R14

was associated with a switch for physically resetting or rebooting the module.

1) (Connecting the Carambola2 Wireless Module): The WiFi module was running on Chaos

Calmer, a form of the OpenWRT working framework. The Carambola2 is basically a little PC

with ground-breaking highlights, for example, those of remote switches [17]. Designing the

module for correspondence over a WiFi organize required associating it first once the module

was controlled on. This should be possible in one of two different ways. The primary technique

was through setting up a LAN association between a PC and the module, at that point utilizing

either Telnet or Secure Shell (SSH) to login. The default IP address of the module's LAN

interface was 192.168.1.1 which the PC consequently recognized once an effective LAN

association was built up.

The second strategy for getting to the module was through a USB to sequential port association.

A terminal program was, for example, Putty in Windows was utilized. Interfacing with the

module by means of SSH required setting a secret phrase which should be possible when

associated through Telnet or SSH.

The module associated with the PC was designed as an Access Point (AP). An AP goes about as

an ace hub or a server which takes into consideration different gadgets to interface with it by

means of WiFi. Station Point (STA) mode was arranged on the module associated with the OBD
II subsystem. STA mode in this way empowers a gadget to associate with an AP as a customer.

Fig. 3.12. The RJ45 MagJack Breakout Board Which was Interfaced with the Carambola2.

Fig. 3.13. The Connection Between the RJ45 MagJack Breakout and the WiFi Module.

2) AP mode arrangement: Once the Carambola module has been associated, the module

needed to designed for WiFi association and correspondence. This was finished by setting up

three records in the =etc=config= registry of the module. The Fig. 3.14. An Example of the GLL

Message Transmitted by the GPS Module. names of these documents were system, remote and

firewall.
The system record is the place all the systems administration interfaces to be utilized for

correspondence are made. The personal residence of the gadget was designed as a loopback

interface with the IP address 127.0.0.1. The LAN interface was named eth0 and given the IP

address 192.168.1.1. This was the IP address used to recognize the gadget when associated with

a PC by means of Ethernet. An interface for WiFi correspondence was likewise made and named

WiFi The IP address of the WiFi interface was 192.168.6.1.

All IP addresses were designed as static locations with a subnet veil of 255.255.255.0.

The remote record is the place the remote interface and the traits of the WiFi organize are

arranged. These incorporated the name of the WiFi arrange (SSID), the name of the gadget, the

method of operation and the correspondence convention standard. The gadget was arranged as a

passageway which could be gotten to by means of the WiFi interface which was at first

arrangement in the system document. The status of the remote interface was affirmed by giving

the direction iwconfig.

The firewall record was arrangement to empower parcels to be sent from the LAN interface to

the WiFi interface and the other way around.

3) STA mode design: Configuring the WiFi module in STA mode is done likewise to the

AP mode arrangements. The thing that matters was that an interface named wwan with a static IP

address of 192.168.6.2 was arrangement in the system record. The method of operation and the

SSID name were likewise designed in the remote document. The equivalent SSID was utilized,

else correspondence would not have been conceivable between the modules. The module

additionally takes into consideration improving security by setting up a secret phrase for the

WiFi arrange.

3.2.3 GPS TRACKING

The transmit stick of the GPS module was associated with the get stick of the microcontroller's

second UART module. The module was set to transmit NMEA convention message strings at a

baud pace of 115200 Kbps consistently. This was on the grounds that the WiFi module was

likewise interfaced with the microcontrollers second UART module and worked at a baud pace

of 115200 Kbps. All settings and arrangements were finished utilizing the Ucentre, open source

programming created by Ublox. The NMEA convention characterizes various messages with a

predefined design. One of the NMEA messages is the GLL message type which is string

containing data about the longitude and scope of a particular area.

The message string has various fields which are delimited by commas. The fields of the GLL

message are appeared in Figure 3.14.

Fig. 3.15. The Power Supply Circuit.

Fig. 3.16. Implementation of the GUI at the Remote Server.

3.2.4 POWER SUPPLY

As appeared in Figure 3.15, the framework was controlled with a 12 V battery from a vehicle

which was directed down to 5 V the LM805 and 3.3 V utilizing the LM1086 voltage controllers.

The 5 V supply was for the ELM327 IC, the MCU and the GPS module. The 3.3 V was for

controlling the remote correspondence module. The two controllers each give a most extreme

yield current of 1.5 A which was adequate to supply all framework parts.

Information Capacitors C1, C3 and C5 were utilized for retaining power homeless people and

waves in the circuit. Yield capacitors C2 and C4 were likewise utilized for a similar explanation.

The qualities were picked to be more prominent than the base information or yield capacitance as

indicated in the information sheet A Zener diode D1, with a separate voltage of 12 V was utilized
to ensure the framework parts against overvoltage. This was to restrict the voltage from the

inventory to 12 V as there might be varieties when a heap is associated. Diodes D2 and D3 with

a 0.7 V drop were utilized to shield supply from any invert voltage.

THE REMOTE SERVER

Information from transmitted remote from the OBD II peruser was put away in a database made

in SQL. The information was then perused from the sequential port into a graphical UI executed

in C#. The electronic model view controller (MVC) stage was utilized. This took into account

division of concerns. Figure 3.16 shows the usage of the GUI at the remote server.

Fig. 17. Test Setup of the OBD II Reader Connected to the Emulator.
Fig. 3.18. Communication Established Between the Emulator and the Reader.
 CHAPTER FOUR

DATA ANALYSIS AND INTERPRETATION

4.1 ESTABLISHING COMMUNICATION BETWEEN THE OBD II READER AND

THE ECU

Right off the bat correspondence between the OBD II peruser subsystem and the vehicle ECU

should have been checked.

A. Freematics OBD II emulator, as appeared in Figure 3.17 in section three, was utilized for

testing purposes. The emulator executes three OBD II conventions (CAN, ISO 9141-2 and ISO

14230-4. It has an OBD II 16 stick connector like a real OBD II consistent gadget and was

controlled from an AC to DC control supply associated with the mains. A USB to sequential

convertor was utilized for correspondence between the PC and the ELM327 IC on the peruser.

The speed and MAF parameter esteems were at first designed on the emulator. AT and OBD II

directions were sent from the MCU on the peruser to the emulator to initialise correspondence.

The information got from the emulator was then shown on the terminal program, Termite (which

was set at a baud pace of 38400 Kbps), as appeared in Figure 3.18 in part three.

To additionally confirm the structured peruser, a Bluetooth OBD II peruser was associated with

the emulator and an Android application on a cell phone was utilized to guarantee that the right

information was gotten.

Directions sent from the MCU were gone before by a brief character '>' and showed in blue

content. The emulator reacted effectively to the solicitations by first resounding the sent order

and afterward reacting with the mentioned information (speed and MAF) appeared in green

content.
Fig. 4.1. The Vehicle Display.

B. Vehicle Parameter Measurement Over Short Distance, The capacity and execution of the

OBD II peruser to gauge vehicle parameters: speed, MAF and separation over a short separation

was resolved.

The planned OBD II peruser was associated with the OBD II port of the vehicle. For this

examination a BMW 125i was utilized as it actualizes the CAN correspondence convention. A

USB to sequential convertor link was associated with a PC running Termite, and the MCU.

The vehicle was driven on a straight way for 400 m. The transmitted yield was seen on Termite.

The installed PC of the vehicle showed the quick estimations for speed, separation and fuel

utilization. The momentary fuel utilization (L/100 km) and separation (km) were appeared on the
advanced presentation, as in Figure 4.1. The speed was seen on a speedometer. A traveler sitting

with he driver mentioned the objective facts in the vehicle.

Tests of all parameters were taken each second for an absolute span of 100 s. The immediate

separation voyaged was gotten by duplicating the inspected speed with one second. The

subsequent worth was added to recently acquired outcomes to get the complete separation went

over the span of the excursion.

The underlying and last information focuses show occurrences when the vehicle began and

halted separately. The complete separation estimated by the framework was 380 m as appeared

by the diagram in Figure 4.2. The most extreme speed came to was around 34 km/h and the

greatest fuel devoured was 0.65 L/km as saw in Figure 4.3. It was additionally noticed that more

fuel was devoured at lower speeds.

C. Vehicle Parameter Measurement Over Long Distance

The capacity and execution of the OBD II peruser to gauge vehicle parameters: speed, MAF and

separation over longer separations was likewise decided.

The vehicle was driven over a separation of 9 km from the city to a thruway. An aggregate of

419 examples were taken each second for a span of 450 s.

The all out separation estimated as appeared in Figure 4.4 was 8.5 km. From Figure 23 the most

extreme speed estimated was 120 km/h and the greatest fuel utilization was 0.38 L/km. As noted

over the more slow the speed the more fuel was devoured.
Fig. 4.2. The Relationship Between Distance Covered by the Vehicle and Time.

Fig. 4.3. The relationship Between Speed and Fuel Consumption.

D. Correspondence Between the Wireless Modules

Correspondence and the scope of correspondence between the two Carambola2 modules is

checked.

A remote Carambola module was associated with a PC and the module in the moving vehicle

was controlled from the vehicle's USB port. Ping directions were always given from the remote

module. The achievement or disappointment of the ping direction was utilized to decide if the

module in the driving vehicle was out of range or not.

An all out correspondence scope of 900 m was resolved.

 CHAPTER FIVE

CONCLUSION, DISSCUSSION AND RECOMMENDATION

5.1 CONCLUSION

The examined structure is for the most part proposed for non-OBD vehicles. Not very many

alterations in such a vehicle can make it appropriate for the framework. In this structure

incredible accentuation has been given to make the framework easy to understand and vehicle

well disposed. When contrasted with the OBD framework in the market this plan has its very

own points of interest. Anyway the plan can be improved by expanding the quantity of parameter

to be watched. This can be effectively done as the utilized neighborhood controllers have

capacity to deal with more parameters. Additionally progressively neighborhood controllers can

be included effectively as every nearby controller transmit their information in same organization

to a solitary fundamental controller. The framework can likewise be coordinated with an

electronic fuel infusion (EFI) arrangement of vehicle as EFI takes criticism of various parameters

like coolant temperature, RPM, oxygen sensor, throttle position sensor and so on for controlling

the planning of fuel injectors.

5.2 DISSCUSSION

On-Board Diagnostic framework including OBD II programming and equipment have been

required on new vehicles sold in Canada since the 1998 MY (since the 1996 MY in the USA).

Along these lines, OBD II framework are not modern; they have been a necessary piece of new

vehicle working framework in this nation for right around seven years, two years longer in the

USA. Also, OBD II framework cross examination has been utilized in different LDV I/M

programs in Canada and the USA for quite a while. In the USA urban focuses with the most
genuine surrounding air contamination issues, socalled 'upgraded' I/M program regions, are

required by government guideline to join OBD II testing into their I/M programs.

From an ecological point of view, the advantage of OBD II over past OBD framework is that

OBD II framework screen and report on the status of the greater part of the framework in a

vehicle that identify with outflows and emanations control. In addition to the fact that

components are identified with exhaust emanations remembered for the general OBD II bundle,

yet observing the fuel stockpiling tank's capacity to keep up weight or vacuum, for example a

sort of hole check, enables the framework to give a proportion of fuel tank evaporative outflows

trustworthiness.

Another incredible advantage of OBD II, with respect to testing in an I/M program is that, when

contrasted with the vast majority of the most recent fumes emanations, tailpipe tests, OBD II

testing is moderately straightforward. OBD II cross examination in an I/M program isn't

burdensome and the test equipment or instrumentation that is required to direct an OBD II

framework cross examination is generally economical. Scanners for examining OBD II

framework ought to be standard gear in any cutting edge fix office.

The IM240 test is at present suggested as the favored I/M tailpipe emanations test by both the

EPA and by the CCME in its Code of Practice for Light Duty Vehicle Emissions I/M Programs.

In any case, one downside of the IM 240 discharges test is its intricacy. This multifaceted nature

not just identifies with the execution of the I/M program by commonplace or local specialists, yet

to the fix business and to general society. At times, that unpredictability has repelled both the

general population and the fix business from the I/M program.

AirCare authorities in British Columbia concur that one clear bit of leeway of OBD II testing is

its straightforwardness. The effortlessness of the OBD II test in an I/M program setting grasps
the purchaser, the I/M Administration and the fix business. OBD II tests are brief and

uncomplicated. The OBD II test evacuates client stress over vehicle harm since their vehicle

won't be driven at fast on a dynamometer. The I/M organization doesn't need to set up or control

assessment offices with complex, upkeep concentrated, equipment and the fix business can copy

the OBD II test utilizing generally economical hardware.

One of the essential mainstays of the OBD II framework, contrasted with its forerunners, is

institutionalization. The standard things incorporate deficiency codes, correspondence

convention, association equipment, and the sweep devices used to check the framework. This

institutionalization permits the all inclusive use of OBD II framework finding to all makes and

models. Institutionalization likewise permits a decrease in the unpredictability and cost of the

I/M test hardware.

Since OBD II framework screen vehicle execution while the vehicle is being worked, OBD II

framework additionally give constant demonstrative data. The OBD II framework stores

discharge data in addition to motor working conditions and parameters. These presentation

estimations and the announcing of that exhibition by means of put away codes furnishes a fix

specialist with on-street motor parameter information that may not be accessible by means of the

more established style tests that were led all things considered fix offices

From encounters with OBD II testing in I/M programs, as of November 2002, the OBD Working

Group in the USA inferred that application in an I/M program OBD II gave the accompanying

advantages: (CAAAC 2002)

• Accurate finding and fix – OBD II limits trips back for second and third assessments which can

be an issue in programs with discharge just I/M tests,

• Short examination times of five to ten minutes, and

• OBD gives exceptional evaporative emanations decrease benefits in that it recognizes some

evaporative control framework surrenders.

AirCare authorities likewise felt that OBD II should make I/M testing conceivable in zones

where the vehicle populace base may not bolster a tailpipe-testing program. In such territories,

OBD II testing should give a reasonable other option.

The equipment required for a perplexing tailpipe outflows test, for example, the IM240 is costly

and in this manner barely any, nearby fix offices are is probably not going to be furnished with

the equipment that would be required to copy that kind of discharges test. Accordingly, a further

advantage of OBD II testing is that it evacuates the issue of detachment between a testing office

(as a rule in a brought together I/M program) and a fix office. The fix business isn't looked with

test results that it can not copy and fixes that are available to discussion. As noted, most present

day fix offices are as of now liable to be outfitted with OBD II cross examination equipment.

5.3 RECOMMENDATION

OBD II framework are advancing. Throughout the following three or four years, in pretty much

every new model year the vehicles delivered will have a somewhat unique OBD II framework.

What's more, there are various developments that are being recommended for another age of

OBD framework.

5.3.1 OBD II - Changes in the Near Future

As noted in the early Chapters, various changes to OBD II have just been administered or

permitted.

CAN (Controller Area Network)

The CAN (Controller Area Network) vehicle correspondence convention for OBD II will be

permitted by EPA in 2004-2007 model a long time alongside the current conventions. Be that as
it may, as of the 2008 model year, CAN will be the main permitted convention and the current

conventions, SAE J1850, ISO 9141 and 14230-4, will be wiped out. (Gardetto 2003)

Vehicle Identification Number (VIN)

While trying to thwart the act of 'clean-examining', CARB is including a Vehicle Identification

Number (VIN) prerequisite to OBD II framework as of the 2005 model year. This operation will

be all inclusive in the USA since all producers as of now ensure to CARB necessities.

Adjustment Verification Number (CVN)

CVN is the Calibration Verification Number and is the aftereffect of a kind of 'registration'

figuring performed on the adjustment esteems put away in a vehicle's ECU. The CVN estimation

checks that OBD II programming has not been adulterated or modified. All OBDII prepared

vehicles, the two California and EPA confirmed, will bolster CVN by the 2005 MY.

NOx Catalyst Conversion Efficiency Monitoring In California, NOx transformation productivity

checking has been received and will start to be staged in on the 2005 MY vehicles. The OBD II

framework on every one of the 2007 MY vehicles will be required to screen for NOx

transformation productivity. (McCarthy 2004) Vehicle producers by the 2007MY should

demonstrate an impetus breakdown (MIL 'on') before the impetus weakens to the point that

tailpipe emanations come to (a) 1.75 occasions the FTP HC standard or; (b) 1.75 occasions the

FTP NOx standard; whichever happens first. Criteria (a) will be the constraining variable on

certain autos and criteria (b) will be the restricting component on others. For the phasein, for the

2005 and 2006 MY, a few vehicles will execute NOx change proficiency checking to a higher

interval edge of 3.5 occasions the FTP NOx standard in lieu of the last 1.75 occasions FTP NOx

standard.
Beginning with the 2004 model year, the EPA needs anybody (counting auto fix shops and

vehicle fans) to have the option to redesign their vehicle for a sensible expense. To achieve this,

the EPA asked SAE to make the J2534 API (Application Programming Interface).

Utilizing the J2534 API all 'vehicle interchanges' equipment will appear to be identical. The EPA

is constraining vehicle makers to discharge programming that updates the firmware on their

autos. The application must sudden spike in demand for Windows and utilize the J2534 API to

converse with the vehicle. A J2534 gadget connects to a vehicle's OBD connector on one side,

and a PC on the opposite side. In the engine, the gadget must talk a bunch of various vehicle

conventions (ISO9141, J1850VPW/PWM, CAN, and so forth.)

 REFERENCE

1. http://www.arb.ca.gov/msprog/obdprog/obdfaq.htm

2. http://eurlex.europa.eu/LexUriServ/LexUriServ.do?

uri=CONSLEG:1998L0069:19981228:EN:DF

3. http://www.iso.org/iso/catalogue_detail?csnumber=33619

4. http://www.epa.gov/fedrgstr/EPA-AIR/2005/December/Day-20/a23669.htm, U.S. EPA

regulations requiring ISO-15676 CAN standard to be supported for all U.S. sold cars

model year 2008 and later.

5. http://english.mep.gov.cn/inventory/Catalogue_Standards/200807/

t20080718_125885.htm

6. http://baike.baidu.com/view/171354.htm, Chinese news article on implementation of

OBD (Google translation http://translate.google.com/translate?

hl=en&sl=zh&tl=en&u=http://baike.baidu.com/view/171354.htm)

7. http://www.webpg.net/ALDLbareINST.pdf

8. http://www.techedge.com.au/vehicle/aldl160/160serial.htm

9. 1994 Corvette Service Manual, Book 2. General Motors Corporation. December 1993.

pp. 6E3–A-166 : 6E3–A-223.

10. 1994 Corvette Service Manual, Book 2. General Motors Corporation. Dec 1993. pp.

6E3–A-11.

11. EEC IV Code Reader: For 2.9L 12 Valve & Early Tdi, Ford Scorpio "Directive 98/69/EC

of the European Parliament". Publications Office of the European Parliament.

12. http://www.obd-codes.com/trouble_codes/
13. "Vehicle Standard (Australian Design Rule 79/01 – Emission Control for Light Vehicles)

2005". Australian Government ComLaw.

14. "Vehicle Standard (Australian Design Rule 79/02 – Emission Control for Light Vehicles)

2005". Australian Government ComLaw.

15. "Autoboss 30 Diagnostic Coverage List" (PDF). STN1110 specifications

16. http://www.progressive.com/myrate/myrate-default.aspx an auto insurer's OBD-II data-

logging

17. http://iosix.com/ a personal/fleet OBD-II datalogger

18. http://www.teensafedriver.com an auto insurer's in-car camera

19. http://www.diagnoseapparatuur.nl/EOBD-General-Periodic-Inspection EOBD General

Periodic Inspection rules

20. OBDuino open source OBD trip computer

21. www.qcontinuum.org/obdgauge/index.htm open source PDA app showing OBD-based

gauges

22. http://www.obdexperts.co.uk/Is_Your_Tracking_Lacking_letter.pdf

23. Bright, Peter (15 May 2010). "Car hacks could turn commutes into a scene from Speed".

Ars Technica. Retrieved 23 Aug 2012.

24. Mastakar, Gaurav (6 Apr 2012). "Experimental Security Analysis of a Modern

Automobile". University of Washington and University of California San Diego.

Retrieved 23 Aug 2012.

25. Marks, Paul (17 July 2013). "$25 gadget lets hackers seize control of a car". New

Scientist. Retrieved 5 November 2013.

26. "Pistonheads report into thefts via obd". Retrieved 2 July 2012.
27. Van den Brink, Rob. "Dude, Your Car is Pwnd" (PDF). SANS Institute.

28. Emidio DiGiampaolo and Francesco Martinelli,” A Passive UHF-RFID System for the

Localization of an Indoor Autonomous Vehicle ”,october 2012.

29. Fulvio Cascio t , Luca Console', Marcella Guagliumi3, “Generating on-board diagnostics

of dynamic automotive systems based on qualitative models”.

30. Gallanti, M . ; Roncato, M . ; Stefamm, A . ; and Tornielli, G. 1989. A diagnostic

algorithm based on models at different levels of abstraction .

31. Huaqun Guo, Yongdong Wu ,” Integrated Embedded Solution for Vehicle

Communication & Control” Institute for Infocomm Research, Connexis Singapore

32. Hu Jie, Yan Fuwu, Tian Jing, Wang Pan, Cao Kai, “Developing PCBasedAutomobile

Diagnostic System Based on OBD System”,IEEE

33. LiShiwu, Coll.of Transp, JilinUniv.,Changchun “Research on method for real-time

monitoring vehicle based on multi_sensors” china, 2011.

34. Shahin Farahani, ZigBee Wireless Networks and Transceivers, Newnes, Sep.2008