Hold-Up & Safe-State Power for ADAS and Safety Systems
← Back to: ADAS / Autonomous Driving
When my ADAS system suddenly loses power, I still want a short, predictable window to finish the most important tasks: park outputs, write the minimum evidence set and shut down cleanly. This hold-up and safe-state power block is where I plan that window, choose the right IC roles and verify that the behaviour really holds up on hardware.
Definition & Role of Hold-Up and Safe-State Power
When my ADAS compute or data logger loses its main supply, I still need a short window to finish critical work. Hold-up and safe-state power are the circuits that buy me those extra milliseconds so the system can die in a clean, explainable way instead of just dropping off the bus.
In practice, that window is usually between a few tens and a few hundreds of milliseconds. A simple MCU-only system might survive with 10–20 ms to park its outputs, while an ADAS logger or EDR often needs 100–300 ms to close files, flush indexes and record the last events before power really disappears.
During this short hold-up time I decide which blocks are allowed to stay alive: the safety state machine, the storage stack and the minimum networking needed to send a last status. High-power accelerators and non-critical HMI can shut down immediately so the limited energy in the supercap is spent where it actually matters.
For me, hold-up and safe-state power are essentially time management around a power fail: detect the collapse early, stretch the supply just long enough, and force the system into a final state that I can explain to a safety assessor and to my own logs.
Operating Principle: From Power-Fail Pin to Final Log Flush
Under normal conditions the PSU keeps my rails within spec and the supercap sits charged in the background. As the supply begins to collapse, a power-fail pin or supervisor comparator fires early and tells the rest of the system that the mains or battery can no longer be trusted.
At that moment the load automatically transitions onto the supercap hold-up path. Ideal-diode or OR-ing switches prevent backfeeding the failing supply while the supercap delivers current to the most important rails. From the software point of view, this is the start of a one-time countdown where every millisecond must be budgeted.
A dedicated safe-state controller or safety island then executes a compact state machine: freeze new work, log the minimum evidence set, park actuators and finally request shutdown. Only when that sequence is complete do I allow the remaining rails to decay and accept that the system is truly off.
Design Challenges & Pitfalls
On paper, hold-up and safe-state power look simple: I add a supercap, detect power fail and shut down gracefully. In a real ADAS project the difficulties show up in the details: how I size the supercap, how early the power-fail signal fires, how much ESR I can tolerate and how my logger behaves under a hard deadline.
For sizing, it is tempting to plug an average load current into a C × ΔV formula and assume the answer is my hold-up time. In practice I have to work backwards from my worst-case task: how long the EDR or ADAS logger needs to write a minimum evidence set, how much current the storage and CPU pull during that burst, and what margin I need for temperature and lifetime drift. If I ignore those effects, my 150 ms on the spreadsheet can easily shrink to 80 ms on the oscilloscope.
Timing is just as critical. If the power-fail threshold is set too low, the supply may have already dropped close to the minimum operating voltage before the system even knows it is in trouble. If the safe-state interrupt competes with other high-priority work, precious milliseconds are lost before the state machine starts. I try to treat the power-fail path as a top-priority, one-shot emergency signal and align all my software and hardware responses around it.
Supercap ESR quietly erodes hold-up time as well. A high ESR part can drop the rail voltage sharply when the logger and CPU ramp current, cutting into my usable ΔV and adding heat at exactly the wrong moment. I usually verify my design with real load waveforms, sometimes splitting the hold-up across multiple caps or placing the most critical rail closest to the lowest ESR path instead of relying only on datasheet tables.
Finally, the logger itself can be the weakest link. Even if the supercap can theoretically support 200 ms, a file system that updates indexes at the wrong moment can still corrupt data or miss the last events. I prefer to define a minimum evidence set, design the log format around fast, append-only writes and then prove in testing that the worst-case power cut still leaves the data in a usable state.
Use Cases and Hold-Up Planning Examples
Different ADAS blocks experience a power fail in very different ways. My EDR or ADAS data logger cares about having enough time to write the last events with a clean index. A vision ISP pipeline cares about closing the current frame and leaving downstream consumers with a consistent view. A TSN router must drop off the network in a way that still respects time synchronization, while a data fusion hub needs to capture a final state snapshot it can trust after restart.
I plan hold-up very differently for these four use cases. The table below is how I like to structure that thinking: what each block does, how much hold-up I typically target, which tasks must run inside that window, what the power profile looks like and what happens if I misjudge it.
| Use case | Typical hold-up target | Critical tasks during hold-up | Power profile / load notes | Failure if hold-up too short | Typical supercap / topology choice |
|---|---|---|---|---|---|
| EDR / ADAS Data Logger | Around 100–300 ms for final event write, index update and file system housekeeping. | Flush last events, commit timestamps, update indexes and close or seal the current log segment. | Short, high-current write bursts into NVMe or UFS; CPU and storage controller may spike above normal averages. | Missing or corrupted crash and near-crash data, inconsistent indexes and logs that cannot be trusted in an investigation. | One or more large supercaps close to the logger rail, often with a dedicated hold-up path and careful ESR selection. |
| Vision ISP Streaming | Tens of milliseconds to close the current frame or line buffer and leave downstream blocks in a consistent state. | Finish or abort the active frame, mark the last good frame, park exposure and gain controls, notify consumers if possible. | ISP, DRAM and sensor I/O draw together; power is dominated by memory and pixel processing rather than storage writes. | Incomplete or corrupted frames, hard-to-reproduce artifacts and debug traces that do not line up with the final video. | Smaller supercap or shared hold-up rail feeding ISP and DRAM, tuned for short but stable operation during the final frame. |
| TSN Router / Gateway | Roughly 50–150 ms to drain critical queues, send link status and avoid violating time sync guarantees. | Flush priority traffic, send last status or topology messages, gracefully shut down TSN schedules and timestamping blocks. | Switch core and PHYs dominate power; traffic pattern can change current quickly as queues are drained and links go idle. | Network peers see a sudden, unexplained drop-out, leading to degraded sync, retries and more complex fault analysis. | Medium-size supercap supporting the Ethernet switch and timing domain, often coordinated with a safety PMIC on core rails. |
| Data Fusion Hub | Around 50–150 ms to capture a compact state snapshot and record sensor health before shutting down. | Save the fused state vector, log which sensors were healthy, park outputs and record enough context for restart or analysis. | MCU-centric power with moderate RAM and flash activity; current is smoother than in a logger but still spikes during writes. | Restart may need to re-learn the environment with no trustworthy prior state, lengthening recovery and complicating safety arguments. | Supercap sized for the MCU and storage rail, sometimes with a dedicated safe-state controller supervising the snapshot sequence. |
IC Roles and Recommended Vendor Lines
A working hold-up scheme is never just a supercap on a rail. I need a power manager to detect trouble and switch paths, a controller or safety island to run the safe-state sequence, and a measurement function that tells me whether the remaining energy is enough to finish my work. The table and block diagram below are how I like to break down those IC roles when I plan the BOM.
I do not treat the vendor list as a shopping cart; it is more of a map. I choose a safety PMIC family that can generate a reliable power-fail signal and manage ideal-diode or OR-ing switches, a controller or safety MCU that can implement the safe-state finite-state machine and a gauge or monitor that lets me budget C × ΔV against real load profiles. Storage and logger ICs also belong in this picture, because their write behavior defines my true hold-up target.
| IC role | Hold-up responsibilities | Works closely with | Example vendor lines | Notes for BOM planning |
|---|---|---|---|---|
| Safety PMIC / Power-Path Manager | Detects supply collapse, asserts power-fail, controls ideal-diode or OR-ing switches and sequences critical rails into and out of hold-up. | Supercap bank, gauge or monitor, safe-state controller, main PSU or DC-DC front-end. | Automotive safety PMIC families from Infineon, NXP, Renesas, ST or TI, often paired with domain controllers or ADAS SoCs. | I look for well-documented power-fail thresholds, flexible power-path control and ASIL-capable diagnostics around the hold-up rails. |
| Hold-Up / Safe-State Controller | Runs the safe-state finite-state machine, freezes new workloads, prioritises logging and finally commands a clean shutdown when time is almost over. | Safety PMIC, logger or ADAS SoC, watchdog, sometimes an HSM or safety island that supervises software behaviour. | Lockstep MCUs and safety islands from NXP, Renesas, TI, Infineon or Microchip, and safety monitors or voters around them. | I budget CPU time and memory for the safe-state flow and treat the power-fail interrupt as a top-priority, one-shot event in my software design. |
| Supercap Gauge / Voltage & Current Monitor | Measures supercap voltage, current and sometimes temperature so I can translate C × ΔV into an actual hold-up time budget in milliseconds. | Supercap bank, safety PMIC, safe-state controller and, in some designs, the main BMS or body-domain energy manager. | High-side monitors, coulomb counters and AEC-Q qualified gauges from TI, ADI, Maxim/ADI, Renesas and similar vendors. | I choose parts with suitable common-mode range, low offset and enough bandwidth to catch real load bursts during the hold-up window. |
| Logger / Storage Controller ICs | Provide the physical write path during hold-up, including flash, UFS or NVMe controllers, and determine how quickly a log segment can be closed and indexed. | Safe-state controller, safety PMIC, PHYs or switches for EDR connectivity, host CPU or domain controller. | Automotive-grade UFS or eMMC controllers, NVMe solutions and their companion PHYs from storage and SoC vendors with ADAS focus. | I validate worst-case write latency and log format under power-cut tests, not just under bench conditions, before freezing the BOM. |
Layout and BOM Considerations
Once the IC roles and supercap size look right on paper, layout and BOM details decide whether the hold-up window really exists on the board. ESR, discharge path parasitics, routing around the power-path switch and how I route the safe-state controller all change the effective ΔV and the noise the rest of the system sees during a power fail.
For ESR, I think in terms of a simple drop: Vdrop = Iburst × ESR. The more current my logger and CPU pull during hold-up, the more that drop eats into my usable headroom and the hotter the supercap runs when the vehicle is already stressed. I try to place the most critical rail as close as possible to the supercap pads, sometimes splitting the energy into multiple caps in parallel to keep ESR down and current paths short.
The discharge path itself should be very explicit: from supercap pads through the power-path switch or ideal-diode FET, into the hold-up rail and then into the controller and logger domains. I avoid sending that high dI/dt current through narrow necks or shared ground returns that feed sensitive analog or reference nodes. A messy discharge path turns a clean hold-up into a source of ground bounce and EMI just when I can least afford it.
Finally, I watch for visible artifacts like LED or backlight flicker during power-fail tests. If an HMI LED strip or tell-tale flashes as the hold-up kicks in, it usually means my safe-state controller is not parking outputs early enough, or that my layout lets the hold-up current couple into LED drivers. On the BOM side I also check supercap ESR, temperature derating, lifetime data and RoHS or REACH status so I do not trade reliability for a part that will be constrained or non-compliant later.
Failure Modes
When I talk about hold-up and safe-state power, I also need to be honest about how it can fail. Supercaps age or get damaged, cold-start conditions do not always let the system charge the hold-up bank fully, and RAM-based state can disappear in ways that leave logs or fusion outputs inconsistent. If I only design for the ideal case, my safety argument will not survive a real investigation.
On the energy side, a supercap that has lost capacity or developed a high ESR looks fine on the BOM but delivers far less than the intended hold-up window. An open or partially disconnected device can remove the hold-up function completely, while a leaky or shorted part can stress the front-end supply during cold-start. I try to treat these as explicit failure modes, not just background reliability noise, and verify them with injected power-fail tests.
Timing and control form a second branch of failure. If the power-fail threshold fires too late, if the power-path FET never actually switches to the supercap, or if the safe-state controller does not get CPU time when it matters, my carefully sized hold-up bank can be wasted. I treat those as control-path failures and include them in my FMEA and fault injection plan, not just in software unit tests.
Finally, there are failures in data and state. A logger that writes slowly or updates its index at the wrong moment can corrupt or lose the most important evidence, even if the hold-up window is available. A fusion hub that keeps its state only in RAM can restart with an inconsistent view of the scene. I prefer to model these as top-level failure modes: hold-up energy present, but safe-state function not achieved, and treat them with the same seriousness as a lost supercap.
Internal Hooks for Search and Project BOM
This section is mainly for my own projects and internal search. I want every hold-up and safe-state power page to carry a small, consistent set of tags that my tools can scan, and a core list of parameters that flow into project-level BOM and safety documentation. It is not a substitute for a formal safety case, but it keeps my notes and purchasing decisions aligned.
For search and knowledge management, I tag this topic as part of the ADAS hold-up and safe-state power family, with use-case anchors in EDR, vision ISP streaming, TSN routing and fusion hubs. I also capture which IC roles are in play here: safety PMIC or power-path manager, supercap gauge or monitor, safe-state controller and logger or storage controller ICs.
At project level I track a small set of fields for this block: my target hold-up window in milliseconds, the assumed peak hold-up current, nominal supercap value and ESR at relevant temperatures, and the size of the minimum evidence set the logger must commit. I also note which safety PMIC family and controller type I am planning to use so that future design reviews and sourcing decisions can quickly cross-check capabilities against these requirements.
Request a Quote
Hold-Up and Safe-State Power FAQs
These are the questions I use to sanity-check my hold-up and safe-state power design. Each answer is short enough to reuse in reviews and documentation, but detailed enough to remind me what to validate on hardware, in safety analysis and in project-level BOM planning.
How do I decide whether my ADAS project really needs a dedicated hold-up and safe-state power path instead of just rebooting on power loss?
I start from consequences, not from hardware. If losing power means I lose evidence, break a safety assumption or confuse other ECUs, I plan a hold-up and safe-state path. If a clean reboot is genuinely acceptable and documented in the safety concept, I may keep it simple, but I always document that decision.
How do I work backwards from my logging and safety requirements to choose a realistic hold-up time window in milliseconds?
I first define the minimum evidence set I must commit and how long my logger needs to write it under worst-case conditions. Then I add time for the safe-state state machine, communication and any shutdown housekeeping. Finally I add margin for temperature, ageing and software changes, and only then turn that into a hold-up time budget.
Should I size my supercap based on average current, rated current or worst-case burst current during hold-up?
For energy I look at the real current profile over the hold-up window, but for ESR and voltage sag I always design to the worst bursts. Logger writes, CPU peaks and memory traffic usually happen at the same time. If I size only to average current, my calculated millisecond window shrinks dramatically on real hardware and at low temperature.
Do EDR, vision ISP, TSN router and fusion hub domains really need different hold-up strategies, or can I treat them all the same?
I treat them differently. EDR wants time to write evidence, a vision ISP wants a last clean frame, a TSN router wants an orderly drop-off and a fusion hub wants a final state snapshot. I may share one supercap bank, but I assign priorities and sometimes dedicate a separate hold-up rail for the logger path.
How should my safety PMIC, supercap gauge and safe-state controller cooperate when a power-fail event occurs?
I expect the PMIC to detect the collapse quickly, assert a clean power-fail signal and switch the power-path to the supercap. The gauge estimates how much time I really have and reports it to the controller. The safe-state MCU freezes new work, runs a prioritised shutdown sequence and finally tells the PMIC when it is safe to let rails go.
During cold-start and frequent start-stop, should I define a “hold-up ready” condition before I rely on the supercap bank?
Yes. I treat the supercap bank like a safety resource that can be unavailable. I define a hold-up ready flag based on cap voltage and estimated energy, and I keep non-critical logging or advanced behaviours disabled until that flag is set. Diagnostics for “reduced hold-up capability” help me explain any feature limitations in harsh or early-life conditions.
What layout and BOM details matter most for ESR and the discharge path so my hold-up time on the bench matches behaviour in the vehicle?
I keep the supercap zone compact with short, wide traces and a clear discharge path through the power-path switch into the protected rails. In the BOM I record ESR at room and cold temperature, lifetime and derating. I avoid sharing narrow planes or returns with sensitive analog or HMI drivers, otherwise ground bounce and noise eat into my hold-up margin.
Why do I sometimes see LEDs or backlights flash when hold-up engages, and how can I avoid that “false fault” in HMI?
A flash usually means my outputs were not parked before the rails moved, or hold-up currents coupled into the LED driver. I update the safe-state sequence to force a known HMI state as soon as power-fail is detected, not at the very end, and I review routing so the high dI/dt discharge path does not run alongside HMI lines or their ground reference.
How can I run a realistic hold-up validation instead of trusting C × ΔV calculations on a spreadsheet?
I test with the real ECU, logger and traffic patterns, not just a dummy load. I trigger a controlled power cut at the input supply and capture waveforms on the critical rails and power-fail pins. I repeat at low and high temperature and with aged parts where possible, and I always check the resulting logs and state after each test, not just voltages.
How do I turn my fault tree and FMEA for hold-up into concrete tests and diagnostics on the ECU?
I take each failure mode, such as supercap open, ESR increase, power-fail too late or logger partial write, and define how to provoke it or emulate it on hardware. Then I decide whether it deserves an online diagnostic, a manufacturing test or a lab-only campaign, and I store the results as part of my safety case evidence package.
How do I define a minimum evidence set so my logger still provides useful data when hold-up time is shorter than ideal?
I split my log into must-have and nice-to-have signals. The must-have set includes timestamps, key states, driver commands and health flags I need to reconstruct events. During hold-up, my safe-state sequence focuses on writing and sealing that core set first, then only writes extra channels if there is time left, so a shorter window still leaves meaningful traces.
Is there a way to monitor hold-up capability in the field so I notice when supercap ageing or new software is eating my margin?
I can log how much time passes between power-fail detection and rail collapse, or monitor supercap voltage behaviour during self-tests. A gauge or ADC can derive an approximate remaining hold-up capacity. If trends show the margin shrinking, I can raise a diagnostic, adjust features or plan a design update before the system starts missing its safe-state targets.
