ISO 24089: ISO 24089 – Tutorial (about 60 minutes)

ISO 24089 is the international standard for software update engineering in road vehicles: the processes, functions and records an organisation needs so that it can change the software in vehicles that are already built, safely and securely, through a workshop or over the air. Vehicle manufacturers use it to organise their update activities and to support the software update management system that UN Regulation No. 156 demands, and suppliers use it to agree who does what along the supply chain. After this tutorial you will be able to explain how the standard is organised, follow an update from the first request to the closed campaign, and judge whether an organisation's update practice is ready for an audit.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: the current version is ISO 24089:2023, Road vehicles — Software update engineering, first edition, published by ISO in February 2023. It was prepared by ISO technical committee ISO/TC 22 (Road vehicles), subcommittee SC 32 (Electrical and electronic components and general system aspects). One short amendment has been published, ISO 24089:2023/Amd 1:2024 (July 2024), which is read together with the 2023 text. The ISO catalogue lists the standard as published (stage 60.60) with no replacement or revision project announced. ISO reviews every standard at least once every five years, so a formal review is due by 2028. Verified 2026-10-29 against the ISO catalogue entries for the standard and its amendment, the published sample pages of the standard (contents, foreword, introduction, scope) and the BSI catalogue. The standard is paid-for and copyrighted; this course explains it in its own words and does not reproduce its text.

Who it is for: software, systems and electrical engineers who build or release vehicle software; people who run over-the-air (OTA) back ends or workshop diagnostic tools; homologation, quality, cybersecurity and functional safety staff; and project managers at vehicle manufacturers and suppliers who are new to software update engineering.

Prerequisites: none. It helps to know roughly what an electronic control unit is and why cars receive software updates. Every term is explained when it first appears.

By the end of this tutorial:

You will be able to explain why software update engineering became its own discipline and what ISO 24089 covers and leaves out.
You will be able to use the core vocabulary correctly: target, recipient, software update package, software update operation, software update campaign, vehicle configuration information and safe vehicle state.
You will be able to describe the six requirement levels of the standard (clauses 4 to 9) and what each one asks for.
You will be able to trace a software update from the project decision through package assembly to campaign completion, naming the evidence produced at each step.
You will be able to explain how conformity with ISO 24089 is assessed and how that differs from the type-approval audit of a software update management system under UN R156.
You will be able to position ISO 24089 against UN R156, UN R155, ISO/SAE 21434, ISO 26262 and the Uptane framework.

Lesson 1 – Origins, purpose and scope

Why vehicle software updates needed a standard

A modern car contains dozens of electronic control units. Each one runs software that controls something important: the engine or the electric drive, the brakes, the airbags, the battery, the lights, the infotainment screen. For a long time this software was written once, flashed at the factory and changed only if a recall forced a visit to the dealer. That world has gone. Manufacturers now fix defects, close security holes, meet new regulations and even add features long after a vehicle has been sold, and they do it more and more often.

Updating a phone is easy because a failed update usually costs the owner some inconvenience. Updating a vehicle is different for three reasons. First, safety: a brake controller that is half-flashed, or a steering function that receives software meant for a different hardware variant, can hurt people. Second, cybersecurity: the update channel is a powerful door into the vehicle, and an attacker who can push software through it controls the car. Third, configuration: two cars of the same model can contain different hardware revisions, different supplier parts and different software versions, so the manufacturer must know exactly what is inside each vehicle before changing anything. A single wrong assumption multiplied across hundreds of thousands of vehicles turns into a large and expensive problem.

Regulators reacted first. Under the UNECE World Forum for Harmonization of Vehicle Regulations (WP.29), UN Regulation No. 156 on software update and software update management systems entered into force in January 2021. It makes a manufacturer prove that it runs a software update management system (SUMS) before it can obtain type approval for vehicles whose software can be updated. The regulation says what must be achieved, but it says little about how an engineering organisation should actually work. The industry needed a common, technology-neutral engineering practice that manufacturers and suppliers could share. ISO 24089 fills that gap. It followed two years after the regulation, in February 2023.

What the standard sets out to do

