Complete Overview of Control DTC Setting (0x85) in UDS Protocol

Hello, fellow automotive tech enthusiasts! In this blog post, I’m excited to walk you through UDS Control DTC Setting 0x85 – one of the key diagnostic services in the UDS

protocol: Control DTC Setting (0x85). This service plays a critical role in controlling how Diagnostic Trouble Codes (DTCs) are enabled or suppressed in Electronic Control Units (ECUs). Whether you’re working with vehicle diagnostics, emissions compliance, or fault management, understanding this service is essential. I’ll explain what Control DTC Setting does, how it works, and where it’s typically used in real-world automotive systems. We’ll also look at example use cases to bring clarity to its application. By the end of this post, you’ll have a solid understanding of the 0x85 service in UDS. Let’s dive into the world of intelligent fault control!

Introduction to Control DTC Setting (0x85) Service in UDS Protocol

Control DTC Setting (0x85) is a diagnostic service defined in the Unified Diagnostic Services (UDS) protocol, primarily used in automotive ECUs (Electronic Control Units). This service allows the tester (typically a diagnostic tool) to enable or disable the recording of Diagnostic Trouble Codes (DTCs) in specific situations. It’s particularly useful during ECU flashing, software updates, or testing phases when triggering fault codes may not be desirable. The ability to control DTC recording ensures that unnecessary or misleading fault codes do not clutter the memory or confuse diagnostics. This service is often used in combination with security access and session control services for safe and authorized operations.

What is Control DTC Setting (0x85) Service in UDS Protocol?

Control DTC Setting (0x85) is a service in the UDS (Unified Diagnostic Services) protocol that allows a diagnostic tool (tester) to control whether the ECU should enable or disable the storage and reporting of Diagnostic Trouble Codes (DTCs). This service is especially useful during development, testing, or software flashing processes when engineers may not want the ECU to log faults that occur under controlled or expected conditions.

The 0x85 service accepts a sub-function parameter that tells the ECU whether to turn DTC recording ON or OFF. This prevents the generation of unnecessary DTCs during non-normal operations like firmware updates or bench testing. Once the testing is complete, DTC logging can be re-enabled to resume normal fault detection and diagnostics.

To maintain system integrity and avoid misuse, access to this service is typically restricted and may require a specific diagnostic session or security access before it can be used.

Why do we need Control DTC Setting (0x85) Service in UDS Protocol?

Here’s a detailed explanation of why we need the Control DTC Setting (0x85) Service in UDS Protocol:

1. Prevents Unnecessary DTC Logging During Testing

During ECU development and validation phases, many temporary or expected errors can occur. Recording these as DTCs can clutter the fault memory and confuse diagnostics later. By using the 0x85 service, engineers can prevent logging of these irrelevant faults. This ensures that only meaningful and permanent issues are captured during actual diagnostics. It helps maintain a clean and relevant DTC history throughout testing.

2. Helps During ECU Software Flashing or Calibration

While flashing new firmware or performing calibration on an ECU, temporary disconnections and state changes are common. These can trigger fault codes that do not represent real issues. The Control DTC Setting service disables DTC logging during such operations to avoid recording false positives. This is crucial for maintaining software and diagnostic integrity. Once the process completes, DTC logging can be re-enabled.

3. Improves Fault Management Accuracy

Logging every fault indiscriminately can overwhelm the diagnostic system with irrelevant data. The 0x85 service enables selective control over what gets logged, improving the accuracy of fault reporting. This helps service technicians and engineers focus only on real, persistent issues. It reduces time spent on analyzing false DTCs. The result is a cleaner and more reliable fault database.

4. Supports Compliance with Emission Regulations

Emission-related ECUs are monitored closely, and any logged fault could have legal or regulatory implications. During non-driving operations like software updates, recording unrelated DTCs could cause compliance violations. Disabling DTC logging during such procedures ensures that only actual emission-related issues are tracked. It keeps the system compliant with regulations like OBD-II and Euro standards. This protects OEMs and workshops from legal complications.

5. Prevents False Fault Memory Entries in Workshops

In a repair or maintenance setting, temporary conditions may occur like unplugging sensors for testing. These could create DTCs that aren’t actual system faults. The 0x85 service allows mechanics to disable DTC logging during such actions. This ensures that only genuine issues are stored in the fault memory. It avoids unnecessary repairs and diagnostic confusion.

