Street/Tunnel operating boundary (minimum spec envelope)

• Input domain: regional mains examples (120/230/277VAC), frequency, brownout window, short interruption tolerance, inrush constraints.
• HV bus domain: rectified/PFC bus range, allowable bus ripple band, UVLO/OVP thresholds and hysteresis targets.
• LED load domain: string count and Vf range, constant-current setpoint range, open/short fault modes, intermittent connector behavior (bounce).
• Environment domain: temperature span, humidity/condensation, vibration/shock, corrosion/salt exposure (tunnel/roadside severity).
• Control domain: required vs optional control interfaces (local dimming, DALI/PLC/wireless as system options), safe default state when control is lost.
• Protection domain: surge target (10kV+), ESD/EFT exposure, isolation/leakage expectations (high-level boundary only).

Practical rule: write each boundary item as “Must / Should / Optional” and attach at least one verification artifact (waveform, event counter, fault flag, or recovery time).

What “good” means in street/tunnel deployments

• Surge survivability (10kV+): no component damage, no persistent lock-up, controlled recovery (no random flicker, no reset storm).
• Brownout immunity: during voltage sag, output behavior remains deterministic (hold / controlled dim / safe-off policy), then clean return.
• Fault containment: a single-string fault does not cascade into luminaire-wide failure; bypass/derate policy is predictable and logged.
• Serviceability: the driver explains itself—events are timestamped, categorized, and linked to measurable snapshots for field diagnosis.

Domain nuance: peak efficiency alone is not a success metric. Street/tunnel acceptance depends on behavior under stress (surge/brownout/temperature) and maintainability.

Minimum evidence set (what to measure or log)

• Event counters: surge_event_count, brownout_count, bypass_trigger_count, comms_drop_count.
• Reset attribution: reset_reason (POR/BOR/WDT/UVLO/OVP/OTP), plus “recovery_state” (recovering/normal/fail-safe).
• Fault flags: UVLO/OVP/OTP, LED open/short detect, bypass active, control lost (timeout), self-test status.
• Event snapshot (4–6 fields): Vin/Vbus, I_LED, temperature (NTC), dimming level, interface state (local/networked).
• Histograms (optional but powerful): runtime_hours, temperature histogram buckets, restart interval distribution.

Why “minimum” matters: storing fewer high-signal fields enables reliable postmortems without exhausting storage or bandwidth.

Define “must not happen” states upfront

• Reset storm after surge (repeated reboots in a short time window).
• Random flicker during brownout or immediately after recovery (no policy, no hysteresis).
• Bypass triggers on a healthy string (threshold drift/noise/transient misclassification).
• Loss of control interface causes unpredictable default state (sometimes on, sometimes off, sometimes flicker).
• Thermal derating oscillates (no hysteresis) and produces visible brightness hunting.
• Fault occurs but leaves no actionable trace (no event category, no snapshot, no reset attribution).
• Surge “passes” but latent degradation causes increased leakage, heat, or reduced immunity over time without detection.

A: PFC + (isolated or non-isolated) CC + comms isolation

• Best fit: tunnel/highway deployments where surge/brownout behavior must be deterministic and control uptime matters.
• Core advantage: control-plane is protected from power-plane stress; recovery can be staged (power first, comms second) to avoid flicker storms.
• Key design contract: define startup ordering and safe default state when comms resets (no unpredictable output).
• Fault containment: string-level detect + bypass + logging can be implemented without letting comms instability trigger unsafe output.

Evidence targets: recovery_time_after_surge, reset_reason distribution, comms_uptime_ratio, and efficiency at low/mid/high power points (not just peak).

B: PFC + non-isolated CC + external node controller

• Best fit: modular maintenance (replace node/controller independently), or fast-evolving connectivity requirements.
• Main risk: power-plane disturbances can desynchronize node vs driver state, causing visible misbehavior (unexpected relight, brightness jumps).
• Integration rule: driver must remain stable and deterministic even if the node resets or temporarily disappears.
• Field diagnostics: node/driver should share a minimal common event timeline (sequence numbers or timestamps).

