2026 SDV agenda · Türkiye
Software-Defined Vehicles: Zonal Architecture, OTA and QNX
TARGET TechNews · Updated
A software-defined vehicle, or SDV, is an approach in which functions can evolve through software and be updated after delivery. Moving from distributed ECUs to zonal and central compute requires joint planning of real-time behavior, safety, cybersecurity and the OTA update lifecycle.
Integration and delivery time are putting SDV programs under pressure
QNX's Under the Hood 2026 study reports the views of 1,100 embedded automotive software developers worldwide. Across developers, 80% say their businesses should focus more on application-layer innovation and less on foundational infrastructure. The figures below describe respondents' views, not market size or measured product performance.
VPs of Engineering surveyed agree that OEMs should focus on application-layer innovation rather than foundational infrastructure.
UN R155 and ISO/SAE 21434 frame the cybersecurity lifecycle; UN R156 addresses software update management and additional OTA safeguards; ISO 24089 covers update engineering at organizational and project levels. OTA is more than remote package delivery: it includes version and integrity records, target-vehicle compatibility, validation, secure installation, and recovery after a failed update. SOVD and AUTOSAR Adaptive also support service-oriented vehicle software. Survey figures: QNX Under the Hood 2026. Integration complexity and lack of scalability across platforms were each cited by 36% in separate answers. For the scope of software update engineering, see the ISO 24089 overview.
From distributed ECUs to zonal and central architectures
The SDV transition is not only about reducing ECU count. The QNX BSP layer supports hardware abstraction by separating board- and processor-specific initialization and drivers from application software. This can reduce porting and reintegration work when supported processor generations or suppliers change. General-purpose operating systems suit many in-vehicle applications, while safety-critical functions also need deterministic behavior, certification support, and controlled isolation. QNX OS® for Safety and QNX Hypervisor for Safety 8.0 address these requirements across real-time and mixed-criticality workloads.
One ECU per function
Separate hardware and software for each function, with heavy integration work and disconnected update cycles.
Workload consolidation
Cockpit, ADAS, and body functions consolidate on domain controllers and share resources with controlled isolation.
Shared software platform
Central vehicle computers, service-oriented data flows, and functions that can be updated throughout vehicle life.
QNX supports the foundational software layer for SDVs
The QNX portfolio combines a real-time operating system with virtualization so application teams can focus on vehicle functions instead of rebuilding infrastructure. The right product depends on the processor, safety target, cybersecurity scope, and consolidation plan.
A high-performance, safety-ready microkernel RTOS platform for central and zonal compute architectures.
An RTOS foundation certified by TÜV Rheinland to ISO 26262 ASIL D. In the context of ISO/SAE 21434, it supports cybersecurity risk assessment, threat analysis, secure development, and lifecycle practices across vehicle programs.
Supports the consolidation of an Android-based cockpit, general-purpose applications, and safety-critical ADAS workloads in strongly isolated domains on one SoC. Its safety scope does not extend to the standard QNX Hypervisor 8.0; guest OS and target-SoC support are confirmed per program.
Co-developed by QNX and Vector, Alloy Kore provides a pre-integrated software foundation for software-defined vehicles. Distribution, release, licensing and certification scope must be confirmed for the program.
Which QNX software layer does an SDV program need?
Zonal architecture is not the name of an operating system. Product selection is incomplete until the team determines where functions run, which resources they share and how they are updated. Read the existing product illustrations alongside the responsibilities and scope distinctions below.
| Layer | Evaluation purpose | Scope to verify |
|---|---|---|
| QNX SDP 8.0 | Real-time application development and an operating-system foundation. | Processor, BSP, drivers and development tools. |
| QNX OS for Safety | A certified OS component for applications with safety requirements. | Release, certificate and conditions in the integration manuals. |
| QNX Hypervisor for Safety | Separation of guest systems and workloads with different criticality levels. | Guest support, resource allocation, device sharing and fault behavior. |
| Alloy Kore | Foundational vehicle software combining QNX and Vector components. | Distribution, release, interfaces, licensing and supplied certification scope. |
The 6 January 2026 announcement distinguished Alloy Kore Early Access from a certified release planned for late 2026. That dated plan is not proof that every distribution is currently certified. Verify the current package together with its certification documents.
How can development start before target hardware arrives?
QNX Accelerate is an initiative that enables supported QNX software on cloud targets; it is not a separate automotive certificate. A cloud environment can help separate application development and shared testing from physical-hardware availability. Match the OS release, processor architecture and marketplace offering being used.
- Define vehicle functions and interfaces, separating hardware-dependent behavior.
- Prepare application and interface tests on a suitable cloud target; record releases and configuration.
- Reassess peripherals, resource sharing and timing on the target SoC/BSP.
- Complete performance, safety and update verification on the physical system.
Successful cloud execution does not validate the software on every vehicle platform. Consult the QNX Accelerate overview to define an appropriate starting scope.
What requirements should a technical discussion cover?
- Vehicle functions and data flows allocated to central or zonal computers.
- SoC/BSP selection, guest operating systems and timing targets.
- Safety objectives, cybersecurity responsibilities and supplier boundaries.
- OTA package compatibility, validation, failed-update recovery and lifecycle expectations.
- Testing and integration work remaining between prototype and production release.
Review the TARGET QNX portfolio for product options. For the distinct question of why SAE driving levels and ASIL D describe different concepts, read the automated-driving and safety article.
Evaluate your SDV architecture against real program requirements
Work with TARGET to clarify vehicle functions, the processor platform, safety targets, and the consolidation approach. This creates a practical technical evaluation scope for the appropriate QNX product and variant.
