Arm Reveals Zena Automotive Compute Subsystem

Last year Arm announced their support for standards-based virtual prototyping in automotive, along with a portfolio of new AE (automotive enhanced) cores. They also suggested that in 2025 they would be following Arm directions in other LOBs by offering integrated compute subsystems (CSS). Now they have delivered: their Zena CSS subsystems for automotive applications round out their automotive strategy.

The Motivation

What is the point of a CSS and why is it important for automotive? In part the motivation is the same as for CSS applications in infrastructure. The customers for these subsystems see them as necessary but not core to their brand. Complete and pre-validated subsystem IPs like Zena are an obvious win, reducing effort and time to deployment without compromising opportunities for differentiation. Automotive OEMs, Tier1s, even leading automotive semi suppliers in some instances, aren’t going to differentiate in compute subsystems. Their brand builds around AI features, sensing, IVI, control, and communication (V2X and in the car). Zena provides a jump start in designing their systems.

Arm is a good company to watch in this area because electronic/AI content is now a huge part of how automotive brands are defined, and Arm completely dominates in processor usage among automakers and automotive chip suppliers. As a result, Arm sees further ahead than most when it comes to trends in automotive electronics. For example we’re already familiar with the concept of a software defined vehicle (SDV), supporting over the air (OTA) updates for maintenance and feature enhancements, orchestrating sensing and control between multiple functions across the car, and emerging potential in V2X communication. Dipti Vachani (Senior VP and GM for Automotive at Arm) says that looking forward she sees the next step being a trend towards AI-defined vehicles. This concept is worth peeling further.

A cynic might assume “AI-defined vehicles” is just buzzword inflation, but there’s more to it than that. First AI has become central to innovation in the modern car – how automakers differentiate and defend their brands, even how they monetize what they provide. Dipti suggests a range of emerging possibilities: in ADAS, adjusting to driver behavior and environment in real-time to better support safety; in IVI to provide support for more personalized voice-enabled control, an important step beyond the limited voice options available today; and for vehicle control to optimize energy consumption and vehicle dynamics based on load and road conditions. I have written separately about advances like birds-eye-view with depth for finer control in autonomy when cornering, for driver and occupant monitoring systems, and for more intelligent battery management.

OK, so lots of AI capabilities in the car, but what does this have to do with Arm, especially if OEMs and Tier1s are differentiating in AI, etc? We already know that to manage the cost side of all this innovation OEMs have moved to zonal architectures, a small number of hardware components around the car rather than components everywhere. Differentiating AI models can be updated OTA as needed, important because AI innovation is fast and furious – what is competitive this year may look dated next year. Models must operate reliably and be updated safely and securely, with regular in-flight checking and corrective action for hardware misbehavior and robust protection against hacking in-flight or during updates. All critical requirements in a car, but this management is beyond the bounds of AI.

Compute subsystems and SDV in the age of AI-defined vehicles

From what I see, safety and security are out of scope today for AI. Research in safety in AI is nascent at best. AI for car-quality security is a bit more advanced, primarily for attack detection and not yet production level. More obviously, orchestration of functions across the car, the communication through which that orchestration must operate, actuation for mechanical functions, display functions and many other non-AI functions, all these are beyond the scope of AI. Such functions, still the great majority of administrative compute in a car, must continue to be handled through software running on a backbone of zonal processors, each managed by one or more standard CPU subsystems (here Zena) front ending the AI engines. In this context, given the cloud-based virtual software development Arm highlighted last year natively modeling Zena in that development, Arm’s role becomes more obvious.

Zena role in zonal processors

Further, there are likely to be many more AI models to support in any given car than there are zonal processors. Running multiple AI models on an NPU is already possible since multi-core NPUs are now common. But which models should run when must be governed by orchestration under an OS running on a CPU subsystem. This orchestration also handles feeding data into the NPU, taking results back out to the larger system, swapping models in and out, and managing updates from the cloud. Together of course with comprehensive safety and security control for the complete automotive electronic system.

Safety in advanced automotive electronics has already evolved to ASIL-B or ASIL-D levels implemented through ASIL-D certified safety islands which regularly monitor other functions in the processor through function isolation, self-test, reboot if necessary, before bringing that function back online. Or perhaps shutting down a broken subsystem and triggering a driver/dealer warning to be addressed in a service call. Security is even more rigorous: secure boot, state of the art encryption, secure enclaves, authentication for downloads, etc. etc.

In short, complete automotive systems depend on CPU subsystem front-ends to the NPU back-end which run the AI models. A standard to ensure interoperability is essential to making this complex environment work well, as is a trusted virtual platform/digital twin to support software development in advance of a car being ready for testing. This is why Arm kicked off the SOAFEE standard four years ago. Dipti says that Zena is the physical manifestation of SOAFEE and claims that between software virtual prototyping and time and effort saved by having a fully characterized compute subsystem in Zena, automotive systems builders can save up to a whole model year in time and 20% in engineering effort over building their own compute subsystem.

For developers, virtual prototyping platforms are already available from major EDA suppliers. Zena is currently in deployment with early adopters and is expected to become more generally available later in 2025.

Takeaway

I see Zena and the larger strategy continuing a theme that has been quite successful for Arm in their Neoverse/infrastructure directions – pre-verified/validated compute subsystems as an IP, backed by cloud-native development based on open standards.  The ecosystem will continue to grow around these standards, competitors are free to enter but will be expected to comply with the same standards, while Arm must continue to execute to stay ahead. Nothing wrong with that for automotive OEMs and Tier1s, though clearly Arm has a strong head start.

You can read more HERE.