module ara::ucm — Update and Configuration Management

The Functional Cluster Update and Configuration Management controls the transactional installation, verification, and activation of software packages on an Adaptive Machine (AUTOSAR_AP_EXP_SWArchitecture p. 138). For this purpose, the service interface PackageManagement implements a three-phase pipeline consisting of data transmission, package processing, and subsequent switching via Activate ([SWS_UCM_00352]). If errors occur or dependencies are missing, standardized mechanisms such as Rollback and RevertProcessedSwPackages ensure the safe recovery of the previous system state ([SWS_UCM_00350], [SWS_UCM_00353]).

more ›

Update and Configuration Management (UCM) is a daemon-based Functional Cluster of the AUTOSAR Adaptive Platform that provides the service-oriented interface PackageManagement via ara::com ([SWS_UCM_00361], AUTOSAR_AP_EXP_SWArchitecture p. 138). UCM acts as the local execution entity for OTA clients, diagnostic applications, or the vehicle-wide Vehicle Update and Configuration Management (V-UCM) and is addressed in multi-ECU configurations via a vehicle-wide unique instance identifier using GetId ([SWS_UCM_00343], TPS_ManifestSpecification p. 631).

The update sequence takes place in three phases: data transmission, processing, and activation (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136). Software packages can be streamed block by block at any time via TransferStart, TransferData, and TransferExit, or registered as an existing URI path via RegisterSoftwarePackage ([SWS_UCM_00344], [SWS_UCM_00345], [SWS_UCM_00346]). Transfers that are no longer needed can be removed with DeleteTransfer ([SWS_UCM_00348]).

Sequence diagram: Transfer of a software package via block-by-block streaming or direct URI registration. Sources: [SWS_UCM_00344], [SWS_UCM_00345], [SWS_UCM_00346], [SWS_UCM_00347], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 137.

Processing is triggered with ProcessSwPackage, during which UCM verifies package manifests and signatures, unpacks the target clusters, and indicates progress in status field CurrentStatus as well as via GetProgress ([SWS_UCM_00349], [SWS_UCM_00360], [SWS_UCM_00361]). After successful preparation, Activate switches to the new clusters in coordination with State Management and Execution Management, whereupon Finish cleans up temporary source data ([SWS_UCM_00352], [SWS_UCM_00354], AUTOSAR_AP_EXP_PlatformDesign p. 77).

Sequence diagram: Activation, platform state transition, and cleanup of software packages. Sources: [SWS_UCM_00352], [SWS_UCM_00354], AUTOSAR_AP_EXP_PlatformDesign p. 77.

Erroneous processing leads to state kProcessingFailed, whereas incomplete campaigns are transactionally reverted to the initial state using RevertProcessedSwPackages before activation and using Rollback after a failed switch ([SWS_UCM_00350], [SWS_UCM_00353], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38). For status inspection and auditing, GetSwClusterInfo, GetSwClusterChangeInfo, and GetHistory are used ([SWS_UCM_00355], [SWS_UCM_00356], [SWS_UCM_00357]).

more ›

Role and Functional System Boundaries within the Platform Network

The Functional Cluster Update and Configuration Management (UCM) forms the central platform component of the AUTOSAR Adaptive Platform for the secure, transactional update, installation, and uninstallation of application and platform software at machine level (AUTOSAR_AP_EXP_SWArchitecture p. 138). Technically, the UCM is implemented as a system-wide background service (daemon-based) and provides its core functionality via the primary ara::com service interface PackageManagement ([SWS_UCM_00361], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 90). Consuming entities include in-vehicle Over-the-Air clients (OTA clients), diagnostic testers via Diagnostic Management, and higher-level coordinators such as Vehicle Update and Configuration Management (V-UCM) (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 17).

Within a multi-tier vehicle architecture, the UCM acts as a local execution entity (UCM Subordinate), while the vehicle-central V-UCM orchestrates software-supported campaigns across multiple ECUs (SWS_VehicleUpdateAndConfigurationManagement p. 16, AUTOSAR_AP_SWS_VehicleUpdateAndConfigurationManagement p. 12). To enable the central orchestrator to address multiple distributed UCM instances on different machines, each instance provides its unique identifier via the method GetId ([SWS_UCM_00343]). In accordance with manifest specifications, this identifier must be configured to be vehicle-wide machine-specifically unique (TPS_ManifestSpecification p. 631).

