ISO/TR 24935:2025

Technical
Report
ISO/TR 24935
First edition
Road vehicles — Software update over
2025-07
the air using mobile cellular network
Véhicules routiers — Mise à jour du logiciel à distance (OTA) à
l'aide d'un réseau cellulaire mobile
Reference number
© ISO 2025
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
or ISO’s member body in the country of the requester.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: +41 22 749 01 11
Email: copyright@iso.org
Website: www.iso.org
Published in Switzerland
ii
Contents Page
Foreword .v
Introduction .vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Abbreviated terms . 2
5 General . 3
5.1 Purpose .3
5.2 Structure of this document .4
5.3 Reference model .6
5.4 Cybersecurity model .7
5.4.1 General .7
5.4.2 Use of cryptography .7
5.4.3 Cryptographic key management model .9
6 Preparation of the SUP .11
6.1 General .11
6.2 Format of the SUP .11
6.2.1 General .11
6.2.2 Information to resolve the target vehicles and recipients into recipient vehicles . 12
6.2.3 Information to resolve the target ECUs into recipient ECUs . 12
6.2.4 Vehicle state for successful software update operation . 12
6.2.5 Compatibility with the related ECUs in the recipient vehicles . 12
6.2.6 Dependency with the related ECUs in the recipient vehicles . 12
6.2.7 Interaction with the vehicle user . 13
6.2.8 Information for the prerequisite of the installation and the activation during
the software update operation . 13
6.3 Verification and validation of an SUP . 13
7 Operation between infrastructure and vehicles .13
7.1 General . 13
7.2 Capabilities and functions in the infrastructure .14
7.2.1 Structure of update server .14
7.2.2 Cybersecurity check . 15
7.2.3 Resolving the target vehicles into recipients . 15
7.2.4 Failure handling .16
7.2.5 Mobile cellular network .16
7.3 Flow of activities .16
7.3.1 Uploading and storing SUP .17
7.3.2 Resolving target vehicles into recipients .18
7.3.3 Verifying the VCI .19
7.3.4 Transferring SUPs and receiving the results of the software update operation . 20
7.3.5 Managing and maintaining of software update campaign . 22
8 Software update operation in vehicles .22
8.1 General . 22
8.1.1 General . 22
8.1.2 Overview of EE architecture in vehicle . 23
8.1.3 Generic functions of components .24
8.2 Overview of procedures for software update operation . 25
8.2.1 General . 25
8.2.2 Preparation and receipt of software update operations . 25
8.2.3 Installation of software update operation . 26
8.2.4 Activation of software update operation .27
8.3 Generic redundant flash bootloader . 28

iii
8.3.1 General . 28
8.3.2 General operation of the bootloader in an ECU . . 28
8.3.3 BSBs receipt and installation operations of the bootloader in an ECU . 29
8.3.4 Fail recovery operation of the bootloader in an ECU .31
8.4 Communications within the vehicle .32
8.4.1 General .32
8.4.2 Generic Ethernet protocols in vehicle.32
8.4.3 UDSonIP in AVTP for update in vehicle .32
9 Evaluation of overall software update operation .34
9.1 General . 34
9.2 Evaluation of software update operation . 35
9.2.1 General . 35
9.2.2 Evaluation of transmission speed between CM server and ECUs . 35
9.2.3 Evaluation of successful transfer . 36
Annex A (informative) KMIP request/response message .38
Bibliography .44

iv
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
ISO draws attention to the possibility that the implementation of this document may involve the use of (a)
patent(s). ISO takes no position concerning the evidence, validity or applicability of any claimed patent
rights in respect thereof. As of the date of publication of this document, ISO had not received notice of (a)
patent(s) which may be required to implement this document. However, implementers are cautioned that
this may not represent the latest information, which may be obtained from the patent database available at
www.iso.org/patents. ISO shall not be held responsible for identifying any or all such patent rights.
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 32,
Electrical and electronic components and general system aspects.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

