Message classes to standardize

• Commands: actionable requests with explicit preconditions (mode/state) and an enforced validity window.
• Status: measured state that must carry timestamp and quality context to be comparable across domains.
• Authority / limits: what is allowed, under which mode, and for how long; includes explicit revocation and inhibit conditions.
• Fault / degrade: signals that instruct conservative behavior and provide a pointer to evidence (reason codes / packet IDs).

Critical fields that make messages provable

Receiver acceptance gates (must be logged)

• Integrity gate: CRC/MAC must validate; failures produce accept_reject_reason.
• Freshness gate: sequence and age must be within window; replays/duplicates are rejected and counted.
• Context gate: mode/state prerequisites must match; partial transitions are treated as unsafe.

The black-channel principle applies: intermediate transport is treated as untrusted; end-to-end telegram fields implement identity, order, freshness, and integrity without assuming trusted switches or gateways.

Serial (RS-485 / RS-422 / UART)

• Strength: shorter stacks and simpler scheduling make determinism easier to budget; differential links are straightforward to isolate and harden.
• Risk: bandwidth and multi-drop topology can create arbitration delays and ambiguous fault attribution without robust counters and line diagnostics.
• Evidence to collect: frame_err_cnt, timeout_cnt, line_fault_flags, retransmit_cnt.

Ethernet (optionally TSN)

• Strength: bandwidth and tooling for diagnostics; scalable integration across train backbone domains.
• Work required: determinism depends on queue discipline and shaping; auditability depends on accurate timestamping and per-hop counters.
• EMC emphasis: common-mode control, shielding termination, and surge/ESD strategy become part of interface design, not wiring afterthought.

Safety / legacy buses (coexistence with backbone)

• Value: established determinism and certification pathways; predictable timing behavior in constrained topologies.
• Constraint: bandwidth and extensibility; coexistence with Ethernet backbone requires consistent semantics, time alignment, and evidence field parity.
• Scope rule: implementation details of gateways are out of scope; only interface obligations (fields, timing proof, audit logs) are defined here.

Selection criteria (inputs that must be stated)

• Distance & environment: cable length, routing near high dv/dt sources, and expected surge/ESD exposure.
• Topology: point-to-point vs multi-drop vs switched network; fault isolation requirements.
• Bandwidth & cycles: telegram size, update rates, and peak congestion scenarios.
• Determinism target: maximum latency and jitter envelope; acceptable loss behavior.
• Certification cost: complexity budget for proving timing and safety behaviors.

Hardware vs software timestamping (impact on jitter and proof)

• Software timestamps are sensitive to CPU scheduling, interrupt latency, and driver queues, increasing worst-case jitter under load.
• Hardware timestamps anchor time closer to the MAC/PHY boundary, reducing variance and improving incident-level traceability.
• For auditability, the timestamp must be paired with time-quality and sync state so ordering claims remain defensible.

Clock architecture (GM, endpoints, redundancy, holdover)

• Grandmaster (GM): primary time source; redundancy planning covers GM switchovers and path changes.
• Distribution: switches and links form a timing chain; endpoints must observe state transitions and record timing evidence.
• Endpoint discipline: each endpoint tracks lock/holdover and exposes local timing health for interface decision making.
• Holdover (OCXO/TCXO): when GM lock is lost, the local oscillator maintains time with increasing uncertainty until degraded.

Minimum time evidence fields (required for audit reconstruction)

Time evidence is considered complete only when it explains what time was used, how good it was, and how it changed during faults.

A/B redundancy and consistency decisions

• Channel identity: every telegram is tagged with channel_id and compared against the peer channel.
• Time alignment: acceptance requires arrival skew within a defined window derived from the jitter envelope.
• Sequence alignment: sequence deltas and gaps are tracked; duplicates and replays are rejected and counted.
• Context alignment: mode/state prerequisites must match across channels; mismatches produce explicit reject reasons.

Heartbeat and timeout window design

• Heartbeat period defines the minimum observability cadence for link health and protocol liveness.
• Timeout window must cover worst-case latency + worst-case jitter + processing margin to avoid EMC-driven false trips.
• Loss tolerance (N-of-M) trades false alarms against delayed fault detection; the choice must be justified by logged jitter and drop statistics.
• Safe-state action must be explicit: revoke authority, inhibit mode, and record the trigger path.

Watchdogs (three categories, each with evidence and action)

