System Scope & Boundary

The Driver Desk & HMI page defines the operator-facing I/O endpoint that turns train states into actionable displays and turns human inputs into bounded, auditable commands. The goal is not “UI beauty”; it is deterministic interaction, evidence-grade event records, and predictable safe behavior under rail power and EMC stress.

• Input acquisition: touch, rotary encoder, hard keys, emergency/safety-related inputs (HMI-side), with debouncing and fault detection.
• Output presentation: display link + backlight control, annunciation (lamps/buzzer), and “freshness” of shown data (stale vs valid).
• Connectivity edge: Ethernet/serial (RS-485/CAN/other) as the HMI’s boundary to TCMS/vehicle networks, including link supervision and watchdog behavior.
• Evidence entry-point: event IDs, timestamps, operator action traces, power-state context, and version context sufficient for post-incident reconstruction.
• Rail constraints: wide input rails and transients, temperature class expectations (e.g., EN 50155), vibration/connector robustness, HMI-side EMC survivability.

• Traction control algorithms (FOC/SVPWM/torque loops) and traction inverter power-stage design. These belong to Traction Inverter / TCMS control pages.
• Core network switching design (TSN scheduling policy, full-train ECN topology). This belongs to Train Backbone Ethernet/ECN/WTB/MVB Gateway pages.
• CBTC/ETCS business logic, interlocking/vital logic, and signaling protocol semantics. These belong to signaling/safety pages.

• Power domain: typical 24/48/110 Vdc vehicle supplies; define brownout/holdup expectations for display continuity and log commit.
• Environment: temperature class target (e.g., EN 50155 TX) and vibration/shock expectations (e.g., EN 61373) that drive connector and mounting choices.
• Interfaces: TCMS/vehicle network (Ethernet/serial), safety-related inputs (if any), and event recorder/log collector interface (local or remote).

Operational Intent & Failure Narrative

Rail HMI failures are rarely “UI bugs” in isolation. Most incidents are the result of a stress condition (transients, EMC, temperature, vibration) interacting with a missing evidence field or an undefined safe behavior. This chapter converts symptom-style questions into an evidence-first diagnostic structure that the rest of the page will consistently reference.

• Black screen / flicker while the system appears “alive”.
• Touch mis-trigger / drift (especially after ESD or in wet/glove operation).
• Encoder jitter (jumps, double-steps, direction reversals).
• Audio echo / hum / noise during PA/intercom actions.
• Network drop (Ethernet link flaps, serial timeouts).
• Timestamp mismatch across subsystems (events cannot be aligned).
• Slow response (button latency, screen update lag).
• Missing logs after reboot or during transient disturbances.

• Normal operation: baseline latency, display refresh, input accuracy, and log completeness.
• EMC stress: ESD/EFT/surge exposure; focus on false inputs, link flaps, and recovery behavior.
• Power disturbance: brownout/holdup windows; focus on “what stays on”, “what resets”, and “what is committed”.
• Extreme temperature: drift, backlight derating, touch controller baseline stability, and boot-time impact.

Hardware Architecture Decomposition

The Driver Desk & HMI is best treated as six cooperating hardware blocks. Each block must publish a clear interface contract, declare its isolation boundary, meet a timing budget, and expose a minimum set of observable health fields (counters/flags/latency) so incidents can be diagnosed without guesswork.

• Interfaces: what enters/leaves (signals, data, power rails, and who owns the contract).
• Isolation boundary: where common-mode suppression / isolation is applied (HMI-side only).
• Timing budget: input → process → display/command, including jitter and freshness thresholds.
• Fault observability: minimum counters/flags to localize the fault domain without ambiguity.

Power Architecture & Brownout Behavior

In rail environments, HMI availability is constrained by inrush, short supply dips, cold-start latency, and reset storms. The design objective is not to “never reset”, but to guarantee a predictable degraded mode and an evidence-grade shutdown sequence when voltage crosses defined thresholds.

• Start-up surge: inrush and backlight/amp load steps can sag the rail and trigger protection or brownout.
• Transient dips: short drops can corrupt storage commits or desynchronize timestamps if policy is undefined.
• Cold-start delay: boot chain latency changes with temperature; “UI ready” must be measurable and bounded.
• Repeated resets: mismatched UV thresholds + watchdog policy can create reset loops that hide root causes.

• Wide-VIN front-end: define measurement points for rail monitoring and set explicit brownout thresholds.
• eFuse / hot-swap: protection actions must be readable as telemetry (fault codes, retry counts, latch state).
• Holdup budgeting: allocate a minimum window to keep the UI in “minimum mode” and to finish log commits.
• Brownout policy: map voltage thresholds to actions: freeze commands → seal evidence → safe off.

Touch & Encoder Interfaces