v
Introduction
The electronic control units (ECUs) and their software have become major components of road vehicles in
recent years. Software, in particular, must be updated as it is frequently revised.
— The need for updating software is more prominent as cybersecurity and passenger safety become more
dependent on software.
— The software update operation was usually performed at workshops, which was very inconvenient for
vehicle users.
The ECUs requiring software update operations range from a smart key to power train ECUs.
— These days, the software update operation for ECUs has become possible even while vehicles are serviced
in gas stations. Moreover, mobile cellular networks can be used to update vehicle software regardless of
the vehicle location.
ISO 24089 was published as the standard for vehicle software update engineering. ISO 24089 addresses
the requirements on the organization, software update project, infrastructure level, vehicle and vehicle-
systems level, software update package and software update campaign, among others. However, ISO 24089
does not address the actual technologies and procedures for updating software.
This document describes an actual experience involving technologies and systems for updating software
using mobile cellular networks. In addition, the results of verification by mounting the ECU developed in this
document on an actual vehicle are included.

vi
Technical Report ISO/TR 24935:2025(en)
Road vehicles — Software update over the air using mobile
cellular network
1 Scope
This document describes use cases and activities for updating software in vehicles over the air using mobile
cellular network. This document provides a case study on the use of International Standards in preparing
software update packages, managing infrastructure and operation within the vehicles.
This document includes descriptions of a reference model for software update operations and metadata
which can be used during the software update operations.
2 Normative references
The following documents are referred to in the text in such a way that some or all of their content constitutes
requirements of this document. For dated references, only the edition cited applies. For undated references,
the latest edition of the referenced document (including any amendments) applies.
ISO 24089, Road vehicles — Software update engineering
3 Terms and definitions
For the purposes of this document, the terms and definitions given in ISO 24089 and the following apply.
ISO and IEC maintain terminology databases for use in standardization at the following addresses:
— ISO Online browsing platform: available at https:// www .iso .org/ obp
— IEC Electropedia: available at https:// www .electropedia .org/
3.1
to archive
to store logs and records on a permanent medium such that they may be retrieved (3.9) at a later date
3.2
authentication
act of proving an assertion, such as the identity of a computer system user
3.3
authorization
formal permission to use a product within specified application constraints
3.4
cryptography
discipline that embodies the principles, means, and methods for the transformation of data in order to hide
their semantic content, prevent their unauthorized use, or prevent their undetected modification
[SOURCE: ISO/IEC 2382:2015, 2126278]
3.5
Ethernet
communication protocol specified in ISO/IEC/8802-3:2021

3.6
metadata
data that provides information about other data
3.7
mobile cellular network
telecommunications network where the link to and from end nodes is wireless and the network is distributed
over land areas called cells
3.8
non-repudiation
ability to prove the occurrence of a claimed event or action and its originating entities
[SOURCE: ISO/IEC 27002:2022, 3.1.19]
3.9
to retrieve
to restore from the archived (3.1) data
3.10
validation
confirmation, through the provision of objective evidence, that the cybersecurity goals of the item are
adequate and are achieved
[SOURCE: ISO/SAE 21434:2021, 3.1.36]
3.11
verification
confirmation, through the provision of objective evidence, that specified requirements have been fulfilled
[SOURCE: ISO/SAE 21434:2021, 3.1.37]
4 Abbreviated terms
ACC Accessory
AVB Audio Video Bridge
AVN Audio Video Navigation
AVTP Audio Video Transport Protocol
BCU Body Control Unit
BSB Binary Software Block
CAN Controller Area Network
CM Campaign Management
DoIP Diagnostic communication over Internet Protocol
DS Digital Signature
ECU Electronic Control Unit
EE Electrical/Electronic
EOL End of Line
E2E End to End
HMI Human Machine Interface
HSM Hardware Security Module
ITS Intelligent Transport Systems
IVN In-Vehicle Network
KMIP Key Management Interoperability Protocol
KMS Key Management Server
LDM Local Dynamic Map
LKAS Lane Keeping Assist System
MAC Message Authentication Code
MFA Multi Factor Authentication
NIST National Institute of Standards and Technology
OTA Over The Air
OTAM OTA Master
OTP One Time Password
SM Software Management
SUP Software Update Package
SUV Sport Utility Vehicles
TLS Transport Layer Security
TSN Time-Sensitive Networking
UDS Unified Diagnostic Services
URL Uniform Resource Locator
VCI Vehicle Configuration Information
VIN Vehicle Identification Number
VM Vehicle Management
VMG Vehicle Mobile Gateway
5 General
5.1 Purpose
The purpose of this document is to share the technical experiences in using mobile cellular networks for
updating software in vehicle ECUs, and to share the experience in the adoption of related International
Standards such as ISO 24089.
5.2 Structure of this document
Clause 5 describes the purpose and the structure of this document. It also describes basic and cybersecurity
models for the software update operation.
Clause 6 describes the preparation of the software update package. This clause includes roles of vehicle
manufacturers and suppliers in the software update process for vehicle ECUs.
Clause 7 describes the capabilities and functions, which are used to perform the activities during the
software update campaign in the update server. It also describes the flow of activities involved during the
software update operation.
Clause 8 describes the software update operations. This clause includes software update operations in the IVN.
Clause 9 describes the results of evaluating the software update operation in actual vehicles.

