Software-defined vehicles and the governance challenge ahead

A modern premium vehicle contains somewhere between 100 and 150 million lines of code, distributed across dozens of electronic control units connected by multiple in-vehicle networks. That figure is expected to double within the next five years as vehicles become platforms for autonomous driving, predictive maintenance, and continuously evolving digital services. The implications of this shift extend far beyond engineering departments — they reach into how the automotive industry governs safety, manages liability, and earns the trust of regulators and the public.

The traditional model of vehicle governance — certify the hardware at type approval, test the software once, ship it, and leave it alone — was designed for an era when vehicle software was static and functionally isolated. That model is fundamentally incompatible with vehicles that receive over-the-air updates, run machine learning models that adapt over time, and depend on cloud-connected services for core functionality. The industry needs new governance infrastructure, and the most promising foundations for that infrastructure are being built collaboratively, through open standards and cross-industry consortia.

The software-defined shift

The phrase "software-defined vehicle" has become ubiquitous in automotive strategy documents, but the substance behind it is genuinely transformative. In a traditional vehicle architecture, software is tightly coupled to specific hardware components. The engine control unit runs firmware written for that particular engine variant. The infotainment system runs on its own processor with its own operating system. Integration between systems happens through carefully specified, point-to-point interfaces that are frozen early in the development cycle and rarely changed after production.

The software-defined architecture inverts this relationship. A hardware abstraction layer decouples software from specific electronic control units, allowing applications to be developed, tested, and deployed independently of the underlying hardware. Vehicle functions that were once implemented in dedicated silicon — advanced driver assistance, climate control logic, battery management — become software services running on high-performance compute platforms. The AUTOSAR Adaptive Platform provides the middleware layer that makes this possible, defining standard interfaces for service discovery, communication, and lifecycle management.

This architectural shift enables capabilities that were impossible under the old model. Manufacturers can improve vehicle performance after the point of sale. A battery management algorithm can be refined based on real-world fleet data and deployed to every vehicle in the field. An advanced driver assistance system can be upgraded to handle new road scenarios. Features that weren't ready at launch can be enabled later via software update, turning the vehicle from a static product into an evolving platform.

But these capabilities come with governance implications that the industry is only beginning to reckon with.

New attack surfaces, new governance requirements

Every capability that makes software-defined vehicles compelling also introduces governance challenges that the traditional automotive safety framework was not designed to address.

Over-the-air updates to safety-critical systems create a fundamental tension between innovation velocity and safety assurance. When a manufacturer can push a software update to millions of vehicles simultaneously, the blast radius of a defective update is enormous. The update might improve braking performance in most conditions but degrade it in a specific edge case — wet cobblestones at a particular temperature range, for instance — that wasn't covered by the test suite. Unlike a mechanical recall, which is visible, trackable, and reversible in a garage, a software update happens silently and may interact with other system state in unpredictable ways.

Machine learning in perception and decision-making introduces opacity into safety-critical functions. A neural network that processes camera and lidar data to identify pedestrians, cyclists, and other road users does not operate according to deterministic rules that can be exhaustively verified. Its behaviour is an emergent property of its training data, its architecture, and its interaction with the broader system. When that system makes an error — misclassifies a pedestrian, misjudges a closing speed — the question of why it failed is often genuinely difficult to answer, even for the engineers who built it.

Connected vehicle data flows raise questions about data sovereignty, privacy, and security that cross jurisdictional boundaries. A vehicle manufactured in Germany, sold in France, and driven through Switzerland generates telemetry that may be processed by cloud services hosted in Ireland. Which jurisdiction's data protection rules apply? Who owns the data — the manufacturer, the driver, the fleet operator? When that data feeds back into machine learning training pipelines, how does the manufacturer ensure compliance with data minimisation principles across every jurisdiction where its vehicles operate?

Supply chain complexity compounds all of these challenges. A tier-one supplier provides the sensor fusion module, another provides the planning algorithms, a third provides the connectivity stack, and the original equipment manufacturer integrates everything into a vehicle that must function as a coherent, safe system. When something goes wrong, tracing the fault through multiple vendors' software stacks — each with their own development processes, testing standards, and update cycles — is a governance challenge of considerable difficulty.

The regulatory landscape

Regulators are responding to these challenges, though the pace and approach vary significantly across jurisdictions.