Evidence targets: comms_drop_count correlated with surge_event_count, startup-order trace (who boots first), and “default output policy” compliance during node outage.

C: Integrated smart node (power + control + sensing in one module)

• Best fit: strong telemetry/asset management needs, sealed luminaires, predictive maintenance, energy/runtime reporting.
• System risk: integration increases single-point failure blast radius unless surge partitioning and recovery throttling are explicit.
• Must-have mitigations: event snapshots, restart throttling, robust fault containment, and predictable safe mode.
• Service model alignment: ensure the operator accepts “module swap” vs “component-level repair” tradeoff.

Evidence targets: event log completeness (snapshots), self-test coverage, and controlled recovery state machine behavior.

Selection rules (avoid the most common street/tunnel failure modes)

• Prefer A when: 10kV+ events are frequent, control stability is mandatory, and “no-flicker recovery” is a hard requirement.
• Prefer B when: modular replacement is key and connectivity changes frequently—only if default output policy remains safe during node resets.
• Prefer C when: telemetry is central and the service model supports module swaps—only if single-point failure is mitigated by strong partitioning.
• Regardless of choice: define (1) recovery ordering, (2) safe default state, (3) restart throttling, (4) bypass/log behavior.

Where CC error comes from and how it is reduced

• Sense resistor tolerance + TCR: initial % error plus temperature drift; reduce with low-TCR parts, Kelvin routing, and heat isolation from power hot spots.
• Current-sense amplifier offset/drift: input offset and temperature drift can dominate at low currents; reduce with low-drift devices and controlled input filtering bandwidth.
• ADC quantization + reference error (if digital trim/telemetry): quantization noise and Vref drift; reduce with stable references, synchronized sampling, and averaging.
• PCB thermal gradient: local heating shifts Rsense and nearby analog; reduce by thermal spreading copper, distance from switching hot spots, and consistent airflow paths.
• Switching noise injection: SW node coupling into sense lines causes apparent current ripple; reduce with routing separation, RC filtering, and disciplined ground referencing.
• Gate-drive delay / PWM non-idealities: duty-cycle edge timing changes average current; reduce by avoiding extreme duty regions and using stable switching conditions.
• LED Vf drift and string variation: changes loop headroom and operating region; reduce by allocating voltage margin and pairing with derating and bypass policy.
• Bus ripple coupling: Vbus ripple can modulate ILED if rejection is weak; reduce with bus control targets and suppression strategies (verification-focused, not topology-specific).
• Humidity/leakage effects (outdoor/tunnel): leakage paths shift measurement; reduce with creepage strategy, conformal protection, and leakage monitoring.
• Aging drift: long-term parameter shift in protection and sensing; reduce with periodic self-checks and drift-aware thresholds plus event statistics.

Practical prioritization: in street/tunnel drivers, the first wins typically come from (1) Rsense + layout, (2) amplifier drift/noise pickup, and (3) thermal gradient management—because field temperature swings and stress events are unavoidable.

Four transitions that expose unstable behavior

• Start-up (cold/hot): avoid visible flash or overcurrent peaks; validate with I_LED peak, settling time, and protection flags.
• Dimming step: maintain monotonic response without ringing; validate with overshoot %, recovery time, and ripple change at the new level.
• Thermal derating transition: prevent “brightness hunting” near thresholds; validate with derating state toggles, hysteresis behavior, and temperature vs current trajectory.
• Line/bus disturbance: prevent bus ripple or line changes from modulating light output; validate V_BUS disturbance vs I_LED ripple envelope and low-frequency components.

Street/tunnel nuance: a small low-frequency envelope on I_LED can become a visible complaint in tunnels and low-illumination scenes. Verification must inspect the envelope, not only high-frequency ripple.

What to observe without protocol or standard deep-dives

• Observe points: I_LED waveform, V_BUS waveform, and dimming command (PWM/analog reference).
• Focus metric: I_LED ripple %, plus presence of a low-frequency envelope that tracks V_BUS or derating toggles.
• High-risk moments: deep dimming levels, recovery after brownout, and transitions into/out of thermal derating.
• Pass expectation: stable output policy—no random flicker, no repeated restarts, no threshold hunting visible to end users.