Input reliability in rail HMI is a measurable engineering problem: it must remain trustworthy under long harnesses, vibration, temperature drift, and EMC exposure. The design target is not only “responsive inputs”, but also evidence-based separation between false triggers and missed triggers, backed by counters, snapshots, and reject-reason codes.

• Mode declaration: the HMI must expose which profile is active (normal / glove / wet) so incidents can be reconstructed.
• Trade-offs: increasing sensitivity can raise false-trigger probability; reducing sensitivity can raise missed-trigger probability.
• Minimum evidence fields: touch_mode, threshold_profile_id, touch_latency_ms, ghost_touch_cnt, baseline_reset_cnt.

• Common-mode path: long cables and shield reference shifts can inject into the sensor reference. Cut-point: HMI-side CM suppression and stable reference plane definition.
• Electrode coupling: large sensor electrodes amplify parasitics under ESD/EFT. Cut-point: controlled recovery path and baseline discipline.
• Supply injection: rail ripple can modulate measurements. Cut-point: sensor rail filtering and “snapshot on event” observability.

• Edge density: abnormal A/B edge burst rate is a primary discriminator between mechanical bounce and injected noise.
• Direction reversals: reverse_step_cnt highlights jitter and EMI-induced phase errors.
• Reject accounting: debounce_reject_cnt must increase when steps are discarded; this prevents “silent misses”.

• Dual confirmation pattern: require two independent input channels for critical HMI actions (e.g., touch + physical confirm), focusing on channel independence.
• Safety button channel: safety-related hard path should remain hardware-based; the HMI records press/release duration and debounce outcomes without implementing safety logic.
• Minimum evidence fields: safety_btn_state, press_duration_ms, reject_reason, event_id, timestamp_source.

Display & Backlight Subsystem

In rail HMIs, “display” is a system: rendering, link timing, panel behavior, backlight power, and recovery policy. Failures must be diagnosable by layer (render vs link vs panel vs backlight), and the design must support visual evidence capture through brightness trends and backlight modulation characteristics.

• Link stability: treat link_lock and retrain_cnt as first-class health signals (separate “panel alive” from “backlight alive”).
• Harness & vibration sensitivity: connector intermittency appears as burst errors and retraining events; keep counters and timestamps.
• Minimum observability: link_lock, link_err_cnt, retrain_cnt, ui_fps, frame_drop_cnt, panel_temp.

• Type A — PWM too low: flicker correlates with low pwm_freq and duty extremes; evidence: pwm_freq_hz + duty vs brightness steps.
• Type B — beat with refresh/bit-depth: flicker correlates with frame timing changes; evidence: ui_fps/frame_drop + flicker reports vs render load.
• Type C — rail ripple into LED current: flicker correlates with backlight rail ripple; evidence: bl_current ripple + supply ripple under load steps.

• Noise source region: backlight switching edges can radiate via harness; isolate and bound the switching region, and measure outcomes via link and input counters.
• Frequency selection: avoid sensitive bands (audio coupling, system sampling interactions); keep the selected pwm_freq and profile ID as evidence.

• Derating state: expose brightness_derate_state and panel_temp, and define a minimum readability mode for alarm-critical UI.
• Cold-start impact: track ui_ready_ms and link_lock time to detect temperature-dependent boot regressions.

Audio/Video & Codec Chain

Cab audio/video issues are rarely “one component failures”. In rail HMIs, audible noise, echo, burst dropouts, and sudden level changes are often caused by coupling across analog, digital, power, and ground/common-mode domains. The chain must provide enough observability to distinguish DSP-state problems from power/ground coupling without trial-and-error replacements.

• Load coupling: video workloads can steal memory bandwidth and raise UI/audio dropouts; evidence via decoder_load, ui_fps, frame_drop_cnt, thermal_state.
• Priority discipline: alarm-critical UI and audio prompts should remain measurable under video stress (report latency and drop counters).

• Power coupling: rail ripple or load-step markers correlate with noise_floor or bursts → prioritize power-domain mitigation and snapshots.
• Ground loop / common-mode: noise changes with external connections or shield reference → prioritize CM evidence and interface boundary checks.
• Digital injection: tones correlate with PWM/PHY activity (fundamental or harmonics) → prioritize frequency profile evidence and isolation boundaries.

Networking & Time Synchronization

Networking is not only connectivity. For rail HMIs, time synchronization is the foundation of evidence: it enables cross-system log alignment between HMI events, vehicle control logs, and external recorders. The design must export a time-quality tag (source, offset, holdover, step events) so timestamps remain trustworthy during link loss and recovery.