The introduction of ISO 24089 gives its purpose in plain terms: it supplies vocabulary, objectives, requirements and guidance for software update engineering, so that the whole supply chain shares one understanding. Applying it should make sure that safety and cybersecurity are dealt with in every update operation, that update work runs as defined processes with goals, plans, audits, measurement and improvement, and that everyone involved is aware of the safety and cybersecurity implications.

The phrase software update engineering is central. It does not mean writing the new feature or fixing the bug in the code. It means everything that is needed to get a new software version safely into vehicles already in the field: deciding which vehicles need it, checking that it is compatible, packaging it, protecting it, distributing it, installing and activating it under safe conditions, recording the result, and dealing with vehicles where it fails.

Scope in five statements

It applies to road vehicles whose software can be updated, and to the organisations that do update engineering for them: vehicle manufacturers, suppliers and their subsidiaries or partners.
Its requirements and recommendations cover the organisation and individual projects, and they apply to vehicles, vehicle systems, ECUs, the back-end infrastructure, and the assembly and deployment of software update packages after initial development.
It is not an over-the-air standard. Updates delivered by a technician in a workshop or through a wired diagnostic connection are in scope just as much as wireless updates.
Developing the vehicle function software itself is out of scope; other standards (for example ISO 26262 for safety and ISO/SAE 21434 for cybersecurity) govern that development.
It is solution-neutral. It does not prescribe a technology, a protocol, an architecture or a vendor. Many of its functions may be realised in the vehicle, in the infrastructure, or split between them.

Two practical consequences follow. A supplier that only produces ECU software and never sends anything to vehicles on the road can still be affected, because its software must support the update functions the manufacturer relies on. And an organisation that thinks "we do not do OTA, so this standard is not for us" is usually wrong, because a workshop reflash is also a software update operation.

Lesson 2 – Key concepts and vocabulary

ISO 24089 defines its own precise terms, and several of them have a narrower meaning than in everyday speech. It is worth keeping the definitions clause at hand while reading the rest of the document. The list below explains the most important terms in our own words.

Software update engineering – the set of activities, processes and functions needed to change software in vehicles after initial development, as opposed to writing the software.
ECU (electronic control unit) – in this standard, an embedded device in the vehicle whose software can be updated. A sensor without updatable software is not an ECU in this sense.
Vehicle system – a group of ECUs and related components that together provide a function, such as the braking system or the battery management system.
Software – programs together with their associated data (calibration tables, configuration parameters) intended for installation on vehicles, vehicle systems or ECUs. Changing a calibration value counts as a software update.
Infrastructure – the processes and information systems outside the vehicle that manage update operations, campaigns, documentation and configuration data. It includes servers and tools, and also manual activities, such as a workshop procedure.
Vehicle configuration information – the record of which hardware, software versions and configuration parameters are present in a specific vehicle. It is the basis for deciding where an update may go.
Target – a description of what an update is meant for, usually expressed as a set of configurations: for example "battery controller hardware revision B running software version 3.1 or earlier".
Recipient – an individual vehicle, vehicle system or ECU that actually receives a package during a campaign. Targets are abstract; recipients are concrete instances, identified for example by vehicle identification number.
Software update package – the unit that is distributed: the software itself plus metadata describing targets, conditions, dependencies and the actions to perform, protected so that its integrity and authenticity can be checked.
Software update operation – what happens to one package in one recipient: it is received, installed and activated, and the outcome is reported.
Software update campaign – the end-to-end sequence for a population of vehicles: identify the targets, resolve them into recipients, distribute the packages, and monitor and document the results of the operations.
Compatibility – the ability of new software to run on the recipient's systems without conflicts. It is checked against the vehicle configuration information.
Dependency – an effect that software in one vehicle system has on the same or another system, such as a shared communication interface between two ECUs. Dependencies often become conditions in the package metadata.
Condition – a criterion that must be met for an update operation to complete successfully: compatibility, enough battery charge or storage, a safe vehicle state, the presence of a skilled person, and so on.
Safe vehicle state – an operating mode in which update steps can be performed without unreasonable risk, for example drive system off and parking brake applied. What counts as safe can differ between packages and between steps of one operation.
In-vehicle resource – a property of the vehicle or ECU that matters for updating, such as free memory, processing power, network bandwidth or battery capacity.
Skilled person – someone with the training or experience to carry out an update operation, typically a workshop technician; a suitably informed vehicle user can also be one for some updates.
Software update project – a project that delivers one or more updates for defined targets. The project is the unit to which plans, roles, tailoring decisions and evidence belong.

