Safety Monitor & Voter ICs in ADAS Safety Architecture
← Back to: ADAS / Autonomous Driving
When I work on ADAS, brake-by-wire or steer-by-wire platforms, I cannot rely only on the MCU watchdog. I need a separate fault judge to check whether both safety channels behave consistently.
That is why this page focuses on dual-channel compare, window watchdog and fault voting logic — and how they translate into real design choices and BOM fields.
What These Safety Monitor & Voter ICs Actually Do
A safety monitor or voter IC works as an independent referee between the Safety MCU / SoC and the power actuation block. Once any inconsistency is detected, it forces the system into a safe state.
It is not a power-sequencing PMIC — that belongs to the Safety PMIC page. It is not responsible for secure boot — that is part of the Safety Island / HSM topic.
Typical ADAS cases include:
- Steer-by-wire ECU
- Brake-by-wire / EPB systems
- Battery disconnect / BDU safety control
Where They Sit in an ADAS Safety Architecture
Two kinds of inputs reach the safety monitor and voter IC:
- Dual sensor inputs – pedal, torque or position from redundant channels.
- Safety MCU heartbeat – a safety task must be triggered within a time window.
The voter IC may be placed inside the ECU, close to the actuator, or next to the Safety PMIC — each position carries different benefits and trade-offs.
A comparison for system-level decision making:
- Near sensor → lower latency, but more EMI risk.
- Near actuator → clearer safety path, but less diagnostic coverage.
- Near PMIC → stronger safe-state trigger, but dependent on MCU-to-voter timing.
Dual-Channel Consistency Compare
To prevent unsafe steering, braking or torque control, both redundant channels must show consistent signals. A safety monitor or voter IC turns this idea into measurable parameters instead of a vague concept of “comparing two signals”.
Typical comparison targets include dual sensors (pedal, torque, angle) and dual control paths (primary ECU vs backup ECU). Once the signal gap leaves the valid window, the IC outputs a dedicated fault line or safe-state request.
Key Design Questions
- How large is the allowed error window (%FS, mV, or ADC counts)?
- Is debounce or hysteresis required to reduce mis-triggering?
- How should the system react when one channel is stuck at zero or full-scale?
These questions can be translated into real datasheet parameters and BOM fields from a Safety Monitor & Voter IC:
| Design Issue | Voter / IC Role | BOM / RFQ Field |
|---|---|---|
| Allowed signal error window | Comparator + threshold + hysteresis | window = ±3%FS |
| Handling “stuck high/low” faults | Detect deviation beyond limits → trigger fault | fault detect: low & high |
| Testing channel consistency | Diagnostic mode for forced offset | diag_mode = yes |
Window Watchdog vs Simple Watchdog
A simple watchdog only checks whether the system “feeds the dog” periodically. However in ADAS tasks, a steering or braking loop may run too fast or too slowly and still keep feeding the watchdog — this leads to a dangerous false OK.
A window watchdog requires the safety task to occur inside a legal time window. Feeding too early or too late is recognized as a fault, enabling much deeper diagnostic coverage.
When located inside a Safety Monitor & Voter IC, the watchdog runs independently from the MCU and can output a direct safe-state signal to the PMIC or actuator.
Fault Voting & Arbitration
Once I have redundant channels, I still need to decide how they vote. A safety monitor or voter IC turns abstract 1oo2 / 2oo2 / 2oo3 rules into hard-wired logic with a clean safe / fault output. For an ASIL-targeted ADAS ECU, this is often easier to justify in the safety case than a pure software or FPGA-only solution.
In practice I choose the voting mode based on safety level, availability and architecture: 1oo2 keeps the system running more often, 2oo2 favors safety, and 2oo3 gives me a compromise that many brake-by-wire and L2+/L3 systems rely on.
How 1oo2 / 2oo2 / 2oo3 map into real projects
I tend to think about each scheme like this:
- 1oo2 (one out of two): if either channel is OK, the voter reports OK. Availability is high but safety is weak, so I only use it in QM / ASIL-A style cases, for example a basic contactor command that still has mechanical fail-safe and limp-home options.
- 2oo2 (two out of two): both channels must agree to be considered OK. Safety is high but availability is lower. This fits ASIL-B/C steering torque sensing or dual-position sensors in body and chassis control, where a false “go” is much worse than a safe shutdown.
- 2oo3 (two out of three): any two out of three channels must agree. This is the typical choice for ASIL-D brake-by-wire and L2+/L3 domain controllers. It lets one channel fail or drift without forcing an immediate system shutdown.
When I plan a new ADAS platform, I look at the ASIL target and pick my voting mode accordingly:
| Voting Type | Availability | Safety | Typical ASIL | Where I use it |
|---|---|---|---|---|
| 1oo2 | High | Low | QM / A | Entry BDU / simple contactor commands with mechanical fail-safe |
| 2oo2 | Medium | High | B / C | Steering torque sensors, dual throttle, safety limit switches |
| 2oo3 | Balanced | Highest | D | Brake-by-wire, high-end ADAS domain controllers, critical BDU |
A dedicated voter IC gives me baked-in logic for these schemes, plus diagnostics. Some devices let me program thresholds, vote modes and whether a single channel can force an immediate fault. That makes it easier to argue about diagnostic coverage and FIT rates when I build the ISO 26262 safety case.
In steer-by-wire and brake-by-wire projects, I tend to reserve 2oo3 voting for the highest impact functions. For secondary paths like contactors or pump control, I sometimes accept 2oo2 or even 1oo2, but only after checking the failure effects and whether mechanical fail-safes still exist.
How Safety Monitor & Voter ICs Interact with Safety PMIC & SoCs
A safety monitor or voter IC does not shut down my ECU by itself. Its job is to make a clear judgement: are the channels consistent and on time, or not? Once that decision is made, the output must be routed to the right block in the safety architecture.
I usually think about three roles in the chain:
- Safety Monitor / Voter IC – checks sensor and loop consistency, evaluates window watchdog, and drives one or more SAFE / FAULT pins. Some devices also expose SPI or SENT diagnostics.
- Safety PMIC – enforces the reaction: power-down, reset, limp-home voltage rails or actuator de-energization. It monitors its own rails and other discrete safety inputs.
- Safety MCU / HSM / SoC – handles software-level diagnostics, secure boot, key storage and log collection. It interprets fault reasons and coordinates recovery strategies, but should not be the only path from voter decision to safe state in an ASIL-D system.
For high-end ADAS ECUs, I prefer a direct hardware path from the voter IC to the Safety PMIC and actuators: if the voter reports a critical fault, the PMIC can enter a safe state even when the MCU or SoC is locked up. In parallel, a diagnostic line or SPI interface lets the ECU log what happened for service and functional safety evidence.
More details on rail sequencing and power domain behavior live in my Safety PMIC for ADAS Compute page, and the secure boot and key handling aspects are covered in the Safety Island / HSM topic. Here I focus on how the safety monitor and voter IC hands off its judgement to both the hardware and software sides of the system.
Key Selection Parameters for Safety Monitor & Voter ICs
When I plan to use a Safety Monitor & Voter IC, I do not start from the datasheet. I start from my safety concept and translate it into a short checklist that I can put directly into an RFQ or BOM. That way, suppliers understand I am asking for a real safety voter, not just a generic comparator or watchdog.
The fields below are the ones I normally lock down before I even ask for samples: channel count and voting modes, window watchdog range, input type and interface, diagnostics and safety package, plus the usual supply, temperature and package details.
Practical checklist I keep in my RFQ
| BOM / RFQ Field | Example Value | How I use it |
|---|---|---|
| channel_count | 3 channels | Match dual or triple sensors and leave room for a future 2oo3 upgrade. |
| voting_modes | 2oo2 + 2oo3, 1oo2 optional | Decide whether the same IC can support both entry and high-end ADAS variants. |
| wd_window_range | 5 ms – 50 ms, 0.5 ms steps | Check if my 10 ms safety task can sit comfortably inside the watchdog window. |
| input_type | analog + digital | Decide whether I compare raw analog signals or digital codes from ADC / SENT. |
| analog_input_range | 0 – 5 V, diff capable | Verify that sensor output and wiring concept fit the voter IC front-end. |
| diag_interface | SPI + FAIL pin | Connect hardware SAFE / FAULT pins to the PMIC and logs to the MCU or SoC. |
| asil_capability | ASIL D capable, safety package | Make sure FMEDA, safety manual and FIT data are available for my safety case. |
| fit_rate | < 10 FIT | Check whether the device fits my overall PMHF target on the ECU level. |
| supply_voltage | 3.3 V and 5 V | Align with existing rails from the Safety PMIC to avoid adding a new supply. |
| temp_range | −40 °C to 150 °C | Confirm that the device survives worst-case under-hood placement. |
| package | TSSOP-16 / QFN-24 | Plan footprint and dual-source strategy with compatible pinouts. |
I re-use this checklist across projects. For each new ADAS ECU I only tweak a few entries, instead of starting device selection from zero every time.
Typical Use Cases & Application Hooks
A Safety Monitor & Voter IC is not only a building block on a block diagram. It anchors specific ADAS functions where I need hard, independent decisions about whether a channel set is still trustworthy. I map it explicitly into my ECU list so each team knows where voting happens and who owns the safe-state reaction.
Brake-by-wire / EPB ECU
In brake-by-wire and advanced EPB projects, I route multi-channel brake pedal or pressure sensors through a 2oo2 or 2oo3 voter IC. The SAFE / FAULT output goes straight to the Safety PMIC and contactor or valve drivers, while a diagnostic line or SPI status goes to the Safety MCU for logging and DTC handling.
Steer-by-wire ECU
For steer-by-wire, dual or triple torque and angle sensors feed the voter. The IC checks consistency between channels and safety tasks; a fault request can force the PMIC to remove assist, enter a limp curve or trigger a controlled handover, while the MCU or SoC records which channel misbehaved.
ADAS Domain Controller Safety Path
In an ADAS domain controller I often have two or three compute paths that each produce a “safe command” signal. A dedicated voter IC performs the last hardware-level 2oo2 or 2oo3 decision before the command reaches the Safety PMIC or high-voltage drivers, while exposing a diagnostic register so the SoC can see why a path was rejected.
Battery Disconnect Unit / High-Voltage Contactors
In a BDU or high-voltage junction box, I may combine redundant commands and fault signals from current sensing, insulation monitoring and HVIL logic. The voter IC ensures that a contactor is only held closed when the relevant channels agree; its FAULT pin lets the Safety PMIC or a dedicated gate driver open the path within the required reaction time.
Redundant Power Steering Pump or Brake Pump Control
For redundant steering or brake pumps, I use voter ICs to arbitrate between primary and backup control paths. Depending on the safety analysis, I may run them in 1oo2 mode for high availability or in 2oo2 mode for stricter safety, always with a clear SAFE / FAULT output that the Safety PMIC and ECU software can both act on.
BOM & Procurement Notes for Safety Monitor & Voter ICs
When I send an RFQ for a Safety Monitor & Voter IC, I no longer write “watchdog IC” or “redundant safety chip”. That wording almost always brings back generic reset supervisors or simple watchdogs. Instead, I describe the key functions and safety targets explicitly, so suppliers understand that I need fault voting + window watchdog + diagnostics, not just a timer.
The table below is the BOM-style checklist I keep on my side. I adjust the example values for each project, but the field names stay almost the same. This keeps discussions with suppliers focused and avoids multiple rounds of “this is not the safety voter I asked for”.
| BOM / RFQ Field | Example Value | How I expect suppliers to respond |
|---|---|---|
| safety_voter_logic | Native 2oo3 + 2oo2 voting (no MCU-only voting) | Confirm that the device has built-in safety voting, not just dual inputs or a simple comparator. |
| channel_count | 3 channels (A/B/C) with independent inputs | Match multi-channel pedal, torque or pressure sensors and leave room for 2oo3 architectures. |
| watchdog_type | Window watchdog (early + late fault detection) | Filter out simple watchdog devices that cannot detect tasks running too fast or too slowly. |
| watchdog_window_range | 5 ms – 50 ms, resolution ≤ 1 ms | Ensure the device can supervise a 10 ms safety task with enough margin and tuning granularity. |
| input_types_supported | Analog (0–5 V) and digital codes (SPI / SENT) | Align the voter IC with my existing sensor front-ends and wiring concept (voltage, current or coded signals). |
| analog_input_range | 0–5 V, differential capable, programmable thresholds | Check that pedal, torque or pressure sensor outputs fit directly into the comparator range. |
| diag_interface | SPI (with status registers) + FAIL / SAFE pins | Guarantee a hardware SAFE / FAULT path to the Safety PMIC and a diagnostic path to the Safety MCU / SoC. |
| asil_capability | ASIL D capable, with safety manual and FMEDA | Require a full safety package, not just a marketing claim of “ASIL-ready” in the brochure. |
| fit_rate_target | Device FIT ≤ 10 FIT over mission profile | Check if the device can fit into my total PMHF budget for the steering, braking or ADAS ECU. |
| safe_fault_pins | Open-drain, active-low SAFE / FAULT outputs | Make sure the outputs can wire-OR with other safety sources into the Safety PMIC or actuator drivers. |
| supply_voltage_options | 3.3 V and 5 V compatible | Avoid adding a dedicated regulator rail just for the voter IC, reuse existing PMIC outputs instead. |
| temp_range_and_grade | −40 °C to 150 °C, AEC-Q100 Grade 0/1 | Confirm the device can be placed under the hood or near hot actuators without derating surprises. |
| package_preference | QFN-24 or TSSOP-16 with compatible pinouts | Plan layout and dual-source strategy; prefer families where pin-to-pin compatible devices exist. |
I send these fields as part of my RFQ so that the first round of proposals is already filtered to genuine Safety Monitor & Voter ICs. It saves time on both sides and reduces the risk that a simple supervisor IC sneaks into an ADAS safety design.
Request a Quote
FAQs: Safety Monitor & Voter ICs in My ADAS Projects
When I plan steering, braking or ADAS ECUs, I keep these twelve questions as a quick sanity check. They remind me when a dedicated Safety Monitor & Voter IC is justified, how to size thresholds and watchdogs, and how to talk to suppliers without being offered a generic watchdog instead.
1. When do I really need to move from a simple MCU watchdog to a dedicated Safety Monitor & Voter IC in an ADAS project?
I move from a simple MCU watchdog to a dedicated Safety Monitor & Voter IC when my safety concept requires an independent hardware path to safe state, not just software supervision. Once I target ASIL-C or ASIL-D steering, braking or BDU functions, the combination of window watchdog, voting logic and separate outputs becomes hard to justify without a dedicated IC.
2. Is FPGA-based voting good enough for my safety concept, and when is it safer or easier to use a dedicated Safety Monitor & Voter IC instead?
FPGA-based voting can be acceptable for lower ASIL projects, but I have to prove the same diagnostic coverage and independence as a safety-rated voter IC. For ASIL-D paths, or when I want a pre-qualified safety manual, FMEDA and known FIT rate, I find it safer and easier to use a dedicated Safety Monitor & Voter IC instead of a pure FPGA solution.
3. How do I decide whether dual-channel or full 2oo3 voting is the right choice for my steering, braking or BDU application?
I start from the safety goal and availability requirement. For ASIL-B or C steering torque or throttle sensing, 2oo2 dual-channel voting is often enough. For ASIL-D brake-by-wire, ADAS domain controllers or critical BDUs, I prefer 2oo3 so one channel can fail without immediately losing function. If future upgrades are likely, I plan 3 channels even in the first design.
4. How should I set the consistency threshold and error window between two redundant sensor channels so that I catch faults without creating noise-driven false trips?
I translate my sensor accuracy and noise budget into a percentage of full scale or ADC counts, then add a small margin for temperature drift and layout mismatch. On top of that I use hysteresis or simple time filtering, so short spikes do not trip the voter. The final window is tight enough to catch real faults, but wide enough to ignore normal jitter.
5. How do I choose the minimum, maximum and resolution of my window watchdog so it properly supervises a 10 ms or 20 ms safety task?
I start from the nominal safety task period, for example 10 milliseconds, and define an early and late boundary that reflect my worst case timing jitter and execution time. Then I check the voter IC’s programmable window range and step size. If I cannot center a realistic window around my task timing, that device is not a good match for this ECU.
6. What is the best way to handle a sensor channel that slowly drifts toward the edge of the “legal” range without immediately shutting down the system?
For slow drift I prefer a graded reaction. I use a tighter internal diagnostic window to flag the channel as suspect while the main voting window still passes. The Safety MCU can log the trend, raise warnings and schedule service, while the Safety Monitor & Voter IC stays in control of the final safe or fault decision for hard out-of-range conditions.
7. Should the fault output from my Safety Monitor & Voter IC go directly to the Safety PMIC, to the Safety MCU, or to both paths in parallel?
In ASIL-D projects I almost always route the primary FAULT output directly to the Safety PMIC or actuator driver so a safe state does not depend on software. In parallel I give the Safety MCU or SoC either a mirrored fault pin or a diagnostic interface, so the software can record what happened and decide how or whether to restart.
8. For an ADAS ECU, how do I choose between SENT, SPI and simple diagnostic pins as the main interface to my Safety Monitor & Voter IC?
I choose the interface based on how much diagnostic detail I really need and how many pins I can afford. For rich error reporting and configuration I prefer SPI. For simple pass or fail information I may use dedicated diagnostic pins. SENT can be useful when I already have a SENT infrastructure and I want a digital, checksum protected status channel.
9. How can I use the diagnostic pins or interface of a Safety Monitor & Voter IC to support end-of-line tests and in-field maintenance checks?
During end-of-line test I use the diagnostic interface or pins to inject known mismatches, force window watchdog violations and confirm that the FAULT and SAFE outputs behave as specified. In the field, I let the Safety MCU periodically read status bits or counters, so I can detect intermittent faults, log them with timestamps and support predictive maintenance instead of only reacting to hard failures.
10. What are the typical differences in FIT rate and diagnostic coverage that I should expect from a Safety Monitor & Voter IC in an ASIL-B project versus an ASIL-D project?
For ASIL-B I may accept a higher FIT rate and simpler diagnostic concept, as long as the system PMHF target is met. For ASIL-D steering, braking or ADAS domain controllers I expect a much lower FIT figure, a full safety package and detailed coverage information, including random hardware failure, latent fault handling and recommended diagnostic measures for the whole safety path.
11. After the system has entered a safe state, what reset and restart strategy should I plan around the Safety Monitor & Voter IC, the Safety PMIC and the Safety MCU?
I define in my safety concept whether a given fault allows an automatic restart or requires manual intervention. The Safety PMIC handles power-down and reset, while the Safety MCU decides if conditions are safe to request a restart. The Safety Monitor & Voter IC must support a clean reset sequence so it does not hide latched faults or restart in an undefined state.
12. When I talk to suppliers, what keywords and requirements should I use to clearly describe that I need a true Safety Monitor & Voter IC instead of a generic watchdog or supervisor IC?
In RFQs and emails I explicitly ask for a Safety Monitor & Voter IC with native 2oo2 or 2oo3 logic, window watchdog, ASIL-capable safety package, documented FIT rate and hardware SAFE / FAULT outputs to a Safety PMIC. I also mention my channel count, watchdog window range and diagnostic interface preference, so suppliers do not answer with simple supervisors or basic watchdog timers.
