class apext::diag::uds_transport::UdsTransportProtocolPeriodicHandler

The class apext::diag::uds_transport::UdsTransportProtocolPeriodicHandler provides a pure virtual interface for handling the periodic UDS service 0x2A via transport-specific diagnostic channels ([SWS_DM_01064]). It allows diagnostic management to determine channel-specific payload and quantity limits as well as the ordered transmission of multiple UDS messages by means of PeriodicTransmit ([SWS_DM_01067]). If sending a message fails, the operation is aborted and the state is reported via a confirmation function. Since all methods are specified as not thread-safe, concurrent accesses must be synchronized by the caller.

more ›

Context

The pure virtual class apext::diag::uds_transport::UdsTransportProtocolPeriodicHandler represents the standardized interface for supporting the periodic readout of diagnostic data according to the UDS service 0x2A ([SWS_DM_01064], AUTOSAR_AP_SWS_Diagnostics §C.3.1 “Class: UdsTransportProtocolPeriodicHandler”). In the diagnostic system of the AUTOSAR Adaptive Platform, it decouples the higher-level diagnostic management from the concrete network and transport protocol implementation. While the diagnostic management evaluates incoming requests for periodic transmissions and assembles corresponding data packets, the handler takes over the actual transmission of these periodic messages via a concrete connection ([SWS_DM_01067]). Interaction partners here are the diagnostic management on the caller side and the respective communication channel, which is identified via a unique ChannelID ([SWS_DM_01065], [SWS_DM_01066]).

Context diagram: Embedding of UdsTransportProtocolPeriodicHandler between diagnostic server and transport layer. Sources: [SWS_DM_01064], [SWS_DM_01067], AUTOSAR_AP_SWS_Diagnostics §C.3.1 “Class: UdsTransportProtocolPeriodicHandler”.

Lifecycle

Since UdsTransportProtocolPeriodicHandler is defined as an abstract base interface with pure virtual methods, it cannot be instantiated directly ([SWS_DM_01064]). The creation of concrete handler instances is presumably performed by transport-specific driver components (for example, for DoIP- or CAN-based protocols). Question Q-d0b3bf3b0c14dcf6 (open) The lifecycle of the instance is typically tied to the availability of the respective transport protocol stack. For clean polymorphic destruction upon termination of the communication stack, the class provides a virtual destructor ~UdsTransportProtocolPeriodicHandler() ([SWS_DM_02089], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.1.1 “Destructor”).

Regarding concurrency, all member functions of the class are explicitly designated as not thread-safe (not thread-safe) ([SWS_DM_01065], [SWS_DM_01066], [SWS_DM_01067], [SWS_DM_02089]). In the case of parallel access via multiple threads or concurrent requests via the same ChannelID, callers must therefore synchronize accesses on their own responsibility.

Usage Path

A typical sequence for performing periodic message transmissions for service 0x2A is divided into the following steps:

• Determination of the maximum payload length: Diagnostic management calls GetMaxPayloadLength(channelId) to check the maximum payload length supported on the specified connection for a single periodic transmission ([SWS_DM_01066], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.2.1 “GetMaxPayloadLength”).
• Querying message capacity: Via GetNumberOfPeriodicMessages(channelId), the transport-protocol- and connection-specific number of possible periodic messages is queried ([SWS_DM_01065], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.2.2 “GetNumberOfPeriodicMessages”).
• Execution of the periodic transmission: Diagnostic management passes an ordered list of messages in a ara::core::Vector<UdsMessageConstPtr> to the method PeriodicTransmit(channelId, messages) ([SWS_DM_01067], AUTOSAR_AP_SWS_Diagnostics §C.3.1.1.2.3 “PeriodicTransmit”). The handler transmits the contained messages in the specified order.
• Confirmation: The transport layer signals the result of the transmission process via the call to PeriodicTransmit Confirmation, which returns the number of successfully transmitted messages and the original vector ([SWS_DM_01067]).

Sequence diagram: Typical sequence of capacity query, periodic sending, and confirmation. Sources: [SWS_DM_01065], [SWS_DM_01066], [SWS_DM_01067].

Error Scenarios

During the execution of PeriodicTransmit, all messages in the list are transmitted sequentially. If the transmission of an individual message fails, the entire sending process is aborted immediately ([SWS_DM_01067]). In this case, subsequent messages in the list are no longer sent. For fault diagnosis and informing diagnostic management, the confirmation call PeriodicTransmit Confirmation is triggered nonetheless. This call contains the number of messages successfully transmitted up to the abort as well as the complete vector of UDS messages unchanged ([SWS_DM_01067]). This allows diagnostic management to trace exactly which message caused the error.

All interface methods are specified as noexcept and exception-safe (exception safe) ([SWS_DM_01065], [SWS_DM_01066], [SWS_DM_01067], [SWS_DM_02089]). Error states during transmission do not lead to C++ exceptions, but are reported deterministically via the intended confirmation mechanism.