SNIP_ADAPTIVE_PLATFORM_FIGURE_Figure_7_1_VEHICLEUPDATEANDCONFIGURATIONMANAGEMENT

Figure 7.1: Example of V-UCM architecture overview within a vehicle The V-UCM could be considered as a set of add-on features that could enrich any UCM instance. Therefore, as per the UCM APIs, the V-UCM APIs are part of the AUTOSAR Adaptive Platform Services. UCM and V-UCM have separate service instances. The OTA Client establishes a communication between Backend and V-UCM so that they can exchange information of the installed Software Clusters in the vehicle and the Software Clusters available in the Backend. This communication could be triggered by OTA Client with a scheduler and V-UCM to request the updates in case of newly available Software Clusters (pull case) or by Backend to push, for instance, an important security update to a fleet of vehicles (push case). The computation to find new Software Clusters versions and resolution of dependencies between Software Clusters can be either done at V-UCM or Backend. Vehicle Driver interface Adaptive Application is required if it is needed during an update campaign to interact with vehicle human driver through for instance Human- Machine Interface. Download of packages from a Backend could have various financial costs for the driver depending of communication types, so consent from driver could be suitable. Vehicle State Manager Adaptive Application is required if it is needed during an update campaign to control the vehicle state for safety purposes. For instance, it could be required for safety to have standing still vehicle, shut-off engine, closed doors, etc. before starting an UCM activation or during its processing.