Serves as an abstract base class for UDS transport plugins to transmit and forward diagnostic messages.
AI-GENERATEDunreviewedModel: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 8b34a053e223ProvenanceOpen questions (2)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original
Serves as an abstract base class for UDS transport plugins to transmit and forward diagnostic messages.
The abstract class serves UDS transport plugins as a base interface for standardized integration into adaptive Diagnostic Management (AUTOSAR_AP_SWS_Diagnostics §7.1.1 “Support of UDS Transport Layer”). A derived implementation forwards received diagnostic messages to the protocol manager and transmits generated response messages via network-specific channels to the diagnostic tester. The lifecycle is subject to a strict sequence of creation, separate initialization, asynchronous start, and orderly stopping ([SWS_DM_00329]). Following instantiation, operational method calls are not thread-safe and require coordinated control by the diagnostic core.
Context
The class apext::diag::uds_transport::UdsTransportProtocolHandler is an abstract base class within the module diag of the AUTOSAR Adaptive Platform. It defines the standardized interface through which proprietary or protocol-specific UDS transport plugins are connected to adaptive Diagnostic Management (DM) (AUTOSAR_AP_SWS_Diagnostics §7.1.1 “Support of UDS Transport Layer”, [SWS_DM_00315]). Each concrete transport protocol—for example for diagnostics via automotive network media—implements this interface as a derived subclass. The DM is likely to exclusively own and manage the respective handler instance throughout its entire operational lifecycle. Question Q-ef308265bfdf6cec (open) Interaction between the diagnostic core and the plugin takes place via the reference transportprotocolManager of type UdsTransportProtocolMgr&, which is passed in the constructor and stored protected ([SWS_DM_09015], [SWS_DM_09025]). Each handler is identified by a numerical UdsTransportProtocolHandlerID that can be queried via GetHandlerID() ([SWS_DM_00325]).
Lifecycle
The lifecycle of a UDS transport protocol handler is strictly controlled sequentially by the DM ([SWS_DM_00329]). Following instantiation via the constructor UdsTransportProtocolHandler ([SWS_DM_09015]), the method Initialize() separates the actual protocol initialization from object creation ([SWS_DM_00319]). Except for an optional query via GetPeriodicHandler(), the DM must not call any methods on the handler before the successful return of InitializationResult::kInitializeOk ([SWS_DM_01746], [SWS_DM_09017]). After successful initialization, calling Start() transitions the handler into the active processing state ([SWS_DM_00322]). To minimize startup time, Start() is designed as an asynchronous operation; the DM is likely to coordinate the parallel start of multiple handlers internally. Question Q-66e5a53d55e6d812 (open) If the DM transitions to the state ApplicationState.kTerminating during shutdown, it instructs the handler to terminate via Stop() ([SWS_DM_00323], [SWS_DM_00333]). The DM waits for completion, which the handler acknowledges by calling UdsTransportProtocolMgr::HandlerStopped() ([SWS_DM_00340]). After returning from Stop(), the plugin is prohibited from making any method calls to the manager except HandlerStopped() ([SWS_DM_01741]). Finally, release of resources takes place via the virtual destructor ([SWS_DM_09016]). While the constructor is thread-safe, the operational interface methods are declared not thread-safe.
During regular diagnostic operation, the handler processes incoming messages and transmits responses. As soon as at least source address, target address, address type (physical or functional), total message length, and, for multi-byte payloads, the first two bytes (payloadInfo) are available at the network interface, the implementation indicates the request to the manager via UdsTransportProtocolMgr::IndicateMessage() ([SWS_DM_00342], AUTOSAR_AP_SWS_Diagnostics §7.1.1.3 “UDS message transmission on a UDS TransportLayer”). Each request is assigned to a unique channel (AUTOSAR_AP_SWS_Diagnostics §7.1.1.4 “Channel Notifications”). To provide a response, the DM passes the diagnostic response to the same handler and channel using Transmit(message, channelId) ([SWS_DM_00327], [SWS_DM_00348]). Following physical transmission, the handler returns the passed message object to the manager via UdsTransportProtocolMgr::TransmitConfirmation() ([SWS_DM_00327], [SWS_DM_00351]). A specialized usage path involves ECU resets (UDS service 0x11) with a positive response after the restart: here, prior to the reset, the DM requests via NotifyReestablishment(channelId) that the handler preserve the connection information non-volatilely; following restart and renewed Start(), the handler indicates the restoration of the same channel via ChannelReestablished() ([SWS_DM_00326], [SWS_DM_01744]).
If initialization of the transport layer fails and Initialize() returns the status InitializationResult::kInitializeFailed, the DM immediately aborts the startup process of this protocol and does not call any further methods on this instance ([SWS_DM_01745], [SWS_DM_09017]). If periodic transmissions are not supported on the transport protocol, calling GetPeriodicHandler() returns a ara::core::Result with the error code kConfigurationMismatch ([SWS_DM_01068]). If a requested channel restoration for an ECU reset cannot be guaranteed, NotifyReestablishment() fails and signals this via the return value false ([SWS_DM_00326]). Finally, if the transmission process of a diagnostic response fails on the network layer, the handler must notify the manager during confirmation by setting the argument result in TransmitConfirmation() to kTransmitFailed ([SWS_DM_00351]).
This guide was generated automatically based on AUTOSAR specification R25-11.
Initializes UDS Transport Protocol handler. This methods needs to be called before a call of Start(). It is meant to separate the actual initialization of the UDS Transport Protocol handler from the constructor.
Tells the UdsTransportProtocolHandler, to notify the DM core via UdsTransportProtocol Mgr::ChannelReestablished() if the given channel has been re-established after next Uds TransportProtocolHandler::Start(). The main purpose of this method is to allow the DM to provide an ECU-Reset (0x11 service), with configuration option "positive response AFTER reset". In this scenario, the request for 0x11 will be received on a certain channel (GlobalChannel Identifier), then the ECU-Reset takes place and after ECU-Restart, all UdsProtocol Handlers/-plugins get restarted via call to UdsTransportProtocolHandler::Start().
Start processing the UDS Transport Protocol. Within the implementation there might be some stack specific implementation. The method is asynchronous to allow the DM to start multiple UdsTransportProtocolHandler in parallel to reduce startup time.
Method to indicate that this UdsTransportProtocolHandler should terminate. If UdsTransportProtocolHandler has stopped, it shall call UdsTransportProtocolMgr:: HandlerStopped(UdsTransportProtocolHandlerID).
If periodic transmissions are supported on this transport protocol, a reference to UdsTransportProtocolPeriodicHandler is returned, and if not supported, an error (kConfigurationMismatch).
Fehler
Fehlercode
Beschreibung
kConfigurationMismatch
Request a governed re-review of this record. The record is not changed immediately.
Initializes UDS Transport Protocol handler. This methods needs to be called before a call of Start(). It is meant to separate the actual initialization of the UDS Transport Protocol handler from the constructor.
AI-GENERATEDunreviewedModel: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 2d1a514affd8ProvenanceOpen questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original
The pure virtual method Initialize serves for the explicit initialization of an instance of apext::diag::uds_transport::UdsTransportProtocolHandler and formally separates this process from the construction of the object [SWS_DM_00319]. It is called synchronously and without parameters by the Diagnostic Manager (DM), throws no exceptions (noexcept), and returns a InitializationResult[SWS_DM_00319][SWS_DM_09017].
The method signals the result via the enumerator InitializationResult::kInitializeOk or InitializationResult::kInitializeFailed[SWS_DM_09017]. The further behavior of the DM depends directly on the return value:
Upon successful return with kInitializeOk, the DM may call subsequent methods of the handler; prior to this successful return value, no further method call is permitted with the exception of GetPeriodicHandler[SWS_DM_01746].
If the handler returns kInitializeFailed, the DM completely aborts the initialization process of this transport protocol and calls no further methods on the affected instance [SWS_DM_01745].
This text was generated by an AI based on AUTOSAR R25-11.
Tells the UdsTransportProtocolHandler, to notify the DM core via UdsTransportProtocol Mgr::ChannelReestablished() if the given channel has been re-established after next Uds TransportProtocolHandler::Start(). The main purpose of this method is to allow the DM to provide an ECU-Reset (0x11 service), with configuration option "positive response AFTER reset". In this scenario, the request for 0x11 will be received on a certain channel (GlobalChannel Identifier), then the ECU-Reset takes place and after ECU-Restart, all UdsProtocol Handlers/-plugins get restarted via call to UdsTransportProtocolHandler::Start().
Now there are two expectations, when this method has been called before and returned "TRUE": If the same remote client connects to the UdsProtocolHandler, it shall get a channel identification with the same identifying as the last time. It consecutively calls UdsTransportProtocolMgr::ChannelReestablished(Global ChannelIdentifier).
The detection/decision, whether the "same" client reconnects as before is an UdsProtocol Handler implementation specific decision.
The general expectation is:
If the channel is set up from exactly the same remote network-endpoint, it typically gets the same ChannelID. To support this functionality, the implementation at least has to store non-volatile, that this notification has to be done. Further it might be needed to store some additional connection specific info non-volatile to make sure, that the same ChannelID can be reassigned. This is the case if the mapping of protocol specific channel info -> channelID isn’t a
stable bijective mapping!
Small example:
The underlying network protocol, which UdsProtocolHandler implements is based on TCP. At the point in time, where the 0x11 Service Identifier request is received on channel identified by the DM calls UdsTransportProtocolHandler::NotifyReestablishment() on this ChannelID.
Now the implementation of UdsProtocolHandler stores non-volatile in the context of this call:
• NetworkEndpoint (IP-address and port number) of the channel. • NetworkEndpoint (IP-address and port number) of the local port (because in this example, the UdsTransportProtocolHandler listens on/supports different ports). • ChannelID it has currently assigned. After restart this ChannelID is only reused for a channel with exactly the same Network Endpoint addresses as stored non-volatile.
If this ChannelID then gets reassigned, then UdsTransportProtocolMgr::Channel Reestablished() has to be called.
AI-GENERATEDunreviewedModel: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: 677bdfc28d3dProvenanceOpen questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original
The method NotifyReestablishment is called synchronously by the Diagnostic Manager (DM) if, in the context of an ECU restart (UDS service 0x11), a positive response is to be sent only after the restart has taken place ([SWS_DM_00326], [SWS_DM_00360]). The transport channel to be monitored is passed via the parameter channelId ([SWS_DM_00326]).
With the call, the transport protocol implementation is instructed to persistently save the monitoring request ([SWS_DM_00359]). After the restart of the system and the renewed start of the handlers, the protocol handler reports the re-availability of the channel asynchronously to the DM by means of [SWS_DM_00313] ([SWS_DM_00358]). The boolean return value signals with true that the notification request was accepted and can be fulfilled; otherwise, false is returned ([SWS_DM_00326]).
Regarding concurrency and error handling, the following applies:
The function is specified as not thread-safe; parallel calls must be synchronized by the caller ([SWS_DM_00326]).
To be able to identify the same channel after the restart, connection-specific endpoint data must be saved unless a stable bijective mapping exists ([SWS_DM_00326]).
This usage note was created by an AI based on the specification.
The channelID, whose re-establishment shall be notified to Uds TransportProtocolMgr
Rückgabewert
Typ
Beschreibung
bool
TRUE, if notification request is accepted and can be fulfilled, else FALSE
Hinweise: The UdsTransportProtocolHandler will call UdsTransportProtocolMgr::Channel Reestablished() after UdsTransportProtocolHandler::Start() is called and as soon as it detects that the remote client/tester is reachable again.
Request a governed re-review of this record. The record is not changed immediately.
Start processing the UDS Transport Protocol. Within the implementation there might be some stack specific implementation. The method is asynchronous to allow the DM to start multiple UdsTransportProtocolHandler in parallel to reduce startup time.
AI-GENERATEDunreviewedModel: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: b5781ddbed6cProvenanceOpen questions (1)
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original
Method Start of interface apext::diag::uds_transport::UdsTransportProtocolHandler starts protocol processing of a UDS transport plugin in Diagnostic Management (DM) according to [SWS_DM_00322]. It takes no parameters and returns no value. Execution is designed to be asynchronous so that DM can start multiple instances in parallel and thus reduce the startup time of the overall system ([SWS_DM_00322]). Since the signature declares void, asynchronous processing is likely handled stack-specifically via internal background mechanisms. Question Q-d1023a05a1f3e2ab (open)
Preconditions: Prior to the call, initialization via Initialize ([SWS_DM_00319]) must have been completed with the result kInitializeOk ([SWS_DM_01746]). If initialization yields kInitializeFailed instead, DM aborts the procedure and must not call Start ([SWS_DM_01745]).
Postconditions: Only after Start has been called may DM trigger downstream functions such as Transmit or Stop on the handler ([SWS_DM_01743]). In addition, DM processes notifications via ChannelReestablished ([SWS_DM_00313]) exclusively if Start was executed beforehand ([SWS_DM_01744]), which is essential, among other things, for ECU reset scenarios with reconnection ([SWS_DM_00326]).
The method is declared as noexcept and thus exception-safe, but explicitly specified as not thread-safe (not thread-safe) ([SWS_DM_00322]). Callers must therefore ensure that instance calls occur synchronously.
This usage note was automatically generated based on the specification data.
Method to indicate that this UdsTransportProtocolHandler should terminate. If UdsTransportProtocolHandler has stopped, it shall call UdsTransportProtocolMgr:: HandlerStopped(UdsTransportProtocolHandlerID).
After return from Stop(), the handler-plugin shall NOT call to UdsTransportProtocolMgr with any other method but UdsTransportProtocolMgr::HandlerStopped().
AI-GENERATEDunreviewedModel: gemini-3.8-flash-medium · Effort: medium · Temperature: not controllable · Prompt: e507b828b86bProvenance
translated from the German guidegemini-3.8-flash-low · 2026-10-13 · German original
The method Stop of the interface apext::diag::uds_transport::UdsTransportProtocolHandler signals to a UDS transport protocol instance that it should terminate [SWS_DM_00323]. The call is triggered by Diagnostic Management (DM) as soon as it transitions to the state ApplicationState.kTerminating[SWS_DM_00333]. The function takes no parameters, has no return value, is declared as noexcept, and is specified as exception-safe (exception safe) [SWS_DM_00323].
The following conditions apply to the call context and concurrency:
Concurrency: The operation is specified as not thread-safe (not thread-safe) [SWS_DM_00323].
Call restriction: After returning from Stop, the handler plugin must not call any further methods on apext::diag::uds_transport::UdsTransportProtocolMgr, with the sole exception of the acknowledgment HandlerStopped[SWS_DM_01741][SWS_DM_00323].
Interaction with the DM occurs asynchronously: After the handler has terminated its network connections and released resources, it must notify the DM via apext::diag::uds_transport::UdsTransportProtocolMgr::HandlerStopped while passing its handlerId[SWS_DM_00314]. After calling Stop, the DM strictly waits for this confirmation callback before finally terminating the process [SWS_DM_00340].
This text was generated automatically based on the AUTOSAR Adaptive R25-11 specification.
Regarding ordering and lifecycle, the Diagnostic Manager must not call Transmit until initialization of the handler with kInitializeOk has been completed ([SWS_DM_01746]) and method Start has been called ([SWS_DM_01743]). Since the operation is specified as not thread-safe and exception safe ([SWS_DM_00327]), coordination of parallel transmit requests is, according to interpretation, likely required to take place on the caller side in the Diagnostic Manager. Question Q-6edd917928b60e55 (open)
The function synchronously returns no value. The transport handler is required to return the message pointer asynchronously to the Diagnostic Manager via apext::diag::uds_transport::UdsTransportProtocolMgr::TransmitConfirmation after transmission ([SWS_DM_00327], [SWS_DM_00312]). Upon successful transmission at network level, the result kTransmitOk is reported, otherwise kTransmitFailed ([SWS_DM_00351]).
This usage note is based on the AUTOSAR Adaptive R25-11 specification.
The message to be transmitted as a UdsMessage::Ptr (unique_ptr style). UdsTransportProtocolHandler has to give back this Uds Message::Ptr via UdsTransportProtocolMgr::Transmit Confirmation() to signal, that it is done with this message.
channelId
Identification of channel on which to transmit.
Rückgabewert
Typ
Beschreibung
None
Hinweise: This transmit API covers T_Data.req of ISO 14229-2[25] Figure 2.
Request a governed re-review of this record. The record is not changed immediately.
The handler ID used by DM to identify this handler. This is just a number/identification given by the DM core, when instantiating a UdsTransportProtocolHandler instance, to be able to distinguish it from other handler-plugins or built-in UdsTransportProtocolHandler implementation(s).
transportProtocolMgr
Reference to UdsTransportProtocolMgr owned by this DM, with which UdsTransportProtocolHandler instance shall interact.
Request a governed re-review of this record. The record is not changed immediately.
gemini-3.8-flash-low· 2026-10-13 · German original