The Vulnerability-Adaptive Protection Paradigm

Resilience.  A metric to quantify resilience is important in our design space as we strive to build a robust autonomous machine. We use the error propagation rate (EPR) as the resilience metric for autonomous vehicles.⁹ EPR indicates the percentage of the final output of the autonomous vehicle (AV) software that is influenced when an error occurs at an earlier kernel. We obtain this metric by comparing the ground truth with the output after error injection. The lower the EPR, the better the resilience.

Latency.  To guarantee resiliency, we trade off other metrics in the design space, where compute latency is the most important among them. The end-to-end compute latency, which is the time between when a new event is sensed from the surroundings and when the vehicle takes action, can impact whether an autonomous machine can stop or decelerate to avoid objects safely.

The extra computation brought by the protection scheme will increase end-to-end compute latency and further negatively impact the safe object avoidance distance. Figure 2(a) illustrates the relationship between compute latency and object avoidance distance deriving from our concrete vehicle data analysis.³⁷ The baseline vehicle operates at a typical speed of 5.6$m/s$ with 4$m/s^2$ brake deceleration, and is equipped with powerful CPU and GPU for computationally intensive autonomy algorithms. The vehicle has an average computing latency of 164$ms$, meaning the vehicle could avoid objects that are 5$m$ away or farther once detected. This latency model illustrates how much compute latency matters in the end-to-end autonomous vehicle system, providing budget guidance for fault-protection-scheme overhead and impact analysis.

Energy.  Energy consumption closely correlates with automotive endurance. With the trend toward electrification, the majority of vehicles in the future will be powered by batteries.

The extra energy consumed by autonomous-driving computing systems will reduce vehicle operating time and translate to revenue loss for commercial vehicles. Figure 2(b) demonstrates the relationship between the power of the autonomous driving system and reduced driving time.³⁷ The vehicle is powered by batteries that have a total energy budget of 6$kW$·$h$. The vehicle itself consumes 0.6$kW$ on average, and enabling autonomous driving consumes an additional 0.175$kW$, allowing for 7.7h of driving time under a single battery charge. The extra energy consumption from the protection scheme will further reduce operating time. This energy model allows us to understand how extra energy consumption brought by the protection scheme would impact the driving time and daily revenue of the vehicle.

Cost.  Cost overhead is important to almost every vendor. We analyze extra chip area and silicon cost for autonomous vehicles and drone systems brought by various fault-protection schemes.

Anomaly detection.  Anomaly detection is generally used to identify rare observations which significantly deviate from the majority of data. In autonomous scenarios with a large number of abnormal behaviors, anomaly detection may incur high latency overhead due to the node re-execution and cannot fully mitigate fault impact due to false-positive detection in corner cases.^9,32

Temporal redundancy.  Temporal redundancy refers to executing the code more than once with the same piece of hardware. The redundant executions can help alleviate the threat of silent data corruption caused by soft errors as they are transient. The temporal data diversity and redundancy in the sensor data can also be exploited in detecting hardware faults.^15,16 Temporal redundancy typically incurs large compute latency and energy overhead due to the redundant sequential executions and may not be able to detect all faults due to the continued existence of few hardware defects.

We then analyze two hardware-based fault-protection schemes: modular redundancy and checkpointing. Hardware-based protection schemes typically offer effective error mitigation but incur significant power overheads and additional costs.

Modular redundancy.  Modular redundancy (that is, spatial redundancy) refers to executing the same node on two or more hardware platforms. For instance, Tesla’s Full Self-Driving chip duplicates the entire processing logic, with one copy serving as a backup in case the other encounters unrecoverable errors. Similarly, NVIDIA Orin chips for self-driving applications enable full system duplication and lock-step execution.^1,6 Other established methods include triple modular redundancy, which involves three identical hardware instances with voting logic at the output. If an error affects one hardware instance, the voting logic records the majority output and masks the malfunctioning hardware. Modular redundancy is typically effective in fault detection with negligible impact on latency, though it incurs considerable energy and silicon costs.

