UDS Diagnostics Interview Questions

UDS (Unified Diagnostic Services) is defined by ISO 14229. It provides a standardized set of diagnostic services for vehicle ECUs. ISO 14229-1 defines the service layer (request/response format), ISO 14229-2 defines session layer, ISO 14229-3 defines UDS on CAN (UDSonCAN), ISO 14229-5 defines UDS on IP (UDSonIP). UDS replaced KWP2000 and is the universal standard for automotive diagnostics in all modern vehicles.

Default Session (0x01): limited diagnostic services available after power-up. Programming Session (0x02): enables flash programming services. Extended Diagnostic Session (0x03): enables advanced diagnostics (writing parameters, I/O control). OEM-specific sessions (0x40-0x5F, 0x60-0x7E): vendor-defined additional sessions. Session changes via DiagnosticSessionControl (SID 0x10). Each session has defined service availability and timeout behavior (S3 timer for auto-reverting to default).

Request: [SID] [Sub-function/parameters...]. Positive Response: [SID + 0x40] [parameters...]. Negative Response: [0x7F] [SID] [NRC]. Example: TesterPresent request = [0x3E][0x00], positive response = [0x7E][0x00]. SID (Service Identifier) defines the service. Sub-function (bit 7 = suppress positive response flag). NRC (Negative Response Code) indicates why a request was rejected.

DiagnosticSessionControl (0x10), ECUReset (0x11), SecurityAccess (0x27), CommunicationControl (0x28), TesterPresent (0x3E), ReadDataByIdentifier (0x22), WriteDataByIdentifier (0x2E), RoutineControl (0x31), RequestDownload (0x34), TransferData (0x36), RequestTransferExit (0x37), ReadDTCInformation (0x19), ClearDiagnosticInformation (0x14), ControlDTCSetting (0x85), and InputOutputControlByIdentifier (0x2F).

Security access uses a seed-key (challenge-response) mechanism: 1) Tester sends RequestSeed (0x27, odd sub-function like 0x01). 2) ECU responds with a random seed. 3) Tester calculates key using the OEM's secret algorithm and seed. 4) Tester sends SendKey (0x27, even sub-function like 0x02, key bytes). 5) ECU verifies the key. If correct, the security level is unlocked. Failed attempts trigger a delay timer (security lockout). Multiple security levels can exist (0x01/0x02, 0x03/0x04, etc.).

A DID is a 2-byte identifier (0x0000-0xFFFF) that addresses a specific data item in the ECU. Standard DIDs: 0xF100 (Active Diagnostic Session), 0xF186 (Active Session), 0xF190 (VIN), 0xF187 (Spare Part Number), 0xF191 (Hardware Version). OEM-specific DIDs typically use ranges 0x0100-0xEFFF. DIDs are read via ReadDataByIdentifier (0x22) and written via WriteDataByIdentifier (0x2E). Each DID has defined read/write permissions per session and security level.

The DTC status byte (8 bits) tracks the diagnostic state: Bit 0 - testFailed (current test result). Bit 1 - testFailedThisOperationCycle. Bit 2 - pendingDTC (failed at least once this cycle). Bit 3 - confirmedDTC (fault confirmed, stored in memory). Bit 4 - testNotCompletedSinceLastClear. Bit 5 - testFailedSinceLastClear. Bit 6 - testNotCompletedThisOperationCycle. Bit 7 - warningIndicatorRequested (MIL on). These bits are managed by DEM in AUTOSAR.

SID 0x19 reads DTC information with various sub-functions: 0x01 - reportNumberOfDTCByStatusMask. 0x02 - reportDTCByStatusMask (list matching DTCs). 0x04 - reportDTCSnapshotRecordByDTCNumber (freeze frame). 0x06 - reportDTCExtDataRecordByDTCNumber. 0x09 - reportSeverityInformationOfDTC. 0x0A - reportSupportedDTC. The status mask parameter filters DTCs (e.g., 0x09 = confirmedDTC AND testFailed). This is the most complex UDS service.

Sequence: 1) DiagnosticSessionControl → Programming Session. 2) SecurityAccess to unlock programming level. 3) RoutineControl to erase flash. 4) RequestDownload (0x34) - specify memory address and size. 5) TransferData (0x36) - send data blocks with block counter. 6) RequestTransferExit (0x37) - finalize transfer. 7) RoutineControl to verify CRC. 8) ECUReset to restart with new software. The bootloader handles flash operations while application is inactive.

