ISO/DTS 20003.2

Road vehicles - Human-machine interface (HMI) for over the air (OTA) software updates

This standard provides human machine interface (HMI) design specifications by Over The Air (OTA) software updates for passenger cars (including sport utility vehicles and light trucks) plus commercial vehicles (including heavy trucks and buses). These HMI specifications include state transitions, timing, HMI locations with respect to the driver, types of information, necessary notifications and warnings, confirmation of successful completion, and how deviations from the intended results will be handled, based on sequences defined in ISO24089. It covers software updates facilitated both while driving and while stationary

Véhicules routiers — Interface homme-machine (IHM) pour les mises à jour logicielles sans fil (OTA)

General Information

• Status: Not Published
• ICS: 43.040.15 - Car informatics. On board computer systems
• ICS: 43.060.50 - Electrical and electronic equipment. Control systems
• Technical Committee: ISO/TC 22 - Road vehicles
• Drafting Committee: ISO/TC 22 - Road vehicles
• Current Stage: 5020 - FDIS ballot initiated: 2 months. Proof sent to secretariat
• Start Date: 10-Dec-2025
• Completion Date: 10-Dec-2025

Overview

ISO/DTS 20003.2, titled "Road vehicles - Human-machine interface (HMI) for over the air (OTA) software updates," is an International Organization for Standardization (ISO) technical specification designed to standardize HMI design for OTA software updates in passenger and commercial vehicles. This standard covers vehicles such as passenger cars, SUVs, light trucks, heavy trucks, and buses, addressing HMI requirements to ensure user safety, clarity, and control during OTA software updates.

As vehicles become increasingly connected, OTA updates enable remote modification or enhancement of vehicle software without dealership visits. These updates are essential for improving vehicle functions including advanced driver-assistance systems (ADAS), infotainment, and navigation systems. ISO/DTS 20003.2 provides critical guidance on the design of user interfaces to notify drivers about software update statuses, potential risks, and outcomes, ensuring a safe and user-friendly OTA experience.

Key Topics

• Scope and Application
  This specification defines HMI requirements where human interaction is needed to secure safe, fully understood OTA software update execution. It applies to both stationary and driving conditions, ensuring the vehicle operator is informed during all update stages, including receipt, installation, activation, and failure management.

• HMI Design Guidelines

  • Visual Information: Specifies symbol locations, colors, and lighting for clear recognition by the driver. Symbols are based on ISO 2575 for uniformity-indicating update states like receipt, installation, activation, and errors.
  • Driver Distraction: Emphasizes minimizing driver distraction by aligning visual information with ergonomic principles and regional/national driver distraction guidelines.
  • State Transitions and Timing: Details how to display progress and confirmation messages, and how to handle exceptions in update processes.
  • Notification and Confirmations: Users can be notified, provide consent, and receive confirmation of successful or failed updates based on ISO 24089 processes.

• Use Cases for HMI OTA Updates
  Annex A provides practical examples illustrating different situations where HMI interactions are necessary. These include vehicle operator acceptance of updates inside or outside the vehicle, during ignition-on or ignition-off states, and various operational contexts ensuring update activities do not jeopardize road safety.

• Terminology and Definitions
  The standard defines key terms such as activation, cancellation, electronic control unit (ECU), vehicle state, and software update campaign to promote consistency across automotive OTA update implementations.

Applications

ISO/DTS 20003.2 serves multiple practical applications in the automotive industry, including:

• Enhanced Vehicle Safety
  By providing standardized HMI elements for OTA updates that inform the vehicle operator of update progress and potential risks, this standard supports safe operation during critical software changes.

• Improved User Experience
  Operators receive clear, consistent feedback and notifications regarding software updates, ensuring transparency and confidence in OTA processes.

• Compliance and Interoperability
  Vehicle manufacturers can apply this standard to ensure compliance with international best practices, supporting interoperability across different vehicle models and brands.

• Support for Advanced Features
  OTA updates often involve ADAS, navigation, and entertainment systems. This HMI standard ensures those updates are communicated effectively to the driver without compromising attention or safety.

• Cybersecurity and Software Quality Assurance
  Integrates with ISO 24089 to tie HMI communication with safety and security processes critical to OTA software management.

Related Standards

To fully implement safe and effective OTA software updates with compliant HMIs, reference to the following related ISO standards is essential:

• ISO 24089: Road vehicles - Software update engineering - Defines processes and functions for software updates, establishing safety and cybersecurity frameworks.

• ISO 2575: Road vehicles - Symbols for controls, indicators, and tell-tales - Provides standardized symbol sets used in the OTA HMI.

• ISO 4040: Road vehicles - Location of hand controls, indicators, and tell-tales - Guides ergonomic placement of HMI elements for visibility and accessibility.

• ISO 15008: Road vehicles - Ergonomic aspects of transport information and control systems - Specifies image flashing and other visual presentation standards aiming to minimize driver distraction.

• ISO 20080: Road vehicles - Concepts and terms for vehicle states pertaining to motion and operation.

By aligning OTA software update HMIs with these standards, vehicle manufacturers and system developers can ensure robust, user-friendly, and safe interfaces that meet global ergonomic and safety expectations.

---

Keywords: ISO DTS 20003.2, OTA software updates, human-machine interface, vehicle software update, automotive HMI standards, over the air updates, driver safety, vehicle operator notification, software update symbols, driver distraction, ISO vehicle standards, advanced driver-assistance systems, ADAS update, automotive cybersecurity.

Standards Content (Sample)

FINAL DRAFT
Technical
Specification
ISO/DTS 20003
ISO/TC 22/SC 39
Road vehicles – Human-machine
Secretariat: ANSI
interface (HMI) for over the air
Voting begins on:
(OTA) software updates
2025-07-28
Voting terminates on:
2025-09-22
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
ISO/DTS 20003:2025(en) © ISO 2025

FINAL DRAFT
ISO/DTS 20003:2025(en)
Technical
Specification
ISO/DTS 20003
ISO/TC 22/SC 39
Road vehicles – Human-machine
Secretariat: ANSI
interface (HMI) for over the air
Voting begins on:
(OTA) software updates
Voting terminates on:
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO/DTS 20003:2025(en) © ISO 2025

ii
ISO/DTS 20003:2025(en)
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Design guidelines . 4
4.1 General .4
4.2 Content . .4
4.3 Visual information .4
4.3.1 General .4
4.3.2 Location .4
4.3.3 Symbol .5
4.3.4 Symbol attention .5
4.3.5 Colour .5
4.4 Driver distraction .5
Annex A (informative) OTA HMI use cases . 6
Bibliography . 19

iii
ISO/DTS 20003:2025(en)
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 document 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 39,
Ergonomics.
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.

iv
ISO/DTS 20003:2025(en)
Introduction
The number of vehicles with internet connectivity capability is increasing. As a result, these vehicles are
more vulnerable to hackers accessing the vehicle. Due to this, it is important to provide safe software
updates to ensure vehicle safety.
Over the air (OTA) software updates add or modify vehicle features. Software require periodic improvements
or feature additions. For example, advanced driver-assistance systems (ADAS), entertainment systems and
navigation systems can be updated without going to the dealership.
The establishment and application of software-update engineering is important to ensure software quality,
cybersecurity and safety. ISO 24089, which defines processes and functionalities for software-update
engineering, has been established. The state of the vehicle is determined to ensure a safe software update. In
the case of an update failure, measures are taken to guarantee safety of the vehicle. If the solution requires
any exchange with the user during any of the OTA update steps, the user can be notified of the OTA update
content, can be informed about the result of the update, and can also have the need to give permission for
the update.
When the completion of an update can affect the safety of the vehicle, the vehicle manufacturer should
demonstrate how the update will be completed safely. If a human-machine interface (HMI) is part of the safe
execution for an OTA update, standardization of the HMI is needed to guarantee the customer understanding
across different products. This is also beneficial in general on any occasion where an HMI can help to explain
influences from OTA updates on the availability or quality of concerned features.
As additional explanation and support for developing specific requirements in case HMI aspects are involved
in securing the safe and/or fully understood execution of an OTA update, use case examples of potential HMI
interactions are provided in Annex A.