How the terms fit together

A useful mental model is a funnel. A project decides that some software must change. Its targets describe the kinds of vehicles concerned. The vehicle configuration information turns those targets into a list of real recipients. A package is assembled for them, and a campaign distributes it. In each recipient, one operation runs only when its conditions are satisfied and the vehicle is in a safe vehicle state. The results flow back and update the configuration record, which is then ready for the next campaign. Figure 5 in Lesson 6 shows this funnel for a concrete case.

Requirements and recommendations

Like other ISO standards, ISO 24089 separates requirements, written with "shall", from recommendations, written with "should". A conforming organisation must meet every applicable requirement and must be able to explain how it handled the recommendations, but it may decide not to follow a recommendation if it has a good reason. Notes and examples are informative only. When someone claims "the standard requires X", ask whether X is a "shall", a "should" or merely an example; this one question settles many arguments in practice.

Lesson 3 – Structure of the standard

The document is short compared with ISO 26262 or ISO/SAE 21434. After the scope (clause 1), the normative references (clause 2) and the terms and definitions (clause 3), the body has six requirement clauses. Each of them follows the same internal pattern, which makes the standard easy to navigate once you know it:

Objectives – what the clause intends to achieve.
General – context and explanation.
Requirements and recommendations – grouped into topics.
Work products – the evidence the activities are expected to produce.

Figure 1 – The six requirement clauses of ISO 24089 build on each other: organisational rules frame projects, projects rely on infrastructure and vehicle functions, which are used to assemble packages and run campaigns.

Clause 2 – Normative references

Three documents are referenced normatively, which means parts of them become requirements of ISO 24089: ISO/SAE 21434 (cybersecurity engineering) and two parts of ISO 26262 (functional safety), part 6 on software-level product development and part 8 on supporting processes. Choosing only two parts of ISO 26262, rather than the whole series, was deliberate: it lets organisations that do specialised work, and do not apply every part of ISO 26262, still conform. The practical message is that an update process cannot be separated from safety and security engineering.

Clause 4 – Organizational level

This clause asks the organisation to set up the management framework for all update work. Its topics are governance (policies, rules, responsibilities and authority for update engineering, and making sure the needed resources and competences exist), continuous improvement (learning from campaigns and incidents and improving the processes), information sharing (deciding what update-related information is shared with whom, inside and outside the organisation), supporting processes (document management, configuration management, requirements management and quality management applied to update engineering), and auditing (independently checking that the update processes are followed and effective).

Clause 5 – Project level

This clause covers each software update project. Its topics are project management (a plan, roles and responsibilities, documentation), tailoring and rationale (adapting the process to the project and recording why a requirement does not apply or is met another way), interoperability (making sure the parties and systems in the project work together, including suppliers' ECUs and the manufacturer's infrastructure), and integrity (protecting the software and data so that what is installed is exactly what was released). Tailoring matters because organisations play very different roles: some create updates but never distribute them, and some, such as body builders who convert a base vehicle, relate to the vehicle differently from the original manufacturer.

Clauses 6 and 7 – Infrastructure and vehicle functions

Clause 6 describes the functions the off-board infrastructure must provide; clause 7 describes the functions the vehicle and its systems must provide. The two clauses deliberately use the same four topic headings, which shows that they are two halves of one system:

Managing risk – identifying and treating the safety and cybersecurity risks of the update functions themselves.
Managing vehicle configuration information – keeping, reading, protecting and updating the record of what is installed.
Communicating campaign information – informing vehicle users or skilled persons, collecting consent where needed, and reporting results back.
Processing software update packages – receiving, checking integrity and authenticity, checking compatibility and conditions, installing, activating, and handling failures.