S3 (Session Timeout) timer runs in the ECU. After transitioning to a non-default session, if no diagnostic request is received within the S3 timeout (typically 5 seconds), the ECU automatically reverts to Default Session. The tester sends TesterPresent (SID 0x3E) periodically to keep the session alive. S3 prevents an ECU from being stuck in Programming or Extended session after the tester disconnects. The timer resets with every valid diagnostic request.

P2 (Server) is the maximum time the ECU can take to respond to a diagnostic request (typically 50ms). P2* (Server Extended) is the extended timeout used when the ECU sends a ResponsePending (NRC 0x78) - it tells the tester to wait longer (typically 5000ms). If the ECU needs more time (e.g., flash erase), it sends NRC 0x78, and the tester waits up to P2* for the actual response. P2/P2* values are communicated in the DiagnosticSessionControl positive response.

NRCs indicate why a service was rejected. Common NRCs: 0x12 - SubFunctionNotSupported. 0x13 - IncorrectMessageLengthOrInvalidFormat. 0x14 - ResponseTooLong. 0x22 - ConditionsNotCorrect (wrong state/mode). 0x24 - RequestSequenceError (e.g., download before erase). 0x31 - RequestOutOfRange (invalid DID/address). 0x33 - SecurityAccessDenied. 0x35 - InvalidKey. 0x36 - ExceededNumberOfAttempts. 0x72 - GeneralProgrammingFailure. 0x78 - RequestCorrectlyReceivedResponsePending.

Physical addressing targets one specific ECU using its unique diagnostic address (e.g., CAN ID 0x7E0 for engine ECU). Functional addressing broadcasts to all ECUs on the bus (CAN ID 0x7DF) - all ECUs that support the requested service respond. Functional addressing is used for: DTC reading across all ECUs, VIN reading, session control broadcast. Each ECU has both a physical request/response ID pair and listens to the functional ID.

CommunicationControl enables/disables specific communication types: Sub-function 0x00 - enableRxAndTx (normal). 0x01 - enableRxAndDisableTx (listen only). 0x02 - disableRxAndEnableTx. 0x03 - disableRxAndTx. Communication type parameter specifies: normal messages (0x01), NM messages (0x02), or both (0x03). Used during: flash programming (disable normal communication), vehicle assembly, and testing. Controlled per network channel.

ControlDTCSetting enables/disables DTC recording in the ECU. Sub-function 0x01 - ON (enable DTC recording). 0x02 - OFF (disable DTC recording). Used during: flash programming (to prevent false DTCs during download), production calibration, and testing. The ECU stops monitoring diagnostic events when disabled. Auto-reverts to ON when returning to Default Session or after power cycle. Essential to prevent false DTCs during service procedures.

RoutineControl executes predefined ECU-internal routines. Sub-functions: 0x01 - startRoutine. 0x02 - stopRoutine. 0x03 - requestRoutineResults. Each routine has a 2-byte Routine Identifier. Common routines: flash memory erase (0xFF00), CRC verification (0xFF01), check programming preconditions (0x0203), and OEM-specific routines (actuator tests, calibration procedures). Routines can be short (sync response) or long-running (async with result polling).

SID 0x2F controls ECU inputs/outputs for testing. Using a DID to identify the I/O, control options include: 0x00 - returnControlToECU (release override). 0x01 - resetToDefault. 0x02 - freezeCurrentState. 0x03 - shortTermAdjustment (set specific value). Example: override engine cooling fan speed, freeze dashboard brightness, simulate sensor value. Used in: production line testing, workshop diagnostics, and development. Active overrides must be releasable.

DoIP (ISO 13400) uses TCP/IP for diagnostic communication: TCP connection for reliable diagnostic data transfer, UDP for vehicle identification/announcement. DoIP adds: vehicle discovery (broadcast), routing activation (selecting target ECU via logical address), larger message sizes (no ISO-TP needed for most messages), faster throughput, and multi-client support. The UDS services (SID layer) are identical - only the transport changes. DoIP uses port 13400.

