Engineering-grade sensing starts with measurable targets

In cabinets, a “good sensor” can still produce bad alarms when placement gradients, condensation, dust, and cable pickup distort readings. This section defines targets that can be verified in production and defended during field troubleshooting.

Targets and breakers by sensor class

• Temperature: define range, accuracy class, response time (t63), and self-heating limits. Breakers include nearby heat sources, top/bottom stratification, and high sampling activity that warms the die.
• Humidity: define RH accuracy, long-term drift, and condensation behavior. Breakers include dew formation, protective membrane latency, and chemical exposure (cleaners/conformal coat fumes).
• Smoke / air quality: explicitly define what “smoke” means in the cabinet (particle vs VOC proxy), and specify false-trigger controls (dust, maintenance aerosols, baseline drift).
• Door / tamper: define debounce windows and misalignment tolerance. Breakers include contact bounce, magnet offset, vibration coupling, and EMI pickup on long switch leads.

Recommended evidence fields (examples): raw and filtered values, fault/status codes, persistence timers, rate-of-change flags, and placement zone tags (top / ingress / dead zone).

Placement rules (cabinet physics, not guesswork)

Placement is part of accuracy. A cabinet has predictable zones: a hot stratified top region, an ingress region near cable glands and door seams, and low-flow dead zones. Each sensor benefits from a specific zone depending on whether the goal is “environment truth” or “early anomaly detection”.

• Top hot zone: best for early smoke/overheat signatures; risks biasing ambient temperature upward.
• Ingress zone: best for detecting external humidity/contaminants; risks transient spikes and false triggers without persistence logic.
• Dead zones: stable readings but slow detection; avoid for early-warning smoke/thermal events.

Practical AFE patterns for cabinets (protect + filter + diagnose)

Cabinet wiring behaves like an antenna and a surge injector at the same time. Robust interfaces follow a repeatable pattern: protect the input, limit bandwidth, and produce fault evidence (timeouts, open/short, stuck-at, and rate checks). This keeps the section focused on field-realistic design without drifting into analog theory.

Interface choices and what they cost

• Digital (I²C / 1-Wire): simple calibration but sensitive to edge quality on longer leads; requires rate control and retry/timeout evidence.
• Analog (NTC / analog RH): tolerant of simple wiring but needs input protection and RC filtering matched to latency targets.
• Switch/pulse (door/tamper): requires debounce + EMI hardening and benefits from bounce-count evidence for maintenance diagnostics.

Evidence-first recommendation: log timeouts/retries (digital), range/fault codes (analog), and debounce rejects / bounce counts (switch inputs).

Fault detection patterns that survive field noise

Fault detection must separate “sensor is wrong” from “wire is wrong” and “environment truly changed”. A cabinet-friendly set of checks includes: open/short detection, stuck-at detection, out-of-range clamping with counters, and rate-of-change sanity checks. For smoke/air-quality sensing, baseline tracking plus persistence windows prevent maintenance aerosols and dust bursts from becoming alarms.

• Open/short: detect impossible voltages/codes and latch a fault state with a counter.
• Stuck-at: detect unchanged readings beyond a maximum dwell time under expected noise.
• Rate-of-change: flag unrealistic steps; treat as “suspect” until corroborated.
• Baseline + hysteresis (air-quality): compare delta vs baseline, require persistence before alarm.

Validation hooks (what proves stability)

Validation should prove that the interface remains stable under cabinet disturbances and that failures become visible in logs. A practical approach is to validate both the electrical layer (edges, spikes, clamp behavior) and the evidence layer (fault codes and counters).

• Electrical: bus edge quality on long leads, transient spikes during relay switching, and ESD/surge injection recovery.
• Evidence: timeout/retry counters, open/short flags, debounce reject counts, and baseline/delta persistence timers.

Event-first design (not always-on polling)

A cabinet monitor is an event system. Power saving is successful only when critical events are never missed and evidence is preserved through outages. The MCU strategy must explicitly define power modes, wake coverage, sampling cadence, and brownout behavior as testable rules.

Power budget ledger (what must be accounted for)

The design should track energy by phases rather than quoting a single “sleep current”. Each phase has a measurable budget and a corresponding log field so field battery anomalies can be diagnosed.

• Sleep (µA): RTC + tamper line retention; budget defines standby life.
• Sample (mA): sensor power-up and readout; budget defines cadence limits.
• Compute (mA): filtering + rule evaluation; budget defines latency headroom.
• Alarm peak (mA/A): buzzer/relay/dry-contact drive; budget defines peak rail stability.
• Report burst (mA): uplink transmissions and retries; budget defines worst-case outage behavior.

