UDS Architecture & Service Model - UDS Diagnostics

UDS ISO 14229 — Unified Diagnostic Services

Attribute	Detail
Standard	ISO 14229-1:2020 (core); ISO 14229-2 (transport); ISO 14229-3 (CAN); ISO 14229-5 (DoIP)
Scope	Application-layer protocol for ECU diagnostics: reading data, controlling actuators, managing DTCs, reprogramming firmware
Transport	ISO 15765-2 (CAN TP); ISO 13400-2 (DoIP/Ethernet); ISO 14229-4 (FlexRay); ISO 14229-6 (LIN)
Session model	Default Session (always available) → Extended Diagnostic Session → Programming Session (requires SecurityAccess)
Addressing	Physical (one ECU), Functional (broadcast to all ECUs matching service), 11-bit/29-bit CAN ID

💡 ISO 14229 vs OBD-II

UDS (ISO 14229) is the OEM/workshop protocol — manufacturer-specific DIDs, security-protected services, and reprogramming. OBD-II (ISO 15031 / SAE J1979) is the legally mandated emissions-related subset accessible to any generic tester without security. Both co-exist on the same CAN bus, served by the same ECU diagnostic stack, on different CAN IDs (OBD: 0x7DF functional; UDS OEM: OEM-specific physical IDs).

UDS Request/Response Model

UDS Request/Response Frame Structure

  Request frame (tester → ECU):
  ┌─────────┬──────────┬────────────────────────────┐
  │ Length  │ SID      │ Parameters                  │
  │ (TP)    │ 1 byte   │ Sub-function + data         │
  └─────────┴──────────┴────────────────────────────┘

  Positive response (ECU → tester):
  ┌─────────┬──────────┬────────────────────────────┐
  │ Length  │ SID+0x40 │ Response data               │
  │ (TP)    │ 1 byte   │ (SID echoed with bit 6 set) │
  └─────────┴──────────┴────────────────────────────┘

  Negative response (ECU → tester):
  ┌─────────┬──────────┬──────────┬──────────────────┐
  │ Length  │ 0x7F     │ SID      │ NRC (1 byte)      │
  │ (TP)    │ fixed    │ echoed   │ error code        │
  └─────────┴──────────┴──────────┴──────────────────┘

  Timing parameters (ISO 14229-2):
  P2: max tester wait for first response = 50 ms (default)
  P2*: max tester wait after NRC 0x78 (requestCorrectlyReceivedResponsePending) = 5000 ms
  S3: TesterPresent session keep-alive timeout = 5000 ms

UDS Service Identifier Reference

SID	Service	Session	Security
0x10	DiagnosticSessionControl	All	None
0x11	ECUReset	All	Level 1 in ExtendedDiag
0x14	ClearDiagnosticInformation	Extended/Programming	Level 1
0x19	ReadDTCInformation	All (sub-function dependent)	None for 0x19 0x02
0x22	ReadDataByIdentifier	All (DID-dependent)	None for standard DIDs
0x23	ReadMemoryByAddress	Extended	Level 1
0x27	SecurityAccess	Extended/Programming	N/A (is the auth service)
0x28	CommunicationControl	Extended	Level 1
0x29	Authentication	Extended/Programming	N/A (PKI-based)
0x2C	DynamicallyDefineDataIdentifier	Extended	Level 1
0x2E	WriteDataByIdentifier	Extended/Programming	Level 1+
0x2F	InputOutputControlByIdentifier	Extended	Level 1
0x31	RoutineControl	Extended/Programming	Level 1+
0x34	RequestDownload	Programming	Level 2
0x36	TransferData	Programming	Level 2 (implied)
0x37	RequestTransferExit	Programming	Level 2 (implied)
0x3E	TesterPresent	All	None
0x7F	NegativeResponse	N/A	N/A

ECU Diagnostic Stack Architecture (AUTOSAR)

Textdcm_stack.txt

AUTOSAR Diagnostic Stack Layers (bottom → top):

  Application SWCs (e.g., EcuM, BswM, NvM)
         ↕  Dcm_* callback functions (e.g., Dcm_ReadDataByIdentifier)
  ─────────────────────────────────────────────────────
  DCM  (Diagnostic Communication Manager)
       ├── Session and security state machine
       ├── Service dispatching (SID → handler)
       └── Response assembly and timing (P2, P2*, S3)
  ─────────────────────────────────────────────────────
  DEM  (Diagnostic Event Manager)
       ├── DTC storage, status byte, snapshot records
       └── Event reporting from application/MCAL
  ─────────────────────────────────────────────────────
  PduR (PDU Router)
       └── Routes diagnostic PDUs between DCM and ComM/CanTp
  ─────────────────────────────────────────────────────
  CanTp (CAN Transport Protocol — ISO 15765-2)
       └── Segmentation/reassembly of multi-frame UDS messages
  ─────────────────────────────────────────────────────
  CanIf / SoAd (CAN Interface / Socket Adapter for DoIP)
  ─────────────────────────────────────────────────────
  Physical: CAN / Ethernet

Summary

UDS ISO 14229 defines the application-layer protocol; transport is separately specified (ISO 15765-2 for CAN, ISO 13400 for DoIP). The session model gates service availability: most write and control services require Extended Diagnostic Session, and programming requires both Programming Session and a successful SecurityAccess exchange. In AUTOSAR, DCM owns session/security state and service dispatch; DEM owns DTC lifecycle; CanTp handles multi-frame segmentation. Understanding which layer handles which responsibility is the foundation for diagnosing any integration issue.

🔬 UDS Protocol Architecture — Layer by Layer

