AI is used in the automotive industry in two places: inside the vehicle and outside it, on the production line. Inside the vehicle, driver-assistance features such as automatic emergency braking measurably reduce crashes. On the production line, AI vision and acoustic checks inspect assembly quality. What automotive edge AI can deploy is bounded by the latency, power and numeric behaviour of the hardware it ships on. And a perception model only earns trust in production once it has safety evidence that no demo produces. The wider cluster, including remote-driving video, is collected in our automotive AI and teleoperation video hub.
How does AI improve vehicle safety after manufacturing?
AI improves safety after the car leaves the factory through driver-assistance functions that detect a potential collision and brake automatically, and this is now measured at fleet scale. MITRE’s 2025 PARTS study of US passenger vehicles covered 98 million vehicles from 168 models (model years 2015 to 2023), with data from nine OEM partners and 21.2 million police-reported crashes across 16 states. It found that vehicles with automatic emergency braking (AEB) had 49% fewer front-to-rear crashes, with a 95% confidence interval of 48% to 50%. AEB’s reduction in rear-end crashes also improved over time, from 46% for model years 2015 to 2017 to 52% for 2021 to 2023.
Pedestrian AEB was measured on a different crash type, crashes with non-motorists. MITRE measured a 9% reduction (95% CI 3% to 14%) in single-vehicle frontal crashes with non-motorists, the first statistically significant PAEB result in the PARTS programme. MITRE itself points out that police-reported pedestrian impacts are rare, and that more research is needed on systems designed to detect cyclists and scooter users. We read the distance between 49% and 9% as a sign of where in-vehicle perception still has the most room to improve. That is our interpretation, not a finding of the study.
Two limits matter before anyone quotes these figures as the effect of AI alone. The study counted features fitted at manufacture, but it could not see whether drivers had them switched on or whether they activated during the crash. Newer vehicles also crash less overall, which can inflate the estimated effect of features that almost every new car has.
Why do GPU acceleration and edge computing matter for automotive AI?
Perception has to run on the car, finish inside a fixed deadline and stay within a power budget, and a general-purpose CPU cannot carry that load. The work by Lin et al., as summarised by The Morning Paper, sets the requirement as processing traffic conditions within 100 ms at least once every 100 ms. Because performance must be highly predictable, it is judged at the 99th or 99.99th percentile latency, not the average.
The load is concurrent, too. A 2024 review of autonomous-vehicle accelerators describes vision systems that must process more than 10 video streams in real time in most cases. A 2021 study of NVIDIA automotive GPUs notes that the number of deep learning instances running at once can easily reach dozens, with some systems using more than 8 cameras and radars. For how those streams flow through detection, tracking, fusion and planning, see the overview of what AI does in an autonomous vehicle. The deep learning perception data path follows sensor input into the models in more detail.
Hardware acceleration is what made convolutional models practical in the car. The 2024 review records that earlier accelerators were not powerful enough to run CNNs, and that CNNs have since replaced most traditional image-processing methods as acceleration made real-time inference possible at reasonable power.
Automotive edge AI hardware: what the spec sheets give and what it costs in range
The headline numbers set the ceiling. NVIDIA’s Jetson AGX Orin offers 275 TOPS, with power configurable between 15 W and 60 W. Qualcomm’s Snapdragon Ride platform is described as delivering 30 TOPS for L1/L2 applications and over 700 TOPS at 130 W for L4/L5. NVIDIA’s AGX Xavier pairs its Volta GPU with 32 GB of LPDDR4x at 137 GB/s.
Vendor comparisons need reading with care. Mobileye’s EyeQ6H benchmark page states that the EyeQ6H runs in INT8 while the Orin results it reports are in FP16. Figures measured at different precisions are not a like-for-like comparison of the chips.
Power shows up as driving range
Lin et al. found that a power-hungry system can degrade fuel efficiency by as much as 11.5%. The processors account for about half of the extra power, and cooling and map storage take the rest. In their design study, GPU object detection with ASIC tracking and localisation gave the lowest tail latency but went slightly over a 5% range-reduction budget. Only the all-ASIC and ASIC-plus-FPGA localisation combinations met both the power budget and, only just, the latency budget. The 2024 review reports that ASIC-based systems can reduce tail latency by up to 93 times compared with GPUs. Higher camera resolution was also out of reach: some accelerated systems met the deadline at 1080p, but none sustained Quad HD.
At fleet scale the constraint becomes environmental. Sudhakar, Sze and Karaman (IEEE Micro) estimate that if about 95% of vehicles were autonomous, onboard compute would have to stay below 1.2 kW per vehicle for its emissions to remain under those of all 2018 data centres in 90% of modelled scenarios.
Offloading work the GPU should not be doing
NVIDIA describes how NIO moved block-linear to pitch-linear conversion, YUV-to-RGB colour conversion and masking from the GPU and VIC onto the Programmable Vision Accelerator on DRIVE Orin. This cut GPU resource use by 10%, and the pipeline used only about 25% of the PVA’s capacity. NVIDIA states that this optimisation is used extensively in NIO’s mass-production vehicles.
INT8 quantisation does not carry over between targets
The usual edge recipe assumes that INT8 post-training quantisation makes inference faster at a small, predictable accuracy cost, and that a model quantised once can go to any target. A cross-platform measurement study, “Is INT8 Portable?”, tested seven hardware classes and found this false on all three counts.
- Speed: cores with a dot-product instruction set (ARM SDOT, x86 VNNI) ran up to 2.1x faster under INT8. Cores without it ran 1.7x slower, for the same model and runtime.
- Numerics: FP32 predictions matched exactly across every platform pair. INT8 predictions matched 1000/1000 only when two targets shared an integer kernel, and 958 to 965 out of 1000 when they did not.
- Deployability: a bring-your-own quantised graph on one vendor NPU dropped accuracy from 0.75 to 0.005, yet it still compiled, profiled and ran without error.
The divergence is easy to miss. On the Jetson iGPU, INT8 top-1 accuracy was 0.7620, lossless against its own FP32, even though it flipped predictions on dozens of individual inputs compared with the CPU INT8 path. A standard accuracy-after-quantisation report would have shown nothing wrong. DETR, a transformer detector, collapsed under INT8: its mAP fell from 0.4207 to 0.2402, a 42.9% drop. In the study, pre-processing mattered more than quantisation itself. A change of resize and crop moved top-1 accuracy by 1.07 percentage points, roughly nine times the 0.12-point cost of quantising.
For automotive work, the consequence reaches determinism and redundancy. Dual-compute safety architectures rely on heterogeneous units running the same model agreeing across modules. Non-portable INT8 numerics directly threaten that assumption. The authors recommend re-validating INT8 on every target, treating the vendor’s native quantisation path as mandatory, and provisioning edge accelerators by data movement rather than TOPS. Their vendor-NPU findings cover Qualcomm and DEEPX only. TI and Renesas parts were not tested.
How is AI used in automotive manufacturing today?
At BMW, AI on the line is used for quality assurance: checking that each vehicle has been built as specified and flagging assembly errors as they happen. BMW Group described in November 2023 how its in-house AIQX and Car2X systems do this. With Car2X, which is cloud-based, the vehicle communicates in real time with the production system, reports its assembly status and identifies and reports assembly errors itself. AI-based visual and acoustic quality assurance runs in the BMW iFACTORY. BMW presents these in-house AI developments as the basis of its production plans across its plants worldwide.
An earlier study of deep learning in the automotive industry already listed quality monitoring in manufacturing next to autonomous driving and infotainment. It also described the image and video data from inspection as often managed by hand in spreadsheets and folders.
What is the role of computer vision in vehicle quality control?
The hard part is keeping accuracy once real factory images replace the curated training set. That study shows this clearly. Its authors built an inspection dataset of 82,011 images covering 4 vehicle types and 25 camera perspectives, 100 categories in all. They then deployed the trained model inside an iPad app used by line associates. Across 204,883 real classifications collected over several weeks, on data that had not been carefully prepared, average accuracy was 81%. It ranged from 44% in the weakest category to 98% in the strongest.
A station that is reliable on most categories but close to a coin toss on one will push defects through on exactly that category. Detection and tracking look solved in demos, but off-the-shelf models fail in production at the edge cases, lighting conditions and throughput of real deployments.
In-vehicle perception or line inspection: where vision pays off first
In-vehicle perception has a measured effect on safety, as the AEB figures show. It also carries tail-latency, power, per-target quantisation and automotive safety-standard constraints. We see the two as complementary rather than competing. They differ in how much evidence each needs before it ships.
What should an automotive team check before trusting a perception model in production?
A team should check that the model meets safety requirements derived from hazard analysis, on the hardware that ships and under the conditions it will meet, with failures caught at runtime. Benchmark accuracy on a public dataset does not show any of this.
The engineering items in the checklist below (porting a perception model to the target accelerator, re-validating quantised builds per target, measuring tail latency on the shipping hardware) are compute work that TechnoLynx takes on through its AI engineering for manufacturing and automotive work.
A 2017 analysis of ISO 26262 found that about 40% of the software techniques in the standard do not apply to machine learning. It also argued that a training set used in place of a specification is necessarily incomplete. ISO/PAS 8800:2024 (edition 1, December 2024) now addresses the risk of unsafe vehicle-level behaviour caused by output insufficiencies, systematic errors and random hardware errors of AI elements in series-production road vehicles. ISO 21448 (SOTIF) covers hazards from performance limitations rather than malfunctions, such as a pedestrian the system fails to detect.
SOTIF offers minimal quantitative guidance, which published work tries to decompose into perception requirements. One published decomposition, for example, concluded that position error must not exceed 17 m at about 110 m when the ego vehicle travels at 130 km/h with a 50 km/h relative speed to the vehicle ahead. It also set a velocity error limit of about 10 km/h. Those authors note that their data comes mainly from public datasets, which may not represent real driving. We see the method as reusable across programmes. The thresholds do not.
The RoboBEV benchmark evaluated 33 bird’s-eye-view perception models. Every model lost performance on corrupted inputs, and many struggled specifically with Dark and Snow. In a day-to-night transfer, a baseline detector’s score fell from 0.3867 to 0.0854.
Silent failures need a separate safety net, because a confident wrong output trips no conventional diagnostic. The FAME framework synthesises runtime monitors from system-level safety requirements. In a simulated autonomous-vehicle perception case it detected 93.5% of critical safety violations that would otherwise have gone unnoticed, using under 0.1% of the inference process’s CPU time and under 1 MB of memory. Its authors place the monitor within ISO 26262 ASIL decomposition, where an ASIL D AI function is paired with a simpler monitor verified to a lower level such as ASIL B, plus a verified safe state.
Diagnostic checklist before production
| Check | What it guards against | Basis |
|---|---|---|
| Safety requirements are written per safety-relevant output, not as a generic accuracy target | A good mAP that hides the misclassifications that matter, such as reading a 40 mph sign as 70 | AMLAS guidance |
| Results are reported per class and per condition (such as dark and snow) | Averages that hide one weak category or one corruption condition | RoboBEV; 2017 field study |
| Accuracy and latency are re-measured on the production target with the production pre-processing | INT8 builds that are slower, or wrong, on the shipping chip | INT8 portability study |
| Latency is measured at the 99th or 99.99th percentile against the deadline | A model that meets the deadline on average and misses it in the tail | Lin et al. via The Morning Paper |
| Per-input agreement is tested across redundant compute units | Dual-compute redundancy that disagrees under INT8 | INT8 portability study |
| The vendor-native quantisation path is used, and its outputs are checked, not only its build | An NPU that runs a silently broken model | INT8 portability study |
| Verification data stays hidden from the developers and verification is independent | A model tuned to pass the test set rather than the class of failure | AMLAS guidance |
| A runtime monitor that triggers a verified safe state is in place | Confident but incorrect AI outputs | FAME |
The evidence that is still missing
The gaps in the evidence are as useful as the evidence itself. ISO/PAS 8800 is a first-edition Publicly Available Specification, published in 2024. The INT8 study did not test TI or Renesas NPUs. The fleet data cannot yet say whether a feature was switched on at the moment of the crash. So a team should be able to point to every number in its perception safety case and say whether it was measured on the chip, at the precision and with the pre-processing that will actually ship. Where it cannot, that is the next measurement to make.