v
FINAL DRAFT Technical Specification ISO/DTS 20003:2025(en)
Road vehicles – Human-machine interface (HMI) for over the
air (OTA) software updates
1 Scope
This document provides human-machine interface (HMI) design specifications in case an HMI is needed to
secure the safe and/or fully understood execution of OTA software updates for passenger cars (including
sport utility vehicles and light trucks) and commercial vehicles (including heavy trucks and buses). The
vehicle operator benefits from knowing if an OTA update has been successful or not, if an OTA update
will influence the operation of the vehicle, or if the OTA update influences the quality of a feature. HMI
specifications for the OTA software update provide support in case an HMI is needed in normal conditions,
emergencies, low battery, avoidance of inadvertent actuations, alerts or specific non-standard situations.
2 Normative references
The following documents are referred to in the text in such a way that some or all 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 15008, Road vehicles — Ergonomic aspects of transport information and control systems - Specifications
and test procedures for in-vehicle visual presentation — Image flashing
ISO 2575, Road vehicles — Symbols for controls, indicators and tell-tales
ISO 4040, Road vehicles — Location of hand controls, indicators and tell-tales in motor vehicles
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
activation
step in the software update operation when the relevant parts of an installed software update package (3.13)
become executable on a vehicle, vehicle system or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.2.3, modified — Examples have been removed.]
3.2
cancel
command that stops a previously commanded function
Note 1 to entry: Depending on the software update operation stage, the system may go back to the same initial state
before the update or enter in a fail-safe state.
[SOURCE: ISO 2806:1994, 2.2.6, modified — "cancels" has been replaced by "stops" and the Note 1 to entry
has been added.]
ISO/DTS 20003:2025(en)
3.3
display
electronic device capable of visually communicating information
[SOURCE: ISO 3600:2022, 3.4]
3.4
electronic control unit
ECU
embedded device in a vehicle whose software (3.12) can be updated
[SOURCE: ISO 24089:2023, 3.1.7]
3.5
ignition
power supply in a vehicle that includes an on and off state
3.6
infrastructure
processes and information systems managing any combination of software update operations, software
update campaigns (3.14), documentation and vehicle configuration information, including both digital and
manual activities
Note 1 to entry: Infrastructure can include any combination of servers, tools and manual activities used in the
software update operation.
[SOURCE: ISO 24089:2023, 3.1.10]
3.7
installation
step in the software update operation when the relevant parts of a software update package (3.13) are
written to a vehicle, vehicle system or electronic control unit (ECU) (3.4) but are not yet activated
[SOURCE: ISO 24089:2023, 3.2.2]
3.8
metadata
datasets, such as software updates, that are intended to be deployed in vehicle systems or electronic control
units (ECUs) (3.4)
Note 1 to entry: Metadata can include vehicle and safety conditions, compatibility information, software (3.12) versions,
necessary in-vehicle resources, information for user to be displayed through a human-machine interface (HMI).
3.9
over the air
OTA
data channel operated by a mobile network operator for the remote management of components resident in
the mobile device
Note 1 to entry: Over the air is the software update distribution method that acts as a mechanism for distributing
software update packages (3.13) during software update campaigns (3.14) in ISO 24089.
[SOURCE: ISO 12812-1:2017, 3.37, modified — Note 1 to entry has been added.]
3.10
potential risk
state in which the vehicle cannot be driven or has similar functional restrictions

ISO/DTS 20003:2025(en)
3.11
receipt
step in the software update operation when a tool, vehicle, vehicle system or electronic control unit (ECU)
(3.4) receives a software update package (3.13)
[SOURCE: ISO 24089:2023, 3.2.1, modified — Examples have been removed.]
3.12
software
computer programs and associated data intended for installation (3.7) on vehicles, vehicle systems or
electronic control unit (ECU) (3.4), that may be dynamically written or modified during execution
[SOURCE: ISO 24089:2023, 3.1.15]
3.13
software update package
set of software (3.12) and associated metadata (3.8) that is intended to be deployed to one or more vehicles,
vehicle systems or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.1.20]
3.14
software update campaign
sequence of identifying targets (3.17) and resolving recipients; distributing software update packages (3.13);
and monitoring and documenting results of software update operations
[SOURCE: ISO 24089:2023, 3.1.16]
3.15
stage
step in the software update process
3.16
symbol
visually perceptible figure used to transmit information independently of language, produced by drawing,
printing or other means
[SOURCE: ISO 2575:2021, 3.1]
3.17
target
one or more classes of vehicles, vehicle systems or electronic control unit (ECU) (3.4) determined by vehicle
configuration information
[SOURCE: ISO 24089:2023, 3.1.23]
3.18
tell-tale
display (3.3) that indicates, by means of a light-emitting device, the actuation of a device, a correct or
defective functioning or condition, or a failure to function
[SOURCE: ISO 2575:2021, 3.2]
3.19
vehicle state
condition of the vehicle at a point in time with regard to motion and operation
Note 1 to entry: Stationary, moving, normally operating, non-operating vehicle (e.g. parked, stationary, driving, engine off).
[SOURCE: ISO 20080:2019, 3.12.1]

ISO/DTS 20003:2025(en)
3.20
vehicle user
person operating, driving, owning or managing a vehicle
[SOURCE: ISO 24089:2023, 3.1.26, modified — Note 1 to entry was removed.]
3.21
vehicle operator
person operating, driving a vehicle
4 Design guidelines
4.1 General
The purpose of Clause 4 is to provide guidance if visual information is used to secure the safety of the
OTA software update by specifying an HMI to make the vehicle operator aware of any potential risks to
the vehicle user and/or other road users before the execution of the OTA software update. An example to
illustrate potential interactions with the vehicle operator while the OTA software is updating is shown in
Figure 1.
a
User consent skipped if settings are set accordingly and no special preconditions have to fulfilled by customer.
b
Only if safe state is need.
Figure 1 — Example to illustrate potential vehicle operator interactions during an OTA software update
Annex A provides supplementary details with use cases and examples for potential HMI interactions to
handle OTA updates for different types of features.
4.2 Content
When updating vehicle software via OTA, information about the content which is required in ISO 24089
should be provided to the vehicle operator.
4.3 Visual information
4.3.1 General
Subclause 4.3 specifies the location of symbols, lighting of the information and what colours should be used
for visual information to notify the vehicle operator.
4.3.2 Location
When an HMI is part of the solution to support OTA software updates, the visual information shall be located
so that the vehicle operator recognizes and can follow the update procedure and gets notified about any
potential risks to the vehicle user, and/or other road users during the execution of the update until it is