TesterPresent keeps a non-default diagnostic session alive by resetting the S3 timer. Request: [0x3E][0x00] (with response) or [0x3E][0x80] (suppress positive response - sub-function bit 7 set). The tester sends this periodically (typically every 2-3 seconds, well within S3 timeout of 5s). Without TesterPresent, the ECU reverts to Default Session. It's a zero-overhead keepalive - the suppress-response variant avoids unnecessary bus traffic.

ECUReset triggers an ECU restart. Sub-functions: 0x01 - hardReset (full power-cycle equivalent, re-initializes all hardware). 0x02 - keyOffOnReset (simulates ignition cycle). 0x03 - softReset (software restart without hardware re-initialization). Used after: flash programming (to start new software), configuration changes, and error recovery. The ECU sends a positive response before resetting. The tester must wait for the ECU to become responsive again.

Freeze frames (DTC Snapshots) capture ECU data at the moment a DTC is confirmed. They record relevant signal values (vehicle speed, engine RPM, temperature, etc.) that help diagnose the root cause. Stored alongside the DTC in DEM. Read via SID 0x19 sub-function 0x04. Each DTC can have one or more snapshot records. The data elements in the freeze frame are OEM-defined. Freeze frames are crucial for intermittent fault diagnosis.

After a configured number of failed SecurityAccess attempts (typically 3), the ECU enters a security lockout state. During lockout, further SecurityAccess requests are rejected with NRC 0x37 (RequiredTimeDelayNotExpired). The lockout timer is typically 10-30 seconds but can be hours for critical security levels. The counter and timer persist across power cycles (stored in NvM). This prevents brute-force attacks on the seed-key algorithm. After the timer expires, attempts reset.

ResponseOnEvent configures the ECU to autonomously report data when a specific event occurs, without the tester polling. Trigger types: DTC status change, timer-based, data change. Example: 'Notify me when DTC 0xC07300 status bit 0 changes to 1.' This reduces bus load compared to polling and ensures faster notification. The ECU stores the event configuration and sends responses when triggered. Less commonly implemented than other services.

Pending DTC (status bit 2 = pendingDTC): the fault has been detected at least once in the current operation cycle but hasn't met the confirmation criteria yet (e.g., failed in fewer than N consecutive cycles). Confirmed DTC (status bit 3 = confirmedDTC): the fault has met all confirmation criteria and is stored in permanent memory. Pending acts as an early warning. Pending DTCs that don't repeat are automatically cleared. Confirmed DTCs require explicit clearing or aging.

DTC aging automatically clears confirmed DTCs after a configured number of operation cycles (typically 40-200) where the fault does not recur. Each passing cycle increments the aging counter. When the counter reaches the threshold, the DTC is cleared from memory. The OBD regulation requires at least 40 warm-up cycles for emission DTCs. Aging prevents old, resolved faults from permanently filling diagnostic memory. Aging counter resets to 0 if the fault recurs.

Responses larger than the transport layer limit (7 bytes on CAN with ISO-TP) use the same segmentation mechanism as requests. The ECU sends a First Frame with total length, the tester responds with Flow Control (BS, STmin), and the ECU sends Consecutive Frames. Large responses are common with: SID 0x19 (DTC lists), SID 0x22 (large data blocks), and SID 0x36 (transfer data). On DoIP/Ethernet, segmentation is typically unnecessary.

OBD (On-Board Diagnostics): legally mandated, emission-related only, standardized services/PIDs, limited functionality (read DTCs, live data, clear DTCs), uses CAN ID 0x7DF/0x7E0-0x7E7. UDS: comprehensive diagnostic services, covers all ECU functions, OEM-customizable, includes programming/security/I/O control, uses OEM-defined CAN IDs. Modern ECUs support both - OBD for legal compliance and UDS for full diagnostics. OBD is a subset of what UDS can do.

Standard diagnostic IDs: 0x7DF - functional request (broadcast). 0x7E0-0x7E7 - physical request (specific ECU). 0x7E8-0x7EF - physical response (from specific ECU). Example: Engine ECU uses 0x7E0/0x7E8, Transmission uses 0x7E1/0x7E9. Extended addressing uses an additional address byte in the data field. Normal Fixed Addressing uses 29-bit CAN IDs with target/source address encoded. The addressing scheme is defined in ISO 15765-2 (for CAN transport).

