namespace apext::diag::uds_transport

The namespace apext::diag::uds_transport provides the C++ transport interface for decoupling generic diagnostic management from specific UDS transport protocols AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”. Protocol plugins derive from the base class UdsTransportProtocolHandler and pass through a strict lifecycle consisting of construction, initialization, start, and orderly stopping [SWS_DM_00329]. Incoming messages are reported via IndicateMessage and receive a memory-managed UdsMessagePtr for payload acquisition if capacity is available. A central constraint is that after stopping, no further calls to diagnostic management are permitted other than the confirmation message.

more ›

Context

The namespace apext::diag::uds_transport defines the standardized C++ transport interface (Transport Protocol API) for Diagnostic Management (DM) in the AUTOSAR Adaptive Platform AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”. The architecture functionally separates the generic core of Diagnostic Management from concrete network and transport layers. In this way, standardized protocols such as DoIP as well as future or vendor-specific transport protocols (for example for CAN, CAN-FD, or FlexRay) can be integrated as modular plugins AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”.

The central mediating instance is the class UdsTransportProtocolMgr, which coordinates the interaction between the instances of the Diagnostic Server and the attached transport protocols. Concrete protocol plugins derive from the abstract base class UdsTransportProtocolHandler AUTOSAR_AP_SWS_Diagnostics §7.1.1 “Support of UDS Transport Layer” [SWS_DM_00315]. Individual handler instances are addressed via UdsTransportProtocolHandlerID [SWS_DM_00336], while communication channels are identified via the type ChannelID [SWS_DM_00337]. To support periodic data queries according to ISO service 0x2A, the interface additionally incorporates the class UdsTransportProtocolPeriodicHandler.

Lifecycle

Diagnostic Management controls the lifecycle of each UdsTransportProtocolHandler instance in a strictly specified sequence [SWS_DM_00329]:

1. Creation: The DM instantiates the protocol plugin via the constructor UdsTransportProtocolHandler::UdsTransportProtocolHandler [SWS_DM_00329].
2. Initialization: The DM calls UdsTransportProtocolHandler::Initialize [SWS_DM_00329]. Except for querying GetPeriodicHandler, the DM must not call any further methods on the handler prior to the successful return of kInitializeOk [SWS_DM_01746].
3. Start and operation: Following successful initialization, the handler is activated using UdsTransportProtocolHandler::Start. Only after this call does the DM process notifications about reactivated channels via UdsTransportProtocolMgr::ChannelReestablished [SWS_DM_01744].
4. Termination: If the DM transitions to the state ApplicationState.kTerminating, it calls UdsTransportProtocolHandler::Stop for all active plugins [SWS_DM_00333]. After this call returns, the plugin may exclusively call UdsTransportProtocolMgr::HandlerStopped [SWS_DM_01741]. The DM actively waits for this confirmation [SWS_DM_00340].

State diagram: Lifecycle phases and transition conditions of a transport protocol handler implementation. Sources: [SWS_DM_00329], [SWS_DM_00333], [SWS_DM_00340], [SWS_DM_01741], [SWS_DM_01744], [SWS_DM_01745], [SWS_DM_01746]

Usage Path

During ongoing operation, incoming diagnostic messages are forwarded via a coordinated interplay of handler and manager:

1. Message indication: If the handler receives data on a channel (ChannelID [SWS_DM_00337]), it calls UdsTransportProtocolMgr::IndicateMessage. In doing so, it can pass advance payload in payloadInfo; at least the first two bytes are recommended for early detection of functional requests AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”.
2. Buffer allocation: If the DM is ready to receive, IndicateMessage responds with a std::pair from IndicationResult::kIndicationOk and a valid smart pointer UdsMessagePtr [SWS_DM_00309] [SWS_DM_00385]. The referenced UdsMessage object has a minimum capacity of one byte [SWS_DM_00385]. The buffer is managed as a std::unique_ptr with a specific deleter of the DM core and is not thread-safe [SWS_DM_00303]. For read access, the constant equivalent UdsMessageConstPtr exists [SWS_DM_00304].
3. Data handoff: The handler writes the received diagnostic data into the provided buffer, whose byte sequence is typed via the type ByteSpan (alias for ara::core::Span<ara::core::Byte> [SWS_DM_00338]). Presumably, providing the separate class UdsTransportProtocolPeriodicHandler via GetPeriodicHandler serves to decouple the periodic transmission service 0x2A from the regular UDS message path. Question Q-230ef0b7c384c594 (open)

Sequence diagram: Sequence of message indication and buffer allocation between handler, manager, and DM core. Sources: AUTOSAR_AP_SWS_Diagnostics §7.1 “UDS Transport Layer”, [SWS_DM_00303], [SWS_DM_00309], [SWS_DM_00385], [SWS_DM_00386]

Error Scenarios

The specification defines concrete error states and preconditions for the transport attachment:

• Failed initialization: If UdsTransportProtocolHandler::Initialize returns the result kInitializeFailed, the DM immediately aborts the initialization process for this handler and calls no further methods on it [SWS_DM_01745].
• Rejection when diagnostic core is busy: If the DM is blocked by ongoing service processing of the same Tester Present conversation and this is not a functional Tester Present with payloadInfo 0x3E 0x80, IndicateMessage returns the result kIndicationOccupied together with a nullptr instead of a message buffer [SWS_DM_00386].
• Disallowed calls after termination: If a plugin calls a method of UdsTransportProtocolMgr other than HandlerStopped after Stop returns, this violates the protocol requirements [SWS_DM_01741]. Likewise, the DM ignores signals such as ChannelReestablished if they arrive prior to the successful call to Start [SWS_DM_01744].