Checkpointing.  Checkpointing refers to periodically storing a fault-free copy of the processor state so that computation can continue from that point without altering the autonomous machine’s behavior.⁴ A rollback consists of a recovery mechanism that restores the processor to a previous safe state in case the autonomous machine crashes due to a failure in the underlying system. The conventional checkpointing method usually accompanies dual modular redundancy and brings large runtime overhead due to the store-and-retrieve procedure that may violate the real-time nature of autonomous machines. Checkpointing can also implemented in a software manner¹⁷ that trades off between efficiency and overhead. Including hardware support in saving checkpoints and re-executing can increase efficiency significantly. Since autonomous machines continuously interact with their environments and have strict real-time and efficiency requirements, we particularly refer to hardware checkpointing in the protection landscape.

Conventional “one-size-fits-all” hardware or software-based protection techniques are limited by the fundamental trade-off between performance overhead and resilience improvement in the design space of autonomous machines. Recently, automotive safety integrity level (ASIL) decomposition³⁹ is proposed to decompose the automotive code with higher ASIL standards into different pieces of lower ASIL standards, and then place the decomposed pieces on different cores. As in Figure 1, in this work, we aim to push the landscape frontier to the top-left corner with low overhead and high resilience. Thus, we leverage the insight from inherent systems performance and resilience characteristics and propose to overcome this trade-off by concurrently optimizing performance-efficiency-resilience with an intelligent VAP paradigm.

Sensing.  Sensing tries to capture the environments^5,26 and is time-consuming. We show one of the nodes in the sensing stage in Figure 3(a), the average latency of the specific node is on the left y-axis. A node is an individual process performing certain tasks in a robot operating system (ROS). Ray_filter filters the LiDAR points to represent the ground. The average runtime of ray_filter is 29.6ms, which is a significant latency in an autonomous vehicle pipeline.

Perception.  Perception helps to build reliable and detailed representations of the dynamic surroundings based on sensory data.^11,27 The perception module is inherently computationally intensive and usually contributes the longest latency in autonomous machines. The serial processing of detect, track, and predict in the perception pipeline exacerbates computing latency. Although most perception nodes have been accelerated by GPUs or other accelerators, the perception stage still takes more than 100ms to finish. Figure 3(a) shows that the vision_detect node contributes 42.2ms to the entire pipeline, and lidar_detect node also has a latency of 15.5ms.

Localization.  Localization serves to calculate the position and orientation of an autonomous machine itself in a given frame of reference. Localization algorithms usually have high computational requirements. These algorithms, such as simultaneous localization and mapping (SLAM)^,31 and visual inertial odometry (VIO),² first capture correspondence in continuous frames, and then use multiple correspondences to solve a complex optimization problem for the final pose. A typical SLAM algorithm takes tens of ms latency even running on a powerful Intel CPU.^22,36 The VIO algorithm exhibits similar latency.³⁰ Figure 3(a) shows that our autonomous vehicle pipeline uses ndt_matching as the localization algorithm, with an average latency of 35.2ms.

Planning.  Planning tries to find a collision-free path from the current location to the destination.^8,12 Planning algorithms usually rely on the occupancy grid produced by the perception module and indicates whether the locations are free or occupied. Once the occupancy grid map is generated, it will not change during one planning process. The start location on the occupancy grid map is determined by the localization module.

Decision making.  Autonomous machines use state machines to control behavior, where the state machine is controlled by the decision-making module. For example, in Autoware, when an autonomous vehicle detects a pedestrian close by, the decision-making module will turn the vehicle’s status from driving to stopping. Decision making also relies on the results of perception and localization. Similar to the planning module, decision making is also vulnerable to errors as it directly influences the agent’s behavior.

Control.  Control is the last module in the autonomous machine pipeline, which is responsible for smoothing the control commands. The control module is the most lightweight module in autonomous machine software but it is the most vulnerable to errors.

Figure 3(a) shows three nodes from the backend: pure_pursuit, twist_filter and twist_gate. All three nodes have very low latency, which is less than 0.1 ms, however, they all have high EPR compared to the front-end. pure_pursuit has an EPR of 20.3%, twist_filter has an EPR of 70.8% and twist_gate has an EPR of 80.2%.

