H2-1. One-line Thesis + What problem this page solves

What this page solves: A practical, evidence-ready architecture for emergency luminaires that must (1) detect mains loss, (2) transfer to battery-backed power without visible failure, (3) regulate emergency LED current within defined limits, and (4) prove compliance through runtime metering and self-test traceability.

Scope boundary (locked): Covers charger + battery readiness, emergency transfer (mains/brownout detect, hold-up, soft-start), emergency inverter/power stage behavior, emergency LED constant-current regulation, runtime/SOC evidence, and self-test + log design. Excludes protocol dimming ecosystems and any networked/PoE/PLC/wireless node content.

Why “deep” matters: Field failures are rarely continuous. Typical issues are intermittent: “sometimes no transfer,” “brief flash then off,” “self-test fails but manual test passes,” or “runtime below label.” This page is built around a minimal evidence dictionary so each symptom maps to a measurable discriminator and a repairable root cause.

Evidence dictionary (8 fields used throughout): Keep these names consistent across firmware logs, test reports, and service tools. Each field exists to separate charger vs battery vs transfer vs inverter vs LED-loop faults with minimal measurement overhead.

H2-2. System requirements & modes (Normal / Standby / Emergency / Test)

Goal of this chapter: Define operating modes with explicit entry/exit conditions and measurable success criteria. Clear mode boundaries prevent hidden conflicts (for example: charger behavior interfering with emergency transfer, or self-test triggering during an actual mains-loss event).

Mode model (4 states):

• Normal Lighting (Mains ON): Mains present; lighting may run from the normal power path; charger can operate in parallel. Must-log: LINE_OK.
• Standby Charging (Ready): Luminaire is idle/ready; charger maintains battery readiness with minimal standby loss. Must-log: battery readiness evidence (use VBAT plus internal charger phase, if available).
• Emergency Supply (Mains OFF): Battery-backed power engages; emergency LED current must reach a defined stable level. Must-log: MAINS_LOSS_TS, TRANSFER_MS, VBUS_MIN_XFER, ILED_AVG/RIPPLE%, RUNTIME_MINUTES.
• Test Mode (Self-test): Controlled verification of emergency chain health. Two classes: functional test (short) and duration test (long). Must-log: SELFTEST_CODE + FAULT_BITS (and the measured KPIs used for pass/fail).

Key requirements (measurable definitions):

• Transfer time (TRANSFER_MS): Measured from MAINS_LOSS_TS (first validated mains-loss) to the time the emergency LED current reaches a defined stable window (for example, ≥X% of target and stable for Y ms). This avoids “success by momentary spike.”
• Emergency constant-current quality: Use both ILED_AVG (accuracy) and ILED_RIPPLE_PCT (stability/visual risk). The minimum requirement should be expressed as a bound, not as “good.”
• Minimum output power / illumination policy: Implemented as an emergency current setpoint and/or derating ladder. Derating decisions must be explainable through runtime evidence (battery voltage/current and time).
• Runtime compliance: Proved by RUNTIME_MINUTES (and optionally SOC estimate in later chapters). Store the battery condition snapshot at start and end of emergency operation.
• Restore strategy: When mains returns, mode switching must avoid chatter. A restore debounce and a controlled re-entry (soft-start/recharge gating) prevents repeated transfer cycling.

Typical constraints (why requirements fail in real luminaires):

• Small enclosure / thermal stress: Reduces battery capacity margin and increases protection triggers; transfer success must be measured at temperature corners.
• Low standby power: Forces sparse sensing/logging; the evidence dictionary prevents “too little data to diagnose.”
• Noise/EMI bursts at transition: The transfer moment is the highest-risk EMI and reset window; capture VBUS_MIN_XFER and fault bits to prevent non-reproducible investigations.

Evidence method (how transfer time and test results are recorded):