Evidence triad: (1) ripple % at key dimming points, (2) overshoot/recovery time at steps, (3) hot steady-state drift curve (temperature vs I_LED).

Minimum verification artifacts

• Waveforms: V_BUS, I_LED, dimming command; optionally annotate SW node as a “marked point” only.
• Step response summary: overshoot %, recovery time, and ripple change at the target level.
• Thermal curve: I_LED drift after thermal stabilization plus derating transition behavior (toggle count).
• Flags/log hooks: UVLO/OVP/OTP and fault flags at the time of any abnormal waveform behavior.

Field practicality: when SW node probing is not feasible, V_BUS + I_LED + reset_reason/fault_flags can still separate line disturbance, restart storms, and threshold hunting.

Protection chain roles (energy vs clamp vs speed)

• GDT: handles high energy but triggers slower; manage follow-current behavior and ensure the downstream path remains controlled.
• MOV: primary energy absorption; plan for aging (clamp shift and leakage rise) and include monitoring-friendly test points.
• TVS: fast clamp for sensitive nodes; do not force it to absorb large surge energy—use it to protect control/communication points.
• System rule: large energy belongs to MOV/GDT; fast sensitive protection belongs to TVS; verify that no single element is overloaded by design.

Pass definition: surge exposure must not cause immediate failure or silent degradation that later shows up as increased leakage, abnormal heating, or reduced immunity.

Threshold windows, hysteresis, and staged restart

• UVLO/OVP thresholds + hysteresis: prevent chatter at boundary conditions so the driver does not oscillate between on/off states.
• Soft-start: control current ramp to avoid flash/overshoot after recovery (especially after a brownout induced by the surge event).
• Restart throttling (anti-reset-storm): enforce minimum restart spacing and escalation rules when repeated faults occur.
• Recovery observables: recovery time, peak I_LED during restart, and reset_reason distribution.

Street/tunnel expectation: a driver that “eventually turns on” but exhibits repeated restarts or random flicker is a functional failure in the field.

Safe default output policy under comms dropout/reboot

• Control-plane independence: constant-current control must remain stable even if DALI/PLC/wireless modules reset or temporarily disappear.
• Deterministic default state: define one policy (hold last / controlled dim / safe-off) appropriate to deployment; avoid “random on/off” behavior.
• Rejoin behavior: upon comms recovery, return smoothly (bounded ramp) to avoid brightness step complaints.
• Logging hook: record control_lost flag, last_valid_cmd time, and the chosen default_policy_id during each event.

Key idea: “No flicker” is a policy requirement enforced by state machine design, not only a component selection outcome.

Common surge-related traps and how they show up

• MOV aging → leakage increases: appears as higher standby heat, unexpected trip behavior, or reduced margin over time; validate with before/after leakage and temperature.
• GDT follow-current: can create repeated conduction events or pull the bus into unstable states; validate via event timing and recovery-state transitions.
• TVS thermal runaway: may short after stress and cause brownout/reset storms; validate through clamp node behavior, reset_reason, and recovery time anomalies.
• False classification: transient spikes misread as open/short or bypass triggers; validate with time-window logic and event snapshots.

What to compare around a surge campaign

• Before: leakage_baseline, thermal_baseline, reset_rate_baseline, and nominal recovery time from controlled brownouts.
• After: leakage_delta, MOV temperature rise, reset_reason histogram shift, surge_trigger timestamps, and recovery_time distribution.
• Minimum snapshot: Vin/Vbus, I_LED, temperature, fault_flags, recovery_state, default_policy_id.

Interpretation rule: passing a surge shot is not the end; the goal is to prove the system returns to the same behavior envelope without drifting into latent instability.

Typical grid events and how they present on the bus