Sub-function bit 7 (suppress positive response) tells the ECU not to send a positive response. This reduces bus traffic for services that don't need confirmation. Commonly used with: TesterPresent (0x3E 0x80), CommunicationControl, ControlDTCSetting. Negative responses are NEVER suppressed - if an error occurs, the ECU always responds. The tester sets bit 7 in the sub-function byte (e.g., 0x00 | 0x80 = 0x80).

SID 0x23 reads raw memory from a specific address in the ECU. The request contains: addressAndLengthFormatIdentifier (defines byte size of address and length fields), memoryAddress, and memorySize. Example: Read 4 bytes from address 0x80001000. Requires appropriate security access. Used for: development debugging, calibration data reading, memory dump analysis. WriteMemoryByAddress (SID 0x3D) is the corresponding write service.

Extended Data Records store additional diagnostic information alongside DTCs beyond freeze frames. Examples: occurrence counter (how many times fault occurred), aging counter, healing counter, time since last failed/passed, first/most recent failure timestamp, operating hours at failure. Record numbers: 0x01-0xEF (OEM-defined), 0xFE (all records). Read via SID 0x19 sub-function 0x06. OEMs define which records are stored per DTC.

SID 0x36 transfers data blocks between tester and ECU (after RequestDownload/RequestUpload). Request format: [0x36][blockSequenceCounter][transferData...]. The block counter starts at 0x01, increments to 0xFF, then wraps to 0x00. The ECU verifies: correct sequence number (detects missing/duplicate blocks), data length against expected block size, and CRC if applicable. Used for: flash programming, calibration data upload/download, and secure boot image transfer.

SID 0x83 reads or modifies diagnostic timing parameters: P2 (max response time), P2* (enhanced response time), S3 (session timeout). Sub-functions: readExtendedTimingParameterSet, setTimingParametersToDefaultValues, readCurrentlyActiveTimingParameters, setTimingParametersToGivenValues. Allows the tester to negotiate faster or slower response times based on the communication channel capabilities. Rarely modified in practice - default values usually suffice.

UDS is fundamentally single-client: one diagnostic session exists at a time. If a second tester sends a request while the first session is active, behavior depends on the ECU implementation. Typically, the new request either: gets NRC 0x22 (conditions not correct), or interrupts the existing session. DoIP supports multiple TCP connections but typically only one active diagnostic session. OEMs define priority rules for workshop tester vs. OTA diagnostic conflicts.

DynamicallyDefineDataIdentifier (SID 0x2C) creates temporary DIDs by combining parts of existing DIDs or memory addresses. Sub-functions: defineByIdentifier (combine existing DIDs), defineByMemoryAddress (read raw memory locations), clearDynamicallyDefinedDataIdentifier. The dynamically defined DID can then be read with normal SID 0x22, providing a customized data view. Useful for diagnostic monitoring of specific signal combinations during debugging.

SID 0x84 provides authenticated and encrypted diagnostic communication. The service wraps another UDS service's request/response with cryptographic protection (signature or encryption). This prevents: message tampering, unauthorized access without key material, and eavesdropping. Uses the ECU's security infrastructure (HSM, Crypto Stack). Particularly important for: remote diagnostics over unsecured networks, OTA updates, and security-critical services.

Key timeouts: S3 Server (session timeout, ~5s, reverts to default if no request received), P2 Server (~50ms, max time for positive/negative response), P2* Server (~5000ms, extended time after NRC 0x78), P3 Client (~2s max wait for response). AUTOSAR DCM manages S3 and P2 timers. The tester manages P3 timeout. TesterPresent (0x3E) prevents S3 expiration. Multiple NRC 0x78 responses reset P2* each time.

OEMs customize: DID definitions (specific data items per ECU type), Routine Identifiers (proprietary test routines), security algorithms (seed-key computation), session types (additional OEM-specific sessions 0x40-0x5F), NRC extensions (OEM-specific error codes 0xF0-0xFE), DTC definitions (OEM-specific trouble codes and freeze frame content), and service access rules (which services available in which session/security). These are documented in OEM diagnostic specifications.