Recommended evidence fields: energy_mode awake_ms report_count alarm_peak_seen.

Wake tree (coverage + priority)

Wake sources should be treated as a coverage problem: which events must wake immediately, which can wait for RTC, and which are conditional. Priority prevents a noisy cabinet from draining energy via unnecessary wakeups.

• Hard real-time wake: door/tamper interrupt; smoke threshold interrupt (or equivalent comparator/event pin).
• Soft real-time wake: RTC tick for periodic temperature/humidity sampling and health checks.
• Conditional wake: vibration/leak triggers only escalate when corroborated or repeated.
• Comms wake (optional): only when the interface supports low-power wake and policy allows.

Minimum traceability: wake_source wake_priority wake_count.

Adaptive sampling cadence (normal vs elevated risk)

A fixed sampling rate is either wasteful or unsafe. Cadence should adapt to a risk state derived from early-warning indicators, increasing sampling only when the cabinet shows signs of instability.

• Normal: low-frequency sampling for long life; alert only on confirmed persistence.
• Elevated risk: higher sampling when temperature rate-of-rise increases, dew margin shrinks, or air-quality delta rises.
• Incident (optional): highest cadence during active alarms to collect evidence snapshots and confirm clearing.

Evidence fields: risk_state sample_interval_ms risk_enter_reason risk_exit_reason.

Brownout rules (minimum viable logging vs graceful shutdown)

Brownout is common in cabinets (rail dips, relay kicks, PoE negotiation, battery sag). Behavior must be deterministic: either commit a minimal evidence record before collapse or complete a graceful shutdown when hold-up energy is available.

• Minimum viable logging: commit event_seq, reset_cause=BOR, vbat_min, and a commit_marker.
• Graceful shutdown: add last sensor snapshot, pending queue depth, and config_version for auditability.

Watchdog + reset-cause logging (field diagnosability)

Field failures are diagnosable only when resets are explained. Every reset should write a reset cause and a monotonic counter, and watchdog servicing should be aligned to critical phases (sampling, logging, reporting) so hangs become visible in evidence.

• Reset cause: brownout, watchdog, pin reset, software fault; persist to evidence storage.
• Counters: reset_count, brownout_count, watchdog_count; include in uplink summaries.
• Phase-aware watchdog: avoid masking hangs during commit or radio/PHY stalls.

From raw readings to credible alarms

Credible alarms require explainable rules. Each event should have a clear trigger, a persistence window, a hysteresis or debounce boundary, and a severity outcome that maps to local actions and evidence fields. Multi-sensor corroboration reduces false alarms and increases confidence.

Core rule building blocks

• Door: debounce + open-duration; separate momentary bounce from a real open/forced event.
• Temperature: absolute threshold + rate-of-rise; rate-of-rise indicates abnormal heating signatures.
• Humidity: dew margin and persistence; pre-warning when condensation risk increases.
• Smoke / air: baseline + delta + persistence; prevent dust/maintenance aerosols from triggering alarms.
• Corroboration: smoke + temp rate raises confidence; vibration-only lowers severity unless repeated.
• Severity ladder: warning → alarm → critical; define latch vs auto-clear and required local actions.

Evidence-first requirement: rules should emit fields such as persist_ms, rate_max, baseline, delta, debounce_rejects, severity, latch.

Rule table (maps triggers to evidence fields)

The table below is intentionally compact. It shows how each alarm is defined, how it is confirmed, and which evidence fields must be logged so field incidents can be reproduced and audited.

Note: Threshold symbols (TH/R/M/D/T) are parameters under version control; log config_version with every alarm.

Local alarms must work when uplink is down

Local outputs are the last line of safety and security. Output design must remain functional during uplink failure, degraded power conditions, and noisy cabinet wiring. Prioritization and anti-chatter rules prevent nuisance actuation while ensuring critical events always assert locally.

Output types (what they are good for)

• Open-drain / low-side sink: drives a buzzer/LED or external logic input; simple and low cost; requires attention to ground noise and backfeed.
• Relay contact: provides a true dry-contact interface (NO/NC) and safety interlocks; requires coil surge handling and kick suppression.
• Opto-isolated output: breaks ground loops and protects domains; requires a clear isolation boundary and external-side pull-up conventions.
• Dry-contact semantics: defines the external system expectation (NO vs NC, fail-safe behavior, and continuity checks).

Evidence fields recommended: alarm_channel alarm_priority alarm_on_ms alarm_asserted.

