Door Control Unit: Motor Drive, Pinch Sensing, Redundancy & Logs
← Back to: Rail Transit & Locomotive
A rail Door Control Unit is not just a motor controller: it combines torque/pinch decision logic, redundant voting, and tamper-resistant event evidence to stop safely under real-world EMI and power dips. This guide focuses on what to measure, what to log, and what to tune first so field failures can be reproduced, diagnosed, and improved through a controlled threshold update loop.
H2-1. System Scope & Boundary
This page focuses on the Door Control Unit (DCU) as an electronic control-and-evidence subsystem for rolling stock doors: actuation, pinch/torque sensing, redundancy decisions, and event/fault traceability under rail power and EMC constraints.
- Actuation path: motor/actuator drivers (DC motor / BLDC / linear actuator), start/stop ramps, torque limiting, and commanded motion profiles.
- Pinch & torque evidence: current/torque sensing AFEs, detection windows, drift/noise boundaries, and how evidence is captured (waveforms + counters).
- Travel/position sensing: encoder/Hall/limit-switch interfaces, plausibility checks, and fault classification from position-vs-time signatures.
- Redundant inputs & voting: dual sensors, dual commands, voter rules (mismatch handling, timeout policy), and safe-state transitions.
- Event/fault logs: pre/post-trigger snapshots, counters, and trace fields that support maintenance and audits.
- Rail power & compliance touchpoints: wide-input adaptation, brownout strategy, and EMC/ESD/surge immunity aligned with EN 50155 and EN 50121 expectations.
- TCMS dispatch/scheduling logic (operational orchestration beyond DCU boundary).
- Platform Screen Door (PSD) controllers (wayside/station domain, different interfaces and constraints).
- Train-wide power distribution architecture (PDU, traction supply, substation topics).
- Full train backbone topology (network design at vehicle level).
H2-2. Operational Failure Narratives
DCU troubleshooting and compliance are evidence-driven: each field symptom must map to a mechanism split, a minimal evidence set, and a first corrective action. The narratives below define the search intent and set the evidence vocabulary used throughout the page.
Symptom: the door reverses direction during closing, sometimes without visible obstruction. Mechanism split: (A) false pinch/torque trigger from sensing drift/noise, or (B) control instability that creates a current spike interpreted as pinch.
- Evidence to capture (2 signals): motor current snapshot (≈200–300 ms pre-trigger) and travel/position vs time in the same window.
- First fix: tighten the detection window logic (debounce + plausibility with position slope) before changing mechanical parts; confirm whether the spike is electrical or load-induced.
Symptom: command is issued but the actuator does not move, or starts and immediately stops. Mechanism split: (A) undervoltage/brownout prevents a complete actuation cycle, or (B) redundant input/voter logic blocks motion due to mismatch/timeout.
- Evidence to capture (2 fields): brownout counter / minimum rail voltage during the attempt, and voter mismatch or “inhibit reason” code.
- First fix: verify the power rail integrity under load (inrush + wiring drop) and ensure the inhibit reason is logged deterministically (single source of truth).
Symptom: door opens when it should remain closed, often correlated with high-EMI events (traction switching nearby) or specific locations. Mechanism split: (A) sensor reference disturbance (EMC/common-mode injection), or (B) drift/aging pushes thresholds across a decision boundary.
- Evidence to capture (2 items): input edge timing (glitch count) and a correlated EMC context marker (supply transient or comm error burst).
- First fix: enforce input plausibility gating (multi-sample + time window) and audit the common-mode return path before increasing thresholds.
Symptom: a field incident cannot be reconstructed; logs are missing, timestamps are inconsistent, or fault causes are ambiguous. Mechanism split: (A) evidence capture is not prioritized during brownout/reset, or (B) the event packet lacks a minimal, standard schema.
- Evidence to capture (2 checks): verify “pre/post-trigger window” presence and a monotonic sequence counter (or trusted timestamp consistency).
- First fix: define a minimal evidence packet and make it atomic (commit + integrity marker) so partial writes are detectable and recoverable.
H2-3. Functional Architecture Decomposition
A Door Control Unit can be engineered as three coupled loops: actuation, safety decision, and evidence. The decomposition below defines interfaces, boundaries, and the minimum set of internal blocks required to make failures diagnosable and audit-ready.
Rail door electronics typically sit on a fluctuating DC bus (24/48/110 V) and must split power into at least three rails: a motor rail (high current), a logic/sensing rail (quiet reference), and a hold-up rail (short-lived evidence commit). The front-end is a protection chain rather than a simple regulator: surge clamp, reverse protection, controlled inrush, and fault reporting.
- Design boundary: faults must be classified as “power integrity” vs “control/sensing” before any algorithm tuning.
- Evidence hook: capture
Vmin,brownout_count, and inrush-relatedinhibit_reasonwhen motion is blocked.
The control core is defined by a deterministic door state machine (idle/closing/opening/obstacle/reopen/latched) and a safety arbiter that gates motion whenever redundancy inputs disagree or timing constraints are violated. A safety MCU (or lockstep domain) is used to make “inhibit decisions” reproducible and explainable in logs.
- Safety path: inhibit and safe-state commands must be able to override the nominal motion controller.
- Evidence hook: log the exact decision code (
inhibit_reason) and the voter inputs used.
The driver stage is treated as a hardware safety layer: controlled ramping, short-circuit response, and predictable stop behavior when supply or sensing is degraded. DC motors typically use an H-bridge; BLDC actuators use a 3-phase driver with commutation support. The architecture must explicitly define the “safe stop” output state (coast, brake, or controlled reverse) used during pinch events.
- Boundary rule: drive faults (OC/SC/OT) are captured and acted on before any higher-level logic retry.
- Evidence hook: store
fault_latch, peak current, and stop mode during transitions.
Pinch detection is a time-bounded classification problem, not a single threshold. The sensing AFE provides (a) a current/torque estimate with known latency, and (b) a calibrated error budget (offset/drift/noise) so that decision thresholds remain meaningful across temperature and aging. The sensing chain must declare where filtering happens (analog vs digital), because filtering placement changes delay and false-trigger behavior.
- Minimum outputs: filtered current, raw/fast current snapshot, and a derived “torque proxy” used in decisions.
- Evidence hook: log the pre/post window snapshot and the threshold/window parameters used at the time of the event.
Travel sensing anchors pinch decisions and prevents “electrical spikes” from being misinterpreted as obstacles. A robust design uses at least one continuous sensor (encoder/Hall) plus a discrete reference (limit switch) for plausibility and homing. The DCU should expose derived features such as travel slope, stall signature, and time-to-close to support both diagnostics and maintenance.
- Plausibility checks: position must evolve consistently with commanded direction and expected acceleration envelope.
- Evidence hook: store
travel_time,stall_flag, and position snapshots around events.
Redundancy is implemented as a rule set: mismatch windows, timeouts, and a defined behavior when sensors or commands disagree. The voter output is not only a control gate but also a forensic record: each inhibit must be traceable to specific inputs and timing. This chapter treats voting as a “decision contract” rather than a wiring diagram.
- Key fields:
voter_mismatch,mismatch_duration,inhibit_reason, and recovery condition. - Boundary rule: voter policy must be deterministic across resets (no ambiguous inhibit states).
Event recording must be designed as an atomic transaction: pre-trigger buffer → event header → payload (snapshots/counters) → integrity marker. During rail brownouts, partial writes are common; the design must detect and report incomplete packets rather than silently losing evidence.
- Minimal packet: timestamp, state, command, current snapshot, position snapshot, and reason code.
- Evidence hook: sequence counter + integrity flag to prove completeness.
The interface is treated as a transport for DCU evidence and state: commands in, status out, and event uploads. Network topology is out of scope; only the DCU-required fields and update semantics are defined (e.g., which faults latch, which counters monotonic).
H2-4. Power Domain & Brownout Strategy
In rail environments, “power integrity” is a primary safety input. Brownouts can create ambiguous states where motion, sensing, and logging fail in different orders. A DCU must define a safe-state policy, a hold-up budget, and an evidence-write priority that remains valid during transient events.
- Voltage variation: DC bus deviation shifts driver headroom and sensing references, changing pinch decision margins.
- Short interruptions: tens of milliseconds can reset logic while the actuator still has inertia, creating partial moves and unclear fault causes.
- EFT / surge: fast pulses and surges can inject common-mode currents that corrupt inputs and timestamps even when the system “keeps running”.
- Start-up transients: inrush and wiring drop can look like a brownout during the exact window when the door is commanded to move.
A DCU must declare how motion is terminated when rail voltage falls below an operating threshold. Two common policies are used depending on the mechanical design and safety case:
- Safe-open: release or reverse to reduce pinch risk when evidence indicates a potential obstruction but the supply is degrading.
- Safe-stop: controlled stop (brake/coast) and latch the system until power integrity and redundancy conditions recover.
Hold-up design is a time budget problem: the hold-up rail must keep the control core alive long enough to complete a minimal evidence commit. The budget can be structured into three deterministic intervals:
- t_detect: detect supply drop (rail monitor) and raise an internal “power degrade” flag.
- t_commit: commit a minimal event packet (pre/post snapshot + reason codes + counters) with an integrity marker.
- t_safe: transition the actuator to safe-open or safe-stop, then enter a controlled low-power state.
When power collapses, “partial evidence” is the most damaging outcome because it creates ambiguity. A minimal packet should be prioritized over verbose logs:
- Always-first fields: timestamp/sequence, door state, command, inhibit reason, current snapshot, position snapshot.
- Then counters: brownout count, retry count, voter mismatch count, fault latch.
- Integrity markers: CRC and a “commit complete” flag to detect interrupted writes after reboot.
H2-5. Motor Drive & Torque Control
Door actuation must be controllable and explainable. Motor control shapes the current/torque signature; later pinch logic relies on this signature to distinguish true obstruction from normal load changes and electrical artifacts.
A DC motor (H-bridge) and a BLDC actuator can reach the same mechanical outcome but produce different electrical fingerprints and fault modes. The DCU architecture must treat these as different evidence classes: DC motors often show abrupt current steps during friction changes; BLDC systems may show commutation-related ripple, back-EMF estimation errors, or regenerative energy during backdrive.
- H-bridge typical evidence: fast current rise on stall, strong asymmetry between directions, and sharp peaks at start/stop.
- BLDC typical evidence: phase-related ripple and transient behavior around commutation or low-speed operation.
Pinch robustness improves when the actuation system is bounded. Closed-loop current control limits di/dt and constrains peak current,
making the “normal envelope” predictable across supply variation. Open-loop drive turns current into a noisy byproduct of load, wiring drop, and rail state,
increasing false triggers and reducing explainability.
- Closed-loop advantage: peak current and rise time become policy-controlled rather than environment-controlled.
- Evidence hook: log a current error metric (target vs measured) during obstacle events to separate “load” from “control instability”.
Soft-start shapes the initial torque ramp so that the door does not create a startup spike that looks like pinch. Soft-stop prevents inertia rebound and reduces the chance that stop transients are misclassified as obstruction. The goal is not comfort, but a stable and repeatable waveform signature.
- Soft-start focus: constrain rise time so the detection window sees a known envelope.
- Soft-stop focus: define the stop mode (coast/brake/reverse) and record it in the event packet.
Torque limiting is a model-driven policy that accounts for temperature, door position, and expected friction profile. A single peak-current threshold is insufficient because the same current can mean “normal friction” in one condition and “obstruction” in another. A practical approach uses a time-windowed score derived from current magnitude, slope, and travel plausibility.
- Model inputs: current (fast + filtered), position slope, temperature, and door state.
- Model outputs: torque proxy, margin to limit, and an obstacle score within a defined window.
Backdrive occurs when external force or mechanical elasticity moves the door against commanded direction. This creates electrical patterns that can be misread as pinch unless explicitly detected. Backdrive detection compares commanded direction, measured travel direction, and motor current sign/behavior to separate “external push” from “true obstacle”.
- Detection cue: travel direction conflicts with command while current signature indicates regeneration or abnormal polarity.
- First response: transition to a defined safe-stop mode and log a dedicated reason code rather than reusing pinch codes.
H2-6. Pinch Detection & Sensing AFE
Pinch detection is only as reliable as the measurement chain. The sensing AFE must balance latency and noise immunity, quantify offset/drift/noise, and keep thresholds meaningful across temperature and aging.
A practical rail DCU often benefits from two measurement paths: a fast path for protection and tight timing windows, and a trusted path for evidence-grade reporting. Shunt amplifiers typically provide low-latency fast measurements; isolated ΣΔ modulators can provide strong common-mode robustness for trusted measurements. The key is to declare which path feeds which decision.
- Fast path: minimal delay for windowed detection and rapid safe-stop triggers.
- Trusted path: high immunity and stable calibration for audit-ready evidence snapshots.
Obstruction events occur on short mechanical time scales. If sensing latency is large or varies (jitter), the decision window misaligns with the event dynamics: peaks appear “late”, thresholds require excessive margin, and false/late triggers increase. This is why the DCU should record both a detection-window ID and the effective sensing delay used when the event was declared.
- Mis-trigger pattern: electrical spikes land inside the window while the true load change lands outside.
- Evidence hook: store
sense_delay(or a derived class) andwindow_idalongside the obstacle score.
Thresholds must be derived from an error budget, not from a single lab trace. Offset shifts the entire measurement baseline; drift moves it with temperature and aging; noise creates transient peaks that look like obstructions. The DCU design must explicitly allocate budget to each term and choose filtering that reduces noise without pushing latency beyond the allowed response time.
Temperature affects both the door mechanics (friction profile) and the electronics (gain/offset drift). This can compress the margin between normal closing current and pinch thresholds. Robust designs either compensate thresholds by temperature bands or normalize decisions by a learned baseline current envelope per travel segment.
Pinch response is a bounded timeline: detection delay plus actuation reaction must remain inside the allowed stopping distance. This contract forces a clear allocation: sensing latency budget, computation budget, and driver reaction budget. Evidence capture must not violate the reaction budget; it should run in parallel with (or immediately after) safe-stop initiation.
H2-7. Redundancy & Voting Logic (1oo2 / 2oo3)
Rail door control must explicitly separate false actions (unnecessary stop/reopen) from missed actions (failure to inhibit or stop). Redundancy is implemented as a deterministic voting policy with defined mismatch windows, recovery rules, and auditable reason codes.
Dual position inputs are not only for backup; they provide cross-checking. The DCU should validate (1) agreement within a tolerance envelope and (2) trajectory plausibility with respect to the commanded direction and expected travel slope. When disagreement occurs, the policy should attempt basic fault isolation (transient vs persistent mismatch) before declaring a confirmed safety event.
- Mismatch window: classify mismatches by duration (
mismatch_ms) and slope (slow drift vs sudden jump). - Dropout detection: detect stuck-at, missing transitions, or invalid encoding and tag the affected channel.
Lockstep execution is effective for detecting core computation errors, but it does not automatically protect against shared input faults. Independent channels can increase resilience by separating sampling, filtering, and timing, but require a defined agreement protocol and a mismatch policy. The DCU should encode the chosen architecture into evidence fields so that “why the voter decided” remains traceable.
- Lockstep focus: detect internal divergence and enforce immediate inhibit when divergence is confirmed.
- Independent focus: preserve channel IDs and timing offsets to distinguish transient EMI from persistent sensor faults.
Voting is a risk-bias decision. 1oo2 favors early action (reduces missed actions but may increase false stops). 2oo3 improves noise immunity (reduces false stops) but may add decision latency and requires a carefully bounded confirmation window. The window must be consistent with sensing latency/jitter; otherwise voting amplifies misalignment instead of improving safety.
- False action evidence: frequent short mismatches, high glitch counts, and window misalignment markers.
- Missed action evidence: excessive decision delay, late safe-stop, or inhibit not asserted under confirmed mismatch.
A robust DCU treats false actions and missed actions as different classes with different counters and remediation paths. False actions typically indicate noise injection, threshold instability, or windowing issues; missed actions indicate timing budget violations, voter policy gaps, or insufficient redundancy coverage.
voter_mode, mismatch_ms, window_id, inhibit_reason, and safe_state.
Without these, field audits cannot distinguish noise events from true faults.
H2-8. Event Logging & Forensic Evidence
Voting decisions are defensible only if the evidence packet preserves inputs, window timing, and state transitions. Event logging must therefore capture pre/post-trigger windows, synchronized timestamps, waveform snippets, travel curves, counters, and integrity protection.
Evidence must include a pre-trigger ring buffer and a post-trigger capture segment. Without pre-trigger data, it is impossible to separate “the cause” (load rise, mismatch onset) from “the consequence” (driver stop transient, rebound). The DCU should commit a minimal packet first, then extend the capture if hold-up energy allows.
A monotonic counter provides ordering across resets and avoids ambiguous time regressions. If an external sync is available, it can be recorded as an additional field, but the evidence packet should remain valid even with only a local monotonic time base. Time quality should be tagged to prevent disputed timelines.
Current waveform snippets describe force/torque dynamics; travel curves describe motion outcome. The pair distinguishes true obstructions from supply artifacts, control oscillations, and backdrive conditions. Both should be captured using the same event window IDs to align analysis.
Monotonic counters provide trend-level evidence (brownout count, mismatch count, reopen count, drive fault count). These counters help identify gradual degradation and separate intermittent EMI from persistent component failure.
Evidence packets should include an integrity marker (hash/CRC) and a signature/MAC over the packet to prevent silent modification. The design should also detect incomplete commits after brownout (missing “commit complete” flag) and preserve the partial packet as a distinct record.
H2-9. EMC & Noise Immunity (EN 50121)
EMC robustness for a rail door control unit is primarily a return-path problem. Motor switching creates common-mode (CM) currents that couple into long harnesses and shift sensor reference points, causing voting mismatches and false pinch triggers unless CM paths are controlled and isolated boundaries are explicit.
PWM edges and switching nodes generate steep dv/dt that drives common-mode current through parasitic capacitances (bridge-to-chassis, motor-to-frame, cable-to-chassis). The result is a short CM pulse that seeks a return path. The DCU must treat these pulses as deterministic events and prevent them from sharing reference with sensor AFEs and digital inputs.
- Field symptom: glitches correlate with PWM edges or specific duty-cycle ranges.
- Evidence hook: correlate
mismatch_cnt/pinch_scorespikes withpwm_stateor window IDs.
Door harnesses are long and mechanically routed; they easily behave as antennas and pick up CM energy. Practical immunity comes from minimizing loop area, defining shield bonding points, and keeping sensor reference lines away from motor switching returns. EMC improvements should be validated by changes in event statistics (not only waveform aesthetics).
- Minimum checks: shield termination strategy, chassis bonding continuity, and separation between motor and sensor wiring.
- Expected evidence change: reduced short-duration mismatches and fewer “suspicious → confirmed” transitions under identical motion cycles.
Common-mode current flowing through unintended paths can lift or modulate the sensor reference. When the reference moves, a stable physical signal may appear shifted, compressing threshold margin and triggering false voting mismatches or pinch events. Robust designs isolate sensitive domains and define a clean reference boundary for AFEs and decision logic.
- Mismatch pattern: brief, repeatable spikes at edge transitions rather than sustained divergence.
- First fix direction: correct return paths and reference boundaries before changing thresholds.
Common-mode chokes are effective only when placed to intercept the dominant CM path. Placement near the harness exit can reduce radiated/received CM energy; placement near sensitive receiver boundaries can protect AFEs and digital inputs. The design intent should specify which boundary the CMC protects and which current it is expected to block.
- Boundary rule: place CMCs where CM current would otherwise flow through sensitive reference points or into long external harnesses.
- Verification hint: compare event counters and mismatch distributions before/after placement changes.
Isolation and isolated transceivers do not “make signals cleaner” by themselves; they prevent common-mode currents from sharing a reference. This preserves logic thresholds and reduces false transitions. Isolation boundaries should be shown in the architecture and reflected in evidence fields.
H2-10. Compliance Mapping (EN 50155 / EN 61373)
Compliance becomes actionable when each standard requirement maps to a concrete design action, a verification test, and a minimal set of evidence fields. This matrix approach links lab qualification and field forensics with the same vocabulary.
Each row defines a single intent (for example “brownout safe-stop with atomic evidence commit”). The intent is verified by a specific test condition and backed by a compact set of log fields. Evidence fields should remain stable across firmware revisions to preserve audit comparability.
H2-11. Validation & Field Debug Playbook
A rail Door Control Unit should ship with a repeatable debug playbook: reproduce → capture → decide → tune → re-test. Each test type must define (1) waveforms to probe, (2) log fields to export, and (3) the first tuning knobs to turn.
The goal is to distinguish a true obstruction from control artifacts by applying controlled resistance at multiple travel segments (start / mid / near-close). The playbook should force the same “physics” repeatedly, then compare the evidence packet shapes (current snippet + travel segment + decision timing).
- Probe waveforms: motor current (fast + filtered), position/travel, PWM/drive state, inhibit/enable.
- Log fields:
window_id,pinch_score,decision_delay_ms,inhibit_reason,safe_state,travel_time_ms. - First knobs: detection window length/alignment, score threshold (not raw peak current), per-segment baseline envelope.
Immunity validation must reproduce the field symptom class: short mismatches and false triggers correlated with switching edges and harness coupling. The objective is to prove that reference boundaries and input confirmation logic prevent “glitch → confirmed safe-stop” escalation.
- Probe waveforms: sensor baseline/reference proxy, digital input edge (redundant position/I/O), motor current snippet, PWM edges.
- Log fields:
glitch_cnt,mismatch_cnt,mismatch_ms,voter_mode,window_id,pwm_state. - First knobs: debounce/confirm window, fast-path vs trusted-path separation, input qualification thresholds.
Brownout validation proves two things: motion enters the defined safe-stop policy, and evidence packets are committed atomically
(either commit_ok or a clearly tagged incomplete record). Test profiles should include dips during motion and during evidence commit.
- Probe waveforms: input rail, MCU rail/reset, drive enable, storage/commit indicator (if available).
- Log fields:
brownout_count,reboot_reason,last_state,commit_ok,event_seq,packet_crc. - First knobs: safe-stop entry policy, log priority (header first), holdup budget split (sampling vs write time).
Aging validation should rely on statistics and feature summaries, not continuous raw waveforms. The playbook should track distributions across temperature bands and travel segments, then decide if drift is slow/consistent (model update) or bursty/random (EMI/noise).
- Probe waveforms (sparse): periodic current snippet + travel segment every N cycles; feature summary every cycle.
- Log fields:
false_stop_cnt,missed_stop_cnt,baseline_seg,temp_band,torque_margin_p95. - First knobs: baseline update rate, segment thresholds, temperature binning strategy.
The following part numbers are commonly used to implement “capture + isolate + timestamp + seal evidence” in a DCU (examples, not a mandate):
- Isolated current / ΣΔ sensing: TI
AMC1306, TIAMC1311, ADIAD7401A. - Digital isolation: ADI
ADuM141E, TIISO7741, Silicon LabsSi8642. - Isolated CAN/RS-485: TI
ISO1042(isolated CAN), ADIADM2587E(isolated RS-485). - Supervisor / watchdog: TI
TPS3839, Analog Devices (Maxim)MAX6369. - Secure element / keys: Microchip
ATECC608B. - Nonvolatile evidence: Infineon/Cypress
FM25V02A(FRAM), FujitsuMB85RS64V(FRAM), WinbondW25Q128JV(SPI NOR). - RTC / monotonic time: Micro Crystal
RV-3028-C7. - Vibration capture (for EN 61373 campaigns): ADI
ADXL355. - Protection examples: Littelfuse
SMBJ58A(TVS), Würth Elektronik744232091(CMC).
H2-12. Field Feedback & Threshold Update Loop
A DCU should not behave as a fixed-threshold device. It is a dynamic model system: baselines, segment thresholds, temperature compensation, and false-trigger statistics must feed a controlled update loop without losing auditability.
Updates should target a small set of parameters that directly control safety decisions: (1) segment baselines, (2) pinch/torque score thresholds, and (3) debounce/confirmation windows. Evidence field names and packet formats should remain stable across versions to preserve forensic comparability.
- Version tags:
baseline_v,threshold_v,fw_version,rollout_group. - Safety invariants: safe-stop entry rules and “commit order” must not regress under updates.
Aging is validated through trends (not single events). Only slow, consistent drift should update the baseline envelope. Bursty deviations should be classified as noise/EMI until proven otherwise by repeated evidence packets and controlled reproduction tests.
The loop should publish a compact metrics set: false_stop_per_1000, missed_stop_per_1000,
and mismatch_to_safestop_ratio. These metrics decide whether the first knob is windowing, debounce,
threshold, or reference/EMC mitigation.
Updates should be staged (small group → wider group) with explicit rollback triggers based on the same evidence fields. Rollback is a safety feature: a model update is not “complete” until its improvement is proven by metrics and evidence integrity rates.
Closed-loop updates rely on trustworthy time, storage, and integrity primitives. Typical parts used for these roles include:
- Secure identity / signing: Microchip
ATECC608Bfor keys and evidence sealing. - Durable NVM: Infineon/Cypress
FM25V02Aor FujitsuMB85RS64V(FRAM) for high-cycle counters and evidence headers. - Firmware/image store: Winbond
W25Q128JV(SPI NOR) for staged images / rollback slots. - Time base: Micro Crystal
RV-3028-C7for stable RTC tagging; supplement with monotonic counters in firmware. - Watchdog supervision: TI
TPS3839or MaximMAX6369to guarantee controlled recovery and consistent reboot reasons.
fw_version and the active parameter versions (baseline_v, threshold_v).
Otherwise field metrics cannot be trusted for before/after comparisons.
H2-13. FAQs (Door Control Unit)
Each answer is evidence-first: 1 conclusion + 2 checks + 1 first fix + chapter backlinks.
Scope: DCU local motor drive, pinch/torque sensing, redundancy/voting, power brownout behavior, event evidence, and EMC immunity (no TCMS/PSD/traction topics).
Door reopens unexpectedly — torque spike or noise injection?
Conclusion: If the reopen aligns with PWM edge activity and brief input glitches, noise injection is more likely than a real torque spike.
Evidence check #1: Correlate
window_idandmismatch_mspeaks withpwm_statetransitions.Evidence check #2: Compare the current snippet shape to the expected segment baseline (isolated sensing examples:
AMC1306,AD7401A).First fix: Increase input qualification/debounce before changing thresholds, then validate CM path controls (CMC example: Würth
744232091).
Logs show no fault but the door stops — brownout or watchdog?
Conclusion: If motion stops with a reboot or reset signature and incomplete evidence commits, brownout/watchdog behavior is the primary suspect.
Evidence check #1: Inspect
reboot_reasonandbrownout_count; verify supervisor behavior (examples: TITPS3839, MaximMAX6369).Evidence check #2: Confirm
commit_ok/packet_crccontinuity andevent_seqmonotonicity (FRAM examples:FM25V02A,MB85RS64V).First fix: Prioritize “header-first” logging and safe-stop entry on undervoltage, then re-run the power-dip script.
Pinch detection is too sensitive — offset drift or threshold window?
Conclusion: If false pinch triggers cluster by temperature band and baseline drift, offset drift is more likely than a purely “too-low threshold.”
Evidence check #1: Compare
pinch_scoredistribution acrosstemp_bandand travel segments; review offset/noise budget (sensing examples:AMC1311,AD7401A).Evidence check #2: Check whether triggers occur at the same
window_idwith similar current waveform shape (repeatability indicates modeling).First fix: Adjust window alignment and per-segment baseline before lowering the main threshold; roll out via staged groups with rollback flags.
Only fails in winter — lubricant drag or current model mismatch?
Conclusion: If travel time increases and current rises smoothly without glitch signatures, mechanical drag is more likely than EMI or voting artifacts.
Evidence check #1: Track
travel_time_msand segment baseline current trends across coldtemp_bandbins.Evidence check #2: Confirm low
glitch_cnt/mismatch_cntduring failures (indicates physics rather than injection).First fix: Update per-segment baseline envelope and torque margin model, then validate under mechanical resistance simulation.
EMC lab test passes, but field glitches persist — wiring reference issue?
Conclusion: If glitches vary by vehicle/harness routing and correlate with CM stress, wiring reference and return-path control are the top suspects.
Evidence check #1: Compare
glitch_cntandmismatch_msacross installations under the same firmware build.Evidence check #2: Verify isolation boundary stability and transceiver robustness (examples: TI
ISO1042, ADIADM2587E; digital isolation:ADuM141E).First fix: Re-anchor shield bonding and CMC placement near harness exit (example CMC:
744232091), then re-run EMI stress with the same playbook.
Redundant inputs disagree — sensor drift or voting window configuration?
Conclusion: Short, edge-correlated disagreements usually indicate voting window/debounce issues, while slow divergence indicates sensor drift.
Evidence check #1: Inspect
mismatch_mshistogram: narrow spikes imply noise/windowing; long spans imply drift.Evidence check #2: Compare channel baselines and offsets using consistent AFE capture (isolated sensing examples:
AMC1306/AD7401A).First fix: Adjust the Suspicious→Confirmed timing window before changing thresholds; validate by EMI injection and mechanical resistance scripts.
Door chatters near end-of-travel — control loop ringing or obstruction scoring?
Conclusion: If current oscillates with a repeatable period and no external glitch signature, loop ringing/settling is more likely than obstruction.
Evidence check #1: Compare current waveform periodicity versus position slope around the same travel segment.
Evidence check #2: Confirm low
glitch_cntand stablevoter_modeduring chatter events.First fix: Increase soft-stop/settling time and align the detection window to avoid transient scoring, then re-validate with the mechanical resistance script.
Evidence packets exist, but waveforms are missing — storage budget or commit order?
Conclusion: If headers are present but waveform payloads are missing, commit order and holdup budget are more likely than sensing failure.
Evidence check #1: Verify
commit_okand a validpacket_crc; check whether the payload length field is truncated.Evidence check #2: Correlate missing payloads with
brownout_countorreboot_reasontransitions.First fix: Make “header + key counters” atomic first, then append waveforms opportunistically; use high-cycle NVM for headers (FRAM:
FM25V02A).
Door stops after maintenance — wiring disturbance or reset policy too strict?
Conclusion: If failures start immediately after harness/service work, disturbed references and reset/safety policy thresholds are more likely than true mechanical wear.
Evidence check #1: Look for increased
glitch_cnt/mismatch_cntafter a known service timestamp.Evidence check #2: Confirm reset signatures via supervisor/watchdog logs (examples:
TPS3839,MAX6369) and verify consistentreboot_reason.First fix: Re-qualify inputs (debounce) and re-check shield bonding/CMC placement; only then relax reset policy windows.
A firmware update changes “feel” — baseline versioning or hidden threshold drift?
Conclusion: If behavior shifts right after an update with stable mechanics, baseline/threshold version mismatch is more likely than a real torque change.
Evidence check #1: Verify that every packet contains
fw_version,baseline_v, andthreshold_v.Evidence check #2: Compare false-stop metrics before/after in the same
rollout_group; check rollback eligibility.First fix: Enforce staged rollout with rollback triggers; store images for rollback (SPI NOR example: Winbond
W25Q128JV) and seal configs (secure element:ATECC608B).
Intermittent failures have identical timestamps — time base drift or logging sync problem?
Conclusion: If repeated events share suspiciously similar timestamps, the time base or commit marker is more likely wrong than the door physics.
Evidence check #1: Validate monotonic counters (
event_seq) against timestamps; detect wrap or resets.Evidence check #2: Confirm RTC health and reset behavior (RTC example: Micro Crystal
RV-3028-C7) and thatreboot_reasonis consistent.First fix: Use monotonic counters as the primary ordering key, then restore timestamp integrity; re-run the brownout script to ensure time does not regress.
Protection looks strong, but field resets persist — TVS placement or supervisor thresholds?
Conclusion: If resets persist despite protection parts, placement and thresholds are usually the issue, not the absence of a TVS or supervisor.
Evidence check #1: Correlate reset events with input dips and
brownout_count; verify supervisor threshold configuration (examples:TPS3839,MAX6369).Evidence check #2: Check whether glitches coincide with harness entry events; review protection placement (TVS example: Littelfuse
SMBJ58A).First fix: Move protection closer to the harness entry and tighten the evidence commit policy so “reset without record” cannot occur.