Because the standard is solution-neutral, many requirements note that a function may be realised in the vehicle, in the infrastructure, or in both. A compatibility check, for example, might run in the back end before distribution, in the vehicle before installation, or in both places. The infrastructure also includes tools, so a workshop flashing tool falls under clause 6.

Clause 8 – Software update package

Clause 8 covers the creation of a package after the software itself has been developed. Its four topics follow the natural order of the work: identify the targets and decide what the package must contain; assemble it (software, metadata, conditions, dependencies, the actions to perform and the distribution method); verify and validate it; and approve it for release. Without that approval, the package must not be used in a campaign.

Clause 9 – Software update campaign

Clause 9 covers the campaign in three phases: preparation (campaign plan, resolving targets into recipients, preparing communications, checking that infrastructure and packages are ready), execution (distributing packages, informing users, performing operations under the defined conditions, monitoring progress and reacting to failures), and completion (closing the campaign, documenting results, updating configuration records and dealing with recipients that were not updated). Lesson 4 walks through the phases in detail.

Three kinds of requirement

A useful way to read the clauses is to group them into three kinds of requirement. Governance requirements (mainly clause 4) set up roles and control. Functional requirements (clauses 6 and 7) describe capabilities the infrastructure and the vehicle must have. Process requirements (clauses 5, 8 and 9) describe activities to perform for each project, package and campaign. Keeping the three apart helps when you plan implementation: governance is set up once, functions are built into products and systems, and processes are executed again and again.

Lesson 4 – How it works in practice

This lesson follows the work in the order an organisation usually experiences it: set up the organisation once, then for each need run a project, assemble a package and execute a campaign.

Step 1 – Establish the organisational framework

The organisation first decides who owns software update engineering. In a vehicle manufacturer this is often a dedicated function linked to homologation, cybersecurity and quality. It writes down the policy and the process rules, assigns authority (for example, who may approve a package for release and who may stop a running campaign), and makes sure people have the competences they need. It connects update engineering to the existing supporting processes: configuration management and document management already exist for development, but they must now also cover vehicles in the field. It sets up information sharing, for instance with suppliers whose ECUs are updated, with dealers and workshops, and with authorities where regulations demand it. Finally, it plans audits of the update processes and a loop for continuous improvement.

Step 2 – Run a software update project

A project starts when someone decides that software in the field must change: a defect was found, a vulnerability was reported, a regulation changed, or a new feature is planned. The project defines its targets, plans the work, assigns roles across the manufacturer and suppliers, and records any tailoring with a rationale. It assesses the impact of the change, using the safety and cybersecurity processes required by the normative references. It also checks interoperability, because the new software must work with all the other ECU versions present in the target vehicles, with the infrastructure and with the workshop tools. Integrity measures, such as signing keys and controlled build environments, are planned so that the software cannot be altered between release and installation.

Step 3 – Make sure the functions exist

Before any campaign can run, the vehicle and the infrastructure must provide the functions of clauses 6 and 7. In practice these are built into the vehicle platform and the back end long before a particular update is needed: an update agent in the vehicle, secure boot and signature checks in each updatable ECU, a configuration database in the back end, a campaign management system, diagnostic tools for workshops, and channels for communicating with users. The standard asks that the risks of these functions themselves be managed, because a poorly protected update agent is a security weakness for the whole fleet.

Step 4 – Assemble, verify and release the package

For each update, the team identifies the targets precisely and decides on the contents. It assembles the package: the software images or calibration data, metadata that states targets, dependencies on other software versions, conditions for installation (such as minimum battery charge, vehicle stationary, or presence of a technician), the actions the vehicle must take, and how the package will be distributed. Integrity and authenticity protection is applied. The package is then verified (is it built correctly, complete and consistent with its metadata?) and validated (does it achieve its purpose in representative vehicles, including failure and recovery paths?). Only then is it formally approved for release, by the person with that authority, and the approval is recorded.

Step 5 – Prepare, execute and complete the campaign

Figure 2 – A software update campaign moves through preparation, execution and completion, and every phase leaves evidence behind.

