What an OMS really solves (not just “a camera in the cabin”)

I do not add an occupant monitoring system just to have another camera in the cabin. I use OMS to cover the safety gaps that seat weight sensors, belt switches and simple presence inputs cannot see when people sit off-position, lean, sleep or move during real driving.

In my projects the OMS helps me detect children left behind after ignition-off, misaligned passengers that confuse traditional seat sensors, and sleeping or reclined occupants that need different airbag and restraint strategies. It turns raw cabin images into concrete occupancy and posture decisions instead of just giving me another video feed.

I treat DMS and OMS as two separate roles: DMS watches the driver’s face, eyes and attention, while OMS watches everyone in the cabin. OMS looks at presence, seat position and posture so I can support child presence functions, hot-car protection and modern safety ratings without overloading the driver-only system.

• Confirm who is really occupying each seat before airbag and restraint decisions.
• Detect children or pets left behind after the vehicle is locked or powered down.
• Track posture and recline that simple weight sensors would misinterpret.
• Support hot-car and child-presence behaviours required by new safety targets.
• Provide cabin-wide context that complements, not replaces, the driver-only DMS.

System architecture & signal chain

When I design an OMS, I always think of the signal chain from light to vehicle network: the ToF or IR array captures depth and intensity, the VCSEL driver sends and monitors the light pulses, the ISP converts frames into depth maps and human-pose information, and a low-power MCU turns those results into simple safety decisions and messages on the bus.

The hardware partition lets me keep optics and high-speed pulses near the sensor, while the MCU focuses on power modes and communication. In practice I choose the sensor and AFE for coverage and robustness, the VCSEL driver for eye-safety and current capability, the ISP for latency and pose quality, and the MCU for sleep current and interface options.

• ToF / IR array and AFE: resolution, FOV, automotive grade and interface robustness.
• VCSEL driver: peak current, pulse control and built-in eye-safety diagnostics.
• Depth & pose ISP: end-to-end latency, accuracy and support for OMS safety use cases.
• Low-power MCU: sleep-mode current budget, wake-up strategy and LIN/CAN/Ethernet support.

Optics, FOV and coverage planning

I start OMS optics planning from the cabin geometry, not from the sensor datasheet. For a 5-seat sedan I mainly need reliable coverage of the front and second row, while a 7-seat SUV forces me to think about third-row distance, roof height and how much the rear glass and pillars create blind spots that a single FOV cannot see.

Horizontal and vertical FOV, together with sensor resolution, set how many pixels I get per occupant and how much depth precision I can achieve at the front versus the rear seats. A wider FOV helps to cover more seats but also spreads the available light and pixel density, so I have to think about the trade-offs before locking an optics and ToF / IR array combination.

I then size the VCSEL and its driver from the coverage targets: the furthest seat distance, the materials and reflections in the cabin and how much margin I need for sunlight and tinted glass. The goal is not a perfect ray-trace model inside this page, but a clear set of ranges that I can use in supplier discussions and BOM planning.

• I choose sensor resolution and FOV based on how many rows and seats I must cover in each vehicle platform.
• I check whether the vertical FOV can handle child seats, adults and reclined passengers in the same cabin.
• I plan depth precision differently for front and rear seats, using realistic occupant distance ranges.
• I size VCSEL driver peak current and margins from the longest required distance and cabin reflectivity.
• I revisit FOV and optics when moving from a 5-seat sedan to a 7-seat SUV, to avoid hidden blind spots.

IC roles and partitioning across sensor, ISP and MCU

I try not to push every OMS function into a single SoC. Sensor and AFE are good at reading pixels and handling analog details, the VCSEL driver is good at shaping light pulses and running eye-safety checks, the ISP is good at turning frames into depth and pose results, and the low-power MCU is good at power states, decision logic and vehicle communication.

This partitioning also helps me reuse OMS hardware across multiple vehicle lines and ADAS domain controllers. When I keep depth reconstruction and pose extraction near the sensor in a dedicated ISP, I can feed a stable set of outputs to whichever MCU or compute platform the project uses, instead of rewriting algorithms for every new SoC.

I usually pick a dedicated ISP when I need predictable depth and pose latency even if the domain controller is busy, and when I want to reuse the same OMS module across multiple platforms. I am more willing to accept an ISP inside a sensor module in lower-end projects where I only need basic occupancy results and do not expect to update algorithms frequently.

• I use a dedicated ISP when depth and pose quality must stay stable across different ADAS compute platforms.
• I accept an ISP inside the sensor module when I just need simple occupancy outputs for cost-sensitive projects.

Low-power strategy and wake-up design