The most consequential regulatory development in Europe is the interaction between the EU AI Act and the existing vehicle type-approval framework. The AI Act classifies AI systems used in safety components of vehicles as "high-risk," subjecting them to requirements for risk management, data governance, transparency, human oversight, accuracy, robustness, and cybersecurity. These requirements apply on top of the existing UNECE WP.29 regulations, which already mandate cybersecurity management systems (UN Regulation No. 155) and software update management systems (UN Regulation No. 156) for all new vehicles sold in the European Union.¹

The practical challenge is that these regulatory frameworks were developed by different bodies with different assumptions. The AI Act's requirements for transparency and explainability — the ability to understand why a system made a particular decision — sit uneasily alongside the reality of deep neural networks whose decision-making processes resist simple explanation. UNECE's software update regulations require manufacturers to demonstrate that updates do not compromise vehicle safety, but the regulations were written before continuous deployment pipelines and machine learning model updates were common practice.

In the United States, the National Highway Traffic Safety Administration (NHTSA) has taken a less prescriptive approach, relying more heavily on manufacturer self-certification and post-market surveillance. NHTSA's Standing General Order on crash reporting for vehicles equipped with automated driving systems and advanced driver assistance systems represents a data-driven approach to regulation — collect incident data at scale and use it to identify systemic safety issues. Whether this approach provides sufficient proactive governance, rather than reactive oversight after incidents occur, remains an open question.

China's regulatory framework, implemented through the Ministry of Industry and Information Technology (MIIT) and a complex web of national standards, takes yet another approach, with stricter requirements around data localisation and algorithmic transparency that reflect both safety concerns and broader strategic priorities around data sovereignty.²

For manufacturers operating globally, the fragmentation of regulatory approaches is itself a governance challenge. A vehicle platform sold across multiple jurisdictions must comply with overlapping and sometimes contradictory requirements. The governance infrastructure needed to manage this complexity — tracking which regulations apply to which software components in which markets, ensuring that updates comply with all applicable frameworks, maintaining audit trails that satisfy regulators in every jurisdiction — is substantial.

Over-the-air updates and safety assurance

The governance of over-the-air updates deserves particular attention because it crystallises the tension between the software-defined vehicle's promise and its risks.

UNECE UN Regulation No. 156 requires manufacturers to implement a Software Update Management System (SUMS) that covers the entire lifecycle of an update: identification of the target vehicle population, risk assessment, testing, deployment, and monitoring. The regulation requires that manufacturers be able to demonstrate that an update does not adversely affect the safety, security, or compliance of the vehicle. For updates that affect type-approved characteristics, a new approval may be required.

In practice, implementing this governance framework at scale is enormously complex. A single vehicle platform may have thousands of software components from hundreds of suppliers. An update to one component may interact with others in ways that are difficult to predict. The testing required to demonstrate safety is proportional to the update's scope and the criticality of the affected systems, but determining that scope requires a detailed understanding of the dependency graph across the entire vehicle software stack.

The most mature approach we have seen involves layered governance. Safety-critical updates — anything touching braking, steering, powertrain, or occupant protection — go through a full validation cycle that mirrors the rigour of the original type-approval process, including hardware-in-the-loop testing, simulated driving scenarios, and controlled fleet trials. Updates to non-safety-critical systems — infotainment features, user interface refinements, comfort settings — follow a lighter process with automated regression testing and staged rollouts. The challenge is maintaining clear, auditable boundaries between these categories when the software architecture increasingly blurs the lines between them.

The Eclipse Software Defined Vehicle working group's projects address several of these challenges directly. Their vehicle update and device management projects provide open reference implementations for update orchestration, including staged rollouts, rollback mechanisms, and fleet monitoring. By building these capabilities as shared, open infrastructure rather than proprietary implementations, the industry benefits from collective security review and a common base of operational experience. A vulnerability discovered in one deployment can be patched across the ecosystem, rather than requiring each manufacturer to independently identify and fix the same issue.³

Open standards as governance infrastructure

The governance challenges outlined above share a common structural feature: they require coordination across organisational boundaries. No single manufacturer, no matter how capable, can unilaterally define the governance standards for an industry in transition. The standards must be developed collaboratively, and the most effective vehicle for that collaboration is open, consortium-based standard development.

COVESA (the Connected Vehicle Systems Alliance) illustrates how open standards serve as governance infrastructure. Their Vehicle Signal Specification (VSS) provides a standardised taxonomy and ontology for vehicle data — a common language that every participant in the ecosystem can use to describe what a vehicle is doing, sensing, and reporting. This is not merely a technical convenience. When regulators require manufacturers to report telemetry data for safety monitoring, a shared signal specification makes that reporting consistent, comparable, and auditable across manufacturers. When data protection authorities need to understand what personal data a vehicle collects, a standardised data model makes that assessment tractable.