Key
1 software update packages (SUPs) are released
2 vehicle is powered off and on
Figure 1 — Overview of software update activities

Figure 1 shows the overview of the software update activities and the corresponding clauses which explain
the activities.
Once the SUP is ready, it is released. Then the interaction of the infrastructure and the vehicle takes place.
When the vehicle is turned on (power on), the vehicle is ready to install a new SUP in ACC mode and begins
to write the SUP in an in-active bank. After the ACC mode is turned off, the installation and activation take
place if the vehicle user agrees to the software update operations.
5.3 Reference model
The basic model, which is used in this document, consists of three parts: preparation of the SUP,
infrastructure and vehicle (see Figure 2).
Key
1 mobile cellular network
2 in-vehicle network (e.g. CAN or automotive Ethernet)
Figure 2 — Reference model for the software update activities
The preparation of the SUP part covers the development of the software to be updated, and tools or
methodologies for identifying the target vehicles whose ECU is to be updated by the software update
operation. It also addresses generation of the metadata which can be used by infrastructure or vehicles
during the software update operation, and creation of the SUP by adding appropriate additional information
such as cybersecurity-related information. However, the development of the software itself is out of scope in
this document.
The infrastructure includes a mobile cellular network and the update server which consists of a CM server,
VM server and SM server (see Clause 7). The infrastructure covers uploading the SUP into the storage server,
validating the SUP, and managing the VCI. It also performs resolving the target vehicles, communicating
with the target vehicles, transferring the SUP into the recipients, and handling the result of the software
update operation.
The architecture of the vehicle is depicted in Figure 3. The software update operation within the vehicle is
managed by the VMG, which communicates with the CM server via the mobile cellular network, receives the
SUP from the server, reports the result of the software update operation to the server, checks the vehicle
state, validates the received SUP, transfers the received SUP into the corresponding ECU, and checks the
result of the installation and activation of software in the ECU.
In-vehicle networks typically include CAN and automotive Ethernet, which are linked through an Ethernet
gateway. All ECUs to be updated by the software update operation are connected to the automotive Ethernet
network for the purpose of faster and parallel data transfer. The ECUs to be updated support a dual bank
memory and UDS diagnostic communication capabilities.

