In-Cabin Sensing: How ASIL Shapes the Perception Evidence It Needs

Treating the in-cabin sensing stack as one perception module — and documenting every function to the same depth — is the mistake that gets teams challenged where it matters and over-invested where it doesn’t. In-cabin sensing is not a single classification. A driver-drowsiness monitor and a gesture-controlled infotainment shortcut both run camera-fed perception, but they carry very different integrity weights, and the evidence each one owes a safety reviewer follows from that weight, not from the fact that they share a sensor.

The naive move is to build one validation surface for “the in-cabin camera stack” and pour equal rigour into every function hanging off it. That produces two failures at once. The high-consequence driver-state monitors get documented at the same shallow depth as a comfort feature, so the reviewer’s risk attention lands on them and finds the evidence thin. Meanwhile the comfort features get the same heavy treatment as safety-relevant monitors, burning validation effort where nobody’s risk model was ever going to point. The expert move is to read the ASIL assigned to each function and let it set how deep the evidence has to go.

What does in-cabin sensing actually cover?

In-cabin sensing is the family of perception functions that observe the vehicle interior — occupants, the driver, and the cabin state — usually from one or more interior cameras, sometimes fused with radar or capacitive sensing. In practice it spans a wide range of jobs: driver drowsiness and attention monitoring, gaze estimation, occupant presence and classification (adult, child, empty seat), seatbelt-state detection, body-pose and hand-keypoint tracking for gesture control, and various comfort or personalization conveniences.

What matters for evidence is that these functions do not share a consequence profile. A driver-monitoring system that misses a drowsy driver contributes to a safety hazard the vehicle’s hazard analysis will care about. A gesture shortcut that misfires and skips a track does not. The perception team often sees them as one codebase and one dataset pipeline. The safety case sees them as separate functions with separate integrity demands — and the safety case is the one the reviewer reads.

Which in-cabin functions are safety-relevant, and which are QM?

The dividing line is set upstream, in the hazard analysis and risk assessment (HARA) that assigns each function an ASIL — A, B, C, or D — or classifies it as quality-managed (QM) when no safety goal depends on it. That assignment reaches the perception team through the system specification; it is not something perception invents, and it is not something you can infer by looking at model architecture. Two functions can run the same detection backbone and land at completely different integrity levels because their failures feed different hazards.

A rough map of where in-cabin functions tend to sit — with the important caveat that the actual ASIL is program-specific and always comes from the HARA, not from a generic table:

In-cabin function	Typical integrity posture	What its failure feeds
Driver drowsiness / attention monitoring	Safety-relevant (often ASIL B, sometimes higher per program)	Driver-state hazard; may trigger warnings or handover logic
Occupant classification for airbag suppression	Safety-relevant (commonly ASIL B)	Restraint-deployment decision
Seatbelt-state detection	Safety-relevant or QM depending on use	Restraint reminder / interlock
Gaze / eye-off-road for ADAS handover	Safety-relevant when it gates a driving function	Control-transition decision
Gesture control for infotainment	QM	Convenience action, no safety goal
Comfort personalization (seat, climate)	QM	User-experience state, no safety goal

The postures above are illustrative planning heuristics drawn from how these functions commonly get classified — not a benchmarked rate and not a substitute for your program’s HARA. The point of the table is the shape, not the specific letters: in-cabin sensing routinely mixes safety-relevant monitors and QM conveniences inside one perception stack.

How does an ASIL set the depth of a driver-state monitor’s evidence?

Once a function carries an ASIL, that rating drives a set of expectations about how thoroughly its behaviour must be characterized and how traceably its evidence connects back to requirements. A higher ASIL does not mean “the same tests, run more times.” It means a broader and deeper evidence surface: more explicit operational-design-domain coverage (lighting, occlusion, occupant diversity, eyewear, head pose), stronger requirements on failure detection and diagnostic coverage, and tighter traceability from each safety expectation to the specific test that produced the supporting result.

