H2-1. Center Idea

Functional safety & compliance for LED drivers should be treated as an evidence system: deterministic safety reactions are designed, verified, and continuously proven in the field with traceable, tamper-evident records.

This topic page is not a standards glossary. It is a practical method to turn “safe” into a set of auditable claims: hazard → safety function → detection/diagnostics → reaction timing → verification artifacts → field evidence. Each claim must be reproducible by measurement and defensible during certification, customer audits, or failure analysis.

• Deterministic safety reaction: define exactly what triggers a safety action (threshold, window, consistency check), what the safe state is (energy removal / limit / latched-off), and the explicit restart prerequisites.
• Verification that binds to versions: every test run must be tied to hardware revision, firmware build, calibration state, and the key/signature policy version used for logging and update authorization.
• Non-repudiable field evidence: safety-relevant events must produce records that cannot be silently altered—using chained integrity (hash/signature), monotonic counters, and controlled service access.

A robust implementation behaves like an engineering “contract”: the driver either remains within safe limits or transitions into a defined safe state within a measured time budget. When a rare failure happens, evidence is sufficient to answer three questions with minimal ambiguity: What happened? When did it happen? Which version and policy were active?

H2-2. Compliance Landscape

Standards do not merely ask for “passing results.” They require repeatable setups, defined pass criteria, and traceable records that bind each result to product versions and operating modes.

A practical approach is to translate compliance into four evidence buckets. Each bucket is written as a testable contract: what is measured, under which operating mode, with what instrumentation, and how the evidence is stored and trace-linked.

• Product safety evidence: insulation barriers, creepage/clearance verification, hipot and leakage limits, temperature rise at defined hot spots, and abnormal operation behavior (e.g., safe shutdown and safe restart policy).
  Required records: test voltage profile, hold time, trip thresholds, ambient conditions, mounting/spacing photos, HW revision and BOM identifiers.
• EMC emissions evidence: conducted and radiated emissions with explicitly documented cabling, grounding, and worst-case operating modes.
  Required records: frequency bands, limit lines, peak frequencies, LISN/receiver IDs, EUT orientation, mode table (load, dim level, input voltage).
• Immunity evidence: ESD/EFT/surge/RF/dips with a clear performance classification (A/B/C) and defined recovery strategy.
  Required records: stress level, injection method/coupling, number of shots, performance class, recovery time, and whether any safety function latched.
• Power-quality evidence: harmonics and flicker/voltage fluctuation (when applicable) bound to mains condition and operating point.
  Required records: input voltage, load point, THD and key harmonic components, flicker metrics, and instrumentation calibration state.

The key differentiator is to avoid “pass/fail only” reporting. Each compliance claim should be supported by: (1) a mode matrix (worst-case selection is justified), (2) a setup fingerprint (cables/grounding/coupling are reproducible), (3) a pass criteria definition including A/B/C behavior, and (4) a trace link to the exact hardware/firmware/calibration and logging policy versions.

The recommended deliverable for this chapter is a single source of truth: Compliance Evidence Matrix. It is a table that connects each requirement to a test case, a setup, a pass criterion, and an immutable record ID. This matrix also becomes the bridge between certification reports and field diagnostics: event codes and log exports should reference the same identifiers used in verification.

H2-3. Hazard → Safety Function

Functional safety starts by converting hazards into testable, time-bounded safety functions. A safety function is complete only when it specifies: trigger, reaction timing, safe-state behavior, and restart policy.

Hazards should be written in an engineering form that exposes energy paths and failure consequences. For LED drivers, the most common hazard families include hazardous touch energy (leakage/insulation failure), fire and thermal runaway (overstress and overheating), unsafe output energy (open/short abnormalities), abnormal restart oscillation (repetitive enable/disable), and EMI-induced misbehavior (false trips, uncontrolled state transitions, or corrupted evidence).

• Hazard → Safety goal: express the objective as a contract, e.g., “remove or limit hazardous energy within T milliseconds after trigger X, and keep the system latched until condition Y is met.”
• Safety goal → Safety function: define a unique Safety Function ID and specify trigger logic (threshold/window/consistency), reaction type (hard-off/limit/derate), and restart prerequisites (manual reset, cool-down, input recovery, authorized service).
• Safety function → Evidence fields: require the exact fields that make the claim auditable: SF-ID, Trigger, Reaction time, Latch policy, Proof-test interval, plus Mode context (input, load, temperature) and evidence linkage (test case ID, log event code, record ID).