Key
a
See 8.1.3.
b
See 8.1.2.
c
See 8.1.2 and 8.1.3.
Figure 3 — Architecture of the vehicle
5.4 Cybersecurity model
5.4.1 General
This subclause addresses the cryptographic techniques and corresponding cryptographic key management
models used in this document. 5.4.2 introduces the cryptographic techniques used in this document to
provide basic security services. 5.4.3 proposes solutions for supplier and vehicle manufacturer cryptographic
key management models for verification and validation of the SUP.
5.4.2 Use of cryptography
Corruption or tampering of data while handling it might have safety-related impact(s) on vehicle(s). Hence,
data used during preparation or software update operation is protected by cryptographic techniques.
Cryptographic techniques used to provide or support several basic security services are as follows:
— Confidentiality
— TLS is used to provide confidentiality in communication between vehicle manufacturers, suppliers,
and vehicles. In this document, cryptographic suites providing a security strength of 128 bits or
higher are utilized.
— Cryptographic objects (e.g. certificates, private keys) used by vehicle manufacturers and suppliers
are encrypted and stored in their respective KMS to prevent leakage (see 5.4.3).
— Identity authentication
— Any access to VCI and SUPs is controlled using identity authentication. The access to the update
server is allowed only to the authorized person and the vehicle that is authorized to access the
corresponding SUP.
— The OASIS KMIP is used as a protocol to communicate with the KMS. KMIP supports MFA using ID/
password or additional OTP as identity authentication methods to grant access the KMS. In this
document, it is possible to access the KMS using a private key/certificate that is pre-issued and
securely provided by the KMS administrator.
— Integrity and source authentication
— The SUP consists of multiple BSBs, along with the DS values for each block, as illustrated in Figure 4.
— The DS, generated with the supplier’s private key, ensures integrity and source authentication for a
BSB. The recipient can verify the integrity and source of the software by performing DS verification
using the supplier’s certificate, which is pre-injected to the ECU’s HSM.
— The DS, generated with the vehicle manufacturer’s private key, ensures integrity and source
authentication for an SUP. The recipient can verify the integrity and source of the SUP by performing
DS verification using the vehicle manufacturer’s certificate, which is pre-injected into the VMG’s HSM.
Figure 4 — Structure of the SUP
— Authorization
— The vehicle manufacturer’s private key for the DS of SUPs is managed in the KMS located in a secure
room controlled by the vehicle manufacturer, and only authorized users (e.g. developer, build server)
can request signature generation.
— The supplier’s private key for the DS of software is managed in the KMS located in a secure room
controlled by the supplier, and only authorized users (e.g. developer, build server) can request
signature generation.
— Keys are logically separated for each purpose and model by using the group concept, which is a
system object in KMIP v.3.0.
— Each group has its own cryptographic objects and users. Users can access only the cryptographic
objects of their own group.
NOTE The user is a person or entity that uses cryptographic objects in the KMS. This can refer to developers,
build servers, EOLs, etc.
— Non-repudiation
— Vehicle manufacturers and suppliers use the non-repudiation property of DSs to protect against
future legal disputes, including defects in distributed software.

