Software-related vehicle recalls surged 80% in 2024 — from 112 cases in 2023 to 202 in 2024 (Envorso, WardsAuto). Software-related issues accounted for 44% of all recalled vehicles — 15 million units in the US in a single year. This is not a temporary anomaly. It is the consequence of a structural shift in how vehicles are engineered: the vehicle has become a software-defined platform, and the industry’s software engineering practices have not yet caught up to the quality expectations that implies.
The automotive OTA (over-the-air) update market is valued at $4.99 billion in 2025, growing to $5.93 billion in 2026 and projected to reach $29 billion by 2035 at approximately 19% CAGR (GM Insights). More than 55% of new vehicles now support OTA capabilities. OTA is simultaneously the mechanism that allows manufacturers to fix software defects without dealer visits and the mechanism that, if mishandled, introduces new defects into safety-critical systems at fleet scale.
The engineering challenge of the software-defined vehicle is not building software for a car. It is building software — at automotive quality, safety, and cybersecurity standards — for a platform that will be in service for 15 years, receive updates throughout its life, and cannot be taken offline for maintenance.
What Software-Defined Vehicle Actually Means
“Software-defined vehicle” is used inconsistently in industry discourse. The engineering-precise definition: a vehicle whose functionality — from powertrain control to ADAS to infotainment to access control — is primarily implemented in software on centralized compute hardware, rather than in dedicated hardware per function.
The contrast is with the traditional distributed E/E (electrical/electronic) architecture: vehicles with 100+ ECUs (electronic control units), each implementing a specific hardware function in firmware, connected by CAN bus networks. This architecture worked when vehicle features were implemented once at manufacturing time and did not change. It does not work when features must be added, updated, and reconfigured over a 15-year vehicle life.
The SDV architecture targets 3–5 domain or zone controllers — high-performance compute units that consolidate what previously ran on dozens of separate ECUs. The software on these controllers is decoupled from the hardware it runs on, enabling software updates without hardware changes, feature-as-a-service business models (enabling features after purchase via subscription), and faster development cycles that are not constrained by hardware ECU lead times.
Three OEM platforms that have moved from announcement to production vehicle commitment:
- GM Ultifi — targeting 2025–2027 production vehicles; a software platform layered over GM’s vehicle compute architecture enabling third-party app development and OTA feature delivery
- Mercedes-Benz MB.OS — announced for 2025 production; an in-house developed automotive operating system replacing supplier-provided software stacks with a centralized platform
- BMW Neue Klasse — launching 2025–2026; the first BMW architecture built ground-up for SDV, with in-house developed software and zonal E/E architecture
AUTOSAR Classic vs. Adaptive: The Architectural Fork
The software architecture that underpins most production automotive software is AUTOSAR (AUTomotive Open System ARchitecture). In 2026, AUTOSAR exists in two distinct variants that serve different purposes and require different engineering expertise:
AUTOSAR Classic Platform is the foundation for ECU-level safety functions — brake control, steering assist, airbag deployment, powertrain management. Classic uses OSEK/OS (a statically configured real-time operating system), MISRA C for safety-critical code, and a component model (Autosar Software Components) that makes software portable across hardware platforms from different suppliers.
The key constraint of Classic: everything is statically configured at build time. The number of tasks, their priorities, the communication matrix, the memory layout — all decided at compile time. This determinism is essential for ASIL-D safety functions but makes Classic unsuitable for the flexible, dynamic compute environments that ADAS perception and OTA-updatable features require.
AUTOSAR Adaptive Platform addresses this. Adaptive uses POSIX-compliant operating systems (typically Linux or QNX), dynamic service discovery (via ara::com, built on DDS/SOME/IP), and C++14. It is designed for centralized domain controllers running ML inference, HD map processing, and complex behavioral planning — functions that require computational flexibility, regular updates, and integration with cloud services.
The E/E architecture migration from distributed Classic to centralized Adaptive is the central engineering challenge of the SDV transition:
- Legacy vehicles have communication matrices built around CAN bus bandwidth (~500 Kbps) — the new zonal architectures use automotive Ethernet (100BASE-T1, 1000BASE-T1) for high-bandwidth backbone communication
- Software that ran isolated in a dedicated ECU must now share compute resources on a mixed-criticality platform, requiring hypervisor-based ASIL decomposition (separating ASIL-D functions from QM applications on the same silicon)
- The development toolchain for Classic (EB tresos, Vector AUTOSAR) differs from Adaptive (CMake-based builds, containerized development environments), requiring engineering teams to maintain parallel expertise
OTA Update Architecture: The Engineering of Safe Remote Software Delivery
OTA updates to vehicles are not equivalent to app updates on a phone. The consequences of a failed or corrupted update can include vehicle immobility (a non-safety consequence, but a customer experience failure) or, for safety-critical software, a defect introduced at fleet scale before it is detected.
The UNECE WP.29 R156 regulation — mandatory for new vehicle type approvals in the EU, Japan, and Korea since July 2024 — requires manufacturers to implement and certify a Software Update Management System (SUMS). SUMS certification requires:
- Cryptographic signing of all software packages delivered via OTA, with verification at the ECU level before installation
- Rollback capability — if an update fails or introduces a critical defect, the vehicle must be able to revert to the previous known-good software state
- Bandwidth-efficient delta updates — for large codebases (ADAS neural networks can exceed 1GB), full image OTA is impractical; delta encoding (sending only the changed portions) requires matching the installed version precisely
- Campaign orchestration — managing update delivery across millions of vehicles in a fleet, respecting update windows (vehicle stationary, connected to power), prioritization of safety-critical updates, and tracking of update completion rates
- Safety state preservation during updates — an ADAS update cannot be applied while the vehicle is in motion; the SUMS must coordinate with the vehicle operating state to ensure updates are applied at safe times only
Tesla held 24.9% market share of the OTA update market in 2025 — its SUMS infrastructure is the most mature in the industry and has been used to deploy both feature additions and safety-critical recalls remotely. The rest of the industry is building equivalent infrastructure on compressed timelines driven by regulatory mandate.
Automotive Cybersecurity: What ISO/SAE 21434 and UNECE R155 Require
The automotive cybersecurity market is projected to reach $21.44 billion by 2035 at 18.5% CAGR (Coherent Market Insights). The growth is driven by regulation, not just market demand: UNECE WP.29 R155 mandates a certified Cybersecurity Management System (CSMS) for vehicle type approval in the EU, Japan, and Korea.
ISO/SAE 21434:2021 is the engineering standard that CSMS certification is built on. It defines:
TARA (Threat Analysis and Risk Assessment): For every system in scope, engineers must identify assets (what has value — vehicle data, user credentials, control authority), threat scenarios (how an attacker could compromise those assets), vulnerabilities (technical weaknesses that enable the threat), and the resulting risk (a function of attack feasibility and impact). The TARA must be completed before the architecture is finalized — security requirements are derived from the risk assessment, not added afterward.
Cybersecurity requirements traceability: Security requirements derived from the TARA must be traceable through design decisions, implementation choices, and verification test cases. This is analogous to functional safety requirements traceability under ISO 26262 — and for teams that already maintain ASIL traceability matrices, adding security traceability to the same toolchain (PTC Integrity, IBM DOORS, Polarion) is operationally feasible.
Post-production vulnerability disclosure (PSIRT): ISO/SAE 21434 mandates that manufacturers maintain a Product Security Incident Response Team process — a defined workflow for receiving external vulnerability reports, assessing impact, developing patches, and releasing updates. This is a permanent operational requirement, not a one-time certification activity.
The attack surface engineers must model includes V2X (Vehicle-to-Everything) communication (IEEE 802.11p / DSRC, C-V2X), Bluetooth and Wi-Fi connectivity, OBD-II diagnostic port access, backend API interfaces used by mobile apps, and the OTA update channel itself. Each interface is an entry point that must appear in the TARA and have security controls designed and verified.
The Software Recall Problem: Quality at Fleet Scale
44% of all recalled vehicles in 2024 had software root causes. The engineering factors driving this:
Neural network updates without distribution shift detection. ADAS perception models updated via OTA improve average-case performance but may perform worse on specific input distributions that were not covered by the post-update test suite. Without production monitoring that tracks perception output distributions in deployed vehicles and alerts when outputs drift from expected patterns, regressions are detected by customer complaints or incident investigations — not by the engineering team.
Insufficient HIL (Hardware-in-the-Loop) test coverage. HIL testing runs software on real ECU hardware connected to simulated sensors and actuators, validating real-time behavior that cannot be captured in software simulation. For OTA updates to safety-critical functions, HIL regression coverage of the full test matrix is required before deployment — but the timeline pressure to deliver OTA fixes quickly creates a temptation to reduce HIL coverage, which is where regressions slip through.
Mixed-criticality scheduling on shared compute. When ASIL-D safety functions and QM (quality managed) feature applications share the same compute platform, a QM process that exceeds its time budget can starve safety-critical processes of CPU time. Hypervisor-based isolation (INTEGRITY RTOS, QNX Hypervisor) and CPU affinity assignment are the mitigations — but their correct configuration requires validation at the integrated platform level, not just at the component level.
ISO 20022 Integration for Connected Vehicle Financial Services
Vehicle software is increasingly integrated with financial services — insurance telematics, usage-based parking, road pricing, V2G (vehicle-to-grid) energy settlements, and subscription feature billing. The financial messaging standard ISO 20022 is the data model that these vehicle-to-financial-infrastructure integrations must target.
ISO 20022’s rich structured data format (vs. legacy MT messages) enables precision in transaction data that matters for automotive use cases: a road pricing event with vehicle type, distance, time-of-day, and emissions class information can be communicated in a single ISO 20022 message that legacy formats cannot express without multiple transaction records. For engineers building connected vehicle financial integration: designing the vehicle’s financial data API layer around ISO 20022 data models from the beginning avoids the translation overhead of mapping proprietary formats to the payment network standard later.
How we approach this at Insoftex
Automotive software engineering is a domain where the standards compliance burden — ISO 26262, ISO/SAE 21434, AUTOSAR, UNECE WP.29 — is substantial enough that teams without prior automotive experience consistently underestimate project scope. We scope compliance requirements as part of the architecture engagement, not as a post-development checklist.
For clients entering automotive software development — either building Tier 2 supplier software components or developing automotive-grade data and analytics platforms — we identify which standards apply to the specific system scope (not every component requires ASIL-D; scoping correctly avoids over-engineering), design the development toolchain around the traceability requirements from day one, and ensure the team understands the difference between automotive software quality expectations and general enterprise software quality expectations before architecture decisions are made.
The SDV transition is creating software engineering opportunities in automotive that did not exist two years ago. The companies that capture those opportunities are those that understand both what the OEM requires and what the software engineering practices are that can reliably deliver it.
Building automotive software components, connected vehicle platforms, or ADAS features? Our automotive engineering team works on connected-vehicle cloud systems, OTA infrastructure, diagnostics, and ADAS-adjacent software. Start with a Product Pilot for a standards scoping assessment — identifying which ISO 26262, ISO/SAE 21434, and AUTOSAR requirements apply before you commit to a development approach.