class apext::diag::uds_transport::UdsTransportProtocolMgr

use

The method ChannelReestablished of class apext::diag::uds_transport::UdsTransportProtocolMgr serves as feedback from a UDS transport protocol implementation to Diagnostic Management (DM) that a communication channel is available again after a (re-)start [SWS_DM_00313]. The transport protocol implementation calls this method exactly once as soon as the re-availability of the network channel represented by ChannelID is detected [SWS_DM_00358]. As a parameter, globalChannelId is passed, consisting of the tuple of own handlerIdent and the ChannelID [SWS_DM_00358].

Interaction and Lifecycle

A prerequisite for the notification is a preceding call of NotifyReestablishment [SWS_DM_00313], [SWS_DM_00356]. A typical use case is performing an ECU reset (UDS service 0x11) with the option of a positive response after the restart [SWS_DM_00326]. In order to ensure notification even after a restart of the DM, the notification request must be persistently stored by the transport protocol [SWS_DM_00359].

Error Handling and Concurrency

The function has no return value and is specified as noexcept (exception safe) [SWS_DM_00313]. Since the interface is classified as not thread-safe (not thread-safe) [SWS_DM_00313], calling handlers might have to synchronize access externally. Question Q-aaf14893457cceb6 (open) As a timing constraint, the DM may process the call to ChannelReestablished only after the call to UdsTransportProtocolHandler::Start [SWS_DM_01744].

Method HandleMessage serves to hand over a completely received, valid UDS request message from the transport layer to the session layer of Diagnostic Management ([SWS_DM_00311]). This corresponds to service T_Data.ind according to ISO 14229-2 ([SWS_DM_00311], AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.2 “HandleMessage”).

Call and Parameters

As soon as the transport protocol implementation has filled the payload of the buffer previously requested via IndicateMessage ([SWS_DM_00388]), it calls HandleMessage on the instance of apext::diag::uds_transport::UdsTransportProtocolMgr ([SWS_DM_00345]). message of type UdsMessagePtr is passed as an argument. Through the std::unique_ptr semantics, ownership of the UDS message is returned to the generic DM core ([SWS_DM_00311]). The function returns no value.

Semantics, Concurrency, and Error Handling

• Asynchrony: The call must return immediately ("instantly returns") ([SWS_DM_00311]). Interpretation: The actual processing of the diagnostic request is likely continued asynchronously in a separate execution context in the DM core. Question Q-b8dd1a5f3d2dcdf0 (open)
• Error case: The method is declared as noexcept and exception-safe ([SWS_DM_00311]). If reception or filling of the message fails, no call to HandleMessage must occur; instead, the error must be reported via NotifyMessageFailure ([SWS_DM_00310]).
• Thread safety: The operation is specified as not thread-safe ([SWS_DM_00311]). Callers must synchronize parallel accesses to the same instance.

Interaction

The interface belongs to the transport protocol layer and is to be distinguished from the application-side service processing method ara::diag::GenericUDSService::HandleMessage ([SWS_DM_00618]).

The pure virtual callback method HandlerStopped of the management interface apext::diag::uds_transport::UdsTransportProtocolMgr serves as feedback from a UDS transport plugin to the Diagnostic Manager (DM) that its execution has ended and all associated resources as well as network connections have been fully released [SWS_DM_00314]. This call is expected as a mandatory reaction of the handler to a previous call to UdsTransportProtocolHandler::Stop() [SWS_DM_00314], [SWS_DM_00323].

Call context and parameters: The affected plugin identifies itself upon the call via the input parameter handlerId of type UdsTransportProtocolHandlerID [SWS_DM_00314]. The method has no return value (void) and ensures complete exception safety (exception safe) through its specification as noexcept [SWS_DM_00314]. Specific error codes, error reactions, or notifications to DET or DEM are not defined for this interface.

Sequence and restrictions: If the Diagnostic Manager transitions to the state ApplicationState.kTerminating during shutdown, it first calls Stop() on each started UDS transport protocol implementation [SWS_DM_00333]. After returning from Stop(), a strict calling prohibition applies: The handler plugin must no longer call any other methods on UdsTransportProtocolMgr, with the exception of HandlerStopped [SWS_DM_01741], [SWS_DM_00323]. Before the final termination of the DM process, it waits for the arrival of the respective HandlerStopped callback with the matching handlerId [SWS_DM_00340]. The interface is designated as not thread-safe (not thread-safe) [SWS_DM_00314]. Interpretation: Since the DM waits separately for the arrival of the callback, the actual termination of the network connections in the plugin is likely to take place asynchronously to the return of the Stop() method. Question Q-40829d46bd661337 (open)

The method IndicateMessage [SWS_DM_00309] of the class apext::diag::uds_transport::UdsTransportProtocolMgr is called synchronously by a UdsTransportProtocolHandler when the start of reception of a UDS message is to be signaled and the handler supports this. The caller passes the source and target address (sourceAddr, targetAddr), the addressing type type (physical or functional), the channel ID globalChannelId, the expected total size size, and optionally a byte view of payload data already received (payloadInfo). Providing at least two bytes in payloadInfo is recommended so that the Diagnostic Management Core can recognize functional requests such as Tester-Present (bypass logic) even during ongoing processing AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”.

As a return value, the synchronous and exception-safe call returns a std::pair of IndicationResult [SWS_DM_00384] and a UdsMessagePtr [SWS_DM_00309]:

• Acceptance: If the message can be processed, the DM Core returns IndicationResult::kIndicationOk together with a valid UdsMessagePtr whose minimum capacity is at least one byte [SWS_DM_00385].
• Rejection and error cases: If the DM is busy, it responds with kIndicationOccupied and nullptr [SWS_DM_00386]. If the target address is invalid, kIndicationUnknownTargetAddress is returned with a null pointer. Further defined status values are kIndicationOverflow [SWS_DM_00384].

