To enable autonomous vehicles to drive safely, they rely on the support of perception hardware such as LiDAR, cameras, and millimeter-wave radar. Equally important is the decision-making system, which analyzes perceived environmental factors and makes reasonable driving behavior decisions. Some may wonder: For autonomous vehicles, is software more important, or is hardware?

By analogy, an autonomous driving system is like a band performance. Hardware represents different instruments, while software is the sheet music and conductor. Without good instruments, the sound is limited; without a good conductor and score, even the best instruments produce noise. Therefore, the key question is not 'which is more important,' but whether the two can harmonize and work together in an engineered, verifiable, and economically sustainable manner. This determines whether the system can be safe, reliable, and deployable.

Hardware determines the system's perception limits and safety boundaries. How far you can see, how small a target you can distinguish, and whether you can obtain reliable echoes in poor weather conditions are all determined by cameras, radar, LiDAR, inertial measurement units (IMUs), high-precision positioning modules, in-vehicle networks, and computing platforms. The physical characteristics of hardware directly affect the difficulty of the problems software needs to solve. For example, camera noise in low-light conditions forces perception models to handle noise and false positives more complexly. The resolution and line count of LiDAR affect the granularity of target segmentation.

Software, on the other hand, is the key to transforming hardware capabilities into practical functions. Perception algorithms, sensor fusion, localization, prediction and planning, and control modules convert raw signals into vehicle behavior. Software determines how to extract semantics from noise, how to make real-time decisions with limited computing power, and how to ensure safety in degraded modes through redundancy and online monitoring. More importantly, software enables vehicle upgrades, iterations, and scalability. Through OTA (Over-The-Air) updates, models can be continuously improved and vulnerabilities fixed. In contrast, hardware is difficult to change once installed in a vehicle unless designed for modularity or hardware pre-embedding.

Therefore, the two are interdependent. Hardware sets the 'physical boundaries' of the problem, while software makes engineering trade-offs and optimizations within those boundaries. Focusing on a single dimension (hardware being more important or software being more important) leads to incorrect design decisions. The right question is: How can resources be reasonably allocated between hardware and software under constraints such as target functionality, budget, mass production capabilities, and regulatory requirements to find the optimal balance? This ensures the system meets safety requirements while being commercially viable and sustainably evolvable.

How to Balance Hardware and Software: From Requirements to Implementation

So, how can we balance hardware and software choices in autonomous driving? Let's start with requirements. Any good trade-off must return to the question of 'what are you trying to achieve?' Are you building a low-speed, closed-campus shuttle, or are you aiming for high-speed L4 autonomy on urban roads? Different goals impose vastly different requirements on hardware and software. Low-speed scenarios benefit from lower-cost sensor combinations and relatively simple decision-making logic, while complex traffic scenarios may demand stronger long-range detection, higher positioning accuracy, and more sophisticated prediction and planning algorithms.

Cost and manufacturability are practical factors that must be considered. In mass-produced vehicles, cost pressures can suppress expensive perception hardware (e.g., high-line-count LiDAR) to an unacceptable level. In such cases, software must bear more perception responsibility, extracting highly reliable results from inexpensive cameras and millimeter-wave radar through stronger algorithms and sensor fusion. Conversely, in experimental vehicles or high-end markets, manufacturers may choose better hardware to reduce software complexity, shorten development time, and improve safety margins.

Reliability and redundancy design also influence the trade-off between hardware and software. In safety-critical systems, redundancy is crucial. Hardware redundancy (e.g., dual cameras, dual LiDAR systems, or independent millimeter-wave radar) provides diverse physical observations, facilitating fault detection and degradation. Software redundancy (e.g., multi-model parallel inference, hybrid architectures combining rules and learning) offers hedging strategies in edge cases. Ideal systems typically retain the minimum necessary hardware redundancy (due to cost, energy consumption, and space constraints) while implementing flexible multi-modal fusion and self-checking logic in software.

Another key consideration is computing power and energy consumption. High-performance SoCs (System-on-Chips) support more complex networks, higher frame-rate processing, and lower perception latency but often come with high power consumption, thermal management challenges, and cost. If you deploy high-computing-power hardware in a vehicle, software can simplify some inference optimizations and reduce model compression efforts. However, this inevitably requires addressing thermal management, power supply design, and cost issues. Conversely, if computing power is limited, more design burden falls on algorithm engineers, making model quantization, distillation, lightweight network design, and temporal scheduling critical. The balance here is often 'appropriate computing power + efficient software,' rather than simply pursuing maximum computing power or the most complex software.

Time cost is another factor that must be considered. Better hardware often accelerates early validation. High-line-count LiDAR combined with strong computing power can reduce algorithmic challenges in the prototype stage and speed up iteration. However, migrating algorithms to mass-production-constrained hardware later may require additional engineering resources. Many startups and automakers adopt a 'hardware flywheel' strategy, using better and more expensive perception hardware in early prototype stages for rapid functional verification and data collection, then gradually optimizing software to adapt to relatively inexpensive mass-production hardware. This strategy reduces R&D risk in the short term but requires long-term engineering investment to complete the transition from prototype to mass production.

