Traditional vehicle homologation was built around a relatively stable product. A vehicle was designed, tested, approved, manufactured and placed on the market with its safety-critical characteristics largely fixed by its physical construction.
Software-defined vehicles challenge that model. Modern vehicles can receive software updates after production that alter functions, calibrations, interfaces, energy management, driver-assistance behaviour and potentially characteristics relevant to type approval.
Over-the-air software updating therefore creates one of the most important questions in modern homologation: if a vehicle can materially change after approval, how can regulators and manufacturers ensure that the approved vehicle remains compliant throughout its operating life?
When Software Becomes Part of the Approved Vehicle
A software-defined vehicle is one in which a growing proportion of vehicle functionality is implemented, controlled or modified through software rather than solely through fixed hardware.
This means the characteristics represented by the original type approval may increasingly depend on the software version installed in the vehicle.
Approval-relevant characteristics are largely established through physical components, mechanical construction and fixed electronic calibration.
Approved functions may depend on software versions, configuration, calibration, digital features and post-production updates.
The International Framework for Vehicle Software Updates
UN Regulation No. 156 establishes the international regulatory framework for vehicle software updates and Software Update Management Systems.
Its importance goes far beyond over-the-air delivery. The regulation addresses how manufacturers identify, assess, manage, record and control software updates affecting vehicles within the approval system.
The manufacturer must operate structured processes controlling software-update activities.
Updates need to be evaluated to determine whether they affect characteristics relevant to vehicle type approval.
Approval-relevant software must be identifiable and traceable to the appropriate vehicle configuration.
Manufacturers require controlled information concerning software versions, updates and vehicles affected.
Its central homologation purpose is to ensure that software updates are managed in a controlled way and that the consequences of those updates for approved vehicle characteristics are understood.
The Update Must Be Controlled Before It Reaches the Vehicle
One of the central concepts of UN R156 is the Software Update Management System — commonly referred to as SUMS.
SUMS moves homologation beyond checking one individual update. It requires the manufacturer to demonstrate that the organisation itself has effective processes for managing software throughout the relevant vehicle lifecycle.
Identify relevant software, versions and relationships with vehicle systems and approval characteristics.
Maintain control over which software configurations correspond to particular vehicle types and variants.
Determine what changes in the update and whether approval-relevant functionality is affected.
Demonstrate that the update performs as intended and does not create unacceptable effects on other systems.
Ensure the correct update reaches compatible vehicles under appropriate conditions.
Maintain evidence connecting software versions, affected vehicles, assessments and update decisions.
Which Software Version Represents the Approved Vehicle?
Software homologation requires a reliable connection between the approved vehicle and the software controlling approval-relevant functions.
UN regulations therefore use software identification mechanisms such as RxSWIN — the Regulation x Software Identification Number — to support traceability of software associated with regulated functionality.
Traditional conformity systems trace physical components through drawings, part numbers, serial numbers and controlled production records.
Software-defined functions require equivalent control over versions, configuration and their relationship to the approved vehicle.
If the controlling software changes, the vehicle’s behaviour or regulated characteristics may also change. Software identification therefore becomes an integral part of vehicle configuration control.
Does the Software Update Change the Approved Vehicle?
This is arguably the most important homologation question in the software-defined vehicle era.
Not every software update affects type approval. A navigation-map update, interface correction or non-regulated feature may have no material effect on regulated vehicle characteristics.
Other updates can be very different.
The change may be managed within the manufacturer’s approved software-update processes without requiring a new approval action.
The manufacturer must evaluate whether testing, approval extension, updated documentation or another regulatory action is required before deployment.
The Vehicle Becomes Its Own Software Installation Environment
Over-the-air updating removes the need for every software change to be physically installed at a workshop, but it also creates new safety and conformity risks.
The update must not only be technically correct. It must reach the correct vehicle, be installed under appropriate conditions and leave the vehicle in a safe and valid state.
The system must determine whether the update is appropriate for the specific vehicle and software configuration.
Software should arrive without unauthorized modification or corruption.
Safety-critical updates may need defined conditions relating to vehicle state, operation or user interaction.
The update process must consider what happens if installation is interrupted or unsuccessful.
Drivers or operators may need information concerning update purpose, installation conditions or changes affecting vehicle use.
The vehicle and manufacturer need confidence that the intended configuration has been installed successfully.
A vehicle update can affect systems capable of steering, braking, accelerating or controlling other safety-relevant functions. The consequences of an incorrect or incomplete installation can therefore be fundamentally different.
Software Update Homologation Cannot Be Separated from Cybersecurity
Software updating introduces communication paths, software delivery mechanisms and digital trust relationships that can become potential cyber-attack surfaces.
This is why UN Regulation No. 156 operates closely alongside UN Regulation No. 155, which addresses vehicle cybersecurity and Cyber Security Management Systems.
Focuses on identifying, assessing and managing cybersecurity risks affecting vehicles throughout their lifecycle.
Focuses on controlling vehicle software updates and their relationship to approved vehicle characteristics.
What Must Be Demonstrated Before an Update Is Released?
The appropriate validation programme depends on what the update changes.
A software modification affecting a safety-related vehicle function may require substantially more evidence than a change limited to a non-regulated user interface.
Confirm that the updated software implements intended requirements correctly.
Demonstrate that affected vehicle functions continue to perform as required.
Confirm that changes have not unintentionally degraded previously validated functions.
Where appropriate, verify the updated function in the complete vehicle environment.
Reassess hazards and safety assumptions where the update affects safety-relevant behaviour.
Determine whether applicable approval requirements remain satisfied following the change.
Software Update Compliance Is Already Part of European Homologation
The European Union has integrated software-update requirements into the EU vehicle type-approval framework through the application of UN Regulation No. 156.
This means software governance is no longer a future compliance concept for manufacturers placing relevant new vehicle types on the European market.
Software-update conformity forms part of the regulatory requirements supporting EU vehicle approval.
Approval documentation increasingly needs to account for software identification and update-relevant characteristics.
Approval-relevant software changes may require appropriate interaction with the type-approval authority.
Software versions intended for vehicles already in service can require careful differentiation from software used for newly manufactured vehicles.
Software-controlled functionality creates an ongoing relationship between the approved vehicle configuration, later software versions and the evidence showing continued conformity.
Software Homologation Extends Through the Supply Chain
Modern vehicle software is rarely created by one organisation. OEMs rely on ECU suppliers, software developers, semiconductor companies, ADAS suppliers, battery-system providers and other technology partners.
Yet the vehicle manufacturer remains responsible for demonstrating that the approved vehicle continues to satisfy applicable regulatory requirements.
Suppliers need controlled mechanisms for informing the OEM when software or embedded functionality changes.
The approved vehicle configuration must be traceable through software supplied across multiple organisations.
Relevant supplier test evidence needs to support the manufacturer’s overall conformity assessment.
Vulnerabilities and software-update risks can arise anywhere within the connected software supply chain.
Approval Continues After the Vehicle Leaves Production
Software-defined vehicles reinforce a broader transformation already visible across automotive regulation: conformity increasingly extends beyond the initial approval event.
The homologation process concentrates heavily on the vehicle design entering production and maintaining conformity of production.
Software-controlled vehicles require continuing configuration management and assessment of changes throughout operational life.
That question sits at the heart of software-defined homologation. The answer depends increasingly on controlled software identification, documented change assessment and evidence showing that regulatory conformity remains intact.
From Fixed Product to Controlled Digital Platform
Software-defined vehicles change homologation because the vehicle increasingly becomes a platform capable of controlled evolution after production.
Future homologation capability therefore requires a combination of traditional vehicle engineering and modern software assurance.
Identify all regulations and approval characteristics potentially affected by software-controlled functions.
Establish systematic software-update management across development, production and field operation.
Maintain reliable traceability between vehicles, regulated functions and installed software.
Determine whether each software change affects safety or approval-relevant characteristics.
Generate evidence demonstrating that changed functionality remains safe and compliant.
Maintain conformity as vehicles receive updates, security patches and functional changes throughout service life.
Can a Vehicle Change After Approval?
The software-defined vehicle makes the answer increasingly clear: yes — but that change must itself be governed.
Software can deliver safety improvements, cybersecurity fixes, performance enhancements and new functionality throughout vehicle life. Yet the same capability can modify systems that originally formed part of the vehicle’s approval evidence.
That is why software-update management, cybersecurity, configuration traceability and regulatory impact assessment are becoming fundamental elements of modern homologation.
It is how manufacturers can demonstrate that every approval-relevant change remains controlled, validated, traceable and compliant before it reaches the vehicle.