Regarding concurrency and lifetime, the method is specified as not thread-safe (not thread-safe) [SWS_DM_00309]; calls must therefore be synchronized accordingly. The view passed via payloadInfo is transient and may be used exclusively within this function call [SWS_DM_00309].

In the further course of events, upon return of kIndicationOk, the transport layer fills the provided buffer via GetPayload [SWS_DM_00301] up to the capacity limit or full message length [SWS_DM_00388]. After successful filling, HandleMessage is called [SWS_DM_00345]. If message reception fails prematurely, the handler must return the buffer to the DM via NotifyMessageFailure [SWS_DM_00310].

use

The pure virtual method NotifyMessageFailure is provided via header apext/diag/uds_transport/protocol_mgr.h in the interface apext::diag::uds_transport::UdsTransportProtocolMgr [SWS_DM_00310]. It serves for the transport protocol implementation to indicate to Diagnostic Management that a message previously signaled via IndicateMessage() has failed and no final call to HandleMessage() [SWS_DM_00345] will occur anymore [SWS_DM_00310]. The pointer message of type UdsMessagePtr is passed as a parameter, whereby the affected message is returned to the session layer [SWS_DM_00310]. A return value does not exist (void).

Error Handling and Concurrency

The function is declared as noexcept and exception safe [SWS_DM_00310]. It throws no exceptions and reports transmission cancellations purely via the parameter interface. Regarding concurrency, the method is classified as not thread-safe (not thread-safe) [SWS_DM_00310]. Interpretation: Callers might have to ensure external synchronization in case of parallel processing at the transport protocol layer. Question Q-8d9b3a3561b9b6ac (open)

Interaction and Sequence

In regular operation, after a successful IndicateMessage(), the transport protocol fills the payload of the UdsMessage [SWS_DM_00388] and forwards it to Diagnostic Management via HandleMessage() [SWS_DM_00345]. However, if the transmission fails—for example, in case of errors during reception of a multi-frame request—NotifyMessageFailure is called instead [SWS_DM_00310]. This prevents subsequent processing calls and affects session management: While the S3Server timer is stopped at the start of reception [SWS_DM_00383], a reception error of a multi-frame message causes the S3Server timer to be reset and start counting again from the beginning (SWS Diagnostics §7.3.2.7 “Session handling” / [SWS_DM_00310]).

use

The pure virtual method PeriodicTransmitConfirmation is part of class apext::diag::uds_transport::UdsTransportProtocolMgr and is declared via header file apext/diag/uds_transport/protocol_mgr.h [SWS_DM_01069]. It serves to acknowledge sent periodic diagnostic messages and to transmit the number of successfully sent messages AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.6 “PeriodicTransmitConfirmation”.

When called, two input parameters are passed, while the method returns no return value:

• messages (ara::core::Vector<UdsMessageConstPtr>): The same ordered list of messages that was previously passed to method UdsTransportProtocolPeriodicHandler::PeriodicTransmit() [SWS_DM_01069].
• numberOfSentMessages (std::size_t): The number of messages successfully transferred from list messages [SWS_DM_01069].

Error Handling and Exception Safety

With regard to exception safety, the interface is specified as exception safe and provided with the specifier noexcept [SWS_DM_01069]. It thus throws no C++ exceptions. Specific error codes or error messages via DET or DEM are not defined in the specification for this acknowledgment function.

Concurrency and Constraints

According to the specification, the function is classified as not thread-safe (not thread-safe) [SWS_DM_01069]. Concurrent calls on the same instance are therefore not protected and must be coordinated by the caller.

Interaction

The function directly follows the periodic transmission sequence: it accepts the acknowledgment of the messages actually dispatched after a call to UdsTransportProtocolPeriodicHandler::PeriodicTransmit() AUTOSAR_AP_SWS_Diagnostics §C.2.1.2.2.6 “PeriodicTransmitConfirmation”. At the requirement level, the function is assigned to upstream requirement RS_Diag_04215 [SWS_DM_01069].

use

The pure virtual method TransmitConfirmation of interface apext::diag::uds_transport::UdsTransportProtocolMgr serves to notify Diagnostic Management (DM) about the completion of a transmit request that was previously initiated by DM via UdsTransportProtocolHandler::Transmit [SWS_DM_00312] [SWS_DM_00348]. The function implements the service primitive T_Data.con according to ISO 14229-2 [SWS_DM_00312].

Two parameters are passed during the call [SWS_DM_00312]:

• message (UdsMessageConstPtr): Pointer to the UDS message that was previously provided in IndicateMessage() and whose transmission is being acknowledged [SWS_DM_00312].
• result (TransmissionResult): Indicates the result of the transmission. If the network layer was able to successfully output the UDS response onto the network, the value must be set to kTransmitOk, otherwise to kTransmitFailed [SWS_DM_00351] SWS Diagnostics §7.1.1.3 “Confirmation Result”.

The method has no return value (void) and is declared as noexcept, which is why it must be executed in an exception-safe manner [SWS_DM_00312].

Concurrency and System Behavior

The interface is explicitly specified as not thread-safe [SWS_DM_00312]. Calls from concurrent network or handler contexts are therefore likely to require external synchronization by the transport protocol implementation. Question Q-e540ca89c3f61ecb (open)

In addition, the call affects authentication management: If a client is in the default session and in state kAuthenticated, the Diagnostic Server transitions it to state kDeAuthenticated if no new request is received for the duration of authenticationTimeout after the last TransmitConfirmation [SWS_DM_01210].