Protocol Fundamentals
Module 2 of 5 · 2 lessons · ~27 min · ← Back to Learning Hub
Lesson 1: UDS Message Structure
Every UDS message follows a simple, predictable structure. Understanding this structure is the foundation of all UDS work.
Basic Request Format
Every UDS diagnostic frame begins with a standardized request layout. Select any segment in the interactive framing inspector below to inspect byte boundaries, sub-function behavior, and payload sizing rules:
Service Identifier (SID)
0x10 / 0x22 / 0x27Mandatory 1-byte identifier (0x00–0xFF) selecting the diagnostic service to execute.
💡 Implementation Note: Common services: 0x10 (Session Control), 0x22 (Read Data), 0x27 (Security Access), 0x3E (Tester Present).
Components
1. SID (Service Identifier) — 1 byte
- Identifies which diagnostic service to execute
- Range: 0x00–0xFF
- Examples: (Session Control), (Read Data), (Security Access)
2. Sub-Function — 1 byte (service-dependent)
- Service-specific parameter
- The high bit (bit 7) can be set to suppress the positive response
- Example: For SID , sub-function = Extended Diagnostic Session
3. Data Bytes — variable length
- Additional parameters specific to the service
- Can be 0 bytes (e.g., SID 0x3E Tester Present) up to many bytes (e.g., firmware blocks)
Response Formats
The ECU returns one of two standardized response formats depending on whether service prerequisites and parameters are satisfied. Explore the interactive byte mapping and error state decoders below:
Service Execution Acknowledged
When the ECU validates all prerequisites and successfully executes the requested diagnostic service, it returns Byte 0 with Bit 6 forced high (+0x40) followed by dynamic response data.
Service Rejection / Exception State
When a request cannot be processed due to format errors, conditions, security lockouts, or unsupported services, the server returns universally 3 bytes: NRC Service ID (0x7F), original SID, and NRC.
Frame Examples
| Operation | Request | Response |
|---|---|---|
Enter Extended Session | ||
Read VIN | 62 F1 90 57 56 57... (17 VIN bytes) | |
Request Security Seed | ||
Tester Present | ||
Error: wrong length | (incomplete) |
Multiple DID Read (SID 0x22)
SID 0x22 allows reading multiple Data Identifiers in a single concatenated request, reducing bus round-trips. Explore the byte decomposition below to see how multiple DIDs and variable-length payloads are formatted and parsed:
Suppress Positive Response
Setting bit 7 (0x80) of the sub-function byte instructs the server to execute the request without transmitting a positive response frame. This significantly optimizes CAN/DoIP bus bandwidth during high-frequency keep-alives or repetitive routine monitoring:
RESPONSE_SUPPRESSION_LOGIC
Active Bit 7 (0x80) detection. When present in the sub-function byte, the ECU enters Silent Mode for positive responses, optimizing packet throughput.
!Critical: NRC 0x7F bypasses suppression logic and will always broadcast.
Negative Response Codes (NRCs)
| NRC | Name | Meaning |
|---|---|---|
generalReject | Request rejected for unspecified reason | |
serviceNotSupported | SID not implemented in this ECU | |
subFunctionNotSupported | Sub-function not valid | |
incorrectMessageLengthOrInvalidFormat | Wrong byte count | |
conditionsNotCorrect | Prerequisites not met (wrong session, etc.) | |
requestSequenceError | Out-of-order operation | |
requestOutOfRange | Parameter outside valid range | |
securityAccessDenied | Security not unlocked | |
invalidKey | Wrong security key | |
exceededNumberOfAttempts | Too many failed security attempts | |
requiredTimeDelayNotExpired | Must wait before retrying | |
requestCorrectlyReceivedResponsePending | ECU needs more time — not an error | |
subFunctionNotSupportedInActiveSession | Valid sub-function, wrong session | |
serviceNotSupportedInActiveSession | Valid service, wrong session |
Key Takeaways
- UDS messages follow SID + sub-function + data bytes structure
- Positive responses add to the request SID
- Negative responses always start with followed by SID and NRC
- NRC (Response Pending) is informational, not an error
- Bit 7 of sub-function suppresses the positive response
Lesson 2: Timing Parameters
UDS defines precise timing parameters that govern how quickly the ECU must respond and how long a diagnostic session can remain idle.
P2 — Standard Response Time
Definition: Maximum time from the end of a client request to the start of the ECU’s response.
- Default: 50 ms ()
- Reported in: Session Control (0x10) positive response, bytes 2–3
- Purpose: Ensures timely response for normal synchronous operations
If the ECU cannot respond within P2, it must send NRC (Response Pending) to extend the window.
P2* — Enhanced Response Time
Definition: Extended response window granted after the ECU sends NRC .
- Default: 5000 ms — encoded at 10 ms resolution ( = 500 units × 10 ms)
- Reported in: Session Control positive response, bytes 4–5
- Purpose: Allows time for long operations: flash erasure, memory programming, complex routines
- Usage: The ECU may send multiple NRC responses, each one resetting the P2* clock
S3 — Session Timeout
Definition: Maximum idle time before the ECU automatically returns to the Default Diagnostic Session.
- Typical: 5000 ms (5 seconds)
- Reset by: Any valid UDS request (including Tester Present 0x3E)
- Purpose: Safety mechanism — ensures the ECU returns to a safe state if the tester disconnects or crashes
Timing in Practice
Diagnostic communications rely on deterministic timing boundaries. Explore the interactive latency visualizer below to toggle between the byte decoder and the live CAN bus transaction timeline:
Standard server response timeout (1 ms resolution)
Reading Timing from the Session Response
When you send (Enter Extended Session), the ECU positive response () explicitly declares its active timing parameters:
- → P2 = 50 ms (0x0032 in 1 ms units).
- → P2* = 5000 ms (0x01F4 = 500 units × 10 ms).
Maintaining Sessions with Tester Present
To prevent S3 timeout during long user interactions or diagnostic delays, send Tester Present periodically:
- : Standard Tester Present (server responds with ).
- : Suppressed Tester Present (server resets S3 watchdog silently without transmitting a response, preserving bus bandwidth).
Best practice: Transmit every 2–3 seconds when maintaining any non-default diagnostic session.
Key Takeaways
- P2 (50 ms) is the standard response window for most operations
- P2* (5000 ms) is the extended window triggered by NRC
- P2* is encoded at 10 ms resolution in the session response
- S3 (5000 ms) is the session idle timeout — send Tester Present to keep sessions alive
- These values are ECU-specific and reported in the SID 0x10 response
Next Steps
Continue to Core UDS Services for detailed coverage of Session Control, Security Access, and DTC reading.