UDS (Unified Diagnostic Services, ISO 14229) is a client-server protocol built on top of a transport layer. Understanding the full stack is essential for implementing a robust diagnostic server:

Application layer (ISO 14229-1): Defines the service primitives (0x10–0x3E). Each service has a request PDU and a positive/negative response PDU. The negative response uses service ID 0x7F + original SID + NRC byte.
Session & Security layer (implicit in services 0x10, 0x27, 0x29): Sessions (Default, Programming, Extended) control which services are accessible. SecurityAccess (0x27) uses seed/key to unlock write operations. The session state is maintained per client connection using the S3Server timer (default 5 seconds — the session resets to Default if no request arrives within this window).
Transport layer (ISO 15765-2 / ISO 13400-2): ISO 15765-2 (ISO-TP) segments UDS messages over CAN frames. ISO 13400-2 (DoIP) carries UDS over Ethernet TCP connections. A single UDS ECUReset (0x11) command can traverse both layers simultaneously on a mixed-topology vehicle.
Addressing: Physical addressing targets one specific ECU. Functional addressing (broadcast) targets all ECUs simultaneously — used for TesterPresent (0x3E) keep-alive and EcuReset during flash programming. Functional addressing responses require careful suppression logic to avoid response collisions.

🏭 UDS in Workshop and Production Use

EOL programming line: At end-of-line (EOL) in the factory, every ECU is programmed via UDS in under 90 seconds. The sequence: enter Programming Session (0x10 0x02) → Unlock with SecurityAccess (0x27) → Erase flash (0x31 0xFF 00) → Download firmware (0x34/0x36/0x37 loop) → Verify CRC (0x31 0xFF 01) → Reset (0x11 0x01). Each step has a hard time budget.
Workshop ISTA / Star Diagnosis: BMW ISTA and Mercedes XENTRY use ISO 22900-2 (D-PDU API) to send UDS messages to ECUs via the VCI (Vehicle Communication Interface). Engineers using these tools expect exact NRC codes — returning 0x22 (conditionsNotCorrect) instead of 0x24 (requestSequenceError) confuses automated diagnostic scripts.
DoIP gateway: Modern vehicles use a DoIP gateway ECU (often the Central Gateway) that translates workshop Ethernet DoIP traffic to CAN ISO-TP towards internal ECUs. The DoIP activation line (pin 8 in OBD connector) must be active for the gateway to open the diagnostic channel — a common workshop connectivity mystery.

⚠️ UDS Implementation Pitfalls

S3Server timer not reset on busy response: A 0x78 (RequestCorrectlyReceivedResponsePending) response resets the P2* timer but does NOT reset the S3Server session timer. If a long operation sends many 0x78 responses over > 5 seconds without an intervening TesterPresent, the session drops and the operation fails mid-execution.
Using physical addressing for broadcast operations: Sending TesterPresent physically to 20 ECUs requires 20 separate requests. Using functional addressing (0xDF on CAN, broadcast target IP on DoIP) sends one request that all ECUs receive simultaneously. Missing this causes session timeout on ECUs that don't receive physical TesterPresent in time.
Wrong NRC for wrong reason: Returning NRC 0x31 (requestOutOfRange) when 0x22 (conditionsNotCorrect) is correct confuses automated diagnostic tools that use NRC to determine their retry strategy. Follow ISO 14229-1 Table 4 NRC conditions precisely.
Forgetting suppressPosRspMsgIndicationBit: Bit 7 of sub-function bytes indicates whether the ECU should suppress the positive response. Not handling this bit means the ECU always responds — doubling bus traffic during bulk TesterPresent broadcasts.

📊 Industry Note

AUTOSAR's DCM module implements UDS as a configurable BSW module. The DSD (Diagnostic Service Dispatcher) layer in DCM routes service IDs to callback handlers. In a properly configured AUTOSAR ECU, you should never need to write raw UDS framing code — only the application-layer callbacks (seed generation, DID read/write handlers) require custom implementation.

🧠 Knowledge Check — Click each question to reveal the answer

❓ What is the S3Server timer, what starts it, and what resets it?

✅ S3Server is a session inactivity timer on the ECU side (server). It starts when the ECU transitions out of the Default Session (into Extended or Programming Session). It resets on every diagnostic request received by the ECU (including TesterPresent 0x3E). If no request arrives within the S3Server period (default 5000 ms, configurable), the ECU transitions back to Default Session automatically. This is why automated testers must send TesterPresent every ~2 seconds during long operations.

❓ What is the difference between physical and functional addressing, and when must functional addressing be used?

✅ Physical addressing targets a single ECU by its unique diagnostic address (CAN ID or DoIP logical address). Functional addressing (broadcast) is received by all ECUs on the network. Functional addressing MUST be used for: (1) TesterPresent keep-alive to maintain sessions on multiple ECUs, (2) EcuReset during OTA programming where all ECUs must reset together, (3) ClearDiagnosticInformation on all ECUs simultaneously. Functional addressing must NOT be used for services that write data (0x2E, 0x34) — multiple ECUs writing simultaneously to conflicting addresses would be catastrophic.

❓ A UDS RequestDownload (0x34) returns NRC 0x70 (uploadDownloadNotAccepted). List three possible root causes.

✅ (1) The ECU is not in Programming Session (0x10 0x02) — the service is not accessible in Default or Extended session. (2) SecurityAccess (0x27) has not been successfully completed — the ECU rejects write operations while security is locked. (3) The memoryAddress or memorySize in the 0x34 request falls outside the configured downloadable flash region — the address range must exactly match the ECU's flash memory map as configured in the DCM/Bootloader ARXML.