DEEP TECHNICAL CONTENT

Unified Diagnostic Services

Unified Diagnostic Services: UDS is the ISO 14229 diagnostic-service family and may be transported over CAN/ISO-TP, DoIP or other supported networks. The page also includes a worked example and measurement sequence.

6 concrete technical facts1 worked example4 sources

Technical frame

Unified Diagnostic Services: UDS is the ISO 14229 diagnostic-service family and may be transported over CAN/ISO-TP, DoIP or other supported networks. The page also includes a worked example and measurement sequence.

The technical values here expose the standard, protocol or physical relationship directly; model-specific service values are linked through the matching model/variant dossier.

The goal is not only to define the term but to let the reader calculate and interpret what the data means in a scan, scope or physical test.

Concrete technical facts

  • UDS is the ISO 14229 diagnostic-service family and may be transported over CAN/ISO-TP, DoIP or other supported networks.
  • 0x10 DiagnosticSessionControl, 0x22 ReadDataByIdentifier, 0x27 SecurityAccess, 0x2E WriteDataByIdentifier and 0x31 RoutineControl are common service identifiers.
  • For many services the positive-response SID is request SID + 0x40; a 0x22 request therefore receives 0x62 on success.
  • A negative response uses 0x7F + request SID + NRC.
  • A valid service can still be rejected when diagnostic session, security level or timing preconditions are not met.
  • UDS application behavior must be separated from CAN/DoIP transport faults.

Worked example

  • Example: a tester sends 22 F1 90 to read a DID; success starts 62 F1 90 … . If 7F 22 31 is returned, NRC 0x31 indicates request-out-of-range logic rather than a physical bus fault.

Data-structure example

22 F1 90 -> 62 F1 90 ...
7F 22 31 -> negative response, NRC 0x31

Measurement and verification sequence

  • Capture exact request/response bytes.
  • Record diagnostic session and security state.
  • Measure P2/P2* timing and transport segmentation behavior.
  • Do not confuse an NRC with a physical-network fault.

Fault-separation logic

  • Is a valid command present and are power/ground/network healthy?
  • Does feedback follow the command?
  • Does an independent physical measurement confirm the output?
  • Is the fault limited to a specific temperature/load/speed condition?
  • Does the result remain stable when the original condition is repeated after repair?

Technical sources

  1. UNECE Vehicle Regulations / WP.29
  2. European Union vehicle type-approval framework
  3. AutoAtlas teknik editoryal sınıflandırması
  4. ISO standards catalogue · road vehicles

Continue investigating

Model-specific real technical data · Measurement references · Technical diagnostic atlas