Knowledge Base
Last Updated: 2026-08-10
UDS 0x10 DiagnosticSessionControl: Read 0x78, 0x50, and NRC Responses
A UDS 0x10 response proves only the matching response observed inside its approved, redacted evidence window. It does not prove later services, session longevity, or ECU root cause.
Common Diagnostic Misinterpretation
A 10 03 -> 50 03 exchange is an observed extended-session response, not a programming-session response and not proof that later diagnostics will succeed.
Evidence Summary
A visible 0x10 response, pending response, or missing outcome is being expanded into a session or ECU conclusion.
Observed
Approved redacted windows contain matching positive, pending, terminal-negative, bounded no-final, repeated-request, and interleaved-role observations.
Supported interpretation
10 03 -> 50 03 is an observed extended-session response; each response must be paired to its role and retained event window.
Not established
Later 0x22, 0x27, or 0x2E success; session persistence; ECU internal state; root cause; or transport topology.
Recommended next check
Pair the next service with its own response and retain transport evidence when the final outcome is absent.
Visual Evidence
These panels are reviewed, public-safe, role-based event summaries. They are not raw packet captures or screenshots.
Repeated Request: Relative Event Timeline
The same 10 83 request is observed twice with a DoIP acknowledgement each time. This is an observation, not a retry-cause or failure conclusion.
Evidence reference: EVID-UDS10-RETRY-01
Derived from: approved redacted role-based event sequence
Normalized by: DiagAgent
Original packet count: not published
Interleaved Logical Roles: Relative Event Timeline
Target A, Target B, and Target C each complete an interleaved 10 03 -> 50 03 exchange. The timeline does not imply separate IP or TCP flows.
Evidence reference: EVID-UDS10-INTERLEAVE-01
Derived from: approved redacted role-based event sequence
Normalized by: DiagAgent
Original packet count: not published
Wireshark Evidence Window: Extended Session Pending To Positive
Generated from the redacted bench sample for EVID-UDS10-PENDING-POS-01.
Evidence reference: EVID-UDS10-PENDING-POS-01
Derived from: approved redacted derived event window (four protocol events)
Normalized by: DiagAgent
Original packet count: not published; redacted derived window contains 13 packets
Wireshark Evidence Window: Direct Negative Response NRC 0x12
Generated from the redacted bench sample for EVID-UDS10-NRC-01.
Evidence reference: EVID-UDS10-NRC-01
Derived from: approved redacted derived event window (two protocol events)
Normalized by: DiagAgent
Original packet count: not published; redacted derived window contains 7 packets
Wireshark Evidence Window: Programming Session Pending To NRC 0x22
Generated from the redacted bench sample for EVID-UDS10-PENDING-NRC-01.
Evidence reference: EVID-UDS10-PENDING-NRC-01
Derived from: approved redacted derived event window (three protocol events)
Normalized by: DiagAgent
Original packet count: not published; redacted derived window contains 16 packets
Timeline
Read this as a role-based swimlane: it shows observed request/response order, not an unproven causal chain.
Observed: Approved redacted windows contain matching positive, pending, terminal-negative, bounded no-final, repeated-request, and interleaved-role observations.
Not established: Later 0x22, 0x27, or 0x2E success; session persistence; ECU internal state; root cause; or transport topology.
Next check: Pair the next service with its own response and retain transport evidence when the final outcome is absent.
Tester
Gateway / ECU
Evidence boundary
10 03 request -> ECU
<- 50 03 matching extended-session response
Later 0x22 / 0x27 / 0x2E outcome is not established
Pair each later request with its own retained response
Priority FAQ
Does a positive Service 0x10 response prove later services will work?
No. It proves only that the response was observed in the retained evidence window. Later authorization, transport, gateway, bus, and ECU behavior require separate evidence.
How should NRC 0x78 after Service 0x10 be recorded?
Record it as pending and continue the same correlation window. Do not treat it as final success, final failure, or proof that a final response will arrive.
Evidence Coverage
This public article uses ten approved, redacted evidence windows: seven reviewed historical windows and three controlled-bench cases. The public record preserves only the smallest role-based sequence needed for each teaching point.
- Positive pairings: 10 01 -> 50 01 and 10 03 -> 50 03.
- No-final observation: a 10 83 request with no final 0x50 or terminal 0x7F response in the retained window.
- Follow-up boundary: 10 03 -> 50 03 followed by an independent 0x22 request.
- Transport boundary: a completed 0x10 exchange and later TCP FIN are separate observations.
- Direct final-negative branch: 10 7F -> 7F 10 12.
- Pending-to-negative branch: 10 02 -> 7F 10 78 -> 7F 10 22.
- Repeated-request boundary: the same suppress-positive-response request is observed twice, each with a DoIP acknowledgement; this does not establish a retry cause or a missing response.
- Interleaving boundary: three independent logical targets complete 10 03 -> 50 03 exchanges in interleaved event order; this does not establish multiple IP addresses, TCP connections, or a concurrency fault.
- Pending-to-positive branch: 10 03 -> 7F 10 78 -> 7F 10 78 -> 50 03.
Evidence patterns
These summaries group approved records without extending what any individual window establishes.
Positive response observed
Problem signal: A positive 0x50 is treated as proof that later diagnostics will succeed.
Observed: Matching 10 01 -> 50 01 and 10 03 -> 50 03 pairs are observed.
Supported interpretation: The matching Service 0x10 positive response is observed in its retained window.
Not established: Later service success, session persistence, ECU state, or root cause.
Next check: Pair the next diagnostic service independently.
Evidence IDs: EVID-UDS10-POS-01, EVID-UDS10-POS-02, EVID-UDS10-FOLLOWUP-01
Pending or terminal-negative outcome
Problem signal: 0x78 is read as success or final failure.
Observed: Pending chains resolve to either 50 03 or a terminal NRC; direct terminal NRC is also observed.
Supported interpretation: 0x78 is pending and requires continued correlation to a final observed outcome.
Not established: The outcome before its final response is observed.
Next check: Follow the same logical request to a final response or a bounded observation end.
Evidence IDs: EVID-UDS10-PENDING-POS-01, EVID-UDS10-PENDING-NRC-01, EVID-UDS10-NRC-01
No final outcome / observation boundary
Problem signal: No observed final response is called ECU failure.
Observed: A suppress-positive-response request or a retained window can end without a final UDS response.
Supported interpretation: Only bounded absence in the retained window is established.
Not established: That the ECU failed, did not process a request, or did not respond outside the window.
Next check: Check capture completeness, transport state, and later response evidence.
Evidence IDs: EVID-UDS10-NOFINAL-01, EVID-UDS10-TRANSPORT-END-01
Correlation complexity
Problem signal: Nearby messages are paired by appearance alone.
Observed: Repeated 10 83 requests and three interleaved logical-target exchanges are observed.
Supported interpretation: Pairing requires role, direction, sub-function, and event order.
Not established: Retry motive, multiple IP/TCP flows, concurrency fault, or ECU behavior.
Next check: Reconstruct the role-based sequence before interpreting a response.
Evidence IDs: EVID-UDS10-RETRY-01, EVID-UDS10-INTERLEAVE-01
When This Article Applies
Use a minimal, redacted evidence window before diagnosing a session-control failure.
Evidence record details
Capture-Backed Evidence
Each example identifies whether it is a controlled simulator observation or a redacted field-evidence window. The evidence record bounds what the sequence can and cannot establish.
Positive Request/Response Pairing (Default Session)
Correlated Positive Response 0x50 01 Window
Evidence reference: EVID-UDS10-POS-01
A reviewed redacted window where a default-session request (10 01) receives a matching positive response (50 01) in role and event order.
Evidence signals
- Request SID 0x10 sub-function 0x01 observed.
- Matching positive response 0x50 01 returned within timing limits.
Real Timeline
- t0 | tester | SID 0x10 sub-function 0x01 | Default session control request.
- t0 + Δ | responder | SID 0x50 sub-function 0x01 | Correlated positive response observed.
Demonstrates valid request/response pairing when direction, sub-function, and timestamp order agree.
Independent Sub-function Positive Pairing (Extended Session)
Correlated Positive Response 0x50 03 Window
Evidence reference: EVID-UDS10-POS-02
A reviewed redacted window showing an extended-session request (10 03) paired with a matching positive response (50 03).
Evidence signals
- Request SID 0x10 sub-function 0x03 observed.
- Echoed positive response 0x50 03 returned.
Real Timeline
- t0 | tester | SID 0x10 sub-function 0x03 | Extended session control request.
- t0 + Δ | responder | SID 0x50 sub-function 0x03 | Correlated positive response observed.
Confirms sub-function level pairing precision across different session types.
No Final Response Observed in Retained Evidence Window
Unresolved Session Control Request Window
Evidence reference: EVID-UDS10-NOFINAL-01
A reviewed redacted window contains a suppress-positive-response session-control request (10 83), but no final 0x50 or terminal 0x7F response is observed before the window ends.
Evidence signals
- Request 10 83 sent.
- Retained capture window ends without an observed terminal response frame.
Real Timeline
- t0 | Tester | 10 83 | Session-control request with suppress-positive-response bit.
- window end | Evidence window | No final response observed | No final 0x50 or terminal 0x7F response is observed before the retained window ends.
Teaches bounded reporting: an unobserved response within a capture window is not proof of ECU internal failure.
Repeated Request Observation Boundary
Repeated Suppress-Positive-Response Request Window
Evidence reference: EVID-UDS10-RETRY-01
A reviewed redacted window shows the same suppress-positive-response request (10 83) twice in the same logical endpoint direction. A DoIP acknowledgement follows each request.
Evidence signals
- Two 10 83 requests are observed in role and event order.
- Each request has a corresponding DoIP acknowledgement.
- The suppress-positive-response bit means absence of 0x50 is not a failure conclusion.
Real Timeline
- Event 1 | Tester | 10 83 | Suppress-positive-response session-control request observed.
- Event 2 | DoIP entity | DoIP ACK | Transport acknowledgement observed for the first request.
- Event 3 (about 1.2 s later) | Tester | 10 83 | The same request is observed again.
- Event 4 | DoIP entity | DoIP ACK | Transport acknowledgement observed for the repeated request.
Establishes only that the identical request was observed twice. It does not prove tester retry motivation, a fault, a request timeout, or ECU behavior.
Interleaved Logical-Target Pairing Boundary
Interleaved Extended-Session Exchanges Window
Evidence reference: EVID-UDS10-INTERLEAVE-01
A reviewed redacted window shows three independent logical targets completing 10 03 -> 50 03 exchanges in interleaved event order.
Evidence signals
- Target A, Target B, and Target C each have a request and matching positive response.
- The three request/response pairs are interleaved by event order.
- Logical roles and sequence, not adjacency alone, establish each pairing.
Real Timeline
- Event 1 | Tester -> Target A | 10 03 | Extended-session request for Target A.
- Event 2 | Tester -> Target B | 10 03 | Extended-session request for Target B.
- Event 3 | Target A -> Tester | 50 03 | Positive response paired to Target A.
- Event 4 | Tester -> Target C | 10 03 | Extended-session request for Target C.
- Event 5 | Target B -> Tester | 50 03 | Positive response paired to Target B.
- Event 6 | Target C -> Tester | 50 03 | Positive response paired to Target C.
Shows that interleaved messages must be paired by logical role and order. It does not prove multiple IP addresses, multiple TCP connections, or an actual concurrency failure.
Follow-up Diagnostic Service as Independent Chain
Positive 0x50 Followed by Independent Service Window
Evidence reference: EVID-UDS10-FOLLOWUP-01
A reviewed redacted window shows a 0x50 positive response followed by an independent ReadDataByIdentifier request (0x22).
Evidence signals
- Session control 10 03 returns 50 03.
- Tester sends 22 F1 90 next.
Real Timeline
- t0 | Tester | 10 03 | Extended-session request.
- after response | Responder | 50 03 | Matching positive response observed.
- later | Tester | 22 F1 90 | Independent subsequent-service request.
Demonstrates that 0x50 proves session control exchange only; subsequent services require their own response pairing.
Transport Connection Termination Distinct from Diagnostic Result
DoIP TCP Session Termination Following 0x10 Exchange
Evidence reference: EVID-UDS10-TRANSPORT-END-01
A reviewed redacted window shows a completed session-control exchange and a later TCP FIN transport event.
Evidence signals
- 0x10 exchange captured.
- TCP FIN/ACK occurs at transport layer.
Real Timeline
- t0 | Tester | 10 01 | Default-session request.
- after request | Responder | 50 01 | Matching positive response observed.
- later | Transport | TCP FIN | Transport connection close; this is distinct from the UDS result.
Establishes that transport connection end (TCP FIN/RST) is a distinct event from UDS diagnostic session outcome.
Direct Final Negative Response to Session Control
Approved Sanitized NRC Window (7F 10 12)
Evidence reference: EVID-UDS10-NRC-01
Controlled bench capture where request 10 7F receives terminal negative response 7F 10 12 (SubFunctionNotSupported).
Evidence signals
- Request 10 7F sent by Tester-A.
- Terminal response 7F 10 12 returned by ECU-B.
Real Timeline
- Derived event 1 | Tester | 10 7F | Service 0x10 request in the approved redacted window.
- Derived event 2 | ECU | 7F 10 12 | Final negative response (SubFunctionNotSupported) observed.
Establishes this controlled final-negative branch only; it does not identify an ECU internal state.
Extended Session Pending Followed by Final Positive Response
Approved Sanitized Pending-to-Positive Window (7F 10 78 -> 50 03)
Evidence reference: EVID-UDS10-PENDING-POS-01
Controlled bench capture where extended session request 10 03 receives two pending responses (7F 10 78) before resolving to positive response 50 03.
Evidence signals
- The retained window records pending twice before the final positive response.
- 0x78 does not prove success or failure while it is pending.
- 0x50 does not prove later services or session longevity.
Real Timeline
- t0 | Tester-A | 10 03 | Extended session request.
- t0 + Δ1 | ECU-B | 7F 10 78 | Pending response observed.
- t0 + Δ2 | ECU-B | 7F 10 78 | Second pending response observed.
- t0 + Δ3 | ECU-B | 50 03 | Final positive response observed.
Demonstrates that pending must be followed to a final response.
Programming Session Pending Followed by Final Negative Response
Approved Sanitized Pending-to-NRC Window (7F 10 78 -> 7F 10 22)
Evidence reference: EVID-UDS10-PENDING-NRC-01
Controlled bench capture where programming session request 10 02 receives pending response 7F 10 78 before resolving to terminal negative response 7F 10 22.
Evidence signals
- Pending is observed before the terminal negative response.
- 0x78 does not prove that the exchange will finish positively.
Real Timeline
- t0 | Tester-A | 10 02 | Programming session request.
- t0 + Δ1 | ECU-B | 7F 10 78 | Pending response observed.
- t0 + Δ2 | ECU-B | 7F 10 22 | Final negative response (ConditionsNotCorrect) observed.
Shows that a pending response requires continued correlation and can end in a final negative response.
What These Cases Do Not Establish
This is the condensed engineering verdict the analyzer would put in front of the operator.
Boundary
A final 0x50 or 0x7F response establishes only that observed exchange.
Not established
Later service success, sustained session availability, ECU internal state, and root cause require separate evidence.
False Positives
These are cases where the tool symptom can point in the wrong direction unless the packet timeline is checked.
Symptom: A positive response is treated as proof of later diagnostic success.
Packet truth: Only the observed Service 0x10 response is established.
Risk: Later authorization, transport, and ECU failures are skipped.
Symptom: A missing final response is called an ECU failure.
Packet truth: The retained window may end before a response or omit relevant transport data.
Risk: The fault is over-located without gateway and bus evidence.
Decision Tree
Use this order in real troubleshooting so packet evidence narrows the branch before repair effort expands.
- 1. Identify the Service 0x10 request and its session window.
- 2. Correlate only matching response or pending frames.
- 3. Separate a final observed response from a missing observation.
- 4. Check transport state and later services before assigning a fault location.
Protocol Scope
UDS DiagnosticSessionControl (Service 0x10) is the application-layer service used to select diagnostic sessions. ISO 14229-1 defines the UDS application layer; AUTOSAR's Diagnostic Communication Manager specification describes Service 0x10 session handling.
OEM configuration determines supported session types and access conditions. Do not turn a decoded request or response into a claim about undocumented vehicle behavior.
Pair a Request with Its Response
Correlate source and target roles, service identifier, transport session, frame order, and the retained observation window. Do not pair a request with the next similarly shaped frame from another session or retry.
A positive response is an observed response event. It does not prove that later diagnostic operations completed or that the session stayed available.
Pending and Missing Outcomes
A negative response for Service 0x10 and NRC 0x78 are not terminal-positive results. Follow the same request family until a terminal response, transport teardown, or the end of the retained window.
When a final response is absent, record it as not observed within the retained evidence window and check capture loss, display filtering, and TCP session closure.
Public References
ISO 14229-1:2026, Road vehicles — Unified diagnostic services (UDS) — Part 1: Application layer: https://www.iso.org/standard/87962.html
AUTOSAR Specification of Diagnostic Communication Manager, Service 0x10 — Diagnostic Session Control: https://www.autosar.org/fileadmin/standards/R18-10_R4.4.0_R1.5.0/CP/AUTOSAR_SWS_DiagnosticCommunicationManager.pdf
More Frequently Asked Questions
Why might the same 0x10 request appear multiple times?
Retries, reconnects, concurrent diagnostic clients, and capture boundaries can create similar frames. Match transport session and timing before treating frames as one exchange.
Related Diagnostic Guides
Use nearby guides to move from protocol filtering to root-cause troubleshooting without leaving the knowledge base.