LinkControl transitions the communication link to a different mode. Sub-functions: verifyModeTransitionWithFixedParameter, verifyModeTransitionWithSpecificParameter, transitionMode. Example: switch CAN communication from 500 kbit/s to 1 Mbit/s for faster flash programming, or activate CAN FD mode for higher throughput. The verify step confirms both tester and ECU support the target mode before the actual transition. Rarely used in practice.

DTCs are 3-byte identifiers (24 bits) in UDS: High byte - functional system (e.g., 0xC0 = Bus communication). Mid byte - sub-system/fault type. Low byte - specific fault condition. Example: 0xC07300 = CAN bus off. OBD DTCs use a different format (P0xxx, C0xxx, etc.) with a translation. ISO 14229 Annex D defines standard DTC format. OEMs maintain DTC databases mapping codes to fault descriptions, repair procedures, and affected systems.

Each UDS service has defined availability per session: Default Session - limited read-only services (ReadDTCInfo, ReadDataByID for public DIDs, TesterPresent). Extended Session - additional write services (WriteDataByID, IOControl, RoutineControl). Programming Session - flash programming services (RequestDownload, TransferData). Security Access further restricts within sessions. This layered access prevents unauthorized modifications while allowing basic diagnostics in all modes.

When DTC memory is full and a new DTC occurs, displacement may evict a lower-priority DTC. Priority is configured per DTC. Displacement criteria: priority (higher displaces lower), age (newer displaces older), and occurrence count. DEM evaluates these criteria to decide which DTC to evict. Critical DTCs (e.g., safety-related) can be configured as non-displaceable. OEMs typically allocate enough memory to avoid displacement for confirmed DTCs.

SID 0x14 clears DTCs and associated data. Request: [0x14][3-byte DTC group]. Group 0xFFFFFF clears all DTCs. Specific DTC groups clear subsets (e.g., 0xD00000 for body DTCs). Clearing resets: DTC status byte, freeze frames, extended data records, occurrence counters, and aging counters. Some DTCs may be marked as non-clearable (e.g., permanent emission DTCs until passing conditions are met). Requires extended session.

Sub-functions (byte immediately after SID): select the service variant (e.g., SID 0x19 sub-function 0x02 = reportDTCByStatusMask). Data parameters follow the sub-function and provide specific values (e.g., the status mask byte). Not all services have sub-functions - SID 0x22 (ReadDataByID) has no sub-function, just the DID directly. Sub-function bit 7 is reserved for suppress-positive-response. The distinction affects NRC handling.

Production line UDS usage: 1) WriteDataByIdentifier - write VIN, serial number, variant coding, production date. 2) RoutineControl - run actuator tests (motors, lights, valves), self-tests, calibration routines. 3) SecurityAccess - unlock production-level security. 4) InputOutputControl - verify I/O functionality (override outputs, read inputs). 5) ClearDTC - clear any assembly DTCs. 6) ReadDataByIdentifier - verify configuration. All automated through end-of-line test scripts.

Diagnostic requests from the OBD port reach the target ECU through a gateway. The diagnostic gateway (usually central gateway ECU) receives requests on the diagnostic CAN bus and routes them to the appropriate internal bus based on the target ECU's logical address. In DoIP vehicles, the gateway has an Ethernet connection to the OBD connector and routes to CAN/LIN sub-networks. ISO 14229-5 defines diagnostic routing via DoIP entity identification.

Enable conditions determine when DTC monitoring is active. Common conditions: engine running, vehicle speed above threshold, battery voltage in range, ECU initialized, no conflicting service active. If enable conditions are not met, the monitor doesn't run and DTCs aren't set - preventing false failures during startup, shutdown, or abnormal operating conditions. AUTOSAR DEM supports configurable enable condition groups per DTC or DTC group.

SID 0x2A configures the ECU to automatically send data at periodic intervals without tester polling. The tester specifies: periodic DID and transmission rate (slow/medium/fast, typically 10ms/25ms/100ms). The ECU sends responses using SID 0x6A (no request needed). Used for: real-time signal monitoring during testing, recording dynamic data. More efficient than repeated SID 0x22 reads for continuous monitoring.

Modern UDS (ISO 14229-1:2020) adds SID 0x29 (Authentication) supporting: PKI-based certificate exchange, challenge-response with asymmetric keys, and proof-of-ownership verification. This replaces the simple seed-key mechanism for higher security applications. The ECU verifies the tester's certificate against a root CA. This enables: OEM tool authentication, third-party tool authorization, and secure OTA update verification. Implemented using the AUTOSAR Crypto Stack.

