A synthetic data approach to DMS, OMS, and CPD validation that starts from the assessment logic, not a reading of it.
Table of Contents
Table of Contents
If you are twelve weeks from validation and your DMS, OMS, or CPD scenario taxonomy is still being debated in a shared document, you already know what the critical path looks like — and it is not model performance. It is data coverage, and whether you have time to close the gap before the timeline closes it for you.
The Anyverse INCABIN Scenario Library was built for exactly this moment. It eliminates the upstream taxonomy design work that consumes weeks before a single image is generated. A ready-to-use catalogue of pre-built scenarios covering DMS, OMS, and CPD validation requirements, structured around Euro NCAP 2026+ protocols, continuously updated as those protocols evolve, and accessible through a no-code web application that takes the scenario design burden off your team entirely.
The Coverage Problem Is a Workflow Problem, Not a Data Volume Problem
The instinctive response to a dataset coverage gap is to collect more data — more drives, more subjects, more recording sessions. But for teams working across DMS, OMS, and CPD simultaneously, the coverage problem is not a volume problem. It is a workflow problem, and it starts weeks before a single image is generated.
Here is where the time actually goes.
Before any data generation begins, someone has to define the scenario taxonomy: which parameters need to be covered, what ranges they span, and how variability is distributed across them. Across three concurrent Euro NCAP 2026+ frameworks, that means:
- DMS — translating assessment criteria into generatable parameters: eye closure thresholds, head pose deviation ranges, gaze direction windows, disengagement state definitions
- OMS — mapping seat occupancy classification, passenger state monitoring, seatbelt compliance, and living beings detection into a coherent parameter space
- CPD — defining child age ranges, seat configuration variables, and heatstroke detection conditions
Each domain requires its own protocol interpretation and cross-functional alignment between safety engineers and ML teams — often working from different documents, different assumptions, and different definitions of what “covered” actually means. That process routinely consumes two to three weeks per domain, compounding across DMS, OMS, and CPD before a single training image exists.
And it is fragile. The taxonomy your team spent weeks assembling is tied directly to the current version of the Euro NCAP protocol. When that protocol updates — and it does, on a rolling basis — the process does not continue from where it left off. It restarts.
That is the structural bottleneck the Anyverse INCABIN Scenario Library removes, by replacing the taxonomy design process with a scenario foundation built around the actual Euro NCAP assessment logic, not a reading of it.
The Anyverse INCABIN Scenario Library is Built Around the Assessment, Not Mapped Onto It
Most teams building a DMS, OMS, or CPD scenario taxonomy start from the same place: the publicly available Euro NCAP protocol documents. They read the assessment criteria, interpret the parameter definitions, make judgment calls where the language is ambiguous, and translate the result into a scenario structure their data pipeline can work with. It is a reasonable process. It is also a lossy one.
Protocol documents are written to define assessment outcomes, not to guide dataset design. The gap between what a document describes and what an assessment actually evaluates is real — and it is wide enough that teams who build their taxonomy from public documents alone are, in practice, reverse-engineering the assessment rather than preparing for it. The resulting scenario coverage reflects their interpretation of Euro NCAP, not Euro NCAP itself.
How is the Anyverse INCABIN Scenario Library built?
Anyverse is engaged in active research with Euro NCAP. The Anyverse INCABIN Scenario Library is built mirroring the assessment logic that Euro NCAP applies. The scenario parameters in the Scenario Library are not derived from a reading of the protocol. They reflect the actual test cases, parameter ranges, and edge conditions that matter under evaluation.
For your team, the practical consequence is significant. The weeks spent interpreting protocol documents, debating parameter boundaries, and aligning safety and ML teams around a shared taxonomy definition — that work is already done. You start from a scenario foundation that reflects the assessment, not one that approximates it.
What happens when the protocol updates mid-programme is where this distinction compounds further.
When Euro NCAP revises its parameters — as it is doing now, with mandatory CPD, cognitive distraction detection, and occupant posture recognition entering the 2026 scoring framework — a team working from a self-built taxonomy has to reinterpret the changes and rebuild the affected scenario structure, taking time the programme schedule rarely has.
The Anyverse INCABIN Scenario Library updates in lockstep with protocol revisions. When a new Euro NCAP document drops, the scenario foundation your team is working from reflects it — without a rebuild cycle, without a reinterpretation exercise, and without the risk of missing a parameter change that only becomes visible at pre-assessment.
For teams managing DMS, OMS, and CPD systems across multi-year vehicle programmes, this is not a convenience feature. It is a programme risk control.
What the Anyverse INCABIN Scenario Library Covers — DMS, OMS, CPD, and Beyond
The Library is not a generic scenario set. Every domain it covers reflects a specific validation challenge that in-cabin monitoring teams face under Euro NCAP 2026+ assessment conditions. Here is what that looks like in practice, domain by domain.
Driver Monitoring System (DMS)
Detecting driver state, attention, and engagement
DMS is the most mature of the three assessment frameworks — active since 2022 and now carrying significant weight in 2026 scoring. The failure mode most teams encounter is not architectural but distributional. A system that performs well on internal benchmarks regularly degrades under the demographic variation, low-light NIR conditions, and behavioural edge cases that Euro NCAP applies — precisely because those conditions were underrepresented in the training data. The Scenario Library covers the full DMS parameter space with systematic variability built in:
Scenario | What It Covers |
Drowsiness & microsleep | Progressive fatigue states, eye closure duration and frequency, and yawning behaviour |
Gaze deviation & distraction | Gaze direction windows, prolonged off-road attention, lizard and owl ocular movement modelling |
Driver disengagement | Hands-off-wheel detection, disengagement state classification |
Driver authentication | Identity verification across demographic variation |
Facial & postural variation | Expression variation, head and body pose diversity across driver profiles |
These constraints make it extremely difficult for OEMs and Tier-1s to validate systems before production, increasing compliance risk and slowing development cycles.
As the Euro NCAP 2029 protocols push systems to demonstrate reliability across extreme lighting conditions, diverse occupants, and complex behavioral scenarios, these data limitations become even more pronounced. Real-world collection simply cannot guarantee that every safety-critical situation will be captured often enough to train and validate AI models effectively.
Occupant Monitoring System (OMS)
Classifying occupants, objects, and living beings across the full cabin
OMS is where Euro NCAP 2026+ creates the most exposure for teams who scoped their programme against an earlier version of the standard. The assessment surface has expanded significantly — occupant posture recognition for smart restraint and airbag logic, living beings detection including pets, and object interference scenarios are now in scope in ways they were not two years ago. Teams that built their OMS taxonomy in 2023 may find their scenario coverage no longer maps cleanly to what 2026 actually evaluates. The following scenarios are structured around the expanded 2026+ scope, not the baseline most existing taxonomies were built against.
Scenario | What It Covers |
Seat occupancy & classification | Occupied vs unoccupied, passenger type, and position across all seating positions |
Seatbelt & headrest compliance | Correct and incorrect usage, force limiters, specific cabin and seat belt models, child seat harnesses |
Posture & gesture monitoring | Body position, movement, and gesture detection for smart restraint logic |
Pet detection | Dogs and cats in passenger and rear seats |
Diverse & inclusive characters | Full demographic variation across ethnicity, age, body morphology, and appearance |
Child Presence Detection (CPD)
Safety-critical detection of children across age, position, and risk scenarios
CPD carries a validation challenge that is fundamentally different in kind from DMS and OMS — not just in technical complexity, but in data availability.
The real-world data collection constraint for CPD is not an operational inconvenience. It is a structural barrier. Across Europe, the US, and China, the legal and ethical restrictions on collecting and processing image data of children make real-world CPD dataset development exceptionally difficult at scale. Synthetic data is not the preferred path for CPD — it is the primary viable one.
The Anyverse INCABIN Library covers the full CPD scenario space without those constraints:
Scenario | What It Covers |
Child modelling | Baby, toddler, and child variation across ages and ethnicities |
Heatstroke avoidance | Unattended child detection under thermal and time-based conditions, including detection under blankets and unconventional positions |
Child seat detection | Correctly and incorrectly fitted child seats, customisable placement across vehicle configurations |
Seatbelt misuse | Incorrect restraint use across child ages, seat types, and child seat harnesses |
Head, body & posture variation | Full postural diversity across child age ranges |
Coverage Without Uniformity Is Still a Gap — How Automated Variability Closes It
Having the right scenario categories in a catalog is necessary. It is not sufficient. A library that lists the correct DMS, OMS, and CPD scenarios but samples them unevenly will still produce datasets that are dense in common cases and thin at the edges — which is exactly where Euro NCAP validation pressure is highest. A drowsy driver in good lighting with an unobstructed face is well-represented in almost every dataset. A drowsy driver of a specific demographic, in high-contrast transitional lighting, with partial facial occlusion, at a precise head pose deviation angle, is not.
That gap does not show up in aggregate metrics. It shows up at pre-assessment.
The Anyverse INCABIN Library aligned with Euro NCAP 2026+ closes this gap through three interconnected mechanisms.
One Library, Any Cabin
Scenario coverage is only as useful as the environment it is generated in. A persistent challenge with synthetic data for in-cabin monitoring is sim-to-real transfer: data generated in a generic virtual cabin does not transfer cleanly to a system deployed in a specific vehicle with a specific sensor configuration. Before uniform coverage can mean anything, the environment enforcing that coverage has to reflect the one your system will actually operate in.
The Anyverse INCABIN Scenario Library addresses this directly. Every domain in the library operates on digital twins of real vehicle cabins — any manufacturer’s interior can be modelled, and any sensor configuration replicated, including rearview mirror, centre stack, or custom placement with multiple simultaneous cameras. The result is scenario coverage that is not generic: it reflects the exact cabin geometry and sensor setup your system will operate in, which is the condition under which sim-to-real transfer holds.
That specificity is the starting point. How Scenario Library enforces uniform coverage across those scenarios is what determines whether the dataset holds up under validation.
Physics-based rendering engine
Every scenario in the Library is rendered using a physics-based engine that simulates light transport, material interaction, and sensor behaviour according to physical laws. The output is not visually plausible data — it is sensor-accurate data. Pixel values reflect the actual radiance a real sensor would capture under those specific conditions. For a DMS system that needs to perform across NIR, RGB-IR, and radar modalities, this is the property that makes synthetic data valid for validation — not just useful for pre-training.
Generative AI enhancement
The physics-based pipeline is further enhanced by a generative AI layer that adds realism at the detail level — skin texture response to infrared illumination, material reflectivity variation, subtle environmental interactions that structured rendering alone does not capture. The result is data that transfers across sensor types and cabin configurations without the domain gap that limits purely synthetic approaches.
Together, these two capabilities enforce what manual curation cannot: uniform sampling across the full parameter space of every scenario in the Library. Each generation run produces tens of thousands of realistic images and sequences — not by generating volume for its own sake, but by systematically traversing the parameter space so that coverage is consistent by construction, not assumed by inspection.
These are the dimensions where dataset gaps most frequently determine pre-assessment outcomes. In practice, systematic variability across all of them means:
- Demographic diversity — occupant age, ethnicity, body morphology, and appearance attributes varied systematically across all scenarios, not selectively sampled
- Lighting states — from full daylight to low-light NIR conditions, including transitional and high-contrast scenarios that real-world collection consistently underrepresents
- Occlusion patterns — glasses, hats, head coverings, objects partially obscuring occupants, and sensor field-of-view edge cases
- Behavioural states — common, rare, and safety-critical, all sampled with the same coverage discipline
The practical implication is this: when your team opens the Anyverse Library and selects a scenario, the coverage discipline described above is already built in. What that looks like in practice is what we cover next.
What This Looks Like in Practice — From Requirement to Ready Dataset
Without the Anyverse INCABIN Scenario Library, closing a dataset coverage gap at pre-assessment looks like this: a safety engineer pulls the relevant Euro NCAP protocol document, identifies the parameter ranges that apply, and begins translating them into scenario definitions the ML team can work with. That triggers cross-functional alignment — what counts as “covered,” how variability should be distributed, and which demographic profiles are in scope. The alignment takes days. The scenario build takes longer. Two to three weeks pass before a targeted dataset is being generated, and the programme timeline absorbs the cost.
With the Scenario Library, the same task looks like this, with no protocol interpretation, no alignment cycle, and no upstream design work:
- Select the scenario — browse the pre-built catalogue for your target use case. The parameter boundaries are already defined around Euro NCAP 2026+ assessment logic; no protocol document required.
- Configure for your AI model — set the occupant demographics, lighting conditions, behavioural states, and cabin geometry relevant to your validation target. No cross-functional alignment meeting to define what “covered” means — that decision is already made.
- Review the distribution — confirm uniform coverage across the parameter space before generation begins, so gaps are visible before they cost you anything.
- Generate — the Library produces tens of thousands of sensor-accurate images and sequences automatically, traversing the full parameter space by construction.
- Export — the dataset arrives with pixel-perfect annotations, ready for direct integration into your ML pipeline. Day one, not week three.
The contrast at programme level is significant:
Without Anyverse INCABIN Scenario Library | With Anyverse INCABIN Scenario Library | |
Timeline | Weeks of upstream taxonomy work before generation begins | Scenario foundation in place from day one |
Pre-assessment | First contact with Euro NCAP scenarios happens in the test lab | Models trained against the full scenario space before live assessment |
Regulatory updates | Protocol revisions trigger dataset rebuilds mid-programme | Library updates in lockstep — no rebuild required |
Engineering focus | Split across protocol interpretation, taxonomy design, and model development | Directed entirely at model performance and validation outcomes |
The shift is not incremental. It is the difference between dataset coverage being a programme constraint and it being a solved problem before the programme clock starts.
The Structural Shift — and What to Do Next
The teams that reach pre-assessment with confidence are not the ones with the largest data budgets. They are the ones who solved the scenario coverage problem early enough that it never became a programme constraint.
That is the shift the Anyverse Library makes possible — from reactive dataset management, where coverage gaps are discovered at validation, to a scenario-first development approach where the full Euro NCAP 2026+ parameter space is covered before the first model is trained.
If your team is at or approaching the validation stage, the question is specific: does your current scenario coverage reflect what Euro NCAP 2026+ will actually test — across DMS, OMS, and CPD, under the parameter ranges that matter, with the demographic and environmental variability the assessment applies? If you are not certain, that uncertainty is the gap. And the Anyverse Scenario Library is the fastest way to close it.
Explore the Anyverse INCABIN Library — or if you are at the validation stage and want to map your current coverage against the Euro NCAP 2026+ framework, book a focused session with our team. We will show you where the gaps are before the assessment does.
