Produced by Zhineng Technology

The concept of software-defined vehicles, which allows for continuous iteration through software after a vehicle is delivered, has been around for many years.

AI-defined vehicles take this a step further: faced with constantly changing human, road, and vehicle conditions, the vehicle understands what is happening and independently chooses how to act.

Software-defined vehicles have driven the centralization of ECUs, central computing, SOA, and OTA. AI-defined vehicles further require immense real-time data throughput, heterogeneous computing capabilities, memory bandwidth, and a comprehensive safety verification and lifecycle management system centered around models.

The real transformation occurring in today's automotive industry is the shift from a machine operating under pre-written rules by engineers to a physical intelligent system capable of perceiving its environment, establishing understanding, reasoning, taking action, and continuously updating its capabilities.

1) "Software-Defined" and "AI-Defined" in the Automotive Industry

AI's integration into automobiles is not new.

A decade ago, neural networks were widely adopted for camera-based recognition of vehicles, pedestrians, and traffic signs. Today's automatic emergency braking, driver monitoring, voice recognition, parking, and assisted driving rely heavily on machine learning.

If "using AI" equates to "AI-defined vehicles," then the automotive industry would have already completed this transition, which is clearly not the case. Semiconductor Engineering's article, "AI-Defined Vehicles Push Compute, Memory, And Validation Limits," highlights how, as more AI is integrated into vehicles, automakers face challenges extending to chips, memory, SerDes, Ethernet, power, thermal management, validation, and even vehicle lifespan.

Why does an algorithmic issue involve the entire vehicle's electronic and electrical architecture?

This is because AI's role has changed.

Increasingly, AI directly processes camera, radar, vehicle status, and user information to build environmental models and determine the next steps. AI is transitioning from a mere "recognition tool" into the vehicle's decision-making chain. Once this happens, the vehicle must be redesigned.

1) What Has Software-Defined Vehicles Accomplished?

To understand AI-defined vehicles, we must first understand what software-defined vehicles have achieved.

Traditional vehicles are typical feature phones. Each function—windows, seats, engine, ABS, instrument (instrument panel), air conditioning, lights, body, and entertainment systems—has its own ECU and software. Each added function often means an additional controller, wiring harness, and software. High-end vehicles once had hundreds of ECUs. The defining characteristic of such vehicles is the tight coupling of functions with hardware. Once built, a vehicle's capabilities are largely fixed.

Software-defined vehicles liberate these functions from dedicated hardware. Dozens of ECUs are consolidated into domain controllers, further evolving towards central computing plus zone controllers. The underlying hardware forms a relatively general-purpose computing platform, with more functions realized through software.

NXP's latest S32N7 attempts to safely isolate and integrate up to eight traditional vehicle domains—including powertrain, body, vehicle dynamics, gateway, and vehicle data—within a single central processing platform while retaining real-time computing, application computing, networking, security, and AI acceleration capabilities. For the first time, vehicles exhibit characteristics similar to smartphones and servers. The hardware platform is established first, with functions added later. This is why OTA has become such a crucial part of SDV. Vehicle delivery represents only hardware delivery; software can continue to be upgraded.

2) The Divide of AI-Defined Vehicles

Here, a true divide emerges.

Traditional software is characterized by engineers pre-defining how a vehicle should operate. For example, the fan turns on when the temperature exceeds a certain level, a function is disabled when the speed surpasses a threshold, and braking is applied when an obstacle is detected below a certain distance. Much of automotive software can be expressed as "if A, then B." Engineers generally know the inputs, judgment conditions, and outputs.

The change brought by AI is that many problems can no longer be resolved by engineers enumerating rules. An intersection may simultaneously contain vehicles, pedestrians, electric bikes, construction zones, traffic lights, temporary barriers, and traffic police gestures. Engineers cannot pre-write all possible combinations into code.

Vehicles thus adopt another approach: models learn from vast amounts of data to understand the surrounding world before deciding how to act. Internally, the vehicle processes: sensors, environmental understanding, state judgment, behavioral decision-making, and control execution. AI is increasingly closer to the core decision-making processes.

