Most embedded engineers encounter UDS from the ECU side, implementing the server that responds to diagnostic requests from a tester. But UDS client development, building the tester itself, is equally important and equally complex. Automated end-of-line programming tools, HIL test benches, production flash programming applications, and OTA orchestration backends all require a UDS client implementation that can reliably initiate diagnostic sessions, sequence service calls correctly, handle response timing, and manage security access across one or many ECU targets simultaneously.
UDS Client vs Server: Architectural Differences
| Dimension | UDS Server (ECU) | UDS Client (Tester) |
|---|---|---|
| Role | Responds to service requests | Initiates service requests |
| Session management | Accepts session change requests | Tracks active session state |
| Timing | Enforces P2 response timing | Manages P2 timeout and retries |
| Security access | Provides seed, validates key | Generates key from seed |
| Multi-target | Typically single instance | Often manages multiple ECUs |
| Typical platform | Embedded MCU | PC, gateway, domain controller |
| Common use | Production ECU | Test tool, EOL programmer, HIL bench |
Session Management in a UDS Client
A UDS client must correctly manage diagnostic session state across the full sequence of operations it performs on a target ECU. Three standard sessions are defined in ISO 14229: default session (0x01), programming session (0x02), and extended diagnostic session (0x03). A typical ECU reprogramming sequence requires ordered session transitions, from default to extended diagnostic to disable normal communication, then to programming session to unlock flash services, and finally a hard reset after programming completes.
Maintaining session validity requires the client to send TesterPresent (0x3E) messages at intervals shorter than the server's session timeout, typically every two to three seconds. A UDS client that loses track of session state or misses TesterPresent timing will encounter NRC 0x7F or NRC 0x22 responses, requiring graceful recovery rather than aborting the operation.
Security Access Implementation
Security access (service 0x27) is the mechanism by which a UDS client proves authorisation to access restricted diagnostic services, most critically, flash programming and ECU reset. The standard challenge-response sequence involves the client sending a RequestSeed request, receiving a seed from the server, computing the correct key using a shared algorithm, and returning the key in a SendKey request.
Security access delay timers are another client-side concern. ISO 14229 allows the server to impose a delay after a configurable number of failed key attempts. A robust UDS client must handle NRC 0x37 (RequiredTimeDelayNotExpired) by waiting for the specified delay before retrying, rather than immediately incrementing the failed-attempt counter further.
Response Timing and Error Handling
UDS timing management is where many client implementations fall short. The standard defines P2 as the maximum time between a client request and the server's first response. When a server needs more time, it returns NRC 0x78 (RequestCorrectlyReceived-ResponsePending) and starts P2* timing, during which the client must continue waiting rather than treating the absence of a positive response as a timeout.
A production UDS client must handle the full NRC response matrix gracefully: retryable conditions like NRC 0x21 (busyRepeatRequest) and NRC 0x78 (responsePending), versus terminal conditions like NRC 0x35 (invalidKey) and NRC 0x24 (requestSequenceError) where the sequence cannot continue without client-side recovery action.
Flash Programming Sequence in Detail
ECU flash programming is the most demanding UDS client use case, a multi-step sequence combining multiple services with strict ordering, timing, and error recovery requirements. The standard sequence involves ECU pre-conditions check via ReadDataByIdentifier, session transitions into programming session, security access, routine control to erase flash, request download to specify target memory address and length, a series of transfer data calls to stream the firmware payload, request transfer exit to complete the transfer, and a final routine control to verify the programmed image checksum.
Partial flash programming, where erase succeeded but transfer failed partway, is the most dangerous outcome and must be handled by any client supporting unattended or over-the-air programming.
Implementing a UDS Client with RAPIDSEA
RAPIDSEA's UDS stack supports both server and client modes under a single royalty-free licence. The client-mode implementation delivers complete ISO 14229 service initiator support, configurable P2 and P2* timeout management, session state tracking with automatic TesterPresent maintenance, security access key generation interface with pluggable algorithm support, and multi-connection management enabling simultaneous diagnostic sessions with multiple ECU targets.
Transport layer support covers ISO-TP over CAN and CAN-FD for DoCAN, and UDP/TCP over automotive Ethernet for DoIP, enabling the same client application code to target ECUs across both transport types. The client stack runs on both embedded platforms and PC platforms under Windows and Linux, supporting the full range of UDS client deployment contexts from production-line programming tools to integrated vehicle diagnostic masters.
Conclusion
Building a UDS diagnostic client correctly requires careful attention to session state management, security access timing, response code handling, and transport-layer multiplexing. For teams building automated test tools, EOL programmers, or integrated gateway diagnostic masters, starting with a production-validated UDS client stack avoids the most common implementation pitfalls and compresses what is otherwise a multi-month development effort.
RAPIDSEA's dual-mode UDS stack, server and client in a single, MISRA-C compliant source package, gives teams a validated foundation for both ECU diagnostic implementation and the tooling that tests it, under a single royalty-free license.
Ready to build your UDS diagnostic client with RAPIDSEA? Contact our team to request an evaluation build or book a technical demo.