• Transfer timing: Latch MAINS_LOSS_TS when LINE_OK becomes false after debounce. Declare “transfer complete” when LED current reaches a stable band (log that moment internally), then compute TRANSFER_MS. During the same window, capture VBUS_MIN_XFER and any reset/fault indicators.
• Functional self-test (short): Verify sense → transfer → inverter start → LED current regulation. Pass/fail is encoded in SELFTEST_CODE. If fail, set FAULT_BITS to indicate the stage and dominant protection cause.
• Duration self-test (long): Verify runtime. Record RUNTIME_MINUTES and the final battery/LED condition snapshot to show whether “short runtime” is capacity-related or load-related.

H2-3. Reference architecture (Power tree + control partition)

Intent: This chapter provides the single “map” used by all later deep-dives. It separates the power tree (energy flow) from the control/telemetry partition (who decides transfer, who enforces protection, and who produces logs). Each major block has a corresponding test point (TP) and a log source, so symptoms can be diagnosed without guesswork.

Power tree (energy flow):

• AC input → Rectifier / (optional PFC) → DC bus (VBUS): Establishes the main energy reservoir and defines the transfer stress window.
• Charger → Battery pack: Maintains readiness; battery condition dominates runtime compliance over product life.
• Battery → Inverter / emergency power path → LED constant-current stage: Produces stable emergency output; any instability here shows up as current ripple, early cutoff, or protection latching.

Control partition (decisions + evidence generation):

• Mains sense + debounce: Produces LINE_OK and the “start timestamp” for transfer evidence.
• Transfer actuation: Relay/solid-state control that gates emergency power engagement (and defines where bus dips may occur).
• Inverter enable + soft-start policy: Controls inrush and peak stress; ties directly to transfer success and fault bits.
• LED CC enable + setpoint: Defines emergency output quality (average current + ripple proxy).
• Logger + self-test scheduler: Converts measured behavior into traceable results (SELFTEST_CODE, FAULT_BITS, runtime evidence).

Evidence mapping: The table below is the practical bridge from “block diagram” to “what to measure first.” Keep TP naming consistent across lab notes, firmware, and service procedures.

H2-4. Battery pack choices & safety envelope (Li-ion / LiFePO₄ / NiMH)

Intent: Battery selection in emergency luminaires is not about “maximum energy density.” It is about long standby life, temperature corners, maintenance strategy, and provable runtime compliance. This chapter compares chemistries only through the lens that matters for emergency lighting: readiness, safety envelope, and evidence fields for ongoing compliance.

What actually matters in emergency lighting:

• Standby behavior: The system may spend most of its life in standby/charging. Chemistry determines whether long-term float/maintenance charging is benign or aging-accelerating.
• Temperature envelope: Enclosures run warm; cold corners reduce deliverable capacity and increase internal resistance effects. Compliance must be defensible at realistic temperature extremes.
• Low-temperature discharge: Runtime shortfalls frequently appear only in cold conditions; the evidence set must capture temperature context.
• Maintenance strategy: Some systems require periodic controlled discharge tests to keep runtime claims calibrated over aging.

Chemistry selection notes (emergency-luminaire lens only):

• Li-ion: Strong energy density but more sensitive to charging policy and thermal history; ensure protection boundaries and evidence logging support safe long-life standby.
• LiFePO₄: Often chosen for safety/thermal robustness; still needs defined UV/OV and temperature-aware behavior to avoid false runtime assumptions.
• NiMH: Different standby/maintenance behavior; selection is driven by the permitted maintenance approach and the acceptable runtime margin under temperature extremes.

Safety envelope (must be explicit, not “implied”): Define what happens when any boundary is crossed. The luminaire must enter a safe state, and the event must be traceable via pack_fault_flags and FAULT_BITS.

• OV / UV: Stop charge/discharge as appropriate; record fault source and snapshot VBAT.
• OCP: Protect against overload/inrush and short conditions; log whether it happened during transfer or steady emergency output.
• OTP: Use pack NTC placement to represent worst-case heating; record temperature extremes for maintenance evidence.
• Reverse / miswire / connector faults: Treat as a pack fault condition; log a distinct fault bit for serviceability.