A more rigorous definition of "AI-defined vehicles" can be given: the core experience and some critical behaviors of the vehicle are increasingly dynamically generated by AI models based on real-time data, while the vehicle's computing architecture, data architecture, and development and verification systems are built around the operation, upgrading, and safety management of these models.

This definition contains three key terms: real-time data, model-based decision-making, and continuous evolution. Simply integrating a large language model into the cabin does not constitute a true AI-defined vehicle; it is merely an AI feature.

3) Data Flow is Transforming Vehicles

When discussing AI vehicles, many first think of computing power—500 TOPS, 1000 TOPS, 2000 TOPS—and how data reaches this computing power. Assume a smart vehicle has ten 8-megapixel cameras, each capturing 30 frames per second, with each pixel calculated as 12 bits of raw information:

8 million × 30 × 12 × 10 approaches 28.8 Gbps of raw data.

This does not include millimeter-wave radar, LiDAR, ultrasonic sensors, positioning information, or the various feature data generated in between. Real vehicles compress, crop, and perform ISP processing to reduce data volume. The first pressure smart vehicles often face is not computing power but data movement.

Data from cameras must pass through SerDes into zone controllers or switches, travel through the vehicle's high-speed network, enter the central computing platform, be written into DRAM, and then be repeatedly read by GPUs, NPUs, or other AI accelerators before the model results are sent to the vehicle's control system. If any link in this chain lags, even the highest TOPS cannot be fully utilized. Moving sensor data is becoming as important as processing it, which is why automotive SerDes is rapidly upgrading. MIPI A-PHY v2.0 has expanded single-link downstream capacity to 32 Gbps while retaining a relatively low-speed reverse control link. It targets typical "asymmetric data" from cameras, radars, and LiDAR: sensors send large amounts of data to central computing, which only needs to send minimal configuration and control information back to the sensors.

In the past, automotive electronic control signals—such as turning a light on or off—were just a few bytes of information.

2) New Architectures for AI Vehicles

After data enters the central computing chip, it encounters a second bottleneck: memory.

Many are accustomed to evaluating autonomous driving chips by TOPS. However, AI computing often involves more than just arithmetic. Models must first place weights, image features, BEV features, historical frames, map information, and various intermediate results into memory, with computing units continuously reading, computing, writing back, and re-reading.

This process becomes increasingly pronounced for Transformers, world models, and multimodal models. The true determinants of AI platform performance are now a set of metrics: computing power, memory capacity, memory bandwidth, data access latency, interconnect bandwidth, and power consumption. GPUs are getting faster, and HBM is becoming more critical. Automobiles are following a similar path but with stricter constraints.

A GPU in a data center can consume hundreds or even over a kilowatt of power. Automobiles obviously cannot afford this. The electricity consumed by chips ultimately turns into heat, which must be dissipated. Heat dissipation adds weight, cost, and energy consumption, affecting the range of electric vehicles. Therefore, evaluating an automotive AI chip based solely on TOPS will become increasingly one-sided in the future. A more critical question is: how much energy is consumed to complete a real driving task?

1) Future Automotive Architectures

Two voices emerge regarding future architectures. One advocates for a "server-on-wheels" approach, maximizing computing power and cramming all functions into a central superchip. The other supports a "right-sized" distributed approach, placing specialized computing closer to actuators. Experts cited by Semiconductor Engineering say both paths have merit, and it is too early to conclude.

I believe a layered computing structure is more likely to emerge.

At the top is high-performance central AI computing, responsible for perception, fusion, world modeling, planning, cabin AI, and complex applications. In the middle are zone controllers, handling data aggregation, power management, network communication, and regional device control. At the bottom, a large number of MCUs and real-time controllers remain. Systems like motor control, braking, steering, airbags, and doors require far higher levels of determinism and real-time performance than large models.

