class ara::diag::DownloadService

use

Method [SWS_DM_00790] is called to process data for the UDS service TransferData (0x36) following a previously initiated download request (AUTOSAR_AP_SWS_Diagnostics §8.14.1.1.3.1 “DownloadData”). Execution is asynchronous via ara::core::Future<OperationOutput>.

As inputs, a ara::core::Span<const std::uint8_t> with the data to be transferred (transferRequestParameterRecord), context data via MetaInfo, and a CancellationHandler are passed. The payload remains valid until the promise is satisfied or the operation is cancelled. Upon successful completion, response data is stored in OperationOutput.responseData and placed behind the block sequence counter in the positive response message [SWS_DM_00786].

Error handling

If an error occurs during processing, the promise is completed with an appropriate ErrorCode from DiagUdsNrcErrc (NRC in accordance with ISO 14229-1) as a negative UDS response [SWS_DM_00790].

Concurrency and Limitations

The function is declared as noexcept. Whether the implementation must be executed thread-safely is conditionally determined by the ConcurrencyType passed in the constructor [SWS_DM_00790]. Via the CancellationHandler, the cancellation status can be queried (IsCanceled) or a notification callback can be registered via SetNotifier.

Interaction

The operation implements the processing of TransferData [SWS_DM_00137] after the download session was previously started via RequestDownload (0x34) [SWS_DM_00869]. The transfer of the data blocks presumably occurs sequentially according to the UDS session order. Question Q-fe18230bf7fcdf47 (open)

The method Offer of class ara::diag::DownloadService enables the forwarding of incoming download requests by the Diagnostic Management Daemon (DM) to the specific handler [SWS_DM_00792]. The call is made synchronously and without parameters without throwing C++ exceptions (noexcept) [SWS_DM_00792]. Typically, offering is likely to be called during the initialization phase of the processing application before external diagnostic requests arrive. Question Q-0180c707edea0eec (open)

The function returns a ara::core::Result<void> as return value [SWS_DM_00792]. If registration was successful, the result is empty. If the service was already offered to the DM previously, the operation fails with error code DiagOfferErrc::kAlreadyOffered, ensuring rollback semantics [SWS_DM_00792].

Regarding concurrency and safety, the following conditions apply:

• Thread Safety: The function is classified as not thread-safe (not thread-safe) [SWS_DM_00792]; parallel calls on the same service instance must be synchronized on the application side.
• Exception Safety: The interface is specified as exception safe (exception safe) [SWS_DM_00792].

The pattern via Offer corresponds to the uniform approach for diagnostic services in AUTOSAR Adaptive, as also analogously defined for UploadService [SWS_DM_00802], SecurityAccess [SWS_DM_00766], or generic UDS services [SWS_DM_00619]. Despite having the same name as other subsystems, it is a specific diagnostic implementation AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 “Monitors”.

use

The method RequestDownload of class ara::diag::DownloadService is called by the Diagnostic Server instance to process the UDS service 0x34 (RequestDownload) according to [SWS_DM_00128] and [SWS_DM_00867]. It takes dataFormatIdentifier, addressAndLengthFormatIdentifier, the memory range memoryAddressAndSize, metaInfo as well as a cancellationHandler [SWS_DM_00789]. Processing is performed asynchronously and returns a ara::core::Future<void>; the validity of the data in memoryAddressAndSize remains in effect until the corresponding promise is fulfilled or the operation is canceled [SWS_DM_00789].

Error handling

In case of success, the future is set to void, resulting in a positive response, whereupon a security event SEV_UDS_REQUEST_UP_DOWNLOAD_SUCCESSFUL is reported to the IdsM [SWS_DM_02031]. If the request fails, the future must be completed with an appropriate error code from DiagUdsNrcErrc according to ISO 14229-1 [SWS_DM_00789].

Concurrency and Interaction

The method is specified as exception safe, while thread safety is conditional and depends on the ConcurrencyType passed in the constructor [SWS_DM_00789]. Cancellation of the conversation can be processed via cancellationHandler.IsCanceled() or a notifier registered via cancellationHandler.SetNotifier [SWS_DM_00789]. After successful execution of RequestDownload, transfer of data via DownloadData typically follows [SWS_DM_00790]. Interpretation: The implementing application is likely to validate the validity of the memory address and size before fulfilling the future, as suggested by the context for memory-related UDS services AUTOSAR_AP_SWS_Diagnostics §7.3.2.8.2 “Common service processing items”. Question Q-728d2e5f7d09e605 (open)

The method RequestDownloadExit of class ara::diag::DownloadService is called by the Diagnostic Server instance to process the UDS service RequestTransferExit (0x37) within the scope of a download sequence ([SWS_DM_00141], [SWS_DM_00871], SWS Diagnostics §7.3.2.8.19 “Service 0x37 – RequestTransferExit”).

When called, the following parameters are passed ([SWS_DM_00791]):

• transferRequestParameterRecord: A ara::core::Span<const std::uint8_t> containing vehicle-manufacturer-specific parameters to support the data transfer. The validity of this memory persists until the corresponding promise is fulfilled or processing is canceled.
• metaInfo: Meta-information on the diagnostic request.
• cancellationHandler: Serves for status queries by means of cancellationHandler.IsCanceled() as well as the registration of a notification function via cancellationHandler.SetNotifier().

The function operates asynchronously and returns a ara::core::Future<OperationOutput> ([SWS_DM_00791]). In case of success, the future is fulfilled with OperationOutput; the data contained in OperationOutput::responseData ([SWS_DM_00786]) are embedded after the service ID as transferResponseParameterRecord into the positive response ([SWS_DM_00791]).

If an error occurs, the future must be completed with an appropriate error code from DiagUdsNrcErrc (Negative Response Code according to ISO 14229-1) ([SWS_DM_00791]). The interface is specified as noexcept; its thread safety is conditional and is defined via the ConcurrencyType during object creation ([SWS_DM_00791]).

Usage and Call Context

The function StopOffer of class ara::diag::DownloadService (AUTOSAR_AP_SWS_Diagnostics §8.14.1.1.3.5 “StopOffer”, [SWS_DM_00793]) serves to disable the forwarding of incoming diagnostic request messages from Diagnostic Management (DM) to the service instance. The synchronous interface has the signature void StopOffer () noexcept;, takes no parameters, and returns no value ([SWS_DM_00793]). The call is made via the header #include "ara/diag/download.h" ([SWS_DM_00793]).

Error Handling and Concurrency

Regarding error handling, the method is declared as exception safe (exception safe) and with noexcept; neither exceptions are thrown nor error codes generated ([SWS_DM_00793]). For concurrency, StopOffer is not thread-safe (not thread-safe) ([SWS_DM_00793]). Simultaneous calls from multiple threads on the same instance must thus be synchronized by the application.

Interaction in the Diagnostic System

Disabling services via StopOffer follows a uniform pattern within AUTOSAR Adaptive: For upload services, the functional counterpart ara::diag::UploadService::StopOffer exists ([SWS_DM_00803]), as do analogous methods for CommunicationControl ([SWS_DM_00810]), Authentication ([SWS_DM_01131]), and EcuResetRequest ([SWS_DM_01017]). The naming is modeled after the platform conventions, but represents an independent diagnostic implementation (AUTOSAR_AP_SWS_Diagnostics §7.3.4.1.2 “Monitors”). Interpretation: After calling StopOffer, the DM is expected to no longer forward or to discard incoming UDS download requests until the service is offered again. Question Q-a45cc70b6ae09431 (open)