The car is an edge-AI device by necessity, not preference: decisions that matter — drowsiness, collision warning, occupancy — cannot wait on a cellular round trip through a tunnel.
This guide covers the models that run inside the vehicle: in-cabin sensing, driver monitoring, road-event detection on ECUs and low-power telematics.
Driver monitoring: latency is the safety case
Driver Monitoring Systems (DMS) watch for drowsiness, distraction, and gaze direction — increasingly mandated by safety ratings and regulation (EU GSR, Euro NCAP). The pipeline is classic edge: IR camera frames through a small face/eye model, scored per frame, fused over time into attention state.
Every stage must run on the ECU or a dedicated SoC — a drowsiness warning that's delayed by connectivity is a drowsiness warning that arrives after the crash. Models are compact CNNs or lightweight landmark detectors; NPU-equipped automotive SoCs handle them at frame rate with headroom.
Occupancy and in-cabin sensing
Beyond the driver: child-presence detection (hot-car prevention), seat occupancy for airbag suppression, and gesture controls for infotainment. These run on radar, ultrawideband, or camera sensing — mmWave radar is winning for privacy (no images) and works in darkness.
The models are small by necessity — automotive qualification (AEC-Q100, functional safety) favors simple, auditable architectures. A small CNN classifying radar point-clouds for 'child in back seat' ships; a transformer that can't be explained to a safety assessor doesn't.
- DMS — drowsiness, distraction, gaze, on IR camera + NPU
- Child presence — mmWave radar, no images, privacy-safe
- Road events — potholes, harsh braking, impacts on IMU/audio
- Telematics — edge scoring of driving events, not raw streams
Road-event detection on telematics
Insurance telematics and fleet dongles run TinyML on IMU + GNSS data to classify driving events: harsh braking, cornering, pothole impacts, crash signatures. On-device classification means the dongle sends 'harsh brake at km 42' instead of streaming accelerometer data — privacy and bandwidth both win.
Crash detection is the highest-stakes case: impact signature plus post-impact trajectory, decided in under a second on the device, escalating to eCall. It's anomaly detection plus a classifier — the same architecture as predictive maintenance, at higher urgency.
Constraints: qualification, temperature, lifecycle
Automotive edge AI lives under the harshest deployment envelope in consumer electronics: -40°C to +105°C junction temps, 10+ year vehicle lifecycles, functional-safety review of anything safety-adjacent. Models ship frozen and qualified — the 'ship fast, update often' consumer playbook doesn't apply without OTA infrastructure that most OEMs are still building.
That lifecycle argues for the flywheel pattern anyway: vehicles that log anonymized event features (with consent frameworks) feed retraining, and OTA-capable ECUs push model updates — turning a decade-long deployment into a learning fleet.
Where it shows up
Driver monitoring (DMS)
IR camera + NPU-class models track gaze, eyelid state, and head pose for drowsiness and distraction warnings — mandated by NCAP/GSR.
Child presence detection
mmWave radar classifies micro-motion signatures in the cabin — hot-car alerts with no camera images leaving the vehicle.
Telematics event scoring
IMU-based classifiers detect harsh braking, impacts, and road conditions on the dongle — events uploaded, not raw streams.
Frequently Asked Questions
Do DMS systems need cameras, or can radar work?
Both ship. Camera-based DMS (IR illumination, small CNN on NPU) is the mainstream — gaze and eyelid tracking need image detail. mmWave radar handles occupancy and child-presence detection without images — preferred where privacy rules or darkness matter. Some systems fuse both.
How does on-device inference handle the automotive temperature range?
Qualified silicon is the answer — AEC-Q100 graded MCUs and SoCs rated for -40°C to +105°C+ ambient. The model doesn't change; the part selection and thermal design do. This is why automotive edge AI is an engineering engagement, not just a model port.
Can vehicle models be updated over the air?
Increasingly yes — modern E/E architectures support OTA to domain controllers and some ECUs. The update discipline is the automotive version of the standard pattern: signed payloads, staged rollout across the fleet, safety-case review for anything touching certified functions.
What about V2X — isn't that cloud AI?
V2X is communication, not inference — and the vehicle must still decide locally what to do with incoming data. Perception fusion, threat assessment, and action all run on-board; V2X just adds another sensor's worth of input to the edge pipeline.
Building something that should run AI on-device?
Edgehound designs, compresses, and deploys TinyML models on microcontrollers — from feasibility audit to field-ready firmware.