• Link watchdog: monitors timeouts, link drops, and error bursts; logs timeout_cnt, reconnect_cnt, frame_err_cnt.
• Protocol watchdog: monitors invalid transitions, sequence anomalies, and window violations; logs seq_gap_cnt, replay_cnt, reject_reason.
• Time watchdog: monitors sync loss, holdover aging, and offset thresholds; logs sync_state, time_quality, offset_ns.

Interface-level voter handshake fields (no internal voter logic)

• Inputs provided to voter: channel consistency result, accept/reject reason, and time-quality state.
• Outputs exposed by voter: voted decision flag and voted health state for audit correlation.
• Minimum fields: voter_state, voter_mismatch_cnt, voter_decision, voter_reason, time_quality

Identity model (three layers that remain auditable)

• Root identity: hardware root-of-trust anchor used to validate boot and protect long-term secrets.
• Device identity: certificate or device credential tied to device_id and managed across the fleet lifecycle.
• Session identity: short-lived keys bound to channels and validity windows; enables rotation without replacing device identity.

Lifecycle and revocation (minimum evidence fields)

Identity is incomplete without lifecycle evidence. Provisioning, renewal, and revocation must be traceable at interface level.

Where the HSM/SE sits (boundary and responsibility)

• Endpoint HSM/SE: stores long-term private keys; produces signatures/MACs; protects secure boot and update validation.
• Gateway HSM/SE: manages multi-endpoint sessions and policy boundaries; logs session issuance and rotation events.
• Switch side: may enforce link-layer security options, but is not assumed to be a root-of-trust for end-to-end integrity.

Communication protection (options matrix, no protocol deep-dive)

Selection is driven by the threat model and certification cost. Regardless of option, interface logs must preserve which protection was active and which key version was in use.

Secure firmware & configuration updates (version chain + rollback)

• Version chain: update events are immutable records that bind fw_version and cfg_version to signed artifacts.
• Rollback control: rollback is either prevented or tightly audited with counters and reasons to avoid downgrade attacks.
• Audit fields: update_event_id, signature_ok, install_ts, rollback_cnt, rollback_reason, active_slot

Isolation placement (PHY-side vs logic-side)

• PHY-side isolation: reduces common-mode injection into the digital core; emphasizes transceiver and line-side survivability.
• Logic-side isolation: protects MCU/SoC domains; requires careful handling of remaining common-mode paths via power and chassis.
• Design rule: isolation is a means to break current return loops, not a cosmetic partition in the schematic.

Common-mode control (Do / Don’t)

Surge/ESD/EFT hardening (clamp loop dominates outcomes)

• Clamp proximity: TVS must sit near the connector so surge current diverts before entering sensitive routing.
• Loop length: effectiveness depends on the physical loop (connector → TVS → chassis return), not only the TVS part number.
• CMC placement: common-mode chokes shape the return current distribution; placement should preserve a clean chassis diversion path.
• Isolation coordination: keep high-energy transients on the line side; avoid coupling across isolation via parasitic capacitance.

Diagnostics (signals that reveal common-mode induced failures)

Without diagnostics, common-mode events appear only as timeouts. The interface should expose counters and state flags that distinguish line noise from protocol faults.

Latency budget (end-to-end decomposition)

End-to-end latency is the sum of segments that can be measured and bounded:

• Endpoint Tx: application/protocol queueing + packetization + NIC egress scheduling.
• Switch hop: ingress queueing + scheduling + forwarding + egress queueing.
• Link: propagation delay driven by physical media length and speed.
• Endpoint Rx: NIC reception + driver/ISR latency + protocol handling + application consumption.

Budgets must target worst-case behavior (upper bounds), not averages. When the budget is exceeded, the system must explain which segment caused the overrun.

Dominant jitter sources (three root-cause classes)

• Queue-induced jitter: contention with background traffic inflates queue delay and increases arrival spread.
• Timestamp/measurement jitter: software timestamping and interrupt latency distort observed timing, masking true link stability.
• Endpoint processing jitter: CPU preemption and driver queues increase Rx/Tx handling variance even when the network path is stable.

TSN-style determinism (conceptual mechanisms)

• Priority & traffic classes: protect control/safety telegrams from bulk traffic by enforcing class-based queue discipline.
• Time-aware shaping: place critical traffic into predictable transmission windows to reduce worst-case queueing.
• Control/data separation: isolate management, logging, and multimedia flows so congestion does not starve critical paths.