Context diagram: Functional embedding of the UCM daemon into the Adaptive Platform and interaction with clients as well as platform clusters. Sources: AUTOSAR_AP_EXP_SWArchitecture p. 138, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 17, SWS_VehicleUpdateAndConfigurationManagement p. 16.

Provisioning and Transfer of Software Packages

The lifecycle of a software update is divided by default into three macro phases: Data Transmission, Processing, and Activation (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136). An essential architectural feature of UCM is the decoupling of data transmission from internal processing and package management states: software packages can be transferred to the machine at any time during ongoing operation (SWS_UpdateAndConfigurationManagement p. 38).

For the provisioning of software packages, the interface PackageManagement defines two complementary mechanisms:

• Block-by-block streaming: The client initiates the transfer by calling TransferStart, specifying the total size in bytes, and receives a unique TransferIdType as well as the maximum permitted block size ([SWS_UCM_00345]). The data fragments are then transferred sequentially using TransferData and a consecutive block counter ([SWS_UCM_00346], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136). The formal completion is marked by the method call TransferExit ([SWS_UCM_00347]).
• URI-based registration: If the package has already been provided outside of UCM (e.g., via a background download manager or pre-placement in the local file system), the client can register the package via RegisterSoftwarePackage by specifying a standardized URI path ([SWS_UCM_00344], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 137).

In both cases, UCM assigns a unique TransferId to the package, via which all subsequent actions are referenced. Transferred but not yet processed packages can be explicitly removed from temporary storage using DeleteTransfer in the event of cancellation or storage cleanup ([SWS_UCM_00348]).

Sequence diagram: Transfer of a software package via block-by-block streaming or direct URI registration. Sources: [SWS_UCM_00344], [SWS_UCM_00345], [SWS_UCM_00346], [SWS_UCM_00347], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 136, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 137.

Processing and Verification in Local UCM

After successful transfer or registration, the client initiates the processing of the package via the method ProcessSwPackage ([SWS_UCM_00349]). Processing comprises extracting the software clusters, parsing the manifests, performing integrity and authenticity checks, and statically validating cluster dependencies (EXP_SWArchitecture p. 185). A single software package can encapsulate executables of Adaptive Applications, operating system or firmware updates, as well as configuration and calibration data (SWS_UpdateAndConfigurationManagement p. 27).

Calling ProcessSwPackage transitions the service field CurrentStatus to the state kProcessing ([SWS_UCM_00361], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 123). Clients can subscribe to the field or monitor the current progress via the query method GetProgress ([SWS_UCM_00360]). In addition, GetSwPackages allows querying all software packages currently known in UCM and their processing status ([SWS_UCM_00359]). Ongoing time-consuming processing steps can be interrupted if needed using Suspend and resumed at a later time via Resume ([SWS_UCM_00397], [SWS_UCM_00398]). If processing is canceled, the operation can be stopped in a controlled manner with Cancel ([SWS_UCM_00351]).

Sequence diagram: Package processing with state transition and progress monitoring. Sources: [SWS_UCM_00349], [SWS_UCM_00360], [SWS_UCM_00361], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 123.

Activation Workflow and Platform State Transition

Once all packages intended for a campaign have been successfully processed, the client initiates the activation of the new software clusters with the synchronous call to Activate ([SWS_UCM_00352]). The prerequisite for this is that the UCM is in a consistent quiescent state and no active processing or cancellation tasks are running (EXP_SWArchitecture p. 185). UCM closely coordinates the activation step with State Management (SM) and Execution Management (EM): running processes of the old version are terminated in an orderly fashion, persistency data structures are migrated, and the new application instances are started (AUTOSAR_AP_EXP_PlatformDesign p. 77).

The manifest metamodel of the Adaptive Platform supports multi-step activation steps (SoftwarePackageStep), allowing the sequence of package processing to be flexibly decoupled from preparation and the actual switchover time (activationSwitch=True) (AUTOSAR_TPS_ManifestSpecification p. 642). After successful switchover and verification of the new software states, the client completes the campaign with Finish ([SWS_UCM_00354]). This call performs final cleanup, deletes the source packages from temporary storage, and transfers the software clusters to the permanent state (EXP_SWArchitecture p. 138).

