Barrier & Vehicle Detection for Boom Gates
← Back to: Security & Surveillance
H2-1. Definition & Boundary — What “Barrier & Vehicle Detection” Covers
This page is scoped to the edge hardware + evidence chain around a boom barrier: sensing → decision → safety interlock → actuator drive. It defines what must be measurable and auditable on-device.
Engineering deliverables (pass/fail semantics):
- Vehicle Present: at least one presence channel crosses threshold with debounce and hold time (e.g., loop Δf, magneto ΔB, radar presence, video-trigger event).
- Safe to Close: a permit-to-move state is true (photo-eye clear + safety edge clear + no critical fault flags).
- Obstruction Detected: safety input asserts or drive feedback indicates jam (edge trip, photo-eye block, abnormal motor current, travel stall).
- Faulted: detection or actuation self-check fails (loop open/short/leakage, drift runaway, brownout during drive, driver OCP/OTP, sensor comm loss).
Minimum evidence set (what logs must capture):
- Primary evidence: one continuous metric + one state bit per channel (e.g., loop Δf + present_flag; magneto ΔB + drift_flag; radar presence + quality_flag).
- Secondary evidence: timestamp + decision latency + “interlock snapshot” at decision time (permit state, safety inputs, rail_min, motor_current_peak).
H2-2. Architecture Options — Sensing + Control Topologies
The key architectural decision is where the presence decision is made and where the safety gate cuts off actuation. These two placements determine fault isolation, event logging quality, and the end-to-end stop/reverse latency.
Topology dimension 1 — Standalone vs integrated:
- Standalone detector + barrier controller: detector outputs present/fault; controller focuses on interlocks and drive. Easier module swap, but weaker correlation between raw metrics and actuator events unless logs are unified.
- Integrated controller: controller reads raw metrics/events and computes presence + fusion + interlock gating. Best for consistent evidence (metrics snapshot + permit state), but higher integration effort and validation scope.
Topology dimension 2 — Single sensor vs multi-sensor:
- Single-sensor: lowest BOM; typically sufficient for controlled environments, but sensitive to rebar, weather, loop geometry, and motorcycles.
- Multi-sensor: improves robustness by using complementary evidence (loop/magneto for metal, radar for presence volume, video-trigger as an external event). Requires explicit time windows, debounce, and a documented rule table.
Decision placement checklist (engineering-grade):
- Auditability: can the “present” outcome include raw metric + threshold + timestamp + interlock snapshot?
- Fault isolation: can the system distinguish sensor fault vs wiring fault vs controller fault vs drive fault?
- Latency budget: can the total reaction time meet safe-stop constraints?
Recommended latency decomposition (for validation): t_detect + t_fuse + t_interlock + t_drive_cutoff + t_mech_stop. Each term should be measurable in logs or scope traces.
H2-3. Inductive Loop Fundamentals (Engineer View) — What the AFE Must Measure
An inductive loop is well modeled as L in series with R. With a capacitor C, it forms a resonant network so small physical changes become measurable shifts in frequency, amplitude, and phase—without relying on parking software workflows.
1) What changes when a vehicle arrives
- ΔL: effective inductance changes due to coupling with conductive mass.
- ΔR: effective loss increases (eddy-current damping), reducing resonance “sharpness”.
- Amplitude & phase shift: at or near resonance, both magnitude and phase respond strongly.
Key insight: ΔL mainly moves the resonant point; ΔR mainly reduces Q (damping), affecting amplitude/phase.
2) What the AFE must measure (observable metrics)
- Δf: frequency shift (from oscillator or PLL lock frequency).
- A: demodulated amplitude / energy proxy (captures damping).
- φ: phase shift (often measured via I/Q synchronous demod).
- Q proxy: derived health/quality metric (e.g., A vs f response or decay estimate).
Practical selection: use at least one “position-like” metric (Δf) + one “loss-like” metric (A or Q proxy) to reduce false triggers.
Metric selection notes (why single-metric systems mis-trigger):
- Δf-only systems can be sensitive to slow drift (temperature, moisture, nearby metal) unless baseline tracking is disciplined.
- Amplitude/Q-aware measurements can reject certain drift patterns because damping behavior differs from slow baseline shifts.
- Phase is highly sensitive near resonance but depends on stable reference timing and clean demodulation.
Recommended “minimum evidence” fields for loop channels:
H2-4. Inductive Loop AFE Implementation — Excitation, Sense, Demod, Thresholding
A production-grade loop detector AFE is a pipeline: excite → sense → demod/count → filter → decision. Robustness comes from disciplined baseline tracking, hysteresis, and blanking windows around known disturbance events (e.g., motor start).
Excitation (how energy is injected)
- Free-running oscillator: simplest; frequency shifts reflect ΔL.
- PLL lock / sweep: locks to resonance or probes around it; stable Δf measurement.
- Burst excitation: time-windowed drive; useful for EMI timing and low average power.
Evidence fields: excite_mode, lock_status, f_ref, drive_level.
Sense + Demod (how observables are extracted)
- Sense amplifier: measures loop voltage/current with headroom and clipping detection.
- Demod: rect/envelope for amplitude or I/Q synchronous demod for amplitude+phase.
- Counter / TDC / ADC: converts to digital metrics (f_count, amp_demod, phase_demod).
Evidence fields: f_count, amp_demod, phase_demod, clip_flag.
Anti-false-trigger mechanisms (must be explicit and loggable):
- Baseline tracking: update baselines only under “no vehicle” conditions; apply slope limits to avoid absorbing real arrivals into baseline.
- Hysteresis: separate enter/exit thresholds (th_hi / th_lo) to prevent chatter at the boundary.
- Blanking windows: temporarily ignore measurements during known disturbance intervals (drive enable edge, relay switching, surge recovery).
Minimum decision evidence (for audit + field debug):
H2-5. Magnetometer / Magneto Vehicle Detection — When Loop Can’t Be Used
Magneto sensing detects vehicle presence by measuring changes in the local magnetic field vector. It is commonly selected when cutting asphalt for loops is constrained, temporary/portable deployments are needed, or multi-lane layouts make loop wiring complex.
Why magneto exists (engineering constraints)
- No saw-cut / no trench: asphalt constraints or rapid installs.
- Portable installs: temporary gates, events, construction detours.
- Multi-lane complexity: loop routing and interference management become costly.
- Maintenance risk: avoids long buried cable runs and connector corrosion chains.
Goal alignment: outputs must still map to vehicle present, clear, and faulted states defined in the page boundary.
Sensor type selection (mention-level)
- AMR / GMR / TMR: mainstream options; differ in sensitivity, drift, and range.
- 1-axis vs 3-axis: multi-axis reduces heading sensitivity and improves robustness.
- Fluxgate: used where very high sensitivity is needed, with different size/power tradeoffs.
Selection focus: sensitivity vs drift, dynamic range (saturation margin), power budget, and axis strategy.
AFE requirements (how weak field changes become stable decisions):
- Offset management: chopper stabilization / offset cancellation keeps low-frequency drift from mimicking “presence”.
- Range + AGC: prevents saturation with large vehicles or close mounting while keeping small vehicles detectable.
- Temperature drift control: compensate baseline vs temperature; track drift rate as a health signal.
- Evidence-based features: extract ΔB magnitude, slope, and persistence to support thresholds + hysteresis.
Installation sensitivities (engineering-level, not a construction guide):
- Distance: signal scales strongly with standoff; characterize site distribution of delta_b.
- Heading/orientation: axis projection changes with sensor rotation; use 2D/3D vectors and track vector_mag.
- Rebar / nearby steel: adds large static offset and slow drift; rely on disciplined baseline rules + drift flags.
Minimum observables (loggable evidence fields):
H2-6. Outdoor Robustness — Cable Faults, Surge/ESD, Ground Issues
Outdoor deployments fail in repeatable ways: cable opens/shorts, water ingress leakage, connector corrosion, surge/ESD hits, and ground reference problems. The objective is to convert these into detectable fault flags with clear evidence fields—before they become random false triggers.
Loop-side failure modes (what to expect)
- Open: low/zero sensed amplitude; lock fails; drive current abnormal.
- Short: overcurrent behavior; clipping; abnormal frequency response.
- Water ingress / leakage: baseline drifts faster; Q proxy degrades; noise rises.
- Connector corrosion: intermittent contact → jittery thresholds and sporadic toggles.
Engineering focus: each mode must map to measurable anomalies and reason codes.
Fault detection (evidence-based methods)
- Runtime monitors: drive_current, lock_status, amp_demod, f_count.
- Baseline runaway: drift-rate beyond limits → baseline_runaway_flag.
- Noise estimation: elevated measurement noise → noise_est.
- Periodic self-test: small stimulus / probe to estimate impedance trend → z_est, selftest_pass.
Preferred workflow: confirm with two signals (sensor metric + power/ground evidence) before replacing hardware.
Protection principles (selection-level, not a full surge chapter):
- TVS / GDT: select for expected surge energy and clamp behavior; place near the cable entry with short return paths.
- Common-mode choke: place near the connector to limit fast common-mode transients into the AFE.
- Ground sanity checks: unstable reference ground can mimic threshold events; log rail minima and ground-related fault hints.
Minimum outdoor evidence fields (fault + integrity):
H2-7. Radar / Video Trigger Inputs & Decision-Level Fusion (Edge)
This chapter treats radar presence and video AI triggers as event inputs to the barrier controller. The focus is interface integrity, timestamping, time-window alignment, and explainable fusion—without diving into radar DSP or video analytics.
Input taxonomy (what arrives at the edge)
- Dry contact / relay: robust wiring, but contact bounce and noise spikes must be filtered.
- TTL / open-collector: define pull-up, polarity, and glitch filtering.
- UART / RS-485 / CAN: treat as framed events (sequence, CRC status, timeout).
Goal: normalize all sources into one internal event record suitable for auditing and replay.
Normalized event record (audit-friendly)
- src (loop/magneto/radar/video)
- event_ts (source timestamp or derived)
- recv_ts (controller arrival time)
- quality (0–1 or grade)
- payload (optional: tag like tailgate/motorcycle)
Tracking both event_ts and recv_ts helps isolate sensor latency vs bus delay vs controller scheduling.
Decision-level semantics (avoid ambiguity):
- Presence: “vehicle occupies the decision zone” (not “motion” or “classification”).
- Clear: “zone is clear to close” for the active time window.
- Tailgating suspect: “multi-vehicle pattern in a short gap” based on event spacing.
- Unknown: input conflict or missing confirmations; require conservative safe-state behavior.
Time alignment and debouncing (where fusion becomes reliable):
- Window alignment: define a fusion window around a primary trigger (e.g., loop event opens window for radar/video confirmations).
- Debounce + refractory: suppress bounce/glitches and prevent rapid re-triggers during actuator motion.
- Hold vs pulse: convert short pulses into bounded “presence-hold” segments to unify sources.
Fusion policies (explainable, not “magic AI”):
Rule-based (most deployable)
- OR for presence robustness (reduce missed detection).
- AND confirmation for false-trigger reduction in noisy sites.
- Special-case rules: motorcycles (weak loop), tailgating (gap pattern).
Every decision must produce reason_code and a source_mask.
Confidence scoring (optional, still auditable)
- Per-source quality weighted and time-decayed within the window.
- Output confidence_present and log per-source contributions.
- Use thresholds + hysteresis to avoid oscillation near boundaries.
Key rule: the fused outcome remains explainable via logged evidence fields.
| Use case | Fusion intent | Primary evidence fields |
|---|---|---|
| Reduce false triggers in rain / EMI-heavy sites | Require time-window confirmation (e.g., loop OR radar, then optional video confirm) | window_open_ts, source_mask, conflict_flag, reason_code |
| Detect tailgating | Pattern match: multiple presence edges within short gap_ms | gap_ms, tailgate_flag, event_count |
| Handle motorcycles (weak loop response) | Allow radar/video to raise confidence when loop metric is marginal | delta_f/delta_b, confidence_present, quality |
Minimum fusion evidence fields (recommended logging set):
H2-8. Actuator Drivers — Motor/Solenoid Control, Braking, and Power Transients
Barrier actuation is a coupled system: driver topology, current sensing, protection policies, and power transients directly affect safety behavior and can inject noise into sensing front-ends. The goal is a driver chain that is protected, logged, and coexistence-aware.
Common actuators (option-level)
- DC motor + gearbox: simple control, high start current, stall needs fast protection.
- BLDC: efficiency/noise benefits; still requires robust current and fault handling at the edge.
- Solenoid latch: short, high-current pulse; demands clean flyback and rail stability.
Actuator choice should be evaluated against inrush, braking energy, and required safe-stop behavior.
Drive chain blocks (what must exist)
- Gate driver: UVLO, dead-time, and controlled switching.
- H-bridge / half-bridge: direction control and braking modes.
- Flyback path: manages inductive energy during stop/brake/reverse.
- Current sense: feeds stall detection, OCP, and event logs.
Protection should output explicit flags and counters rather than only “shutting down silently”.
Protection and safety interlocks (tie back to safe barrier behavior):
- Overcurrent / stall: detect quickly; stop or reverse; increment stall_counter; log fault_reason_code.
- Thermal: driver temperature flags (otp_flag) and derating or lockout states.
- UVLO / brownout: avoid half-driven states; count uvlo_count; record rail_min.
- Limit/door inputs: interlock gates motion; enforce safe disable independent of firmware timing.
Power transients and coexistence with sensing AFE:
- Inrush: motor start can droop rails; budget hold-up for safe stop/reverse decisions.
- Braking/reverse: can cause rail spikes; track rail_max and clamp behavior.
- Ground bounce: driver returns can corrupt loop/magneto readings; prefer domain separation and scheduled AFE sampling.
- Blanking windows: temporarily ignore sensor glitches during switching edges while logging the blanking period.
Minimum actuator evidence fields (waveforms → counters → audit):
H2-9. Safety Interlocks — Photo-eye, Safety Edge, Limit Switch, Emergency Stop
The safety layer defines must-not-close conditions and enforces fail-safe behavior via a Permit-to-Move gate (PTM). The intent is predictable action (stop/reverse/hold-open) with an auditable reason code—without diving into certification math.
Interlock inputs (semantic meaning)
- IR photo-eye: beam blocked → “do not close / stop closing”.
- Safety edge: contact pressure → “reverse immediately”.
- Limit switch / encoder: motion boundary and position validity.
- E-Stop: immediate disable + manual reset policy.
- Loop safety channel (optional): presence enforced as a safety veto.
Each input must map to a clear “veto” condition that drives PTM_CLOSE false.
Fault detection (make inputs trustworthy)
- Stuck active: persistent blocked/pressed without expected transitions.
- Stuck inactive: never triggers in expected situations (self-test alarms).
- Line fault: open/short indications or implausible toggling rate.
- Bounce/noise: filtered by debounce + minimum stable time.
When a safety input is not trustworthy, the system should move to a conservative safe state.
Fail-safe philosophy (action priorities):
- Priority: E-Stop > Safety edge > Photo-eye > Position validity > Presence veto.
- Safe-state: on ambiguity or sensor fault → stop motion and/or hold-open (never “close anyway”).
- Recovery: some events are auto-recoverable; E-Stop and selected faults require manual reset.
Permit-to-Move gate (PTM) — the enforcement point:
PTM_CLOSE (permit to close)
- Requires: system_ok, watchdog_ok, position_ok
- Vetoes: E-Stop, safety edge active, photo-eye blocked, safety presence veto
- Outputs: drive_enable_close = cmd_close AND PTM_CLOSE
Any true→false edge generates a safety event with a reason code and snapshot.
PTM_OPEN (permit to open)
- Often less restrictive than close, but still vetoed by E-Stop and critical drive faults.
- Used for safe recovery: hold-open, fault reopen, manual override policies.
- Outputs: drive_enable_open = cmd_open AND PTM_OPEN
Open is usually the conservative response when safety ambiguity appears during closing.
Redundancy patterns (concept-level, deployable):
- Dual-channel safety edge: A/B channels must agree; mismatch → PTM_CLOSE false + fault latch.
- Periodic self-test: schedule a test window; log self-test result and lock out if failed.
- Watchdog coupling: a stuck controller must never continue driving; watchdog vetoes PTM.
| Condition (must-not-close) | Required action | Latch / reset | Evidence fields to log |
|---|---|---|---|
| Photo-eye blocked while closing | Stop → reverse → hold-open (configurable hold time) | Usually non-latching (auto recover once clear) | interlock_src=PE, action=REVERSE, pos, motor_i_peak |
| Safety edge activated | Immediate reverse (highest safety response during contact) | Configurable: latch if repeated or self-test fails | interlock_src=EDGE, edge_active_ms, stall_counter |
| E-Stop asserted | Disable drive enable immediately; block all automatic motion | Latching; manual reset required | fault_reason=ESTOP, recovery=MANUAL, rail_min |
| Position invalid (limit/encoder conflict) | Stop and hold-open or stop-only depending on state | Often latching until operator check | pos_invalid, reason_code, event_ts |
| Safety input line fault (open/short) or stuck-active | Enter safe-state; prohibit close (PTM_CLOSE false) | Latching recommended | line_fault, src, fault_reason_code |
Minimum safety evidence fields (recommended):
H2-10. Event Logging & Interfaces — Make Every Decision Auditable
A barrier controller should behave like a compact black box: every close/open/stop/reverse decision is reconstructible from timestamped evidence. This chapter defines a minimal event schema, evidence snapshots, and edge telemetry interfaces (relay, RS-485 registers, Ethernet uplink) without expanding into cloud platforms.
Minimal event schema (audit-grade)
- Header: ts, event_id, op_mode, cmd
- Snapshot: fused + safety + drive + power evidence in one record
- Outcome: action_taken, result, fault_reason_code
Use a consistent time base (RTC/PTP/monotonic) and keep a monotonic sequence number for ordering.
Where evidence comes from (layered)
- AFE: raw deltas, baseline, quality flags
- Fusion: window, source mask, confidence, reason
- Safety: PTM states, interlock source, latch state
- Drive/Power: motor current, OCP/OTP, rail_min/max, UVLO
Every “decision” should be traceable to one snapshot with stable field definitions.
Recommended snapshot fields (practical and replayable):
Diagnostics counters (fast field triage):
- false_trigger_count: increments when fused presence is rejected by safety/fusion consistency checks.
- interlock_abort_count: increments when PTM_CLOSE drops during an active closing command.
- fault_reopen_count: increments when a fault forces an open/hold-open recovery action.
- stall_event_count: increments on stall detection or OCP-based stop.
- uvlo_event_count: increments on UVLO events or rail droop below threshold.
| Interface | What it should expose (edge telemetry) | Recommended mapping (intent-level) |
|---|---|---|
| Relay outputs | Simple states for external panels: present/fault/moving/closed/open | relay_present, relay_fault, relay_moving |
| RS-485 registers | Live state + last event summary + counters | 0x0001 fused_state, 0x0002 ptm_close, 0x0003 reason_code, 0x0020 false_trigger_count |
| Ethernet uplink | Event streaming / batch upload / buffering during link loss | event_id ordered upload + buffer_depth reporting |
H2-9. Safety Interlocks — Photo-eye, Safety Edge, Limit Switch, Emergency Stop
The safety layer defines must-not-close conditions and enforces fail-safe behavior via a Permit-to-Move gate (PTM). The intent is predictable action (stop/reverse/hold-open) with an auditable reason code—without diving into certification math.
Interlock inputs (semantic meaning)
- IR photo-eye: beam blocked → “do not close / stop closing”.
- Safety edge: contact pressure → “reverse immediately”.
- Limit switch / encoder: motion boundary and position validity.
- E-Stop: immediate disable + manual reset policy.
- Loop safety channel (optional): presence enforced as a safety veto.
Each input must map to a clear “veto” condition that drives PTM_CLOSE false.
Fault detection (make inputs trustworthy)
- Stuck active: persistent blocked/pressed without expected transitions.
- Stuck inactive: never triggers in expected situations (self-test alarms).
- Line fault: open/short indications or implausible toggling rate.
- Bounce/noise: filtered by debounce + minimum stable time.
When a safety input is not trustworthy, the system should move to a conservative safe state.
Fail-safe philosophy (action priorities):
- Priority: E-Stop > Safety edge > Photo-eye > Position validity > Presence veto.
- Safe-state: on ambiguity or sensor fault → stop motion and/or hold-open (never “close anyway”).
- Recovery: some events are auto-recoverable; E-Stop and selected faults require manual reset.
Permit-to-Move gate (PTM) — the enforcement point:
PTM_CLOSE (permit to close)
- Requires: system_ok, watchdog_ok, position_ok
- Vetoes: E-Stop, safety edge active, photo-eye blocked, safety presence veto
- Outputs: drive_enable_close = cmd_close AND PTM_CLOSE
Any true→false edge generates a safety event with a reason code and snapshot.
PTM_OPEN (permit to open)
- Often less restrictive than close, but still vetoed by E-Stop and critical drive faults.
- Used for safe recovery: hold-open, fault reopen, manual override policies.
- Outputs: drive_enable_open = cmd_open AND PTM_OPEN
Open is usually the conservative response when safety ambiguity appears during closing.
Redundancy patterns (concept-level, deployable):
- Dual-channel safety edge: A/B channels must agree; mismatch → PTM_CLOSE false + fault latch.
- Periodic self-test: schedule a test window; log self-test result and lock out if failed.
- Watchdog coupling: a stuck controller must never continue driving; watchdog vetoes PTM.
| Condition (must-not-close) | Required action | Latch / reset | Evidence fields to log |
|---|---|---|---|
| Photo-eye blocked while closing | Stop → reverse → hold-open (configurable hold time) | Usually non-latching (auto recover once clear) | interlock_src=PE, action=REVERSE, pos, motor_i_peak |
| Safety edge activated | Immediate reverse (highest safety response during contact) | Configurable: latch if repeated or self-test fails | interlock_src=EDGE, edge_active_ms, stall_counter |
| E-Stop asserted | Disable drive enable immediately; block all automatic motion | Latching; manual reset required | fault_reason=ESTOP, recovery=MANUAL, rail_min |
| Position invalid (limit/encoder conflict) | Stop and hold-open or stop-only depending on state | Often latching until operator check | pos_invalid, reason_code, event_ts |
| Safety input line fault (open/short) or stuck-active | Enter safe-state; prohibit close (PTM_CLOSE false) | Latching recommended | line_fault, src, fault_reason_code |
Minimum safety evidence fields (recommended):
H2-10. Event Logging & Interfaces — Make Every Decision Auditable
A barrier controller should behave like a compact black box: every close/open/stop/reverse decision is reconstructible from timestamped evidence. This chapter defines a minimal event schema, evidence snapshots, and edge telemetry interfaces (relay, RS-485 registers, Ethernet uplink) without expanding into cloud platforms.
Minimal event schema (audit-grade)
- Header: ts, event_id, op_mode, cmd
- Snapshot: fused + safety + drive + power evidence in one record
- Outcome: action_taken, result, fault_reason_code
Use a consistent time base (RTC/PTP/monotonic) and keep a monotonic sequence number for ordering.
Where evidence comes from (layered)
- AFE: raw deltas, baseline, quality flags
- Fusion: window, source mask, confidence, reason
- Safety: PTM states, interlock source, latch state
- Drive/Power: motor current, OCP/OTP, rail_min/max, UVLO
Every “decision” should be traceable to one snapshot with stable field definitions.
Recommended snapshot fields (practical and replayable):
Diagnostics counters (fast field triage):
- false_trigger_count: increments when fused presence is rejected by safety/fusion consistency checks.
- interlock_abort_count: increments when PTM_CLOSE drops during an active closing command.
- fault_reopen_count: increments when a fault forces an open/hold-open recovery action.
- stall_event_count: increments on stall detection or OCP-based stop.
- uvlo_event_count: increments on UVLO events or rail droop below threshold.
| Interface | What it should expose (edge telemetry) | Recommended mapping (intent-level) |
|---|---|---|
| Relay outputs | Simple states for external panels: present/fault/moving/closed/open | relay_present, relay_fault, relay_moving |
| RS-485 registers | Live state + last event summary + counters | 0x0001 fused_state, 0x0002 ptm_close, 0x0003 reason_code, 0x0020 false_trigger_count |
| Ethernet uplink | Event streaming / batch upload / buffering during link loss | event_id ordered upload + buffer_depth reporting |
H2-11. Validation Plan — Prove Detection + Safety Under Real Conditions
This chapter defines a repeatable, evidence-driven SOP to prove: detection correctness, false-trigger control, safety response, and power/drive robustness under real vehicles and harsh outdoor conditions. Every pass/fail decision must be traceable to scope captures, AFE metrics, and event records.
1) Test instrumentation — minimum evidence channels
- Power rail: capture rail_min/rail_max, UVLO edges, and brownout during motor start/stop.
- Motor current: measure motor_i waveform (start spike, stall signature, reverse timing).
- Safety gate: log or probe PTM_CLOSE, drive_enable, and interlock_src.
- AFE metrics: record loop/magneto features (delta, baseline, quality flags) and decision thresholds.
- Event record: store ts, event_id, reason_code, snapshot, and outcome for every action.
2) Test matrix — combine vehicles × environment × interference × safety/fault
A matrix-driven plan prevents “random testing” and makes results comparable across sites, firmware versions, and installers. Each case is a defined combination of four axes:
| Axis | What varies | Why it matters | Evidence to capture |
|---|---|---|---|
| A — Vehicle | motorcycle / car / truck; speed; lane position; stop-hold; reverse | covers sensitivity extremes and boundary conditions | T_detect_on/off, miss/false counts, AFE delta/baseline |
| B — Environment | wet/rain; ice/cold; hot soak; rebar/metal structures | drift + damping + baseline tracking stress | baseline drift, quality flags, stability windows |
| C — Interference | adjacent lane traffic; gate motion coupling; EMI/noise; surge recovery | main source of false triggers and unstable edges | false_trigger_count, conflict counters, rail noise |
| D — Safety/Fault | photo-eye misalign/blocked; safety edge hit; line faults; E-stop; position conflicts | must-not-close enforcement and safe recovery | PTM_CLOSE drop, action timing, latch reason |
Each test case should be labeled as A#-B#-C#-D# and tied to a saved configuration fingerprint: config_version + fusion_ruleset + threshold_profile.
3) Repeatable SOP — per-case checklist
- Preconditions: temperature bucket, surface state (dry/wet/ice), site notes (rebar, adjacent lane distance), threshold profile.
- Steps: run pass-through → stop-hold → tailgate attempt → clear-out; then repeat at another lane position.
- Capture: (1) scope MP1/MP2/MP3; (2) export event record; (3) read counters.
- Labeling: attach case_id, event_id range, and a short “what happened” note.
- Immediate triage: if fail, tag the suspected layer (AFE/fusion/safety/drive/power) and rerun once to verify repeatability.
The same SOP must be used for loop-only systems and multi-sensor systems (loop + magneto + radar/video trigger), so the evidence format stays consistent.
4) Pass/fail metrics — measurable and auditable
- Detection latency: T_detect_on (vehicle enter → present asserted), T_detect_off (vehicle exit → clear). Budget: sensor + filter + fusion + control.
- Miss / false rates: compute per bucket (wet vs dry, rebar vs none, adjacent-lane vs isolated). Avoid mixing buckets.
- Safety reaction: measure T_interlock (interlock active → PTM_CLOSE low), T_disable (PTM_CLOSE low → drive_enable low), and verify safe-stop distance under the site’s barrier speed.
- Fault handling: verify latch policy (manual reset vs auto recover) matches configuration and never allows “close on unsafe”.
- Power robustness: brownout during movement must not create unsafe toggling. Confirm with rail_min, uvlo_count, and event outcomes.
5) Fault injection focus — prove “must-not-close” is always enforced
- Photo-eye stress: blocked, partially blocked, misalignment; verify PTM_CLOSE veto and consistent reason codes.
- Safety edge: activation during closing; verify immediate reverse and timing boundaries; verify A/B mismatch triggers safe lockout.
- Position validity: simulate limit/encoder conflict; verify safe stop and latch policy.
- E-Stop: assert during motion; verify drive_enable drops immediately and motion cannot auto-resume.
- Power stress: brownout during start/stop; verify no unsafe close and that event records show rail evidence.
6) Example parts list (MPNs) — reference-grade building blocks for validation
The following MPNs are representative options (or equivalents) commonly used in barrier controllers and outdoor detector modules. They are listed to make the validation plan actionable: each category ties directly to measurable evidence fields.
| Block | Example MPNs (or equivalent) | Why relevant to validation | Evidence fields enabled |
|---|---|---|---|
| Motor drive (24V class) | Infineon BTN8982TA (NovalithIC half-bridge); TI DRV8701 (gate driver + ext MOSFETs) | supports controlled braking/reverse; provides fault flags | motor_i_peak, ocp_flag, stall_counter |
| Current sense | TI INA240A1 (current-sense amp); Allegro ACS712 (Hall current sensor) | clean motor current waveform capture under PWM | motor_i, stall_signature |
| eFuse / hot-swap | TI TPS25947; Analog Devices LTC4368 | controls inrush and records/flags faults during brownout | rail_min, uvlo_count, fault_reason_code |
| Buck regulator | TI LM5163; Analog Devices LT8609S | rail stability during motor transients and cold crank | rail_min/max, noise sensitivity vs false triggers |
| RTC / time base | Micro Crystal RV-3028-C7; Abracon AB1805 | stable timestamps for auditable event ordering | ts, monotonic event ordering |
| Nonvolatile log (durable) | Fujitsu FRAM MB85RC256V; Winbond SPI NOR W25Q64JV | event record retention across power loss | event_id, buffered upload reliability |
| MCU (edge control) | ST STM32G0 family (example class); NXP LPC55S family (example class) | deterministic timers for latency, gating, and logging | T_interlock, PTM_CLOSE, counters |
| RS-485 transceiver | TI SN65HVD3082E; Analog Devices/Maxim MAX3485 | field register reads + counter extraction in harsh EMI | register telemetry consistency |
| Ethernet PHY (if uplink) | TI DP83822; Microchip LAN8720A | event upload + buffering behavior tests | upload integrity vs buffer_depth |
| Outdoor surge protection | Littelfuse SMBJ58A (TVS class example); Bourns 2038-xx (GDT class example) | surge recovery validation without false triggers | post-surge stability, false_trigger_count |
Notes: MPNs are examples for BOM planning and evidence-path enablement. Selection must match the site’s motor voltage/current, protection level, and regulatory requirements.