Preparation. The campaign plan states which packages go to which population, in what order, through which distribution methods, with what timing and what stop criteria. Targets are resolved into recipients by querying the vehicle configuration information: every vehicle whose recorded configuration matches the target becomes a recipient, and vehicles whose configuration is unknown or inconsistent are handled separately rather than guessed. Communications are prepared: what the vehicle user will be told about the purpose of the update, the expected duration and any functions that will be unavailable during it; what workshops need to know; and how consent will be collected where it is needed.

Execution. Packages are distributed, over the air, through workshop tools, or both. In each recipient a software update operation runs. Before installation the vehicle or the infrastructure checks that the package is authentic and intact and that it is compatible with the actual configuration of that vehicle. It checks the conditions, such as resources and safe vehicle state. Installation and activation follow, and the result is reported. The campaign team monitors success and failure rates; if failures rise above an agreed threshold, it pauses the rollout and investigates. Many organisations release to a small first wave before the wider fleet.

Figure 3 – One software update operation in one recipient: each step is gated by checks, and every path ends with a reported result.

Figure 3 shows a simplified life of one operation. The important idea is that every path ends with a reported result. A failed installation must leave the vehicle working: typically the ECU falls back to the previous version or stays in a defined safe state, and the user or technician is told. UN R156 expects exactly this kind of behaviour for over-the-air updates, and ISO 24089 gives the engineering structure to deliver it.

Completion. When the campaign ends, the configuration records of all updated vehicles reflect their new state. Recipients that were not reached, refused, or failed are analysed and given a follow-up route, for example a workshop visit. The campaign is formally closed, its results are documented, and lessons go back into the organisational improvement loop of clause 4.

Roles and typical artefacts

Level	Typical roles	Typical evidence (work products)
Organisation (clause 4)	Head of update engineering, quality, cybersecurity and safety managers, internal auditors	Update policy and process rules, responsibility assignments, competence records, audit reports, improvement actions
Project (clause 5)	Project lead, ECU supplier contacts, safety and security engineers	Project plan, tailoring rationale, interoperability analysis, integrity measures
Infrastructure and vehicle (clauses 6, 7)	Back-end architects, vehicle platform team, diagnostic tool owners	Risk analysis of update functions, configuration data model, specifications of update functions
Package (clause 8)	Release engineers, test engineers, release authority	Target and contents definition, package with metadata, verification and validation reports, release approval
Campaign (clause 9)	Campaign manager, customer communication, workshop network	Campaign plan, recipient list, user information, monitoring records, completion report

The table shows typical examples, not a list copied from the standard. Each clause of ISO 24089 names its own work products; an organisation should map its existing documents to them rather than creating new paperwork for its own sake.

Lesson 5 – Assessment, certification and compliance

Three different questions

People often mix up three questions that have different answers. Is the organisation conforming to ISO 24089? Does it hold a certificate for ISO 24089? Is it compliant with UN R156? Keeping them apart avoids expensive misunderstandings.

Conformity with ISO 24089

ISO 24089 is a voluntary engineering standard. An organisation conforms when it meets all requirements that apply to it, with any tailoring justified. The standard itself asks for auditing of the update processes at the organisational level, so internal audits are part of conformity, not an optional extra. Conformity can be checked by the organisation itself, by a customer (for example a manufacturer auditing an ECU supplier), or by an independent assessor.

Certification

ISO 24089 is not a management system standard in the sense of ISO 9001 or ISO/IEC 27001, and we found no accredited certification scheme for organisations against it as of 2026-10-28. Several testing and inspection organisations offer gap analyses, assessments and their own attestations of conformity. Such an attestation can be useful evidence, but it is a private statement by that assessor, not an accredited certificate, and it does not replace any regulatory approval. A practical assessment usually crosses two views: the organisational level (are the rules, roles and supporting processes in place?) and the project lifecycle (did a real update project actually follow them, and can it show the evidence?). Organisations that assess themselves often find that the technical update mechanism is in better shape than the records around it: configuration data, approvals and campaign documentation.

Compliance with UN R156