Priority, rate limiting, and anti-chatter

Local actuation should be governed by explicit priorities. Critical events should not be suppressed by communication outages, while lower-severity events should be rate-limited to prevent chatter and battery drain.

• P0 (must assert): smoke signature (baseline+delta+persistence), forced door/tamper, critical overtemperature or temp rate-of-rise.
• P1 (assert with limits): overtemperature warning, prolonged high humidity / condensation risk, repeated abnormal air delta.
• P2 (log + report only): minor vibration, transient humidity spikes, non-critical comms errors.
• Anti-chatter: minimum-on time for relays/buzzers; release conditions require hysteresis/persistence.
• Rate limiting: cap local actuation frequency; never drop evidence logs (track rate_limit_dropped_count).

Service mode / mute window with audit trail

Maintenance requires controlled suppression without hiding events. Mute windows should be time-bounded and auditable, recording the reason and the number of events that occurred while muted. Service mode should also relax nuisance triggers without disabling critical safety logic.

• Mute window: record mute_active, mute_reason, mute_until.
• Audit counters: record events_while_muted and per-type counts.
• Fail-safe: P0 events can override mute depending on policy; override must be logged.

Wiring & EMC notes (cabinet-realistic)

• Inductive kick: relay coils require flyback/TVS; placement defines both EMI and release behavior.
• Segregation: keep alarm power wiring away from sensor buses and ADC traces; avoid shared return paths for noisy loads.
• Isolation barriers: define which side of an opto/relay belongs to the cabinet controller domain vs external domain.
• Backfeed prevention: external systems may source voltage into “dry contact” or open-drain lines; ensure current cannot back-power logic.

Logs must be forensically useful

Evidence logs should reconstruct incidents, not merely record that “something happened”. Each record should carry a sensor snapshot, severity, duration and extremes, rule fingerprints, and reset causes. Storage format must withstand power loss and time errors while preserving ordering.

Minimum event record (fields that should exist)

• Identity: event_seq, event_type, record_version
• Time: t_start/t_end or duration_ms, plus time_quality
• Severity: severity, latch, alarm_channel
• Snapshot: temp/rh/air/door values at trigger + optional min/max during the event
• Rule fingerprint: rule_id or trigger_flags + persist_ms
• System context: wake_source, risk_state, config_version, reset_cause

Ring buffer integrity (sequence, wrap markers, CRC)

A ring buffer should make wrap-around and gaps detectable. Each record should have integrity checks and a structure version so postmortem tools can parse mixed firmware eras. Sequence gaps indicate overwrite or corruption; CRC indicates partial writes or bit flips.

• Sequence: monotonic event_seq across reboots; never reset to zero silently.
• Wrap marker: record wrap cycles with wrap_marker to prove overwrites.
• Integrity: crc32 per record; invalid CRC is treated as unreadable evidence.

Power-loss safe commits (two-phase commit + last gasp)

Power loss must not create ambiguous records. Use a two-phase approach: write the body first, then write a commit marker. If the marker is missing, the record is invalid by definition. Last-gasp logging should capture reset cause and minimum context before rails collapse.

• Two-phase commit: BODY → COMMIT marker; no marker means “ignore”.
• Wear strategy: distribute writes across pages; only log essentials at high frequency.
• Last gasp: log reset_cause=BOR, vbat_min, event_seq, and last event type.

Time sources and wrong-clock behavior

• RTC: stable ordering but drifts; track time_quality and sync events.
• Network time: corrects drift but can jump; log time_sync_offset_ms when applying corrections.
• GNSS (if present): highest trust when locked; log lock status and last fix age.
• When clock is wrong: rely on event_seq + duration_ms + time anchors.

Practical cabinet security is detection + evidence

Cabinet security is typically defeated through simple bypass attempts: holding a switch, using a magnet, shorting a loop, unplugging a sensor, or deleting evidence after an incident. Effective anti-tamper focuses on reliable tamper signals and tamper-evident logging so deletions and edits become detectable.

Tamper signals (what to monitor in a cabinet)

Tamper inputs should be treated as a coverage set. Each input needs a trigger definition (threshold + persistence), a severity outcome, and evidence fields that allow post-incident reconstruction.

• Door switch: debounced open/close plus open-duration; supports forced-open detection.
• Magnetic tamper: detects magnet proximity or abnormal magnetic field; helps defeat “magnet bypass”.
• Enclosure open: cover/hinge switch for cabinet access attempts.
• Mesh loop / continuity loop: detects cut or short; supports periodic loop self-test.
• Accelerometer triggers: movement/shock; best as corroboration or lower-severity unless repeated.

