The Future of Automotive Controls is Zonal

Background: Traditional Domain-Driven Vehicle Networks

As the automobile digitized in the 1990s the network of onboard computers that emerged were driven by domain; a hardware subsystem operated by a hardware-defined control module running a domain specific control application. For a rapidly evolving industry this design had significant benefits for agility, both technical and organizational. The hardware designers and control system engineers shared a domain, allowing for close collaboration and a common scope. Interactions with the rest of the vehicle were limited to network interfaces with no shared compute resources, specifically CANbus. Control software could be tracked and managed under an ECU part number. Organizational requirements drove system architecture more than technical merits.

This was a great system for the 1990s and early 2000s, a time before modern version control made software collaboration more seamless than hardware collaboration. Technologies like embedded Linux, virtualization, and hypervisors were nascent and uncommon in established industries. By separating the system along hardware boundaries the software development could fit into a hardware design model.

But this architecture also carries significant additional weight and cost that has grown exponentially with electrical complexity.

Wiring harnesses are repetitive overlays of the same wire runs with multiple central controllers telegraphing commands to actuators and sensors at all corners of the vehicle. Each individual controller is often underutilized and over-specced. The software on those controllers is rigid in function and often can’t be updated without a dealership replacing the hardware itself. As the market emphasizes high-technology cars with autonomous and connected features this has become a significant disadvantage in the flexibility of vehicle platforms and the agility of their development process.

The Rise of Zonal Architectures

Zonal architectures have been proposed for over a decade as an alternative to decentralized vehicle networks. A key principle of this approach is recognizing the inherent symmetry in vehicle design—left and right sides mirror each other, and there's often substantial similarity front to back. Leveraging this symmetry, zonal architectures divide the vehicle into physical zones, typically quadrants or front-and-back sections, each managed by a centralized controller that operates all co-located functions regardless of subsystem category.

For example, a zonal controller might actuate door locks, control lights, read suspension data and sensors, and operate driver assistance sensors like radars. These zonal super-controllers all communicate on modern high-speed and high-traffic buses. An even more centralized proposal is to commonize some functions on singular High Performance Computers (HPCs) and treat the entire car as one unified zone.

These centralized architectures offer significant cost savings by reducing wiring complexity, eliminating redundant controllers, and minimizing associated mounting hardware and peripherals. Each of these benefits triggers additional advantages in reduced engineering and development resources, manufacturing complexity, and servicing difficulty.

Historically, centralized vehicle computing faced significant hurdles due to real-time constraints, network latency, resource contention, and software isolation issues. However, software innovations over the last two decades have fundamentally reshaped this landscape. Real-time operating systems (RTOS), embedded Linux, virtualization, and hypervisors now enable multiple independent—and even safety-critical—applications to coexist securely on centralized hardware. Robust intra-process communication (IPC) frameworks have significantly reduced latency and improved reliability, ensuring predictable interactions among software modules.

Moreover, collaborative software development practices, facilitated by version control systems such as Git, sophisticated branching and merging strategies, and Continuous Integration/Continuous Deployment (CI/CD) workflows, allow distributed engineering teams to efficiently merge, test, and validate complex software stacks. Containerization technologies (e.g., Docker and Kubernetes) further enhance modularity and maintainability, streamlining deployment processes across centralized computing platforms.

Together, these software advancements have transformed zonal architectures from promising theoretical concepts into practical, highly advantageous solutions.

Though initially theoretical, zonal architectures have recently been validated by real-world implementations. Rivian’s transition from traditional architectures to a zonal approach in their revamped R1T and R1S models provided an excellent comparative example. By openly sharing their redesign process, Rivian highlighted tangible advantages such as reducing ECU count from 17 to just 7, eliminating approximately 1.6 miles of wiring, and shedding 44 pounds of vehicle mass.

To say that every OEM is looking towards zonal architectures would be an understatement; the vehicle platforms that aren’t zonal are simply outdated.

What do Zonal Architectures Mean for the Future of Controls?

How do you write control models that may run as an app in a zonal controller? For decades the development of automotive controls has been optimized for the deeply embedded controllers found in a distributed architecture. CANbus has remained dominant over any other network, the most advanced OS to be seen is an RTOS, and the integration between controls and hand code is difficult at best.

Zonal architectures preview a future where a hardware controller is as likely to be deployed as a virtual machine or container, an application, or a system process as it is to run as a low-level embedded application on a dedicated processor. A traditional controller might run on bare metal and communicate over CAN but in the future it may run as a process in Linux and communicate via pub/sub intraprocess communication. A Tier 1 supplier could be delivering their controls to OEMs as a Docker image or virtual machine instead of a microcontroller in a metal box.

How Pictorus Makes Controls Futureproof

To be future-proof, controls development needs an injection of generalizable technologies. Modern languages like Rust can be as low-level as embedded C but also expressive enough for app development.  Developing a single controls model that can be deployed across this wide range of environments will be critical for efficiency and agility. Network interfaces will need to extend beyond CAN or LIN and be compatible with SDV middleware protocols, intra-process communication, and inter-car networks - all while continuing to integrate into the controls model seamlessly. Additionally, tight integration into the version control and CI/CD systems required to assure collaboration and development of a zonal controller is an absolute must.

If this set of requirements seems to have significant overlap with Pictorus’ feature set, that’s no coincidence: this collaborative and agile future of hardware control is the inspiring force behind our tool. We chose web-based for broad collaboration, added custom code integration for flexibility, and built on the Rust programming language for safety and expressibility. A Pictorus model can go from embedded device deployment to running as a Linux process by changing a single setting.

When industries like automotive make tectonic shifts like zonal architectures, will your toolchain be able to follow?