• Voltage sag (slow droop): AC RMS decreases and V_BUS falls with a gentle slope; risk is low-frequency modulation and threshold hunting near UVLO.
• Short interruption (dip / dropout): tens to hundreds of ms gaps; V_BUS collapses quickly; risk is visible light dropout or repeated restarts.
• Surge-followed sag: protection engages and the line “falls back” afterward; risk is recovery instability (flash, reset storm, false fault classification).
• Frequency shift (minor): may alter boundary timing and stress margins; treat as a “corner condition” rather than a primary design driver.

Stability-first rule: in street/tunnel lighting, a controlled brightness reduction is preferable to random flicker or repeated restarts.

Engineering handles that keep light behavior predictable

• Hold-up time: use bus energy storage plus bounded power draw so short interruptions do not produce visible instability.
• UVLO hysteresis window: prevent chatter around thresholds; widen hysteresis and enforce minimum “on/off dwell” timing.
• Bus strategy under droop: keep I_LED response smooth as V_BUS falls; prioritize envelope stability over fast tracking.
• Stability-first derate: enter a controlled reduced-output mode before UVLO is reached; define clear enter/exit criteria with hysteresis.
• Restart throttling (anti-reset-storm): enforce minimum restart spacing and escalation rules if repeated brownouts occur.

Verification focus: the design target is not “maximum brightness during droop,” but “bounded, non-flickering output with deterministic recovery.”

Convert complaints into waveforms and immediate actions

• “One quick flash, then normal” → check V_BUS + I_LED alignment → reduce recovery step (ramp limit) and tighten threshold transitions.
• “Restarts every few seconds” → check V_BUS + start_interval_stats / reset_reason → add UVLO hysteresis + enforce restart throttling.
• “Random flicker during sag” → check V_BUS ripple/envelope + I_LED envelope → enter stability-first derate earlier and eliminate threshold hunting.
• “After a surge, it stays off too long” → check fault_flags + recovery_state timing → fix recovery state machine windows (cool-down, soft-start slope, OVP/UVLO release logic).
• “Only visible at low dim level” → check I_LED ripple% + derate/UVLO toggle count → remove low-frequency envelope sources and prevent rapid state toggling.
• “Flicker bursts during comms reset” → check default_policy_id + I_LED → enforce deterministic default state (hold/ramp/fixed/safe-off) during control-plane dropout.

Two-signal discipline: most brownout issues are diagnosable using V_BUS (TP2) plus one additional signal (I_LED, reset_reason, or start interval statistics).

Minimum artifacts that prove immunity

• V_BUS droop curve: droop slope, minimum level, and recovery time after disturbance.
• Hold time: duration that I_LED/brightness remains stable (or controlled-derated) through a defined interruption.
• reset_count + reset_reason_histogram: distribution of UVLO/WDT/OVP causes under disturbance campaigns.
• start_interval_stats: min/median/max restart spacing; periodic spacing indicates a reset storm.
• brownout_event_counter + last_brownout_timestamp: field maintainability and remote triage readiness.

Separate real-time safety from network behavior

• Local driver control: constant-current regulation, protection, thermal derating, brownout state machine, bounded ramps.
• Network control: scenes, groups, scheduling, remote configuration; latency and packet loss must not destabilize light output.
• Safety default policy: deterministic behavior when control is lost (hold / ramp / fixed / safe-off), with explicit enter/exit rules.

Non-negotiable rule: network control must never bypass local safety limits or force uncontrolled output transitions.

What the network module may request—and what the driver core enforces

• Inputs to driver core: target level, ramp rate limit, scene identifier, optional time window (valid-until timestamp).
• Driver enforcement: range clamp, slew-rate clamp, timeout handling, and stability-first derate during disturbances.
• Outputs to network module: fault flags, event counters, last_valid_cmd_time, and a compact telemetry snapshot.

Maintainability benefit: protocol changes remain inside the comms module while the driver core preserves stable light behavior.

Prevent surge/ESD events from dragging the control domain into instability

• Isolation strategy: isolate or strongly partition the comms domain so it may reset without collapsing the driver core.
• Protection routing: provide a controlled discharge path for ESD/surge energy; avoid injecting stress into MCU or reference grounds.
• Ground reference discipline: keep noisy power returns from modulating comms reference and causing false resets.
• Power sequencing: comms brownout should not create repeated driver resets; default policy must cover comms reboot windows.