ISO/DTS 20003:2025(en)
completed. The guidance regarding display visibility in ISO 4040 shall be followed when the OTA software
updates concern vital functions for operating the vehicle.
4.3.3 Symbol
The symbols for OTA software updates specified in ISO 2575 shall be used to indicate the status of the
software update. This includes, but is not limited to, receipt, installation, activation and update failure.
Symbols are not needed if there is no potential risk to the vehicle operator during the OTA update, or if be
shown that other visual information fulfils the same purpose.
EXAMPLE 1 After the software update has been installed and the ignition is turned off, the vehicle cannot be moved
for 10 min, so the above symbol will flash in the meter until the vehicle is safe to drive.
EXAMPLE 2 The software update for the vehicle is accepted by a terminal outside the vehicle and the software
update has been installed. The display indicates that the software update has been accepted, that the installation is
complete, and that the vehicle will be able to move until the ignition is turned off.
4.3.4 Symbol attention
If symbols according to the above are needed to get the attention from the vehicle operator while progressing
any stage of the OTA software updates, they shall be in accordance with the requirements of ISO 15008.
EXAMPLE 1 In the case of a brake system update, the green OTA tell-tale blinks before acceptance because without
consent, the vehicle becomes undrivable.
EXAMPLE 2 In the case of a navigation system update, the tell-tale is not turned on because the vehicle will keep
driving without any risk.
4.3.5 Colour
Tell-tale colours shall follow the guidance for use of colours in ISO 2575.
4.4 Driver distraction
The OTA HMI should consider the impact on driver glance behaviour to avoid driver distraction. The OTA
HMI should be consistent with regional and/or international driver distraction guidelines.

ISO/DTS 20003:2025(en)
Annex A
(informative)
OTA HMI use cases
A.1 General
This annex provides additional explanations for situations when an HMI can be needed. This annex lists use
cases and provides examples of how OTA software updates can be handled for different kinds of systems.
A.2 Use cases
Depending on the specifications of the software and the linkage with external terminals, it is possible to not
only accept software updates in the vehicle, but also to accept them outside the vehicle. Table A.1 shows an
example of vehicle system operation patterns for the riding condition of vehicle users and locations where
the vehicle user or vehicle operator accept any step in the OTA software update activity.
Table A.1 — OTA use case of OTA software update
Vehicle state time
Operation of vehicle systems
Where to
of acceptance
Use case Consenter
accept
(EXAMPLE)
(EXAMPLE)
Accepted while the vehicle Vehicle oper- Software update is executed
A In the car Ignition on and off
operator is in the vehicle ator when ignition off
A software update is per-
Accepted without a vehicle
formed and continues.
operator in the vehicle. Outside
B-1 Vehicle user Ignition off
He/she does not board the car
Ignition on is possible after
during the update
update is complete
A software update is per-
Accepted without a vehicle
formed and continues.
operator in the vehicle. Outside
B-2 Vehicle user Ignition off
He/she gets on during the the car
Ignition on is possible after
update execution
update is complete
Vehicle users
Accepted from outside of
Outside who are Software update execution
B-3.1 the vehicle and the opera- Ignition on
the car outside of the does not run
tor is in the vehicle
vehicle
Vehicle users Software update execution is
Accepted from outside of
Outside who are started at next ignition off
B-3.2 the vehicle and the opera- Ignition on
the car outside of the
tor is in the vehicle
vehicle
NOTE B-3.2 is not recommended.
Table A.2 shows the cases in which updates are per
...

•••• PRPROTOTEECCTEDTED 関関係者外係者外秘秘
© ISO #### – All rights reserved
1 ISO/DTS 20003
2 ISO/TC 22/SC 39/WG 3
3 Secretariat: XXXX ANSI
4 Date: 2025-07-11
5 Road Vehicles – Overvehicles – Human-machine interface
6 (HMI) for over the Airair (OTA) Software Update Human
7 Machine Interfacesoftware updates
9 WD/CD/DIS/FDIS stage
11 Warning for WDs and CDs
12 This document is not an ISO International Standard. It is distributed for review and comment. It is
13 subject to change without notice and may not be referred to as an International Standard.
14 Recipients of this draft are invited to submit, with their comments, notification of any relevant patent
15 rights of which they are aware and to provide supporting documentation.
16 To help you, this guide on writing standards was produced by the ISO/TMB and is available at
17 A model manuscript of a draft International Standard (known as “The Rice Model”) is available at
•••• PRPROTOTEECCTEDTED 関関係者外係者外秘秘
ISO #####-#:####(X)
2 © ISO #### – All rights reserved

•• PROTECTED 関係者外秘
ISO/DTS 20003:(en)
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
Fax: [phone]
EmailE-mail: [e-mail]
Website: www.iso.orgwww.iso.org
Published in Switzerland
© ISO #### 2025 – All rights reserved
iii
•• PROTECTED 関係者外秘
ISO/DTS 20003:(en)
Contents
Foreword . v
Introduction . vi
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Design guidelines . 4
4.1 General. 4
4.2 Content . 5
4.3 Visual information . 5
4.4 Driver distraction . 6
Annex A (informative) OTA HMI use cases . 7
Bibliography . 24