Front end: Software-based protection.  We apply anomaly detection in autonomous-machine, front-end sensing-perception-localization kernels (Figure 4). We leverage three insights for front-end protection. First, the vehicles or drones typically process temporal inputs and generate temporal outputs. For instance, the sequences of sensor inputs usually exhibit strong temporal consistency and continuous property. Moreover, when a vehicle is driving in a straight line, it is unlikely that the path planning module will issue a sudden actuator acceleration. Therefore, the outputs of consecutive time steps are usually bounded in the fault-free case, and errors in autonomous machines are sometimes manifested as outliers that break the temporal consistency and can be detected. Second, front-end kernels have inherent error-masking and error-attenuation capabilities through redundant information and operations, such as low-pass filtering and operator union. For example, an autonomous machine can tolerate a significant input-data rate drop without causing safety hazards. Third, front-end kernels exhibit rare false positive detection with anomaly detection, thus significantly reducing the node re-execution overhead and protection-failure cases.

To facilitate the proposed protection scheme in a plug-and-play manner, we propose to design anomaly detection as a ROS node. In this way, the autonomous machine code can be treated as a black box, and designers can directly integrate the protection scheme in the autonomous system through standard ROS function calls.

Back end: Hardware-based protection.  We apply modular redundancy and checkpointing in autonomous-machine, back-end planning-control kernels (Figure 4), by periodically storing a fault-free copy of the architectural state and executing the same code on two hardware modules. We leverage three insights for back-end protection. First, back-end kernels are very critical to errors (Figure 3), motivating us to strengthen fault protection with the hardware-based method. Second, the back-end nodes are extremely lightweight and do not perform any complicated computation, thus the overhead of running software calculations (for example, anomaly detection) would be large, but the overhead of hardware-based protection would be small. Third, more false-positive detection cases are from the back end in software protection, which results in potential protection failure and needs to strengthen from hardware-based protection.

To improve resilience without impacting performance, we propose a selective redundancy and ROS-based checkpointing approach. We only make redundancy copy for the hardware core running back-end modules and keep all cores running front-end modules unchanged. In ROS, we periodically queue the ROS node message during the normal process. If faults are detected, the faulty node can directly re-execute as long as the restart point is before the ROS node communication. Since all computation occurs locally before node communication and the amount of back-end computation is small, we can guarantee robustness without incurring large checkpointing overhead. This checkpointing method designed for ROS eliminates the large compute latency overhead brought by conventional architectural-state checkpointing and restore methods that may violate the real-time nature of autonomous machines.

Scalability and adaptability.  VAP is extensible to finer-grained stage-level or node-level protection. VAP can assign suitable protection schemes to each sensing-perception-localization-planning-control stage or each ROS node given the inherent node-level robustness variations (Figure 3). VAP is also extensible to other protection schemes, such as autoencoder-based anomaly detection and temporary redundancy.¹⁴ Moreover, VAP is adaptive for both pre-deployment and post-deployment protection scenarios. For pre-deployment, VAP offers the methodology to characterize the vulnerability of autonomous machine pipelines thus adaptively determining the protection scheme. For post-deployment, VAP can dynamically reschedule the ROS nodes across compute cores to adaptively switch between software and hardware protection.

Compared with software techniques: Anomaly detection.  Anomaly detection detects abnormal behaviors by leveraging the temporal consistency of autonomous machines. Evaluated on Autoware, anomaly detection can reduce the EPR from 46.5% to 24.2%. The reason that EPR is not further reduced is that in a few scenarios, the input information or output actions do have a sudden change, yet the anomaly protector treats it as an outlier and replaces it with the average value in the previous window or directly re-executes the node. These false-positive errors thus will propagate and result in non-perfect results. We observe that these false-positive cases mainly result from back-end modules. For example, in Autoware, 97.3% of the protection failure cases in $twist\_gate$ are caused by false positives, and the data is 94.5% for $twist\_filter$ node. This motivates us to adopt the hardware-based technique in the adaptive protection scheme to achieve improved resilience.