5.4.3 Cryptographic key management model
5.4.3.1 General
This subclause describes how the supplier and the vehicle manufacturer generate and use private keys/
certificates in their respective KMS to ensure source authentication and non-repudiation.
Appropriate key management requires secure processes for generating, storing, archiving, retrieving,
distributing, retiring and destroying cryptographic keys.
This document uses OASIS’s KMIP as the communication protocol between the KMS and the entities
performing DSs.
The ISO/IEC 11770 series and NIST SP 800-57 provide further information on key management.
5.4.3.2 Supplier’s key management model
The supplier creates and manages private keys/certificates in its own KMS for source authentication and
non-repudiation of BSBs. The supplier’s certificate injection ensures that each ECU can verify the authenticity
of the BSB, while DS provide proof that the BSB was distributed by the legitimate supplier. The EOL obtains
the appropriate certificates for each ECU from KMS and injects them into the ECU (see Figure 5).
Figure 5 — Supplier’s certificate injection
— Supplier’s certificate injection
— Suppliers manage private keys/certificates separately for each ECU model, production year, etc.
— Supplier's certificate is injected during ECU production to verify the integrity and authenticity of the
BSB using the supplier's DS.
— ECU that offers this feature has a built-in HSM to securely store supplier's certificates.
— The KMIP request/response message pairs for generating the corresponding private key/certificate
are shown in A.1.
— The KMIP request/response message pairs for locating and obtaining the certificates that are
shown in A.2.
— DSs
— The supplier signs the BSB with a private key to prove that the BSB was legitimately distributed by
the supplier.
— The KMIP request/response message pairs for locating and signing with the corresponding private
key are shown in A.3 and A.4.
5.4.3.3 Vehicle manufacturer’s key management model
The vehicle manufacturer creates and manages private keys/certificates in its own KMS for source
authentication and non-repudiation of SUPs. Vehicle manufacturer’s certificate injection ensures that each
VMG can verify the authenticity of the SUP, while DSs provide proof that the SUP was distributed by the
legitimate vehicle manufacturer. The flash station obtains the appropriate certificates for each VMG from
KMS and injects them into the VMG (see Figure 6).
Figure 6 — Vehicle manufacturer’s certificate injection
— Vehicle manufacturer’s certificate injection
— Vehicle manufacturer manages private keys/certificates separately for each car model, production
year, etc.
— Vehicle manufacturer’s certificate is injected during VMG production to verify the integrity and
authenticity of the SUP with the vehicle manufacturer’s DS.
— VMG has a built-in HSM to securely store certificates.
— The KMIP request/response message pairs for generating the corresponding private key/certificate
are shown in A.1.
— The KMIP request/response message pairs for locating and to obtaining the certificates are
shown in A.2.
— DSs
— Vehicle manufacturer performs verification and validation of the BSB from the supplier before
constructing an SUP.
— Vehicle manufacturer signs the SUP with a private key to prove that the SUP was legitimately
distributed by the vehicle manufacturer.
— The KMIP request/response message pairs for locating and signing with the corresponding private
key is shown in A.3 and A.4.
6 Preparation of the SUP
6.1 General
The campaign initiator (vehicle manufacturer) makes all plans for software update engineering activities.
According to the established plan, the suppliers in charge of the target ECUs develop the software according
to the software update project plan. The supplier develops the software code by updating the existing
software based on the request for update. The software of the update targets is verified by the supplier
and delivered to the campaign initiator. The software of the update targets includes the target related
information. In addition, the software of the update targets includes specific conditions for software update
operation (metadata such as compatibility, vehicle state, etc.). The target related information is prepared in
accordance with the criteria defined by the vehicle manufacturer.
The vehicle manufacturer receives software from the supplier for the ECU to be updated. The vehicle
manufacturer integrates the software submitted by the supplier to form the SUP. In addition, the SUP
includes information about the target at the vehicle and the ECU level. The vehicle manufacturer verifies the
functionality and security attributes of the SUP and uploads it to the update server.
The metadata is used to allow the update server or the recipient vehicle to perform the activities or
operations for the software update operation appropriately, which include identification of the recipient
vehicle, verifying if the target vehicle is in the proper states for the software update operation, and indicating
the communication for the software update operation. Also, the metadata include information to indicate
behaviour(s) or performance(s) of the function in other ECU(s) which is affected by updating the software in
the target ECU.
The additional data is used to assure cybersecurity during the transfer of the SUP up to the recipient. An
example of additional data is a DS of the SUP, which is used to check if there is any tampering during the
transfer of the SUP.
NOTE DS includes information to check the integrity necessary for cybersecurity.
6.2 Format of the SUP
6.2.1 General
The SUP consists of three major parts: a BSB, metadata and DS. The BSB includes an executable software
for the target ECU and data for installation and activation in the software update operation. The metadata
include the following information related to the software update operation:
— information to resolve the target vehicles into recipient vehicles;
— information to resolve the target ECUs into recipient ECUs;
— vehicle states for successful software update operation;
— in-vehicle resources for successful software update operation;
— compatibility with related ECUs in the recipient vehicles;
— dependency with the related ECUs in the recipient vehicles;
— interaction with the vehicle user, if applicable:

— information for the prerequisite of the installation and the activation during the software update
operation, if applicable.
The DS is used to validate the integrity of the SUP by the update server and the recipients.
6.2.2 Information to resolve the target vehicles and recipients into recipient vehicles
The update server checks whether the vehicle belongs to the SUP target and resolves into a recipient of the
SUP. The following information is exchanged for confirmation:
— Vehicle identifier: a unique designation for each recipient vehicle.
— Variant: the variant information is able to identify model, model year, production date, sales area and
unit information.
— Conditions: conditions include parked, engine off, or availability of vehicle functions. Conditions related to
external resources include available or remaining network capacity, workshop availability, connectivity.
6.2.3 Information to resolve the target ECUs into recipient ECUs
When a recipient vehicle is identified, the next step is to determine whether a target ECU exists in the vehicle.
The following information was used in the use case to resolve target ECUs into recipient ECUs:
— ECU identifier: unit information is used as the ECU identifier.
— Version: the version information includes hardware information such as the current version of the
corresponding hardware.
— Software update operation condition: prerequisite for installation and activation. If the software update
operation fails, safe operating procedure is needed.
— Compatibility: compatibility for performing a software update operation means compatibility with
information such as a hardware or software version of the current ECU.
— Type (delta): information about whether a software update operation partially or fully updates the
software
6.2.4 Vehicle state for successful software update operation
The vehicle communicates that it is in the safe vehicle state prior to beginning the software update operation.
The safe vehicle state of software update includes:
— the vehicle driving state (e.g. parked, in motion, engine off);
— the ECU resource state (e.g. available memory size, battery state).
6.2.5 Compatibility with the related ECUs in the recipient vehicles
Compatibility for the SUP(s) is confirmed prior to activation. This confirmation can be performed either
in the vehicle, or in the infrastructure, or both. A vehicle model and year are resolved into specific VIN of
individual vehicles.
6.2.6 Dependency with the related ECUs in the recipient vehicles
Dependency is the effect of software for one vehicle system on the same or other vehicle systems. In
particular, it indicates whether there is a necessity of an additional consideration for the software update
operation. Some measures are needed during the software update operation in order not to affect ECUs with
dependency. But it was not considered in this document.

