class ara::diag::DataTransferWriteSession

The class ara::diag::DataTransferWriteSession encapsulates write diagnostic data transfers and coordinates forwarding to application-specific write handlers ([SWS_DM_01555]). For incoming UDS services such as TransferData (0x36) or RequestTransferExit (0x37), the diagnostic server instance calls the corresponding Write or Exit methods of the registered handlers ([SWS_DM_01317]). Because default and copy construction are deleted, the session exists as an exception-safe unique instance whose creation presumably takes place via template constructors. Question (open)

more ›

Context

The class ara::diag::DataTransferWriteSession encapsulates all variants of write data transfers within the functional cluster Adaptive Platform Diagnostics ([SWS_DM_01555]). It acts as a connecting element between the platform's diagnostic server instance and the application-specific implementations that perform the actual write transfer.

In the context of diagnostic services such as RequestFileTransfer (for example with operating mode ReplaceFile (0x03) according to [SWS_DM_01313]), the diagnostic server instance accepts transfer requests. If diagnostic requests of the UDS service TransferData (0x36) arrive subsequently, the server delegates them to the Write method of the handler class bound to the respective DataTransferWriteSession ([SWS_DM_01317]). After all data blocks have been transferred, the service RequestTransferExit (0x37) signals completion, whereupon the diagnostic server instance calls the Exit method of the registered handler ([SWS_DM_01318]).

Context diagram: Interaction between diagnostic server, DataTransferWriteSession, and application-specific handler class. Sources: [SWS_DM_01555], [SWS_DM_01317], [SWS_DM_01318].

Lifecycle

The lifecycle of a DataTransferWriteSession is subject to the specifications from the header file ara/diag/data_transfer.h ([SWS_DM_01339]). Default construction is explicitly deleted (DataTransferWriteSession() = delete, [SWS_DM_01339]). An instantiation therefore presumably takes place via template constructors through which specific handler classes are bound to the session object (AUTOSAR_AP_SWS_Diagnostics §8.10 “Context of RequestFileTransfer”). Question Q-4575aa1e5d0889b3 (open)

To enforce unique ownership, DataTransferWriteSession is neither copyable nor copy-assignable: both the copy constructor ([SWS_DM_01559]) and the copy assignment operator ([SWS_DM_01560]) are declared as delete. Instances consequently exist as exclusive single instances.

In contrast, the class supports full move semantics: the move constructor ([SWS_DM_01557]) and the move assignment operator ([SWS_DM_01558]) are declared as default implementations and specified as noexcept as well as exception-safe ("exception safe"). They allow the efficient transfer of session state between program contexts. Destruction takes place via the exception-safe default destructor (~DataTransferWriteSession() noexcept = default, [SWS_DM_01556]). Regarding concurrency, usage is likely to be primarily sequential within the executing server thread, since no synchronization mechanisms for concurrent accesses are documented. Question Q-2c2278884fa11b21 (open)

Usage Path

The regular flow of a write transfer proceeds in the following steps:

1. Initialization: Upon receipt of a write request (for example RequestFileTransfer with kReplace according to [SWS_DM_01313]), a DataTransferWriteSession is established. Here, the application-specific handler for write operations is registered via template constructors (AUTOSAR_AP_SWS_Diagnostics §8.10 “Context of RequestFileTransfer”).
2. Data block transfer: For each incoming request of the UDS service TransferData (0x36), the diagnostic server instance calls the Write method of the registered handler class ([SWS_DM_01317]). This step is repeated cyclically for all blocks of the transfer.
3. Session termination: After the transfer is complete, the diagnostic server receives RequestTransferExit (0x37) and thereupon calls the Exit method of the handler class ([SWS_DM_01318]).
4. Cleanup: After successful completion or in the event of premature cancellation, the session object is destroyed ([SWS_DM_01556]).

Sequence diagram: Typical flow of a write data transfer across the participating instances. Sources: [SWS_DM_01317], [SWS_DM_01318], [SWS_DM_01556].

Error Scenarios

Error handling and reliability in ara::diag::DataTransferWriteSession rely significantly on static type safety and exception safety:

• Prevention of invalid object states: Deletion of the default constructor ([SWS_DM_01339]) prevents uninitialized session objects from existing without a bound handler. The prohibition of copy operations ([SWS_DM_01559], [SWS_DM_01560]) rules out inconsistent states due to multiple ownership already at compile time.
• Exception safety during moving and destruction: Declaring the move constructor ([SWS_DM_01557]), move assignment ([SWS_DM_01558]), and destructor ([SWS_DM_01556]) as noexcept guarantees that no exceptions are thrown at runtime during resource transfers and session teardown.
• Premature abort: If a transfer fails prematurely, the noexcept destructor ensures that the session object can also be cleaned up reliably during exception unwinding ([SWS_DM_01556]).