Aging → runtime compliance (the key linkage): A luminaire often “works” while silently losing compliant runtime. To keep runtime claims defensible, record an evidence set that connects capacity/aging to the observed duration outcome.

Evidence fields (minimal maintenance-ready set):

• capacity_estimate: A capacity proxy derived from controlled tests or consistent discharge characterization (concept-level; implementation detailed later).
• temp_extremes: Max/min temperatures observed near the pack; temperature is the first-order modifier of deliverable runtime.
• cycle_count: Tracks wear; helps distinguish “normal aging” from a sudden defect or abnormal maintenance policy.
• pack_fault_flags: Pack/BMS fault indicators (OV/UV/OCP/OTP, etc.) that must map into service-visible fault codes.

H2-5. Charge management (CC/CV, standby, health monitoring)

Intent: Charge control must be a phase machine with explicit entry/exit rules, temperature guards, per-phase timeouts, and a traceable termination reason. “Standby” is an active policy state: it maintains readiness while collecting evidence that explains long-term runtime compliance.

Phase machine: PRECHG → CC → CV → TERM → STANDBY

Implement charging as discrete phases, each with entry conditions, a control objective, exit conditions, and mandatory evidence. Avoid hidden behavior that cannot be audited later.

Standby policy: readiness + low aging + traceability

• Recharge triggers: OCV drift below a threshold (measured under low-load/quiet conditions), scheduled maintenance events, or post-test recovery.
• Guards: temperature out of range, active pack fault, excessive recharge frequency (anti-chatter) to avoid accelerated aging.
• Exception handling: if a charge cycle is repeatedly terminated by timeouts or temp guards, raise a service-visible code rather than silently looping.

Health monitoring (minimal, implementable set)

Evidence fields (service-usable)

• CHG_PHASE (PRECHG/CC/CV/TERM/STANDBY)
• PHASE_T_START / PHASE_T_END per phase
• VBAT_SNAP / IBAT_SNAP / T_SNAP (enter/mid/exit sampling points)
• CHG_TIMEOUT_FLAG (per-phase bits recommended)
• TERMINATION_REASON (I_TERM / TIMEOUT / TEMP_GUARD / FAULT / MANUAL)

H2-6. Emergency transfer (mains sense, hold-up, inrush, switchover)

Intent: This is the reliability core: explain why transfer can fail (“no transfer”), why it can cause a visible disturbance (“flicker dip”), and why it can trigger a restart (“reset/brownout”). The chapter is structured as a time-chain: detect → decide → actuate → stabilize, with evidence fields that make outcomes defensible.

1) Mains detection (logic-level): threshold, debounce, delay

• Signal definition: create a single truth signal (e.g., LINE_OK) that represents “mains is valid for normal operation.”
• Debounce: apply separate down/up debounces to prevent chatter during dips and recovery.
• Delay policy: a short delay reduces false transfers; too long increases the probability of a deep DC-bus dip and restart.
• Evidence anchor: the moment LINE_OK deasserts defines transfer_timestamp.

2) Hold-up (keep control alive during the transfer window)

• Hold-up window: from mains invalidation to stable emergency output (ILED stable).
• Critical metric: VDC-link dip depth (how low VBUS falls) relative to the system’s brownout threshold.
• Priority: maintain the control/log domain first; an uncontrolled restart turns a brief dip into a long blackout and destroys traceability.

3) Inrush and soft-start (battery/inverter start events)

• Battery-side stress: discharge current peaks can create VBAT droop that mimics an undervoltage event.
• Inverter-side stress: peak events at inverter start can trigger OCP/OTP or destabilize the LED CC stage.
• Soft-start objective: cap peaks, avoid false UV/OCP, and reach stable ILED quickly without overshoot.

4) Switchover actuation: relay vs solid-state (impact metrics only)