This template allows you to work with default MS Word functions and styles. You can use these if you want to
maintain the Table of Contents automatically and apply auto-numbering.
To update the Table of Contents please select it and press "F9".
© ISO #### 2025 – All rights reserved
iv
•• PROTECTED 関係者外秘
ISO/DTS 20003:(en)
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 documentsdocument 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).
Attention is drawnISO draws attention to the possibility that some of the elementsimplementation of this
document may beinvolve the subjectuse 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. Details of any patent rights identified during the development of the
document will be in the Introduction and/or on the ISO list of patent declarations received (see ).
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 Vehiclesvehicles, Subcommittee SC 39,
Ergonomics.
A list of all parts in the ISO ##### series can be found on the ISO website.
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.
© ISO #### 2025 – All rights reserved
v
•• PROTECTED 関係者外秘
ISO/DTS 20003:(en)
Introduction
The number of vehicles with internet connectivity capability is increasing. As a result, these vehicles are more
vulnerable to hackers accessing the vehicle. Due to this, it is important to provide safe software updates to
ensure vehicle safety.
Over the air (OTA) software updates add or modify vehicle features. Software requiresrequire periodic
improvements or feature additions. For example, Advanced Driver-Assistance Systemsadvanced driver-
assistance systems (ADAS), entertainment systems and navigation systems can be updated without going to
the dealer. dealership.
The establishment and application of software-update engineering is important to ensure software quality,
cybersecurity, and safety. ISO 24089, which defines processes and functionalities for software-update
engineering, has been established. The state of the vehicle is determined to ensure a safe software update. In
the case of an update failure, measures will beare taken to guarantee safety of the vehicle. If the solution
requires any exchange with the user during any of the OTA update steps, the user can be notified of the OTA
update content;, can be informed about the result of the update;, and can also have the need to give permission
for the update.
When the completion of an update can affect the safety of the vehicle, the vehicle manufacturer shallshould
demonstrate how the update will be completed safely. If a Human Machine Interfacehuman-machine interface
(HMI) is part of the safe execution for an OTA update, standardization of the HMI is needed to guarantee the
customer understanding across different products. This is also beneficial in general on any occasion where an
HMI can help to explain influences from OTA updates on the availability or quality of concerned features.
As additional explanation and support for developing specific requirements in case HMI aspects are involved
in securing the safe and/or fully understood execution of an OTA update, use case examples of potential HMI
interactions are provided in Annex AAnnex A. .
© ISO #### 2025 – All rights reserved
vi
ISO/DTS 20003:(en)
Road Vehicles – Overvehicles – Human-machine interface (HMI) for
over the Airair (OTA) Software Update Human Machine
Interfacesoftware updates
1 1 Scope
This document provides human-machine interface (HMI) design specifications in case an HMI is needed to
secure the safe and/or fully understood execution of OTA software updates for passenger cars (including sport
utility vehicles and light trucks) and commercial vehicles (including heavy trucks and buses). The vehicle
operator benefits from knowing if an OTA update has been successful or not, if an OTA update will influence
the operation of the vehicle, or if the OTA update influences the quality of a feature. HMI specifications for the
OTA software update provide support in case an HMI is needed in normal conditions, emergencies, low
battery, avoidance of inadvertent actuations, alerts, and / or specific non-standard situations.
2 2 Normative references
The following documents are referred to in the text in such a way that some or all 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:2023 Road vehicles — Software update engineering
ISO 15008, Road vehicles — Ergonomic aspects of transport information and control systems - Specifications and
test procedures for in-vehicle visual presentation — Image flashing
ISO 2575, Road vehicles — Symbols for controls, indicators and tell-tales
ISO 4040, Road vehicles — Location of hand controls, indicators and tell-tales in motor vehicles
ISO 20080 Road vehicles — Information for remote diagnostic support — General requirements, definitions
and use cases
ISO 9241-302:2008 — Ergonomics of human-system interaction Part 302: Terminology for electronic visual
displays
3 3 Terms and definitions
For the purposes of this document, the following terms and definitions apply.
ISO and IEC maintain terminologicalterminology databases for use in standardization at the following
addresses:
— ISO Online browsing platform: available at https://www.iso.org/obphttps://www.iso.org/obp
— IEC Electropedia: available at https://www.electropedia.org/
3.1 3.1
activation
step in the software update operation when the relevant parts of an installed software update package (3.13)
become executable on a vehicle, vehicle system, or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.2.3], modified — Examples have been removed.]
ISO/DTS 20003:(en)
3.2 3.2
cancel
command (2.4.3) that cancelsstops a previously commanded function
Note 1 to entry: depending Depending on the software update operation stage, the system may go back to the same
initial state before the update or enter in a fail-safe state.
[SOURCE: ISO 2806:1994 (en),, 2.2.6], modified — "cancels" has been replaced by "stops" and the Note 1 to
entry has been added.]
3.3 3.3
display
electronic display device capable of visiblyvisually communicating information
[SOURCE: 9241-302:2008ISO 3600:2022, 3.4.6]
3.4 3.4
electronic control unit
(ECU)
embedded device in a vehicle whose software (3.12) can be updated
[SOURCE: ISO 24089:2023, 3.1.7]
3.5 3.5
ignition
power supply in a vehicle that includes an on and off state
3.6 3.6
infrastructure
processes and information systems managing any combination of software update operations (3.1.19),,
software update campaigns (3.14(3.1.16),), documentation, and vehicle configuration information (3.1.24),,
including both digital and manual activities
Note 1 to entry: Infrastructure can include any combination of servers, tools, and manual activities used in the software
update operation.
[SOURCE: ISO 24089:2023, 3.1.10]
3.7 3.7
installation
step in the software update operation when the relevant parts of a software update package (3.13) are written
to a vehicle, vehicle system, or electronic control unit (ECU) (3.4) but are not yet activated
[SOURCE: ISO 24089:2023, 3.2.2]
3.8 3.8
metadata
datasets, such as software updates, that are intended to be deployed in vehicle systems or electronic control
units (ECUs) (3.4)
Note 1 to entry: Metadata can include vehicle and safety conditions, compatibility information, software (3.12SW)
versions, necessary in-vehicle resources, information for user to be displayed through a human-machine interface (HMI).
ISO/DTS 20003:(en)
3.9 3.9
over the air
(OTA)
data channel operated by a mobile network operator (3.28) for the remote management of components
resident in the mobile device (3.24)
Note 1 to entry: Over the air is the software update distribution method that acts as a mechanism for distributing
software update packages (3.13) during software update campaigns (3.14) in ISO 24089.
[SOURCE: ISO 12812-1:2017(en),, 3.37], modified — Note 1 to entry has been added.]
3.10 3.10
potential risk
state in which the vehicle cannot be driven or has similar functional restrictions
3.11 3.11
receipt
step in the software update operation when a tool, vehicle, vehicle system, or electronic control unit (ECU)
(3.4) receives a software update package (3.13)
[SOURCE: ISO 24089:2023, 3.2.1], modified — Examples have been removed.]
3.12 3.12
software
computer programs and associated data intended for installation (3.7) on vehicles, vehicle systems, or
electronic control unit (ECU) (3.4,), that may be dynamically written or modified during execution
[SOURCE: ISO 24089:2023, 3.1.15.]]
3.13 3.13
software update package
set of software (3.12) and associated metadata (3.8) that is intended to be deployed to one or more vehicles,
vehicle systems, or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.1.20]
3.14 3.14
software update campaign
sequence of identifying targets (3.17) and resolving recipients; distributing software update packages (3.13;);
and monitoring and documenting results of software update operations
[SOURCE: ISO 24089:2023, 3.1.16]
3.15 3.15
stage
step in the software update process
3.16 3.16
symbol
visually perceptible figure used to transmit information independently of language, produced by drawing,
printing or other means
[SOURCE: ISO 2575:2021, 3.1]
ISO/DTS 20003:(en)
3.17 3.17
target
one or more classes of vehicles, vehicle systems (3.1.25), or electronic control unit (ECU) (3.4units (ECUs)
(3.1.7)) determined by vehicle configuration information (3.1.24)
[SOURCE: ISO 24089:2023, 3.1.23.]]
3.18 3.18
tell-tale
display (3.3) that indicates, by means of a light-emitting device, the actuation of a device, a correct or defective
functioning or condition, or a failure to function
[SOURCE: ISO 2575:2021, 3.2]
3.19 3.19
vehicle state
condition of the vehicle at a point in time with regard to motion and operation
Note 1 to entry: Examples of vehicle states are stationary Stationary, moving, normally operating, non-operating vehicle
(e.g. parked, stationary, driving, engine off)).
[SOURCE: ISO 20080:2019, 3.12.1]
3.20 3.20
vehicle user
person operating, driving, owning or managing a vehicle
[SOURCE: ISO 24089:2023, 3.1.26], modified — Note 1 to entry was removed.]
3.21 3.21
vehicle operator
person operating, driving a vehicle
4 4 Design guidelines
4.1 4.1 General
The purpose of 4this clause is to provide guidance if visual information is used to secure the safety of the OTA
software update by specifying an HMI to make the vehicle operator aware of any potential risks to the vehicle
user and/or other road users before the execution of the OTA software update. An example to illustrate
potential interactions with the vehicle operator while the OTA software is updating is shown in Figure 1Figure
1.
ISO/DTS 20003:(en)
a
User consent skipped if settings are set accordingly and no special preconditions have to fulfilled by customer.
b
Only if safe state is need.
Figure 1 ― — Example to illustrate potential vehicle operator interactions during an OTA software
update.
Annex AAnnex A provides supplementary details with use cases and examples for potential HMI interactions
to handle OTA updates for different types of features.
4.2 4.2 Content
When updating vehicle software via OTA, information about the content which is required in ISO 24089 should
be provided to the vehicle operator.
4.3 4.3 Visual information
4.3.1 This sectionGeneral
4.3 specifies the location of symbols, lighting of the information, and what colours should be used for visual
information to notify the vehicle operator.
4.3.2 4.3.1 Location
When an HMI is part of the solution to support OTA software updates, the visual information shall be located
so that the vehicle operator recognizes and can follow the update procedure and gets notified about any
potential risks to the vehicle user, and/or other road users during the execution of the update until it is
completed. The guidance regarding display visibility in ISO 4040 shall be followed when the OTA software
updates concern vital functions for operating the vehicle.
4.3.3 4.3.2 Symbol
The symbols for OTA software updates specified in ISO 2575 shall be used to indicate the status of the software
update. This includes, but is not limited to, receipt, installation, activation, and update failure. Symbols are not
needed if there is no potential risk to the vehicle operator during the OTA update, or if be shown that other
visual information fulfils the same purpose.
EXAMPLE 1 After the software update has been installed and the ignition is turned off, the vehicle cannot be moved
for 10 min, so the above symbol will flash in the meter until the vehicle is safe to drive.
EXAMPLE 2 The software update for the vehicle is accepted by a terminal outside the vehicle and the software update
has been installed. The display indicates that the software update has been accepted, that the installation is complete,
and that the vehicle will be able to move until the ignition is turned off.
ISO/DTS 20003:(en)
4.3.4 4.3.3 Symbol attention
If symbols according to the above are needed to get the attention from the vehicle operator while progressing
any stage of the OTA software updates, they shall be in accordance with the provisionsrequirements of ISO
15008.
EXAMPLE 1 In the case of a brake system update, the green OTA tell-tale blinks before acceptance because without
consent, the vehicle becomes undrivable.
EXAMPLE 2 In the case of a navigation system update, the tell-tale is not turned on because the vehicle will keep
driving without any risk.
4.3.5 4.3.4 Colour
Tell-tale colours shall follow the guidance for use of colours in ISO 2575.
4.4 4.4 Driver distraction
The OTA HMI should consider the impact on driver glance behaviour to avoid driver distraction. The OTA HMI
should be consistent with regional and/or international driver distraction guidelines.