UN R156 is a regulation adopted under the 1958 Agreement of WP.29. In the contracting parties that apply it, it is mandatory for type approval. Two things are approved. First, the manufacturer's software update management system is assessed by the approval authority or its technical service, and a positive assessment leads to a Certificate of Compliance for the SUMS, valid for a limited period of at most three years. Second, each vehicle type is approved with regard to software updates, which requires a valid SUMS certificate and checks on the vehicle's update capabilities. In the European Union, the regulation became mandatory for new vehicle types from July 2022 and for all newly registered vehicles from July 2024. Other contracting parties that apply it, such as Japan, follow their own schedules.

R156 also introduces the RXSWIN (regulation X software identification number), an identifier defined by the manufacturer that represents the type-approval-relevant software of a vehicle system for a given regulation. The manufacturer must be able to show whether an update affects a type-approved system and must keep the RXSWIN information consistent. ISO 24089 does not define the RXSWIN; that is a regulatory construct. Its configuration management and impact analysis are, however, exactly the activities that feed it.

How the standard and the regulation relate

R156 does not reference ISO 24089, so conformity with the standard is not a legal requirement and is not automatically accepted as proof of compliance. In practice, many manufacturers use ISO 24089 as the engineering basis for their SUMS and as the reference in supplier contracts, because the regulation states outcomes at a high level and the standard turns them into processes, functions and evidence. The two documents do not map one to one. Some R156 topics are regulatory constructs the standard does not define, such as the RXSWIN, while the standard treats some topics in more detail than the regulation, for example campaign completion and organisational improvement. A WP.29 task-force proposal would cite ISO 24089:2023 in the interpretation document for R156; treat any such reference as guidance, not as a change to the regulation, unless the regulation text itself is amended.

Figure 4 – Regulations state what must be achieved; ISO 24089 describes how to engineer updates and draws on the safety and cybersecurity standards it references.

Lesson 6 – Worked example

The following example is fictional, but it is built from the kinds of situations that update teams describe. It shows how the clauses of ISO 24089 fit together in one real change.

The situation

Northvale Motors is a mid-sized manufacturer of electric vans. Its field quality team notices that vans in cold regions occasionally show a charging fault after a fast-charging session. Analysis shows that a calibration table in the battery management ECU, supplied by a tier-one supplier called Cellcore, uses a temperature threshold that is too strict for one battery cell variant. About 42,000 vans are on the road in three hardware variants. Most have a telematics unit that supports over-the-air updates; around 6,000 older vans built before the telematics upgrade do not.

Organisational level already in place

Two years earlier, Northvale set up its update engineering framework while preparing for R156. An update governance board owns the policy. Release authority for packages sits with a named role in vehicle software quality; authority to stop a campaign sits with the campaign manager and, out of hours, with the duty engineer. The configuration management process was extended to cover vehicles in the field. Supplier contracts with Cellcore define what information is shared, for example ECU software identifiers, dependencies, and test evidence. The internal audit plan includes one update project per quarter.

Project level

The governance board opens software update project "BMS cold-charge calibration". The project plan names the targets: battery management ECU hardware revisions A and B with calibration version 2.4 or earlier, in vans with cell variant C. Hardware revision A0 is excluded because it uses different cells. The plan assigns Cellcore to deliver the new calibration and its test evidence, the Northvale platform team to check interoperability with the charging controller and the instrument cluster, and the release engineering team to assemble the package.

The team records a tailoring decision: because only calibration data changes, not executable code, some code-level activities are not repeated, and the rationale and the supporting safety and cybersecurity impact analyses are documented. The safety team confirms that the new threshold still protects the cells; the cybersecurity team confirms that no new interface is introduced. Integrity is protected by Cellcore's controlled build and Northvale's signing service.

Functions in the vehicle and the infrastructure

Northvale's back end holds vehicle configuration information for every van, updated at production, at each workshop visit and after every OTA operation. The vans' update agent can download in the background, check signatures, check compatibility against the actual ECU versions, and install only when the van is parked, not charging, and above a minimum state of charge. The battery management ECU keeps the previous calibration until the new one is confirmed active, so it can fall back. Workshops use a diagnostic tool connected to the same back end, so workshop updates are recorded exactly like OTA updates.