The most frequently missing element is the reaction-time definition. Reaction timing should be expressed as a budget that can be measured and defended: Treact = Tdetect + Tdecide + Texecute. This decomposition prevents “undefined pass” situations where a fault is detected but the shutdown is too slow, or the restart policy causes oscillation.

1. Define SF-ID and hazard boundary What energy is hazardous, where is the boundary, and what constitutes a safe state.
2. Specify trigger logic Threshold/window/consistency, filtering and debounce, and the fault classification (transient vs persistent).
3. Lock the timing budget Tdetect + Tdecide + Texecute, with measurement points and a reproducible test method.
4. Define latch & restart policy When to latch, what conditions allow recovery, and how repeated toggling is prevented.
5. Bind verification + field proof Test case ID + immutable record ID + event code that is stored in tamper-evident logs.

H2-4. Safety Architecture

A safety architecture is the hardware skeleton that keeps safety functions enforceable even during software faults. The core principles are independent detection, independent execution, and independent power/retention for evidence.

The first architectural decision is the partition between the dangerous-energy domain and the monitor/evidence domain. The dangerous-energy domain contains the power path that must be removed or limited under fault. The monitor/evidence domain is designed to remain coherent long enough to latch fault state, preserve critical counters, and produce audit-friendly records. This separation prevents a single disturbance from simultaneously removing energy control and evidence.

• Safety PMIC / supervisor responsibilities: power-on reset integrity (POR), brownout/undervoltage supervision (BOR/UV), window watchdog to detect stuck execution, rail monitoring with sequencing checks, and a dedicated fault-safety output (FSO) that is capable of driving a shutdown path without firmware cooperation.
• Independent shutdown path: a hardware path that can force energy removal or limiting when the main controller is non-responsive. The shutdown path should be prioritized, non-maskable, and measurable (waveforms/timestamps demonstrate execution latency).
• Latch & reset conditions: define which faults must latch (to prevent oscillatory restarts), what constitutes safe recovery (cool-down, input recovery, authorized service), and how reset attempts are counted and recorded to support root-cause analysis.

A practical way to avoid ambiguity is to document two artifacts that are directly auditable: (1) a safety signal list describing the source, priority, and effect of each safety-relevant signal, and (2) a power-domain truth table specifying which domains remain powered during each state (normal, latched fault, service export, recovery). These artifacts align the hardware design, firmware policy, and test plans under a single deterministic contract.

H2-5. Fault Detection & Coverage

Fault detection is only meaningful when it is auditable: each fault class must map to a detection method, a measurable latency target, and a diagnostic-coverage (DC) target under explicit assumptions.

A robust safety plan starts with a fault dictionary: a normalized list of faults that must be detected, expressed as an object (sensor/rail/thermal/drive/isolation/storage), a fault form (open/short/drift/stuck/intermittent), and an observable symptom. This prevents ambiguous coverage statements where “overvoltage protection” is treated as a root cause.

• Typical fault classes: sensor open/short or drift, rail UV/OV and sequencing violations, true overtemperature vs sensor failure, gate/drive path anomalies (missing switching, stuck-on/off indicators), isolation/leakage indication faults, and critical storage corruption (CRC failure, write abort, wear-out).
• Detection templates: threshold (X > Xhi / X < Xlo), window (X within [a,b] for N samples), slope/rate-of-change (dX/dt exceeds bound), and cross-check consistency (dual-sense or redundant monitors with tolerance and arbitration).
• Coverage trade-offs: higher sensitivity improves DC but can increase false trips under noise, temperature drift, and aging. False positives are not only a usability issue; repeated shutdown/restart oscillation can create additional safety risk and must be explicitly bounded.

Detection latency should be stated as a measurable contract: from the physical fault occurrence to a declared fault state. When applicable, document the internal split: Tdetect (signal acquisition) + Tdecide (classification/consistency) + Treport (fault output or log update). This makes it possible to validate that the detection and reaction chain remains within the intended safety budget across operating modes.

