Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Understanding SAE J1979-2: E/E Diagnostic Test Modes for OBDonUDS
SAE J1979-2 specifies the diagnostic services and functionally addressed request/response messages for motor vehicle emission-related diagnostics using Unified Diagnostic Services (UDS). It enhances the legacy OBD approach (J1979) by adding capabilities such as DTC-based readiness, extended data records, and support for multiple snapshots. This standard is crucial for engineers working on emissions diagnostics for vehicles that use UDS data links (e.g., ISO 14229-1).
🛠️ What is OBDonUDS and How Does It Build on Classic OBD?
OBDonUDS is not just a translation of the classic J1979 $01-$0A services to UDS; it provides new features that significantly improve diagnostic capability. The standard defines diagnostic services under UDS, allowing for richer error handling and more robust data retrieval. Key enhancements include:
- DTC-based readiness monitoring
- ExtendedDataRecords for diagnostic trouble codes
- Readiness group to DTC readiness translation
- Support for snapshots for up to five DTCs with two occurrences each
🔍 Engineering Insight: OBDonUDS is a step change, not a direct mapping. When migrating from legacy J1979, engineers must re-evaluate how they handle readiness and data requests to avoid misinterpreting the richer UDS semantics.
Key Technical Enhancements and Diagnostic Services in J1979-2
The standard specifies several diagnostic services that replace and supplement the older $01-$0A modes. Below is a summary of the essential services defined in J1979-2:
| Service (UDS ID) | Description | Related Subfunction |
|---|---|---|
| $22 ReadDataByIdentifier | Request current powertrain diagnostic data | N/A |
| $19 ReadDTCInformation | Request freeze frame data, DTC status, and extended data | $04, $42 |
| $14 ClearDiagnosticInformation | Clear/reset emission-related diagnostic information | N/A |
| $19 $42 | Request emission-related DTCs with confirmed status | $42 |
Additionally, the standard defines message formats, application timing parameters, and response codes that must be respected to ensure interoperability. For example, multiple responses to a single data request are allowed, but external test equipment must handle them correctly.
⚠️ Common Implementation Pitfall: In OBDonUDS, a request may return multiple responses to a single data request (e.g., when multiple ECUs respond). Engineers must design their test equipment to aggregate and process these multiple responses per the standard’s guidelines.
Practical Implementation Considerations for Engineers
Integrating OBDonUDS into a vehicle or diagnostic tool requires careful attention to timing, message structure, and data availability. The standard defines minimum time between requests, handling of ‘Data Not Available’ conditions, and byte order conventions. Here are key points to consider:
- Protocol Detection: The vehicle must support a mechanism for external test equipment to detect the active OBD protocol.
- Timing Parameters: External test equipment must respect the minimum time between requests to avoid bus congestion.
- Data Not Available: Implementations must correctly report when requested data is not available, using the defined response codes.
- Expansion Capabilities: The standard allows for enhanced diagnostic services beyond the mandatory emissions data, so systems should support future extensions.
OBDonUDS brings modern diagnostic features to emissions OBD, but it demands a thorough understanding of UDS principles. Engineers familiar with legacy J1979 must adapt to the new message semantics and richer data models.
FAQs
How does OBDonUDS differ from legacy SAE J1979?
OBDonUDS is based on UDS (ISO 14229-1) and adds features like DTC-based readiness, extended data records, and support for multiple DTC snapshots. Legacy J1979 used simpler PID-based requests and limited data sets.
What are the main diagnostic services defined in J1979-2?
The key services are $22 (ReadDataByIdentifier) for current data, $19 (ReadDTCInformation) for freeze frame and DTC data, and $14 (ClearDiagnosticInformation) for clearing DTCs. Each has specific subfunctions for emission-related diagnostics.
How should I handle multiple responses to a single request?
The external test equipment must be capable of receiving and processing multiple responses (e.g., from multiple ECUs) per the Multiple Responses to a Single Data Request clause in the standard. The design should aggregate responses and ensure timeout handling is robust.
What happens when diagnostic data is not available?
Vehicles must respond with a negative response code indicating ‘Data Not Available’ (0x12) or specific subfunction-related NRCs. Designers should check the response code and adapt their logic accordingly, rather than assuming data will always be present.
By following the guidelines in SAE J1979-2, engineers can build reliable and future-compatible emissions diagnostics that leverage the power of UDS. The standard is available at the SAE website for the full detailed specification.