Figure 5 – In the worked example, the target is resolved into concrete recipients using vehicle configuration information, and recipients are split by distribution method.

Package level

The release engineers assemble two packages with the same calibration content but different distribution metadata: one for OTA and one for the workshop tool. The metadata states the targets, a dependency on charging controller software version 5.0 or newer, the conditions (parked, not charging, minimum battery charge, ignition off), the actions (write calibration, verify checksum, activate at next start), and the user-facing description. Verification checks that the packages are complete, correctly signed and consistent with their metadata. Validation runs on test vans of each hardware variant, including deliberate power loss during installation to confirm that the ECU falls back to the old calibration. The release authority approves both packages and the approval is stored with the evidence.

Campaign level

Preparation. The campaign manager resolves targets into recipients from the configuration database. Of the 42,000 vans, about 40,000 match. Of these, 34,500 can be updated over the air and 5,100 need a workshop visit; for about 400 vans the configuration record is inconsistent, for example because an ECU was replaced in an independent garage. Those 400 are not guessed: they are invited to a workshop, where the actual configuration is read before anything is installed. User information explains the purpose, the expected duration of about ten minutes and that charging is unavailable during installation. The plan defines a first wave of 1,000 vans and a stop criterion: pause if more than 0.5 % of operations fail.

Execution. The first wave completes with a handful of failures, all caused by low battery charge; the vans simply retry later when the conditions are met. The full rollout follows. On day four, failures rise in one region. The campaign manager pauses distribution there and the investigation finds a dealer-installed accessory that draws power during installation. Northvale adds a condition to the package metadata, repeats verification and approval for the changed package, and resumes. Workshop updates run in parallel during scheduled services.

Completion. After eight weeks, 98 % of recipients are updated. The configuration records of every updated van show the new calibration version. Vans not yet updated stay on a follow-up list with reminder letters and a flag in the workshop system. The completion report documents numbers, failures, root causes and the accessory finding. The governance board adds the accessory issue to the lessons learned, the validation team adds accessory power draw to its standard test cases, and the next quarterly audit picks this project as its sample.

What the example teaches

Almost nothing in the example is exotic technology. What makes the update safe is the discipline around it: knowing which vans have which configuration, refusing to guess when records are unclear, protecting and validating the package, setting conditions and stop criteria, and documenting every result. That discipline is what ISO 24089 standardises.

Lesson 7 – Relationship to other standards and frameworks

ISO 24089 sits at the point where functional safety, cybersecurity and regulation meet. Understanding its neighbours prevents both gaps and duplicated effort.

Standard or framework	What it is	Relationship to ISO 24089
UN Regulation No. 156	UNECE regulation on software update and software update management systems; mandatory for type approval in contracting parties that apply it	States outcomes for the manufacturer's SUMS and vehicle update capabilities; ISO 24089 is a common engineering way to achieve them, but R156 does not reference it
UN Regulation No. 155	UNECE regulation on cybersecurity and cybersecurity management systems	Treats the update channel as an attack surface; the cybersecurity management system must cover threats to the update process
ISO/SAE 21434	Road vehicle cybersecurity engineering across the lifecycle, including threat analysis and risk assessment	Normative reference; ISO 24089 also follows its pattern of organisational and project levels, and updates must be developed with its cybersecurity activities
ISO 26262 (parts 6 and 8)	Functional safety of road vehicle electrical and electronic systems	Normative reference for software-level development and supporting processes such as configuration and change management
Uptane	Open security framework for software update systems in vehicles, maintained as an open standard project	A possible technical design for the integrity and authenticity functions; ISO 24089 stays solution-neutral and neither requires nor excludes it
Automotive SPICE	Process assessment model for automotive software and system development	Assesses how software is developed; ISO 24089 governs how it is delivered to vehicles in the field

Common confusions