Compared with software techniques: Temporal redundancy.  Temporal redundancy ceases fault propagation by executing the same piece of autonomous-machine software code twice. Evaluated on Autoware, the temporal redundancy technique can reduce the EPR from 46.5% to 11.7%. Temporal redundancy is not guaranteed to fully mitigate hardware faults as the input to certain nodes can be faulty. Practically, instead of fully duplicating executions, the temporal redundancy scheme can trade off error-detection coverage with less percentage of code duplication for lower overheads, design complexity, and availability.

Compared with hardware techniques: Modular redundancy.  By executing identical software code on independent hardware, the fully duplicated system is shown to be effective against soft errors on Autoware. The error-propagation rate of autonomous vehicles can reduce to 0%. However, modular redundancy usually comes with a high extra dollar cost. The main overhead comes from the added silicon area and associated non-recurring engineering, which is expected to increase as autonomous machines increasingly integrate specialized accelerators.

Compared with hardware techniques: Checkpointing.  The checkpointing scheme ceases fault propagation by retrieving the saved state, so the application is recovered from the checkpoint and continues from that point on. Combined with modular redundancy as fault detection, the checkpointing protection scheme can reduce the EPR to 0% in Autoware. However, it is to note that checkpointing and restoring procedures greatly increase compute latency that may violate the real-time nature of autonomous machines.

Compared with software techniques: Anomaly detection.  Anomaly detection brings performance overhead due to the detection algorithm execution and node re-compute once outliers are detected. We apply anomaly detection on multiple ROS nodes in Autoware (Figure 3). The end-to-end compute latency increases from 164$ms$ to 245$ms$, resulting in a longer object avoidance distance from 5$m$ to 5.47$m$ (9.4% increase). The energy consumption of the system increases by 33.14%, resulting in 0.54$h$ driving time reduction. Since only a piece of code needs to be added to the autonomous vehicle software stack, the extra cost is negligible.

Compared with software techniques: Temporal redundancy.  Temporal redundancy introduces performance overhead mainly due to the redundant execution. Executing each software module twice effectively halves the performance. We apply temporal redundancy in Autoware, and the redundant execution almost doubles the compute latency from 164$ms$ to 347$ms$. Therefore, the vehicle can only proactively plan the route to avoid obstacles at 6.05$m$ away instead of 5$m$. The energy consumption increases by 75.24%, reducing the driving time by 1.12h. The temporal redundancy technique usually only involves extra software code execution with negligible engineering and silicon cost.

Compared with hardware techniques: Modular redundancy.  Hardware redundancy usually trades off extra power and cost for performance. We adopt the triple modular redundancy technique as an example, and evaluate it in Autoware. By leveraging three identical main computing modules (CPU + GPU), the end-to-end compute latency is almost unchanged since modern processors usually provide hardware support to minimize the performance overhead of executing on identical hardware copies. However, due to the redundancy of hardware platforms, the autonomous driving system power increases from 175$W$ to 473$W$, reducing the driving time by 2.15h, which can translate to 27.78% daily revenue loss.

Compared with hardware techniques: Checkpointing.  Checkpointing usually accompanies dual modular redundancy and brings a large performance overhead due to the store-and-retrieve procedure that may violate the real-time nature of autonomous machines. Checkpointing freezes the process and dumps the application states to the persistent storage, during which the process halts its execution without any progress. Meanwhile, checkpointing needs to be able to create globally consistent checkpoints across the entire application.

We evaluate checkpointing in Autoware. The end-to-end compute latency increases from 164$ms$ to 610$ms$, mainly due to the overhead of state frozen and restore. This significant latency increase results in a 51.2% longer stop distance, forcing the vehicle to avoid the obstacle 7.56m away. That is usually not tolerable compared to the original performance. The extra checkpointing operations and redundancy increase compute energy consumption by 91.52%, resulting in a 1.32 operation-hour reduction.

Although checkpointing is considered an efficient error-mitigation technique in cloud and database applications, it is not suitable for real-time applications, such as safety-critical autonomous machines, since it introduces latency spikes into the critical path which may result in deadline missing. Furthermore, the checkpointing and restore times scale linearly with the memory size, thus the overhead could be bigger if the autonomy kernels take lots of memory.

