class apext::diag::uds_transport::UdsMessage

The class apext::diag::uds_transport::UdsMessage represents the standardized storage and transfer object for diagnostic messages exchanged between the generic diagnostic core and transport-specific handlers. Instances are created exclusively by the generic core with optimized memory allocation and provided via UdsMessagePtr [SWS_DM_09012]. In the receive path, the handler fills the provided data buffer starting from the service ID and forwards the message after appending any channel metadata [SWS_DM_00388]. If the core cannot process a message due to existing load, the allocation is rejected and a null pointer is returned [SWS_DM_00386].

more ›

Context

The class apext::diag::uds_transport::UdsMessage represents the central data and storage object for UDS messages exchanged between the generic core of Diagnostic Management (DM Generic Core or UdsTransportProtocolMgr) and a specific implementation of UdsTransportProtocolHandler. It serves as encapsulation and storage for incoming UDS requests and outgoing UDS responses.

In addition to the payload, UdsMessage transports the addressing parameters of diagnostic communication: the source address Address [SWS_DM_00293] via GetSa() [SWS_DM_00297], the target address via GetTa() [SWS_DM_00298], and the address type TargetAddressType (physical with kPhysical or functional with kFunctional) [SWS_DM_00296] via GetTaType() [SWS_DM_00299]. Furthermore, channel-specific meta-information such as connection parameters for DoIP can be appended via AddMetaInfo() [SWS_DM_00294], [SWS_DM_00302].

Context diagram: Interaction between DM core, transport handler, and UdsMessage. Sources: [SWS_DM_09012], [SWS_DM_00385], [SWS_DM_00345]

Lifecycle

Instances of UdsMessage are created with optimized resource allocation exclusively by the generic core of Diagnostic Management. To prevent uncontrolled instantiation by protocol handlers, the default constructor is declared protected (protected) [SWS_DM_09012]. Handlers obtain access to message objects exclusively via owning pointers of type apext::diag::uds_transport::UdsMessagePtr [SWS_DM_00303] or for read-only access via apext::diag::uds_transport::UdsMessageConstPtr [SWS_DM_00304], AUTOSAR_AP_SWS_Diagnostics p. 98.

The object is destroyed via the virtual destructor ~UdsMessage() [SWS_DM_09010]. With regard to concurrency, the query methods for address information (GetSa, GetTa, GetTaType) are reentrant (reentrant) and exception-safe (noexcept) [SWS_DM_00297], [SWS_DM_00298], [SWS_DM_00299]. Access to the data buffer via GetPayload() and adding metadata via AddMetaInfo(), on the other hand, are classified as not thread-safe because the implementation is permitted to perform buffer and resource allocations within these calls [SWS_DM_00300], [SWS_DM_00301], [SWS_DM_00302].

Usage Path

In the regular flow of the receive path, the UdsTransportProtocolHandler announces an incoming UDS request via UdsTransportProtocolMgr::IndicateMessage() to the DM [SWS_DM_00385]. Provided the DM is ready to receive, it acknowledges this with status kIndicationOk and passes a UdsMessagePtr with a minimum size of one byte and the buffer capacity requested by the DM [SWS_DM_00385].

Subsequently, the protocol handler calls the non-const method GetPayload() to obtain a writable reference to the underlying memory area (uds_transport::ByteSpan&) [SWS_DM_00301]. It fills this buffer starting at the service identifier (SID) up to the maximum capacity of the UdsMessage object or the complete message length [SWS_DM_00388]. After optionally appending channel-specific metadata via AddMetaInfo() [SWS_DM_00302], the handler forwards the filled object via UdsTransportProtocolMgr::HandleMessage() to the diagnostic core [SWS_DM_00345]. (Interpretation: In the transmission path for diagnostic responses, the provision of UdsMessage is likely performed analogously by the generic core.) Question Q-4f568a0e527bdfbc (open)

Sequence diagram: Interaction sequence when receiving a UDS message. Sources: [SWS_DM_00385], [SWS_DM_00386], [SWS_DM_00388], [SWS_DM_00301], [SWS_DM_00302], [SWS_DM_00345]

Error Scenarios

If the DM cannot process the message announced via IndicateMessage() because it is busy with the active processing of a service from the same Tester Present session, it returns status kIndicationOccupied and a UdsMessagePtr equal to nullptr [SWS_DM_00386]. In this case, no UdsMessage is provided and the reception is aborted. Likewise, an unknown target address leads to the result kIndicationUnknownTargetAddress with a null pointer as message reference AUTOSAR_AP_SWS_Diagnostics p. 100.

When filling the buffer, the protocol handler must respect the specified buffer capacity: Incoming requests that exceed the provided capacity of the UdsMessage are clamped to the full buffer size [SWS_DM_00388]. Moreover, concurrent, unprotected accesses to GetPayload() or AddMetaInfo() from multiple threads lead to undefined behavior, as these interfaces are explicitly specified as thread safety unsafe (unsafe) [SWS_DM_00300], [SWS_DM_00301], [SWS_DM_00302].