ISO 24089 versus UN R156. The regulation is law where it applies and leads to type approval; the standard is voluntary engineering practice. Conforming to the standard helps, but it is the regulation that the approval authority checks.
ISO 24089 versus ISO/SAE 21434. The cybersecurity standard asks for secure development and for updates to be part of a secure lifecycle; ISO 24089 describes the whole update engineering chain, of which security is one dimension. A secure signing scheme alone does not make a conforming update process.
ISO 24089 versus OTA platforms. An OTA platform is a product that may implement some functions of clauses 6 and 7. Buying one does not provide the organisational, project, package and campaign processes, and it does not cover workshop updates.
ISO 24089 versus ISO 26262. ISO 26262 decides how safety-relevant software is developed. ISO 24089 makes sure that its safe delivery into the field does not undo that work, for example by installing it on incompatible hardware or in an unsafe vehicle state.

Common pitfalls and best practices

Pitfalls

Treating it as an OTA-only standard. Workshop and diagnostic-tool updates are left uncontrolled, so the fleet configuration drifts and the next OTA campaign targets the wrong vehicles.
Unreliable configuration data. Teams resolve recipients from production records that are never updated after repairs; replaced ECUs then receive incompatible software.
Buying a tool instead of building a process. An update platform is installed, but there is no release authority, no tailoring rationale and no campaign completion; the technology works and the evidence is missing.
Testing only the happy path. Packages are validated for successful installation but never for power loss, interrupted downloads or failed activation, so recovery behaviour is unknown when it is needed.
Leaving campaigns open forever. Without a defined completion, vehicles that were never updated are forgotten and the organisation cannot say how many vehicles still carry the old version.
Ignoring suppliers. Responsibilities with ECU suppliers are not agreed, so dependency information, signing and test evidence arrive late or not at all.

Best practices

Make configuration information the backbone. Update it after every operation, whatever the channel, and treat inconsistent records as their own recipient group.
Define authority clearly. Name who approves a package, who may start a campaign and who may stop it, including outside office hours.
Roll out in waves with stop criteria. Start with a small population, agree thresholds in advance and pause automatically when they are exceeded.
Validate failure and recovery. Include interrupted installation, low power, missing dependencies and rollback or safe-state behaviour in every validation plan.
Integrate with safety and security processes. Run impact analyses through the existing ISO 26262 and ISO/SAE 21434 processes instead of creating parallel ones.
Write supplier agreements against the clauses. Use the clause structure to agree who provides which function and which work product.
Close the loop. Use campaign completion reports and audit findings to improve the processes, as clause 4 intends.

Summary and key takeaways

ISO 24089:2023 (with Amendment 1:2024) is the international standard for software update engineering in road vehicles, published by ISO/TC 22/SC 32.
It covers getting software safely into vehicles after initial development, by any route: over the air or in the workshop; it does not cover writing the function software.
Six requirement clauses form a chain: organisation, project, infrastructure functions, vehicle functions, package and campaign, each with objectives, requirements and recommendations, and work products.
Vehicle configuration information is the backbone: targets are resolved into recipients with it, compatibility is checked against it, and every result updates it.
Every operation runs only when its conditions and a safe vehicle state are met, and every path, including failure, ends with a reported result.
ISO/SAE 21434 and ISO 26262 parts 6 and 8 are normative references, so update engineering is tied to cybersecurity and safety engineering.
UN R156 is the mandatory regulation with SUMS certificates and type approval; ISO 24089 is voluntary, is not referenced by R156, and has no accredited certification scheme that we could find, but it is widely used to implement R156.
Good practice is about discipline: clear authority, reliable configuration data, staged rollout, validated recovery and a closed loop of improvement.

Reflection questions

Think of an organisation you know or work for. Which software update routes exist for its vehicles or products, and which of them would currently fall outside its documented update process?
Where does your organisation's vehicle configuration information come from, and what events could make it wrong? How would you detect and handle a vehicle with an unreliable record?
For a planned update in your area, write down the targets, the conditions and the dependencies you would put into the package metadata. Who would need to confirm each of them?
What stop criteria would you set for the first wave of a campaign, and who should have the authority to pause it? Explain your reasoning.
Your management says, "We passed the R156 SUMS audit, so we are ISO 24089 compliant." How would you respond, and what evidence would you look for to check the claim?