Every driver monitoring system built so far shares the same underlying goal: keep the person behind the wheel alert enough to drive safely. That goal quietly assumes something that won't be true forever — that there's a person who needs to be driving at all. As vehicle autonomy climbs toward SAE Levels 4 and 5, the entire premise of in-cabin monitoring flips. The question stops being "is this person alert enough to drive" and starts becoming "is this person comfortable, safe, and okay" — a fundamentally different sensing problem, even though many of the same sensors end up being used to answer it.
This post walks through how driver monitoring's purpose, and the sensor architecture behind it, changes as autonomy level increases — and why teams building in-cabin sensing today need to design for where that curve is heading, not just where it is now.
The SAE Levels, and Where the Human's Role Actually Changes
The SAE's five-level framework for driving automation defines a steadily shrinking role for human attention:
- Levels 1-2 — driver assistance and partial automation. The human must remain completely attentive at all times, since these systems work in parallel with the driver rather than replacing their judgment.
- Level 3 — conditional automation. The driver may divert attention from driving but must be ready to retake control when the vehicle requests it — the classic "eyes off, mind ready" state that current DMS platforms are built around.
Level 4 — high automation. The vehicle is fully capable of driving itself within defined limitations (geography, weather, road type), and occupants don't need to be engaged or ready to take over at all — though these systems remain geographically constrained, well suited to robotaxis, shuttles, and defined-route trucking rather than universal driving.
- Level 5 — full automation. The vehicle handles all driving in all conditions. There is no driver in any functional sense — every occupant is simply a passenger, free to work, sleep, or otherwise disengage entirely from the driving task.
The critical transition, from a sensing standpoint, happens at the boundary into Level 4: this is where "is the human ready to drive" stops being a meaningful question the system needs to ask at all.
- Why "Stay Awake" Sensing Doesn't Just Become Unnecessary — It Becomes the Wrong Question
At Levels 1-3, drowsiness detection exists to prevent a specific failure mode: a driver who needs to be actively controlling or ready to control the vehicle loses the alertness required to do so safely. Every design decision in current DMS platforms — alert urgency, false-alarm tolerance, escalation logic — is built around that specific stakes profile.
At Level 4 and beyond, that failure mode simply doesn't exist for driving purposes, because the human was never expected to intervene. Research on in-cabin monitoring for autonomous vehicles explicitly recognizes this shift, noting that at Level 4 and beyond, every occupant is a passenger, with no one in the vehicle responsible for driving — which means the entire premise behind "wake this person up to drive" sensing has to be rethought, not simply relaxed.
This doesn't mean in-cabin sensing becomes less important. It means it needs to answer different questions.
What In-Cabin Sensing Is For at Level 4 and Beyond
Once the human isn't a fallback driver, in-cabin monitoring shifts toward occupant wellbeing, safety, and comfort — a real, if different, set of engineering requirements:
Safety monitoring without a driving purpose. Even with no one driving, the cabin still needs monitoring for genuine safety events — a medical emergency, an unresponsive occupant, an unrestrained child, someone in physical distress. This is closer to the occupant-monitoring systems already used for functions like adjusting airbag deployment based on detected passenger presence and position, extended into an ongoing wellbeing-monitoring role rather than a single-moment safety check.
Handling the "must remain conscious" edge cases. Even at Level 5, some analyses of autonomous vehicle patents and engineering approaches note that occupants may still need to remain conscious enough to respond appropriately to certain situations — meaning full disengagement isn't necessarily absolute, and monitoring for basic responsiveness may persist even when active driving readiness is no longer required.
Comfort as an explicit design goal. With driving controls no longer relevant, the passenger experience genuinely shifts toward what comfort-focused engineering literature describes as the ability to work, sleep, or otherwise fully occupy the ride — meaning in-cabin sensing increasingly needs to support comfort features (seat positioning, cabin climate personalization, sleep-friendly lighting) rather than alertness enforcement.
Data needs change, not just purpose. Research on autonomous in-cabin monitoring systems has flagged the lack of substantial, purpose-built datasets as a real bottleneck — existing driver-monitoring datasets were built to capture drowsiness and distraction signals relevant to a driving task, and don't necessarily transfer well to a monitoring system whose job is now passenger wellbeing rather than driving readiness.
The Sensor Architecture Implication: Reuse the Hardware, Rearchitect the Purpose
Here's the genuinely useful engineering insight for teams building in-cabin sensing today: much of the physical sensor stack doesn't need to change across this transition, even though what the system is trying to determine does.
Cameras remain present and useful across every SAE level — the same vision hardware that tracked eye closure and head pose for drowsiness detection at Level 2 can, at Level 4, be repurposed to detect whether a sleeping passenger has slumped into an unsafe position, or whether an occupant appears to be in medical distress. Similarly, physiological sensing approaches — heart rate via seat or steering-adjacent sensors, as covered in our recent post on physiological sensing in the cabin — remain just as relevant for detecting a genuine medical event in a Level 5 passenger as they were for detecting fatigue in a Level 2 driver.
What has to change is the inference layer sitting on top of that sensor data: the classification model that once asked "is this person drowsy" needs to be substantially rearchitected to ask "is this person safe and comfortable" — a different set of labeled behaviors, different alert thresholds, and, per the dataset gap noted above, likely a different training dataset altogether, even when the raw camera and physiological signal pipeline underneath stays largely intact.
What This Means for Teams Building In-Cabin Sensing Now
For hardware and firmware teams working on cabin sensing platforms today, a few forward-looking design choices are worth making even before Level 4 deployment is the immediate target:
Architect the sensor layer to be purpose-agnostic where possible. Camera placement, physiological sensor integration, and data pipeline design that assume only a "driver alertness" use case will need real rework later — designing with occupant-wellbeing use cases in mind from the start avoids a second hardware iteration.
Separate the inference/classification layer from the sensing layer explicitly. If the model logic answering "is this person okay" is cleanly decoupled from the raw sensor acquisition pipeline, retraining or replacing that layer as the product's purpose shifts becomes a software problem rather than a hardware redesign.
Start building or sourcing occupant-wellbeing training data now, not later. Given the acknowledged dataset gap for autonomous-vehicle occupant monitoring, teams with an early data collection strategy — even simple labeled comfort/distress scenarios — will have a real head start when the purpose shift becomes commercially urgent.
Treat comfort sensing as a genuine, non-trivial engineering requirement, not an afterthought bolted onto a safety system — cabin climate, seating, and lighting personalization increasingly depend on the same occupant-sensing infrastructure as safety monitoring, and are worth co-designing rather than treating as unrelated features.
Conclusion
The shift from "stay awake" to "sleep well" isn't a simplification of driver monitoring — it's a genuine re-scoping of what in-cabin sensing needs to determine, even as much of the underlying camera and physiological sensor hardware carries over largely unchanged. Teams that architect their sensing and inference layers with that eventual purpose shift in mind now will be far better positioned than those who build tightly around today's alertness-detection use case and have to rebuild the whole stack when the cabin's job changes from monitoring a driver to caring for a passenger.
At CoBuild Labs, we design in-cabin and wearable sensing systems with this kind of purpose evolution in mind from the start — building sensor architecture that can be re-targeted as requirements shift — see wearables vs cabin cameras and firmware modularity.
Planning in-cabin sensing for higher automation levels? Talk to CoBuild Labs — explore wearables vs cabin cameras, motion-sickness prediction, and firmware architecture.