Field operations should be rate-limited and auditable

• Identity & address: stable node ID / address mapping supports truck-roll minimization.
• Remote reset policy: rate-limit remote resets and define escalation (cool-down) to avoid reset storms.
• Logs for triage: snapshots around disturbances (fault_flags, reset_reason, recovery_state, default_policy_id) enable remote diagnosis.
• Command validity: timestamps (last_valid_cmd_time) prevent stale commands from causing unexpected output steps after recovery.

Signals that prove partitioning works

• link_drop_counter + rejoin_counter: connectivity health without forcing output instability.
• cmd_latency_stats: min/median/max delay; correlate spikes with output policy transitions (should remain bounded).
• control_lost_flag + last_valid_cmd_time: prove default policy takes over deterministically during dropouts.
• watchdog_reset_reason: ensure comms resets do not propagate into driver reset storms.
• default_policy_id + policy_change_log: verify configured behavior is auditable and stable across firmware updates.

DALI / PLC / Wireless: what belongs here vs elsewhere

• DALI integration card: focus here on driver-core boundary + deterministic default policy; protocol and addressing details belong to the DALI interface subpage.
• PLC integration card: focus here on immunity and brownout behavior under line noise; coupling/modem/network details belong to the PLC control subpage.
• Wireless integration card: focus here on comms reboot windows and secure default behavior; radio/stack/OTA details belong to the wireless node subpage.

Street/tunnel fault handling is about controlled behavior, not hiding failures

• Containment: a single string/segment fault must not collapse the entire luminaire.
• No misbehavior: prevent visible flicker bursts, restart storms, or uncontrolled brightness steps.
• Forensics: every bypass action must leave an auditable trace (what happened, where, and why).
• Policy split: street deployments often prefer “derate & continue”; tunnels may prefer “safe-off / safe-degrade” for higher safety margin.

Hard rule: bypass is a state-machine decision (with time windows and recovery rules), not a raw comparator trip.

Failure modes that matter in outdoor/tunnel deployments

• LED open: I_LED cannot sustain; V_STRING rises toward its limit; may present as sudden dropout or repeated restarts.
• LED short: V_STRING unexpectedly low; segment voltage distribution changes; thermal redistribution risk.
• Leakage / moisture: insulation degrades; measurements drift; may trigger false faults or violate safety assumptions.
• Connector intermittent open: bursty dropouts with repeat signature; often correlates with vibration and thermal cycling.
• Degradation / headroom shortage: reduced margin (V_BUS or string headroom) drives regulation into saturation and causes visible instability.

Two-signal baseline: most classifications start from V_STRING (TP7ᵢ) + I_LED (TP4), plus optional temperature correlation (TP-T).

Choose the containment level and define the behavior policy

• Segment-level shunt bypass (partial bypass): masks local open/abnormal segments; keeps the string operating with reduced Vf and controlled output loss.
• String-level bypass (whole-string bypass): isolates an entire failing string so other strings remain stable; simplifies containment in multi-string luminaires.
• Derate & continue: reduce I_LED or cap maximum dim level to avoid instability while maintaining illumination (street-oriented).
• Safe-off / safe-degrade: for leakage/safety-critical anomalies, prefer deterministic safe states over continuing output (tunnel-oriented).

Policy must bind to fault class: avoid a one-size-fits-all rule that “always bypasses” or “always shuts down.”

Prevent bypass actions from being triggered by disturbances

• Threshold discipline: define V/I thresholds with tolerance and temperature drift budgets; avoid marginal thresholds that chatter near boundaries.
• Time windows: require persistence (N ms) before enabling bypass; use count-based accumulation for intermittent faults rather than one-shot triggers.
• Temperature correlation: record temperature and optionally use temperature-gated logic to avoid false classification during transient thermal gradients.
• Post-surge / post-brownout mask: during recovery windows, suppress irreversible bypass decisions or raise trigger requirements.
• Anti-hunt rules: enforce minimum dwell time per state; prevent oscillation between bypass and restore.