6. Allows Controlled Diagnostic Environment

Engineers often simulate errors to test how systems respond, but logging those simulations can corrupt fault history. Control DTC Setting lets them disable DTC recording during fault injection tests. This makes the diagnostic process cleaner and more controlled. It ensures only real-world, persistent faults are stored for evaluation. This is essential in a lab or bench testing environment.

7. Reduces Debugging Time for Engineers

If the fault memory is cluttered with unrelated DTCs, engineers spend extra time filtering and analyzing them. By controlling DTC logging with the 0x85 service, they avoid logging non-critical faults. This reduces post-test debugging time significantly. Engineers can focus on real problems without the distraction of test-related DTCs. It streamlines the development and validation process.

8. Enhances Test Automation Efficiency

Automated testing environments may run scripts that trigger temporary fault states. Logging every minor error can make result files large and confusing. Using 0x85 to disable DTC recording during certain test phases improves clarity. The logs remain concise and focused on actual problems. It also speeds up the test review process and supports better documentation.

9. Ensures System Stability During Initialization

When an ECU or full vehicle system powers up, it may briefly detect conditions that resemble faults. Without control, these might be wrongly stored as DTCs. The 0x85 service can prevent fault logging during startup sequences. This results in a more stable and accurate fault memory. It also avoids customer complaints due to false fault lights.

10. Essential for Secure ECU Updates and Reprogramming

Modern vehicles use secure bootloaders and encrypted firmware. Interruptions during these updates might appear as fault conditions. Disabling DTC logging during these sensitive operations using 0x85 avoids misleading logs. It also ensures that security-related functions aren’t incorrectly flagged. This is a critical step in safe and compliant ECU programming.

Syntax of 0x85 SID Request Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Control DTC Setting Request SID	0x85
#2	sub-function = [ DTC Setting Type ]	0x00 – 0xFF
#3 : #n	DTC Setting Control Option Record [] = [                              parameter#1                                     :                              parameter#m	0x00 – 0xFF : 0x00 – 0xFF

Request Message Data-Parameter

DTCSettingControlOptionRecord

This parameter is optional for users to transmit data to a server while managing the updating of DTC status bits. For example, it may include a list of DTCs that need to be turned on or off.

Syntax of 0x85 SID Positive Response Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Control DTC Setting Response SID	0xC5
#2	DTC Setting Type	00-7F

Response Message Data-Parameter

DTCSettingType

This parameter echoes bits 6 through 0 of the sub-function parameter from the request message.

Syntax of 0x85 SID Negative Response Message Frame Format

Data byte	Parameter Name	Byte Value
#1	Control DTC Setting Response SID	0x7F
#2	Requested SID [ byte#1 ]	0x85
#3	Negative Response Code [ byte#1 ]	NRC

Sub-Function ID of (0x85) SID in UDS Protocol

Bits 6 – 0	Description
0x00	ISO SAE Reserved This value is reserved by this document.
0x01	On The servers shall resume the updating of diagnostic trouble code status bits according to normal operating conditions
0x02	Off The servers shall stop the updating of diagnostic trouble code status bits.
0x03 – 0x3F	ISO SAE Reserved This range of values is reserved by this document for future definition.
0x40 – 0x5F	Vehicle Manufacturer Specific This range of values is reserved for vehicle manufacturer specific use.
0x60 – 0x7E	System Supplier Specific This range of values is reserved for system supplier specific use.
0x7F	SOSAE Reserved This value is reserved by this document for future definition.

Supported Negative Response Codes (NRCs) of 0x85 in UDS Protocol

NRC	Name	Description
0x12	sub-function Not Supported	This NRC shall be sent if the sub-function parameter is not supported.
0x13	Incorrect Message Length or Invalid Format	This NRC shall be sent if the length of the message is incorrect.
0x22	Conditions Not Correct	This is used when the server is engaged in critical normal mode activities and is thus unable to carry out the requested DTC control functionality.
0x31	Request Out of Range	The server will utilize this response code if it identifies an error in the DTC Setting Control Option Record.

Example of Control DTC Setting (0x85) Service in UDS Protocol

Following are the examples of Control DTC Setting (0x85) Service in UDS Protocol:

Example #1 – ControlDTCSetting (DTCSettingType = off)