Evidence fields recommended: tamper_type persist_ms tamper_count door_open_ms loop_state.

Threat model (keep it practical)

• Technician mistake: accidental door left open, sensor unplug, maintenance aerosols; handle with service windows and audited mute.
• Malicious bypass: magnet trick, shorting loops, “cleaning” logs; handle with corroboration and tamper-evident evidence.
• Device swap / clone: replacing the unit or replaying old data; handle with identity binding and monotonic evidence anchors.

Secure identity (unique ID + anti-clone strategy)

Anti-clone does not require complex architecture, but identity must be stable and verifiable. At minimum, each unit should expose a unique device ID and a build/config fingerprint. A secure element is optional; it becomes valuable when keys must be protected from simple readout and cloning.

• Baseline: unique device ID + firmware build ID + config_version included in heartbeat and incident uploads.
• Enhanced: secure element stores signing key and performs signatures; reduces key extraction and device cloning risk.
• Operational: provisioning creates identity, locks storage, and records the identity in the backend inventory.

Evidence fields: device_id fw_build_id config_version provision_state.

Tamper-evident logs and authenticated uplink

Tamper-evident logging is achieved by chaining event records. Each new record includes the previous record hash, producing a hash chain where deletions and edits break verification. Uplink authenticity can be implemented by reporting periodic hash anchors and signing anchors or record hashes.

• What to chain: the event record digest (not necessarily full raw payload).
• What to report: periodic hash_anchor in heartbeat + full event record on incident.
• What to verify: sequence continuity + commit markers + CRC + hash chain continuity.

Key storage basics (minimal but real)

• Protect against simple readout: lock debug ports; isolate provisioning tools; avoid shipping with universal test keys.
• Provisioning flow: generate keys/IDs → inject → verify → lock → register device ID in backend.
• Audit: provisioning and key changes must be logged as events (also chained).

Logging is part of security: config_change and key_event records should also enter the hash chain.

Integration paths without building a full network stack

Communication design should expose a stable data model (telemetry, events, counters, and configuration) and then map it to fieldbus or IP transports. The system should support event push, periodic heartbeat, and safe remote configuration with auditability and rollback.

Local fieldbus (RS-485/Modbus, CAN)

Fieldbus integration should provide deterministic reads for environment values and counters, plus a controlled write path for configuration updates. Multi-register values should be read atomically (snapshot on read) to avoid inconsistent frames.

• Telemetry registers: temp, RH, air delta, dew margin, door/tamper state.
• Alarm/status: current severity, last event seq, mute active, rate-limit counters.
• Counters: reset/brownout/tamper/alarm counts, events while muted.
• Config: thresholds and windows guarded by ranges; writes must bump config_version.

Ethernet/PoE option (power domains + port protection)

• Domain separation: PoE PD → isolated DC/DC → logic; avoid noisy relay returns sharing PHY grounds.
• Port protection: surge/ESD at RJ45, common-mode control, and clear isolation boundaries.
• Brownout linkage: PoE negotiation/restart can dip rails; ensure last-gasp evidence commits remain deterministic.

Evidence fields to correlate port faults: link_state reconnect_count power_event.

Cellular option (burst power + offline queueing)

• Burst power: uplink transmissions require peak current support; schedule retries and cap wake time.
• SIM/eSIM: provisioning status should be auditable; avoid shipping universal credentials.
• Offline queueing: store events locally and upload later; use event_seq to dedupe.
• Replay resistance: heartbeat carries hash_anchor so old payloads can be rejected.

Message design (event push + heartbeat + configuration pull)

• Event push: event record + this_hash + time_quality; sent on alarms or tamper events.
• Heartbeat: device identity + counters + hash_anchor + config_version; periodic and lightweight.
• Configuration pull: versioned updates with safety checks; apply within maintenance windows and record an audit event.

Guardrails: range limits, minimum persistence windows, and “P0 cannot be downgraded” policies should be enforced before apply.

Remote configuration safety (guardrails + audit + rollback)

Remote configuration is a high-risk path. Updates should be versioned, auditable, and reversible. Any threshold changes should produce a configuration change event that enters the hash chain to prevent silent tuning after incidents.

• Guardrails: clamp thresholds to safe ranges; enforce minimum debounce/persistence; protect P0 rules.
• Audit logs: write config_change records with old/new versions and apply results.
• Rollback: revert to previous config when abnormal resets or alarm storms are detected after apply.