I treat OMS as a permanent load on the vehicle electrical system, so I define clear power states before I ever talk to suppliers. For each state I want to know which parts of the sensor, VCSEL, ISP and MCU are actually powered and what current ballpark I am committing to, from full ADAS driving to long-term parking and shipping.

In full ADAS mode I allow milliamp-level current for best quality and lowest latency. In short idle cabin monitoring I slow the frame rate and VCSEL duty cycle. In deep parking and hot-car monitoring I rely on a low-power MCU and short wake-up scans, and in shipping or transport mode I want the OMS to be effectively off or as close to off as the platform allows.

• I map OMS power modes to real vehicle states: ADAS on, short idle, deep parking and shipping.
• I ask suppliers for realistic current ranges per mode instead of a single “typical” number.
• I expect a clear story for how the MCU wakes the sensor, VCSEL and ISP on events or timers.
• I design hot-car monitoring so most of the time only the MCU sits in a few tens of microamps.
• I treat shipping mode as a first-class requirement, not an afterthought handled by the plant.

Safety, diagnostics and automotive constraints

In most projects OMS ends up in an ASIL B or C safety path because child presence and cabin monitoring are not “nice to have” features. I do not try to run a full FMEDA on this page, but I do expect clear hardware hooks for safety: eye-safety diagnostics on the VCSEL, link health between sensor and ISP, and watchdog and fault routing from the MCU into the ADAS safety path.

My goal is to know exactly which pins, status bits and heartbeat signals I can rely on at the hardware level. With those in place, system-level safety analysis and software architecture can sit on top, instead of trying to retrofit diagnostics into a camera module that was never designed for occupant safety.

Eye-safety and VCSEL diagnostics

I treat the VCSEL driver as both a light source and a safety risk. I want built-in protection for over-current, open and short faults, and a way to read back what the driver thinks is happening on the light engine. I also need a safe way to run self-tests without overheating the device or creating false alarms in the cabin.

• What over-current, open and short protections does the VCSEL driver implement by design?
• Can I read actual VCSEL or LED current and fault states via pins or SPI / I²C registers?
• What happens on a permanent fault: does the driver latch off, and how do I clear it safely?
• Is there a recommended self-test mode that I can run without overheating the device?

Sensor / ISP link health

I do not want the MCU to trust depth or pose results from a sensor link that is silently failing. For OMS I look for link health indicators such as frame counters, CRC flags, error counters and clear status bits that tell me when the image stream is stuck, corrupted or out of sync, not just when it has gone completely silent.

• How can I detect that the sensor / ISP link is stuck or corrupted rather than simply idle?
• Do you provide frame counters, CRC flags or error counters that the MCU can log and react to?
• Which status bits or pins indicate link loss, degraded quality or internal ISP failures?
• Is there a recommended heartbeat or watchdog scheme for the depth / pose stream?

MCU watchdog and safety path integration

The OMS MCU is where local safety decisions are made and forwarded. I want robust watchdog support, clear fault separation between non-critical diagnostics and child-presence related alarms, and a simple way to route OMS faults into the ADAS safety island or safety PMIC so the system can take a safe action within the required fault reaction time.

• What watchdog and self-test options does the MCU or OMS platform provide for this safety path?
• How do I route OMS faults into the ADAS safety island or safety PMIC (pins, buses, protocols)?
• Which OMS faults must trigger a safe state, and how quickly can I guarantee that reaction?
• Can I separate non-critical diagnostics from child-presence related faults for different handling?

Anti-flicker: dealing with cabin and headlamp flicker

In real vehicles I rarely have a perfectly steady light field. Cabin ambient LEDs, cluster backlight, center displays and exterior headlamps all run with mains-related flicker and PWM dimming. To a DMS or OMS camera this looks like a time-varying signal, so the eye and face region can jump between very bright and very dark from frame to frame even when the driver is not moving at all.

Anti-flicker is simply how I control the exposure window against these flicker cycles. I want the sensor and ISP to lock to mains or lamp frequencies where possible, restrict exposure times to safe ranges, and use IR illumination timing to cancel as much background flicker as I can. If I describe this clearly in the RFQ, I get much better answers than just asking for “good DMS performance under LED lighting”.

• I list cabin and exterior flicker sources up front: ambient LEDs, clusters, screens, headlamps and signs.
• I ask what anti-flicker modes the sensor / ISP support for 50/60 Hz and common PWM lamp frequencies.
• I check how exposure time and start phase can be constrained to avoid worst-case flicker bands.
• I confirm whether IR illumination can be tightly synchronised with exposure for differential capture.
• I document anti-flicker as a concrete requirement in the RFQ, not a vague “robust under LED flicker”.

Mechanical and thermal constraints feeding IC choices

