On-Board Diagnostics (OBD) – introduction to the Modes of Operation (Diagnostic Services)

The vast majority of vehicles in use nowdays are OBD compliant, which means that they have on-board monitoring functions for the systems and components whose functionality has an impact on exhaust gas toxic emissions levels.

For an overall understanding of OBD read the article Introduction to On-Board Diagnostics (OBD).

The communication between the scantool (diagnostic equipment) and the vehicle is defined in the OBD related standards. The communication protocol and the content of the diagnostic data is define in the Application Layer (OSI Level 7).

In this article, we are going to focus on the diagnostic modes/services defined for the CAN protocol. The diagnostic modes/services are described in the ISO and SAE standards:

• ISO 15031-5: Road vehicles – Communication between vehicle and external equipment for emissions-related diagnostics – Part 5: Emissions-related diagnostic services
• SAE J1979: E/E Diagnostic Test Modes

Currently, on the market there are three main types of diagnostic devices (scantools, testers):

• handheld
• PC/laptop based
• mobile device (phone or tablet) application

The handheld one is the one usually identified as a scantool. It’s an independent device, which doesn’t need to be powered from an external source, because it’s using the OBD connector supply voltage pins. It can be used regardless of the type of the vehicle, as long as both are OBD 2 compliant. The advantage of the handheld scantool is that it’s portable and easy to use, just “plug and play”.

The PC/laptop based “scantool” is basically a software that uses an external interface to connect to the vehicle’s OBD port. The main disadvantage, compared to the handheld one, is that you need a laptop with an operating system to install and use the diagnostic software. Further, it still requires an OBD adapter (also called “interface”), which is converting the data between the laptop and vehicle to the right format. The connection between the OBD adapter and the laptop can be serial (USB or RS-232 port) or wireless (Bluetooth).

The advantage of this diagnostic device is mainly linked to the memory and data processing power of the laptop/PC. Large amounts of data can be logged and stored, data plots and other functions (acceleration time, fuel consumption, etc.) can be integrated into the main application.

The third type, the mobile device “scantool”, can be regarded as a combination between the handheld solution and the PC/laptop based one. It still requires the use of an OBD adapter between the mobile device and vehicle but has the advantage of portability. Most of these devices are using a wireless connection (Bluetooth) for the OBD adapter.

Regardless of the type of diagnostic device, the OBD modes of operation (also called diagnostic services) define how the data is requested from the vehicle and how the vehicle responds to the request. You can look at the OBD modes of operation as a definition of the “language” to be used by both parties (scantool and vehicle) when requesting and sending data.

The communication between diagnostic device (scantool) and vehicle is client-server type, based on request and response.

The Client is defined as the function that is part of the diagnostic device (scantool, tester), that makes use of the diagnostic services. A tester normally makes use of other functions such as data base management, specific interpretation and man-machine interfaces.

The Server is defined as a function that is part of an electronic control unit on-board of the vehicle and that provides data to the diagnostic services.

The diagnostic Service can be defined as an information exchange initiated by a client (external test equipment) in order to require diagnostic information from a server (ECU) or/and to modify its behavior for diagnostic purpose.

In the OBD CAN protocol there are 9/10 modes of operation (diagnostic services), each defined by an identifier (also called header). First 9 modes of operation are common between ISO and SAE standards, the 10^th is specific to the SAE standard.

The table below describes the purpose of each mode of operation (diagnostic service) and which standard contains it. Even if there are different standard defining the diagnostic services (SAE and ISO), the content is similar, the ISO standards being adapted after the SAE ones.

Diagnostic service Mode of operation	Description	Standard
$01	Request Current Powertrain Diagnostic Data	SAE, ISO
$02	Request Powertrain Freeze Frame Data	SAE, ISO
$03	Request Emission-Related Diagnostic Trouble Codes	SAE, ISO
$04	Clear/Reset Emission-Related Diagnostic Information	SAE, ISO
$05	Request Oxygen Sensor Monitoring Test Results	SAE, ISO
$06	Request On-Board Monitoring Test Results for Specific Monitored Systems	SAE, ISO
$07	Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle	SAE, ISO
$08	Request Control of On-Board System, Test or Component	SAE, ISO
$09	Request Vehicle Information	SAE, ISO
$0A	Request Emission-Related Diagnostic Trouble Codes with Permanent Status	SAE

