The purpose of diagnostic service/mode 01 is to allow access to current emission-related data values of an internal combustion engine (ICE). The data should include analogue inputs and outputs, digital inputs and outputs, and system status information. The request for engine data includes a parameter identification (PID) value that indicates to the on-board system what information is requested. PID specifications, scaling information, and display formats are defined in part 5 of the ISO-15031 standard and SAE J 1979 standard.
For a reminder of all OBD diagnostic modes/services, please read the article On-Board Diagnostics (OBD) – introduction to the Modes of Operation (Diagnostic Services).
This article will focus on the implementation of OBD diagnostic service/mode 01 define in the standards SAE J1979 / ISO 15031-5. The main reason is that most of the new vehicles use Controller Area Network (CAN) protocol for OBD communication.
When a data request is send by the diagnostic tool, the electronic control units (ECUs) will respond to this message by transmitting the requested data value last determined by the system. All data values returned for sensor readings will be actual readings, not default or substitute values used by the system because of a fault with that sensor. Usually, the ECUs which are mandatory to implement the OBD diagnostic services are:
- engine/powertrain control module (PCM)
- transmission control module (TCM)
Not all PIDs are applicable or supported by all systems. PID 00 is a bit-encoded PID that indicates, for each ECU, which PIDs that ECU supports. PID 00 shall be supported by all ECUs that respond to a service $01 request, because the external test equipment that conforms to ISO 15031-4 use the presence of a response message by the vehicle to this request message to determine which protocol is supported for diagnostic communications.
All emissions-related OBD ECUs shall support service 01 and PID 00. Service 01 with PID 00 is defined as the universal “initialization/keep alive/ping” message for all emissions-related OBD ECUs.
How does it work ?
The scantool is making a request for a parameter (PID) and the vehicle responds to the request with the data. For example, to request the engine coolant temperature, the scantool will send 0105 and the vehicle’s PCM will respond with 41054F. Please note that both request and response messages are in hexadecimal format.
The meaning of the 0105 request is:
01is the requested service, Request Current Powertrain Diagnostic Data in this case05is the PID of the engine coolant temperature
The meaning of the 41054F response is:
41 = 40 + 01means a positive response (40) to the service/mode (01) request05the parameter identifier for which following data will be provided4Fthe value of the engine coolant temperature, in hexadecimal format; to convert in physical values we need to convert in decimal numbers and subtract 40, which gives 79 – 40 = 39 °C
The general format of the $01 Read Current Diagnostic Data service/mode is:
| Data bytes (HEX) | |||||||
| #1 | #2 | #3 | #4 | #5 | #6 | #7 | |
| Request | 01 | PID | |||||
| Response | 41 | PID | data A | data B | data C | data D | |
The request is a stream of maximum 7 bytes. The first byte represents the service/mode identifier, which for Read Current Diagnostic Data is 01. From second byte up to the seventh are the IDs of the parameters we want to read (PIDs). In one request up to 6 PIDs can be requested. The minimum number of requested PIDs is 1, the maximum is 6.
Observation: The maximum number of 4 data bytes is defined in the SAE J1979, version year 2002. Newer version of the standard allows for more data bytes.
For example, if 4 PIDs are requested: 01PID1PID2PID3PID4
the response message will have the following format: 41PID1(data)PID2(data)PID3(data)PID4(data)
where (data) can have from 1 to 4 bytes.
The length of the response stream is variable, depending on the number of requested PIDs and the number of data bytes of each PIDs. For example, let’s assume that we need to read 3 engine parameters:
| Engine parameter | PID | Data bytes | Conversion rule |
| Engine speed [rpm] | 0C | 2 | ((A*256)+B)/4 |
| Absolute Throttle Position [%] | 11 | 1 | A*100/255 |
| Time since engine start [s] | 1F | 2 | (A*256)+B |
The request will be: 010C111F
The response could be: 410C2B7D118C1F37D2
Applying the conversion rule we get the following physical data for the engine parameters:
| Engine parameter | Conversion rule | Data byte A [hex/dec] | Data byte B [hex/dec] | Physical value |
| Engine speed [rpm] | ((A*256)+B)/4 | 2B / 43 | 7D / 125 | ((43*256)+125)/4 = 2783.25 rpm |
| Absolute Throttle Position [%] | A*100/255 | 8C / 140 | 140*100/255 = 54.9 % | |
| Time since engine start [s] | (A*256)+B | 37 / 55 | D2 / 210 | (55*256)+210 = 14290 s |
How the information is encoded ?
The standard SAE J1979 and its European equivalent ISO 15031-5 define the OBD PIDs using a bit-encoded method. For example, if the PID uses 4 bytes of information, they’ll be defined as:
| Byte | A | B | C | D | ||||||||||||||||||||||||||||
| Bit | A7 | A6 | A5 | A4 | A3 | A2 | A1 | A0 | B7 | B6 | B5 | B4 | B3 | B2 | B1 | B0 | C7 | C6 | C5 | C4 | C3 | C2 | C1 | C0 | D7 | D6 | D5 | D4 | D3 | D2 | D1 | D0 |
Bit 7 is the most significant bit (MSB) and bit 0 is the least significant bit (LSB).
Specific PIDs
PID 00
A request for this PID returns 4 bytes of data. Each bit, from MSB to LSB, represents one of the next 32 PIDs, from ID 01 to 20, and specifies whether that PID is supported.
For example, for the request 0100 if the vehicle’s response is 4100BE1FA813, the decoded information looks like:
| Byte # | 1 | 2 | 3 | 4 | ||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Hexadecimal | B | E | 1 | F | A | 8 | 1 | 3 | ||||||||||||||||||||||||
| Binary | 1 | 0 | 1 | 1 | 1 | 1 | 1 | 0 | 0 | 0 | 0 | 1 | 1 | 1 | 1 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | 1 |
| Supported? | Yes | No | Yes | Yes | Yes | Yes | Yes | No | No | No | No | Yes | Yes | Yes | Yes | Yes | Yes | No | Yes | No | Yes | No | No | No | No | No | No | Yes | No | No | Yes | Yes |
| PID number | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | 0E | 0F | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | 20 |
which means that the supported PIDs are: 01, 03, 04, 05, 06, 07, 0C, 0D, 0E, 0F, 10, 11, 13, 15, 1C, 1F and 20.
Similar PIDs are:
- PID
20: shows which PIDs are supported between21and40 - PID
40: shows which PIDs are supported between41and60 - PID
60: shows which PIDs are supported between61and80 - PID
80: shows which PIDs are supported between81andA0 - PID
A0: shows which PIDs are supported betweenA1andC0
PID 01
A request 0101 returns 4 bytes of data, labeled A B C and D.
The first byte(A) contains two pieces of information. Bit A7 (MSB of byte A, the first byte) indicates whether or not the MIL (check engine light) is illuminated. Bits A6 through A0 represent the number of diagnostic trouble codes currently flagged in the ECU.
The second, third, and fourth bytes(B, C and D) give information about the availability and completeness of certain on-board tests. Note that test availability is indicated by set (1) bit and completeness is indicated by reset (0) bit.
| Byte | Min value | Max value | Encoding | Engine | |
| A | Bit A0: | Number of DTCs stored in this ECU (MIN: 0, MAX:127) | SI/CI | ||
| Bit A1: | |||||
| Bit A2: | |||||
| Bit A3: | |||||
| Bit A4: | |||||
| Bit A5: | |||||
| Bit A6: | |||||
| 0 = MIL OFF | 1 = MIL ON | Bit A7: | Malfunction Indicator Lamp (MIL) status | SI/CI | |
| B | 0 = NO | 1 = YES | Bit B0: | Misfire monitoring supported | |
| 0 = NO | 1 = YES | Bit B1: | Fuel system monitoring supported | ||
| 0 = NO | 1 = YES | Bit B2: | Comprehensive component monitoring supported | ||
| 0 = SI | 1 = CI | Bit B3: | Compression ignition monitoring supported | ||
| 0 = YES | 1 = NO | Bit B4: | Misfire monitoring ready | ||
| 0 = YES | 1 = NO | Bit B5: | Fuel system monitoring ready | ||
| 0 = YES | 1 = NO | Bit B6: | Comprehensive component monitoring ready | ||
| 0 | 0 | Bit B7: | ISO/SAE reserved | ||
| C | 0 = NO | 1 = YES | Bit C0: | Catalyst monitoring supported | SI |
| NMHC catalyst monitoring supported | CI | ||||
| Bit C1: | Heated catalyst monitoring supported | SI | |||
| NOx after-treatment monitoring supported | CI | ||||
| Bit C2: | Evaporative system monitoring supported | SI | |||
| ISO/SAE reserved | CI | ||||
| Bit C3: | Secondary air system monitoring supported | SI | |||
| Boost pressure system monitoring supported | CI | ||||
| Bit C4: | ISO/SAE reserved | SI | |||
| ISO/SAE reserved | CI | ||||
| Bit C5: | Oxygen sensor monitoring supported | SI | |||
| Exhaust gas sensor monitoring supported | CI | ||||
| Bit C6: | Oxygen sensor heater monitoring supported | SI | |||
| PM filter monitoring supported | CI | ||||
| Bit C7: | EGR and/or VVT system monitoring supported | SI | |||
| EGR and/or VVT system monitoring supported | CI | ||||
| D | Bit D0: | Catalyst monitoring ready | SI | ||
| NMHC catalyst monitoring ready | CI | ||||
| Bit D1: | Heated catalyst monitoring ready | SI | |||
| NOx aftertreatment monitoring ready | CI | ||||
| Bit D2: | Evaporative system monitoring ready | SI | |||
| ISO/SAE reserved | CI | ||||
| Bit D3: | Secondary air system monitoring ready | SI | |||
| Boost pressure system monitoring ready | CI | ||||
| Bit D4: | ISO/SAE reserved | SI | |||
| ISO/SAE reserved | CI | ||||
| Bit D5: | Oxygen sensor monitoring ready | SI | |||
| Exhaust gas sensor monitoring ready | CI | ||||
| Bit D6: | Oxygen sensor heater monitoring ready | SI | |||
| PM filter monitoring ready | CI | ||||
| Bit D7: | EGR and/or VVT system monitoring ready | SI | |||
| EGR and/or VVT system monitoring ready | CI | ||||
The third and fourth bytes are to be interpreted differently depending on if the engine is spark ignition (SI, petrol/gasoline) or compression ignition (CI, diesel). In the second (B) byte, bit 3 indicates how to interpret the C and D bytes, with 0 being SI and 1 being CI.
PC Diagnostic Tools
All diagnostic services can be implemented in a software which can run on a PC or laptop, as well as on a mobile device (smart phone or tablet). The advantage of such a software is that the PIDs can be easily read, logged and saved.
Image: Request Current Powertrain Diagnostic Data – supported PIDs
OBD 2007 diagnostic software allows to see which are the supported PIDs of the vehicle under test. By selecting the individual PIDs, their values can be monitored and logged for further time analysis. The number of supported PIDs depends on the type on engine (petrol or diesel) and the model year (MY). Newer vehicles with latest emissions standards have more PIDs supported.
Image: OBD diagnostic service (mode) 01 – Request Current Powertrain Diagnostic Data
Image: Request Current Powertrain Diagnostic Data – PID 01
OBD diagnostic service (mode) $01 – Request Current Powertrain Diagnostic Data can be summarised as:
- Mode $01 provides diagnostic data, commonly known as PIDs (Parameter IDs)
- Service technicians can use the data to troubleshoot sensors, check OBD monitor completion and MIL status
- Test tools (scantools, diagnostic tools) specifies the request data by PID number (
00toFF) - PIDs are defined in part 5 of the ISO-15031 standard and SAE J 1979 standard
- Each PID has an ID, description, unit, conversion/scaling factor or encoding and an acronym)
- PIDs must show “raw” measured values, not substitute values if a sensor fails