ISO/DTS 20003:(en)
Annex AAnnex A
(informative)
OTA HMI use cases
A.1 A.1 General
The informative Annex AThis annex provides additional explanations for situations when an HMI can be
needed. The Annex AThis annex lists use cases and provides examples of how OTA software updates can be
handled for different kinds of systems.
A.2 A.2 Use cases
Depending on the specifications of the software and the linkage with external terminals, it is possible to not
only accept software updates in the vehicle, but also to accept them outside the vehicle. Table A.1Table A.1
shows an example of vehicle system operation patterns for the riding condition of vehicle users and locations
where the vehicle user or vehicle operator accept any step in the OTA software update activity.
Table A.1 – — OTA use case of OTA software update.
Vehicle state time Operation of vehicle
Where
of acceptance systems
Use case Consenter
to accept
(EXAMPLE) (EXAMPLE)
Accepted while the
Vehicle Software update is executed
A vehicle operator is in the In the car Ignition on and off
operator when ignition off
vehicle
A software update is
Accepted without a
performed and continues.
vehicle operator in the Outside
B-1 Vehicle user Ignition off
vehicle. He/she does not the car
Ignition on is possible after
board during the update
update is complete
Accepted without a
A software update is
vehicle operator in the
performed and continues.
Outside
B-2 vehicle. He/she gets on Vehicle user Ignition off
the car
Ignition on is possible after
during the update
update is complete
execution
Vehicle users
Accepted from outside of
B- Outside who are Software update execution
the vehicle and the Ignition on
3.1 the car outside of does not run
operator is in the vehicle
the vehicle
Vehicle users Software update execution is
Accepted from outside of
B- Outside who are started at next ignition off
the vehicle and the Ignition on
3.2 the car outside of
operator is in the vehicle
the vehicle
NOTE: B-3.2 is not recommended.

ISO/DTS 20003:(en)
Table A.2
NOTE B-3.2 is not recommended.
Table A.2 shows the cases in which updates are performed for each software update state.
Table A.2 – — In case OTA update is executed as user intended. (=update successfully)
Reference Use case Term of use case Justification
subclause definition
A.3.2A.3.1 Campaign After the campaign registration Vehicle users benefit from understanding the
notification and before the user's consent on need for software updates, vehicle functions
that are restricted during updates (such as the
the campaign
vehicle not being able to drive), and when to
make updates
A.3.3A.3.2 Campaign After the campaign notification and Vehicle users decide whether to update or not
consent before the start of activation (pending) based on events (Updateupdate
changes, restricted vehicle function, estimated
time, etc.) associated with software updates
and input to the vehicle
A.3.4A.3.3 Campaign Between the time you accept the Understand that the vehicle user has accepted
accepted campaign and the time you receive the campaign
a download notification
(A.3.5(A.3.4))
A.3.5A.3.4 D
...

FINAL DRAFT
Technical
Specification
ISO/TC 22/SC 39
Road vehicles — Human-machine
Secretariat: ANSI
interface (HMI) for over the air
Voting begins on:
(OTA) software updates
2025-12-10
Véhicules routiers — Interface homme-machine (IHM) pour les
Voting terminates on:
mises à jour logicielles sans fil (OTA)
2026-02-04
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
Reference number
FINAL DRAFT
Technical
Specification
ISO/TC 22/SC 39
Road vehicles — Human-machine
Secretariat: ANSI
interface (HMI) for over the air
Voting begins on:
(OTA) software updates
Véhicules routiers — Interface homme-machine (IHM) pour les
Voting terminates on:
mises à jour logicielles sans fil (OTA)
RECIPIENTS OF THIS DRAFT ARE INVITED TO SUBMIT,
WITH THEIR COMMENTS, NOTIFICATION OF ANY
RELEVANT PATENT RIGHTS OF WHICH THEY ARE AWARE
AND TO PROVIDE SUPPOR TING DOCUMENTATION.
© ISO 2025
IN ADDITION TO THEIR EVALUATION AS
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
BEING ACCEPTABLE FOR INDUSTRIAL, TECHNO­
LOGICAL, COMMERCIAL AND USER PURPOSES, DRAFT
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
INTERNATIONAL STANDARDS MAY ON OCCASION HAVE
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
TO BE CONSIDERED IN THE LIGHT OF THEIR POTENTIAL
or ISO’s member body in the country of the requester.
TO BECOME STAN DARDS TO WHICH REFERENCE MAY BE
MADE IN NATIONAL REGULATIONS.
ISO copyright office
CP 401 • Ch. de Blandonnet 8
CH-1214 Vernier, Geneva
Phone: [phone]
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ii
Contents Page
Foreword .iv
Introduction .v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Design guidelines . 4
4.1 General .4
4.2 Content . .4
4.3 Visual information .4
4.3.1 General .4
4.3.2 Location .4
4.3.3 Symbol .5
4.3.4 Symbol attention .5
4.3.5 Colour .5
4.4 Driver distraction .5
Annex A (informative) OTA HMI use cases . 6
Bibliography . 19

iii
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 document 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 39,
Ergonomics.
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.

iv
Introduction
The number of vehicles with internet connectivity capability is increasing. As a result, these vehicles are
more vulnerable to hackers accessing the vehicle. Due to this, it is important to provide safe software
updates to ensure vehicle safety.
Over the air (OTA) software updates add or modify vehicle features. Software require periodic improvements
or feature additions. For example, advanced driver-assistance systems (ADAS), entertainment systems and
navigation systems can be updated without going to the dealership.
The establishment and application of software-update engineering is important to ensure software quality,
cybersecurity and safety. ISO 24089, which defines processes and functionalities for software-update
engineering, has been established. The state of the vehicle is determined to ensure a safe software update. In
the case of an update failure, measures are taken to guarantee safety of the vehicle. If the solution requires
any exchange with the user during any of the OTA update steps, the user can be notified of the OTA update
content, can be informed about the result of the update, and can also have the need to give permission for
the update.
When the completion of an update can affect the safety of the vehicle, the vehicle manufacturer should
demonstrate how the update will be completed safely. If a human-machine interface (HMI) is part of the safe
execution for an OTA update, standardization of the HMI is needed to guarantee the customer understanding
across different products. This is also beneficial in general on any occasion where an HMI can help to explain
influences from OTA updates on the availability or quality of concerned features.
As additional explanation and support for developing specific requirements in case HMI aspects are involved
in securing the safe and/or fully understood execution of an OTA update, use case examples of potential HMI
interactions are provided in Annex A.