I do not treat OMS or DMS as “just a camera and an algorithm”. Mounting position, harness routing and hot spots around the windshield all feed back into how I choose the sensor, AFE and LED / VCSEL driver. A module on the steering column, behind the cluster or at the mirror base sees very different occlusion patterns, cable lengths and EMC constraints.

Summer sun can push the module housing far above cabin air temperature, so I also care about temperature grade and derating. That changes whether I prefer a highly integrated front-end or a driver with external MOSFETs that I can bolt to a better heatsink. I want these mechanical and thermal facts on the table before I freeze the BOM, not after the first hot-weather test drive.

• I map DMS / OMS mounting options and harness length before finalising the front-end topology.
• I estimate module internal temperature under worst-case sun load, not just ambient cabin temperature.
• I choose integration level and package style with real heat paths and space limits in mind.
• I prefer drivers and sensors with clear temperature grades and derating behaviour at high junction temps.
• I revisit EMC risk when LED or VCSEL current loops become long due to mechanical constraints.

Brand-neutral IC mapping for OMS front-end

When I plan an OMS front-end I do not start from part numbers, I start from blocks and IC categories. First I split the design into ToF / IR array, VCSEL driver, depth / pose ISP and a low-power MCU. Only then do I look at which automotive families each vendor offers in those categories, so I can compare options without locking myself into a single brand too early.

The table below is deliberately vendor-agnostic. I only list typical IC categories and the vendor families I usually investigate. Detailed SoC or ADAS compute comparisons sit in my ADAS compute hub, not on this OMS page.

I keep this mapping brand-neutral on purpose. It reminds me which vendor families to scan for OMS front-end ICs, while leaving full ADAS compute and SoC decisions to a separate, dedicated hub.

BOM and procurement notes for OMS

This section is written from my RFQ point of view. Instead of sending suppliers a vague “OMS spec”, I break the requirements into clear fields and describe each one in the same language I use in e-mails and BOM notes. That way the vendor understands what I really need from the sensor, VCSEL driver, ISP and MCU, and I can compare responses across different brands.

I treat these bullets as my OMS RFQ checklist. I rarely send them word for word, but I keep the structure: field name first, then a short sentence that explains how I state the requirement and what details I expect the supplier to fill in.

• Field – IR array / ToF sensor: I describe the IR array as resolution, FOV, automotive grade and interface. For example I might write: “640×480 ToF or IR array, ≥90° horizontal FOV, AEC-Q100 Grade 1, CSI-2 output, optimised for full-cabin presence and posture.”
• Field – VCSEL / IR driver: I state the driver in terms of peak current, pulse width range and eye-safety diagnostics. For example: “Automotive VCSEL driver up to XX A peak, YY–ZZ ns pulse width range, integrated eye-safety monitor, fault indication pin and SPI/I²C status registers.”
• Field – Depth / pose ISP: I specify the ISP by the depth output type, latency and function scope. A typical line is: “Depth / pose ISP that outputs per-seat occupancy and basic pose / child presence flags with ≤XX ms pipeline latency, exported over CSI-2 or Ethernet.”
• Field – OMS MCU: I describe the MCU by target sleep current, memory size and interfaces. For example: “Automotive MCU with deep-sleep current ≤XX µA including RTC, at least YY KB Flash and ZZ KB RAM, and enough SPI/I²C, CAN/LIN or Ethernet to host the OMS state machine and diagnostics.”
• Field – Safety and diagnostics: I make the target safety role explicit. I usually write something like: “OMS is expected to participate in an ASIL B/C child presence path; I need documented diagnostics, watchdog support, error pins or status flags, and safety manual / FMEDA information where available.”
• Field – Power modes and currents: I include a short table of OMS power modes (ADAS On, Cabin monitor, Parking monitor, Shipping) and ask for realistic current figures and active blocks per mode, instead of a single “typical current” number.
• Field – Interfaces and integration constraints: I summarise which blocks must be on the same PCB and which can be remote, and I list required interfaces and voltage domains. That helps the supplier tell me whether their sensor, ISP and driver families fit my OMS module partitioning.

When I keep these fields consistent across projects, it becomes much easier to send structured RFQs, compare quotes and make sure every OMS design I build has the same level of clarity on sensing, power and safety.

Recommended topics you might also need

• Driver Monitoring System (DMS)
• Stereo Sync & Depth
• Environment & Road-Condition Fusion Hub
• HMI Actuators for ADAS Alerts

FAQs: how I plan and source an OMS front-end

These twelve questions are how I sanity check my own OMS plans before I freeze the BOM or send an RFQ. The answers are written from my point of view so I can reuse them in project notes, supplier calls and search snippets without rewriting the story every time.