6.2.7 Interaction with the vehicle user
User interface such as HMI is used for notifying or warning drivers during a software update operation, if
applicable.
6.2.8 Information for the prerequisite of the installation and the activation during the software
update operation
Software update operation condition means prerequisite for installation and activation. If a software update
operation fails, a safe operating procedure is needed, if applicable.
6.3 Verification and validation of an SUP
The verification includes planning, execution and result management. The planning includes specification of
the testing environment. This process ensures that each item or component has been specified, implemented
and integrated correctly. Validation is defined by the following heuristic: any activities whose results answer
the question “are we building appropriately?”.
Since the SUP replaces software in the existing vehicle, completeness and integrity verification is completed
before it is released. In addition, it is assured that the updated content as well as the basic functions operate
without any problems in the vehicle.
Activities related to verification and validation are covered by various international standards, and based
on the content, the following verification and validation methodologies are applied to this document.
The verification and validation of an SUP is achieved before the release of the SUP. Ensuring the integrity
with the package and verification for update releases was considered very important.
— Verification for software
— Regression testing for update changes
— Compatibility check: validation of hardware, software compatibility to be updated
— In-vehicle resources test
— Memory and CPU: consumption test of the vehicle’s memory, battery and CPU which is necessary to
perform updates
— Cybersecurity verification
— Verify that DS is performing its intended function
— Safety validation
— ECU modifications are checked to see if any of them affect safety-related functions, analyse the
impact, and check whether there are any countermeasures in case of failure
7 Operation between infrastructure and vehicles
7.1 General
The infrastructure in this document consists of update server, mobile cellular communication network
and actions of the responsible person in the software update campaign, if applicable. The infrastructure
system is managed and maintained by either the campaign initiator or a third party such as the mobile
communication network operator.
The update server for the software update campaign consists of three management sub-servers, i.e. a CM
server, a VM server and a SM server. The three management subservers are connected via backbone network.

The infrastructure performs the following during the software update campaign:
— to manage the software update campaign related issues;
— to manage VCI for vehicles of interest;
— to archive and to retrieve the SUP itself with an appropriate identifier;
— to facilitate uploading the SUP to the update server by the responsible person in the software campaign
initiator;
— to validate the integrity and authenticity of the SUP, and the consistency of the metadata in the SUP;
— to resolve targets into recipients for software update campaigns;
— to initiate communications to inform that SUPs are available for software update campaigns;
— to confirm whether a vehicle belongs to the targets of the software update campaign;
— to transfer the SUP;
— to log the failure or successful result during the software update campaign, and the result of the software
update operation in vehicles.
The capabilities and functions in the infrastructure for the software update campaign are described in
7.2, and the detailed activities performed by the infrastructure during the software update campaign are
described in 7.3.
7.2 Capabilities and functions in the infrastructure
7.2.1 Structure of update server
The CM server manages the software update campaign and handles the communications for both the
campaign initiator and the recipient vehicles.
The responsible person is authorized to access the CM server via a dedicated network and is responsible
to upload the SUP through the CM server. He or she also can access the following information related to the
software update campaign through the CM server:
— status information of the software update campaign, including a current status, overall progress, starting
and ending dates;
— progress and results of each software update operation in the software update campaign;
— information related to the target vehicles.
NOTE 1 The information includes VIN, VCI, and the information of the recipients.
For this purpose, the CM server has the capabilities of:
— facilitating the upload of the SUP;
— validating
...