When you speak with engineers who’ve lived through the evolution of in-vehicle software, you often hear the same theme: complexity crept in faster than anyone expected.
Deepak Kumar Sharma, Associate Technical Lead at Embitel, experienced that shift firsthand. Since he began working in automotive software development in 2017, he has moved across multiple layers of the stack—MCAL, BSW, and application development and watched the electrical and electronic (E/E) architecture of vehicles evolve around him.
Today, as the industry pushes toward software-defined vehicles (SDVs), zonal E/E architecture has gone from a promising concept to a practical path forward. Deepak sat down with us to discuss what drives this transition, the challenges it addresses, and how it refines development, safety, and cybersecurity practices.
Here’s how it went!
So, what exactly makes up a modern vehicle’s E/E architecture?
People sometimes forget how much of a vehicle’s behaviour now depends on electronics,†he says. Modern vehicles are built on a network of ECUs, sensors, and actuators, all stitched together through CAN, LIN, FlexRay, Ethernet, and other protocols.
“All of that together forms the E/E architecture,†he explains. “It’s the nervous system of the vehicle. It has evolved from distributed systems to domain-based designs and now has shifted to toward centralized and zonal approach.â€
What triggered the shift from Domain to Centralized & Zonal E/E Architecture? “As features grow more connected and data-dependent, previous architectures began to show their limits†he says. “Bandwidth became a concern, wiring became excessive and performance demands, especially for autonomous functions, pushed CAN networks to their limits.†Deepak recalled that the demands of integrating smart & digital features opened the door for more scalable and next-gen approaches such as the zonal architecture. What sets the zonal E/E architecture apart from earlier architectures? “Zonal E/E architecture is a mindset shift. To break it down, let’s divide the car into its physical zones: front left, front right, rear left, rear right, and cabin. Each is managed by a zonal controller that aggregates local sensors and actuators and communicates with a central computing unit†he claims. Deepak highlighted that zonal controllers are not rigidly tied to any single function, they allow OEMs to introduce new features or applications seamlessly, during their development and throughout their lifecycle. Additionally, he revealed that zonal architectures replace CAN with automotive Ethernet, offering higher bandwidth for data-intensive applications. How is it changing the way automotive software itself is developed? One of the most striking changes Deepak highlights is how zonal E/E architecture reshapes automotive software development itself. “Instead of every ECU running its own dedicated software, zonal systems separate the hardware from the software. This means developers can build and update applications more like they do in the cloud, using DevOps methodologies such as continuous integration and deployment (CI/CD) to roll out updates faster. They also support containerization, which basically means you can run multiple applications on the same computer without them interfering with each other. It’s flexible, easier to maintain, and the same app can run on different platforms with very little change. And then there are virtual ECUs, software versions of real ECUs. They let engineers test and try out new functions before the actual hardware is ready. So, overall, zonal E/E architecture helps automakers move toward a more agile, cloud-like way of developing and deploying vehicle software. But as vehicles adopt more cloud-like development approaches, what new challenges does this create for cybersecurity and software validation? “That’s a good point! Connectivity introduces risk, and zonal architecture does not eliminate cybersecurity challenges; instead, it centralizes and controls how data flows between vehicle components.†Deepak highlighted. According to him, by introducing zonal controllers and centralized computing units, OEMs gain clearer control over how data moves across the vehicle. These components act as controlled gateways, regulating communication between sensors, actuators, and higher-level software layers. This makes it easier to monitor traffic, enforce access rules, and prevent unauthorized interactions between different parts of the system. “Testing strategies evolve alongside this architectural shift. OEMs are increasingly adopting software-based validation approaches such as digital twins, which replicate the vehicle’s E/E architecture in virtual environments. These models allow teams to simulate system behavior, integration scenarios, and potential attack vectors before deployment.†This, combined with AI-driven testing, helps in speeding up development, cutting testing costs, and addressing weaknesses proactively. Beyond cybersecurity, how does zonal E/E architecture enable secure and reliable over-the-air (OTA) software updates? “From the OTA perspective let’s understand that ECUs must continue to perform their safety-critical functions even if an update fails.†he says. When the stakes are this high, Deepak claimed that OEMs take special care in integrating the following mechanisms into their OTA module in the zonal architecture: 1. Rollback Mechanism → Ensures vehicle functions remain operational even if an update fails. 2. Encryption, Authentication, and Certificates → Protects update packages from tampering and guarantees data integrity. 3. Secure Boot & Code Signing → Validates the authenticity and integrity of firmware before execution. 4. Delta Updates → Sends only the modified portions of software, reducing bandwidth and update time. 5. Parallel Update Distribution → Zonal ECUs distribute updates locally to connected ECUs, enabling faster and more efficient deployment. But as connectivity increases, how do zonal architectures guarantee the real-time performance required for safety-critical vehicle functions? Safety-critical systems like braking and steering demand predictable, real-time performance. “Zonal ECUs help by having direct access to local sensors and actuators,†Deepak explains. This reduces response times and helps meet ISO 26262 safety standard for SDVs. However, Ethernet alone may not provide the ultra-low latency needed for all functions. Deepak describes how OEMs approach this: 1. For highly latency-sensitive functions, certain ECUs may continue to rely on legacy CAN networks to guarantee timely data delivery. 2. Zonal ECUs can execute safety-critical actions locally by directly interfacing with inputs/outputs (e.g., braking systems), thereby reducing dependency on the central network and avoiding delays. 3. Safety signals can be transmitted redundantly across both Ethernet and CAN to ensure maximum reliability and availability. “It’s about selecting the right communication strategy for each function,†he says. Looking beyond zonal design, where are E/E architectures headed next? If you look at where things are headed, a clear pattern is already emerging.†he said. Automakers are continuing to consolidate multiple ECUs into “fewer and smarter hardware unitsâ€, with powerful zonal controllers taking on more responsibility across the vehicle. “The next step in this evolution is central compute, where a single high-performance processor connects to smaller satellite nodes distributed across the vehicle. To make this possible, OEMs are adopting 10BASE-T1 Ethernet, which provides faster and more reliable communication than traditional Ethernet while reducing gateway latency. “Deepak said. Some manufacturers are also exploring IoT cloud integration to handle non-critical functions such as in-vehicle infotainment, analytics, and fleet management, while keeping safety-critical controls within the vehicle. In the near future, centralized computing with satellite nodes is expected to become the next practical step beyond zonal architecture, paving the way for truly software-defined vehicles.