Regulations and verification costs also influence the trade-off between software and hardware. Certain safety standards or regulatory requirements may mandate specific hardware redundancies or functional safety mechanisms (e.g., ASIL levels, failure mode detection), driving more investment in hardware. Software verification and certification costs are extremely high, as complex machine learning components are difficult to formally prove reliable in all scenarios. Therefore, on critical paths, more explainable and verifiable modules (e.g., rule-based decision logic, localization methods combining traditional filters and models) are often chosen, with machine learning reserved for auxiliary or performance-enhancing roles until sufficient data and methods exist to prove its safety.

Practical Selection Strategies and Recommendations

What should be considered when balancing hardware and software? Intelligent Driving Frontier recommends treating hardware and software selection as a phased evolutionary process rather than a one-time decision. The first step is to clarify product positioning and key scenarios. If the goal is highly autonomous driving on urban open roads, you must prioritize perception range, positioning accuracy, and redundancy. For low-speed campus or fixed-route autonomy, software can be emphasized to compensate for hardware shortcomings and save costs.

Next, create a 'capability matrix' that clearly lists the capabilities and limitations of each sensor and computing unit (e.g., cameras provide high-resolution semantic information but are sensitive to lighting; millimeter-wave radar can detect speed and distance in rain, snow, and fog but has low resolution; LiDAR provides precise 3D point clouds but is vulnerable to harsh weather and mirror reflections; high-precision GNSS+RTK offers centimeter-level positioning but depends on base station coverage and antenna installation conditions; high-performance SoCs support complex networks but are costly and power-hungry). Overlaying scenario weights (urban, suburban, highway, nighttime, etc.) on this matrix yields a clearer hardware priority and software requirements.

At the perception level, a 'multi-modal first, fusion-driven' design philosophy is recommended. Single sensors have blind spots, and multi-sensor fusion improves robustness and explainability. Software should not simply concatenate data from multiple sensors but design fusion logic that leverages each sensor's strengths and compensates for weaknesses, along with fault detection and degradation modes. For example, if a camera fails, the system should rely on millimeter-wave radar and low-resolution LiDAR to maintain basic lateral control and collision prevention rather than entering a dangerous state.

The choice of computing platform should balance current and future system development needs. Many technical solutions adopt a hierarchical computing architecture, using onboard edge computing for real-time perception and control and the cloud for large-scale learning, map updates, and offline verification. Onboard hardware must ensure low latency and functional safety. When selecting commercial SoCs, prioritize those with mature ecosystems and safety features (e.g., hardware isolation, secure boot, automotive-grade certification paths) to reduce software burdens in trusted execution and tamper resistance. Additionally, hardware interface designs should reserve scalability for future hardware upgrades or functional expansions.

For software architecture, a hybrid strategy is recommended. Implement deterministic and easily verifiable functions using traditional algorithms or rules first (e.g., basic control, emergency braking logic, sensor health monitoring), while delegating complex perception and prediction tasks to machine learning solutions. However, machine learning outputs should be reinforced through redundancy, thresholds, conservative strategies, and extensive simulation verification. For machine learning models, clear deployment/rollback mechanisms, performance regression testing, and online monitoring (e.g., data drift detection, abnormal sample reporting) should be in place to ensure OTA updates do not introduce uncontrollable risks.

Testing and verification strategies are also critical. Hardware choices affect the amount of testing required. More complex or high-risk hardware schemes necessitate additional fault injection testing, environmental tolerance testing, and functional safety verification. Therefore, verification costs (including HIL, SIL, scenario-based simulation, closed-loop testing, and large-scale road testing) should be factored into decision-making. Technically, an end-to-end data loop should be established, using data collected from vehicles for simulation scenario construction and model training while efficiently feeding online faults and edge cases back into the development process to shorten the time from problem detection to fix deployment.

Team and organizational structure also influence the hardware/software balance. Hardware-oriented teams (led by hardware engineers) tend to prioritize robust but expensive hardware, while software-oriented teams lean toward cost reduction through algorithmic compression. The ideal approach is cross-disciplinary teamwork, with joint decision-making from requirement definition and system architecture to mass production engineering, ensuring risks and costs from both sides are comprehensively considered. Additionally, decision-making should be transparent, with a clear breakdown of the total cost of ownership (TCO) for hardware and software, including not just per-unit costs but also maintenance, upgrades, energy consumption, and verification costs.

Finally, supply chain and maintainability should be considered. Hardware procurement is affected by component availability and lifecycle. Certain high-end sensors may have limited supply or short lifespans, posing mass production risks. Software has high long-term maintenance costs but offers flexibility. A wise choice is to prioritize hardware with mature automotive-grade support and long-term supply commitments while adopting a modular system design that allows single hardware replacements without requiring major software stack changes.

Shifting from 'Which Is More Important' to 'How They Collaborate' Is Key

Returning to the original question: Is software or hardware more important for autonomous driving? The answer is that both are important, but in different ways. Hardware defines what can be done, when, and how well; software determines how to combine these capabilities to meet safety, efficiency, and user experience goals. When designing autonomous driving systems, the key lies in finding the right balance among functionality, cost, risk, and time to ensure the system can operate safely, be commercially viable, and evolve sustainably. When choosing hardware, ask, 'What can software still achieve within this hardware budget?' When selecting software, ask, 'Can this software be proven safe given the current hardware capabilities and verification constraints?'

-- END --