JOURNAL OF L
A
T
E
X CLASS FILES, VOL. 13, NO. 9, SEPTEMBER 2014 3
Fig. 1. The Three Main Subsystems.
Fig. 2. The Functional Units of the Subsystems.
is designed and implemented on off-the shelf hardware. The
data link connector (FU 1.3) is a standard connector in the
vehicle to which the OBD II reader is connected. The OBD II
protocol interface (FU 2.1) detects and interprets the ECU data
according to the implemented OBD II protocol. Conversion
of data in text format to voltage levels (FU 2.2) from the
processor to the on-board system and vice versa is performed.
PID data is requested and performs the processing of the
data received from the ECU via the OBD II protocol interface
(FU 2.3). It is also responsible for controlling the GPS (FU
2.6) and the wireless communication modules (FU 2.5). The
server is a PC from which a database management system
(FU 3.1) and a GUI (FU 3.2) is run. Discrete components and
regulators are used (FU 2.7) to scale the 12 V output from the
OBD II data link connector down to voltage levels suitable for
powering other system components.
IV. SYSTEM DESIGN
A. ELM327 Integrated Circuit
The ELM327 is an OBD II interpreter IC. It is a microcon-
troller designed to automatically interpret all OBD II signalling
protocols. It can thus be interfaced with the electronic circuitry
required to establish communication with the vehicle ECU via
the OBD II port. The protocols implemented in this study were
the ISO 15765 (CAN), ISO 9141-2 and ISO 14230-4.
An AT Command set predefined for the ELM327 was used
to communicate with the IC through RS232. The command
set allowed for setting up the IC to change its behaviour so as
to suit the requirements of the system. This included setting
Fig. 3. The OBD II Message Format.
Fig. 4. The OBD II Response Message Format.
up the Baud rate for RS232 communication, format of the
received data from the ECU and initialisation of the type of
OBD II protocol implemented on the vehicle.
A separate command set referred to as OBD commands,
was used to communicate with the ECU from the ELM327.
Commands from this set consist of only hexadecimal charac-
ters as defined in the SAE J1979 standard. Each command
from this set is a combination of either a PID or a DTC and
a value that indicates a mode of operation. The ELM327 has
ten diagnostic modes of operation which are defined in the
SAE J1979 standard. The operation of each mode depends
on the type of information required from the ECU. Mode
one was mainly used in the implementation of the OBD II
reader subsystem is for requesting and showing current real
time vehicle data and mode two for example is for diagnosing
engine malfunctions. The SAEJ1979 standard also defines
formulas to be used to decode messages received from the
ECU so as to obtain actual parameter measurements and the
structure of response message from the ECU.
OBD commands are typically two bytes long, however they
are sent to the vehicle ECU as part of a longer message. The
byte structure of this message is shown in Figure 3.
Messages are assigned priorities which are used to deter-
mine the order of sending messages in the event that more
than one message is sent simultaneously.The receiver and
transmitter bytes are the source and destination addresses. The
vehicle ECU is an addressable electrical bus, the source and
destination address are thus necessary for use in the address
line of the bus.
OBD II commands are encapsulated as part of the payload
section which can be as long as 7 bytes. The last field of
the message is a checksum which is responsible for detecting
errors in messages received from the vehicle ECU. The ISO
9141-2 and ISO 14230-4 standards both employ the same mes-
sage structure, CAN messages are however slightly different.
The structure of response messages from the ECU is shown
in Figure 4. The first byte indicates the mode of operation.
The hexadecimal value ’1’ in the ’41’ indicates mode 1. If a
DTC was sent under mode two then value of the first byte
would be ’42’. The second byte is the PID which was sent
with the request message. Position A to D is the data bytes
which contain the requested parameter value from the vehicle.
Figure 5 shows an example of a request and a response
message sent by the ELM327 and ECU respectively when