Field reality: many “mystery bypasses” are actually recovery transients unless the design explicitly masks and logs these windows.

Use a repeatable record for every fault pathway

• Fault: open / short / leakage / intermittent / headroom shortage
• Detect signals: V_STRING(TP7ᵢ) + I_LED(TP4), optional V_BUS(TP2), Temp(TP-T), and state-machine state
• Action: segment bypass / string bypass / derate / safe-off
• Recover: clear condition (stable normal window) + hysteresis + optional manual confirmation; rate-limit recovery attempts
• Record fields: event_type, string_id/segment_id, trigger_threshold_id, pre_snapshot(V/I/T/state), timestamp, repeat_count, recovery_time

Mandatory: always capture a pre-trigger snapshot so remote triage can distinguish “real LED fault” from “grid transient.”

Temperature sensing must reflect the real hotspot behavior

• Hot vs cold points: place sensing near relevant thermal bottlenecks; avoid relying solely on enclosure temperature.
• Thermal path bias: potting, interface materials, and mounting change response time; validate rise/fall dynamics.
• Gradient awareness: tunnel airflow and outdoor weather create gradients; log conditions and avoid over-trusting a single point.
• Sanity checks: compare expected power-to-temp trends and detect sensor anomalies (stuck readings, offsets).

Evidence principle: confidence comes from consistent power↔temperature correlation over time, not from a single calibration moment.

Define entry, execution, and exit with hysteresis

• Entry: multi-level temperature thresholds that trigger derating before instability or safety limits are approached.
• Execution: step or ramp reduction of I_LED, power limiting, and/or a maximum dim level cap.
• Exit: temperature hysteresis + minimum dwell time to prevent oscillation (anti-hunt).
• Slew control: bound change rate so brightness shifts remain smooth and non-flickering.

Stop “derate ↔ restore” flapping that creates visible artifacts

• Hysteresis windows: separate enter/exit thresholds and enforce stable residence time per state.
• Rate limiting: cap how fast output is allowed to rise after cooling; avoid sudden jumps.
• Coherence with brownout strategy: during grid disturbances, prefer stable derate states and suppress aggressive recovery.
• Logging for proof: record state transitions with timestamps and durations to show the system is not hunting.

Maintain target illumination under aging—within thermal limits

• Goal: keep practical illumination targets across seasons and aging without violating thermal margins.
• Strategy: controlled long-term compensation (within caps) paired with temperature-aware limits.
• Constraints: any maintenance uplift must respect derating ceilings; do not trade safety/lifetime for short-term brightness.
• Auditability: maintenance-related setpoint changes must be logged and reversible.

This section intentionally avoids standards and physics deep-dives; it focuses on deployable strategies and verifiable evidence.

Artifacts that prove thermal policy is working

• Temperature histogram: distribution over time (day/night and seasonal signatures).
• Derating timeline: number of entries, total duration, and maximum level reached.
• Current drift trend: long-term I_LED behavior to catch calibration and aging effects.
• Maintenance delta: before/after brightness difference and how it changes derating frequency.
• Thermal event counters: over-temp near-miss counts and time spent near limits.

Use a 3-layer logging system that matches field reality

• Event snapshots: triggered records that capture “what just happened” with a compact pre/post window.
• Periodic rollups: low-rate statistics (histograms, counters, durations) for slow trends and seasonal signatures.
• Identity header: device + firmware + policy versioning so logs remain comparable across fleets and updates.

Design rule: use high-value snapshots for fast transients, and rollups for long-term drift. Avoid high-rate raw streaming.

Events that must be recorded to make maintenance cheap

• Surge / lightning event: protection action, recovery entry, or abnormal rail excursion markers.
• Reset reason: watchdog / brownout / software / manual / protection-triggered restart.
• Bypass events: segment/string bypass enter/exit, including the target (string_id/segment_id).
• UV/OV/OTP & derating transitions: enter/exit of undervoltage, overvoltage, overtemp, and derating levels.
• Comms loss: link timeout, last-valid-command expiry, and rejoin/retry bursts (type-tag only).