The dollar sign “$” in front of the numerical value highlights that this is an identifier. It’s important to know that the numerical values of the identifiers are in hexadecimal format. The correct notations would be using the 0x prefix, for example 0x01.

Mode/Service $01 – Request Current Powertrain Diagnostic Data

The purpose of this service is to allow the individual who is performing a vehicle diagnostic, to access the current emission-related data values, including analogue inputs and outputs, digital inputs and outputs, and system status information.

The Client request for information includes a Parameter IDentification (PID) value which indicates to the on-board system what specific information is requested. PID specifications (description, scaling information and display formats) are included in the ISO and SAE standard mentioned above.

The electronic control units (Server) shall respond to this message by transmitting the requested data value last determined by the system. This service provides accurate information, all data values returned for sensor readings shall be actual readings, not default or substitute values used by the system (constant values or calibration parameters) due to a fault with the sensor.

This diagnostic mode can provide relevant data to the user since it gives the current values of the engine parameters (speed, load, temperature, etc.). If the data is requested continuously (e.g. every 0.1 s) and recorded, a data plot can be created, which shows the variation in time of the parameters.

There are currently 135 PIDs defined in the OBD standard but not all of them are mandatory. There are a limited number of mandatory PIDs, the rest of them depending on the configuration of the system (engine).

The table below contains the list of mandatory PIDs (common between spark ignition and compression ignition engines) and some examples of optional PIDs.

PID	Description	Required
00	PIDs supported [01 – 20]	Mandatory
01	Monitor status since DTCs cleared
02	DTC that caused required freeze frame data storage
04	Calculated LOAD Value
05	Engine Coolant Temperature
0C	Engine RPM
0D	Vehicle Speed Sensor
1C	OBD requirements to which vehicle or engine is certified
20	PIDs supported [21 – 40]
21	Distance Traveled While MIL is Activated
30	Number of warm-ups since DTC cleared
31	Distance since DTCs cleared
0B	Intake Manifold Absolute Pressure	Optional
0F	Intake Air Temperature
10	Air Flow Rate from Mass Air Flow Sensor
1F	Time Since Engine Start
42	Control module voltage

Every parameter is identified with a number, which is in hexadecimal format. For example, the identifier of the engine speed is 0x0C.

For example, let’s assume that we want to read the current value of the calculated engine load. This parameter can be read with the diagnostic service 0x01 and has the identifier 0x04.

For spark ignition (gasoline) engines, Calculated Load Value is an indication of the current airflow divided by peak (maximum) airflow at Wide Open Throttle (WOT) as a function of rpm, where airflow is corrected for altitude and ambient temperature. This definition provides a unit-less number, and provides the service technician with an indication of the percent engine capacity that is being used. For compression ignition (diesel) engines, the calculated load value shall be determined by replacing air mass flow with fuel mass flow in the calculation.

The scantool (client) will send 0104 to the vehicle (server). This message has two components, both in hexadecimal format:

• 01 is the ID of the diagnostic service to be used
• 04 is the ID of the requested engine parameter (calculated load in this case)

The vehicle will respond with 41046A. This response message has three components, all in hexadecimal format:

• 41 is the positive response (40 + 01), which means that the server understand the request and will provide the data
• 04 is an acknowledgement of the parameter ID to be read
• 6A is the value of the calculated engine load

Now the scantool has to convert the hexadecimal value of the engine load in physical value so that it can be understood by the human user. The conversion from hexadecimal to physical values [%] is defined in the ISO and SAE standard for each PID. For the calculated engine load, the conversion is:

\[\text{LOAD [%]} = \frac{100}{255} \cdot \text{DECIMAL}\]

To understand what’s happening in the scantool, we’ll convert the hexadecimal number into decimal values. For reference read the article Hexadecimal to Decimal Conversion, use a handheld calculator or a Matlab/Scilab function:

-->hex2dec('6A')

ans =
106.

-->

Now we can calculate the physical value of the engine load:

\[\text{LOAD} = \frac{100}{255} \cdot 106 = 41.5686 \text{ [%]}\]

The same approach is valid for all of the physical engine parameters.

Mode/Service $02 – Request powertrain freeze frame data