The purpose is not “faster Ethernet”, but bounded delay with accountability evidence when bounds are violated.

Minimum accountability evidence fields

Evidentiary logging (four mandatory properties)

• Tamper-evident: edits, deletions, and insertions are detectable via proof metadata.
• Time-qualified: each event carries time_quality and sync_state context.
• Field-complete: enough fields exist to explain the decision chain (accept/reject reasons, watchdog states, counters).
• Power-loss safe: commits are transactional with explicit commit markers and loss-of-power events.

Evidence packet pipeline (trigger → window → snapshot → proof)

• Trigger: timeout, A/B mismatch, integrity failure, time degraded, or repeated link resets.
• Window: pre-trigger and post-trigger captures of key telegrams with seq, age, and integrity status.
• Snapshot: counter and state snapshots that explain congestion, noise, and safety decisions at that moment.
• Proof: a proof layer that binds the packet to an ordered log sequence and detects missing records.

Minimum evidence packet fields (interface-level)

Storage strategy (evidence outcomes, not file-system details)

• Transactional commit: a packet is either fully committed or flagged incomplete with a power-loss marker.
• Continuity proof: ordered sequence numbers and hash linkage reveal missing or deleted records.
• Minimal disclosure: configuration is referenced by version or hash, not by dumping sensitive parameters into logs.

Example MPNs for this interface stack (reference only)

The following part numbers are representative building blocks commonly used in deterministic networking, timing, secure identity, and hardened physical interfaces. They are examples to anchor design discussions and test planning.

A) Bring-up checklist (link + time lock + error injection)

B) EMC checklist (EFT / ESD / surge)

C) Security checklist (interface-level identity, keys, replay, rollback)

D) Field regression checklist (alignment, replayable evidence, staged rollout)

EP (Evidence Packet) indicates that the test must generate a structured event record with event_id, pre/post window, snapshot counters, log_seq, commit_ok so the scenario can be replayed and audited without relying on “best effort” raw logs.

PTP is “locked”, but event order still disagrees — missing hardware timestamps or wrong clock domain in logs?

Conclusion: “Locked” time is not automatically evidentiary; ordering errors usually come from mixed timestamp sources or mixed clock domains.
Evidence: (1) Compare timestamp_source (HW vs SW) and ensure every log uses a single clock domain. (2) Check time_quality/sync_state/offset around the disputed interval.
First fix: Force a single time-qualified logging rule: always log timestamp_source + time_quality and sort only within the same qualified domain. (H2-10, H2-5)

A/B redundant links look healthy, but timeouts false-trigger occasionally — window too tight or queue jitter?

Conclusion: Most false timeouts are threshold-vs-tail issues: the window is smaller than the real worst-case jitter budget.
Evidence: (1) Inspect p99/p999 e2e_latency vs the timeout window and look for tail spikes. (2) Correlate timeout moments with queue_delay/queue_depth/drop_cnt (and whether A/B spike together).
First fix: Re-align timeout to the latency budget ladder (reserve headroom), then tighten using evidence distributions. (H2-6, H2-9)

Serial link errors only during traction acceleration — common-mode return path or insufficient isolation CMTI?

Conclusion: Strong correlation to acceleration points to a physical disturbance: common-mode current routing or isolation stress during fast dv/dt events.
Evidence: (1) Align error bursts (crc_fail_cnt/frame_err_cnt) with the traction event timeline. (2) Check for concurrent signs like link_down_cnt, isolation fault flags, or repeated re-sync attempts.
First fix: Shorten and harden return/clamp paths, and enforce a clear shield/chassis termination rule before retesting. (H2-8, H2-4)

Ethernet latency spikes occasionally — shaping not taking effect or CPU preemption causing processing jitter?

Conclusion: First separate “network queue delay” from “endpoint handling jitter”; the fix depends on which side moves.
Evidence: (1) Compare per_hop_delay and queue stats around spikes. (2) Compare endpoint processing time indicators (Rx/Tx handling variance) during the same window.
First fix: Isolate critical telegram traffic from background flows, and add endpoint handling time into evidence fields to prevent misattribution. (H2-9, H2-2)

Adding TVS makes dropouts more frequent — clamp loop too long or shield termination increases common-mode?

