struct ara::diag::SovdSwUpdate::UpdatePackageDetails

The struct ara::diag::SovdSwUpdate::UpdatePackageDetails serves as a standardized data transfer object for metadata of software update packages in the context of ASAM SOVD [SWS_DM_01877]. It transports package identifiers, sizes, conditions, and affected components from the implementing application to the SOVD protocol layer of the diagnostic instance AUTOSAR_AP_SWS_Diagnostics §7.4 “Figure 7.4: SOVD Software Update API - concept”. The data is provided primarily in response to queries via GetUpdatePackageDetails. Because the struct bundles purely passive member variables, it has no synchronization of its own and requires external safeguarding during concurrent use.

more ›

Context

The struct ara::diag::SovdSwUpdate::UpdatePackageDetails is defined in header ara/diag/sovd_sw_update.h [SWS_DM_01877] and serves as a standardized data container for detailed information on software update packages in the context of Service-Oriented Vehicle Diagnostics (SOVD). According to [SWS_DM_01796], the Diagnostic Server instance implements the SOVD API methods for software updates in accordance with the ASAM SOVD standard. Since the functional logic of software updates is not processed within the Diagnostics functional cluster, handling is primarily the responsibility of the adaptive application, while ara::diag::SovdSwUpdate focuses on handling the underlying SOVD protocol AUTOSAR_AP_SWS_Diagnostics §7.4 “Figure 7.4: SOVD Software Update API - concept”.

In this architecture, UpdatePackageDetails functions as the interface for information exchange between the application's vehicle-specific update logic and the SOVD protocol layer. The struct bundles metadata required for identifying, validating, scheduling, and displaying the update process. These include elementary identifiers such as the package ID id [SWS_DM_01878] and the name name [SWS_DM_01879] along with translation reference translation_id [SWS_DM_01881]. Furthermore, the struct encapsulates dimensioning and runtime specifications such as package size size in bytes [SWS_DM_01893], estimated execution duration duration in seconds [SWS_DM_01891], and the optional flag automated for automated processes [SWS_DM_01882]. For traceability and target component management, it transports origin data in origin [SWS_DM_01883], the list of updated components in updated_components [SWS_DM_01894], and affected system constituents in affected_components [SWS_DM_01895]. Additional boundary conditions and user interactions are provided via preconditions [SWS_DM_01888], execution_conditions [SWS_DM_01890], notes [SWS_DM_01884], and user_activity [SWS_DM_01886] along with their respective translation identifiers preconditions_translation_id [SWS_DM_01889], notes_translation_id [SWS_DM_01885], and user_activity_translation_id [SWS_DM_01887].

Lifecycle

The class is specified as a C++ struct struct with purely public member variables AUTOSAR_AP_SWS_Diagnostics §8.58.4 “Struct: UpdatePackageDetails” [SWS_DM_01877]. Interpretation: As a pure data transfer object, UpdatePackageDetails has no business logic or internal state machine of its own. Question Q-4f532d6356cadc54 (open) Its instantiation is carried out by the application as needed, as soon as information about an update package is queried or managed.

Regarding ownership, the struct is under the sovereignty of the creator. When provided via interface functions such as GetUpdatePackageDetails [SWS_DM_01917], the object is typically passed by value or via move semantics to the diagnostic framework. The lifetime of individual instances is thus bound to the respective execution context of the processing functions. When leaving scope, destruction occurs deterministically according to standard rules for C++ objects, with embedded standard types such as ara::core::String, ara::core::Vector, and ara::core::Optional freeing their allocated memory AUTOSAR_AP_SWS_Diagnostics §8.58.4.1 “Public Member Variables”.

Regarding concurrency, UpdatePackageDetails provides no internal synchronization. If instances are shared or modified across threads, safeguarding against data conflicts is entirely the responsibility of the calling application.

Usage Path

The primary use of UpdatePackageDetails takes place in the context of determining detailed update information via SOVD. A typical flow is as follows:

• Request reception: An external client sends a request to retrieve package details to the Diagnostic Server, which implements the SOVD API methods for software updates [SWS_DM_01796].
• Method call: Since the protocol layer delegates the update logic to the application AUTOSAR_AP_SWS_Diagnostics §7.4, the framework initiates the function call GetUpdatePackageDetails [SWS_DM_01917].
• Compilation of data: The application determines the properties of the requested update package. It creates an instance of UpdatePackageDetails [SWS_DM_01877] and populates its mandatory and optional fields:
  • Setting the identifiers id [SWS_DM_01878] and name [SWS_DM_01879] as well as translation_id [SWS_DM_01881].
  • Specifying the metric values size [SWS_DM_01893] as well as optionally duration [SWS_DM_01891] and automated [SWS_DM_01882].
  • Defining target and dependency structures via origin [SWS_DM_01883], updated_components [SWS_DM_01894], and affected_components [SWS_DM_01895].
  • Providing preconditions, execution conditions, and instructions via preconditions [SWS_DM_01888], execution_conditions [SWS_DM_01890], notes [SWS_DM_01884], and user_activity [SWS_DM_01886] with associated translation keys [SWS_DM_01889] [SWS_DM_01885] [SWS_DM_01887].
• Return and serialization: The fully populated struct is passed to the diagnostic framework. Presumably, the Diagnostic Server serializes the fields according to the specifications of ASAM SOVD into a corresponding protocol response and delivers it to the client. Question Q-018edc7d19373646 (open)

Sequence diagram: Typical sequence for querying update package details via SOVD. Sources: [SWS_DM_01796], [SWS_DM_01877], [SWS_DM_01917], AUTOSAR_AP_SWS_Diagnostics §7.4.