SID 0x38 manages file operations on ECUs with file systems (typically Adaptive AUTOSAR or Linux-based ECUs). Operations: addFile, deleteFile, replaceFile, readFile, readDir. After initiating with SID 0x38, data transfer uses SID 0x36 (TransferData). This enables: software update package transfer, log file download, configuration file management. More flexible than memory-based transfer for complex ECUs with file-system storage.

UDS provides SID 0x19 sub-function 0x06 (ReadDTCExtendedData) and OBD Service $06 (Test Results) for detailed test results. Each test has: test ID, min/max threshold, actual value, and pass/fail status. Results are stored per DTC or per monitoring function. Workshop testers use these results to: assess repair effectiveness, verify sensor calibration, and identify borderline components. The data helps differentiate between hard failures and marginal behavior.

UDS provides the programming services for OTA: DiagnosticSessionControl (Programming), SecurityAccess/Authentication (authorize update), RoutineControl (verify preconditions, erase memory, verify CRC), RequestDownload/TransferData/RequestTransferExit (transfer new software). The OTA backend communicates with the vehicle's central gateway, which routes UDS commands to target ECUs. Additional OTA-specific logic handles: download scheduling, rollback, multi-ECU coordination, and resume after interruption.

ODX (Open Diagnostic Data Exchange, ISO 22901) describes ECU diagnostic capabilities in XML format: available services per session, DID definitions (format, scaling), DTC descriptions, security access parameters, flash sequences, communication parameters. PDX is the packaged (zipped) ODX format. Diagnostic tools (CANoe, vFlash) import ODX/PDX to know how to communicate with each ECU without hardcoded logic. Created in Vector CANdelaStudio or ODXStudio.

When transitioning between sessions: 1) Tester sends SID 0x10 with target session. 2) ECU validates the transition is allowed (some transitions require security access first). 3) ECU reconfigures: enables/disables services, adjusts timing parameters (P2/P2*), resets security access state (session change typically requires re-authentication). 4) ECU responds with positive response including new P2/P2* values. 5) S3 timer starts for the new session.

Event combinations combine multiple diagnostic events into a single DTC. Types: combined events (multiple monitors contribute to one DTC - the combined status is a logical OR or AND of individual event statuses) and dependent events (secondary DTCs that are only reported when a primary DTC is active). Example: 'Sensor plausibility error' DTC combines 'Signal range check' and 'Signal stuck' events. This reduces DTC count while maintaining diagnostic granularity.

Standard identification DIDs: 0xF100 - Active Session. 0xF10A - ECU Serial Number. 0xF186 - Active Diagnostic Session. 0xF187 - Spare Part Number. 0xF188 - ECU Software Number. 0xF189 - ECU Software Version. 0xF18A - Supplier ID. 0xF18B - ECU Manufacturing Date. 0xF18C - ECU Serial Number. 0xF190 - VIN. 0xF195 - Software Fingerprint. These DIDs are readable in Default Session without security access.

Snapshot (freeze frame): captures environment data AT THE MOMENT the DTC is confirmed - provides context (speed, RPM, temperature). Like a photograph of the system state. Extended data: accumulates OVER TIME - occurrence counter, aging counter, healing counter, timestamps, operation cycle count since last failure. Extended data provides the fault history. Both are stored per DTC in NvM and read via SID 0x19 with different sub-functions.

When the ECU cannot respond within P2 time (e.g., flash erase in progress), it sends NRC 0x78 (RequestCorrectlyReceivedResponsePending). This tells the tester: 'I received your request, I'm working on it, wait P2* time for the actual response.' The ECU can send multiple NRC 0x78 responses, each resetting the P2* timer. The tester must keep waiting. There's typically a maximum NRC 0x78 count (~100) to prevent infinite waiting.

Development: comprehensive testing of all services, edge cases, error handling, timing, and security. Uses tools like CANoe with automated test suites, manual exploratory testing. Focus on specification compliance. Production: focused on end-of-line functionality verification - can the ECU be programmed, does it respond correctly, are identification DIDs correct, do actuator tests pass. Production tests are automated, fast (seconds per ECU), and cover only essential checks.