Field mapping: these five categories cover the dominant “not reproducible in the lab” cases: grid disturbances, thermal gradients, moisture/corrosion, and intermittent wiring.

Combine event snapshots with rollups instead of constant logging

• Event snapshot: record a compact pre-trigger summary (min/max over a short window) and the state-machine state.
• Periodic rollup: write histograms and counters at a low cadence (minutes), not waveforms.
• Rate limits: cap how many snapshots of the same type can be emitted per hour to avoid storm writes.
• Backpressure behavior: when storage is near full, keep recent + critical summaries; degrade gracefully rather than stopping.

Maintenance-first priority: always keep “why it restarted”, “why it bypassed”, and “how long it stayed in derate”.

Smallest payload that still classifies most field issues

• Identity: device_id, fw_version, policy_version (and threshold_id if available)
• Event header: event_type, event_id, timestamp, uptime
• Snapshot: vin, vbus, i_led, temp (temp_hot preferred), optional vstring
• State: recovery_state, derate_level, bypass_state
• Flags: fault_flags (UV/OV/OTP/COMMS/BYPASS)
• Counters: reset_count, repeat_count (for intermittent signatures)

Why versioning matters: without policy/threshold versioning, the same event pattern may be misinterpreted after a firmware update.

Three “read once” diagnoses using the minimum fields

1. “Surge then unstable”: surge_event appears, recovery_state stays in recover, reset_reason repeats, vbus is depressed near restart.
   Likely class: grid disturbance / recovery policy issue.
   First action: recovery throttling + UVLO hysteresis review + confirm SPD aging counters.
2. “One string drops intermittently”: bypass_event repeats on the same string_id, repeat_count grows, temperature is stable, vstring is noisy.
   Likely class: connector/wiring intermittency or localized degradation.
   First action: physical inspection of that string path (connector, solder joints, strain points).
3. “Night-time brightness capped”: derate_level enters frequently and stays long, temp histogram is heavy in high bins, resets are absent.
   Likely class: thermal bottleneck (enclosure, potting, mounting, airflow).
   First action: thermal path audit + verify potting/adhesive heat resistance impact + mounting conditions.

Sealing improves protection, but changes heat and maintenance outcomes

• Better sealing often increases internal thermal stress (hotter operation and more derating time).
• Condensation risk creates leakage paths and measurement drift, especially in high-voltage zones.
• Serviceability declines when sealing and adhesives prevent access to connectors and test points.

Verification focus: compare leakage/IR before and after humidity exposure, and track derating durations after enclosure changes.

Reliability gains come with thermal and repair penalties

• Moisture + vibration robustness improves, but repairability typically drops sharply.
• Thermal path uncertainty increases: potting changes heat resistance and sensor credibility.
• Creepage surfaces may improve (depending on partitioning), but uncontrolled potting edges can create unexpected paths.

Evidence checks: thermal resistance shift (same power → steady-state temperature), and IR/leakage shift after damp heat.

Use partitioning to make unsafe paths hard to form

• Zone separation: keep HV power, LV control, and comms physically partitioned with barriers/slots.
• Surface path control: avoid sharp corners and “water/contamination collection” geometries that shorten surface leakage paths.
• Metal hardware awareness: fasteners, shields, and brackets must not create cross-zone shortcuts.
• Inspection points: define clear “HV boundary lines” that can be checked visually during assembly and service.

Corrosion often appears as intermittent faults and thermal anomalies

• Contact resistance rises → local heating → more derating and intermittent behavior.
• Leakage paths form → false protection/bypass triggers and unstable readings.
• Field signature: damp-heat exposure correlates with rising event counters (comms loss, bypass repeats, near-OTP entries).

Make “fast field isolation” possible without tearing the luminaire apart

• Module partition: keep HV power, LV control, and comms/sensors separable where possible.
• Replaceable path: connectors and wiring should be inspectable and replaceable without destroying sealing features.
• Readable identity: string_id labeling + log access reduce guesswork and shorten on-site time.

Deployment-friendly robustness rules

The checklist is intended to keep the section scope practical: electrical robustness emerges from enclosure choices plus verifiable evidence.