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
OBD Scantool

Image: OBD Scantool

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”.

Windows OBD Scantool

Image: Windows OBD Scantool
Credit: Auterra

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.

OBD diagnostic device - mobile

Image: OBD diagnostic device – mobile
Credit: PLX Devices

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.

OBD mode of operation (diagnostic services) client-server type

Image: OBD mode of operation (diagnostic services) client-server type

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 10th is specific to the SAE standard.

OBD modes of operation (diagnostic services)

Image: OBD modes of operation (diagnostic services)

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
$01Request Current Powertrain Diagnostic DataSAE, ISO
$02Request Powertrain Freeze Frame DataSAE, ISO
$03Request Emission-Related Diagnostic Trouble CodesSAE, ISO
$04Clear/Reset Emission-Related Diagnostic InformationSAE, ISO
$05Request Oxygen Sensor Monitoring Test ResultsSAE, ISO
$06Request On-Board Monitoring Test Results for Specific Monitored SystemsSAE, ISO
$07Request Emission-Related Diagnostic Trouble Codes Detected During
Current or Last Completed Driving Cycle
$08Request Control of On-Board System, Test or ComponentSAE, ISO
$09Request Vehicle InformationSAE, ISO
$0ARequest Emission-Related Diagnostic Trouble Codes with Permanent StatusSAE

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.

OBD Mode 01 - intake air mass flow rate plot

Image: OBD Mode 01 – intake air mass flow rate plot

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.

00PIDs supported [01 – 20]Mandatory
01Monitor status since DTCs cleared
02DTC that caused required freeze frame data storage
04Calculated LOAD Value
05Engine Coolant Temperature
0CEngine RPM
0DVehicle Speed Sensor
1COBD requirements to which vehicle or engine is
20PIDs supported [21 – 40]
21Distance Traveled While MIL is Activated
30Number of warm-ups since DTC cleared
31Distance since DTCs cleared
0BIntake Manifold Absolute PressureOptional
0FIntake Air Temperature
10Air Flow Rate from Mass Air Flow Sensor
1FTime Since Engine Start
42Control 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.

OBD scantool requesting engine load parameter

Image: OBD scantool requesting engine load parameter

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:


ans =


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:

0x02DTC that caused required freeze frame data storageP1461
0x04Calculated Load Value0%
0x05Engine Coolant Temperature63°C
0x0BIntake Manifold Absolute Pressure89.0kPa
0x0CEngine RPM0rpm
0x0DVehicle Speed0km/h
0x10Air Flow Rate from Mass Flow Sensor0.00gm/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:

P0000No stored trouble codes
P1462A/C pressure sensor circuit voltage high
P1461A/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.

OBD Mode 06 - oxygen sensor data

Image: OBD Mode 06 – oxygen sensor data

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

Test IDDescription
$00ISO/SAE reserved
$01Rich to lean sensor threshold voltage (constant)
$02Lean to rich sensor threshold voltage (constant)
$03Low sensor voltage for switch time calculation (constant)
$04High sensor voltage for switch time calculation (constant)
$05Rich to lean sensor switch time (calculated)
$06Lean to rich sensor switch time (calculated)
$07Minimum sensor voltage for test cycle (calculated)
$08Maximum sensor voltage for test cycle (calculated)
$09Time between sensor transitions (calculated)
$0ASensor period (calculated)
$0BEWMA (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):

OBDMIDDescriptionTest IDDescriptionValueMin ValueMax ValueMinMaxResult
0x31EGR Monitor Bank 10x80Manufacture test ID description21-3277217-3276.83276.7Passed
0x21Catalyst Monitor Bank 10x80Manufacture test ID description00101.99Passed
0x81Fuel System Monitor Bank 10x82Manufacture test ID description11101.99Passed
0xA4Misfire Cylinder 3 Data0x0CMisfire counts for last/current driving cycles202065535Passed

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:

P0000No pending trouble codes
P1462A/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 IDECUDescriptionData
0x047E8Calibration Identifications000007615981
0x047E8Calibration Identifications000007619027
0x067E8Calibration Verification NumbersB34322E5
0x067E8Calibration Verification NumbersF1070907

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!


  1. Lori
  2. clyde barnett
  3. Slim

Leave a Reply

Ad Blocker Detected

Dear user, Our website provides free and high quality content by displaying ads to our visitors. Please support us by disabling your Ad blocker for our site. Thank you!