Conclusion: TVS can worsen results if the clamp current loop is inductive/long, or if shield/chassis termination unintentionally amplifies common-mode return currents.
Evidence: (1) Determine whether failures are error-bursts first (crc_fail_cnt) or immediate link-down (phy_link_down_cnt). (2) Review clamp loop geometry and shield termination rule used for the affected cable run.
First fix: Make the clamp loop short/low-inductance and lock a single termination rule, then re-run the same EMC exposure. (H2-8)

Logs look “complete”, but an audit says evidence is insufficient — which fields or proof chain are missing?

Conclusion: Human-readable logs are not evidentiary without continuity proof and identity binding; audits typically fail on “cannot prove no deletion/alteration”.
Evidence: (1) Verify continuity with log_seq, missing_seq_cnt, and explicit gap reasons. (2) Verify proof metadata exists: prev_hash/record_hash/signature_id/commit_ok.
First fix: Add a minimal proof layer (sequence + hash linkage + commit markers) and require it for every evidence packet. (H2-10, H2-7)

Communication fails after key rotation — certificate chain issue or time is untrustworthy for verification?

Conclusion: Post-rotation failures usually split into identity-chain failures vs time-context failures (validity checks using an unqualified clock).
Evidence: (1) Read auth_fail_reason with cert_serial/cert_expiry/revocation_status. (2) At the same moment, check time_quality/sync_state/offset to confirm verification used a qualified time context.
First fix: Log auth failures with time-quality context and pin verification to a time-qualified domain before retrying rotation. (H2-7, H2-5)

CRC passes, but state is still inconsistent — unclear semantics or missing out-of-order handling?

Conclusion: CRC only proves bit integrity; semantic inconsistency usually comes from missing validity rules (age/window) or undefined reorder/duplicate resolution.
Evidence: (1) Confirm the telegram model includes source_id/seq/mode/state/validity_window. (2) Check out_of_order_cnt, seq_reuse_cnt, and whether reject_reason distinguishes “expired vs reordered vs duplicate”.
First fix: Add a minimal semantic contract (seq + validity window + state rules) and define deterministic reorder/duplicate handling. (H2-3, H2-6)

After a power loss and reboot, interface recovery is slow — security handshake timeout or rollback policy?

Conclusion: Slow recovery is typically a staged-path problem: link returns quickly, but session/auth or version gates keep retrying.
Evidence: (1) Measure link-up to session-ready time using handshake_state, handshake_fail_reason, and retry counters. (2) Check update/rollback evidence: cfg_version/fw_version, commit_ok, rollback_cnt/rollback_reason.
First fix: Split recovery timing into link vs secure-session phases and log a single root fail reason per phase. (H2-7, H2-11)

After ESD, the link recovers but time drift increases — PTP path delay jump or degraded holdover?

Conclusion: Link recovery can hide timing degradation; increased drift is either path-delay instability or holdover quality regression.
Evidence: (1) Compare path_delay_ns and offset_ns before/after ESD to detect step changes. (2) Check holdover_state and persistent time_quality degradation that accumulates over time.
First fix: Capture an evidence packet spanning pre/post ESD with path-delay, offset, and holdover markers, then isolate the dominant driver. (H2-5, H2-11)

Latency becomes uncontrollable after gateway forwarding — buffering from bridging or missing per-hop evidence fields?

Conclusion: Gateways become “black boxes” unless per-hop evidence exists; uncontrolled latency is often buffering/queueing that cannot be attributed.
Evidence: (1) Verify hop_id and per_hop_delay exist so delay increments are visible at the gateway boundary. (2) Check queue/drop evidence near the gateway: queue_depth/queue_delay/drop_cnt.
First fix: Add per-hop evidence at the gateway boundary (ingress/egress markers or equivalent stats) before tuning thresholds. (H2-4, H2-9, H2-10)

Want fewer false alarms without missing real faults — how to calibrate timeouts and consistency thresholds using evidence?

Conclusion: Thresholds should be evidence-calibrated: set gates against measured tail distributions and validate with replayable incident packets.
Evidence: (1) Track latency/jitter tails (p99/p999) and the time-quality context at each alarm. (2) Analyze reject_reason statistics to identify which causes dominate false alarms vs true faults.
First fix: Require every threshold change to attach a before/after evidence packet set and run the H2-11 gate subset before rollout. (H2-6, H2-11)