• Relay: can introduce contact bounce and timing variation; impacts transfer time and dip shape.
• Solid-state: supports tighter timing control but adds conduction loss and thermal constraints; impacts steady efficiency and heat.
• Engineering lens: choose based on impact to transfer timestamp precision, dip depth, inrush peak, and restart probability.

Evidence fields (transfer reliability proof set)

• transfer_timestamp: when the system declared mains invalid and initiated transfer.
• VDC-link dip depth: minimum VBUS during the window; predicts brownout risk.
• reset_cause: explicit reason if a restart occurs (brownout/WDT/other).
• brownout_counter: frequency measure for field reliability and maintenance decisions.

H2-7. Inverter / emergency power stage (topologies + control priorities)

Intent: The emergency inverter stage is evaluated by start reliability, peak containment, and deterministic fault behavior—not by general-purpose UPS features. Topology is compared only by its impact on isolation integration, efficiency tendency, cost/complexity, and EMI risk.

Common stage forms (compared by impact metrics)

Control priorities ladder (what wins when constraints conflict)

• 1) Start-up reliability: reach a stable switching state quickly after INV_EN, without oscillation or repeated retries.
• 2) Peak containment: enforce power/current limits to prevent VBAT droop and over-current events during ramp and load steps.
• 3) Regulation stability: provide a stable supply condition to the emergency LED current loop (or direct emergency CC path).
• 4) Efficiency: optimize only after the above constraints are satisfied.

Defined behaviors for edge cases (deterministic, service-friendly)

• Light-load / no-load: enter a bounded switching mode (e.g., frequency reduction or controlled burst) with a logged mode flag, not an uncontrolled oscillation.
• Short-circuit: prefer hiccup (periodic retry) when safe to attempt recovery; otherwise latched off with a clear cause code.
• Over-temperature: use a staged response (warn → limit → shutdown) so field logs reveal whether the event was gradual heating or a sudden thermal spike.

Evidence fields (minimal set that explains real failures)

• IINV_PEAK: peak inverter input current in a defined window (e.g., around T2→T3 of transfer).
• SWFREQ_STATE: startup / normal / foldback / hiccup (enum), to disambiguate “attempting recovery” vs “stable.”
• FAULT_CAUSE_BITS: OCP / UV / OV / SHORT / DRIVE_FAULT (bitset).
• THERMAL_FLAGS: T_WARN / T_LIMIT / OTP_LATCH (bitset).
• FAULT_FIRST_CAUSE: first-cause capture when multiple faults occur simultaneously (prevents ambiguous field diagnosis).

H2-8. LED current regulation during emergency (CC loop, dim level, flicker safety)

Intent: In emergency mode, the current loop must stay stable while respecting a tighter energy budget. The key is priority: battery-side power limiting sets the available envelope, and the LED CC loop tracks within that envelope using a setpoint clamp (or duty cap) to prevent integrator wind-up, oscillation, and visible flicker.

Emergency CC targets (measurable, service-friendly)

• ILED_SETPOINT: defined current target (or power-to-current mapping) in emergency mode.
• RIPPLE_BOUNDS: acceptable current ripple bounds (pp or rms; choose one consistently).
• STABILITY: no sustained oscillation or repeated mode toggling during derate events.

Dual-loop concept (battery budget loop + LED CC loop)

Derate strategy (low battery / thermal / power limit) with anti-chatter

• Triggers: VBAT low, power limit active, thermal warning, abnormal IR proxy trend.
• Shape: step-down or ramp-down with a minimum hold time; avoid rapid up/down toggles.
• Logging: every derate event must record a DERATE_REASON and an updated current command.

Flicker safety: evidence chain (no standards deep-dive)

• ILED_RIPPLE_PP / ILED_RIPPLE_RMS: ripple evidence at the time of complaint.
• LOOP_MODE_FLAG: CC normal / CC clamped / power-limit / saturation (enum).
• MODE_TOGGLE_COUNT: number of mode switches in a time window (high counts correlate with visible instability).
• Complaint triage fields: timestamp, temperature, VBAT snapshot, and whether the event occurred shortly after transfer.