Request Message Flow:

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ControlDTCSetting Request SID	0x85
#2	DTCSettingType = off, suppressPosRspMsgIndicationBit = FALSE	0x02

Positive Response Message Flow:

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ControlDTCSetting Response SID	0xC5
#2	DTCSettingType = off	0x02

Negative Response Message Flow:

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ControlDTCSetting –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x85
#3	Negative Response Code [ byte#1 ]	NRC

Example #2 – ControlDTCSetting ( DTCSettingType = on)

Request Message Flow:

Message Direction	Client → Server
Message Type	Request
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ControlDTCSetting Request SID	0x85
#2	DTCSettingType = on, suppressPosRspMsgIndicationBit = FALSE	0x01

Positive Response Message Flow:

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ControlDTCSetting Response SID	0xC5
#2	DTCSettingType = on	0x01

Negative Response Message Flow:

Message Direction	Server → Client
Message Type	Response
Data byte	Description (all values are in hexadecimal)	Byte Value
#1	ControlDTCSetting –Ve Response SID [ byte#1 ]	0x7F
#2	Requested SID [ byte#1 ]	0x85
#3	Negative Response Code [ byte#1 ]	NRC

// Below example shows how to use the UDS commands over the CAN data field as per the DoCAN
// Example for Positive Response for SID-0x85
Request: Client --> Server
02 85 01
Positive Response: Server --> Client
02 C5 01
// Example for Negative Response for SID-0x85
Request: Client --> Server
03 85 01
Negative Response: Server --> Client
03 7F 85 13

Example: Control DTC Setting (0x85) Service – UDS over CAN (DoCAN)

This section demonstrates how the Control DTC Setting (Service ID 0x85) works when transmitted over the CAN bus using UDS protocol as per ISO 14229. We’ll explain both positive and negative responses with byte-by-byte breakdown.

✅ Example of Positive Response:

Request: Client → Server
02 85 01

Response: Server → Client
02 C5 01

Breakdown of Request: 02 85 01

• 02 → This is the length byte. It tells that 2 more bytes follow (SID and sub-function).
• 85 → This is the Service ID (SID) for Control DTC Setting.
• 01 → This is the Sub-function to enable or disable DTC setting. 01 typically means “DTC Setting ON”.

Breakdown of Positive Response: 02 C5 01

• 02 → This is the length byte (2 more bytes to follow).
• C5 → This is the Positive Response SID. It’s formed by adding 0x40 to the original SID (0x85 + 0x40 = 0xC5).
• 01 → This is the same sub-function echoed back by the server to confirm success.

What it means: The ECU successfully received and executed the request to enable DTC logging.

❌ Example of Negative Response:

Request: Client → Server
03 85 01

Response: Server → Client
03 7F 85 13

Breakdown of Request: 03 85 01

• 03 → Indicates 3 bytes follow (SID, sub-function, and possibly more data).
• 85 → Service ID for Control DTC Setting.
• 01 → Sub-function: request to turn ON DTC setting.

Breakdown of Negative Response: 03 7F 85 13

• 03 → Length byte.
• 7F → This marks the beginning of a Negative Response.
• 85 → The original Service ID that caused the error (Control DTC Setting).
• 13 → The Negative Response Code (NRC): 0x13 means “Invalid Format”.

What it means: The ECU rejected the request because the message format was incorrect or unexpected (possibly due to length mismatch or invalid sub-function).

Summary of the Example:

Type	Message	Meaning
Request	02 85 01	Client requests to enable DTC logging
Positive Response	02 C5 01	Server confirms the DTC logging was enabled
Request	03 85 01	Client sends a potentially malformed request
Negative Response	03 7F 85 13	Server rejects with error: Invalid Format

Advantages of Control DTC Setting (0x85) Service in UDS Protocol

Following are the Advantages of Control DTC Setting (0x85) Service in UDS Protocol:

1. Avoids Logging of Temporary Faults: This service helps prevent the ECU from logging faults that are temporary or expected during testing, software flashing, or maintenance activities. It ensures that diagnostic logs are not cluttered with non-critical issues, maintaining a cleaner and more accurate DTC history. This is especially important during development when transient faults are common. Keeping the DTC log clean improves post-analysis. It avoids confusion for technicians who rely on DTCs for diagnostics.
2. Supports Accurate Diagnostics: When DTC logging is disabled during specific operations, it ensures that only genuine and relevant faults are recorded. This prevents misinterpretation of system behavior caused by non-permanent issues. It leads to faster root cause identification and better decision-making in service or development phases. Engineers can then focus on meaningful diagnostics. It ultimately enhances the quality of maintenance.
3. Essential During ECU Flashing and Updates: During ECU flashing or firmware updates, the system might behave unusually, which can trigger false DTCs. The 0x85 service allows you to suppress DTC logging during these sessions to avoid confusion post-update. This maintains the reliability of DTC records. It also reduces the need for clearing fault codes manually. This is essential in automotive production and service workflows.
4. Helps Meet Compliance Requirements: Some emission regulations require that only valid, persistent, and emission-related faults be logged. Using the 0x85 service strategically helps in meeting such regulations by excluding irrelevant faults. It ensures that vehicle compliance logs remain accurate. This is critical for homologation testing and audits. It contributes to regulatory and safety standard alignment.
5. Improves Development Workflow: Developers often induce faults on purpose to test system behavior. With 0x85, they can suppress fault logging temporarily to avoid false entries. This keeps DTC memory focused on real issues. It also helps in evaluating new features without interference from unrelated DTCs. This makes debugging and validation cleaner and more structured.
6. Prevents Fault Memory Overload: If every minor or expected error is logged, the DTC memory can fill up quickly. This service prevents that by allowing DTC logging to be turned off during non-critical activities. It ensures that important faults don’t get missed due to memory overflow. It also reduces unnecessary processing and storage overhead. This is particularly useful in low-resource ECUs.
7. Enhances Service Efficiency: Technicians can disable DTC logging while replacing, calibrating, or testing vehicle components. This avoids false fault entries during maintenance and improves the efficiency of service operations. It reduces time spent on clearing and verifying DTCs. The customer experience is improved due to fewer unnecessary warning lights. Service centers also benefit from faster workflows.
8. Allows Controlled Testing Scenarios: When components or subsystems are tested in isolation, unexpected behaviors may be expected. The 0x85 service can prevent these behaviors from being misinterpreted as faults. It allows for more accurate performance evaluation. It also ensures the test environment remains clean from irrelevant DTCs. This is valuable in both bench and in-vehicle testing setups.
9. Reduces Debugging Time: Clean and minimal DTC logs save engineers from sifting through irrelevant fault codes. The 0x85 service thus shortens debugging and analysis time during validation or troubleshooting. It leads to faster delivery of fixes and updates. Development cycles are more efficient with cleaner logs. It contributes to product quality and team productivity.
10. Protects Vehicle Stability During Updates: Boot-time or initialization glitches during updates may trigger false errors. Disabling DTCs during such events ensures that only real faults are logged, avoiding unnecessary error flags. This contributes to a stable system post-update. It also reduces user concerns triggered by unnecessary warning indicators. OEMs can deliver more polished firmware updates.

Disadvantages of Control DTC Setting (0x85) Service in UDS Protocol

Following are the Disadvantages of Control DTC Setting (0x85) Service in UDS Protocol:

