Access Control Panel: Secure MCU/SE, Door I/O, PoE
← Back to: Security & Surveillance
H2-1. Definition & System Boundary
Intent: establish a hard engineering boundary—Access Control Panel ≠ Reader/Intercom ≠ Video Platform.
An Access Control Panel is the door-execution and audit node of a building security system. It accepts an authorization result (from a reader or a host), drives the lock output, samples door status inputs, and produces an tamper-evident event record that can be uploaded or reconciled later. This page focuses on the panel’s hardware boundary and the evidence hooks required to prove correct behavior in the field.
- Door execution: relay / high-side switching, protection, and “unlock actually happened” proof points.
- Inputs: door contact, REX, tamper, and minimal line supervision signals (interface-level only).
- Security root: secure boot + firmware signing, key storage via secure element, controlled provisioning.
- Evidence chain: sequence counter + timestamps + signature status + reset cause → makes events auditable.
- Comms & power: RS-485 physical robustness, Ethernet secure uplink, PoE PD inrush/UVLO/hold-up.
- Reader internals: fingerprint/face/IR/depth sensor AFE and liveness pipelines (reader pages own this).
- Intercom A/V: audio/video codec, echo cancellation, camera ISP/encoding (intercom/camera pages own this).
- Video platforms: NVR/VMS ingest, decoding/transcoding, recording compliance systems (platform pages own this).
- PoE PSE / switch: power allocation, PSE control loops, L2/L3 switching (PoE switch page owns this).
- Outdoor surge systems: building-wide lightning protection architecture (surge page owns this).
Evidence-first definition (one closed-loop example): A credential is presented → the panel receives an allow/deny result → the panel energizes the lock output for a controlled time → it samples door contact and tamper inputs → it commits an event record with seq + timestamp + signature status → it uploads (or buffers) the record. If any part fails, the failure must be distinguishable by two measurements: (1) rail/actuation waveform, (2) a specific log field or counter.
Cite this figure
“F1. Access Control Panel — System Boundary”, ICNavigator (Security & Surveillance).
H2-2. Top-Level Architecture & Data Flows
Intent: define a stable 5-block architecture and two explicit flows—Control vs Audit—so every later chapter maps back to measurable evidence.
A reliable access control panel is easiest to design and debug when every function belongs to one of five blocks, and every action produces two outputs: a physical outcome (door actuation) and a verifiable record (audit evidence). This chapter pins the architecture and defines the evidence hooks that must exist before adding features.
- Control flow: input/authorization → decision → lock actuation → status sampling (door contact/REX/tamper).
- Audit flow: event creation → seq/timestamp → integrity mark (sign/hash status) → buffer → upload/reconcile.
Minimum audit fields (must exist on day one):
| Field | Why it is required | Field evidence use |
|---|---|---|
| event_id | Defines the action type (unlock, deny, tamper, door forced, power fault). | Enables filtering and deterministic replay checks. |
| seq (monotonic) | Proves ordering and detects drops/duplicates after outages. | Gap detection, non-repudiation chain anchor. |
| time | Human-usable timeline; required for investigations and correlation. | Cross-check with RTC/NTP status; drift diagnosis. |
| actor | Who/what requested the action (reader/channel/host). | Rules out “random unlock” vs authorized automation. |
| result | Allow/deny + actuation outcome (did the output energize). | Separates policy denial from hardware failure. |
| sig_status | Marks integrity state (signed/hashed/failed/unavailable). | Detects tamper, key loss, or provisioning mistakes. |
| reset_reason | Explains reboots that can cause repeated actions or missing logs. | Maps failures to power droop/WD/firmware crash. |
Engineering rule for “deep but not messy” content: Every later chapter must answer two questions with evidence: (1) What waveform or electrical measurement proves the physical outcome? (2) What log field/counter proves the software/security outcome? If a claim cannot be proven by those two evidence types, it does not belong to this page.
Cite this figure
“F2. Top-Level Architecture & Data Flows”, ICNavigator (Security & Surveillance).
H2-3. Root of Trust: Secure MCU/MPU + Secure Element
Intent: pin down where security “lives” on the panel—boot verification, key custody, anti-rollback, and tamper response—with field-auditable evidence.
The panel’s trust model must be explicit: what is verified (firmware + critical config), where keys are kept, how rollbacks are blocked, and what tamper triggers. This chapter defines the minimum implementation that supports reliable forensic answers without relying on platform-side assumptions.
- Verification points: ROM verifies Bootloader (BL); BL verifies Application (APP); APP verifies critical policy/config (e.g., door rules, trust anchors).
- Failure behavior: verification failure must prevent normal door control (safe mode / maintenance-only). The device must still emit an auditable boot record.
- Version binding: each stage must carry a version identifier that is checked against the minimum allowed version (anti-rollback).
- Key custody: device identity keys and signing keys remain non-exportable inside the SE.
- Signing service: the MCU/MPU requests signatures for critical artifacts (e.g., event integrity marks, config seals). The private key never leaves the SE.
- TLS client authentication (high level): SE-backed keys support device identity during secure uplink; only results and status codes are needed on the panel side.
- Monotonic counter authority: store the rollback counter in SE counter (preferred) or a protected NVM/OTP region with write controls.
- Commit rule: counter is only advanced after the new image reaches a trusted milestone (e.g., APP verified + runtime health OK) to avoid “half-updated” lockouts.
- Backup & resilience: counter reads and policy compare must be logged so field failures can distinguish: counter not updated vs wrong version encoding vs provisioning mismatch.
- Lockdown: disable unlock actions and require authorized service mode; log every attempted action while tampered.
- Degrade: allow local door function but block sensitive operations (e.g., key updates, remote unlock, firmware install).
- Record-only: always log tamper state transitions; keep function for low false-positive environments.
Evidence requirements (must be present in board logs and event records):
| Evidence item | What it proves | Minimum fields to log |
|---|---|---|
| Boot verification record | Firmware executed is the expected signed image; failure is diagnosable. | boot_stage, image_version, verify_result, key_slot/id, reset_reason |
| Provisioning identity record | Panel identity is bound to a traceable manufacturing entry. | device_id, cert_serial, issuer, provision_time, seal_state |
| Rollback decision record | Rejects older firmware based on an authoritative monotonic state. | min_allowed_version, image_version, rollback_detected |
| Tamper policy action | Explains why outputs were blocked or restricted under tamper. | tamper_state, tamper_count, policy_mode, action_taken |
Cite this figure
“F3. Key Flow & Trust Boundary”, ICNavigator (Security & Surveillance).
H2-4. Door Outputs: Relay / High-Side Drivers / Safety Interlocks
Intent: make unlock actions reliable and safe—choose the right output topology, add protection and proof points, and enforce interlocks that survive firmware bugs.
A door output is not “a GPIO that turns on a lock.” It is an energy delivery path that must be bounded (time/thermal/current), protected (flyback/short/overcurrent), and provable (measured current/voltage + explicit event fields). This chapter focuses on the output stage and the minimum instrumentation required to diagnose failures quickly.
- Relay output: broad compatibility and galvanic flexibility; main risks are contact wear and weld/stick.
- High-side switch: easier inline current sensing and protection; suited for controlled DC loads and diagnostics.
- Low-side switch: can be cost-effective but requires careful return-path control; keep design evidence on the panel side only.
- Flyback management: clamps inductive kick during turn-off to protect the switch and reduce resets/EMI bursts.
- Overcurrent/short: hardware limit (or fast firmware + sensing) to prevent rail collapse and repeated reboot loops during unlock.
- Thermal/energy limiting: enforce max on-time and duty limits; sustained loads must not exceed safe temperature margins.
- Core rule: if the command is OFF but measurable current/voltage still indicates energization, record a stuck output suspicion.
- Minimum proof signals: current sense (preferred) or output voltage sense + time window; log the decision with a dedicated flag.
- Immediate response: block repeated energize attempts and raise a high-priority audit event (prevents heating and unsafe states).
- Hard timeout: every unlock has unlock_time_max; exceeding it is logged as abnormal even if the door opens.
- Dual confirmation: combine output actuation with door contact transition evidence; missing transition becomes a diagnostic branch.
- Tamper gating: tamper policy from H2-3 determines whether unlock is allowed, degraded, or blocked.
Evidence checklist (field diagnosis starts here):
| Evidence | How to measure | What it discriminates |
|---|---|---|
| Unlock current waveform | Measure output current (sense resistor/driver telemetry) during ON/OFF edges and steady state. | Normal load vs short vs open load; “unlock causes reboot” correlation via rail droop. |
| Driver thermal trend | Track driver temperature proxy (NTC/telemetry) under repeated unlock patterns. | Over-duty usage, enclosure hot spots, derating policy effectiveness. |
| Proof of OFF | After OFF command, check current/voltage within a time window; log stuck-suspect flag. | Relay weld/stick vs firmware timing vs sensing failure. |
Cite this figure
“F4. Door Output Drivers + Protection + Proof Points”, ICNavigator (Security & Surveillance).
H2-5. Inputs: Door Contact / REX / Tamper / Supervised Lines
Intent: reduce false alarms, false unlocks, and wrong states by treating inputs as long-cable sensors with measurable noise, debounce rules, and minimum supervision.
Inputs on an access control panel are exposed to long cables, contact bounce, EMI bursts, and wiring faults. A reliable design separates the problem into: front-end protection, controlled sampling, debounce/threshold policy, and field-auditable evidence (waveforms + counters + statistics). The goal is a deterministic, testable input path rather than “it seems stable on the bench”.
- Dry contact (door contact / REX button): mechanical bounce, oxidation, vibration → multiple raw edges and short glitches.
- Open-collector / active output: pull-up mismatch and cable capacitance → slow edges, threshold hovering, intermittent toggles.
- Long cable exposure: ESD/EFT bursts, induced spikes, ground reference shifts → false triggers and “phantom opens”.
- Protection: clamp transients (ESD/surge), limit fault current (series resistance), and avoid pin overstress during miswiring.
- Filtering: shape fast spikes into bounded edges (RC or equivalent), preventing microsecond-scale noise from becoming state changes.
- Sampling: define a stable sampling window (GPIO/ADC) and keep input state transitions consistent with the debounce policy.
- Hardware: suppress sub-millisecond spikes and protect the pin (cannot “think”, only bound physics).
- Firmware: enforce state rules (time window + hysteresis + minimum stable duration), and expose counts for auditing.
- Acceptance criterion: raw edges can be noisy, but debounced state changes must match real events and remain statistically stable.
- Scope: only detect open, short, and abnormal resistance windows; keep supervision logic board-side and measurable.
- Implementation hint: a single EOL resistor with an ADC window can classify states without expanding into fire-alarm deep zoning rules.
- Output: each supervision decision must log a reason code and the measured value bucket.
Evidence requirements (inputs must be diagnosable in the field):
| Evidence | How to capture | Minimum log/counter fields |
|---|---|---|
| Input waveform at pin | Scope TP-IN and TP-MCU during real cable runs; observe spikes, edge rate, and bounce length. | channel_id, timestamp, capture_tag (optional), threshold_mode |
| Debounce before/after counters | Count raw edges vs debounced transitions to prove noise rejection works. | raw_edge_count, debounced_change_count, glitch_reject_count |
| False-trigger statistics | Daily/hourly abnormal rates per channel; correlate with environment (surge periods, unlock bursts). | false_trigger_rate, top_channels, event_bucket |
| Supervision classification | ADC bucket (normal/open/short/abnormal) with measured window index. | supervision_state, adc_bucket, open_short_flag |
Cite this figure
“F5. Input Front-End + Debounce + Minimal Supervision”, ICNavigator (Security & Surveillance).
H2-6. RS-485 to Readers: Robust Physical Layer (OSDP/Wiegand as Constraints)
Intent: turn “bus unstable / reader drops / CRC explodes” into a measurable diagnosis path: A–B differential quality, common-mode behavior, and error counters.
Reader connectivity issues are typically physical-layer problems disguised as “protocol trouble.” This chapter focuses only on RS-485 port robustness—termination, bias/failsafe, common-mode margin, isolation, and ESD/surge protection. OSDP and Wiegand are treated as interface constraints (cable exposure, I/O levels, ESD) without protocol-stack deep dive.
- Termination: correct end-point termination prevents reflections that create overshoot/ringing and intermittent errors.
- Bias / failsafe: define a stable idle state on A/B so the bus does not “float” into random toggles on long lines.
- Acceptance criterion: A–B waveform shows a single clean transition with bounded ringing, and stable idle with no chatter.
- Measure common-mode: evaluate (A+B)/2 relative to panel reference to detect ground shifts that push transceivers out of range.
- Failure pattern: CRC/timeout bursts correlate with ground events (load switching, lightning, long cable routing).
- Mitigation choice: isolation is selected by measured common-mode headroom and expected surge environment, not by guesswork.
- ESD/surge clamping: TVS and port protection prevent destructive spikes and repeated latch-up behavior.
- Common-mode control: common-mode choke (CMC) reduces coupled noise without changing protocol behavior.
- Isolation barrier (optional): breaks ground loops and extends common-mode tolerance; still requires TVS/termination discipline.
- Waveforms: A–B differential and common-mode voltage must be captured at TP-DIFF and TP-CM.
- Counters: CRC/timeouts/retries and link-down reasons reveal whether the issue is reflection, common-mode, or surge events.
- Interface constraints: Wiegand/OSDP influence pin exposure and ESD hardening; stack parsing is out of scope.
Evidence requirements (minimum observable signals):
| Evidence | How to measure | Minimum log/counter fields |
|---|---|---|
| A–B differential waveform | Scope TP-DIFF near the panel port; check amplitude, symmetry, and ringing/reflections. | baud_profile_tag, diff_quality_bucket |
| Common-mode voltage | Measure TP-CM relative to panel ground; identify excursions beyond the transceiver common-mode range. | cm_bucket, cm_out_of_range_flag |
| Error + retry statistics | Track CRC, timeout, retry rate per port; correlate to unlock bursts and surge events. | crc_error_count, timeout_count, retry_count |
| Link-down reason codes | Record why the port dropped (no response, cm out of range, surge detected, reset). | link_down_events, reason_code, reset_reason |
Cite this figure
“F6. RS-485 Reader Port: Robust PHY Blocks + Measure Points”, ICNavigator (Security & Surveillance).
H2-7. Ethernet Uplink: MAC/PHY, Isolation, Secure Channels
Intent: make “link is up but unreliable / insecure” a deterministic engineering decision: isolate correctly, harden the port, and make secure sessions auditable (cert + handshake logs).
An access control panel’s Ethernet uplink is both a reliability boundary and an attack boundary. A “working” link can still be unstable (EMI, common-mode events, ESD), and a “connected” session can still be insecure (expired credentials, weak key storage, silent fallback to plaintext). This chapter focuses on panel-side design: MAC/PHY + magnetics isolation, port protection, and the minimum secure-channel capabilities required for long-life deployments.
- PHY + magnetics form the primary isolation boundary for the Ethernet port; the board design must respect that boundary.
- Common-mode suppression (CMC and layout discipline) reduces coupled noise that can cause intermittent link renegotiation.
- ESD clamp placement must protect the PHY pins while minimizing added capacitance on high-speed pairs.
- Failure pattern: link-up is stable on bench, then flaps in the field during unlock bursts, nearby motors, or storm conditions.
- Design objective: keep PHY supply and reference quiet, keep differential pairs controlled, and clamp fast transients before they reach the PHY.
- Acceptance criterion: link-drop rate is measurable and stays within a defined target (per day / per week) under worst-case stimuli.
- Identity and trust: the panel must hold a device identity (keypair/cert) and verify peer identity (CA chain / pinning policy).
- Certificate lifecycle: storage, update, expiry detection, and “safe fail” behavior (no silent downgrade to plaintext).
- Operational requirement: failures must be diagnosable (handshake failure codes, cert validity logs, retry/backoff policy).
- Why: separation reduces blast radius (broadcast storms, compromised endpoints) and constrains who can talk to the panel.
- Panel-side expectation: support tagged/untagged operation as a deployment constraint, and log the active network profile.
- Scope: no switch design; only the panel’s compatibility and auditing requirements.
Evidence requirements (Ethernet must be auditable):
| Evidence | How to observe | Minimum log fields |
|---|---|---|
| Link drop reason + rate | Track PHY link events and reason buckets; correlate with environment and load events. | link_event, reason_code, link_down_count, reconnect_ms |
| Reconnect latency | Measure time from link loss to fully established secure session. | reconnect_ms, dhcp_ms (if used), tls_handshake_ms |
| TLS handshake failure codes | Log explicit failure causes (cert verify fail, time invalid, key error, peer mismatch). | tls_fail_code, peer_id, cipher_profile |
| Certificate validity state | Record cert status at boot and after updates; flag expiry/near-expiry. | cert_state, not_after, update_source, verify_result |
Cite this figure
“F7. Ethernet Uplink: Isolation + Protection + Secure Session Path”, ICNavigator (Security & Surveillance).
H2-8. Power Tree with PoE PD: Inrush, UVLO, Hold-Up
Intent: turn “reboots on power-up / unlock causes brownout / PoE is unstable” into a verifiable PD-side design with measurable rails, reason logs, and a defined hold-up energy window.
Power instability in an access control panel is rarely “random.” It usually comes from predictable events: PoE inrush behavior, PD classification and power budget, unlock transients on the lock rail, and insufficient hold-up energy for safe auditing. This chapter is strictly PD-side: PoE input, classification/inrush, DC/DC tree, domain isolation, brownout behavior, and the minimum hold-up window needed to finish critical writes/signatures.
- Classification outcome defines the available power budget; the system must not exceed it during boot or unlock events.
- Inrush must be controlled so the PD starts reliably without repeated detection/reset loops.
- Acceptance criterion: startup completes in a bounded time without brownout resets, and classification remains stable.
- Separate domains: keep the lock rail transient and back-EMF effects from collapsing logic rails.
- Sequencing: bring up secure compute and storage deterministically before enabling high-energy outputs.
- Isolation objective: unlock events should not corrupt audit logs or cause repeated actions after reboot.
- Brownout policy: define what is allowed when rails droop (freeze outputs, block unlock, force safe state).
- Watchdog policy: avoid “reboot loops” that repeat unlock/report actions; log reset reasons and monotonic sequence ids.
- Acceptance criterion: every reset is explainable by a reason register and correlated rail evidence.
- Goal: guarantee a minimum energy window to complete critical storage operations (event record + signature + time tag).
- Definition: hold-up time is measured from input droop detection to the last confirmed commit.
- Output safety: when hold-up begins, outputs should transition to a safe state and block new actions.
Evidence requirements (power must be measurable and explainable):
| Evidence | How to measure | Minimum log fields |
|---|---|---|
| Startup rails + inrush | Scope PoE input and main rails during boot; observe inrush peak and startup time-to-ready. | boot_stage, inrush_bucket, rail_ok_time_ms |
| Unlock rail droop | Trigger on unlock command; capture lock rail current and logic rail droop simultaneously. | unlock_event_id, lock_i_peak, vcore_min_mv |
| Reset reason register | Record reset cause (brownout, watchdog, software reset) and last power state. | reset_reason, brownout_flag, last_event_seq |
| Hold-up duration | Drop PoE input deliberately; measure time to last committed log + signature completion. | holdup_ms, last_commit_seq, sig_complete_flag |
Cite this figure
“F8. PoE PD Power Tree: Inrush • UVLO • Hold-Up • Domain Isolation”, ICNavigator (Security & Surveillance).
H2-9. Audit Logging, Time, and Non-Repudiation Basics
Intent: make access-control evidence usable: who, when, what happened, and whether it was altered—closed-loop on the panel side (no NVR/VMS compliance scope).
A panel is the authoritative source for access decisions and door actions. If logs can be lost, reordered, duplicated, or edited, the “evidence chain” collapses. This chapter defines the minimum viable panel-side audit system: stable time, monotonic sequencing, tamper-evident records (hash chain / signatures), and offline buffering with deterministic overflow behavior.
- RTC is mandatory for continuity: time must not jump backwards across resets or power cycles.
- Time sources: boot-time RTC + optional network time sync (NTP mentioned only as a reference input).
- Holdover strategy: define how time behaves during outages (battery/supercap holdover, and a “time quality” flag).
- Monotonic sequence: every event increments a sequence counter; no duplicates and no “replay gaps” without a logged reason.
- Hash chain: link records by hashing (prev_hash → new_hash) to reveal deletion/reorder attempts.
- Signature checkpoint: sign batches or checkpoints (panel key/SE key) so verification can prove authenticity.
- Ring buffer: deterministic storage with fixed size; define overwrite rules and “overflow markers”.
- Network outage mode: keep logging locally; upload later with ack so the panel knows what was received.
- Resend policy: re-send from last acked sequence to avoid silent loss; avoid duplicate actions (logs may duplicate, actions must not).
Evidence requirements (audit must be verifiable):
| Evidence | How to validate | Minimum fields |
|---|---|---|
| Audit field set | Confirm every event records identity, door/channel, result, and device state. | event_id, seq, time, actor, door_id, result |
| Time quality | Prove whether time is RTC-only, synced, or degraded; log jumps/drift. | time_source, time_quality, time_jump_flag |
| Hash / signature verification | Verify chain continuity and signature status for each batch or checkpoint. | prev_hash, hash, sig_status, key_id |
| Outage replay consistency | Disconnect network / cut power and replay logs; ensure seq continuity and deterministic overflow markers. | buffer_state, overflow_count, last_acked_seq |
Cite this figure
“F9. Audit Logging: Time + Sequence + Hash Chain + Signed Upload”, ICNavigator (Security & Surveillance).
H2-10. Validation Plan: Functional + Security + EMC/Power
Intent: provide a reusable SOP that proves readiness across door actions, communications, security root, PoE power integrity, and board-level immunity—each with measurable pass/fail evidence.
Validation should not be a checklist of “features work.” It must prove the panel remains correct under concurrency, faults, power events, and interference. This SOP is designed to be repeatable across products and manufacturing lots by using defined stimuli, specific measurement points, required logs, and pass criteria.
- Multi-door concurrency: simultaneous unlocks, mixed inputs, and burst events; verify no missed events and no duplicated actions.
- Abnormal inputs: bounce/noise injection, open/short states, tamper triggers; verify classification and stable debounced outputs.
- Lock load edges: maximum current and worst-case duty; verify thermal limits and safe cutoffs.
- Signature enforcement: attempt boot with invalid signature; confirm deterministic failure and evidence logs.
- Rollback attempts: install older firmware; confirm anti-rollback counters prevent downgrade and log the reason.
- Key erase / tamper: trigger tamper input; verify configured policy (lockout / degrade / record-only) and audit integrity.
- PoE range: validate across expected PoE voltage and load classes; no reboot loops at cold start.
- Unlock transient: unlock bursts under worst-case lock load; verify logic rails droop stays above brownout thresholds.
- Hold-up: cut PoE during critical logging; prove last commit + signature completes within guaranteed hold-up window.
- ESD points: Ethernet port, RS-485 port, input terminals; verify recovery behavior and no silent counter corruption.
- EFT/noise coupling: inject bursts on long I/O lines and power; confirm debounce stability and no false unlock.
- Pass condition: explicit “what changed” logs (link drops, resets, error counters) must remain within limits.
Test record template (minimum artifacts to keep):
| Test Item | Required captures | Pass criteria (examples) |
|---|---|---|
| Unlock burst | TP-LOCK current waveform + TP-CORE min voltage + event logs (seq continuity). | No brownout reset; no duplicated unlock; logs continuous. |
| RS-485 long line | TP-DIFF + TP-CM waveforms; CRC/timeout/retry counters over time. | Error rates below target; no link-down storm. |
| TLS/cert lifecycle | Handshake logs, cert state logs, fail codes; reconnect time after link flap. | No plaintext fallback; explicit failure reasons; bounded reconnect time. |
| Power cut during commit | PoE droop moment + hold-up duration + last_commit_seq + sig_complete flag. | Commit completes within hold-up window; no log corruption. |
Cite this figure
“F10. Validation Map: Probes + Logs + Pass/Fail Evidence”, ICNavigator (Security & Surveillance).
H2-11. Field Debug Playbook: Symptom → Evidence → Isolate → Fix
Intent: turn 8–10 common field issues into a “2-measurement decision tree” so engineers can isolate root cause fast and apply the first safe fix with auditable evidence.
Field failures usually look random because the first response is “swap parts.” This playbook forces a repeatable workflow: for each symptom, take two measurements (1) a rail/output waveform and (2) a bus/log evidence set, then follow a small number of deterministic split conditions. Each branch ends in a root-cause pool and a first fix that is safe and testable.
- Pick the symptom that matches the field report (temperature-only, load-only, network-only, etc.).
- Take the first two measurements: (A) rail/output waveform, (B) bus + log fields.
- Apply split rules (brownout? CRC spike? seq discontinuity? output current persists?).
- Land in a root-cause pool and apply the “first fix” (then re-run the same two measurements).
- Measure #1 (rail/output): capture VLOCK and ILOCK during unlock (peak + hold current), plus VCORE min.
- Measure #2 (logs): unlock_event_id, lock_i_peak, vcore_min_mv, reset_reason, door_contact_state.
- Split: if VCORE drops near BOR/UVLO → Power Integrity pool; else if ILOCK peak is high/long → Output/Load pool.
- Measure #1: relay coil voltage/current and contact-side current after OFF command (does current persist?).
- Measure #2: cmd_off_timestamp, coil_pwm/duty (if used), weld_detect_flag, temp.
- Split: if command OFF but load current persists → Output Stage pool (weld/contact); if coil voltage decays slowly → flyback/driver path.
- Measure #1: A/B differential waveform + common-mode voltage at the RS-485 port.
- Measure #2: crc_err_count, timeout_count, retry_rate, link_state, bus_reset_count.
- Split: if CM voltage exceeds safe range / large spikes → RS-485 Physical Layer pool; else if waveform clean but errors persist → firmware retry/backoff & timing policy.
- Measure #1: PoE input + PD PG/UVLO signals + VCORE ramp (time-to-ready, brownout dips).
- Measure #2: reset_reason, brownout_flag, boot_stage, inrush_bucket, rail_ok_time_ms.
- Split: if UVLO triggers before rails settle → Power Integrity pool (inrush/PG/UVLO); if VCORE stable but reboot continues → watchdog/boot policy.
- Measure #1: power-cut test (hold-up window) while generating events; confirm last commit behavior.
- Measure #2: seq continuity, last_acked_seq, overflow_count, sig_status, time_quality.
- Split: if seq discontinuity correlates to reboot/power loss → Power Integrity + commit window; if overflow_count increases → buffer sizing/overwrite policy.
- Measure #1: tamper input waveform at terminal + internal sampled state (glitch width vs debounce window).
- Measure #2: tamper_raw_count, tamper_debounced_count, policy_action, input_fault_flags.
- Split: if raw glitches correlate with unlock current/EMI → Input Front-End pool; if raw is stable but policy too aggressive → policy thresholds/state machine.
- Measure #1: VCORE min during unlock + PHY link-state pin/event timing correlation.
- Measure #2: link_down_count, reconnect_ms, tls_fail_code, cert_state.
- Split: if link drops align with VCORE dips → Power Integrity pool; if link stable but TLS fails → cert/time validity + key storage.
- Measure #1: RS-485 common-mode and Ethernet port common-mode under real cabling conditions.
- Measure #2: error counters by location (CRC, link drops), plus any “ground health” flags if available.
- Split: location-specific CM spikes → isolation/CM suppression; broad failures → power budget / inrush or configuration mismatch.
What proves it: VCORE min crosses BOR; reset_reason shows brownout; PoE PG/UVLO toggles; failures correlate with unlock bursts or cold start.
First fixes (safe + testable):
- Separate logic rail and lock rail (domain isolation) and re-check VCORE min during unlock.
- Control inrush and ensure PG/UVLO thresholds match real ramp behavior.
- Add/resize hold-up energy for “commit + signature” window; verify holdup_ms vs last_commit_seq.
MPN examples (choose per design constraints):
- PoE PD controller: TI TPS2373-4, TPS2372-4; Analog Devices (LT) LTC4269-1; Microchip PD70224.
- eFuse / hot-swap / inrush limiting: TI TPS25947, TPS25940; Analog Devices LTC4366 (surge stopper class); onsemi NCP45520 (load switch class).
- Buck regulators (logic rails): TI TPS62130, TPS62133; Analog Devices LTC3621; MPS MP2145.
- Supercap / backup controller (RTC/hold-up): TI BQ25570 (harvest/backup class), Analog Devices LTC3225 (supercap charger), Maxim/ADI MAX38888 (example class).
What proves it: command OFF but load current persists; coil decay abnormal; thermal rise or OCP triggers under duty.
First fixes:
- Add correct flyback strategy (diode/TVS) and validate coil/current decay and contact release time.
- Add current sense / weld detection and enforce timeout (prevent indefinite energization).
- Use protected high-side/low-side drivers where relay is failure-prone.
MPN examples:
- High-side switch / protected driver: Infineon BTS50055-1TAD (PROFET class), TI TPS1H200A (high-side switch class), ST VNQ5E050AK.
- Low-side MOSFET driver: TI DRV103 (solenoid/valve driver), Allegro A4925 (driver class).
- Relay (example families): Omron G5Q series, Panasonic TQ series (final selection depends on current/voltage rating).
- Flyback / clamp: Littelfuse SMBJ/SMCJ TVS families; Vishay SS14 Schottky diode family (examples, choose per coil energy).
What proves it: CRC spikes correlate with CM excursions; differential amplitude collapses on long lines; failures are location/cabling dependent.
First fixes:
- Verify termination + biasing, and re-measure A/B differential + CM at the port.
- Add galvanic isolation (if CM/ground loop is dominant) and harden with proper ESD protection.
- Use robust transceiver with failsafe and wider CM tolerance; confirm error counters drop.
MPN examples:
- RS-485 transceiver: TI SN65HVD3082E, SN65HVD75; Maxim/ADI MAX485 family (classic); ST ST485.
- Isolated RS-485: Analog Devices ADM2587E; TI ISO1410 (isolator class) + transceiver.
- ESD protection for data lines: Nexperia PESD series; Littelfuse SP05 family (examples).
What proves it: seq gaps/jumps; last_acked_seq regressions; overflow_count rises; sig_status fails; time_quality degraded after outages.
First fixes:
- Make logging commits atomic (write-ahead or checkpoint), then re-test power-cut during commit.
- Enforce ACK-based resend from last_acked_seq; never assume upload success without ack.
- Improve RTC holdover and record time_quality; block signing if time invalid (log the reason explicitly).
MPN examples:
- Secure element (key storage/signing): Microchip ATECC608B; Infineon OPTIGA Trust M; NXP SE050.
- External RTC (holdover): Maxim/ADI DS3231; NXP PCF8563.
- Non-volatile storage (event buffering): Winbond W25Q64 (SPI NOR), Micron MT25Q family; if higher endurance needed: FRAM families (e.g., Fujitsu/Cypress/Infineon FRAM lines).
What proves it: raw tamper pulses/glitches align with unlock current or ESD events; debounced count differs heavily from raw count.
First fixes:
- Add RC filtering + proper ESD clamps at terminals, then confirm glitch width is below debounce window.
- Improve firmware debounce (time + state consistency) and log both raw and debounced counters.
- If long wires dominate, add input isolation/conditioning and enforce supervised thresholds (minimal).
MPN examples:
- ESD/TVS for I/O: Littelfuse SMF/SMBJ TVS families; Nexperia PESD series (choose per line and capacitance).
- Digital isolator (if needed): TI ISO7721; Analog Devices ADuM1250 (example class).
- Analog front-end building blocks: comparators like TI TLV3201 / Microchip MCP6561 for thresholding (examples; final selection depends on thresholds/ESD strategy).
Cite this figure
“F11. Field Debug Decision Tree (2 Measurements → Root Cause)”, ICNavigator (Security & Surveillance).
Request a Quote
H2-12. FAQs ×12 (Accordion; each maps back to chapters)
Relay clicks but the door never unlocks—driver issue or lock wiring? (→ H2-4 / H2-11)
Answer: If the relay clicks but the door doesn’t unlock, check the driver circuit and lock wiring. Measure the relay coil voltage during the unlocking command to ensure it is receiving enough current. Verify if the lock is drawing power during the unlock command. If the issue persists, check the relay contacts for welding or slow release due to inadequate power or driver faults.
What to Measure:
- Measure relay coil voltage (voltage across the coil during unlock).
- Check the current through the door lock (ILOCK) to see if it’s within the expected range.
First Fix: If relay coil voltage is normal but the lock does not actuate, replace or service the relay to avoid welding. Ensure the lock wiring and driver circuits are correctly connected.
Door randomly unlocks once a day—input bounce or firmware replay? (→ H2-5 / H2-9 / H2-11)
Answer: Random door unlocking may be caused by input bounce or firmware replay issues. Check if the input signal from the door contact or REX switch is stable. Measure the debounced count for irregularities and check if the event sequence is intact.
What to Measure:
- Measure the door contact and REX signal waveforms to identify bounce or noise.
- Check the event logs to ensure sequence integrity and verify if the same event is being replayed.
First Fix: If input bounce is detected, improve the hardware debounce or adjust the firmware debounce window. If sequence integrity is compromised, check the event handling logic and adjust the replay settings.
CRC errors explode only on one building—ground potential or termination? (→ H2-6 / H2-11)
Answer: CRC errors that occur only in one building may indicate ground potential issues or improper termination. Check for common-mode voltage and ensure that RS-485 termination is applied correctly. If errors persist, test the ground potential between different parts of the building’s network.
What to Measure:
- Measure the differential signal (A/B) and common-mode voltage at the RS-485 terminal.
- Check the error count on the RS-485 bus to identify if errors correlate with ground potential fluctuations.
First Fix: If common-mode voltage exceeds acceptable levels, implement isolation or common-mode suppression. Recheck termination and biasing on the bus.
OSDP works on bench but fails in field—what 2 waveforms prove the cause? (→ H2-6 / H2-11)
Answer: When OSDP works on the bench but fails in the field, measure the A/B differential signal and the common-mode voltage. These two waveforms will help identify if the issue is related to wiring, common-mode interference, or signal degradation due to environmental factors.
What to Measure:
- Measure the A/B differential signals on the RS-485 bus.
- Measure the common-mode voltage at the RS-485 terminals to check for grounding issues.
First Fix: Apply appropriate isolation and improve grounding to reduce common-mode interference. Recheck the integrity of the differential signal.
PoE powers up but reboots during unlock—hold-up or inrush margin? (→ H2-8 / H2-11)
Answer: If PoE powers up but reboots during unlock, the issue is likely related to either insufficient hold-up energy or inadequate inrush margin. Check the inrush current during power-up and measure the rail droop during the unlock action.
What to Measure:
- Measure the inrush current during power-up and monitor voltage levels on the key rails.
- Check the hold-up duration and verify if the power budget is sufficient to maintain system stability during unlock.
First Fix: Increase the hold-up energy to ensure that critical systems remain powered during the unlock process. Adjust inrush current limits if necessary.
Audit logs show duplicates after outage—sequence counter or time sync? (→ H2-9 / H2-11)
Answer: Duplicate events in audit logs after an outage may result from a sequence counter failure or time synchronization issue. Verify the sequence continuity in the logs and check for discrepancies in the timestamp and event order.
What to Measure:
- Measure the sequence counter to ensure continuity and verify if any events were duplicated.
- Check the timestamp consistency and compare the last acknowledged sequence with the first unacknowledged sequence.
First Fix: If sequence continuity is compromised, implement more robust ACK-based error handling. Verify time sync settings and ensure that timestamps are consistent during reconnection.
Tamper triggered but enclosure is fine—ESD coupling or input threshold? (→ H2-5 / H2-10 / H2-11)
Answer: False tamper triggers can occur due to electrostatic discharge (ESD) coupling or improper input threshold settings. Measure the tamper input signal and assess the input’s threshold to determine if it is overly sensitive or influenced by environmental factors.
What to Measure:
- Measure the tamper input waveform and check for any glitches or interference.
- Check the tamper threshold and debounce settings to ensure that they are not too sensitive.
First Fix: Implement better ESD protection and ensure that input thresholds are properly configured to avoid false triggers.
Secure boot enabled yet unauthorized firmware runs—SE usage wrong? (→ H2-3 / H2-11)
Answer: If secure boot is enabled yet unauthorized firmware runs, the issue is likely with the secure element (SE) configuration or key management. Verify that the SE is correctly handling key storage and that firmware signatures are being validated correctly during boot.
What to Measure:
- Verify the boot process log to check if the firmware signature is being correctly validated during the boot sequence.
- Check the secure element’s key storage and validation process to ensure that the correct keys are being used.
First Fix: Ensure that the SE is properly configured to manage keys and verify firmware signatures before allowing it to run.
Rollback protection fails after board swap—where should monotonic counter live? (→ H2-3 / H2-9)
Answer: If rollback protection fails after a board swap, the issue is likely due to improper storage or handling of the monotonic counter. Ensure that the monotonic counter is stored in a secure, non-volatile location that survives power cycles and board swaps.
What to Measure:
- Check the monotonic counter value and verify if it persists across power cycles or board swaps.
- Check the logs for rollback attempts and verify if the counter prevents them.
First Fix: Store the monotonic counter in a secure element or other non-volatile memory that survives power cycles and board swaps.
Ethernet link is up but TLS fails—clock/cert storage/entropy? (→ H2-7 / H2-3 / H2-9)
Answer: If the Ethernet link is up but TLS fails, the issue is likely related to clock synchronization, certificate storage, or insufficient entropy. Verify the system clock and ensure that it is synchronized with an accurate time source. Check certificate storage and entropy sources for issues.
What to Measure:
- Measure the system clock’s accuracy and verify time synchronization.
- Check the certificate storage and ensure that certificates are properly loaded and valid.
First Fix: Synchronize the system clock with an external time source and ensure that certificate storage is correctly configured. Ensure adequate entropy sources for secure key generation.
Reader works until lock actuates—EMI coupling or rail droop? (→ H2-4 / H2-8 / H2-11)
Answer: If the reader works until the lock actuates, the issue may be due to EMI coupling or rail droop. Check the power supply rails during lock activation and verify if the signal integrity is affected by electromagnetic interference.
What to Measure:
- Measure the power rail voltage during the unlock action to check for droops.
- Check the differential signal on the RS-485 bus during lock activation to identify any EMI coupling.
First Fix: Apply proper EMI shielding and isolation. Ensure that the power rails have adequate decoupling to prevent voltage sag during high-current events.
How to migrate keys in manufacturing without exposing secrets? (→ H2-3)
Answer: To migrate keys during manufacturing without exposing secrets, use secure key provisioning methods that ensure private keys are not exposed. Utilize secure elements to store keys and use encrypted channels for key transfers. Make sure that keys are never written to unprotected memory or transferred in an insecure way.
What to Measure:
- Check the key provisioning logs to ensure that keys are securely transferred using encrypted methods.
- Ensure that key storage is secure and that unencrypted key migration does not occur.
First Fix: Use secure key management systems such as secure elements (SE) to handle key provisioning and storage. Encrypt keys during the transfer process and validate their integrity after migration.