This is the same graded-evidence logic that governs the exterior perception stack. A human bounding box in an ASIL D pack owes far more than a label — it owes coverage, provenance, and a traceable link to the requirement it satisfies. In-cabin driver-state monitoring inherits that same discipline, scaled to its own assigned ASIL. A drowsiness monitor at ASIL B carries a demonstrably deeper evidence obligation than a QM gesture feature, and the reviewer expects to see that difference reflected in the pack, not flattened out of it.

Concretely, for a safety-relevant driver-attention function you would expect the evidence to show: the ODD conditions the model was validated across, performance under the degradations that matter in a cabin (low light, sunglasses, partial face occlusion, extreme head angles), the fault-detection behaviour when the input is unusable, and a trace from the assigned integrity expectation to the test case that demonstrates each of these. For a QM gesture feature, a functional test suite and basic accuracy reporting is proportionate. Same stack, different depth.

Why uniform documentation depth backfires

When a team documents every in-cabin function to one depth, the depth is almost always wrong for most of them. If the team picks a shallow uniform depth to keep effort manageable, the safety-relevant monitors come up short exactly where the reviewer looks hardest, and clarification rounds pile up on the driver-state functions. If the team picks a deep uniform depth to be safe, it burns validation effort characterizing comfort features to an integrity level nobody asked for — effort that could have gone into the ODD coverage the driver monitor actually needs.

The failure is not a lack of rigour. It is misplaced rigour. In our experience across perception validation work, the packs that clear review fastest are the ones where the depth of each function’s evidence visibly tracks its assigned integrity level, so the reviewer can see the team understood why a given test depth matches a given function. That legibility is itself part of the evidence. A reviewer who can see the mapping spends less time asking whether the team knows which functions are safety-relevant.

The measurable payoff shows up as fewer clarification rounds on the high-ASIL driver-monitoring functions, higher first-pass clearance on their evidence surfaces, and less rework when a reviewer questions why a test depth matches an integrity level. These are outcomes we observe when evidence depth is mapped to per-function ASIL rather than applied uniformly — an observed pattern from validation engagements, not a published benchmark.

Where does an in-cabin function’s ASIL come from?

It originates before perception ever sees it. The HARA identifies hazards and assigns safety goals; the functional-safety concept allocates those goals to functions and derives their ASILs; the system specification then hands the perception team a function with an integrity level already attached. This matters because the perception team’s job is not to decide how safe a function must be — it is to produce evidence proportionate to a decision made upstream. When a perception engineer treats the in-cabin stack as one undifferentiated module, they are quietly overriding a classification the HARA already made, and the reviewer will notice the mismatch.

This is why the useful question is never “how good is our in-cabin model?” but “which function are we talking about, what ASIL did it inherit, and does its evidence go as deep as that ASIL demands?” The same reasoning runs through the whole automotive computer-vision discipline: the model is the same object regardless of consequence, but the evidence it owes is set by the safety context it operates in. In-cabin sensing simply makes that split unusually visible, because it packs high- and low-consequence functions into one stack. The broader relationship — how ML perception meets automotive safety demands — is the same pattern applied to the exterior stack.

How should the validation pack be structured for a mixed-integrity stack?

Structure the pack by function, not by module, and let each function’s section carry evidence proportionate to its ASIL. A practical rubric:

Enumerate functions, not features. List each in-cabin sensing function as its own evidence subject, with its assigned ASIL (or QM) stated explicitly at the top of its section, cited back to the system spec.
Scale the ODD coverage to the integrity level. Safety-relevant driver-state monitors get full cabin-condition coverage matrices; QM conveniences get a functional test suite. Do not invert this.
Trace every safety expectation to a test. For each ASIL-carrying function, show the link from the integrity expectation to the specific test that produced the supporting result — the traceability a reviewer needs to confirm the evidence actually backs the claim.
Make the depth difference visible. The pack should let a reviewer see, at a glance, that the driver monitor’s evidence is deeper than the gesture feature’s — and why. That legibility shortens review.
Keep provenance intact across shared components. When two functions share a backbone or dataset, the shared provenance still has to satisfy the highest ASIL among the functions that depend on it.