v
FINAL DRAFT Technical Specification ISO/DTS 20003.2:2025(en)
Road vehicles — Human-machine interface (HMI) for over the
air (OTA) software updates
1 Scope
This document provides human-machine interface (HMI) design specifications in case an HMI is needed to
secure the safe and/or fully understood execution of OTA software updates for passenger cars (including
sport utility vehicles and light trucks) and commercial vehicles (including heavy trucks and buses). The
vehicle operator benefits from knowing if an OTA update has been successful or not, if an OTA update
will influence the operation of the vehicle, or if the OTA update influences the quality of a feature. HMI
specifications for the OTA software update provide support in case an HMI is needed in normal conditions,
emergencies, low battery, avoidance of inadvertent actuations, alerts or specific non-standard situations.
2 Normative references
The following documents are referred to in the text in such a way that some or all 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 15008, Road vehicles — Ergonomic aspects of transport information and control systems - Specifications
and test procedures for in-vehicle visual presentation — Image flashing
ISO 2575, Road vehicles — Symbols for controls, indicators and tell-tales
ISO 4040, Road vehicles — Location of hand controls, indicators and tell-tales in motor vehicles
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
activation
step in the software update operation when the relevant parts of an installed software update package (3.13)
become executable on a vehicle, vehicle system or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.2.3, modified — Examples have been removed.]
3.2
cancel
command that stops a previously commanded function
Note 1 to entry: Depending on the software update operation stage, the system may go back to the same initial state
before the update or enter in a fail-safe state.
[SOURCE: ISO 2806:1994, 2.2.6, modified — "cancels" has been replaced by "stops" and the Note 1 to entry
has been added.]
3.3
display
electronic device capable of visually communicating information
[SOURCE: ISO 3600:2022, 3.4]
3.4
electronic control unit
ECU
embedded device in a vehicle whose software (3.12) can be updated
[SOURCE: ISO 24089:2023, 3.1.7]
3.5
ignition
power supply in a vehicle that includes an on and off state
3.6
infrastructure
processes and information systems managing any combination of software update operations, software
update campaigns (3.14), documentation and vehicle configuration information, including both digital and
manual activities
Note 1 to entry: Infrastructure can include any combination of servers, tools and manual activities used in the
software update operation.
[SOURCE: ISO 24089:2023, 3.1.10]
3.7
installation
step in the software update operation when the relevant parts of a software update package (3.13) are
written to a vehicle, vehicle system or electronic control unit (ECU) (3.4) but are not yet activated
[SOURCE: ISO 24089:2023, 3.2.2]
3.8
metadata
descriptive information associated with software updates, intended for deployment in vehicle systems or
electronic control units (ECUs) (3.4)
Note 1 to entry: Metadata includes vehicle and safety conditions, compatibility information, software (3.12) versions,
required resources, and information to a user via a human-machine interface (HMI). Additionally, necessary
information will be added depending on the content to be updated.
3.9
over the air
OTA
data channel operated by a mobile network operator for the remote management of components resident in
the mobile device
Note 1 to entry: Over the air is the software update distribution method that acts as a mechanism for distributing
software update packages (3.13) during software update campaigns (3.14) in ISO 24089.
[SOURCE: ISO 12812-1:2017, 3.37, modified — Note 1 to entry has been added.]
3.10
potential risk
state in which the vehicle cannot be driven or has similar functional restrictions

3.11
receipt
step in the software update operation when a tool, vehicle, vehicle system or electronic control unit (ECU)
(3.4) receives a software update package (3.13)
[SOURCE: ISO 24089:2023, 3.2.1, modified — Examples have been removed.]
3.12
software
computer programs and associated data intended for installation (3.7) on vehicles, vehicle systems or
electronic control unit (ECU) (3.4), that may be dynamically written or modified during execution
[SOURCE: ISO 24089:2023, 3.1.15]
3.13
software update package
set of software (3.12) and associated metadata (3.8) that is intended to be deployed to one or more vehicles,
vehicle systems or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.1.20]
3.14
software update campaign
sequence of identifying targets (3.17) and resolving recipients; distributing software update packages (3.13);
and monitoring and documenting results of software update operations
[SOURCE: ISO 24089:2023, 3.1.16]
3.15
stage
step in the software update process
3.16
symbol
visually perceptible figure used to transmit information independently of language, produced by drawing,
printing or other means
[SOURCE: ISO 2575:2021, 3.1]
3.17
target
one or more classes of vehicles, vehicle systems or electronic control unit (ECU) (3.4) determined by vehicle
configuration information
[SOURCE: ISO 24089:2023, 3.1.23]
3.18
tell-tale
display (3.3) that indicates, by means of a light-emitting device, the actuation of a device, a correct or
defective functioning or condition, or a failure to function
[SOURCE: ISO 2575:2021, 3.2]
3.19
vehicle state
condition of the vehicle at a point in time with regard to motion and operation
EXAMPLE Stationary, moving, normally operating, non-operating vehicle (e.g. parked, stationary, driving, engine off).
[SOURCE: ISO 20080:2019, 3.12.1]

3.20
vehicle user
person operating, driving, owning or managing a vehicle
[SOURCE: ISO 24089:2023, 3.1.26, modified — Note 1 to entry was removed.]
3.21
vehicle operator
person operating, driving a vehicle
4 Design guidelines
4.1 General
The purpose of Clause 4 is to provide guidance if visual information is used to secure the safety of the
OTA software update by specifying an HMI to make the vehicle operator aware of any potential risks to
the vehicle user and/or other road users before the execution of the OTA software update. An example to
illustrate potential interactions with the vehicle operator while the OTA software is updating is shown in
Figure 1.
a
User consent skipped if settings are set accordingly and no special preconditions have to fulfilled by customer.
b
Only if safe state is need.
Figure 1 — Example to illustrate potential vehicle operator interactions during an OTA software update
Annex A provides supplementary details with use cases and examples for potential HMI interactions to
handle OTA updates for different types of features.
4.2 Content
When updating vehicle software via OTA, information about the content which is required in ISO 24089
should be provided to the vehicle operator.
4.3 Visual information
4.3.1 General
Subclause 4.3 specifies the location of symbols, lighting of the information and what colours should be used
for visual information to notify the vehicle operator.
4.3.2 Location
When an HMI is part of the solution to support OTA software updates, the visual information shall be located
so that the vehicle operator recognizes and can follow the update procedure and gets notified about any
potential risks to the vehicle user, and/or other road users during the execution of the update until it is

completed. The guidance regarding display visibility in ISO 4040 shall be followed when the OTA software
updates concern vital functions for operating the vehicle.
4.3.3 Symbol
The symbols for OTA software updates specified in ISO 2575 shall be used to indicate the status of the
software update. This includes, but is not limited to, receipt, installation, activation and update failure.
Symbols are not needed if there is no potential risk to the vehicle operator during the OTA update, or if be
shown that other visual information fulfils the same purpose.
EXAMPLE 1 After the software update has been installed and the ignition is turned off, the vehicle cannot be moved
for 10 min, so the above symbol will flash in the meter until the vehicle is safe to drive.
EXAMPLE 2 The software update for the vehicle is accepted by a terminal outside the vehicle and the software
update has been installed. The display indicates that the software update has been accepted, that the installation is
complete, and that the vehicle will be able to move until the ignition is turned off.
4.3.4 Symbol attention
If symbols according to the above are needed to get the attention from the vehicle operator while progressing
any stage of the OTA software updates, they shall be in accordance with the requirements of ISO 15008.
EXAMPLE 1 In the case of a brake system update, the green OTA tell-tale blinks before acceptance because without
consent, the vehicle becomes undrivable.
EXAMPLE 2 In the case of a navigation system update, the tell-tale is not turned on because the vehicle will keep
driving without any risk.
4.3.5 Colour
Tell-tale colours shall follow the guidance for use of colours in ISO 2575.
4.4 Driver distraction
The OTA HMI should consider the impact on driver glance behaviour to avoid driver distraction. The OTA
HMI should be consistent with regional and/or international driver distraction guidelines.