H2-9. Discharge curve, runtime metering & SOC estimation (aging-aware)

Intent: Turn “runtime” into a verifiable and self-testable metric. That requires an evidence chain: a meter that is explainable, thresholds that adapt to temperature/aging, and a derate/cutoff policy that is logged and replayable.

Runtime metering: why coulomb count + voltage need to work together

• Coulomb count (primary continuity): tracks delivered charge/energy during emergency discharge, enabling a continuous runtime_minutes counter.
• Voltage-based check (absolute sanity anchor): validates boundaries and protects against drift, especially near low-battery thresholds where load/temperature distort terminal voltage.
• Engineering conclusion: coulomb count explains “how much was delivered,” voltage-based checks prevent “drifted truth.” Combined, runtime becomes reproducible across field conditions without exposing algorithm internals.

Discharge curve drift: temperature + aging move the thresholds

• Temperature: low temperature increases effective impedance; terminal voltage collapses earlier under load → fixed cutoffs can cause premature shutdown.
• Aging: reduced usable capacity and softer voltage profile compress the tail of discharge → stability and flicker risk rise near end-of-runtime.
• Load level: emergency brightness/power changes the curve shape; thresholds must be consistent with the active power budget.

Low-battery policy: staged derate + deterministic cutoff (battery-safe, recoverable)

• Stage 1 (Early warning): mild derate to keep regulation stable; log the event and the active threshold profile.
• Stage 2 (Stability priority): stronger derate with command clamp; prevent mode-chatter that creates visible instability.
• Stage 3 (Safe cutoff): shutdown at a defined boundary, record a full snapshot so maintenance can replay the decision.

Evidence fields (the minimum set that proves runtime)

• runtime_minutes: elapsed emergency runtime from transfer start to cutoff/restore.
• SOC_percent: reported SOC with a method tag (e.g., “cc+v sanity”) for interpretability.
• low_batt_events: count of low-battery stage entries (process trace).
• capacity_estimate: aging-aware usable capacity estimate used to select thresholds.
• temp_at_discharge: temperature snapshot (and/or bin) used for the threshold profile.

H2-10. Self-test & reporting (functional test vs duration test, logs & indicators)

Intent: Self-test is the compliance and maintenance core: define what is tested, how pass/fail is decided, and how results are recorded and indicated so failures are deterministic, explainable, and repeatable.

Two self-test classes (coverage vs cost)

• Functional test (short): validates transfer path, inverter start, and LED current regulation stability over a short window. Low battery wear, high frequency scheduling.
• Duration test (long): validates runtime compliance and end-of-discharge derate/cutoff policy. Higher wear and time cost, lower frequency scheduling.

Pass/fail gates (each gate maps to a measurable field + failure stage)

• Transfer gate: transfer_time meets target and does not trigger brownout/reset; failure_stage=transfer.
• Regulation gate: ILED setpoint is reached and remains stable (no sustained oscillation, limited mode toggles); failure_stage=cc_reg.
• Runtime gate (duration test only): runtime_minutes reaches requirement or follows the approved derate/cutoff policy; failure_stage=runtime or cutoff.
• Diagnosability gate: failure is explainable (first-cause + stage), not random; failure_stage=diag.

Reporting: minimal self-test record (field-replayable)

• self_test_schedule: periodic / manual / maintenance-triggered (source + cadence id).
• test_type: functional / duration (enum).
• test_result_code: PASS or FAIL_xxx (enum).
• failure_stage: transfer / cc_reg / runtime / cutoff / diag (enum).
• last_pass_time: timestamp of last PASS (supports overdue logic).

Indicators: align UI state with logs (no black boxes)

• PASS: last_pass_time recent, no active failure codes.
• FAIL: test_result_code indicates failure; indicator must be explainable by failure_stage.
• OVERDUE: schedule missed; does not imply failure, but requires maintenance action.