Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
SAE J1979-2017: OBD Diagnostic Test Modes Explained for Engineers
On-Board Diagnostic (OBD) regulations mandate that vehicles support standardized communication of emission-related diagnostic data to generic test equipment. SAE J1979-2017 (E/E Diagnostic Test Modes) specifies the diagnostic services, message formats, and parameter definitions required to ensure interoperability across different vehicle platforms and data link protocols. This article outlines the key aspects of the standard for engineers implementing or integrating OBD diagnostics.
Overview and Scope
SAE J1979-2017 revises previous versions to align with California Air Resources Board (CARB) legislation and harmonize U.S. and European OBD requirements. The standard defines nine diagnostic services (e.g., Service $01 Request Current Powertrain Diagnostic Data, Service $02 Request Freeze Frame Data) and covers multiple data link protocols: ISO 9141-2, ISO 14230-4, SAE J1850, and ISO 15765-4 (CAN). The goal is to allow any external test equipment compliant with SAE J1978 to retrieve emission-related information from vehicles.
The standard also introduces a comprehensive set of Parameter IDs (PIDs) for powertrain, freeze frame, and other diagnostic data. These PIDs are defined in the companion document SAE J1979DA, which includes scaling, units, and data conversion rules.
Key Technical Requirements
Diagnostic Services and Message Formats
Each diagnostic service uses a specific request/response message format. The standard defines how multiple ECUs may respond to a single request, timing parameters to ensure reliable bus communication, and error handling for “data not available” or invalid signals. A crucial aspect is the byte order convention (most significant byte first) and maximum message lengths per protocol.
Below is a summary of supported protocols and their key characteristics:
| Protocol | Max Message Length (including headers) | Addressing |
|---|---|---|
| ISO 9141-2 | 12 bytes | Physical or functional |
| ISO 14230-4 (KWP2000) | 255 bytes | Physical or functional |
| SAE J1850 (VPW/PWM) | 12 bytes | Physical or functional |
| ISO 15765-4 (CAN) | 4095 bytes | Physical or functional (11-bit or 29-bit identifiers) |
🛠️ Engineering Design Insight: The standard’s strength lies in its definition of a common set of PIDs and services across different protocols, enabling generic diagnostic tools to work with vehicles from multiple manufacturers. However, careful attention must be paid to protocol-specific header structures and timing constraints to avoid communication failures.
Timing and Error Handling
Timing parameters are critical. For example, the standard defines the minimum time between requests from external test equipment (P2 timing) and the response time for ECUs. Misimplementation can lead to bus collisions or timeouts. The standard also specifies how to indicate “data not available” (e.g., using a specific response code or invalid data value).
⚠️ Common Mistake: Failing to properly handle multiple responses from different ECUs when using functional addressing. The standard mandates that test equipment be capable of processing multiple responses in a defined manner to avoid data loss or misdiagnosis.
Design Insights and Implementation Guidance
For engineers developing diagnostic software or hardware, here are key takeaways from SAE J1979-2017:
- Interoperability: The standard is directly influenced by regulatory requirements (CARB, EPA, EU). Compliance ensures that vehicles can be diagnosed by generic tools.
- Expansibility: The standard allows for manufacturer-specific diagnostic services beyond mandatory OBD PIDs, enabling enhanced diagnostics while maintaining base compatibility.
- Robustness: Error handling (e.g., invalid signals, data not available) must be implemented exactly as specified to prevent false diagnostic trouble codes.
- Byte Order: Multi-byte parameters use Motorola big-endian order (most significant byte first). Ensure consistency across all implementations.
Frequently Asked Questions
How are multiple responses to a single diagnostic request handled?
The standard specifies that when multiple ECUs respond to a functionally addressed request, the test equipment must process all valid responses. The ECU controllers arbitration mechanism on the bus ensures orderly transmission; for CAN, the identifier priority handles collisions. The test tool must be capable of receiving and interpreting multiple messages.
What is the byte order convention for multi-byte parameters?
SAE J1979-2017 uses big-endian byte order, with the most significant byte transmitted first. This is specified in Section 6.4 Byte Order Convention and must be followed for all PIDs and diagnostic data.
How is ‘data not available’ indicated in responses?
When a requested PID is not supported or data is not accessible, the response includes a specific indicator. For example, Service $01 may return a data value of 0xFF or a dedicated response code like $7F (negative response code with ‘requested data not available’ sub-function). The exact method depends on the service and protocol and is defined in the standard.
What are the maximum message lengths for each supported protocol?
See the table above. For ISO 9141-2 and SAE J1850, the maximum is 12 bytes including headers; for ISO 14230-4, up to 255 bytes; for ISO 15765-4, up to 4095 bytes using extended addressing. These lengths include header and data bytes.
In summary, SAE J1979-2017 is a foundational standard for OBD II communication. Engineers working on vehicle diagnostics must understand its service definitions, protocol variations, and timing parameters to build compliant and interoperable solutions. 🔍
