struct ara::diag::GenericUDSService::OperationOutput

The structure ara::diag::GenericUDSService::OperationOutput serves in module diag as an output structure for the payload data of positive UDS response messages [SWS_DM_00632]. After successful execution of a generic UDS service, an application populates the byte variable responseData and hands the instance over to Diagnostic Management. Here, the UDS Service Identifier (SID) must not be contained in responseData, as it is automatically added by the platform [SWS_DM_00632]. The structure is not intended for error scenarios and negative responses.

more ›

Context

Within the AUTOSAR Adaptive Platform in module diag, the data structure ara::diag::GenericUDSService::OperationOutput serves as a standardized output channel for generic UDS services [SWS_DM_00632]. It is defined in the header file #include "ara/diag/generic_uds_service.h" and functions as an encapsulation for the payload data of a successful UDS service execution [SWS_DM_00632]. The essential interaction partners are the application-specific implementation of the generic UDS service handler as well as the platform's higher-level Diagnostic Management AUTOSAR_AP_SWS_Diagnostics p. 80. While Diagnostic Management handles coordination with the external diagnostic tester, protocol validation, and the framework, OperationOutput provides the isolated payload for the positive UDS response message [SWS_DM_00632].

Lifecycle

Instances of ara::diag::GenericUDSService::OperationOutput exhibit a strongly focused and short-lived lifecycle. The structure is instantiated by the service application in the local context of an incoming UDS request. Via the single public member variable responseData of type ara::core::Vector<std::uint8_t>, the structure assumes complete ownership of the payload data bytes [SWS_DM_00632].

Interpretation: The lifetime of OperationOutput is transient and bound to the duration of the respective request processing; after being populated, the instance is likely handed over to Diagnostic Management by means of return value or move semantics and destroyed again after serialization into the UDS response frame. Question Q-c736182a9518978a (open) Because it is a pure data transfer object (DTO) without internal state logic, no state transitions exist. With regard to concurrency, OperationOutput offers no inherent thread safety; however, because instantiation and population occur isolated per request within the processing context, no external synchronization is required in regular service application.

Usage Path

The regular sequence during the processing of a diagnostic request is divided into the following steps:

• Reception: Diagnostic Management receives a UDS request from an external diagnostic tester and forwards it to the corresponding instance of GenericUDSService AUTOSAR_AP_SWS_Diagnostics p. 81.
• Service execution: The application interprets the received parameters and executes the internal diagnostic function.
• Result provision: Upon successful processing, the application instantiates an object of type OperationOutput and assigns the payload data of the response to field responseData [SWS_DM_00632]. Here, the specification mandatorily dictates that responseData may exclusively contain the data bytes without the Service Identifier (SID) [SWS_DM_00632].
• Handover: The application hands OperationOutput over to Diagnostic Management. Interpretation: The handover typically takes place as a synchronous return value or embedded in an asynchronous future value such as ara::core::Future. Question Q-2dcf40060cca29a1 (open)
• Message dispatch: Diagnostic Management automatically prepends the positive SID, completes the UDS telegram, and transmits the response to the diagnostic tester.

Sequence diagram: Sequence of UDS response generation and handover via OperationOutput. Sources: [SWS_DM_00632], AUTOSAR_AP_SWS_Diagnostics p. 81

Error Scenarios

When using the structure, essential constraints and behavior patterns in the event of an error must be observed:

• Exclusion of negative responses: According to the specification, OperationOutput explicitly and exclusively represents the content of positive response messages [SWS_DM_00632]. Interpretation: If a service request cannot be processed successfully (e.g., as a result of impermissible parameters or invalid preconditions), no OperationOutput is likely to be created; instead, the application signals a Negative Response Code (NRC) to Diagnostic Management. Question Q-09abb9092c1dc167 (open)
• Erroneous SID inclusion: If the Service Identifier is mistakenly inserted into responseData, an incorrectly formatted UDS telegram results, as Diagnostic Management independently prepends the SID for positive responses [SWS_DM_00632].
• Memory allocation: Because responseData is declared as a dynamic vector (ara::core::Vector), potential memory bottlenecks must be taken into account when assigning very large amounts of payload data [SWS_DM_00632].