A software-defined vehicle (SDV) represents a shift in automotive development, where vehicle functions and capabilities are increasingly implemented, managed, and enhanced through software. This approach requires an underlying computing and electrical/electronic (E/E) architecture capable of supporting how these functions are distributed, isolated, connected, validated, and updated throughout the vehicle's lifecycle.
The challenge extends beyond enabling over-the-air updates or introducing advanced digital interfaces. As vehicles become increasingly software-driven, manufacturers must determine how to introduce new capabilities without continuously adding hardware, increasing integration complexity, or compromising safety and reliability.
Addressing these challenges requires coordinated architectural decisions involving computing resources, software platforms, communication networks, physical infrastructure, and lifecycle management. Each decision introduces trade-offs that influence development costs, system integration, scalability, and long-term vehicle support.
Why architecture is the foundation of a Software-Defined Vehicle
Software-defined vehicles depend on an architecture that allows different functions to operate reliably while supporting future software improvements. The electrical/electronic (E/E) architecture provides the computing resources, communication networks, power distribution, and physical interfaces needed to make this possible.
For example, a driver-facing application may share computing hardware with a time-critical vehicle control function. Even when these applications run on the same platform, the architecture must ensure that critical operations meet their timing and isolation requirements. This involves careful coordination of resource allocation, real-time scheduling, and communication between systems.
Over-the-air (OTA) updates can introduce new features and improvements, but their capabilities remain limited by the underlying hardware and software architecture. A well-designed SDV platform provides the foundation for deploying, integrating, and maintaining these capabilities throughout the vehicle's lifecycle.
Key components of Software-Defined Vehicle architecture
A software-defined vehicle architecture brings together five interconnected areas: computing, software platforms, communication networks, physical infrastructure, and lifecycle tools. Together, they determine how vehicle functions are executed, connected, validated, and maintained.
Computing and function allocation
The computing layer determines where vehicle functions are executed, whether on central processors, domain or zonal controllers, dedicated electronic control units (ECUs), or a combination of these. These decisions influence processing performance, resource allocation, system complexity, and fault management.
Rather than focusing exclusively on reducing the number of ECUs, function allocation should be based on the vehicle's technical requirements. Some workloads can share computing resources, while others may require dedicated interfaces, independent execution, or specific recovery mechanisms to maintain reliable operation.
Operating systems and middleware
The software platform provides the environment in which vehicle functions operate. It includes operating systems, real-time scheduling, middleware, communication services, and applications. Depending on the architecture, different execution environments may support time-critical control functions and more flexible application workloads.
Middleware enables communication between software components and helps manage integration across systems and suppliers. A well-defined software architecture establishes how applications exchange information, access resources, handle failures, and maintain compatibility as the platform evolves.
Networks and vehicle interfaces
Vehicle networks connect computing systems to controllers, sensors, and actuators. Depending on the architecture, these connections may use Automotive Ethernet, Controller Area Network (CAN), Local Interconnect Network (LIN), and gateways that enable communication between different protocols.
Wiring and power distribution
The physical infrastructure includes wiring harnesses, connectors, power distribution systems, and sensor and actuator input/output (I/O) interfaces. These elements remain essential even as vehicle functions become increasingly software-driven and computing resources are consolidated.
Changes in computing and network architecture can also affect the vehicle's physical design. Engineers must consider cable routing, connector requirements, power delivery, environmental conditions, diagnostics, and maintenance. Reducing the number of computing units does not automatically guarantee equivalent reductions in wiring complexity, weight, or installation costs.
Development and lifecycle tools
Software-defined vehicles require tools and processes to develop, validate, update, diagnose, and maintain software throughout their operational life. These capabilities include over-the-air (OTA) updates, software configuration management, testing environments, diagnostic systems, and deployment infrastructure.
Lifecycle engineering also connects software development with long-term vehicle support. Teams must establish how requirements are validated, how software versions are managed, and how faults are identified after deployment. Testing methods such as hardware-in-the-loop (HIL) simulation can help validate integrated functions under defined operating conditions.
Key Requirements for SDV Architecture
A software-defined vehicle architecture must support more than the functions available when a vehicle is first manufactured. It must meet requirements for real-time performance, functional safety, cybersecurity, scalability, software updates, cost efficiency, and long-term maintenance. These requirements influence how vehicle systems are designed, integrated, and supported throughout their operational life.
Predictable End-to-End Timing
Real-time performance is essential for vehicle functions that must respond within defined deadlines. Unlike systems measured primarily by average processing speed, time-critical automotive applications require predictable execution under specified operating conditions.
Achieving this predictability involves coordinating task scheduling, computing resources, communication networks, and input/output (I/O) operations. Research on DrakoTech's DriveOS architecture illustrates how these elements can be evaluated together within a centralized vehicle-management system.
For functions involving braking, steering, or powertrain control, timing requirements must also account for system interference, processing loads, communication delays, and fault recovery. Performance demonstrated in one configuration cannot automatically be treated as a guarantee across different vehicles or operating conditions.
Functional safety and isolation
Functional safety is the absence of unreasonable risk due to hazards caused by malfunctioning behaviour of electrical and electronic (E/E) systems. The ISO 26262 series provides a framework for addressing functional safety throughout automotive development, including the application of Automotive Safety Integrity Levels (ASILs) to safety-related requirements.
In SDV architectures, particular challenges arise when safety-critical and non-critical applications share computing hardware. Isolation mechanisms, such as resource partitioning and controlled communication, help prevent one workload from interfering with another.
The DriveOS research illustrates an implementation in which real-time services and other software operate in separated execution environments in the same physical platform. However, functional safety must ultimately be demonstrated through documented requirements, system-specific analysis, testing, and appropriate assessment evidence.
Cybersecurity and secure updates
As vehicles become more connected and software-driven, cybersecurity becomes essential to protecting vehicle systems and their communication interfaces. While functional safety addresses risks from system malfunctions, cybersecurity focuses on threats such as unauthorized access, malicious interference, and software manipulation.
Several standards and regulations guide this area. ISO/SAE 21434 addresses cybersecurity engineering across the vehicle lifecycle, while UN Regulation No. 155 covers vehicle cybersecurity and cybersecurity management systems. UN Regulation No. 156 and ISO 24089 address software updates and their management.
Secure software updates require more than delivering new code to a vehicle. Authentication, software integrity, controlled deployment, vulnerability management, and recovery procedures must be considered throughout the lifecycle.
Regulatory requirements may vary according to the vehicle category and markets where it will be sold. For manufacturers operating in India or exporting internationally, the applicability of each regulation should be assessed against the relevant vehicle programme.
Scalability and software updatability
An SDV architecture should support the evolution of vehicle functions across different models, configurations, and generations. A scalable software platform can enable manufacturers to reuse components, maintain consistent interfaces, and adapt functionality without redesigning the entire system for every vehicle variant.
Software updatability is another essential consideration. Over-the-air (OTA) updates can enable feature improvements, maintenance, and security fixes after production, provided the vehicle's hardware and software architecture support those changes.
However, software updates cannot overcome every physical limitation. Available processing power, memory, sensors, actuators, interfaces, and thermal capacity determine which new capabilities can be introduced without hardware modifications.
Cost efficiency and long-term support
Architecture decisions directly influence vehicle development, manufacturing, and maintenance costs. Beyond the bill of materials (BOM), manufacturers must consider wiring complexity, harness weight, assembly labor, integration, validation, licensing, cooling, and redundancy requirements.
Consolidating computing resources or reusing software platforms may offer opportunities for simplification, but the financial benefits depend on the specific vehicle configuration and implementation. Cost comparisons should therefore consider both initial development and long-term operational requirements.
Long-term support is particularly important for commercial vehicles and platforms designed to remain in service for many years. Manufacturers must plan for software compatibility, security updates, replacement hardware, diagnostics, and continued access to development and maintenance tools.
Architecture Choices and Trade-Offs
Designing a software-defined vehicle requires balancing computing performance, functional safety, integration complexity, and long-term flexibility. Each architectural approach presents trade-offs that influence how vehicle functions are developed, connected, and maintained.
Centralization and Edge Responsibilities
Centralized computing and zonal architecture address different aspects of vehicle design. Centralization determines where processing functions execute, while zoning organizes electronic systems according to their physical location.
These approaches can coexist. Central processors may handle advanced applications while local controllers manage sensors, actuators, and time-sensitive functions. The optimal distribution depends on processing requirements, communication latency, fault tolerance, and system availability.
Hypervisors and Separation Kernels
When safety-critical and non-critical applications share computing hardware, workload isolation becomes essential. Hypervisors create and manage separate execution environments on shared hardware. Separation kernels are a minimal, partitioning-focused form of this approach, designed to strictly partition resources and permit communication only through defined channels..
Both approaches typically rely on hardware virtualization features. The published DriveOS describes a separation-kernel architecture, operating as a partitioning hypervisor, that assigns dedicated processor cores, isolated memory regions and I/O devices to each environment. The appropriate strategy depends on timing requirements, resource allocation, and fault-management needs.
Backbone and Legacy Networks
Vehicle networks connect central computers, controllers, sensors, and actuators. Automotive Ethernet supports higher-bandwidth communication, while established protocols such as CAN and LIN remain relevant for many vehicle functions.
Network design involves trade-offs between bandwidth, latency, reliability, and compatibility. Gateways can connect different protocols but introduce additional integration requirements. Alternative implementations, including DrakoTech's USB-based approach, must also be evaluated against the vehicle's communication and performance needs.
Conventional and Digital Harnesses
Wiring harnesses carry power and communication signals throughout the vehicle. As computing architectures evolve, manufacturers can explore alternative designs that reorganize physical connections and simplify integration.
Digital harness technologies, including DrakoTech's DigiHarness™, represent one approach to this evolution. However, potential improvements in wiring complexity, weight, and manufacturing costs depend on the vehicle configuration, network topology, and implementation.
General-Purpose and Specialized Silicon
Processor selection influences computing performance, power consumption, integration flexibility, and reliability. SDV architectures may use general-purpose processors, specialized automotive chips, or combinations of both.
General-purpose computing can support function consolidation, as explored in the 2021 DriveOS study. However, hardware suitability depends on meeting automotive requirements for timing, isolation, environmental conditions, fault handling, and long-term support.
Building In-House or Partnering with Technology Providers
Manufacturers must decide whether to develop their SDV platforms internally, license existing solutions, or collaborate with specialized technology providers.
Internal development offers greater control over architecture and software ownership but requires sustained engineering investment. Partnerships can provide established technologies and specialized expertise, although integration responsibilities and supplier dependencies remain important considerations.
The best approach depends on development capabilities, interface ownership, customization requirements, and long-term platform support.
Summary of SDV Architecture Trade-Offs
These decisions are interconnected. Changes in computing architecture can affect network topology, wiring, software integration, and validation requirements. Evaluating these trade-offs together helps manufacturers select an architecture aligned with their vehicle platforms and long-term objectives.
Implications for Indian automotive teams
For India's automotive industry, adopting software-defined vehicle architecture involves balancing technological innovation with affordability, integration complexity, and long-term platform flexibility. According to a 2025 ETAuto interview with Continental Automotive India, manufacturers are pursuing different approaches to SDV development, shaped by cost considerations, technical ambitions, and integration requirements.
One major challenge is integrating software and components from multiple suppliers into a coordinated vehicle architecture. As computing becomes more centralized, manufacturers must establish clear interfaces, communication standards, and responsibilities across systems that may have been developed independently.
Platform scalability is another important consideration. Reusing software and computing resources across vehicle models can create opportunities to reduce development complexity, but manufacturers must still account for differences in hardware configurations, safety requirements, and validation processes.
For Indian OEMs and Tier 1 suppliers, a successful SDV strategy therefore requires more than selecting a particular computing architecture. It involves developing a platform that supports integration, meets the relevant safety and regulatory requirements, and remains economically viable throughout the vehicle's lifecycle.
How DrakoTech approaches these decisions
DrakoTech addresses several of these architectural challenges through its unified vehicle platform, combining centralized computing, software execution, vehicle connectivity, and workload isolation. Rather than adding middleware to existing operating systems, DrakoTech built DriveOS around its own separation kernel and real-time operating system, designed from first principles to run all vehicle functions on a single computer.
Its approach brings together four technologies: OneECU™ Architecture, DriveOS™, DigiHarness™, and HyperSafety™. Each addresses a different aspect of developing and managing software-defined vehicle systems.
OneECU Architecture
OneECU™ Architecture is DrakoTech's approach to consolidating vehicle functions onto a unified multicore computing platform. Rather than relying on separate ECUs for individual subsystems, the architecture is designed to support functions such as vehicle control, digital cockpit, and advanced driver assistance on shared computing hardware.
This approach aims to simplify software integration and reduce hardware fragmentation while maintaining isolation between workloads. By consolidating computing resources, DrakoTech seeks to provide manufacturers with a more unified foundation for developing, deploying, and managing vehicle functions.
DriveOS
Drako DriveOS™ is the software platform supporting the company's centralized vehicle architecture. It uses a separation-kernel-based approach to manage computing resources and isolate applications with different performance and safety requirements.
The platform is designed to support both time-critical control functions and general-purpose software environments on shared multicore hardware. Its architecture combines resource partitioning, controlled communication, and real-time execution to support mixed-criticality automotive workloads.
Research published in Towards an Integrated Vehicle Management System in DriveOS (2021) examined this approach using real-time services alongside Linux-based applications. The study provides technical background for the architecture, while current product capabilities should be evaluated against DrakoTech's latest specifications.
DigiHarness™
DigiHarness™ is DrakoTech's digital harness technology, designed to simplify communication and physical connectivity across vehicle systems. According to the company's platform architecture, it builds on a real-time USB-based communication approach to connect devices through a more unified network infrastructure.
The architecture is intended to support flexible device integration and reduce dependence on conventional fixed-pin wiring arrangements. By combining networking, device control, and power delivery within its proposed connectivity framework, DigiHarness™ aims to make vehicle integration and future modifications more manageable.
Actual improvements in wiring complexity, assembly requirements, and cost depend on the vehicle configuration and implementation.
HyperSafety™
HyperSafety™ is DrakoTech's approach to addressing safety-related requirements in a consolidated computing architecture. It combines predictable real-time execution, hardware-enforced workload isolation, and fault-recovery mechanisms to support the operation of applications with different criticality levels.
The technology is intended to help contain faults within individual subsystems and maintain the separation of safety-critical functions from other software workloads. DrakoTech describes the architecture as designed to support ASIL D requirements under ISO 26262.
This positioning does not, by itself, establish completed ASIL D certification. The applicable safety case, verification evidence, and certification status must be confirmed for the intended implementation.
How to evaluate a Software-Defined Vehicle Architecture
Evaluating an SDV architecture starts with defining the vehicle's technical requirements, operating conditions, and long-term development goals. Manufacturers should compare potential platforms against consistent criteria rather than relying solely on architectural features or supplier claims.
A reliable assessment requires technical documentation, system diagrams, performance benchmarks, and evidence of functional safety and cybersecurity processes. Testing should reflect realistic operating conditions, including system integration, workload interference, fault handling, and software updates.
Ultimately, the decision should consider not only technical capabilities but also implementation costs, integration effort, and lifecycle support. Clear acceptance criteria and representative testing help manufacturers select an architecture that meets their specific vehicle development requirements.
Discuss your SDV Architecture requirements
Developing a software-defined vehicle involves decisions that influence computing architecture, system integration, safety, and long-term flexibility.
DrakoTech's unified platform brings together centralized computing, real-time software execution, and vehicle connectivity within a single architectural approach.
Contact DrakoTech to discuss your vehicle architecture requirements and explore how its technologies could support your next development programme.