Resilience.  We use mission-failure rate as the resilience metric for drones.¹⁴ We define a failure case as the drone colliding with obstacles or failing to find a feasible path to the destination within the battery capacity limit. The reason we apply different metrics in autonomous vehicles and drones is that autonomous vehicles and drones face different reliability concerns. Autonomous vehicles face more complicated scenarios on the road. A slight difference in the command to the actuators can lead to a potential crash with other vehicles or pedestrians. Drones, however, work in scenarios with greater freedom. The chance of a crash with obstacles led by a slight trajectory change is rare.

Latency.  Compute latency impacts the safe flight velocity of drones and needs to be short enough to ensure flight mission safety. Within the sensor rate and physics limits, as the compute latency becomes longer, the drone must lower its safe flight velocity to ensure enough time to react to obstacles without colliding.

Figure 5(a) shows the relationship between compute latency and maximum safe flight velocity derived from analytical modeling²⁴ and validated in concrete real-world flight tests.^19,21 Our drone is equipped with cameras that sense objects within 4.5$m$, and an TX2 as onboard compute to generate high-level flight commands. Our drone has an average compute latency of 871$ms$ with 2.79$m/s$ average flight velocity during an autonomous navigation task. Achieving high safe velocity is crucial as it ensures that the drone is reactive to a dynamic environment and finishes tasks quickly, thereby lowering mission time and energy.²⁰ This latency model allows us to understand how computing latency matters in the autonomous drone system and impacts mission performance.

Energy.  The drone is severely constrained in terms of size, weight, and power (SWaP). A physics component change (for example, onboard payload) will impact flight performance. Payload weight, such as redundant onboard computers and larger heatsinks, affects a drone’s acceleration, thus lowering its thrust-to-weight ratio and safe flight velocity.

Figure 5(b) illustrates the relationship between drone payload weight and its maximum safe flight velocity on an drone platform. As the drone gets smaller in form factor, its safe velocity would be more sensitive and affected by payload weight due to a decreasing payload-carrying capability.¹⁹ Furthermore, flight velocity closely correlates to the flight mission time and energy. Hence, it is essential to understand these effects when designing and evaluating fault-protection schemes for drones.

Adaptive protection VAP is cost-effective in a drone system.  The proposed VAP exhibits high resilience on a drone system with a small performance overhead. For improved operational safety, notably, VAP can reduce the flight mission failure rate to 0% under soft errors.

For reduced performance overhead, evaluated on a typical autonomous drone system, the adaptive protection slightly increases end-to-end compute latency from 871$ms$ to 897$ms$. Since false-positive cases are rare for front-end modules, the main overhead of anomaly detection comes from extra detection logic. This slight latency overhead results in a small drop in average flight velocity from 2.79$m/s$ to 2.77$m/s$, consequently resulting in mission flight time slightly increasing from 107.53$s$ to 108.30$s$, and mission energy increasing from 60.09$kJ$ to 60.52$kJ$ with 0.72% less endurance.

Conventional “one-size-fits-all” techniques bring more performance degradation in small-scale systems.  Conventional hardware and software protection techniques incur large compute and end-to-end performance overhead on drone systems. For example, software-based anomaly detection increases the end-to-end compute latency from 871$ms$ to 1,201$ms$, lowering the average flight velocity from 2.79$m/s$ to 2.51$m/s$. This consequently results in 11.15% higher flight energy for the same navigation task, and the number of missions that a drone is capable of finishing is reduced from 5.62 to 5.05.

Notably, since a drone has a limited battery capacity and a smaller form factor compared to vehicles, the compute latency overhead results in greater system performance degradation. For example, software-based temporal redundancy increases the end-to-end compute latency by 2.21$\times$ in the worst scenario, which lowers the average flight velocity from 2.79$m/s$ to 2.14$m/s$. This results in 30.37% higher flight energy and 23.30% less mission endurance. Hardware-based checkpointing increases end-to-end compute latency by 3.97$\times$, lowering the average flight velocity to 1.75 $m/s$ and resulting in 61.02% higher flight energy for the same navigation task. Similarly, extra payload weight have higher impacts on small form factor drones and result in more performance degradation.