Annex A
(informative)
OTA HMI use cases
A.1 General
This annex provides additional explanations for situations when an HMI can be needed. This annex lists use
cases and provides examples of how OTA software updates can be handled for different kinds of systems.
A.2 Use cases
Depending on the specifications of the software and the linkage with external terminals, it is possible to not
only accept software updates in the vehicle, but also to accept them outside the vehicle. Table A.1 shows an
example of vehicle system operation patterns for the riding condition of vehicle users and locations where
the vehicle user or vehicle operator accept any step in the OTA software update activity.
Table A.1 — OTA use case of OTA software update
Vehicle state time
Operation of vehicle systems
Where to
of acceptance
Use case Consenter
accept
(EXAMPLE)
(EXAMPLE)
Accepted while the vehicle Vehicle oper- Software update is executed
A In the car Ignition on and off
operator is in the vehicle ator when ignition off
A software update is per-
Accepted without a vehicle
formed and continues.
operator in the vehicle. Outside
B-1 Vehicle user Ignition off
He/she does not board the car
Ignition on is possible after
during the update
update is complete
A software update is per-
Accepted without a vehicle
formed and continues.
operator in the vehicle. Outside
B-2 Vehicle user Ignition off
He/she gets on during the the car
Ignition on is possible after
update execution
update is complete
Vehicle users
Accepted from outside of
Outside who are Software update execution
B-3.1 the vehicle and the opera- Ignition on
the car outside of the does not run
tor is in the vehicle
vehicle
Vehicle users Software update execution is
Accepted from outside of
Outside who are started at next ignition off
B-3.2 the vehicle and the opera- Ignition on
the car outside of the
tor is in the vehicle
vehicle
NOTE B-3.2 is not recommended.
Table A.
...

ISO/TC 22/SC 39
Secretariat: ANSI
Date: 2025-07-11-25
Road vehicles – — Human-machine interface (HMI) for over the air
(OTA) software updates
Véhicules routiers — Interface homme-machine (IHM) pour les mises à jour logicielles sans fil (OTA)

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
E-mail: [e-mail]
Website: www.iso.org
Published in Switzerland
ii
Contents
Foreword . iv
Introduction . v
1 Scope . 1
2 Normative references . 1
3 Terms and definitions . 1
4 Design guidelines . 4
4.1 General . 4
4.2 Content . 4
4.3 Visual information . 5
4.4 Driver distraction . 5
Annex A (informative) OTA HMI use cases . 6
Bibliography . 23

iii
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 document 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 39,
Ergonomics.
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.
iv
Introduction
The number of vehicles with internet connectivity capability is increasing. As a result, these vehicles are more
vulnerable to hackers accessing the vehicle. Due to this, it is important to provide safe software updates to
ensure vehicle safety.
Over the air (OTA) software updates add or modify vehicle features. Software require periodic improvements
or feature additions. For example, advanced driver-assistance systems (ADAS), entertainment systems and
navigation systems can be updated without going to the dealership.
The establishment and application of software-update engineering is important to ensure software quality,
cybersecurity and safety. ISO 24089, which defines processes and functionalities for software-update
engineering, has been established. The state of the vehicle is determined to ensure a safe software update. In
the case of an update failure, measures are taken to guarantee safety of the vehicle. If the solution requires any
exchange with the user during any of the OTA update steps, the user can be notified of the OTA update content,
can be informed about the result of the update, and can also have the need to give permission for the update.
When the completion of an update can affect the safety of the vehicle, the vehicle manufacturer should
demonstrate how the update will be completed safely. If a human-machine interface (HMI) is part of the safe
execution for an OTA update, standardization of the HMI is needed to guarantee the customer understanding
across different products. This is also beneficial in general on any occasion where an HMI can help to explain
influences from OTA updates on the availability or quality of concerned features.
As additional explanation and support for developing specific requirements in case HMI aspects are involved
in securing the safe and/or fully understood execution of an OTA update, use case examples of potential HMI
interactions are provided in Annex A.
v
Road vehicles – — Human-machine interface (HMI) for over the air
(OTA) software updates
1 Scope
This document provides human-machine interface (HMI) design specifications in case an HMI is needed to
secure the safe and/or fully understood execution of OTA software updates for passenger cars (including sport
utility vehicles and light trucks) and commercial vehicles (including heavy trucks and buses). The vehicle
operator benefits from knowing if an OTA update has been successful or not, if an OTA update will influence
the operation of the vehicle, or if the OTA update influences the quality of a feature. HMI specifications for the
OTA software update provide support in case an HMI is needed in normal conditions, emergencies, low
battery, avoidance of inadvertent actuations, alerts or specific non-standard situations.
2 Normative references
The following documents are referred to in the text in such a way that some or all 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 15008, Road vehicles — Ergonomic aspects of transport information and control systems - Specifications and
test procedures for in-vehicle visual presentation — Image flashing
ISO 2575, Road vehicles — Symbols for controls, indicators and tell-tales
ISO 4040, Road vehicles — Location of hand controls, indicators and tell-tales in motor vehicles
3 Terms and definitions
For the purposes of this document, the following terms and definitions 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
activation
step in the software update operation when the relevant parts of an installed software update package (3.13)
become executable on a vehicle, vehicle system or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.2.3, modified — Examples have been removed.]
3.2
cancel
command that stops a previously commanded function
Note 1 to entry: Depending on the software update operation stage, the system may go back to the same initial state
before the update or enter in a fail-safe state.
[SOURCE: ISO 2806:1994, 2.2.6, modified — "cancels" has been replaced by "stops" and the Note 1 to entry
has been added.]
3.3
display
electronic device capable of visually communicating information
[SOURCE: ISO 3600:2022, 3.4]
3.4
electronic control unit
ECU
embedded device in a vehicle whose software (3.12) can be updated
[SOURCE: ISO 24089:2023, 3.1.7]
3.5
ignition
power supply in a vehicle that includes an on and off state
3.6
infrastructure
processes and information systems managing any combination of software update operations, software
update campaigns (3.14), documentation and vehicle configuration information, including both digital and
manual activities
Note 1 to entry: Infrastructure can include any combination of servers, tools and manual activities used in the software
update operation.
[SOURCE: ISO 24089:2023, 3.1.10]
3.7
installation
step in the software update operation when the relevant parts of a software update package (3.13) are written
to a vehicle, vehicle system or electronic control unit (ECU) (3.4) but are not yet activated
[SOURCE: ISO 24089:2023, 3.2.2]
3.8
metadata
descriptive information associated with software updates, intended for deployment in vehicle systems or
electronic control units (ECUs) (3.4)
Note 1 to entry: Metadata includes vehicle and safety conditions, compatibility information, software (3.12) versions,
required resources, and information to a user via a human-machine interface (HMI). Additionally, necessary information
will be added depending on the content to be updated.
3.9
over the air
OTA
data channel operated by a mobile network operator for the remote management of components resident in
the mobile device
Note 1 to entry: Over the air is the software update distribution method that acts as a mechanism for distributing
software update packages (3.13) during software update campaigns (3.14) in ISO 24089.
[SOURCE: ISO 12812-1:2017, 3.37, modified — Note 1 to entry has been added.]
3.10
potential risk
state in which the vehicle cannot be driven or has similar functional restrictions
3.11
receipt
step in the software update operation when a tool, vehicle, vehicle system or electronic control unit (ECU) (3.4)
receives a software update package (3.13)
[SOURCE: ISO 24089:2023, 3.2.1, modified — Examples have been removed.]
3.12
software
computer programs and associated data intended for installation (3.7) on vehicles, vehicle systems or
electronic control unit (ECU) (3.4), that may be dynamically written or modified during execution
[SOURCE: ISO 24089:2023, 3.1.15]
3.13
software update package
set of software (3.12) and associated metadata (3.8) that is intended to be deployed to one or more vehicles,
vehicle systems or electronic control unit (ECU) (3.4)
[SOURCE: ISO 24089:2023, 3.1.20]
3.14
software update campaign
sequence of identifying targets (3.17) and resolving recipients; distributing software update packages (3.13);
and monitoring and documenting results of software update operations
[SOURCE: ISO 24089:2023, 3.1.16]
3.15
stage
step in the software update process
3.16
symbol
visually perceptible figure used to transmit information independently of language, produced by drawing,
printing or other means
[SOURCE: ISO 2575:2021, 3.1]
3.17
target
one or more classes of vehicles, vehicle systems or electronic control unit (ECU) (3.4) determined by vehicle
configuration information
[SOURCE: ISO 24089:2023, 3.1.23]
3.18
tell-tale
display (3.3) that indicates, by means of a light-emitting device, the actuation of a device, a correct or defective
functioning or condition, or a failure to function
[SOURCE: ISO 2575:2021, 3.2]
3.19
vehicle state
condition of the vehicle at a point in time with regard to motion and operation
Note 1 to entry: EXAMPLE Stationary, moving, normally operating, non-operating vehicle (e.g. parked, stationary,
driving, engine off).
[SOURCE: ISO 20080:2019, 3.12.1]
3.20
vehicle user
person operating, driving, owning or managing a vehicle
[SOURCE: ISO 24089:2023, 3.1.26, modified — Note 1 to entry was removed.]
3.21
vehicle operator
person operating, driving a vehicle
4 Design guidelines
4.1 General
The purpose of Clause 4 is to provide guidance if visual information is used to secure the safety of the OTA
software update by specifying an HMI to make the vehicle operator aware of any potential risks to the vehicle
user and/or other road users before the execution of the OTA software update. An example to illustrate
potential interactions with the vehicle operator while the OTA software is updating is shown in Figure 1.