That last point is the trap in mixed-integrity stacks: a shared component inherits the integrity demand of the most safety-relevant function that uses it. You cannot document a shared driver-facing model to QM depth just because one of its downstream uses is a comfort feature. The graded evidence pattern — the discipline of matching validation depth to consequence — is the general reliability engineering approach applied to a per-function ASIL classification, and in-cabin sensing is where it gets tested hardest.

FAQ

How does in-cabin sensing work in practice?

In-cabin sensing observes the vehicle interior — driver, occupants, cabin state — usually from interior cameras, sometimes fused with radar or capacitive sensing. It covers functions ranging from driver drowsiness and attention monitoring to occupant classification, gesture control, and comfort personalization. In practice these functions often share a codebase and dataset pipeline but carry very different safety consequences, so treating them as one perception module misrepresents what the safety case actually needs.

Which in-cabin sensing functions carry safety-relevant ASIL ratings and which are quality-managed (QM) convenience features?

Driver drowsiness and attention monitoring, occupant classification for airbag suppression, and gaze detection that gates an ADAS handover are typically safety-relevant and carry an ASIL. Gesture control for infotainment and comfort personalization are usually QM because no safety goal depends on them. The actual assignment is always program-specific and comes from the HARA, not from a generic table — two functions on the same backbone can land at different integrity levels because their failures feed different hazards.

How does the ASIL assigned to a driver-state monitor set how deep its evidence surface in the validation pack must go?

A higher ASIL means a broader and deeper evidence surface, not simply more test repetitions. It demands more explicit operational-design-domain coverage — lighting, occlusion, occupant diversity, eyewear, head pose — stronger fault-detection requirements, and tighter traceability from each safety expectation to the test that produced the supporting result. A drowsiness monitor at ASIL B carries a demonstrably deeper evidence obligation than a QM gesture feature.

How do we avoid documenting every in-cabin function at uniform depth when their integrity levels differ?

Structure the validation pack by function rather than by module, and let each function’s evidence depth track its assigned ASIL. Enumerate functions individually, state each one’s integrity level at the top of its section, scale ODD coverage to that level, and make the depth difference visible to a reviewer. Uniform depth backfires either way: shallow leaves safety-relevant monitors thin where reviewers look hardest, deep burns effort characterizing comfort features nobody’s risk model points at.

How do we trace an ASIL expectation for an in-cabin function to the specific test that produced the supporting evidence?

For each ASIL-carrying function, the pack must show an explicit link from the integrity expectation to the test case that demonstrates it — the ODD conditions covered, the performance under cabin-specific degradations, and the fault behaviour when input is unusable. That traceability lets a reviewer confirm the evidence actually backs the safety claim rather than just asserting it. Making the mapping legible is itself part of the evidence, because it shows the team understood which functions are safety-relevant.

Where does an in-cabin sensing function’s ASIL originate before it reaches the perception team, via HARA and the system spec?

It originates in the hazard analysis and risk assessment (HARA), which identifies hazards and assigns safety goals. The functional-safety concept allocates those goals to functions and derives their ASILs, and the system specification then hands the perception team a function with an integrity level already attached. The perception team’s job is not to decide how safe a function must be but to produce evidence proportionate to a classification made upstream.

How should the validation pack be structured when in-cabin sensing mixes high-integrity and low-integrity functions in one perception stack?

Structure it by function, with each function’s ASIL stated explicitly and its evidence scaled to that level: full cabin-condition coverage matrices for safety-relevant driver-state monitors, functional test suites for QM conveniences. Trace every safety expectation to a test, and make the depth difference visible so a reviewer can see why one function’s evidence goes deeper than another’s. Critically, any shared component inherits the integrity demand of the most safety-relevant function that depends on it — you cannot document a shared driver-facing model to QM depth just because one of its uses is a comfort feature.

The question worth carrying out of this is not whether your in-cabin model is accurate. It is whether, for each function it serves, the evidence goes exactly as deep as that function’s inherited ASIL demands — no shallower where a reviewer’s risk attention lands, no deeper where nobody asked. That per-function mapping is the difference between a pack that clears review and one that gets challenged on its highest-consequence surfaces.