• Ethernet / TSN: expose link_up_time, link_flap_cnt, crc_err_cnt, and a freshness policy (stale threshold) for displayed state.
• RS-485 / CAN: expose timeout_cnt, retry_cnt, and bus_off_cnt (CAN) to prevent silent data loss.
• Watchdog PHY: use PHY watchdog or controlled resets to recover from stuck link states; record reset count and last reason.
• Isolation boundary: isolate network interfaces and treat CM suppression as part of reliability evidence (isolation_fault_flag, cm_event_cnt).

• Alignment key: use event_id + sequence to correlate across devices; timestamp alone is not enough when steps occur.
• Time quality tag: every event should include timestamp_source, offset class, holdover_state, and time_step markers.
• Conflict handling: when time_step is detected, seal an event and mark the affected window as reduced-quality for forensic reconstruction.

Safety, Redundancy & Fail-safe States

For rail HMIs, safety is defined by controllability and provability: the interface must enter predictable restricted states when its trust is degraded, while maintaining minimum critical visibility and evidence continuity. This section focuses on HMI-internal redundancy, watchdog discipline, and fail-safe UI behavior (not vehicle safety logic).

• UI domain: graphics, touch, audio/video, networking; high load and non-deterministic by nature.
• Monitor domain: low-load supervision for heartbeats, time quality, logging triggers, and controlled resets.
• Observed safety inputs: record/present only (e.g., dual-channel states); do not implement vehicle-level voting outcomes.
• Minimum evidence: heartbeat_miss_cnt, cross_check_mismatch_cnt, monitor_reset_cnt, safe_state_latched_flag.

• Windowed watchdog: detects both “no kick” and “bad kick” patterns; record wdt_trip_cnt and last_reset_reason.
• Independent monitor reset: enables recovery even when the UI domain stalls; record monitor_initiated_reset_cnt.
• Reset continuity: reboot must preserve boot_counter, last_good_seq, last_log_commit_ts to maintain forensic continuity.

• Degraded UI: load-shedding (video off, reduced effects) while keeping critical status readable and logging active.
• Fail-safe UI: restricted navigation and inputs; allow only alarm acknowledgement and limited confirmations.
• Emergency mode limits: block configuration, updates, and deep menus; expose read-only status + exportable error codes.
• Required fields: safe_state_enter_reason, safe_state_current, ui_ready_ms, time_quality_degraded_flag.

Event Logging & Forensics

Event logging for rail HMIs must be designed as a forensic evidence packet: a bounded pre/post window, aligned timestamps with quality tags, and integrity protection. A record without time quality is not reconstruction-grade and cannot support consistent cross-system timelines.

• Pre-trigger ring buffer: always-on rolling cache of key fields for a configurable time/event window.
• Trigger freeze: a defined condition seals the start boundary (fault, threshold, operator action, time-step event).
• Post-trigger tail: extend until system stabilizes or a fixed tail window is reached; record closure reason.

• Dual time basis: monotonic_time for local ordering + wall_time for cross-device alignment.
• Time quality tag: timestamp_source, offset class, holdover_state, and time_step markers on every critical event.
• Quality transitions: time_quality_change events must be logged; affected windows are tagged as reduced-quality.

• Signature: proves integrity (packet header + content hash). Store key_id and signature status for auditability.
• Encryption: protects sensitive traces; record encrypt_flag and policy profile without exposing secrets.

EMC & Rail Compliance Mapping

Rail HMI must comply with multiple standards such as EN 50155 (temperature and voltage), EN 50121 (EMC), and 61373 (vibration). This section maps these standards to design actions, test evidence, and the necessary log fields for compliance.

• Design action: Implement thermal derating strategies and define measurement points for critical thermal points.
• Test evidence: Thermal chamber curves, testing at critical voltage and transient drop conditions.
• Log fields: thermal_state, derate_level, ui_fps, decoder_load, vin_min, brownout_flag.

• Design action: Ensure proper shielding and isolation at input and output connections. Implement common-mode suppression strategies.
• Test evidence: Rail ripple measurements, EMC testing under operational conditions.
• Log fields: rail_ripple_mV, cm_event_cnt, noise_floor, touch_reset_cnt.

• Design action: Secure connectors and fixings; ensure resilience against vibration-induced intermittent failures.
• Test evidence: Vibration testing and monitoring during operational conditions.
• Log fields: link_flap_cnt, crc_err_cnt, log_commit_fail, input_reject_reason.

• Design action: Implement effective ESD suppression strategies, with special attention to touchscreen recovery.
• Test evidence: Measurement of ESD event counts, recovery times for touchscreens.
• Log fields: esd_event_cnt, touch_ctrl_reset_cnt, touch_lockout_ms.

Validation & Field Debug Playbook

The Validation and Debug Playbook defines how to approach testing, from initial boot verification to network consistency. It ensures that evidence is captured before, during, and after each test phase, including essential waveforms, logged fields, and recovery actions.