a
User consent skipped if settings are set accordingly and no special preconditions have to fulfilled by customer.
b
Only if safe state is need.
Figure 1 — Example to illustrate potential vehicle operator interactions during an OTA software
update
Annex A provides supplementary details with use cases and examples for potential HMI interactions to handle
OTA updates for different types of features.
4.2 Content
When updating vehicle software via OTA, information about the content which is required in ISO 24089 should
be provided to the vehicle operator.
4.3 Visual information
4.3.1 General
Subclause 4.3 specifies the location of symbols, lighting of the information and what colours should be used
for visual information to notify the vehicle operator.
4.3.2 Location
When an HMI is part of the solution to support OTA software updates, the visual information shall be located
so that the vehicle operator recognizes and can follow the update procedure and gets notified about any
potential risks to the vehicle user, and/or other road users during the execution of the update until it is
completed. The guidance regarding display visibility in ISO 4040 shall be followed when the OTA software
updates concern vital functions for operating the vehicle.
4.3.3 Symbol
The symbols for OTA software updates specified in ISO 2575 shall be used to indicate the status of the software
update. This includes, but is not limited to, receipt, installation, activation and update failure. Symbols are not
needed if there is no potential risk to the vehicle operator during the OTA update, or if be shown that other
visual information fulfils the same purpose.
EXAMPLE 1 After the software update has been installed and the ignition is turned off, the vehicle cannot be moved
for 10 min, so the above symbol will flash in the meter until the vehicle is safe to drive.
EXAMPLE 2 The software update for the vehicle is accepted by a terminal outside the vehicle and the software update
has been installed. The display indicates that the software update has been accepted, that the installation is complete,
and that the vehicle will be able to move until the ignition is turned off.
4.3.4 Symbol attention
If symbols according to the above are needed to get the attention from the vehicle operator while progressing
any stage of the OTA software updates, they shall be in accordance with the requirements of ISO 15008.
EXAMPLE 1 In the case of a brake system update, the green OTA tell-tale blinks before acceptance because without
consent, the vehicle becomes undrivable.
EXAMPLE 2 In the case of a navigation system update, the tell-tale is not turned on because the vehicle will keep
driving without any risk.
4.3.5 Colour
Tell-tale colours shall follow the guidance for use of colours in ISO 2575.
4.4 Driver distraction
The OTA HMI should consider the impact on driver glance behaviour to avoid driver distraction. The OTA HMI
should be consistent with regional and/or international driver distraction guidelines.
Annex A
(informative)
OTA HMI use cases
A.1 General
This annex provides additional explanations for situations when an HMI can be needed. This annex lists use
cases and provides examples of how OTA software updates can be handled for different kinds of systems.
A.2 Use cases
Depending on the specifications of the software and the linkage with external terminals, it is possible to not
only accept software updates in the vehicle, but also to accept them outside the vehicle. Table A.1 shows an
example of vehicle system operation patterns for the riding condition of vehicle users and locations where the
vehicle user or vehicle operator accept any step in the OTA software update activity.
Table A.1 — OTA use case of OTA software update
Vehicle state time Operation of vehicle
Where
of acceptance systems
Use case Consenter
to accept
(EXAMPLE) (EXAMPLE)
Accepted while the
Vehicle Software update is executed
A vehicle operator is in the In the car Ignition on and off
operator when ignition off
vehicle
A software update is
Accepted without a
performed and continues.
vehicle operator in the Outside
B-1 Vehicle user Ignition off
vehicle. He/she does not the car
Ignition on is possible after
board during the update
update is complete
Accepted without a
A software update is
vehicle operator in the
performed and continues.
Outside
B-2 vehicle. He/she gets on Vehicle user Ignition off
the car
Ignition on is possible after
during the update
update is complete
execution
Vehicle users
Accepted from outside of
B- Outside who are Software update execution
the vehicle and the Ignition on
3.1 the car outside of does not run
operator is in the vehicle
the vehicle
Vehicle users Software update execution is
Accepted from outside of
B- Outside who are started at next ignition off
the vehicle and the Ignition on
3.2 the car outside of
operator is in the vehicle
the vehicle
NOTE B-3.2 is not recommended.
Table A.2 shows the cases in which updates are performed for each software update state.
Table A.2 — In case OTA update is executed as user intended (=update successfully)
Reference Use case Term of use case Justification
subclause definition
A.3.2 Campaign After the campaign registration Vehicle users benefit from understanding the
notification and before the user's consent on need for software updates, vehicle functions
the campaign that are restricted during updates (such as the
vehicle not being able to drive), and when to
make updates
A.3.3 Campaign After the campaign notification and Vehicle users decide whether to update or not
consent before the start of activation (pending) based on events (update changes,
restricted vehicle function, estimated time,
etc.) associated with software updates and
input to the vehicle
A.3.4 Campaign Between the time you accept the Understand that the vehicle user has accepted
accepted campaign and the time you receive the campaign
a download notification (A.3.5))
A.3.5 Download Before the start of download The vehicle user benefits from understanding
notification the events that occur as a result of the
download (cost burden, restricted vehicle
functions such as inability to drive), their
timing, and the content of the download
A.3.6 Download After the notification of download The vehicle user decides whether to update or
consent and before the start of download not (pending) based on the events (update
changes, restricted vehicle function, estimated
time, etc.) associated with the download
execution and inputs it to the vehicle
A.3.7 Download From the time of approval of Understand that the vehicle user has
accepted downloading from
...