H2-6. Diagnostic Injection

Diagnostic injection turns “detectable” into “provable.” Each injection case must be controlled, reversible, and bounded by safety guards so that injection itself never creates hazardous output energy.

The most effective injection plan covers the entire detection chain: acquisition (ADC), thresholding (comparators and rail monitors), thermal sensing, watchdog/supervision, and critical alert lines. For each target, injection should be designed as a repeatable demonstration: Injection case → expected fault code → reaction timing → recovery conditions → immutable record ID.

• Injection targets: ADC channels and front-end checks, comparator threshold chains, thermal sensors (true overtemp vs sensor fault), rail supervision (POR/BOR/UV/OV), watchdog paths, and communication/alert lines (stuck-low/high and disconnect detection).
• Methods ladder (confidence vs cost): software simulation (logic path validation), controlled firmware test modes (end-to-end reaction demonstration), and hardware injection (switch/resistor networks or open/short emulation for certification-grade evidence).
• Strategy by phase: power-up self-test (BIST) for critical functions, low-rate periodic online tests for long-term coverage, and service/factory modes for deeper injection under authorization.

Evidence fields must be consistent across all injection cases: Injection case ID, expected fault code, reaction time, recovery conditions, and an immutable record ID. Add preconditions (allowed operating mode) and active safety guard (limit vs forced safe-state) so that audits can confirm injection did not introduce risk.

H2-7. Safe Reaction & Timing

Safety fails when a system detects a fault but hazardous energy is not removed or bounded within the required time window. Reaction timing must be defined as an auditable budget and proven at energy-side measurement points, not only by fault-code timestamps.

A complete reaction definition uses a deterministic chain: Detect → Decide → Execute → Latch → Recover. Detection and decision establish that a fault is real; execution is the moment when hazardous energy is forced below a defined boundary. Latching prevents oscillatory restart behavior; recovery defines conditions and authorization for returning to normal operation.

• Detect: threshold/window/consistency becomes “true,” including filtering and debounce assumptions.
• Decide: classification and arbitration (transient vs persistent, vote rule, escalation rule).
• Execute: hard-off, energy limiting, or derating until the energy-side safe criterion is met (current/voltage/thermal).
• Latch: define which faults must remain latched to avoid repeated enable/disable toggling.
• Recover: define recovery prerequisites (cool-down, input stability, authorized service) and what evidence must be preserved.

Strategy selection must be rule-based. Hard-off is mandatory for hazards where any sustained energy output is unsafe (touch-energy boundary violations, insulation/leakage indications, fire-risk conditions, or untrusted control states). Energy limiting is appropriate when the boundary can be proven by measurement and the limiting path remains enforceable under controller faults. Derating is suitable for non-immediate risk indicators only when an explicit escalation path is defined (Derate → Limit → Hard-off).

H2-8. Tamper-Evident Logs

Tamper-evident logs turn field events into non-repudiable evidence. A defensible log system defines a structured event model, a tamper-evident chain (hash/signature/counter), and a power-loss-safe write protocol with explicit version and key binding.

A useful log is not a text stream. It is a structured record that can answer five audit questions: what happened, when it happened, the operating context at that moment, what reaction was taken, and whether the record was modified. Context must be captured as a snapshot (input voltage, key rails, temperature, mode, counters), not reconstructed from later readings.

• Event model: stable event code, severity level, context snapshot (VIN/rails/temp/mode), reaction snapshot (hard-off/limit/derate, latch state), and pointers (fault ID, waveform ID, test ID).
• Tamper-evident chain: include previous-record hash (insertion/deletion detection), apply signature over the record hash (prevents chain recomputation), and bind a monotonic counter (rollback/replay resistance).
• Version + key binding: store log format version, hash algorithm version, signature algorithm version, and key ID so that audits can confirm what cryptographic policy was used.

Fault tolerance must be specified as a contract. If writing fails, emit a distinct “log write fail” status where possible. If storage wear approaches limits, raise severity and reduce write frequency while preserving critical events. The system should prefer immutable evidence continuity over cosmetic “clean logs.”

H2-9. Key / Signature Management

