# 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

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

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.

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.

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.

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

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.

 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.

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:

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