The SOAFEE (Scalable Open Architecture for Embedded Edge) initiative addresses governance at the platform level. By defining a cloud-native software architecture for vehicles — based on containers, orchestration, and standardised hardware abstraction — SOAFEE makes it possible to apply the same governance tooling and processes across different vehicle platforms. Continuous integration, automated security scanning, software bill of materials generation, and compliance checking can be implemented once against the SOAFEE reference architecture and applied consistently across every vehicle platform that adopts it.

The AUTOSAR Adaptive Platform provides the foundational middleware layer that makes this governance tractable. Its standardised interfaces for service communication, diagnostics, and lifecycle management create the stable contracts that governance processes depend on. When a regulator asks "can you demonstrate that this update does not affect the vehicle's braking system?", the answer depends on having well-defined interfaces between the braking service and the updated component — interfaces that AUTOSAR Adaptive standardises.

These open standards are not governance frameworks themselves, but they provide the infrastructure on which governance frameworks can be built. They make the vehicle software stack legible — to engineers, to auditors, and to regulators — in a way that proprietary, vertically integrated stacks do not. This legibility is a precondition for effective governance, and it is why open standards participation is not merely a cost-saving exercise for the automotive industry but a strategic investment in the industry's ability to govern itself credibly.⁴

From compliance burden to engineering discipline

The most forward-thinking organisations in the automotive industry are moving beyond a compliance-oriented view of governance — where the goal is to satisfy regulatory requirements at minimum cost — toward an engineering-discipline view, where governance is an integral part of the software development process.

This shift has practical implications. Instead of treating safety validation as a gate at the end of the development cycle, governance-as-discipline integrates safety analysis into every stage. Threat modelling happens during architecture design, not as a post-hoc review. Safety cases are living documents that evolve with the software, not static artefacts produced for a type-approval milestone. Update validation is automated and continuous, not manual and periodic.

The tooling for this approach is increasingly available through open source. The OpenMobility working group at the Eclipse Foundation is developing open simulation standards that allow manufacturers to validate autonomous driving functions against standardised scenario libraries. The Eclipse Tractus-X project provides the data exchange infrastructure for automotive supply chains, enabling the kind of cross-vendor software bill of materials tracking that regulators are beginning to require. The LFAI & Data Foundation's Trusted AI initiative offers frameworks for assessing the fairness, robustness, and transparency of machine learning models — directly applicable to the AI components in advanced driver assistance and autonomous driving systems.

The organisations that adopt this engineering-discipline approach will find themselves better prepared not only for current regulations but for the regulatory evolution that is certain to come. The EU AI Act's requirements for high-risk AI systems will be refined through implementing acts and harmonised standards over the coming years. UNECE's software update regulations will be extended as the industry gains operational experience. New regulations addressing connected vehicle data, algorithmic liability, and cross-border governance are in various stages of development across multiple jurisdictions.

Treating governance as an afterthought — a compliance cost to be minimised — leaves organisations perpetually reactive, scrambling to meet each new requirement as it emerges. Treating governance as an engineering discipline — embedded in processes, supported by open tooling, aligned with industry standards — creates an organisation that can absorb regulatory change as a matter of course.

The automotive industry's transition to software-defined vehicles is irreversible. The governance infrastructure needed to make that transition safe, trustworthy, and sustainable is still being built. The organisations that contribute to building it — through open standards, collaborative regulation, and shared engineering practices — will be the ones that shape the industry's future. Those that wait for governance to be imposed from outside will find themselves constrained by frameworks they had no hand in designing.

Footnotes

1. UNECE's World Forum for Harmonization of Vehicle Regulations (WP.29) maintains the full text of UN Regulations No. 155 (cybersecurity) and No. 156 (software updates), which became mandatory for all new vehicle types in the EU from July 2024. ↩

2. The fragmentation of automotive AI regulation across jurisdictions is examined in detail by the International Transport Forum, which publishes comparative analyses of regulatory approaches to automated driving across OECD member states. ↩

3. The Eclipse SDV working group's project landscape provides a comprehensive overview of the open-source projects addressing vehicle software infrastructure, including update management, vehicle abstraction, and fleet orchestration. ↩

4. COVESA publishes the Vehicle Signal Specification and its governance model as open resources on GitHub, with a specification process that allows any member organisation to propose extensions and modifications through a structured review process. ↩