When a monitored component/system fails, a diagnostic trouble code (DTC) is raised. For a better understanding of the failure, by the service technician, the OBD is providing a “freeze frame”. This is a set of engine and vehicle parameters stored in the non-volatile memory, when the DTC is raised.

For example, while driving at high speed, a DTC is raised for the exhaust catalyst. In order to understand why the failure occurred, we are going to have the value of the engine temperature, speed, load and vehicle speed stored in the freeze frame, for the exact moment of the failure appearance.

Example of Freeze Frame Data:

PID	Description	Value	Units
0x02	DTC that caused required freeze frame data storage	P1461	–
0x04	Calculated Load Value	0	%
0x05	Engine Coolant Temperature	63	°C
0x0B	Intake Manifold Absolute Pressure	89.0	kPa
0x0C	Engine RPM	0	rpm
0x0D	Vehicle Speed	0	km/h
0x10	Air Flow Rate from Mass Flow Sensor	0.00	gm/sec

Only engine or vehicle parameters defined as PIDs can be used in the freeze frame.

Mode/Service $03 – Request Emission-Related Diagnostic Trouble Codes

The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to obtain all the “confirmed” emission-related diagnostic trouble codes (DTCs). A confirmed fault code is defined as the DTC stored when an OBD system has confirmed that a malfunction exists. Usually, the confirmation is given on the second driving cycle following the malfunction detection.

When the scantool is sending a Service $03 request for all emission-related DTCs, each ECU that has DTCs shall respond with one message containing all emission-related DTCs. If an ECU does not have emission-related DTCs, then it shall respond with a message indicating no DTCs are stored by setting the parameter number of DTC to 0x00.

Example of Emission-Related Diagnostic Trouble Codes:

Code	Description
P0000	No stored trouble codes
P1462	A/C pressure sensor circuit voltage high
P1461	A/C pressure sensor circuit voltage low

Mode/Service $04 – Clear/Reset Emission-Related Diagnostic Information

The purpose of this service is to provide a means for the external test equipment (scantool, tester) to command ECUs to clear all emission related diagnostic information.

Mode $04 clears/erases diagnostic trouble codes and diagnostic data, which includes:

• freeze frames
• inspection/maintainance readiness
• status of monitors
• PID for number of engine warm-ups, distance with Malfunction Indicator Lamp (MIL) ON
• data read by mode/service $06

This mode can be used by the service technicians (or other users) to turn off the MIL and erase stored DTCs after a repair has been performed. It can be also used as a confirmation that the fault is not present anymore (after reset the DTC are read again).

Mode/Service $05 – Request Oxygen Sensor Monitoring Test Results

Mode $05 provides test results for oxygen (lambda) sensors. It is not supported anymore for CAN communication protocol but all the functionality of this mode is implemented in Mode $06.

Mode/Service $06 – Request On-Board Monitoring Test Results for Specific Monitored Systems

The purpose of this diagnostic service is to allow access to the results for on-board diagnostic monitoring tests of specific components/systems that are either continuously monitored (e.g. misfire monitoring) or non-continuously monitored (e.g. catalyst system).

The vehicle manufacturer will define “Manufacturer Defined Test IDs” for different tests of a monitored system. Mode $06 will provide the monitoring test values and fault (malfunction) limits for the defined tests (monitors).

The data provided by this diagnostic service can be used by service technicians to identify which monitor has failed and by how much. Once the failed component/system has been repaired/restored, Mode $06 data can be used to validate the process.

A particular monitoring test of Mode $06 is defined for the oxygen (lambda) sensor. The test monitors the voltage output of the sensor.

The parameters of the oxygen sensor output voltage are requested as Test ID (TID), with the following description:

Test ID	Description
$00	ISO/SAE reserved
$01	Rich to lean sensor threshold voltage (constant)
$02	Lean to rich sensor threshold voltage (constant)
$03	Low sensor voltage for switch time calculation (constant)
$04	High sensor voltage for switch time calculation (constant)
$05	Rich to lean sensor switch time (calculated)
$06	Lean to rich sensor switch time (calculated)
$07	Minimum sensor voltage for test cycle (calculated)
$08	Maximum sensor voltage for test cycle (calculated)
$09	Time between sensor transitions (calculated)
$0A	Sensor period (calculated)
$0B	EWMA (Exponential Weighted Moving Average) misfire counts for last ten (10) driving cycles (calculated, rounded to an integer value)