Field reliability is decided at the entry points

Cabinets fail in the field when disturbance energy enters through long sensor leads, comms ports, power inputs, or alarm wiring and pushes the system into false events, latch-ups, resets, corrupted logs, or intermittent comms. Hardening requires (1) identifying entry points, (2) applying layered protection with controlled return paths, (3) placing isolation boundaries when ground potential and port exposure demand it, and (4) proving it with production tests and event simulation.

ESD & surge entry points (what to protect first)

• Sensor cables / long lines: door switch, tamper loop, external T/H probes — common-mode injection and fast ESD spikes.
• Comms ports: RS-485/CAN, Ethernet/PoE — cable-coupled surge and ground shifts.
• Power inputs: DC feed, PoE PD, auxiliary rails — dip/overshoot that triggers BOR or causes partial commits.
• Alarm wiring: relay contacts, open-drain outputs — inductive kick and backfeed from external systems.

Typical “symptom mapping”: false tamper bursts → check cable entry + filtering; random reboots → check BOR + port surge; log gaps → check commit + CRC.

Layered protection topology (ESD → limit → filter → clamp)

Protection should be staged. Place fast clamps at the connector, limit current into internal rails, filter to prevent state-machine flips, and clamp residual energy before sensitive IC pins. Layout and return paths are part of the protection: a good TVS with a bad return is still a bad design.

Example MPNs (common building blocks)

These are representative, widely-used options. Selection must match working voltage, line impedance, surge class, and package constraints.

• RS-485 / differential line TVS: SM712 (Littelfuse) SM712-02HTG (Littelfuse) SMBJ series (e.g., SMBJ58A)
• High-speed ESD arrays (signal lines): TPD2E001 / TPD4E05U06 (TI) PESD series (Nexperia)
• Common-mode chokes (noise control): WE-CNS series (Würth) ACM/ACT series (TDK)
• Reset / supervisor (ESD reset immunity + BOR proof): TPS3839 (TI) MAX809/MAX810 (Analog Devices/Maxim)
• Input protection “series element” (when cable is long): PTC resettable fuse (e.g., MF-R series) small series R (10–100Ω class)
• Relay coil suppression: SS14 (diode) SMBJ series (coil rail clamp)

Isolation boundaries (when isolation becomes necessary)

Isolation is justified when the cabinet interface is exposed to large common-mode swings, long building-scale cabling, or unknown external grounds. The practical goal is to keep the logic + evidence domain stable while allowing the port domain to absorb stress.

Example MPNs (isolated interfaces & power)

• Isolated RS-485 transceivers: ISO1410 (TI) ADM2587E (Analog Devices)
• Digital isolators (logic domain boundaries): ISO77xx series (TI) ADuM series (Analog Devices)
• PoE PD controllers (if PoE is used): TPS2372 / TPS2373 / TPS2375 (TI) LTC4269 (Analog Devices)

Isolation does not eliminate the need for port ESD/surge protection. It relocates the stress boundary and protects the evidence domain.

Condensation & corrosion (slow failures that look like drift)

High humidity is not the whole story; failures often start when condensation forms on cold surfaces or when contaminants accumulate and change sensor response. Hardening for humidity requires controlling placement and venting, defining coating rules, and adding drift monitoring fields.

• Dew margin: track dew-point proximity as a pre-warning. Use a stable pre-alarm rather than noisy “RH spikes”.
• Conformal coating cautions: RH sensors need a breathable path; coating over the sensing membrane can permanently bias readings.
• Venting strategy: use vents/membranes to reduce trapped moisture while keeping ingress protection goals intact.
• Corrosion signals: rising contact resistance on loops/switches, stuck-at values, increased CRC or comms errors.

Drift evidence fields: drift_flag baseline_age sensor_fault_count.

Serviceability (replace modules without losing identity or evidence)

Service actions should be expected and auditable. Replaceable sensor modules should not break device identity or delete evidence. Each service action should create an event record that enters the hash chain, and it should trigger a short self-test event sequence.

• Replace sensor module: log service_action, update module_id (if available), run self-test, then resume.
• Preserve identity: keep unique device ID in protected storage; avoid binding identity to a replaceable daughterboard.
• Preserve logs: store evidence in FRAM/Flash ring buffer; avoid “factory reset” behavior during routine service.

Production test (calibration sanity + event simulation checklist)

Production test should be fast and decisive: verify sensor ranges, verify event logic triggers, and verify that disturbance does not silently corrupt state or evidence. A minimal test plan ties each stimulus to expected log fields.