UV-C Control & Safety for Dose Metering and Interlocks
← Back to: Lighting & LED Drivers
UV-C Control & Safety is about proving two things with measurable evidence: the device delivers the required dose at the target plane, and it always fails safe (default-OFF) when interlocks, leakage sensing, timers, or power integrity indicate risk. This page shows how to design the dose metering + safety chain, and how to validate it using logs, calibration records, and acceptance tests—so “dose” and “safety” are auditable, repeatable, and field-debuggable.
H2-1. Scope, system boundary, and what success looks like
Chapter intent (why this must come first)
UV-C safety fails when the design focuses on “turning UV on” instead of proving a closed chain: permission → controlled emission → continuous monitoring → deterministic cutoff → auditable evidence. This chapter locks the boundary and defines success criteria that can be measured on the bench and in production.
System boundary (what this page owns vs ignores)
- UV source (black box): UV-C LED arrays or lamps are described only by measurable radiometric output, warm-up behavior, temperature dependence, and aging drift. The internal driver topology is out of scope.
- Optics / enclosure: defines where UV is allowed to go (aperture) and where it must never go (seams, vents, cable exits). This is the primary surface for leakage risk.
- Target plane: the plane where “dose” is defined (dose is not a property of source current; it is delivered energy at the target).
- Safety control: interlock chain, timers/watchdogs, dose & leakage monitors, and logging (the core of this page).
Practical rule: if a feature does not directly change “dose correctness” or “exposure prevention”, it does not belong on this page.
The control & safety chain (the invariant backbone)
Treat UV-C as a state machine with explicit proofs per transition. Each block below must have (1) an input condition, (2) a measurable output, and (3) a fail-safe behavior.
-
1
EnableInterlocks valid + arming policy satisfied → emission permitted.Proof: latched interlock status + arm reason logged.
-
2
EmitUV source active only while safety conditions remain true.Proof: emission state + runtime counters recorded.
-
3
Monitor doseCorrected irradiance → integrated dose accumulator at defined plane.Proof: irradiance_raw/irradiance_corr + dose_accum + sampling health.
-
4
Monitor leakagePerimeter/stray UV sensing monitors forbidden regions continuously.Proof: leakage level + persistence time + trip cause.
-
5
Cut offAny unsafe condition forces a hard transition to SAFE_OFF (critical faults latch).Proof: cutoff timestamp + reason + clear method (manual acknowledge / key-cycle).
-
6
LogEvent records make safety auditable and debuggable.Proof: fixed schema + retention policy + integrity checks.
Success criteria (measurable, testable, non-negotiable)
- Dose correctness class: explicitly label whether the system proves target-plane dose (direct or verified sensing) or only estimates dose (model/proxy). Define the associated error budget and the “worst-case low dose” margin (used as acceptance threshold).
- Leakage thresholding concept: define threshold, persistence window, and reset policy. Engineering-friendly rule form: leakage > T for Δt ⇒ SAFE_OFF + LATCH + log.
- Interlock stop time: define maximum time from “interlock open” to “emission terminated”, and verify it by measurement.
- Fail-safe defaults: any power-up/reset/brownout must land in SAFE_OFF; no automatic resume-to-ON after restart or fault.
- Traceability: every exposure session can be reconstructed from logs: initial conditions, sensor readings, computed dose, cutoffs, and faults.
Evidence to capture (minimum record set that prevents “hand-wavy safety”)
Define the evidence schema early; later chapters must populate it without exceptions:
- Interlock snapshot: door/key/e-stop/service bits + debounced state + open duration
- Emission state: SAFE_OFF / ARMED / EMITTING / FAULT_LATCHED + state transition timestamps
- Dose telemetry: irradiance_raw, irradiance_corr, dose_accum, dose_target, integration health
- Leakage telemetry: leakage_raw, leakage_corr, persistence_ms, trip threshold, trip flag
- Timing: session_timer, cumulative_timer, watchdog events, power anomaly counters
- Calibration: coefficient version, date, validity, temperature range assumptions
- Fault: fault_code, latch flag, clear method, last-known sensor snapshot
- Runtime/aging: runtime hours, temperature (at least one), maintenance counters
Acceptance test list (what will be proven on the bench / in production)
- Default OFF: prove SAFE_OFF after power-up/reset/brownout (no “resume ON”).
- Interlock stop time: measure “interlock open → emission stops” and compare to requirement.
- Timer cutoff: prove max-session and cumulative limits force SAFE_OFF under fault injection.
- Leakage trip: induce controlled leakage and verify SAFE_OFF + latch + logged evidence.
- Audit trail: verify required log fields exist for every session and every cutoff event.
H2-2. UV-C dose fundamentals and an engineer’s error budget
Dose is an integral, not a setting
Dose is delivered energy per area. In engineering terms, dose is computed by integrating irradiance over time at a defined plane (the target plane): dose (mJ/cm²) = ∫ irradiance (mW/cm²) dt. Any dose claim is incomplete unless it states (1) where irradiance is defined, (2) how it is sampled, and (3) which corrections are applied.
- Irradiance: instantaneous UV-C power per area at a specific plane and orientation.
- Dose: time-integrated irradiance; integration must be robust to dropouts, saturation, and filtering delay.
- Minimum guaranteed dose: conservative value after subtracting negative contributors in the error budget.
Discrete-time integration (what the firmware must decide)
Real systems integrate samples. The implementation choices below directly change dose accuracy and safety margins.
- Sampling cadence: choose a cadence that captures expected intensity changes (warm-up, PWM windows, motion).
- Missing samples: define a rule (hold-last, decay-to-zero, or invalidate session) and log when it happens.
- Clipping/saturation: if the sensor or ADC saturates, the dose estimate becomes untrustworthy; handle as a fault or conservative bound.
- Timebase integrity: dose is proportional to time; track timebase health (watchdog resets, clock drift indicators).
- Filtering: avoid filters that delay detection of unsafe spikes; separate “display smoothing” from “safety decisions”.
Recommended logged fields for dose integrity
- irradiance_raw, irradiance_corr, dose_accum, sample_period_ms
- sample_drop_count, sensor_saturation_count, integration_state (valid/invalid)
- cal_version, cal_valid, temp (at least one), runtime_hours
Geometry and environment terms (why “stable output” can still under-dose)
Even if UV source output is stable, delivered irradiance at the target plane can vary due to geometry and medium effects. These effects belong in the error budget as bounded factors (not as vague warnings).
- Distance & orientation: off-axis targets reduce effective irradiance; sensor cosine response matters.
- Shadowing: occlusions create local under-dose zones that near-source sensors may not detect.
- Reflectance paths: reflectors can boost dose locally while increasing seam leakage risk.
- Airflow / turbidity (context): scattering/absorption changes energy delivery; treat as a correction factor if the product’s application includes it.
Error budget template (spreadsheet-ready, design-decision forcing)
A useful error budget forces decisions. It must separate contributors by source, sign, and evidence method. The goal is to compute a conservative worst-case low dose that is still above the minimum required dose.
- Sensor calibration: reference uncertainty, linearity, repeatability, spectral mismatch, dark offset.
- Placement/model mismatch: sensor sees a different flux than the target plane; geometry tolerance & baffle effects.
- Temperature: responsivity changes with temperature (sensor) and output shifts with temperature (UV source).
- Drift & aging: source aging, window contamination/yellowing, sensor drift; define runtime-based bounds.
- Integration: sample cadence, missing-sample policy, saturation handling, timebase integrity.
Columns that make the budget auditable
- Contributor (e.g., “sensor gain”, “placement”, “aging factor”, “temp factor”, “sample dropouts”)
- Type (systematic / random / bounded)
- Sign (reduces dose / increases dose / both)
- Bound (±% or absolute mapped to mW/cm² and then mJ/cm²)
- Mitigation (calibration, mechanical constraint, self-test, fault rule)
- Evidence (test ID, log fields, cal version)
Worst-case low dose margin (how to turn the budget into a safety criterion)
Avoid using nominal calculated dose as the acceptance criterion. Use a conservative margin based on the lowest plausible delivered dose. A simple, design-driving form is: dose_min = dose_nominal × (1 − cal_err − placement_err − drift_err − temp_err − integ_err). The exact combination rule depends on whether contributors are independent, but the output must be conservative and repeatable.
- Step 1: define dose_nominal at the target plane for a controlled, repeatable setup.
- Step 2: assign bounds for each negative contributor (with an evidence method).
- Step 3: compute dose_min and require dose_min ≥ required_minimum_dose.
- Step 4: log the assumptions (cal_version, runtime, temperature range, sampling policy) so the proof is reproducible.
H2-5. Sensor placement & optical coupling (how to avoid lying measurements)
What this chapter solves
Placement is usually the #1 source of dose measurement errors. This chapter explains how to correctly position sensors to avoid errors such as over-reads, under-reads, and shadowing. It also covers how optical coupling influences sensor readings and what to do to ensure accurate measurements.
Placement strategies and failure modes
| Placement | Failure Mode | Mitigation |
|---|---|---|
| Near-source | Over-read due to direct light paths and limited geometric coverage. | Use baffles and shields to limit direct light; ensure the sensor is properly aligned with the source’s emission angle. |
| Aperture | Hotspot readings and potential contamination of the sensor. | Protect sensors from direct hotspots with shielding and periodic self-checks for contamination. |
| Target plane | Shadowing effects or uneven coverage, leading to inaccurate readings. | Use multiple sensors for uniformity checks and apply regular maintenance for calibration consistency. |
| Leakage-prone seams | Incorrect readings due to light leakage at seams. | Use high-sensitivity leakage sensors and interlock systems to detect and respond to leakage. |
Multi-sensor strategy for uniformity & diagnostics
- Goal: Use 2–4 sensors to diagnose uniformity issues and ensure accuracy in readings.
- Strategy: Place sensors at different positions to measure the consistency of light across the target area.
- Failure Mode: If one sensor reads differently, it signals an issue in the system (e.g., shadowing, leakage).
- Action: Cross-check readings between sensors and adjust placement accordingly.
Failure modes & evidence fields
- Over-read: The sensor picks up more light than it should due to direct light paths. Capture:
sensor_fov_check - Under-read: The sensor fails to capture all available light due to shadowing. Capture:
shadow_suspect_flag - Contamination: Sensor lens contamination reduces readings over time. Capture:
sensor_window_status - Leakage: Incorrect readings from leakage points. Capture:
leakage_detection_flag
Figure F5: Placement options & failure modes
H2-6. Calibration workflow: factory calibration, in-field checks, drift & aging compensation
What this chapter solves
This chapter turns calibration into a repeatable SOP and ensures its validity over time by addressing factory calibration, in-field checks, and drift & aging compensation.
Factory calibration setup
- Reference radiometer setup: Use a calibrated radiometer with fixed geometry.
- Multiple points: Calibrate at multiple points across the target plane.
- Store coefficients: Save calibration coefficients for later use and validation.
In-field verification
- Quick check routine: Perform a self-test intensity window, using a reference target in service mode.
- Service mode: Allow easy access for calibration checks and adjustments.
Drift sources
- Sensor drift: Over time, sensor response can change due to internal factors.
- Window yellowing: The optical window may degrade, impacting light transmission.
- LED/lamp aging: The light source may degrade over time, affecting emitted energy.
- Temperature dependence: Sensor response may vary with temperature.
Compensation strategies
- Temperature correction: Use temperature coefficients to adjust for temperature-induced variations.
- Runtime-based derating model: Adjust for aging over the lifetime of the device.
- Periodic recalibration triggers: Set triggers to recalibrate when significant drift is detected.
Calibration records structure
Store calibration records with the following details:
- calibration_date: Date of calibration.
- coefficients_version: Version of the calibration coefficients.
- reference_setup_id: ID of the calibration setup used.
- pass_fail_bounds: Pass/fail limits for each calibration test.
Figure F6: Calibration loop over product life
H2-7. Safety interlocks: hardware chain, redundancy, and safe states
Design intent & non-negotiables
Interlocks must be hardware-first and software-assisted. The hard-disable path must remain effective even when firmware is stalled, misconfigured, or partially functional. Software may add diagnostics and logging, but must never be the only barrier between “unsafe” and “UV emission.”
Interlock sources & how to treat them (concept-level)
Door / cover switch
- Assume contact bounce and mechanical wear exist.
- Use the hardware chain to enforce “open = emission disabled.”
- Log transitions and count unexpected opens during emission attempts.
Key switch / mode selector
- Hardware should gate emission enable by mode.
- Firmware may add UX prompts, but hardware must still block unauthorized enable.
Service jumper / service cover detect
- When present: enforce reduced emission policy or lockout depending on risk.
- Require explicit re-arm steps after service exits.
E-stop / emergency stop
- Directly breaks the hard-enable chain.
- Fault should latch until manual reset.
Tamper detect (concept-level)
- Use as a reason to enter a latched safe state.
- Record an event snapshot: states, timestamps, and interlock source.
Hardware-first architecture: safety chain → hard disable
Use a series safety chain that drives a hard cutoff element (a hardware gate/enable input or equivalent). Firmware monitors each interlock node, validates re-arm policy, and logs evidence — but the chain must cut off emission even if firmware is not executing.
Recommended split of responsibilities
Hard-disable path must guarantee
- Any critical interlock open → emission disabled.
- Cutoff is independent from firmware scheduling.
- Cutoff is measurable (response time can be tested).
Firmware supervision should add
- State validation before enable (“all closed, stable”).
- Fault classification (bounce vs genuine open vs tamper).
- Event logs with timestamps and pre-fault snapshots.
Redundancy patterns & when to use them
Redundancy is selected by risk level. For higher-risk exposure, prefer two-channel interlocks or diverse sensing. The goal is to avoid a single point of failure that silently disables safety.
| Pattern | What it mitigates | Implementation notes (system-level) |
|---|---|---|
| Single-channel + supervision | Basic open detection + logging. | Use stable-time qualification and log transitions; treat suspicious toggling as fault. |
| Two-channel (A/B) | Contact failure, broken wire, stuck state. | Cross-check A vs B; mismatch → safe-off and latch depending on policy. |
| Diverse sensing | Common-mode failure (same sensor type failure). | Pair different sensing principles; disagreement → safe-off with diagnostic code. |
| Series chain + independent latch | Ensures cutoff even during firmware failure. | Hardware latch can require manual reset for critical violations (e-stop, tamper). |
Safe states & re-arm policy
Define safe states explicitly so behavior remains predictable and testable. A practical policy uses default OFF on fault, latched OFF for critical violations, and a clear re-arm sequence that prevents repeated unsafe retries.
Default safe state (non-critical)
- Emission disabled immediately when an interlock opens.
- Auto-retry is allowed only after “closed & stable” qualification.
- Rate-limit re-enables to avoid oscillation.
Latched safe state (critical)
- Violation triggers a latch that blocks emission until explicit service action.
- Re-arm requires a deliberate sequence (e.g., e-stop reset + key switch + service confirm).
- Event log must include the “why” and the interlock source.
Evidence to capture & acceptance tests
Interlocks are only credible when response time and behavior are measured. Capture requirements and measured results as part of validation.
Minimum evidence fields (loggable)
interlock_source,interlock_state,chain_stateenable_request_ts,hard_cutoff_tsresponse_time_ms,response_time_limit_msfault_class,latch_state,rearm_required
Acceptance tests (system-level)
- Open each interlock while emitting → verify hard cutoff within limit.
- Introduce bounce / toggling → verify safe-off without oscillation.
- Critical violation → verify latch + explicit re-arm policy.
- Firmware stall simulation → hard cutoff still works.
Figure F7: Interlock hard-disable chain
H2-8. Leakage / stray UV sensing: detection, thresholds, and containment verification
Design intent: verify containment continuously
Leakage sensing is not “shield it once and hope.” It is a continuous verification layer that detects stray UV paths, enforces immediate cutoff, and provides traceable evidence for containment performance over time.
Where leakage happens (generic leakage points)
Seams & joints
- Leakage often grows with wear and repeated cycles.
- Reflective interior surfaces can redirect stray paths to seams.
Vents & airflow paths
- Indirect paths can appear due to internal reflections.
- Flow-induced contamination can change optical behavior over time.
Cable exits & grommets
- Small clearances can create concentrated leakage beams.
- Assembly variance must be handled by conservative limits.
Reflective paths
- Leakage may correlate with door position and internal geometry.
- Perimeter sensors help detect emergent paths early.
Sensing strategy: perimeter sensors + threshold + time filter
A practical architecture uses a perimeter ring of leakage sensors focused on seams/vents/exits. Each sensor uses thresholding plus a short time filter to avoid nuisance trips from brief transients while still reacting fast to real leakage.
Sensor placement rules (leakage role)
- Place at leakage-prone edges, not at “nice-to-measure” points.
- Shield the sensor so it sees seam paths, not the main emission cavity.
- Prefer multiple nodes to localize the leak (diagnostics, not imaging).
Threshold & time filter (concept)
- Threshold: set from containment limits + margin.
- Time filter: require persistence for non-critical bands (ms-scale).
- Critical band: immediate cutoff (no delay) if risk demands it.
Trip behavior (recommended)
- Leakage trip → immediate cutoff → latch (for critical leakage) → service required.
- Store an event snapshot: sensor node ID, peak value, duration, door/mode state, and timestamps.
- Expose a maintenance flag that blocks re-enable until service clears the condition.
Containment verification during production test (generic)
Containment must be verified at production with a repeatable scan plan. Define test points around seams/vents/exits, measure leakage envelope, and enforce pass/fail bounds with clear rationale.
Test plan deliverables
- List of scan points (IDs + physical description).
- Maximum allowable leakage envelope per point group.
- Repeatable geometry conditions for the test fixture.
What “good” looks like
- No point exceeds leakage threshold under specified conditions.
- Perimeter sensor readings correlate with scan results.
- Trips are deterministic when intentionally induced.
Evidence to capture: leakage map, threshold rationale, trip logs
Minimum evidence fields (loggable)
leak_node_id,leak_value,leak_duration_msleak_threshold,time_filter_ms,trip_reasoncutoff_ts,latch_state,service_requireddoor_state,mode_state,tamper_state
Artifacts to keep (auditable)
- Leakage map: test points + measured envelope.
- Threshold rationale: basis + margin policy.
- Trip log examples: at least one true trip + one nuisance filter case.
Figure F8: Leakage sensing perimeter map
H2-9. Timed safety cutoffs, watchdogs, and stuck-on prevention
Why timing is a safety barrier (not a convenience)
Timed cutoffs exist to guarantee SAFE_OFF even when commands, sensors, or firmware become unreliable. The design target is simple: no single fault can keep emission enabled indefinitely.
Maximum exposure timers (three complementary gates)
Session timer
- Starts at
t_enablewhen emission is allowed. - At
T_session_max→ force SAFE_OFF. - Must not be refreshable while ACTIVE.
Cumulative timer
- Accumulates runtime across sessions.
- At
T_cum_max→ lockout or supervised limit policy. - Must survive resets with a defined consistency rule.
Cooldown timer
- Starts when leaving ACTIVE.
- Blocks re-enable until
T_cooldown_minexpires. - Policy must define behavior across reboot.
Watchdogs (three layers, one goal)
The goal is not “reboot”; the goal is “OFF is guaranteed and measurable.”
MCU WDT
- Detects firmware hang (no periodic kick).
- Triggers reset → system must come back in SAFE_OFF.
External supervisor
- Improves reset quality during supply anomalies.
- Helps avoid “half-alive” states during brownout.
Independent OFF timer
- Does not rely on firmware scheduling.
- Forces OFF after a fixed active window.
- Acts as the last-resort cutoff path.
Power anomaly handling: default OFF and no resume-in-ON
Brownout reset → SAFE_OFF
- Any brownout indication is treated as a safety event.
- After reset, emission is not allowed until re-arm completes.
- Reset cause must be logged for traceability.
Avoid resume-in-ON
- Restart cannot continue an active session automatically.
- Re-arm requires explicit acknowledge + condition re-check.
- Enable is granted as a single “token,” not a sticky mode.
Re-arm rules (policy-level, but testable)
Re-arm is a controlled sequence that reduces unsafe retries. A practical minimum is: acknowledge → re-validate safety conditions → grant a one-shot enable.
Minimum re-arm steps
- Step 1: manual acknowledge (clears latch intent, not the fault cause).
- Step 2: interlock closed & stable, leakage below threshold, calibration valid.
- Step 3: supervised enable grant (one-shot token, rate-limited).
Common re-arm policies
- Manual acknowledge button or HMI confirm.
- Key cycle / key switch transition required for critical violations.
- Supervised command only (service mode) after repeated safety trips.
Evidence to capture & fault-injection checklist
Minimum evidence fields
session_limit_ms,session_timer_ms,cooldown_remaining_mscum_runtime_s,cum_limit_swdt_kick_counter,reset_cause,brownout_flagstate,safe_off_reason,rearm_requiredhard_enable_cmd,hard_enable_fb
Fault injection (prove OFF)
- Stuck enable command → OFF at
T_session_max. - MCU hang (stop kicking WDT) → OFF + reboot → SAFE_OFF.
- Brownout → reset → SAFE_OFF (no auto-resume).
- Rapid short sessions → cumulative/cooldown prevents bypass.
- Timer bypass attempt by reboot → re-arm blocks immediate ACTIVE.
Figure F9: Fail-safe timing ladder
H2-10. Control firmware: dose accumulator, fault logic, and event logging schema
Firmware boundary: dose + safety + proof (without protocol creep)
Firmware is where dose estimation, safety triggers, and audit-ready evidence converge. The scope here is strictly internal: sampling → correction → integration → fault logic → state machine → logs.
Dose accumulator (engineering-grade, not hand-wavy)
Sampling & dt-aware integration
- Use measured
dt(from uptime tick) rather than assuming fixed periods. - Integrate irradiance estimates into
dose_accper sample or per window. - Record
sample_dt_msdistribution for diagnosis.
Missing-sample strategy
- Track
missing_sample_cntandmissing_dt_ms. - Below a small threshold: apply a defined policy (hold/linear).
- Above threshold: mark
dose_invalidor force SAFE_OFF (risk-driven).
Saturation handling
- Detect ADC/TIA saturation and log
sensor_saturated. - Saturation means dose proof is unreliable; trigger safe behavior.
- Store peak value and duration for root-cause analysis.
Correction chain with versioning
raw_counts → dark_offset → temp_comp → cal_table → irradiance_est- Always record
cal_versionandcoef_set_id. - Calibration invalid → block emission or force supervised mode policy.
Fault logic (layered triggers with deterministic actions)
Each fault needs: trigger condition → action (SAFE_OFF/latch/degrade) → log fields.
| Layer | Examples (in-scope) | Recommended action pattern |
|---|---|---|
| Sensor-level | out-of-range, stuck reading, saturation, calibration invalid | SAFE_OFF or supervised downgrade; log fault_code, peak, duration, cal_version |
| Safety triggers | interlock open, leakage trip, over-temp trigger | Immediate SAFE_OFF; latch for critical; log trip_reason, interlock_state, leak_node_id |
| System integrity | timer expired, watchdog reset, brownout detected, state mismatch | SAFE_OFF + re-arm required; log reset_cause, timer states, enable cmd vs fb |
Event logging schema (ring buffer + critical snapshot)
Ring buffer (high frequency)
- Fields:
ts,state, key sensors,dose_acc,timer_session_ms. - Overwrites oldest entries by design.
- Used for “what happened before the trip?”
Critical snapshot (low frequency)
- Triggered by trip/latch/timer expiry/watchdog/brownout.
- Includes pre-fault summary + parameter versions.
- Must be protected from immediate overwrite (policy-defined).
{
"ts_ms": 123456789,
"state": "ACTIVE",
"irradiance_est_mw_cm2": 4.12,
"dose_acc_mj_cm2": 52.8,
"dose_target_mj_cm2": 60.0,
"sample_dt_ms": 10,
"missing_sample_cnt": 0,
"interlock_state": "CLOSED",
"leak_state": "OK",
"timer_session_ms": 42000,
"fault_code": "NONE",
"trip_reason": "NONE",
"cal_version": "CAL_3",
"reset_cause": "NONE"
}
Minimum retention policy (auditable but practical)
Ring buffer
- Size by time: keep at least “last N minutes” of records.
- Record rate: fixed (e.g., 10–100 ms) or adaptive (state-based).
- Freeze a window around critical events if possible.
Critical snapshots
- Keep last K critical events (K small but non-zero).
- Each snapshot stores: trip reason, peak values, timer states, versions.
- Expose snapshot IDs for service workflows.
Evidence fields checklist (copy into a requirements doc)
Dose & sampling
raw_counts,dark_offset,temp_cirradiance_est,dose_acc,dose_target,dose_marginsample_dt_ms,missing_sample_cnt,sensor_saturatedcal_version,coef_set_id
Safety & system
state,state_enter_tsinterlock_state,leak_node_id,leak_valuetimer_session_ms,cooldown_remaining_ms,cum_runtime_sfault_code,trip_reason,reset_causehard_enable_cmd,hard_enable_fb
Figure F10: Firmware dataflow
H2-11. Validation & Field Debug Playbook (Symptom → Evidence → Isolate → Fix)
Typical Symptoms in UV-C Devices
The following are common symptoms faced in field debugging of UV-C devices. For each symptom, follow a 4-step process: diagnose, measure, isolate, and fix.
4-Step Debug Process for UV-C Symptoms
For each symptom, enforce a structured 4-step troubleshooting process:
Step 1: First 2 Measurements
- Radiometer check for field-dose measurements.
- Raw counts from the UV-C sensor and snapshot of interlock GPIO.
Step 2: Discriminator
- What proves sensor drift vs. placement vs. aging vs. firmware integration bug?
- Determine whether it is a sensor error, incorrect placement, aging, or firmware issue.
Step 3: Isolate
- Swap sensors to confirm fault source.
- Block optics, force known current, and run controlled timer tests.
Step 4: First Fix
- Recalibrate, adjust sensor placement, tighten latch policy, and add independent cutoff mechanisms.
Evidence to Capture During Debug
During the debugging process, ensure the following evidence is captured:
Last N Event Logs
- Event timestamps, state changes, and fault codes.
Calibration Version
- Record the calibration version to check against firmware versions.
Figure F11: UV-C Debug Decision Tree
H2-12. FAQs ×12
We meet timer limits, but dose is still low—sensor placement or optical model error?
- Radiometer (example): ILT2400-UVC
- UV sensor (example): GUVC-S10GD; S12742-254
Sensor reads stable, yet radiometer says dose is drifting—aging or window contamination?
- Radiometer (example): ILT2400-UVGI-NB (254 nm)
- UV photodiode (example): S12742-254
Leakage sensor trips only on cold mornings—condensation scattering or thresholding?
- UV sensor (example): GUVC-S10GD
- Watchdog/supervisor for robust reset (example): TPS3430
Random interlock faults—contact bounce or wiring routing noise?
- Window watchdog (example): TPS3430
- UV sensor (example, for cross-check): S12742-254
Dose overshoots at start—integrator warm-up or calibration offset?
- Radiometer (example): ILT2400-UVC
- UV photodiode (example): S12742-254
Unit sometimes powers up “armed”—how to guarantee default-OFF after brownout?
- Window watchdog / supervisor (example): TPS3430
- Radiometer (example, for validation): ILT2400-UVC
Two sensors disagree—cosine response/angle or baffle design?
- UV sensor (example): GUVC-S10GD
- UV photodiode (example): S12742-254
Leakage passes production scan but fails in the field—assembly tolerance or reflective path?
- UV sensor (example, perimeter nodes): GUVC-S10GD
- Watchdog (example, for latched-safe behavior): TPS3430
Dose calculation differs between firmware versions—what must be logged for traceability?
- Radiometer (example, golden test): ILT2400-UVC
- UV photodiode (example, reference sensor): S12742-254
How often should we recalibrate—runtime-based or sensor-drift based triggers?
- Radiometer (example): ILT2400-UVGI-NB
- UV sensor (example): GUVC-S10GD
How do we handle sensor failure—degrade mode or hard stop?
- Window watchdog / independent OFF enforcement (example): TPS3430
- UV photodiode (example): S12742-254
What’s the minimal acceptance test to “prove safety” without over-testing?
- Radiometer (example): ILT2400-UVC
- Window watchdog (example): TPS3430