Keys and signatures become compliance-grade engineering only when they are defined as roles, governed by lifecycle policy, enforced by anti-rollback rules, and bounded by field-service authorization with auditable evidence records.

A defensible design separates keys by role so that a compromise in one domain does not invalidate all evidence. At minimum, isolate provisioning identity from firmware authorization, log integrity, and service tooling. Each key type must have an explicit allowed-operation set, storage boundary, and audit trail requirements.

• Provisioning (manufacturing) keys: establish device identity and root-of-trust bindings. Highest isolation and strictest audit requirements are expected.
• Firmware signing keys: authorize executable images and upgrade paths. Must support rotation and revocation with device-enforced rejection of revoked signers.
• Log signing keys: provide non-repudiable evidence for field events. Keep separate from firmware keys to prevent “one-key breaks all evidence.”
• Service tool / operator keys: authorize reading evidence, clearing latches, entering service mode, triggering diagnostic injection, and performing updates under controlled policy.

Anti-rollback cannot be reduced to “no downgrade.” Use monotonic counters for firmware and for policy artifacts (log format, signature algorithm policy, revocation list version). If rollback is permitted under exceptional rules (e.g., approved remediation), the policy must specify the allowed set and require an auditable record: who performed it, why it was performed, and which versions were involved.

H2-10. Verification Plan

Verification becomes audit-ready when all safety and compliance requirements are translated into a test matrix with pass criteria, traceability bindings (FW/HW/cal versions), and an evidence package manifest with hashes and archive locations.

The core deliverable is a test matrix that maps each safety function to explicit test cases. Every test case must define setup, stimulus, pass criteria, and required artifacts. The matrix must also bind results to immutable traceability: firmware version, hardware revision, calibration/versioned policy, and a results hash with an archive URI.

• Matrix mapping: Safety Function ID → Test Case ID → Setup (VIN/load/temp/mode) → Stimulus (fault injection / surge / ESD / dip curve) → Pass criteria → Artifacts.
• Critical tests (evidence-oriented): hipot/leakage, insulation distance inspection, temperature rise and abnormal operation, and immunity (ESD/EFT/Surge/RF/voltage dips) with performance criteria and recovery behavior.
• Immunity success is more than “no reboot”: expected reaction strategy must occur, hazardous output must remain bounded, and the event must be correctly recorded with a verifiable log chain.

H2-11. Manufacturing & Field Ops

Many safety/compliance failures are process failures: missing factory proof, field actions that erase evidence, and RMAs that cannot map logs to batches and root causes. This chapter defines an evidence-closed loop from factory gate to field service to RMA return.

A production-ready program treats “pass” as a deliverable evidence package. Factory validation should prove: (1) device identity and provisioning records match, (2) selected safety functions can be demonstrated end-to-end (trigger → reaction → energy below safe criterion), and (3) the tamper-evident log chain and signature policy verify correctly at shipment time. The output is a manifest that binds device identity to versions, artifacts, hashes, and archive locations.

Field operations must be policy-driven, not “technician judgment.” Evidence should be exported in read-only form before any action that could change device state (unlocking latches, firmware update, storage maintenance). Controlled unlock must require prerequisites (fault source removed, cool-down achieved, input stable) and must always write a signed service record (operator identity, session ID, reason code, counter snapshot). Evidence erasure by default is disallowed: if a wipe is unavoidable, it must be explicitly authorized, logged, and linked to an exported manifest.

• Read-only export first: log bundle + context snapshot + verification result (key ID/policy version/counter) + manifest hash.
• Controlled unlock: explicit prerequisites + rate limits to prevent oscillatory restart behavior; every unlock is logged and signed.
• Update/repair actions: export evidence before change; record version deltas and anti-rollback counter snapshots after change.
• Three prohibitions: no unauthorized fault clearing, no firmware flashing before evidence export, no critical part swaps without mapping records.

RMA (return/repair) closes the loop only when each returned unit can be mapped to (a) exported evidence manifests, (b) provisioning records and policy versions, (c) batch/lot traceability, and (d) a root-cause taxonomy that feeds corrective action and regression testing. A useful taxonomy distinguishes design defects, manufacturing variation, field misuse, environmental exceedance, service misuse, and adversarial tampering—each with minimum required evidence fields.