Example of Monitoring Test Results (non oxygen sensor):

OBDMID	Description	Test ID	Description	Value	Min Value	Max Value	Min	Max	Result
0x31	EGR Monitor Bank 1	0x80	Manufacture test ID description	21	-3277	217	-3276.8	3276.7	Passed
0x21	Catalyst Monitor Bank 1	0x80	Manufacture test ID description	0	0	1	0	1.99	Passed
0x81	Fuel System Monitor Bank 1	0x82	Manufacture test ID description	1	1	1	0	1.99	Passed
0xA4	Misfire Cylinder 3 Data	0x0C	Misfire counts for last/current driving cycles	2	0	2	0	65535	Passed

Mode/Service $07 – Request Emission-Related Diagnostic Trouble Codes Detected During Current or Last Completed Driving Cycle

The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to obtain “pending” diagnostic trouble codes (DTCs) detected during current or last completed driving cycle for emission-related components/systems.

A pending fault code is defined as the diagnostic trouble code, stored as a result of initial detection of a malfunction (usually in the current driving cycle), before the activation of the malfunction indicator lamp (MIL).

This operating mode is required for all diagnostic trouble codes and it’s independent of Service $03.

The intended use of this data is to assist the service technician after a vehicle repair, and after clearing diagnostic information, by reporting test results after a single driving cycle.

Example of Emission-Related Pending Diagnostic Trouble Codes:

Code	Description
P0000	No pending trouble codes
P1462	A/C pressure sensor circuit voltage high

Mode/Service $08 – Request Control of On-Board System, Test or Component

The purpose of this service is to enable the external test equipment (scantool, tester) to control the operation of an on-board system, test or component. With the help of this service, the service technician can activate an on-board test mode.

The possible types of tests performed with Mode $08 are:

• turn on-board system/test/component ON
• turn on-board system/test/component OFF
• cycle on-board system/test/component for a predefined number of seconds

An example of test is the sealing of the evaporative system (EVAP) for a pressure test. When the test is triggered, the canister ventilation solenoid is closed for fixed duration (e.g. 10 minutes).

Mode/Service $09 – Request Vehicle Information

The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to request vehicle specific information such as:

• Vehicle Identification Number (VIN)
• Module Calibration Number (CALID)
• Calibration Verification Number (CVN)
• In-use Performance Ratio (IUPR) values

The VIN is a unique number which identifies the vehicle. It’s defined by an international standard and every vehicle in use has an unique VIN.

A unique CALID is required for each emission-related calibration of the electronic control unit (ECU). Even if only one value of the ECU calibration data is changed, a new CALID must be generated.

A CVN is linked to each CALID. It’s basically a checksum of the ECU calibration, which is calculated at every driving cycle and stored in the non-volatile memory of the ECU, so that it can be read with the the engine ON or OFF.

IUPR are counters which display how often OBD monitors are triggered in real driving conditions compared to a standard homologation cycle. These are required for the most of the OBD monitored systems (exhaust catalysts, oxygen sensors, exhaust gas recirculation (EGR), secondary air, etc.).

Example of Vehicle Information Data:

Info Type ID	ECU	Description	Data
0x04	7E8	Calibration Identifications	000007615981
0x04	7E8	Calibration Identifications	000007619027
0x06	7E8	Calibration Verification Numbers	B34322E5
0x06	7E8	Calibration Verification Numbers	F1070907

Mode/Service $0A – Request Emission-Related Diagnostic Trouble Codes with Permanent Status

The purpose of this diagnostic service is to enable the external test equipment (scantool, tester) to obtain all diagnostic trouble codes with “permanent” status. These are DTCs that are “confirmed” and are stored in the non-volatile memory of the electronic control unit until the corresponding monitor for each DTC has determined that the malfunction is no longer present and is not setting the MIL ON anymore.

The DTCs stored as permanent can not be cleared with the scantool using Mode $04. Permanent status codes automatically clear themselves after repairs have been made and the related system monitor runs successfully.

For any questions or observations regarding this tutorial please use the comment form below.

Don’t forget to Like, Share and Subscribe!