1. Risk of Missing Critical Faults: If used carelessly, disabling DTC logging may prevent the recording of real and critical issues. This can delay detection of system failures and lead to unsafe vehicle behavior. It increases the chances of unresolved issues being left unnoticed. This could negatively affect both reliability and safety. Therefore, proper control and timing are crucial.
2. Potential Misuse by Unauthorized Tools: If access control is weak, unauthorized users or tools might disable DTC logging, hiding important faults. This poses a serious risk during diagnostics or service. It could lead to a vehicle being wrongly marked as fault-free. Ensuring robust access conditions is essential. Otherwise, it can compromise vehicle health monitoring.
3. Confusion During Post-Maintenance Analysis: If DTC logging is turned off and not re-enabled properly, important issues may not be recorded. Technicians may struggle to identify faults after maintenance. This leads to extended service times and misinterpretation. Documentation and proper process adherence are key. Otherwise, diagnostic accuracy suffers.
4. Complicates Regulatory Compliance: Regulations often require the recording of certain emissions or safety-related faults. If 0x85 is misapplied, the vehicle might not meet such requirements. This can result in compliance failures and legal implications. It’s particularly important for emissions-related systems. Misuse could also affect type approval.
5. Increases Dependency on Manual Handling: Since developers or service technicians must enable/disable this service manually or via script, human error becomes a risk. Forgetting to re-enable DTC logging can lead to major oversights. Automation may help, but it adds complexity. It also increases the need for technician training and awareness.
6. Reduces Fault Traceability: DTC logs serve as a crucial tool for historical fault analysis. Disabling logging during an important fault event removes a chance to trace its origin. This limits root cause investigation. It may also affect future analytics or machine learning models that rely on complete DTC data. Hence, data loss can reduce insight quality.
7. Not Always Supported by All ECUs: Some ECUs may not implement or fully support the 0x85 service, leading to inconsistent behavior across the vehicle. This makes diagnostics and testing workflows more complex. Developers need to check compatibility ECU by ECU. Otherwise, it results in unreliable or partial test coverage.
8. Potential for Permanent Suppression: If the DTC setting remains disabled longer than intended, faults during that period will go unrecorded. This leaves gaps in diagnostic history. It can be especially problematic in field vehicles. Long-term impacts could go unnoticed, affecting customer satisfaction and reliability metrics.
9. Requires Proper Session Management: This service often needs to be executed in a specific diagnostic session (e.g., extended or programming). Incorrect session handling can result in command rejection or ineffective execution. Managing sessions properly adds to development and testing complexity. Improper use could lead to unexpected behavior.
10. Adds to System Complexity: Introducing a service that selectively disables fault logging adds layers to the diagnostic architecture. Engineers must account for it in every testing or validation plan. It also increases test matrix size and potential failure points. This complexity must be carefully managed to prevent unintended side effects.

Future Development and Enhancement of Control DTC Setting (0x85) Service in UDS Protocol

Below are the Future Development and Enhancement of Control DTC Setting (0x85) Service in UDS Protocol:

1. Intelligent DTC Logging Control: Future implementations may include intelligent systems that automatically enable or disable DTC logging based on driving mode, environment, or fault criticality. This ensures fault logging is always meaningful and prevents unnecessary DTC entries during development or known non-critical events.
2. Enhanced Access Control Mechanisms: Upcoming UDS implementations could integrate role-based or multi-layered authentication for invoking the 0x85 service. This would prevent unauthorized access, securing the DTC setting functionality and ensuring that only certified diagnostic tools or OEM personnel can make changes.
3. Integration with Cybersecurity Standards: As vehicles become more connected, secure communication for DTC control will be essential. Future versions may support encrypted requests and responses aligned with AUTOSAR or ISO 21434 to safeguard diagnostic functions from remote or malicious access.
4. Event-Based DTC Enablement: Advancements may allow DTC logging to be automatically re-enabled after specific events like power cycles, vehicle sleep, or the end of a testing phase. This reduces the risk of forgetting to reactivate fault logging after temporary suspension during development or service.
5. Support for Logging State History: Future ECUs might record a timestamped log of when the DTC setting was changed using 0x85. This will help trace changes during testing or service and improve the transparency of diagnostics in production and post-market environments.
6. Adaptive Behavior Based on System Health: Advanced diagnostic stacks could adapt the DTC setting state based on real-time system health analysis. For example, logging could remain active for safety-critical modules but be disabled for non-essential subsystems during high-load development phases.
7. UI Integration in Diagnostic Tools: OEM diagnostic tools and testers may offer user-friendly visual controls with reminders, alerts, or auto-reset timers when the 0x85 service is used. This helps avoid long-term suppression of DTC logging due to human oversight and increases usability.
8. Automated Testing Frameworks Integration: Modern testing frameworks might include built-in support for toggling the DTC setting with validations, rollback mechanisms, and test-case-linked metadata. This ensures safe and efficient use of 0x85 in large-scale HIL or automated test setups.
9. Enhanced Feedback on DTC Setting Status: Future standards could mandate richer responses from the ECU after using 0x85, including active status, affected DTC groups, and the expected duration. This feedback would allow better tool-ECU synchronization and informed user decisions.
10. Compatibility with OTA and Cloud Diagnostics: As over-the-air updates and remote diagnostics grow, 0x85 may become part of cloud-connected workflows. This could enable remote toggling of DTC logging during software updates or fleet testing, with secure and traceable protocols.