Post on 26-Jul-2018
2
Acknowledgements
First of all we would like to thank Almighty ALLAH for giving us the courage and
persistence to achieve our goals. We are extremely thankful to Dr. Laiq Hasan for his
continued supervision and guidance for entire duration of the project. We are much
thankful to Engr. Syed Aamir Ali Shah, and Engr. Zahid Ali for their extended co-
operation throughout the project. We are also very thankful to the sponsor of our project
and Principal Investigator of "OpenM4S" project Dr. Safi-Ur-Rehman for his consistent
support and encouragement during the project. Finally we are very thankful to Dr.Nasru-
min-Allah and his Panel team for their kind support.
Asim Ul Haq
Shawkat Ali
Dr. Safi Ur Rehman
3
Dedication
We dedicate our work to our beloved parents and teachers whom prayers have brought us
here, to our brothers, sisters and friends whose love and prayers able us to be here and
finally to our OpenM4S director and supervisors for their endless support and
encouragement.
Asim Ul Haq
Shawkat Ali
Dr. Safi Ur Rehman
4
Abstract
Efficient monitoring and management of vehicles is a complex task and is hard to do
manually. Enterprises having large fleet of vehicles are facing challenges of management
and performance optimization. Therefore, a system is developed for management and
performance optimization through real time monitoring of vehicle health and its
positioning. The proposed thesis is focused on developing hardware and software platform
for extracting, logging, reporting and analysis of vehicle health and positioning data.
Vehicle health data is acquired through On-Board Diagnostics (OBD) system & Engine
Control Unit (ECU). The system is able to communicate (get linked) with multiple kinds
of cars (including Japanese and European), and access diagnostic data from the ECU, for
real time monitoring, management, performance optimization and trouble shooting. The
system collects data using an OBD scanning tool, having an STN1110 OBD interpreter
IC, which can read all five generic OBD-II protocols, and hence is compatible with almost
all types of vehicles. The data can be sent to a mobile device, i.e. a cell phone, tablet or a
laptop through Bluetooth. A vehicle performance optimization module is developed in an
open source ERP system i.e. OpenERP® (now renamed as odoo®) for engine health
monitoring, fleet tracking, monitor fuel efficiency, prevent unsafe driving, as well as for
remote diagnostics, using the general OBD data.
The system can not only be used by professionals and hobbyists to monitor and manage
the vehicle health and positioning but, can also be used by organizations. Significance of
this system is to achieve management and performance optimization through initiating the
corrective measures based on the “just in time” information about vehicles.
5
Contents Acknowledgements .......................................................................................................................................1
Dedication .....................................................................................................................................................3
Abstract .........................................................................................................................................................4
Chapter 1 .................................................................................................................................................... 10
Introduction ................................................................................................................................................ 10
1.1 System Overview ............................................................................................................................. 10
1.2 Background ...................................................................................................................................... 10
1.3 Objectives and Motivation ............................................................................................................... 13
1.4 System Architecture ......................................................................................................................... 13
1.4.1 Diagnostic System Architecture .................................................................................................... 14
1.4.2 Logging Data ................................................................................................................................. 15
1.5 Significance of Proposed Work ........................................................................................................ 16
Chapter 2 ................................................................................................................................................ 17
Literature Review ................................................................................................................................... 17
2.1 Universal OBDII Scan tool .............................................................................................................. 17
2.2 A Prototype System .......................................................................................................................... 17
2.3 Elimination of Fault Codes ............................................................................................................... 18
2.4 Fleet Monitoring ............................................................................................................................... 19
2.5 Standard Protocols ............................................................................................................................ 20
2.6 Vehicle Communication Interface .................................................................................................... 21
2.7 ERP System Characteristics ............................................................................................................. 22
2.8 Open ERP (ODOO) .......................................................................................................................... 23
Chapter 3 ................................................................................................................................................ 25
Hardwar Design and Implementation ..................................................................................................... 25
3.1 Main Hardware Components Used .................................................................................................. 25
3.2 STN1110 (Multiprotocol OBD to UART Interpreter IC)................................................................. 25
3.2.1 Features: ........................................................................................................................................ 25
3.2.2 STN1110 vs. ELM327 IC’s ........................................................................................................... 26
3.3 LM399PWR (Comparator) ............................................................................................................... 27
3.3.1 Features: ........................................................................................................................................ 27
3.3.2 Applications: ................................................................................................................................. 27
3.4 LM317LD (Positive-Voltage Regulators) ........................................................................................ 28
6
3.4.1 Features ......................................................................................................................................... 28
3.5 MCP2551 ........................................................................................................................................ 28
3.5.1 Features: ........................................................................................................................................ 29
3.6 78M05 (5V Voltage Regulator) ........................................................................................................ 29
3.6.1 Features ....................................................................................................................................... 30
3.7 AME1117 (3.3V Voltage Regulator) ............................................................................................. 30
3.7.1 Application: ................................................................................................................................. 30
3.8 Diodes ............................................................................................................................................... 30
3.8.1 Description: ................................................................................................................................... 30
3.9 Transistor: ......................................................................................................................................... 31
3.9.1 2N3904 .......................................................................................................................................... 31
3.9.1.1 Features .................................................................................................................................. 31
3.9.2 2N3906 .......................................................................................................................................... 31
3.9.2.2 Applications ............................................................................................................................ 31
3.10 DLC (Data Link Connector) ........................................................................................................... 32
3.11 Bluetooth Serial Interface Module ................................................................................................. 32
3.12 Hardware Implementation .............................................................................................................. 34
3.12.1 Block Diagram ............................................................................................................................ 34
3.12.2 Circuit Diagram ........................................................................................................................... 34
Chapter 4 ................................................................................................................................................ 37
ERP System Module Development ........................................................................................................ 37
4.1 OpenERP (Odoo) System ................................................................................................................. 37
4.1.1 Proposed Work .............................................................................................................................. 38
4.2 Developing Module in OpenERP ..................................................................................................... 40
4.3 Installing a Module ........................................................................................................................... 40
4.4 Data Logging and Uploading Using Torque .................................................................................... 42
4.5 Importing Log File in OpenERP ...................................................................................................... 43
Chapter 5 ................................................................................................................................................ 45
Testing and Results ................................................................................................................................ 45
5.1 Testing OBDII Hardware ................................................................................................................. 45
5.1.1 Testing With Teraterm Terminal ................................................................................................... 45
5.1.2 Real Time Testing ......................................................................................................................... 46
5.1.3 Log File Data and Its Output ......................................................................................................... 51
7
Chapter 6 ................................................................................................................................................ 55
Application and Conclusion ................................................................................................................... 55
6.1 Applications: .................................................................................................................................... 55
6.1.1 User Applications .......................................................................................................................... 55
6.1.2 Enterprise applications .................................................................................................................. 55
6.2 Conclusion .................................................................................................................................. 55
6.3 Recommendation ........................................................................................................................ 56
Appendix A ............................................................................................................................................ 57
List of Standard PIDs and Mode of Communication .............................................................................. 57
Appendix B............................................................................................................................................. 68
Steps for Installing OpenERP in Ubuntu ................................................................................................. 68
Appendix C............................................................................................................................................. 77
Testing with TeraTerm Terminal ................................................................................................................ 77
Appendix D ............................................................................................................................................ 82
OBDII ....................................................................................................................................................... 82
OBDII Standard Connector and Protocols .............................................................................................. 83
Bibliography ............................................................................................................................................... 88
8
List of Figures
Chapter 1
Figure 1. 1: System Overview ..................................................................................................................... 10
Figure 1. 2: ECU and Sensor........................................................................................................................ 12
Figure 1. 3: Architecture of Diagnostic system........................................................................................... 15
Chapter 2
Figure 2. 1: Data Logging ...........................................................................................................................21
Chapter 3
Figure 3. 1: STN1110 IC Pins Configuration ..............................................................................................27
Figure 3. 2: ELM 327 IC .............................................................................................................................27
Figure 3. 3: STN1110 ..................................................................................................................................27
Figure 3. 4: LM339 IC ................................................................................................................................28
Figure 3. 5: LM339 IC pin Configuration ...................................................................................................28
Figure 3. 6: LM317 LD connection diagram ...............................................................................................28
Figure 3. 7: 5V Voltage Regulator ..............................................................................................................29
Figure 3. 8: MCP2551 Pin configuration ....................................................................................................29
Figure 3. 9: 7805 Connections diagram ......................................................................................................29
Figure 3. 10: 1N4148 diode .........................................................................................................................31
Figure 3. 11: AME 1117 Connection diagram ............................................................................................31
Figure 3. 14: 2N3904 Transistor pin diagram .............................................................................................32
Figure 3. 12: 2N3906 Transistor pin diagram .............................................................................................32
Figure 3. 13: DLC connector .......................................................................................................................32
Figure 3. 15: HC06 Bluetooth module pin configuration ............................................................................33
Figure 3. 16: HC06 Bluetooth module ........................................................................................................33
Figure 3. 17: HC06 Bluetooth Pin diagram .................................................................................................33
Figure 3. 18: Block diagram of the System .................................................................................................34
Figure 3. 19: 3D PCB Design ......................................................................................................................35
Figure 3. 20: Ares PCB Design ...................................................................................................................35
Figure 3. 21: Breadboard Design.................................................................................................................36
Chapter 4
Figure 4. 1: OpenERP (old name) Odoo (new name) Labels ......................................................................38
Figure 4. 2: Module in OpenERP/ Odoo .....................................................................................................38
Figure 4. 3: OpenERP Login .......................................................................................................................39
Figure 4. 4: Database management screen ..................................................................................................41
Figure 4. 5: Main Setup screen ....................................................................................................................41
Figure 4. 6: Torque Output ..........................................................................................................................43
Figure 4. 7: Importing log file .....................................................................................................................44
Figure 4. 8: Uploaded data in ERP Module.................................................................................................44
Chapter 5
9
Figure 5. 1: Serial Port Setup ......................................................................................................................45
Figure 5. 2: Terminal Setup .........................................................................................................................46
Figure 5. 3: Successful connection of Torque .............................................................................................47
Figure 5. 4: Connection Established ............................................................................................................49
Figure 5. 5: PIDs .........................................................................................................................................49
Figure 5. 6: Available Sensors and PIDs for Logging .................................................................................50
Figure 5. 7: Dashboard ................................................................................................................................50
Figure 5. 8: PIDs to Log files ......................................................................................................................51
Figure 5. 9: Log file containing different parameters information ..............................................................51
Appendix B
Figure Appendix B. 1: OpenERP.py ...........................................................................................................72
Figure Appendix B. 2: The Fleet info file ...................................................................................................73
Appendix D
Figure Appendix D. 1: DTC Specification ..................................................................................................87
List of Tables
Chapter 3
Table 3. 1: Comparison between STN1110 and ELM327 ..........................................................................26
Chapter 4
Table 4. 1: List of Fields..............................................................................................................................40
Appendix D
Table Appendix D. 1: DLC Pins Description ..............................................................................................83
Table Appendix D. 2: Protocol specification ..............................................................................................84
10
Chapter 1
Introduction
1.1 System Overview
A universal OBDII scanning tool, using a PIC microcontroller, STN1110 IC, is developed
to extract information from vehicle ECU. The STN1110 is a UART to OBD interpreter
IC that convert messages between them. This IC connects to Bluetooth at one side and
OBD connector on the other side. The Bluetooth is then connected to an interface, which
can be a mobile phone or PC software. User can save different information from vehicle
by creating log file in these software applications and then send this log file to an ERP
web server. This system consists of hardware and software parts as shown in Figure 1.
Hardware Software
1.2 Background
OBDII stands for Second Generation On-Board Diagnostic system. It provides a set of
standards for vehicle's self-diagnostic and reporting capability. A large number of new
vehicles support OBDII. To analysis and working with OBDII system the most important
things is that each compliant vehicle must have:
Link App ERP
server
STN11
10
OBDII
System
Figure 1. 1: System Overview
11
Sixteen pins Data Link Connector(DLC) and
A standard way to communicate with the vehicle’s computer, also known as
Electronic Control Unit or Engine Control Unit (ECU).
A large number of information is obtained from ECU through OBD system. For example
the status of the malfunction indicator light (MIL), diagnostic trouble codes (DTCs),
information inspection and maintenance (I/M), freeze frames, Vehicle
Identification Numbers (VIN), hundreds of real time parameters and many more. Details
of OBDII are presented in Appendix D.
In automotive electronics, ECU is a general term used for any embedded system that
control one or more electrical system or subsystem in vehicles. There are many types of
ECU including Electronic/ Engine control module (ECM), Power train control module
(PCM), Transmission control module (TCM), Brake control module (BCM / EBCM),
Central control module (CCM), General electronic module (GEM), Body control
module(BCM), Suspension control module (SCM). All these system taken together are
sometimes called car computer. Latest automobiles have up to 80 or more ECUs.
Increasing complexity and managing the number of ECUs in a vehicle has become a key
challenge for Original equipment manufacturers (OEMs).
The On board Diagnostic System was made to control and monitor vehicle exhaust
emissions. At Generation 2 of its development, the OBDII now supports 11 different types
of protocols aimed at all types of vehicles. The problem that arises is that the vehicles may
not use the protocols on the specified methodology of pinouts and DLC rules and
regulations, so a direct need is to design a device that would support all or most
12
communication protocols and have a transfer and scan mechanism for successfully
establishing communication to any vehicle [1].
Modern OBD Systems make use of a digital standardized (ISO standardized) cable called
as the DLC for intercommunication between host and OBD. AT commands are a specific
communication way between host and the OBD interpreter IC (in our case STN1110).
They are called AT commands due to the observation that they start with “AT” followed
by xx, where xx is any alphanumeric acceptable combination by the interpreter IC. The
communication starts with three bytes of request code and a reply may consists as big as
seven bytes of information in which start bit, stop bit, parity and checksum are added side
by side in a standard format specified by the Society of Automotive Engineer (SAE). The
checksum is created by the interpreter to make communication easy. The breakdown of
communication is given below:
First byte = “MODE” specifies the type of data required,
The second byte or more bytes = “PID” (parameter identification) specify the
requested information.
Mostly the first request sent by the host is AT00 which specifies the number of OBD
parameters supported by the Vehicle. [2].
Figure 1. 2: ECU and Sensor
13
ERP system is a platform used for business management. It is an integrated application
that an organization can use to store and manage data. ERP system provides a real-time
view of fundamental business processes by using common database. It eases information
flow between all business function and manages connections to outside stakeholders.
1.3 Objectives and Motivation
There are different OBDII Scan tools available for vehicle diagnostics, but these are
specific in their functions and are compatible only with vehicles having the same OBDII
standard as scanning device have. Also, some of these diagnostic tools have high cost, not
too efficient nor user friendly. Also, software solutions for vehicle management and
performance optimization are costly. Therefore, project objectives are:
1. A low cost universal OBDII scanning device that is compatible with every type of
vehicle, for real time monitoring and optimization of automobile’s performance.
2. To develop a vehicle performance optimization module in OpenERP.
1.4 System Architecture
Vehicle health and positioning telemetry system is a way of monitoring status of engine
condition, location, movements, status and behaviour of a vehicle or fleet of vehicles. This
is achieved through a remote collection of data through a combination of hardware devices
installed in a vehicle, communication technologies and software’s. With the advancement
of new paradigms of technology, it is becoming easy to manage and control vehicles
through telemetric systems. Enterprises having large fleet of vehicles are facing
challenges of management and performance optimization. Therefore, a telemetry system
is developed for optimal management through real time monitoring of vehicle health and
its positioning.
Hardware and software platforms are required for extracting, logging, reporting and
analysis of vehicle health and other data. This data from vehicle is acquired through On-
Board Diagnostic (OBD) system &Engine control Unit (ECU). There are several sensors
14
available in the vehicles which are connected to the ECU. One can communicate with an
ECU through connecting an OBD scanning tool in OBD data link connector or port, as
OBD system has then made it easy to extract data from the engine. The latest technology
in use is OBD-II and there is a 16 pin OBD-II connector, in most of the cars manufactured
after 1996 models. One can view information such as mileage, mpg, fuel consumption,
error codes, air/fuel ratio, timing and many other parameters depending on the sensors
available in the vehicle to see the performance of a vehicle.
Communication technologies and software’s are used to view this OBD system data.
There are many ways to read the data using android device or desktop application. A
mobile, desktop or web application connects to the OBD scanner through a Bluetooth or
WI-FI. These applications are used to get data from OBD scanner. Also, the user is able
to save the data into log files on the mobile device or PC. Similarly, the data can be sent
to the Enterprise Resource Planning (ERP) system in an organization, just in time to the
repair and maintenance department, where it is evaluated to identify the faults or to detect
anomalies, and can help for managing the performance of vehicles in an optimal manner.
1.4.1 Diagnostic System Architecture
OBD system can be separated in 3 parts from the perspective of layering of OBD system
diagnostic protocol; the assorted qualities in physical layer, conncection layers and
uniqueness in application layer. PC diagnostic software is the basic part of the diagnositc
system. This gives human computer interaction interface, and accomplishes the
application layer of the protocol. Moreover, it helps the single support station which join
the automobile information by web. Thus a diganostic system is structured and the
capacity of asset imparting and remote diagnotics could be accomplished.
15
Vehicle Communication interface (VCI) system is the bridge which connects the vehicle
diagnoictic system and host computer diagnosis system. It implements the conversion of
different communication protocols between network and host computer diagnosis system.
When the car is moving, ECU constantly mointors the input information of sensors and
actuators by CAN. When it detects one or more fault information, it will lit up the MIL
and then store the fault information in the form of diagnostic codes into memory. When
diagnosing fautls, diagnostic devices communicate with ECU and get the storage fault
codes and other information, according to diagnostic protocols used. Architecture of the
over all system is shown in Figure 3.
1.4.2 Logging Data
Data of available sensor can be logged and stored in log file for further analysis. The file
is in CSV format generally store in the log folder of the available software.
Figure 1. 3: Architecture of Diagnostic system
16
1.5 Significance of Proposed Work
OBDII system requires all light duty cars and trucks to monitor specific systems using
generic criteria for evaluation and reporting of system status, and for indicating problems
to the motorist and/or technician. OBDII code provides definitions, description, symptoms
and a possible solution of vehicles faults.
Using this OBDII scan tool one can easily diagnose vehicle and can avoid different
accident due to hide failures in vehicle. Also future faults in vehicle are easily diagnosed.
Also for fleet management organization, it provide a better and sophisticated way of
diagnosing and monitoring status of engine condition, location, movements, status and
behaviour of a vehicle.
17
Chapter 2
Literature Review
Automization of vehicle is very important field and is started since 1990s. Many scientist
contributes in this area and achieve many important goals. Lots of hardware are made and
many techniques and methods are applied to achieve efficiency in automization of
vehicles. In this chapter, few methods and techniques of onboard diagnostic system
engineering is briefly described.
This chapter mainly focus on description about related work on OBDII system and OBDII
scanning devices. A sketch of ERP system and its related work are also defined. Literature
review covers the OBDII system analysis, Data Collection, Monitoring Performance,
Efficiency analysis and actions based on test data, Fleet management, Managing
Teenage/Amateur Drivers, Preventive measures, Proactive measures.
2.1 Universal OBDII Scan tool
On-Board Diagnostic System (OBD) is a very important component in automization of
vehicles and machinery. Jie and H. Fuwu (2010, March) Developed PC-Based
Automobile Diagnostic System Based on OBD System. Automobile diagnosis has been
taken into considerations at the start of 1970 in the form of sensors embedded in them.
Today, the international manufacturers all over the world have successfully adapted OBD
II as the standard for checking, maintaining, diagnosing and removing faults in
automobiles in order to eliminate environmental hazards due to emissions of toxic gases
and particles.
2.2 A Prototype System
Roscaet. Al (2011) developed and described the design, development, and data processing
characteristics of the prototype system [2]. A microcomputer-based multichannel data
18
acquisition system is used to acquire high frequency transient information typified by, but
not limited to, automotive vehicle crash test applications. The system was designed to be
mounted on the test vehicle during a vehicle crash, will accommodate up to 240 channels.
Each channel is comprised of a stand-alone microcomputer, memory for data storage,
signal conditioning for piezo-resistive transducers, automatic calibration and zero offsets,
and programmable gain amplifier. The microcomputer is based upon a Motorola
6801/68701 microcomputer.
2.3 Elimination of Fault Codes
The On-board Diagnostic (OBD) standards were released and established as a measure to
get control over the vehicular emissions. The Engine Control Unit (ECU) constantly
monitors the various aspects of the vehicle for any possible faults such as an engine
misfire, or a high temperature or a failure of the torque system. Upon failure or detection
of an error, the ECU stores that data in a memory location of the ECU called as the freeze
frame memory. Freeze frame is a snapshot of the information of all the sensors at the time
of occurrence of a fault.
If we focus on the preventive side of the possible applications of a remote data scanner
device, there is almost no or very scarce work available. OBDII is specialized in a sense
that it has assigned alphanumeric codes to errors that may occur in the automobile. So at
the occurrence of the error, the info is stored and a Diagnostic Trouble Code is set in the
ECU which can be read in the memory of the ECU by the scanner device and then try to
eliminate it [3]. The ECU of a vehicle stores only faults and DTCs when there is an actual
error in the vehicle. The device:
1. Detect and transmit fault codes to the host
2. Predict faults that may occur with time
19
Global Information System (GIS) is utilized in the vehicle and the location of the vehicle
is also being transmitted to the server through cell-phone’s General Packet Radio Service
(GPRS) system [4].
2.4 Fleet Monitoring
Siegel, J. E. (2011) Design and developed a remotely reconfigurable vehicle telemetry
system for consumer and government applications. Government and enterprises are
seeking ways to control vehicle through online monitoring system based on the social
determinants, cost optimization, automobile’s health. This system will provide ways of
billing, monitoring, safety and control over disaster and accident preventive methods as
well as optimization techniques for automobiles services. Consumers will appreciate the
amount of information that their cars will feedback to them through mobile phones or
web-based applications.
Few aspects On-Board Diagnostic System try to cover.
Data Collection
Monitoring Performance
Efficiency analysis and actions based on test data
Fleet management
Managing Teenage/Amateur Drivers
Preventive measures
Proactive measures.
No such system is made until now which can tackle all the above mentioned aspects.
Presently just handheld standalone tools are present for diagnostics purposes of detecting
faults and diagnostics trouble codes associated with automobile control units. Problem
with this handheld standalone device are:
Engine parameters measurement is not done freely for calculations purposes.
Real time feedback is not provided [5].
20
United States Environmental Protection Agency (EPA) has mandated that the DTCs
should be set only when there is emissions beyond control ranges. But manufacturers have
programmed their vehicles to trigger DTC events based on any faults in the vehicle.
Consider a scenario in which no DTC is set but there is a definite problem in the vehicle’s
functioning. So in that case, we may need data fetched from the OBD scanner for the
purpose of eliminating and correcting faults for optimization and preventive measures. A
technician may sometime use his common sense and intuition to detect faults based on
experience. But these methods are time consuming and tiring.
So a universal scanner is needed with advanced diagnostics capabilities to better cope with
these MIL, DTC and other unknown errors for the health and safety and performance
optimization of machinery [6]. OBD is responsible for monitoring:
Catalytic converters
Evaporative control system
Emissions control system
Oxygen sensors
Emissions related sensors and actuators
Engine misfire
Exhaust gas recirculation (EGR)
Fuel system
Closed loop system performance etc. [7]
2.5 Standard Protocols
OBD-II Standards are installed inside the Engine Control Unit (ECU) known as power
train control module of the vehicle (PCM). OBD-II scan tool is used to extract useful
information from vehicle. Some of OBD-II scan tool related devices are available in the
market e.g. personal digital assistant Dyno/ OBD-II scan tool, Car Chip fleet, Driver Right
600, Scan Gauge. But there are some limitations in these devices. So to supports all the
21
features together a universal OBD-II scan tool is needed with support of ISO, SAE
standardized the OBD-II. There are five communication protocols used to retrieve data
from OBD-II which follow the SAE J1979 standard common diagnostic test mode. These
five protocols are SAE J1850 (PWM), SAE J1850 (VPW), ISO 9141-2, ISO 14230-4
(KWP 2000), ISO 15765-4 (CAN).The data get through OBD-II is then displayed on
driver information system (DIS) which is connected through OBD-II connector. It also
provides data logging using multimedia card attached in USB slot of Personal Computer
[8].
2.6 Vehicle Communication Interface
The interface is very important for communication with vehicles. The interface is needed
for communication of application layer with physical layer. The physical layer is basically
the electronic control system in this case. The Structure of automotive electronic control
system becomes more and more complicated with the increasing application of electronic
control technology. Finding the cause and position of faults in vehicles is difficult. Vehicle
consists of Engine Control Unit (ECU) having connections with different sensors. When
vehicle starts ignition, ECU constantly monitors the incoming information of sensors
attached it. When it detects any fault it will blink the fault indicator (MIL) and store the
Figure 2. 1: Data Logging
22
incoming fault information in the memory in the form of diagnostic codes. When
diagnostic devices communicate with ECU it will retrieve the storage fault diagnostic
codes and other information from the memory, according to diagnostic protocols occur in
diagnostic devices. OBD systems can analysis different kinds of diagnostic protocol use
on OBD diagnostic system. Presently, widely used diagnostic equipment is OBD-II.
Desktop based diagnostic software is used to diagnose the system which is the main part
of diagnostic system. It provides human-computer communication interface. The vehicle
diagnostic system and diagnostic software can be connected with the help of vehicle
Communication Interface (VCI) system. This system is used for data transmission as well
as conversion of different communication protocols between network and computer [9].
There are three sub module of Vehicle Communication Interface (VCI) system.
1. Protocol conversion function module: This module is used for level transmission
between vehicles protocol and computer (Host).
2. Host microcontroller module: This module is used for analysis the on board data
and send message to Host and at the same time receive data from host.
3. USB bridge module: This module is used to transfer serial data to USB data and
ensure the communication between microcontroller and the Computer (host).
2.7 ERP System Characteristics
ERP stands for Enterprise Resource Planning, ERP is basically known as Enterprise
Information System. It has great advantages over the manual information system e.g.
efficient monitoring over all the resources of enterprise, timely scheduled maintenance
and management, human resource planning, project planning, Accounts and financial
planning and monitoring etc. Because of such great advantages ERP system gets very
importance in the industries, and most of the companies adopts ERP systems.
Companies are usually triggered by the appearance of some symptoms to adopt ERP
systems. Such symptoms can be high levels of inventory, mismatched stock, lack of
23
coordinated activity, excessive need for reconciliation, flouting of controls, poor customer
response levels, poor cost control, lack of efficiency and lack of a total visibility into the
overall supply chain performance [22]. Shehab et al. (2004) argue that the ERP package
selection process is deceptively difficult.
There is a concept used in software engineer’s community known as Open Source
Community. Open Source Software (OSS) now exists for many of the most common types
of software ranging from servers to office programs. OSS means that the source code is
available for programmers to view, read, modify and re-distribute. OS software are given
GPL (General Public Licence) Licence. Same concept is also present in ERP systems i.e.
Openbravo, tryton, xTuple ERP, AvERP, OpenERP (now known as ODOO) etc. An ERP
system integrates business processes throughout an organization, thereby improving
speed, efficiency and accessibility of information flows. This offers benefits such as
lowered cost for software, along with flexibility and avoidance of vendor lock-in.
According to Umble et al. ( “a successful ERP project can cut the fat out of operating
costs, generate more accurate demand forecast, speed production cycles, and greatly
enhance customer service”. The evaluation of the chosen Open Source ERP systems is
going to be performed based on a set of dimensions and features. The defined set of
dimensions is inspired from the organizations’ needs [23].
2.8 Open ERP (ODOO)
The concept of OpenERP and development of application begins 2005, and AGPL licence
was given. The development of software is done mostly in Python, because the python-
based system is familiar to both Windows and Linux operating systems. It uses
PostgreSQL database and for export and import CSV format is used.
There are around 300 modules present in ODOO with different functionalities. Few
modules are automatically installed during installation of ODOO system. Installing
24
additional module along with their visual presentation data provides an appropriate way
of exploring the entire basic system. The update facility is also available but it depends
on the client’s choice, whether the client want to update the module automatically or
manually or may be the client do not want any update for specific module. That is why
the update is left on the user’s choice.
25
Chapter 3
Hardwar Design and Implementation
Hardware is the core part of our project. The hardware consists of multiple components
where STN1110 IC is the main component of hardware. The function and structure of
each component are presented in the following section. Temporary testing and
implementation of this hardware is carried out using a breadboard. Simulation and
Schematic of this system was designed using different software’s such as Proteus, Eagle
and Multisim etc.
3.1 Main Hardware Components Used
The following components are used during hardware implementation:
STN1110 IC, LM399PWR IC, LM317LD IC, MCP2551 IC,78MO5 IC, AME1117 IC,
1N4148 Diodes, 2N3904 and 2N3906 Transistors, DLC and various resistors.
3.2 STN1110 (Multiprotocol OBD to UART Interpreter IC)
The smallest and lowest cost PIC multiprotocol OBD to UART interpreter IC is STN1110.
With the help of STN1110 one can easily access vehicle data such as diagnostic trouble
codes, MIL status, Inspection and Maintenance information. ELM327 command set has
full supported by STN1110.This IC is based on PIC micro-controller which is
implemented on PIC24HJ128GP502 reference family. It support all AT command like
ELM327. It also supports ST commands sets.
3.2.1 Features:
This IC is supported all legislated OBDII protocols. Such as
ISO 15765-4 (CAN)
ISO 14230-4 (keyword protocol 2000)
ISO 9141-2 (Asian, European, Chrysler vehicles)
26
SAE J1850 VPW (GM vehicles)
It also has support for non-legislated OBDII protocols. Such as
ISO 15765
ISO 11898 (raw CAN)
And also support for SAE J1939 OBDII protocol.
3.2.2 STN1110 vs. ELM327 IC’s
Automatic protocol detection algorithm of Default ELM327 doesn't work upon several
autos that use the ISO 9141‐2 or the SAE J1850 protocol. STN1110 incorporates a
superior algorithm that guarantee the device connects reliably even to vehicles that do not
totally comply with the OBD‐II standards criteria [24]. Figure 55 show pin configuration
of STN1110.
The following Table 1shows the comparison between STN1110 and ELM327 IC’s.
Table 3. 1: Comparison between STN1110 and ELM327
27
3.3 LM399PWR (Comparator)
This package consists of four independent voltage comparators and design to operate for
a single voltage supply. Figure 8 show LM399PWR IC and Figure 9 shows the pins
configuration of LM399PWR.
3.3.1 Features:
Its initial tolerance is 2 %.
Its temperature coefficient is 0.5 part per million.
3.3.2 Applications:
Precision voltage reference for millimetres
Laboratory measurement equipment
used in Industrial monitor instruments
used as High accuracy data converters
Figure 3. 1: STN1110 IC Pins Configuration
Figure 3. 3: STN1110 Figure 3. 2: ELM 327 IC
28
3.4 LM317LD (Positive-Voltage Regulators)
LM317LD is J1850 transceiver. It is an adjustable positive voltage regulator which has
capability of excess current is 100ma and can effort voltage 1.2v up to 37v. Figure 10
shows the connection diagram of LM317LD.
3.4.1 Features
capability of excess Current is 100 mA
it can effort 1.2 V up to 37 V
Output Transistor Safe−Area Compensation
Eliminates Stocking Many Fixed Voltages
3.5 MCP2551
MCP2551 is CAN transceiver. Interface between a CAN protocol controller and the
physical bus can be served by MCP2551. Transmitting and receiving for the CAN
protocol controller is provided by MCP2551. Operating speeds is up to 1 Mb/s. Figure 11
shows pin configuration of MCP2551.
Figure 3. 4: LM339 IC Figure 3. 5: LM339 IC pin
Configuration
Figure 3. 6: LM317 LD connection diagram
29
3.5.1 Features:
Supports 1 Mb/s operation
it can effort 12 V up to 24 V
Power-on reset and voltage brown-out protection
CAN bus will not be disturbed by an unpowered node
Low current standby operation
3.6 78M05 (5V Voltage Regulator)
7805 is a 5V voltage regulator. It support input voltage up to 37V and maintain output
voltage at a constant value of 5V. Appropriate values of capacitors are connected to input
and output pins depending upon the required voltage level. Figure 12 show pin
configuration and figure (13) show connection diagram of 78M05.
Figure 3. 8: MCP2551 Pin configuration
Figure 3. 7: 5V Voltage Regulator
Figure 3. 9: 7805 Connections diagram
30
3.6.1 Features
It produce Output Current up to 0.5A
It produce Output Voltages of 5V
Thermal Overload Protection
Short Circuit Protection
3.7 AME1117 (3.3V Voltage Regulator)
AME1117 is 3.3V positive voltage regulator. It support input voltage up to 7V and
maintain output voltage at a constant value of 3.3V. For the required output voltage level
an appropriate values of capacitor can be connected at the input and output pins. Figure
14, show connection diagram of AME1117 IC.
3.7.1 Application:
It is High Efficiency Linear Voltage Regulators.
It can convert 5volt in to 3.3Volt.
It is used in Battery Charger.
3.8 Diodes
Diodes are used for regulation purpose here. 1N4148 diode are used here which is
discussed below:
3.8.1 Description:
It is a switching diode. It also used in high-speed rectifying. Figure 15show 1N4148
diode.
3.8.1.1 Features
switching speed is high
It is high Reliability
31
very low current leakage
3.9 Transistor:
3.9.1 2N3904
It is NPN General Purpose Amplifier. Its pin configuration is shown in Figure 16.
3.9.1.1 Features
It is used as amplifier and as a switch.
3.9.2 2N3906
It is PNP switching transistor. Its pin diagram is shown in Figure 3.12.
3.9.2.2 Applications
High-speed switching used in industrial applications.
Figure 3. 10: AME 1117 Connection diagram
Figure 3. 11: 1N4148 diode
32
3.10 DLC (Data Link Connector)
Data Link Connector is connected under the dash at the steering column. It is sixteen pins
diagnostic connector used for connection with ECU. It interfaces the OBDII scan tool
with the vehicle computer to access On-Board Diagnostic and live data streams.
3.11 Bluetooth Serial Interface Module
There is different level of Bluetooth module.HC-06 is civil level module. It is used for
converting serial port to Bluetooth. There are two modes of Bluetooth modules master
and slaver device. The HC-06 module only can be a slave. It is shown in Figure 3.15, and
its pin configuration is shown in Figure 3.16.
KEY: This pin need to pull-up while power-on-reset of the module to enforce AT
mode.
VCC: It indicated Voltage. It worked for both 3.3V and 5V.
GND: It indicates Ground.
Figure 3. 13: 2N3904 Transistor pin diagram Figure 3. 12: 2N3906 Transistor pin diagram
Figure 3. 14: DLC connector
33
TXD: This pin is to be connected to RX of the STN1110 PIC microcontroller. It is
Output of the module.
RXD: This pin is to be connected to TX of the STN1110 PIC microcontroller. It is
Input of the module.
State: This pin is connected to LED of the module. Used to check the connection of
Module.
These pins are clearly seen in Figure 21.
Figure 3. 16: HC06 Bluetooth module Figure 3. 15: HC06 Bluetooth module pin configuration
Figure 3. 17: HC06 Bluetooth Pin diagram
34
3.12 Hardware Implementation
3.12.1 Block Diagram
Before implementing the circuit the block diagram was design for the sake of simplicity.
The block diagram shown in Figure 22, represents the flow of project. The data link
connector will be attached with the car (OBD II), where the line driver circuit will be
interfaced with it; the line driver circuit is further interfaced with main part (STN1110)
controller. The STN1110 part will be further attached with communication translational
circuit; here in this case Bluetooth will be used to send the data remotely.
3.12.2 Circuit Diagram
In order to communicate with the STN1110 IC, a communication link is needs to be
developed. A micro-controller used as Communication Bridge requires oscillator to
Figure 3. 18: Block diagram of the System
35
provide pulses. Electronics, the developers of the STN1110 IC provide a schematic of
recommended connections for it. The schematic is reproduced because of unavailability
of some recommended components. The followings figures shows schematic and PCB
design develops in Proteus application.
Figure 3. 19: 3D PCB Design
Figure 3. 20: Ares PCB Design
36
Figure 3.20, indicates the whole circuit diagram of this project, using a breadboard starting
from the regulator which supplies the pure DC voltage to the STN1110, comparator, high-
speed CAN as these all components need to be activated through proper power supply so
that they can work properly. The STN1110 will be used as a central part which will
perform the main task.
After implementing the block and circuit diagram now it is easily to build the hardware
(PCB).
Figure 3. 21: Breadboard Design
37
Chapter 4
ERP System Module Development
Enterprise Resource Planning (ERP) is business management software. This is an
integrated application that an organization can use to store and accomplish data from every
stage of business, including all sorts of product planning and development. ERP provides
a real time view of core business processes by using common database. It eases
information flow between all business function and manages connections to outside
stakeholders.
4.1 OpenERP (Odoo) System
ERP system is a platform used for business management. It is an integrated application
that an organization can use to store and manage data. ERP system provides a real time
view of fundamental business processes by using common database.
Organizations are usually triggered by the appearance of some symptoms to adopt ERP
systems. Such symptoms can be high levels of inventory, mismatched stock, lack of
coordinated activity, excessive need for reconciliation, flouting of controls, poor customer
response levels, poor cost control, lack of efficiency and lack of a total visibility into the
overall supply chain performance. Open source software (OSS) now exists for many of
the most common types of software ranging from servers to office programs. OSS means
that the source code is available for programmers to view, read, modify and re-distribute.
An OpenERP system integrates business processes throughout an organization, thereby
improving speed, efficiency and accessibility of information flows. Organizations require
a cost effective business management solution that enables control and efficiencies, so
OpenERP is a business management solution. It requires free software licenses and is
platform independent. OpenERP is free to use and share. OpenERP featuring HR,
Manufacturing, CRM, Accounting, Sales, Warehouse Management and more. It is based
38
on a modular, intuitive and scalable Rapid Application Development (RAD) framework
which is written in Python.
4.1.1 Proposed Work
The task is to make the data online available, which we receive from OBDII scan tool.
For this we choose OpenERP system. As it is an open source, so it is easily customized
and make data online available in OpenERP system. For receiving data in OpenERP, we
have to develop a module in it. OpenERP has built-in APIs, by using which we can easily
develop a module in minimum time. Module contains different directories, folders and
files (.py, .xml etc.) which contain codes for module view, interface, database connection
and entry of data to database.
The basic module structure is shown in Figure 4.2.
To install OpenERP v7, requires
Windows7 or
Ubuntu 12.04
Figure 4. 1: OpenERP (old name) Odoo (new name) Labels
Figure 4. 2: Module in OpenERP/ Odoo
39
After installation of OpenERP, OpenERP can be accessed at address:
http://localhost:8069 or http://127.0.0.1:8069
Which are basically the same thing, means 127.0.0.1 and localhost.com are the same thing
and after “:” there is port number. Port number is to access odoo or OpenERP. In windows
its services starts either automatically or manually with double click on OpenERP icon,
but in case of linux and Ubuntu it is a bit difficult or different. In order to run the
OPENERP services in Ubuntu, the following commands are used;
$sudo service openep-server start
$sudo service openep-server stop
After installing the OpenERP on your system, point the web browser at
“http://IP_or_domain.com:8069”, the following screen will appear on monitor:
Figure 4. 3: OpenERP Login
Details of installation process of OpenERP system is given in Appendix B.
40
4.2 Developing Module in OpenERP
Each module in OpenERP is contained in its own directory either within the
server/bin/add-ons directory or another directory of add-ons, configured in server
installation. To create a new module, the following steps are necessary.
Creation of subfolder in the add-ons directory.
Creation of the module import file, named_init_.py
Creation of the module minefield file, named_openerp_.py
Creation of Python files containing objects, named abd.py
Creation of .xml files holding module data such as views, demo data or menu entries.
And optionally create report or workflows.
Name Contain the name of the module.
Version Version of the module.
Description The module description.
Category Category of the module.
Author Author of the module.
Website URL of the website of module.
License The license of the module (default license AGPL-3).
Depends List of modules on which this module depends, beside base.
Data List of .xml files to load when the module is installed/ updated.
Demo List of additional .xml files to load when the module is
installed.
Table 4. 1: List of Fields
4.3 Installing a Module
As the module has been developed, now we have to install it in OpenERP. To install
a module in OpenERP we have to create a database.
Creating database
41
To create a database in it, go to manage database (an option on login page of OpenERP),
the following screen appears.
Figure 4. 4: Database management screen
Master password is admin
Give name to database
And set password
Now the database is created. When the database is initialized the following main setup
screen appears.
Figure 4. 5: Main Setup screen
Installing module through the following steps:
Go to setting
42
user
switch user to admin
check the technical features in access rights
save
We obtain some additional options. Now go to update module list, then installed modules,
remove the installed option from search bar and write name of module to search. The
module become visible and can be installed.
4.4 Data Logging and Uploading Using Torque
Torque is an engine diagnostics application that facilitates user to monitor engine control unit
and extract various information from the sensors connected to ECU .It use phone's internal
GPS and accelerometer sensors to graph information. Torque can be used to view any stored
fault codes on vehicles' ECU and after fixing the fault it can also clear the fault codes and
‘Check Engine Light’ on dashboard. Torque works on different versions of android.
Uploading Data to OpenERP:
The following steps are included in logging and uploading data from Torque to OpenERP:
1. Go to adapter status
2. Select setting and
3. Go to data logging and uploading
4. Check the option 'upload to web server'
5. Enter your URL where you have to upload the log file in 'Webserver URL'. In our case
URL is'http://localhost:8069'
The log file sent by Torque contains the necessary information about the vehicle. Now we
can access log file online by importing it in OpenERP.
43
Some screenshots are taken from Torque software which is basically an Android application
used for communication with OBDII scanning device. Screenshots from Torque are shown
below.
4.5 Importing Log File in OpenERP
Now to make the vehicle information available online, we have to import the log file
generated by TORQUE in OpenERP system. This functionality is available in OpenERP
system as shown in Figure 4.7. By using the “import” button we can import the log file in
created module in OpenERP system. After importing, the readings of the log file will be
saved in relative fields of table, shown in Figure 4.8.
Figure 4. 6: Torque Output
45
Chapter 5
Testing and Results
5.1 Testing OBDII Hardware
To work with OBDII prototype, it need to be tested first, to make sure that the hardware
circuitry, serial communication as well as the signaling protocol worked fine. To do so a
terminal software called Teraterm is used. After successful testing the hardware is then
apply on vehicle in real time which gives the correct measurement.
5.1.1 Testing With Teraterm Terminal
Before connecting the OBDII Circuit to the vehicle, the circuit should be checked first to
confirm the serial communication. The easy way to test the circuit is, by using
HyperTerminal and Teraterm software. To do this, connect the OBDII circuit with
Teraterm terminal through Bluetooth. But before to start with testing first set the setup of
Teraterm as shown in the following figures.
Figure 5. 1: Serial Port Setup
46
Figure 5. 2: Terminal Setup
After connecting TeraTerm interface with the OBDII via Bluetooth. Test every protocol
in sequence avoiding vehicle connection. Use the SP command to select a protocol and
send ‘0100’ command. If all goes well and you see only these text ‘NO DATA’ or
‘UNABLE TO CONNECT’ then all goes right and the hardware work correctly. In case
others text appears during testing instead of the above then there will be faults in hardware
circuit. After successful testing connect the hardware to a real vehicle. The followings are
output results during testing.
>ATZ Command for checking the family of micro-controller and its version
STN1110 v1.30
>AT@1 Command for checking the designer of micro-controller
SCANTOOL.NET LLC
>0100 Command for searching protocols
SEARCHING...
UNABLE TO CONNECT
>ATE1 Command for checking status of the micro-controller
OK
>ATRV
9.1V Command for checking the voltage of the circuit
5.1.2 Real Time Testing
Torque is a vehicle / car performance / diagnostics tool and scanner that uses an OBD II
Bluetooth adapter to connect to OBD2 engine control unit (ECU). It can use the GPS to
provide tracker logs with OBD engine logging so you can see what you were doing at
47
any point in real time. It can also show and reset a DTC fault codes and show you exact
location of faults.
To start with OBDII and Torque, First connect the OBDII with vehicle on one side and
with Torque on other side. Successful connection of torque with OBDII shown in the
following Figure 4.
After establishing the connection of torque with communication device, the information
is then retrieving from the vehicle ECU. The adaptor status information also shows the
vehicle OBD standard, OBD protocol used by vehicle, calibration id and available sensor
etc. The OBDII port is capable of reading the following information from a vehicle:
a) Turbo Boost Pressure (PSI)
b) Fuel Economy (Real-Time/AVG/Trip)
c) Timing Position
d) Speed (MPH, KPH)
e) Engine RPM
f) Coolant Temperature
g) Throttle Position (in percent)
h) Injection Pulse width (IPW)
i) Air Intake Temperature
j) Mass Air Flow (g/sec)
Figure 5. 3: Successful connection of Torque
48
k) Throttle Position
l) Barometer
m) Battery Voltage
n) Engine Oil Temperature
o) Injection Control Pressure (ICP)
p) Transmission temperature
q) Load
49
The vehicle used for testing and performance analysis was TOYOTA Corolla XLI 2014.
Figures 5 to 8 show the available sensors and other parameters that stores for data logging
in vehicle.
Figure 5. 5: PIDs
Figure 5. 4: Connection Established
50
The above parameters show the real time data form engine ECU. This data is exactly the
same as the vehicle standard data.
Figure 1: Adapter Status information Main Menu Figure 5. 7: Dashboard
Figure 5. 6: Available Sensors and PIDs for Logging
51
Now to store the parameters and real time data in a log file such as .csv file for further
analysis, select the appropriate parameters and data from PID's manager as shown below
figure 9.
Figure 5. 8: PIDs to Log files
5.1.3 Log File Data and Its Output
The following file format is a .csv file which was collected during testing various
parameters. The Torque collect data through OBDII form ECU and store it as .csv file
on regular intervals. To analysis the data, one can draw any sort of graph based on their
needs and requirement.
Figure 5. 9: Log file containing different parameters information
52
The following different graphs are drawn with various parameter such voltage, RPM, Air
fuel Ratio. Etc. taken from the above data. These graphs are drawn by using Torque log
analyser. Torque log analyser is a tool for checking the driver style and highlighting
behaviour that can waste fuel and other stuff of vehicle.
54
As seen from the above results, one can easily analysis vehicle heath and driver behavior
of driving. This process can minimize cost, time and improve performance of vehicle. In
short one can see every status of his vehicle. It can be implemented in any department of
industry, educational institutes, telecommunication industries etc.
55
Chapter 6
Application and Conclusion
6.1 Applications:
Potential Application of our proposed and developed work is: one can remotely monitor
vehicle health, check faults, emission detection problems, avoid the higher fuel
consumptions etc. Using this parameters individual or industries or groups can optimize
the expense of vehicles and faults can be predicted and notify the managers in time.
6.1.1 User Applications
Individual and Industrial Users can benefit from it in many ways. E.g. he can locate their
vehicle, monitor the vehicle performance and detect faults in any part of vehicle. To detect
the fault on time one can drive safely and prevent accidents. User can benefit from it by
checking his vehicle itself, thus reduce operation and mechanical costs.
6.1.2 Enterprise applications
Some Enterprise application may include Fleet tracking, monitoring fuel efficiency.
Through this device Enterprise can know the driving behavior of their drivers. Also they
can remotely diagnostic their vehicles in areas where vehicle repair service is not
available.
6.2 Conclusion
This project gives us the information about the technology used in vehicles for extracting
data through ECU from vehicle sensors. The extracted data is subsequently used for
vehicle management, monitoring and health performance optimization. It’s an exciting
area in the field of automotive engineering. This can enhance existing telemetry system.
56
It will be helpful in developing a commercial grade machinery performance optimization
system.
6.3 Recommendation
The remote examination of OBD information has been considered OBDIII or OBD X.
This concept implicates that using wireless techniques in the OBDII scan tool which is
directly connected to the ECU of vehicle should be equipped permanently. The real-time
information gets from ECU through OBDII scan tool is directly send to the database of
ERP System, where the data is automatically analyzed and diagnosed. This can handle a
large fleet of vehicles. Such system would be simple and convenient for both users and
enterprise fleet solution.
57
Appendix A
List of Standard PIDs and Mode of Communication
Mode 1 and 2
PID N⁰ Description
0 00 Determine PIDs supported (range 01h to 20h )
1 01 Trouble codes and on board test information
2 02 Freeze frame trouble code
3 03 Fuel system status
4 04 Calculated load value
5 05 Coolant temperature
6 06 Short term fuel % trim Bank 1
7 07 Long term fuel % trim Bank 1
8 08 Short term fuel % trim Bank 2
9 09 Long term fuel % trim Bank 2
10 0A Fuel pressure
11 0B Intake Mani fold Pressure
12 0C Engine RPM
13 0D Vehicle speed
14 0E Timing advance
15 0F Intake air temperature
16 10 air flow
17 11 Absolute Throttle sensor position
18 12 Secondary air status
19 13 Oxygen sensor locations bank/sensor
20 14 Oxy. sensor voltage bank1 sensor1
58
21 15 Oxy. sensor voltage bank1 sensor2
22 16 Oxy. sensor voltage bank1 sensor3
23 17 Oxy. sensor voltage bank1 sensor4
24 18 Oxy. sensor voltage bank2 sensor1
25 19 Oxy. sensor voltage bank2 sensor2
26 1A Oxy. sensor voltage bank2 sensor3
27 1B Oxy. sensor voltage bank2 sensor4
28 1C Design OBD requirements
29 1D Al ternate Oxy sensor locations
30 1E Auxiliary input status
31 1F Time since engine start
32 20 Determine PIDs supported (range 21h to 40h )
33 21 Distance traveled while MIL is activated
34 22 Fuel rail pressure relative manifold
35 23 Fuel rail pressure
36 24 Bank 1 - sensor 1 (wide range O2S)
37 25 Bank 1 - sensor 2 (wide range O2S)
38 26 Bank 1 - sensor 3 (wide range O2S)
39 27 Bank 1 - sensor 4 (wide range O2S)
40 28 Bank 2 - sensor 1 (wide range O2S)
41 29 Bank 2 - sensor 2 (wide range O2S)
42 2A Bank 2 - sensor 3 (wide range O2S)
43 2B Bank 2 - sensor 4 (wide range O2S)
44 2C Commanded EGR
45 2D EGR error
59
46 2E Commanded evaporative purge
47 2F Fuel level input
48 30 Number of warn-ups since DTCs cleared
49 31 Distance traveled since DTCs cleared
50 32 Evap system vapor pressure
51 33 Barometric pressure
52 34 Bank 1 - sensor 1 (wide range O2S)
53 35 Bank 1 - sensor 2 (wide range O2S)
54 36 Bank 1 - sensor 3 (wide range O2S)
55 37 Bank 1 - sensor 4 (wide range O2S)
56 38 Bank 2 - sensor 1 (wide range O2S)
57 39 Bank 2 - sensor 2 (wide range O2S)
58 3A Bank 2 - sensor 3 (wide range O2S)
59 3B Bank 2 - sensor 4 (wide range O2S)
60 3C Catalyst Temperature bank 1, sensor 1
61 3D Catalyst Temperature bank 2, sensor 1
62 3E Catalyst Temperature bank 1, sensor 2
63 3F Catalyst Temperature bank 2, sensor 2
64 40 Determine PIDs supported (range 41h to 60h )
65 41 Monitor status this driving cycle
66 42 Control module voltage
67 43 Absolute load value
68 44 Fuel /air commanded equivalence ratio
69 45 Relative throttle position
70 46 Ambient air temperature
60
71 47 Absolute throttle position B
72 48 Absolute throttle position C
73 49 Accelerator pedal position D
74 4A Accelerator pedal position E
75 4B Accelerator pedal position F
76 4C Commanded throttle actuator control
77 4D Engine run time while MIL is activated
78 4E Engine run time since DTCs cleared
79 4F External test equipment configuration information #1
80 50 External test equipment configuration information #2
81 51 Type of fuel currently being utilized by the vehicle
82 52 Alcohol fuel percentage
83 53 Absolute evap system vapor pressure
84 54 Evap system vapor pressure
85 55 Short term secondary O2 sensor fuel trim - bank 1 and 3
86 56 Long term secondary O2 sensor fuel trim - bank 1 and 3
87 57 Short term secondary O2 sensor fuel trim - bank 2 and 4
88 58 Long term secondary O2 sensor fuel trim - bank 2 and 4
89 59 Fuel rail pressure (absolute)
90 5A Relative accelerator pedal position
91 5B Hybrid battery pack remaining l ife
92 5C Engine oil temperature
93 5D Fuel injection timing
94 5E Engine fuel rate
95 5F Emission requirements to which vehicle is designed
61
96 60 Determine PIDs supported (range 61h to 80h )
97 61 Driver's demand engine - percent torque
98 62 Actual engine - percent torque
99 63 Engine reference torque
100 64 Engine percent torque data
101 65 Auxiliary inputs / outputs
102 66 Mass air flow sensor
103 67 Engine coolant temperature
104 68 Intake air temperature sensor
105 69 Commanded EGR and EGR error
106 6A Commanded diesel intake air flow control and relative intake air flow
position
107 6B Exhaust gas recirculation temperature
108 6C Commanded throttle actuator control and relative throttle position
109 6D Fuel pressure control system
110 6E Injection pressure control system
111 6F Turbocharger compressor inlet pressure
112 70 Boost pressure control
113 71 Variable geometry turbo (VGT) control
114 72 Waste gate control
115 73 Exhaust pressure
116 74 Turbocharger RPM
117 75 Turbocharger A temperature
118 76 Turbocharger B temperature
119 77 Charge air cooler temperature (CACT)
120 78 Exhaust gas temperature (EGT) bank 1
62
121 79 Exhaust gas temperature (EGT) bank 2
122 7A Diesel particulate filter (DPF) bank 1
123 7B Diesel particulate filter (DPF) bank 2
124 7C Diesel particulate filter (DPF) temperature
125 7D NOx NTE control area status
126 7E PM NTE control area status
127 7F Engine run time
128 80 Determine PIDs supported (range 81h to A0h )
129 81 Engine run time for AECD #1 - #5
130 82 Engine run time for AECD #6 - #10
131 83 Nox sensor
132 84 Mani fold surface temperature
133 85 Nox control system
134 86 Particulate matter (PM) sensor
135 87 Intake manifold absolute pressure
136 88 ISO/SAE reserved
137 89 Determine PIDs supported (range A1h to C0h )
138 8A Determine PIDs supported (range C1h to E0h )
139 8B Determine PIDs supported (range E1h to FFh )
Mode 5
PID N⁰ Description
0 00 Determine PIDs supported (range 01h to 20h )
1 01 Rich to lean sensor threshold voltage
2 02 Lean to rich sensor threshold voltage
63
3 03 Low sensor voltage for switch time calculation
4 04 High sensor voltage for switch time calculation
5 05 Rich to lean sensor switch time
6 06 Lean to rich sensor switch time
7 07 Minimum sensor voltage for test cycle
8 08 Maximum sensor voltage for test cycle
9 09 Time between sensor transitions
10 0A Sensor period
11 0B ISO/SAE reserved
Mode 6
PID N⁰ Description
0 00 Determine PIDs supported (range 01h to 20h )
1 01 Exhaust Gas Sensor Monitor Bank 1 Sensor 1
2 02 Exhaust Gas Sensor Monitor Bank 1 Sensor 2
3 03 Exhaust Gas Sensor Monitor Bank 1 Sensor 3
4 04 Exhaust Gas Sensor Monitor Bank 1 Sensor 4
5 05 Exhaust Gas Sensor Monitor Bank 2 Sensor 1
6 06 Exhaust Gas Sensor Monitor Bank 2 Sensor 2
7 07 Exhaust Gas Sensor Monitor Bank 2 Sensor 3
8 08 Exhaust Gas Sensor Monitor Bank 2 Sensor 4
9 09 Exhaust Gas Sensor Monitor Bank 3 Sensor 1
10 0A Exhaust Gas Sensor Monitor Bank 3 Sensor 2
11 0B Exhaust Gas Sensor Monitor Bank 3 Sensor 3
12 0C Exhaust Gas Sensor Monitor Bank 3 Sensor 4
13 0D Exhaust Gas Sensor Monitor Bank 4 Sensor 1
64
14 0E Exhaust Gas Sensor Monitor Bank 4 Sensor 2
15 0F Exhaust Gas Sensor Monitor Bank 4 Sensor 3
16 10 Exhaust Gas Sensor Monitor Bank 4 Sensor 4
17 11 Determine PIDs supported (range 21h to 40h )
18 12 Catalyst Monitor Bank 1
19 13 Catalyst Monitor Bank 2
20 14 Catalyst Monitor Bank 3
21 15 Catalyst Monitor Bank 4
22 16 EGR Monitor Bank 1
23 17 EGR Monitor Bank 2
24 18 EGR Monitor Bank 3
25 19 EGR Monitor Bank 4
26 1A VVT Monitor Bank 1
27 1B VVT Monitor Bank 2
28 1C VVT Monitor Bank 3
29 1D VVT Monitor Bank 4
30 1E EVAP Monitor (Cap Off / 0.150)
31 1F EVAP Monitor (0.090)
32 20 EVAP Monitor (0.040)
33 21 EVAP Monitor (0.020)
34 22 Purge Flow Monitor
35 23 Determine PIDs supported (range 41h to 60h )
36 24 Exhaust Gas Sensor Heater Monitor Bank 1 Sensor 1
37 25 Exhaust Gas Sensor Heater Monitor Bank 1 Sensor 2
38 26 Exhaust Gas Sensor Heater Monitor Bank 1 Sensor 3
65
39 27 Exhaust Gas Sensor Heater Monitor Bank 1 Sensor 4
40 28 Exhaust Gas Sensor Heater Monitor Bank 2 Sensor 1
41 29 Exhaust Gas Sensor Heater Monitor Bank 2 Sensor 2
42 2A Exhaust Gas Sensor Heater Monitor Bank 2 Sensor 3
43 2B Exhaust Gas Sensor Heater Monitor Bank 2 Sensor 4
44 2C Exhaust Gas Sensor Heater Monitor Bank 3 Sensor 1
45 2D Exhaust Gas Sensor Heater Monitor Bank 3 Sensor 2
46 2E Exhaust Gas Sensor Heater Monitor Bank 3 Sensor 3
47 2F Exhaust Gas Sensor Heater Monitor Bank 3 Sensor 4
48 30 Exhaust Gas Sensor Heater Monitor Bank 4 Sensor 1
49 31 Exhaust Gas Sensor Heater Monitor Bank 4 Sensor 2
50 32 Exhaust Gas Sensor Heater Monitor Bank 4 Sensor 3
51 33 Exhaust Gas Sensor Heater Monitor Bank 4 Sensor 4
52 34 Determine PIDs supported (range 61h to 80h )
53 35 Heated Catalyst Monitor Bank 1
54 36 Heated Catalyst Monitor Bank 2
55 37 Heated Catalyst Monitor Bank 3
56 38 Heated Catalyst Monitor Bank 4
57 39 Secondary Ai r Monitor 1
58 3A Secondary Ai r Monitor 2
59 3B Secondary Ai r Monitor 3
60 3C Secondary Ai r Monitor 4
61 3D Determine PIDs supported (range 81h to A0h )
62 3E Fuel System Monitor Bank 1
63 3F Fuel System Monitor Bank 2
66
64 40 Fuel System Monitor Bank 3
65 41 Fuel System Monitor Bank 4
66 42 Boost Pressure Control Monitor Bank 1
67 43 Boost Pressure Control Monitor Bank 2
68 44 NOxAdsorber Monitor Bank 1
69 45 NOxAdsorber Monitor Bank 2
70 46 NOx Catalyst Monitor Bank 1
71 47 NOx Catalyst Monitor Bank 2
72 48 Determine PIDs supported (range A1h to C0h )
73 49 Misfire Monitor General Data
74 4A Misfire Cylinder 1 Data
75 4B Misfire Cylinder 2 Data
76 4C Misfire Cylinder 3 Data
77 4D Misfire Cylinder 4 Data
78 4E Misfire Cylinder 5 Data
79 4F Misfire Cylinder 6 Data
80 50 Misfire Cylinder 7 Data
81 51 Misfire Cylinder 8 Data
82 52 Misfire Cylinder 9 Data
83 53 Misfire Cylinder 10 Data
84 54 Misfire Cylinder 11 Data
85 55 Misfire Cylinder 12 Data
86 56 Misfire Cylinder 13 Data
87 57 Misfire Cylinder 14 Data
88 58 Misfire Cylinder 15 Data
67
89 59 Misfire Cylinder 16 Data
90 5A PM Filter Monitor Bank 1
91 5B PM Filter Monitor Bank 2
92 5C Determine PIDs supported (range C1h to E0h )
93 5D Determine PIDs supported (range E1h to FFh )
94 5E Manufacturer specific
Mode 9
PID N⁰ Description
0 00 Determine PIDs supported (range 01h to 20h )
1 01 MessageCount VIN
2 02 Vehicle Identification Number
3 03 MessageCount CALID
4 04 Calibration Identifications
5 05 MessageCount CVN
6 06 Calibration Verification Numbers
7 07 MessageCount IPT
8 08 In-use Performance Tracking
9 09 MessageCount ECU name
10 0A ECU name
11 0B In-use Performance Tracking
12-255 0C-FF ISO/SAE reserved
68
Appendix B
Steps for Installing OpenERP in Ubuntu
Following steps are required for installing OpenERP in Ubuntu:
Step 1:
Make sure your server has all the latest versions by doing an update:
sudo apt-get update
sudo apt-get dist-upgrade
Step 2:
Create the OpenERP user that will own and run the application /opt/openerp directory is
created automatically by the following command and here the OpenERP server code will
reside.
sudoadduser --system --home=/opt/openerp --group openerp
To go in openERP’s home directory: /opt/openerp, use command:
sudosu - openerp -s /bin/bash
You can leave the openerpuser areas shell by typing "exit".
Step 3:
Install and configure the database server, PostgreSQL
sudo apt-get install postgresql
Then configure the OpenERP user on PostgreSQL:
69
To have the necessary privileges to configure the database, change to the postgres user by
using the command:
sudosu - postgres
Now create a new database user so that OpenERP has access rights to connect to
PostgreSQL and to create and drop databases.
createuser --createdb --username postgres --no-
createrole --no-superuser --pwpromptopenerp
Enter password for new role: ********
Enter it again: ********
Then exit from postgres user account by using "exit" command.
Step 4:
Install the necessary Python libraries for the server
sudo apt-get install python-dateutil python-docutils python-
feedparser python-gdata \
python-jinja2 python-ldap python-libxslt1 python-lxml
python-mako python-mock python-openid \
python-psycopg2 python-psutil python-pybabel python-pychart
python-pydot python-pyparsing \
python-reportlab python-simplejson python-tz python-
unittest2 python-vatnumber python-vobject \
python-webdav python-werkzeug python-xlwt python-yaml
python-zsi
By doing this, all the dependencies for installing OpenERP 7.0 will be satisfied.
70
Step 5:
Install the OpenERP server
Get the latest version of OpenERP in your home directory using following command.
wget
http://nightly.openerp.com/7.0/nightly/src/openerp-7.0-
latest.tar.gz
To extract the tarball in the /opt/openerp/. cd to the /opt/openerp/
cd /opt/openerp/
sudo tar xvf ~/openerp-7.0-latest.tar.gz
Now change the ownership of all the files to the OpenERP user and group by using
command:
sudochown -R openerp: *
sudocp -a openerp-7.0 server
Step 6:
Configuring the OpenERP application
The following commands make the file owned and writeable only by the openerp user and
group and only readable by openerp and root.
sudocp /opt/openerp/server/install/openerp-server.conf
/etc/
sudochownopenerp: /etc/openerp-server.conf
sudochmod 640 /etc/openerp-server.conf
71
Change line db_password = False to the same password you used back in step 3 by using
the command:
sudonano /etc/openerp-server.conf
logfile = /var/log/openerp/openerp-server.log
Now we can start the server just to check if it actually runs.
sudosu - openerp -s /bin/bash
/opt/openerp/server/openerp-server
If you end up with a few lines eventually saying OpenERP is running and waiting for
connections then you are all set. Enter CTL+C to stop the server and then exit to leave the
openerp user account and go back to your own shell. To make it executable and owned by
root use commands:
sudochmod 755 /etc/init.d/openerp-server
sudochown root: /etc/init.d/openerp-server
Step 7:
Now we need to create a directory so that the server has somewhere to log and we must
make it writeable by the openerp user:
sudomkdir /var/log/openerp
sudochownopenerp:root /var/log/openerp
Step 8:
Testing the server. To start the OpenERP server type:
sudo /etc/init.d/openerp-server start
To stop the OpenERP server type:
72
sudo /etc/init.d/openerp-server stop
If there are any problems you need to go back and check. There’s really no point ploughing
on if the server doesn’t start. If the log file looks Fine, now point the web browser at the
domain or IP address of your OpenERP server (or local host if on the same machine) and
use port 8069. The url will look something like this:
http://IP_or_domain.com:8069
For the fleet information module the _openerp_.py declaration file is
Figure Appendix B. 1: OpenERP.py
Python file
It contains the class which inherits OSV class by importing OSV model and fields
from OSV file. The class contains:
_name: contains name of the table.
_column: contains fields of table and
_defaults: give default value.
The fleetopt_engine() calls the parent class osv.osv’s constructor. For fleet
information module, the _fleet_info.py declaration file is shown below.
73
Figure Appendix B. 2: The Fleet info file
XML Files
XML files are used to initialize / update the database when the module is installed/
updated. They are used for many purposes. Data can be inserted/ updated into the
PostgreSQl table using XML files. The general structure of an OpenERP XML file
is shown below.
Views
74
Views are a way to represent objects on the client side. They indicate the client how
to layout the data on the screen coming from the objects.
There are three types of views.
Form view
Tree view
Search view
Form view:
It is used when the user wants to edit or add the information. By default each field is
preceded by a label, with its name. The following code displays the form view of module.
Tree View
Tree view is aslo called list view. We can specify columns which we want to add in
the list.
75
If no view has been defined for an object, the object is able to generate a view to
represent itself. This can limit the developers work. The following code displays the
tree view of modul.
Search View
Search view used in module to provide the search panels in form. Using it user can
search the data from those fields which are specified in search view. It creates a
customized search panel and is quite similarly to a form view, except that the root
element and view type change to search instead of form. The following code displays
the tree view of module.
Action
The action defines the behavior of system in response to the action of the users. Action
portion of XML file shows an action/ behavior of module. It shows the priority of the
views. The following code displays the action of module.
76
Menu
In OpenERP, this element represents a menu structure. We can trigger an action created
above by clicking on the menu. The following code displays the menu of module.
77
Appendix C
Testing with TeraTerm Terminal
TIMESTAMP DIRECTION DATA
2014-06-19 12:22:54 >> ATZ
2014-06-19 12:22:54 << ??
2014-06-19 12:22:54 << ELM327 v1.5
2014-06-19 12:22:55 >> ATI
2014-06-19 12:22:55 << ATIELM327 v1.5
2014-06-19 12:22:55 >> AT@1
2014-06-19 12:22:55 << AT@1OBDII to RS232 Interpreter
2014-06-19 12:22:55 >> AT@2
2014-06-19 12:22:55 << AT@2?
2014-06-19 12:22:56 >> ATE0
2014-06-19 12:22:56 << ATE0OK
2014-06-19 12:22:56 >> ATL0
2014-06-19 12:22:56 << OK
2014-06-19 12:22:56 >> ATS0
2014-06-19 12:22:56 << OK
2014-06-19 12:22:56 >> ATTP0
2014-06-19 12:22:56 << OK
2014-06-19 12:22:57 >> 0100
2014-06-19 12:22:57 << SEARCHING...4100BE1FB013
2014-06-19 12:22:57 >> ATDPN
2014-06-19 12:22:57 << A6
2014-06-19 12:22:57 >> ATDP
2014-06-19 12:22:57 << AUTO, ISO 15765-4 (CAN 11/500)
2014-06-19 12:22:57 >> ATH1
2014-06-19 12:22:57 << OK
2014-06-19 12:22:58 >> 0100
2014-06-19 12:22:58 << 7E8064100BE1FB013
2014-06-19 12:22:58 >> 0100
2014-06-19 12:22:58 << 7E8064100BE1FB013
78
2014-06-19 12:22:58 >> 0120
2014-06-19 12:22:58 << 7E80641208005A001
2014-06-19 12:22:58 >> 0140
2014-06-19 12:22:58 << 7E80641407ADC0000
2014-06-19 12:22:58 >> 0101
2014-06-19 12:22:59 << 7E806410100074000
2014-06-19 12:22:59 >> 020000
2014-06-19 12:22:59 << 7E8074200007E1F9003
2014-06-19 12:22:59 >> 022000
2014-06-19 12:22:59 << 7E8074220000005A001
2014-06-19 12:22:59 >> 024000
2014-06-19 12:22:59 << 7E8074240007AD40000
2014-06-19 12:22:59 >> 0600
2014-06-19 12:22:59 << 7E806460080000001
2014-06-19 12:22:59 >> 0620
2014-06-19 12:22:59 << 7E806462000000001
2014-06-19 12:22:59 >> 0640
2014-06-19 12:22:59 << 7E806464080000000
2014-06-19 12:22:59 >> 0900
2014-06-19 12:22:59 << 7E80649003C000000
2014-06-19 12:22:59 >> 011C
2014-06-19 12:22:59 << 7E803411C06
2014-06-19 12:22:59 >> 0113
2014-06-19 12:22:59 << 7E803411301
2014-06-19 12:23:00 >> 03
2014-06-19 12:23:00 << 7E8024300
2014-06-19 12:23:00 >> 07
2014-06-19 12:23:00 << 7E8024700
2014-06-19 12:23:00 >> 0101
2014-06-19 12:23:00 << 7E806410100074000
2014-06-19 12:23:00 >> 020200
2014-06-19 12:23:00 << 7E8054202000000
2014-06-19 12:23:37 >> 03
2014-06-19 12:23:37 << 7E8024300
2014-06-19 12:23:38 >> 07
79
2014-06-19 12:23:39 << 7E8024700
2014-06-19 12:23:39 >> 0A
2014-06-19 12:23:39 << 7E8037F0A11
2014-06-19 12:23:40 >> 020200
2014-06-19 12:23:40 << 7E8054202000000
2014-06-19 12:23:40 >> 020300
2014-06-19 12:23:40 << NO DATA
2014-06-19 12:23:40 >> 020400
2014-06-19 12:23:40 << NO DATA
2014-06-19 12:23:40 >> 020500
2014-06-19 12:23:40 << NO DATA
2014-06-19 12:23:40 >> 020600
2014-06-19 12:23:41 << NO DATA
2014-06-19 12:23:41 >> 020700
2014-06-19 12:23:41 << NO DATA
2014-06-19 12:23:41 >> 020C00
2014-06-19 12:23:41 << NO DATA
2014-06-19 12:23:41 >> 020D00
2014-06-19 12:23:41 << NO DATA
2014-06-19 12:23:41 >> 020E00
2014-06-19 12:23:41 << NO DATA
2014-06-19 12:23:42 >> 020F00
2014-06-19 12:23:42 << NO DATA
2014-06-19 12:23:42 >> 021000
2014-06-19 12:23:42 << NO DATA
2014-06-19 12:23:42 >> 021100
2014-06-19 12:23:42 << NO DATA
2014-06-19 12:23:42 >> 021400
2014-06-19 12:23:42 << NO DATA
2014-06-19 12:23:42 >> 021F00
2014-06-19 12:23:43 << NO DATA
2014-06-19 12:23:43 >> 022E00
2014-06-19 12:23:43 << NO DATA
2014-06-19 12:23:43 >> 023000
2014-06-19 12:23:43 << NO DATA
80
2014-06-19 12:23:43 >> 023100
2014-06-19 12:23:43 << NO DATA
2014-06-19 12:23:43 >> 023300
2014-06-19 12:23:44 << NO DATA
2014-06-19 12:23:44 >> 024200
2014-06-19 12:23:44 << NO DATA
2014-06-19 12:23:44 >> 024300
2014-06-19 12:23:44 << NO DATA
2014-06-19 12:23:44 >> 024400
2014-06-19 12:23:44 << NO DATA
2014-06-19 12:23:44 >> 024500
2014-06-19 12:23:44 << NO DATA
2014-06-19 12:23:44 >> 024700
2014-06-19 12:23:45 << NO DATA
2014-06-19 12:23:45 >> 024900
2014-06-19 12:23:45 << NO DATA
2014-06-19 12:23:45 >> 024A00
2014-06-19 12:23:45 << NO DATA
2014-06-19 12:23:45 >> 024C00
2014-06-19 12:23:45 << NO DATA
2014-06-19 12:23:45 >> 024E00
2014-06-19 12:23:46 << NO DATA
2014-06-19 12:24:06 >> 0101
2014-06-19 12:24:06 << 7E806410100074000
2014-06-19 12:24:06 >> 0601
2014-06-19 12:24:06 << 7E810404601030B00007E8210000000001040
B7E822000000000000017E823051000000000007E824000106100000007E82500000001070B007E826000000
000001087E8270B0000000000007E828018110000000007E82900000000000000
2014-06-19 12:24:06 >> 0641
2014-06-19 12:24:06 << 7E8100A4641900E02237E82100FAFFFF000000
2014-06-19 12:24:10 >> 0101
2014-06-19 12:24:10 << 7E806410100074000
2014-06-19 12:24:10 >> 0601
81
2014-06-19 12:24:10 << 7E810404601030B00007E8210000000001040
B7E822000000000000017E823051000000000007E824000106100000007E82500000001070B007E826000000
000001087E8270B0000000000007E828018110000000007E82900000000000000
2014-06-19 12:24:10 >> 0641
2014-06-19 12:24:10 << 7E8100A4641900E02237E82100FAFFFF000000
2014-06-19 12:24:34 >> 0904
2014-06-19 12:24:34 << 7E810134904013330327E821413630303000007E82200000000000000
2014-06-19 12:24:34 >> 0906
2014-06-19 12:24:34 << 7E807490601BC668E41
2014-06-19 12:25:21 >> 0904
2014-06-19 12:25:21 << 7E810134904013330327E821413630303000007E82200000000000000
82
Appendix D
OBDII
In the 1970’s and later in 1980’s manufacturers’ underway of using electronic means to
control engine functionality and detect engine problems. It was the primarily aim to meet
EPA emission standards. Over the years OBDII system has become more developed.
OBDII a new standard was presented in 1990 which provide almost all engine control and
also monitors parts of the chassis, body and accessory devices, as well as the diagnostic
control network of the vehicle.
For avoiding smog problems in the LA Basin, the California state started demanding an
emission control systems on 66’s model cars. Smog problem in the LA basin, the State of
California started demand in emission control systems on 1966 model cars. Afterwards
the federal government in 1968 extended these controls countrywide. Congress approved
the Clean Air Act in 1970 and established the Environmental Protection Agency (EPA).
Thus a sequence of graduated emission standards and requirements for optimization and
maintenance of vehicles health had started for extended period of time. To come upon
these standards, manufactures turned into electronically controlled fuel feed and ignition
systems. Different sensors available in the vehicle measured engine performance and
adjusted the systems to provide minimum pollution.
In the beginning each manufacturer had their own framework for extracting data. In 1988,
the Society of Automotive Engineers (SAE) set a standard connector plug and set of
diagnostic test signals. The standard connector plug consists of sixteen pin and in which
five are data pins. OBDII is an extended set of standards and practices developed by SAE
and adopted by the EPA and California Air Resources Board (CARB) for implementation
by 1 January 1996.
83
OBDII Standard Connector and Protocols OBDII was initially presented in the United State in 1994, and in 1996 it became requisite
in the newer US vehicles. Similar legislation is also adopted by other countries like
Canada, Japan, European Union, Australia and Brazil. We can access the vehicle ECU
through the sixteen pin standard connector called data link controller (DLC). A sixteen
pin male (J1962) connector plug is connected to female connector equipped in the Vehicle
under the steering or dashboard. Every pin has assigned its own specific signalling
protocol. Its distinctive pin contact fusions figure out which convention is being used at
the current time as each one assembling organization uses its particular protocol. The sorts
of information you recover will rely on upon the output interface you're utilizing.
The pins layout and description is given below.
Pin Description Pin Description
1 Vendor Option 9 Vendor Option
2 J1850 Bus + 10 J1850 Bus -
3 Vendor Option 11 Vendor Option
4 Chassis Ground 12 Vendor Option
5 Signal Ground 13 Vendor Option
6 CAN High (J-2234) 14 CAN Low (J-2234)
7 ISO 9141-2 K-Line 15 ISO 9141-2 L-Line
8 Vendor Option 16 Battery Voltage
Table Appendix D. 1: DLC Pins Description
An OBD-II compliant automobile can use any one of the five basic communication
protocols. These are SAE J1850 VPM, SAE J1850 PWM, ISO 14230-4 (KWP2000), ISO
9141-2 and since 2003 also include ISO 15765-4/SAE J2480.
84
DETERMINING PROTOCOL FROM OBD-II PINOUT
When in doubt, we can detect which protocol our vehicle is using by gazing at the pin
layout of the OBDII connector. The following table 4 shows the communicating pins with
respect to specific protocol.
Standard Pin no 2 Pin no 6 Pin no 7 Pin no 10 Pin no
14
Pin no
15
J1850 PWM Must
have
----------- ----------- Must
have
----------- -------------
J1850 VPM Must
have
------------ ----------- ------------ ------------- ------------
ISO9141/14230 ------------- ------------ Must
have
------------ ------------- Optional
ISO15765(CAN) ------------ Must have ---------- ------------ Must have -----------
Table Appendix D. 2: Protocol specification
OBDII Signal Protocol Description
There are five protocols in use with the OBD-II interface, and often it is possible to make
an educated guess about the protocol in use based on which pins are present on the J1962
connector:
a. SAE J1850 PWM (41.6 kbaud, standard of the Ford Motor Company)
(1) pin 2: Bus-
(2) pin 10: Bus+
(3) High voltage is +5V
(4) Message length is restricted to 12 bytes, including CRC
(5) Employs a multi-master arbitration scheme called 'Carrier Sense
Multiple Access with Non-Destructive Arbitration' (CSMA/NDA)
85
b. SAE J1850 VPW (Variable Pulse Width) (10.4/41.6 kbaud, standard of
General Motors)
(1) pin 2: Bus+
(2) Bus idles low
(3) High voltage is +7V
(4) Decision point is +3.5V
(5) Message length is restricted to 12 bytes, including CRC
(6) Employs CSMA/NDA
c. ISO 9141-2. This protocol has a data rate of 10.4 kbaud, and is similar to RS-
232. ISO 9141-2 is primarily used in Chrysler, European, and Asian vehicles.
(1) pin 7: K-line
(2) pin 15: L-line (optional)
(3) UART signalling (though not RS-232 voltage levels)
(4) K-line idles high
(5) High voltage is Vbatt
(6) Message length is restricted to 12 bytes, including CRC
d. ISO 14230 KWP2000 (Keyword Protocol 2000)
(1) pin 7: K-line
(2) pin 15: L-line (optional)
(3) Physical layer identical to ISO 9141-2
(4) Data rate 1.2 to 10.4 kbaud
(5) Message may contain up to 255 bytes in the data field
e. ISO 15765 CAN (250kbit/sec or 500kbit/sec)
(1) pin 6: CAN High
(2) pin 14: CAN Low
86
Note: Pin 5 (Battery ground) and pin 16 (Battery positive) are present in all
configurations. As ISO 9141 and ISO 14230 use the same pin layout, thus we cannot
differentiate between the two by simply examining the DLC connector.
OBDII Diagnostic Data
When there is a troubleshooting problems inside a vehicle, the OBDII retrieve various
data from ECU and provide valuable source of information. The standard SAE J1979
describes a method for requesting numerous diagnostic data and a list of standard
parameter’s that might be available from ECU. The several parameters that are available
are called “parameter identification numbers” OR PIDs. These are explained in J1979.
See appendix A for basic PIDs and their definitions.
The EMC (engine control module), PMC (power control module) constantly monitoring
standard Parameter ID (PID) codes. If the EMC and PMC detect any potential problem
with engine, the warning light call MIL (malfunction indicator light) is lit up to alert the
driver about the problem. After 1996 every vehicle must be capable of sending and
receiving these codes over it OBDII connector.
We need combination of software (Desktop application OR android application) and
hardware (OBDII scan tool) to get these information from ECU. The hardware is acts as
a cable between the diagnostic connector and the device that runs software for reading
codes and data. OBDII provides way for reading codes and all kinds of information. E.g.
live data, test result and ECU information. It record and display any trouble code that the
vehicle is sending. Users can then use the code to see what’s wrong with the vehicle.
What is DTC
Diagnostic trouble codes also known as DTCs are alphanumeric codes that an
automobile's computer yields when it detects a failure. These codes are transferred by a
vehicle's on-board diagnostics (OBD) system and can be read using a diagnostic scanner
87
that plugs into the OBD connector. From the following diagram we can easily understand
the format and value of DTC.
Figure Appendix D. 1: DTC Specification
88
Bibliography
[1]. Jie, H., Fuwu, Y., Jing, T., Pan, W., & Kai, C. (2010, March). Developing PC-
Based Automobile Diagnostic System Based on OBD System. In Power and
Energy Engineering Conference (APPEEC), 2010 Asia-Pacific (pp. 1-5). IEEE.
[2]. Rosca, G., Daniel-Alexandru, A., Ilina-Elena, I., Cristina, L., Mihai, M., Paval, D.,
& Iftene, A. (2011, June). Remote Equipment Diagnosis using Bluetooth
Communication. In Roedunet International Conference (RoEduNet), 2011 10th (pp.
1-5). IEEE.
[3]. Zaldivar, J., Calafate, C. T., Cano, J. C., & Manzoni, P. (2011, October). Providing
accident detection in vehicular networks through OBD-II devices and Android-
based smartphones. In Local Computer Networks (LCN), 2011 IEEE 36th
Conference on (pp. 813-819). IEEE.
[4]. Tahat, A., Said, A., Jaouni, F., & Qadamani, W. (2012, June). Android-based
universal vehicle diagnostic and tracking system. In Consumer Electronics (ISCE),
2012 IEEE 16th International Symposium on (pp. 137-143). IEEE.
[5]. Siegel, J. E. (2011). Design, development, and validation of a remotely
reconfigurable vehicle telemetry system for consumer and government
applications (Doctoral dissertation, Massachusetts Institute of Technology).
[6]. Bertosa, Thomas, Michael Gessner, and Hamid Namaky. "Diagnostic tool with
advanced diagnostic capabilities." U.S. Patent No. 7,809,482. 5 Oct. 2010.
[7]. Dzhelekarski, P., &Alexiev, D. (2005). Initializing communication to vehicle obdii
system. ELECTRONICS, 5, 21.
[8]. Development of OBD-II driver information system, International Journal of
Engineering and Technology, Vol. 4, No. 2, 2007, pp. 253-259
[9]. M.A.S. Kamal, M. Mukai, J. Murata, T. Kawabe, “On board eco-driving system for
varying road-traffic environments using model predictive control,” 2010 IEEE
International Conference on Control Applications, 2010, pp. 1636-1641.
89
[10]. Noxon, Jeff. “Opendiag OBD-II Schematics & PCB Layout.” Planetfall. N.p., 13
Jan. 2009. Web. 21 Feb. 2011. http://www.planetfall.com/cms/content/ opendiag-
obd-ii-schematics-pcb-layout
[11]. OBD-II Background.” The OBD II Home Page. N.p., 2011. Web. 23 Feb. 2011.
<http://www.obdii.com/background.html>.
[12]. OBD2 Diagnostic Operational Modes.” CanOBD2. Innova, 2011. Web. 18 Feb.
2011.
[13]. OBD FAQ: OBD-II Communication Protocols.” OBD-Codes. N.p., n.d. Web. 21
Mar. 2011. <http://www.obd-codes.com/faq/obd-ii-protocols.php>.
[14]. OBD-II PIDs, http://en.wikipedia.org/wiki/OBD-II_PIDs
[15]. Scantool, http://www.scantool.net/
[16]. Elm Electronics, http://www.elmelectronics.com/
[17]. http://ahdesign.us/blog/stn1170-bluetooth-obdii-adapter/bluetooth-obdii-adapter/
[18]. http://nabiltewolde.blogspot.com/2011/11/bluetooth-obd-ii-adapter.html
[19]. http://nicegear.co.nz/electronics-gear/obdii-uart/
[20]. http://softgyan.com/2009/06/top-5-java-erp-software-11422/
[21]. http://torque-bhp.com/software/torque-android-obd2-adapters/. May 2011
[22]. E.M. Shehab, M.W. Sharp, L. Supramaniam& T.A. Spedding, ‘Enterprise Resource
Planning An Integrative Review’, Business Process Management Journal , Vol. 10,
No. 4, 2004, pp. 359-386
[23]. Magnusson, Monika. "Intentions to Adopt Open Source Software ERP Systems-A
Case Study of Four Swedish Municipalities." In System Sciences (HICSS), 2011
44th Hawaii International Conference on, pp. 1-10. IEEE, 2011.
[24]. http://www.obdsol.com/downloads/stn1110_vs_elm327.pdf