AI can afford to spend tens of milliseconds contemplating a complex road situation. Brake control cannot suddenly say, "I'll reason a bit slower this frame." This is why today's central computing chips emphasize mixed criticality computing.

Qualcomm's Snapdragon Ride Flex allows cabin, ADAS, and autonomous driving workloads to run on the same SoC while using hardware isolation, virtualization, and an independent ASIL-D Safety Island to separate tasks of different safety levels. NVIDIA's DRIVE Thor goes further, aiming to integrate assisted driving, autonomous driving, parking, instrumentation, and entertainment into a central computing architecture. Meanwhile, companies like NXP continue to strengthen real-time processors, safety islands, CAN, Ethernet, and zone control.

Thus, the future vehicle will likely resemble a central AI brain, a high-speed data backbone, regional neural nodes, and numerous real-time execution units—more akin to a biological organism. The brain handles complex judgments, the spinal cord manages rapid reflexes, and peripheral nerves deliver signals to the limbs. Automobiles will not send every action to the brain for computation just because they have a super central processor.

Traditional code is relatively easy to trace. Engineers can examine the inputs, which code was executed, and why a particular output was generated. AI models, especially large neural networks, are difficult to explain with the same level of determinism. Their behavior arises from the interplay of training data, model structure, parameters, and current inputs.

Do traditional hardware and software fail? This is primarily addressed by ISO 26262, covering random hardware faults and functional safety issues in system and software development. The system may not fail but may lack sufficient capability—for example, a camera failing to correctly identify an object under special lighting. This issue falls under SOTIF, or ISO 21448, which focuses on "safety of the intended functionality": dangers arising from inherent inadequacies in functional realization.

AI itself can produce unreliable judgments. ISO/PAS 8800, released at the end of 2024, specifically addresses automotive AI safety. It focuses on vehicle safety risks arising from AI element outputs, systemic errors, or hardware faults. The future will increasingly involve asking, "What evidence do we have to prove that this model is sufficiently reliable within its permitted operating range?"

2) AI Redefines Automaker Capabilities and the Industrial Chain

In the era of software-defined vehicles, OTA is straightforward: adding new functions, fixing bugs, and updating maps.

In the AI era, OTA will become deeper: updating models, adjusting perception capabilities, changing prediction abilities, optimizing driving strategies, upgrading cabin agents, and even altering how the vehicle understands users and the environment. Each upgrade represents a change in vehicle behavior.

Future automotive companies will likely need to manage models as they do components: which vehicle, which hardware version, which sensor combination, which model is running, when it was upgraded, and what happened after the upgrade—all traceable.

AI-defined vehicles add further layers: data systems, AI models, training platforms, simulation platforms, computing infrastructure, model verification, in-vehicle inference, and continuous learning.

Automobile companies simultaneously manage two very different worlds. One is the manufacturing world, demanding a decade-long lifespan, consistency across millions of units, and extremely low failure rates. The other is the AI world, where models, data, and capabilities are constantly changing and rapidly iterating.

The automotive supply chain is tiered. Chip companies sell chips to Tier 1 suppliers, who build ECUs, which OEMs integrate into vehicles. OEMs increasingly want to understand the underlying chips directly. Without knowledge of memory bandwidth, NPU architecture, and data interfaces, optimizing their models becomes difficult.

Thus, chip companies are moving toward systems, automakers toward chips, algorithm companies toward computing platforms, and traditional Tier 1 suppliers must redefine their positions. The industrial changes brought by AI-defined vehicles will penetrate deeper into the electronics supply chain than electrification.

Summary:

Looking back at the past fifteen years of change in the automotive industry, the path is clear. Electric vehicles transformed energy systems, software-defined vehicles changed functional development approaches, and AI-defined vehicles are now altering vehicle decision-making. This marks the third and deepest transformation.

In the era of software-defined vehicles, engineers asked: What additional functions can this vehicle support in the future?

In the era of AI-defined vehicles, an additional question arises: Faced with a world that never fully repeats, what should this vehicle do?