Sequence diagram: Activation, platform state transition, and cleanup of software packages. Sources: [SWS_UCM_00352], [SWS_UCM_00354], AUTOSAR_AP_EXP_PlatformDesign p. 77.

Cluster lifecycle, query APIs, and audit history

Software clusters (SwCluster) have a well-defined lifecycle: After successful processing via ProcessSwPackage, a newly added cluster transitions to the state kAdded, while an updated cluster assumes the state kUpdating (SWS_UpdateAndConfigurationManagement p. 24). Only with the final call to Finish after activation do these clusters transition to the stable production state kPresent (SWS_UpdateAndConfigurationManagement p. 24). For software packages themselves, decoupled state machines exist: The TransferState (states kTransferring, kTransferred) and the ProcessingState (states kReady, kProcessing, kProcessed, kProcessingFailed) also permit pure streaming scenarios without prior intermediate buffering of the entire package (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38).

At runtime, UCM provides comprehensive information interfaces for system inspection:

• GetSwClusterInfo provides a list of all currently active software clusters in the state kPresent along with version identifiers ([SWS_UCM_00357]).
• GetSwClusterChangeInfo reports all pending changes (clusters to be added, updated, or removed) prior to final activation ([SWS_UCM_00356]).
• GetSwClusterManifestInfo permits targeted querying of manifest details of a specific installed software cluster ([SWS_UCM_00358]).
• GetHistory enables reading a chronological audit trail of all UCM actions within a defined time interval for seamless tracking in fleet management ([SWS_UCM_00355], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 86).

State diagram: Decoupled state machines for data transfer and processing of a software package. Sources: AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38, AUTOSAR_SWS_UpdateAndConfigManagement p. 20.

State diagram: Lifecycle of a software cluster from preparation to final activation. Sources: SWS_UpdateAndConfigurationManagement p. 24, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 87.

Behavior in case of errors and transactional protection

To ensure the functional safety and system stability of the ECU under all operating conditions, UCM enforces strict consistency checks and provides fallback mechanisms for each phase of the update process. If validation or installation fails during package processing, the affected package transitions to the state kProcessingFailed (AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38). If already processed packages are to be discarded prior to activation, RevertProcessedSwPackages rolls back all temporary file and configuration changes collectively ([SWS_UCM_00350]).

If an error is detected during the activation step—for instance due to unresolvable dependencies (kDependencyMissing), failed memory allocations (kPersistencyAllocationFailed), or errors in the update session with State Management ([SWS_UCM_00352])—UCM aborts the activation. In such an error scenario, the method Rollback reverts the entire platform to the exact state prior to the start of package processing ([SWS_UCM_00353]). Interpretation: In this case, UCM likely relies on redundant storage structures such as A/B partitions or file system snapshots to return the unchanged previous versions to operation without data loss (AUTOSAR_AP_EXP_SWArchitecture p. 138). Question Q-8d85be7343a9aace (open)

At the interface level, invalid calls (e.g. activation attempts when packages are missing or concurrent calls during active operations) are rejected deterministically via error code kOperationNotPermitted ([SWS_UCM_00347], [SWS_UCM_00352]). Interpretation: During ongoing activation or rollback operations, UCM likely blocks any concurrent modification calls strictly in order to prevent race conditions during partition switchover (EXP_SWArchitecture p. 185). Question Q-60859031e6230a65 (open) UCM acknowledges invalid or unknown session identifiers with the application error kTransferIdInvalid ([SWS_UCM_00348], [SWS_UCM_00351]).

Further detailed evidence

The architecture of UCM and its service-oriented embedding are normatively anchored in the following core specifications:

• PackageManagement Service interface and transfer protocol: [SWS_UCM_00345], [SWS_UCM_00346], [SWS_UCM_00347], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 85.
• Processing, state transitions, and error handling: [SWS_UCM_00349], [SWS_UCM_00350], [SWS_UCM_00352], [SWS_UCM_00353], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 38.
• Status inspection, software cluster data model, and history: [SWS_UCM_00355], [SWS_UCM_00356], [SWS_UCM_00357], AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 86, AUTOSAR_AP_SWS_UpdateAndConfigurationManagement p. 87.
• Multi-ECU coordination and interaction with the Vehicle UCM: [SWS_UCM_00343], SWS_VehicleUpdateAndConfigurationManagement p. 16, TPS_ManifestSpecification p. 631.