1) TSN Switching Fabric (Forwarding • Queues • Shaping)

• Contract

  Keep control-class streams within a bounded latency/jitter envelope while isolating non-critical traffic.

• Interfaces

  Ingress classification (VLAN/PCP/stream ID) → queue mapping → shapers/gates → egress scheduling.

• Validation hooks

  Latency/jitter under worst-case load, queue watermark curves, drop reasons (tail drop vs policing), schedule conformance.

• Minimum evidence fields

  Per-queue counters, gate schedule version, policing violation counters, queue watermark snapshots.

2) PTP Hardware Timestamping (Timestamps • Servo • Clock)

• Contract

  Bound and explain time error through hardware TX/RX timestamps and defined Boundary/Transparent Clock behavior.

• Interfaces

  PTP event messages → hardware timestamp unit (MAC/PHY) → servo/clock → time distribution to the data plane.

• Validation hooks

  Offset-from-master stability, residence time visibility, holdover quality, GM switch relock time, asymmetry sensitivity.

• Minimum evidence fields

  Offset/state, timestamp error flags, servo lock quality, residence time stats, GM change events.

3) ECN/WTB/MVB Protocol Engine (Terminate • Map • Filter)

• Contract

  Bridge legacy buses into shaped TSN streams without burst leakage or violation of traffic-class guarantees.

• Interfaces

  Bus frames → mapping tables/ACL → buffering & shaping → TSN stream encapsulation with priority tagging.

• Validation hooks

  Buffer occupancy under bursts, cycle alignment, mapping correctness, deny/drop behavior for out-of-policy frames.

• Minimum evidence fields

  Mapping table version, deny/drop counters, buffer watermark, per-stream conformance reports.

4) Isolation + Supervision (Isolated PHY • Watchdog • PMIC)

• Contract

  Avoid silent failure via supervised power/reset, independent watchdog strategy, and isolation-aware port health reporting.

• Interfaces

  Power rails/PMIC → reset tree; watchdog (external/window) → safety reset; isolated PHY → link/PCS error counters.

• Validation hooks

  Brownout behavior, restart determinism, watchdog independence under high CPU load, post-transient port integrity checks.

• Minimum evidence fields

  Reset cause, rail event logs, PMIC fault pins, watchdog resets, port error deltas after transients.

802.1Qbv — Time-Aware Shaper (Gates)

• Purpose

  Reserve guaranteed “control windows” so critical traffic meets a worst-case delay bound.

• Implementation points

  Gate control list (GCL), cycle time/phase, guard band, VLAN/PCP → queue → gate mapping.

• Measurable proof

  Control-stream max latency/jitter under worst-case load; gate misses; queue watermark peaks; window utilization.

• Common pitfalls

  GCL version drift between nodes; cycle misaligned with application rhythm; insufficient guard band allowing tail-frame intrusion.

802.1Qbu / 802.3br — Frame Preemption

• Purpose

  Bound the blocking time caused by large preemptable frames at the egress port.

• Implementation points

  Express vs preemptable queue separation, preemption handshake, fragment/reassembly behavior, coordination with Qbv.

• Measurable proof

  Worst-case blocking time for critical frames; preemption event counters; reassembly error/drop statistics.

• Common pitfalls

  Capability mismatch on the link; hidden drops during reassembly; conflicts with guard band design leading to “random” jitter.

802.1Qci — Per-Stream Filtering & Policing

• Purpose

  Contain misbehaving streams so a single flow cannot collapse queues or scheduled traffic.

• Implementation points

  Stream identification, metering/policing rules, drop/mark action, violation counters with reason codes.

• Measurable proof

  Violations are capped and attributable; control-stream latency bound remains intact during aggressive injection tests.

• Common pitfalls

  Over-broad rules causing false drops; under-strict rules letting storms through; missing reason codes making field incidents non-actionable.

802.1Qav — Credit-Based Shaper (CBS)

• Purpose

  Provide stable throughput to mid-priority streams while yielding deterministically to control windows.

• Implementation points

  IdleSlope/SendSlope parameterization, queue mapping, bandwidth caps, coordination with Qbv windows.

• Measurable proof

  Mid-class throughput stability and bounded queue growth; control-stream jitter does not increase under sustained CBS load.

• Common pitfalls

  Parameters not matched to link rate/frame sizes; interaction with Qbv creating periodic congestion that appears as intermittent jitter.

802.1Qcc — Centralized Configuration

• Purpose

  Keep TSN configuration consistent and auditable so “only some trains fail” cannot happen silently.

• Implementation points

  Config distribution, versioning, rollback strategy, change audit; optional hash/signature for integrity.

• Measurable proof

  Consistency scans detect drift; change events correlate with metric shifts; version mismatches raise explicit alarms.

• Common pitfalls

  No version control; field tweaks not traceable; distribution delays causing transient mismatches across nodes.

Minimum proof package (what must be logged together)

• Worst-case load model

  Control + status + maintenance mix, plus legacy burst injection at domain crossings.

• Measurements

  Per-class latency/jitter, queue watermark, policing violations, and port blocking time during failover.

• Evidence set

  Schedule version + counters + time sync state must be captured in the same incident window.

• Acceptance target

  Control-class P99.999 latency stays inside budget across burst and redundancy transitions.

A) 802.1AS (gPTP) vs IEEE 1588 (PTP)

• Decision principle

  Use 802.1AS when the TSN domain requires tightly-coupled timing semantics; keep IEEE 1588 compatibility at defined boundaries (maintenance/uplink) without leaking external timing into the safety domain.

• Implementation points

  Profile selection, domain separation, port role enforcement, and explicit “trusted time source” policy per interface.

• Measurable proof

  Stable offset under worst-case traffic plus controlled convergence after topology changes.

• Minimum evidence fields

  Profile/domain ID, port state, offset statistics, grandmaster ID history, policy decisions (accept/reject).

B) Boundary Clock (BC) vs Transparent Clock (TC)

• Role selection

  BC terminates upstream time and regenerates downstream time (strong domain isolation). TC forwards time while correcting residence time (lower complexity, higher path determinism requirements).

• Implementation points

  BC: per-port servo + role/state machine. TC: correction field update + stable forwarding path for PTP event packets.

• Measurable proof

  Residence time visibility and bounded jitter contribution; controlled behavior during link failover and redundant GM selection.

• Minimum evidence fields

  BC/TC mode, port states, residence time stats, correction updates, GM switch events and re-lock timing.

C) PHY vs MAC timestamping (where error is born)

• Key difference

  PHY timestamps minimize variability introduced by MAC pipelines and egress queueing. MAC-only timestamping is more load-sensitive unless the PTP path is strictly isolated.

• Implementation points

  Explicit TX/RX timestamp insertion location, dedicated handling for PTP event packets, and isolation from best-effort queueing.

• Measurable proof

  Timestamp jitter stays low as network load increases; offset variance does not correlate with queue depth.

• Minimum evidence fields

  TX/RX timestamp jitter, event-packet latency distribution, queue watermark snapshots, load-correlation indicators.

D) BMCA, holdover, loss-of-lock, GM switching

• Operational contract

  Loss-of-lock must be detected quickly, switching must be explainable, and holdover drift must be bounded with an explicit “time quality” state exposed to consumers.

• Implementation points

  BMCA policy (trusted GM list), dual-uplink preference logic, OCXO/TCXO holdover tuning, and deterministic re-lock sequence.

• Measurable proof

  Convergence time after GM change, holdover drift rate, false alarm rate for lock loss, and recovery stability.

• Minimum evidence fields

  GM change log, servo state transitions, holdover enter/exit events, clock quality score, drift rate estimate.

E) SyncE (if present) + PTP: frequency vs time

• Division of labor

  SyncE stabilizes frequency (lower wander), while PTP provides time/phase alignment. The gateway must prevent “two masters” by defining priority and handover rules.

• Implementation points

  PLL/clock-tree status gating into the PTP servo, explicit SyncE lock propagation, and failover policies that keep time quality monotonic.

• Measurable proof

  Faster re-lock and lower holdover drift when SyncE is locked; clean degradation when SyncE unlocks.

• Minimum evidence fields

  SyncE lock, PLL status, servo rate ratio, holdover drift estimate, time quality state changes.

Minimum acceptance checklist (time plane)

1. Timestamp points are documented per port (TX/RX, PHY/MAC), and PTP event packets have a deterministic fast path.
2. Residence time is measurable and logged (TC correction or BC regeneration behavior is explicit).
3. Asymmetry sensitivity is tested (cable/PHY mismatch scenarios) and flagged when beyond limits.
4. GM switching produces a complete evidence trail (GM IDs, servo state, convergence time).
5. Holdover drift has a bounded model with a “time quality” state that downstream functions can trust.

A) Two traffic types → two mapping rules

• Periodic state (telemetry)

  Map to a periodic Ethernet stream with bounded bandwidth and explicit freshness policy (e.g., drop-oldest vs drop-newest). Target predictable cadence and stable queue occupancy.

• Event-driven control

  Map to an event stream with higher priority but strict policing (burst caps). Events must be attributable (who/what/when) and must not collapse scheduled control windows.

• Measurable proof

  State streams keep cadence; event storms are contained; scheduled TSN control latency bound stays intact during burst injection.

• Minimum evidence fields

  Classification counts, mapping table version, per-class output rates, violation/drop reason codes.

B) Burst absorption + cycle alignment (shaping strategy)

• Implementation points

  Ingress burst buffer (watermark), token-bucket/leaky-bucket shaping for events, periodic alignment for state traffic, and queue isolation between state/event/control classes.

• Measurable proof

  Buffer watermarks remain bounded; output rates conform to configured limits; TSN queues do not exceed planned windows during bursts.

• Minimum evidence fields

  Buffer watermark timeline, burst-size histogram, shaping counters, queue occupancy snapshots, schedule version tag.

• Common pitfalls

  One shared queue for everything; burst buffer without shaping; “event stream” not policed and therefore becomes a DoS path.

C) Time consistency: tagging vs alignment

• Tagging model

  Attach an ingress PTP timestamp to each bridged object/frame so consumers can distinguish “acquired time” from “arrival time”.

• Alignment model

  For periodic state, align emission to a PTP-derived cycle boundary to reduce jitter and improve correlation across car segments.

• Measurable proof

  Consumers can reconstruct ordering and latency without ambiguity; state streams show reduced phase noise after alignment.

• Minimum evidence fields

  Ingress timestamp, sequence/cycle markers, alignment phase offset, time-quality state at emission.

D) Filtering and whitelist (semantic boundary)

• Whitelist logic

  Permit crossing only for explicitly allowed message IDs/object IDs/device IDs with rate ceilings. Default deny must be logged with reason codes.

• Policing integration

  Apply whitelist first, then per-stream policing (Qci-style) so both semantic violations and rate violations are independently attributable.

• Measurable proof

  Untrusted frames are rejected deterministically; high-rate sources are contained; crossing cannot create uncontrolled traffic in TSN classes.

• Minimum evidence fields

  Deny/drop counters with reasons, offender identity, mapping table version, and audit log for changes.

Minimum acceptance checklist (cross-domain)

1. Every legacy frame/object is classified as State or Event and mapped to a defined TSN class and queue.
2. Burst absorption exists, but outputs are shaped (token bucket / cadence alignment) to protect TSN schedules.
3. Time semantics are explicit: ingress timestamp tagging and/or PTP cycle alignment is documented and testable.
4. Whitelist rules are default-deny, versioned, auditable, and integrated with rate policing.
5. Evidence explains outcomes: accepted vs shaped vs delayed vs dropped, with reason codes and counters.

A) Isolation placement (what is isolated, and where)

• PHY-side isolation

  Choose an isolated PHY/transceiver when the link must remain robust under large common-mode excursions. The boundary becomes explicit: cable/shield energy is handled on the port side, while logic remains protected.

• Magnetics coupling (Ethernet)

  Transformer coupling improves signal integrity and helps with DC blocking, but it does not eliminate common-mode coupling. Shield/chassis strategy still determines whether transients inject into logic reference.

• Digital isolators (legacy ports)

  Use digital isolation for ECN/WTB/MVB-side physical interfaces where bus reference and long cable runs can swing. Ensure bandwidth/latency and EMC behavior are validated at the gateway boundary.

• Isolated power

  Isolated DC-DC reduces DC coupling but introduces parasitic capacitance that becomes a high-frequency common-mode path. Treat it as a deliberate return element, not a hidden side effect.

B) CMTI and the common-mode return path (the real failure mode)

• CMTI as a link-stability limiter

  When common-mode dv/dt exceeds isolation tolerance, symptoms often look like random link drops, CRC storms, timestamp jitter spikes, or unexpected resets. The gateway must be designed so the dominant transient energy returns to chassis, not through logic ground.

• Return path ownership

  Define where shield is bonded to chassis, where suppression components reference (chassis vs logic), and which high-frequency paths are “allowed” (short, local) vs “harmful” (large loops through logic ground).

• Measurable proof

  During bursty transients, port error counters rise predictably (if at all), timestamps remain stable, and resets are attributable with a consistent cause chain.

• Minimum evidence fields

  Per-port PHY error counters, link up/down timestamps, PTP offset/jitter correlation, reset cause, brownout/rail event markers.

C) Port protection topology (ESD / surge / transient)

• TVS placement and reference

  TVS is only effective when its return loop is short and referenced to the intended sink (often chassis). A long “TVS-to-ground” loop can convert clamping into injected noise.

• Common-mode choke (CMC) with intent

  CMC reduces common-mode current but can create resonances or saturate under high-energy events. Select and place it to avoid turning the port into a tuned antenna.

• Two-stage thinking

  First stage near the connector limits energy and defines the return path. Second stage deeper on-board protects sensitive nodes. (Gas discharge devices may appear at system level, but keep gateway analysis focused on port-level behavior.)

• Measurable proof

  After ESD/surge, link recovery is deterministic, error counters reflect the event window, and no silent corruption appears in timing streams.

D) What EN 50155 / EN 50121 imply at gateway level

• EN 50155 (power/temperature reality)

  Wide temperature, supply variation, and transient behavior force explicit brownout strategy, reset governance, and “survivable logging” during voltage disturbances.

• EN 50121 (EMC reality)

  EMC constraints translate directly into isolation boundary design, shield-to-chassis referencing, and common-mode current management at every external interface.

• Gateway deliverable

  A compliance-ready gateway has traceable design decisions: boundary diagrams, return-path rationale, and evidence outputs that align with test outcomes and field incidents.

• Minimum evidence fields

  Port-level error counters, link-event logs, transient/brownout flags, reset cause, and time-quality state transitions.

Minimum acceptance checklist (isolation/EMC)

1. Every external interface has an explicit isolation boundary and a defined reference strategy (chassis vs logic).
2. Common-mode energy has a short, intended return path; “accidental” returns through logic ground are minimized.
3. Port protection (TVS/CMC) is placed to keep clamp loops short and avoid resonance/antenna behavior.
4. Field symptoms can be explained with evidence: PHY counters, link events, PTP jitter/offset correlation, reset cause.
5. Standard constraints are mapped to gateway-level decisions and logs (not treated as external system problems).

A) Wide input + brownout thresholds (rail transients)

• What must be decided

  Define a brownout policy that distinguishes short dips from sustained undervoltage: warn, degrade, and reset must be separate stages with explicit timing and hysteresis.

• Implementation points

  Per-rail monitoring for core/DDR/PHY domains, debounce windows, and a staged response (log + mark time quality + controlled reset if needed).

• Measurable proof

  Reduced false resets under brief sags, bounded recovery time after real brownouts, and consistent reset causes across repeated events.

• Minimum evidence fields

  Rail min/max, brownout counters, debounce-trigger flags, reset cause, time-of-event stamp.

B) PMIC supervision (rails, sequencing, reset governance)

• PMIC as the hardware referee

  The PMIC must supervise rails, enforce sequencing, latch faults, and drive a reset tree that brings up switch/PHY/compute in a reproducible order.

• Implementation points

  PG signals, fault latches, staged resets (local vs global), and deterministic re-assertion rules for partial faults.

• Measurable proof

  Power-up is repeatable; faulted rails trigger the intended scope of reset; a single-rail issue does not silently corrupt timing or switching state.

• Minimum evidence fields

  PG/fault latch state, rail event log, reset-tree state, reboot step timing markers.

C) Watchdog (window + external + decoupled feeding)

• Why window/external WD

  A window watchdog prevents “always-on feeding” that masks failures. An external watchdog remains effective when the SoC is hung or the scheduler is compromised.

• Feeding strategy

  Feed is conditional on a health vote, not a single task heartbeat. Typical health inputs include switch liveliness, PTP lock/time quality, buffer watermark sanity, and PMIC fault state.

• Measurable proof

  Real deadlocks reset reliably; heavy load does not cause false triggers; post-reset recovery is deterministic and recorded.

• Minimum evidence fields

  WD reset cause, last health vote snapshot, last-known counters, WD window violations, recovery outcome.

D) Holdup objectives (minimum survivable actions)

• Define goals, not capacitor math

  Holdup is sized to finish a small set of actions: flush critical logs, preserve minimal state, and mark timing as degraded (holdover / not-trustworthy) before power collapses.

• Implementation points

  Brownout pre-warning triggers log commit; storage controller flush completion is verified; time-quality state is updated so consumers do not misinterpret stale timestamps.

• Measurable proof

  After power loss, evidence is complete (reset cause + rail event + time state) and recovery time is bounded.

• Minimum evidence fields

  Holdup enter/exit, flush complete flag, last log sequence ID, last time-quality state, restart reason chain.

Minimum acceptance checklist (power/supervision)

1. Brownout is staged (warn/degrade/reset) with explicit debounce and evidence logs.
2. PMIC enforces rail sequencing and latches faults; reset scope is intentional and reproducible.
3. Watchdog is windowed and preferably external; feeding is gated by a multi-signal health vote.
4. Holdup completes a minimal survivable set: evidence flush, minimal state save, and time-quality marking.
5. Resets are explainable: reset cause aligns with rail events, port counters, and time-quality transitions.

A) PRP/HSR Redundancy Mechanisms

• PRP Operation

  Dual network configuration with automatic frame retransmission and de-duplication at the receiving end. Zero switch-over time between networks.

• HSR Operation

  Dual-ring setup with bi-directional forwarding, reducing switch-over latency. Packets circulate in the ring, with duplicate frames removed.

• Measurable Metrics

  Packet loss window during failover, duplicate detection efficiency, and recovery time after link failure.

• Evidence Fields

  PRP/HSR mode, packet sequence number, duplicate counters, failover timestamps, recovery time logs.

B) Ring Redundancy (MRP etc.)

• Ring Protocols

  Use of Ring protocols (MRP, etc.) at the car-level to maintain network continuity. Ring Manager or Client roles should be clearly defined in the train’s network topology.

• Failover and Recovery

  Ring switching latency should be minimized (in the order of milliseconds). Failure detection and recovery times must be defined and kept within operational tolerances.

• Measurable Metrics

  Switching time during ring failure, latency during recovery, packet loss rates, and network re-convergence time.

• Evidence Fields

  Ring state, topology change events, failover duration, and packet drop counters during ring failure.

C) Fault Containment (Storm Control, Qci Policing, Loop Prevention)

• Storm Control

  Limit broadcast and multicast traffic to avoid network storms that could affect time-sensitive data flows.

• Qci Policing

  Policing mechanisms to limit traffic bursts that may overwhelm the network, especially in safety-critical data streams.

• Loop Prevention

  Using protocols such as Spanning Tree to prevent network loops and broadcast flooding in the Ethernet network.

• Measurable Metrics

  Drop rates of non-critical traffic, violations of Qci thresholds, loop detection timestamps, and flood-control statistics.

D) Partitioning (VLAN/VRF/ACL for Control Domain Isolation)

• VLAN/ACLs

  Define traffic flows within the train’s control domain using VLANs and ACLs to isolate critical traffic from non-essential data.

• VRF Partitioning

  Use Virtual Routing and Forwarding (VRF) to logically separate control plane from other data domains in the network.

• Measurable Metrics

  Cross-domain traffic enforcement, VLAN membership, ACL hits, and VRF policy logs.

• Evidence Fields

  VLAN/ACL counters, policy versioning, cross-domain traffic logs, and audit hash for config integrity.

Redundancy and Containment Acceptance Checklist

1. PRP/HSR redundancy mechanisms are deployed with zero switch-over time and minimal packet loss.
2. Ring redundancy mechanisms are implemented with low switching latency and stable failover recovery.
3. Fault containment measures are in place: storm control, Qci policing, and loop prevention.
4. Cross-domain traffic is isolated with VLAN and ACL policies; VRF is used for domain separation.
5. All critical events are logged with relevant evidence fields and can be traced for debugging and maintenance.

A) PTP Evidence Fields

• Offset

  Track timing deviations between grandmaster and the gateway. Detect large offsets or synchronization failures.

• GM State

  Monitor the state of the Grandmaster (locked, holdover, free-run). Critical for diagnosing timing issues.

• Servo Lock

  Record whether the PTP servo is locked and stable. Useful to identify when the gateway is not synchronizing properly.

• Residence Time

  Measure the time that PTP packets reside in the gateway. A large residence time can indicate bottlenecks.

• Asymmetry Indicators

  Track the asymmetry between TX and RX timestamps, highlighting potential delays or incorrect path setups.

Security & Configuration Integrity (Without Turning Into a Cyber Article)

A train gateway is “secure enough” only when firmware and configuration changes are provably authentic, auditable, and cannot silently drift in the field. The objective here is not attacker tactics, but operational integrity: boot only trusted code, apply only signed schedules/policies, isolate maintenance access, and allow cross-domain traffic strictly by whitelist.

Secure boot Root-of-trust Signed config Mgmt isolation Whitelist cross-domain

Required security surface (4 blocks)

A) Secure boot + signed firmware + anti-rollback

• What must be guaranteed

  Only authenticated firmware can run, and older vulnerable images cannot be re-installed (rollback).

• Implementation points

  Boot-time signature verification, measured/verified boot state flag, and a monotonic counter for version gating (stored in TPM/secure element/HSM-backed NVM).

• Measurable acceptance

  Unsigned images refuse to boot; signature failures are logged; rollback attempts are blocked and recorded.

• Evidence fields

  secure_boot=enabled, fw_version, fw_signature=ok/fail, anti_rollback_counter, last_update_id.

• Example MPNs (root-of-trust)

  Microchip ATECC608B, Infineon OPTIGA™ Trust M (SLS32AIA), NXP SE050, Infineon TPM2.0 SLB9670.

B) Configuration integrity for TSN/VLAN/ACL

• What must be guaranteed

  TSN gate schedules, VLAN membership, ACL rules, and policing profiles cannot be modified without detection and audit traceability.

• Implementation points

  Sign the configuration bundle; store a version + audit hash; verify signature before activation; keep an immutable “last-known-good” snapshot.

• Measurable acceptance

  Unsigned policy updates are rejected; active configuration always exposes a version ID and hash; policy changes correlate to a logged maintenance session.

• Evidence fields

  cfg_version, cfg_audit_hash, cfg_signature=ok/fail, tsn_schedule_id, acl_profile_id, change_actor.

• Example MPNs (secure storage)

  Cypress/Infineon FM25V10 (FRAM), Fujitsu MB85RS64V (FRAM), Winbond W25Q128JV (SPI NOR, for signed bundles + LKG images).

C) Remote maintenance isolation (do not mix planes)

• What must be guaranteed

  Maintenance access cannot become a “backdoor” into the control domain, and control traffic cannot saturate or destabilize maintenance functions.

• Implementation points

  Dedicated maintenance port (preferred), or a strict logical boundary (VLAN + ACL + rate limits) with a separate management CPU/process domain.

• Measurable acceptance

  Only authenticated sessions can change configuration; cross-plane traffic is blocked by default; access attempts are logged with identity and outcome.

• Evidence fields

  mgmt_port_state, mgmt_auth=ok/fail, mgmt_session_id, mgmt_acl_drops, rate_limit_hits.

• Example MPNs (isolation options)

  ADI ADuM140D (digital isolator family), TI ISO7741 (digital isolator family) — commonly used to harden management/legacy I/O boundaries.

D) Least privilege + whitelist cross-domain flows

• What must be guaranteed

  Only explicitly approved flows can cross domain boundaries (maintenance ↔ control, legacy ↔ TSN), matching the whitelist mapping rules in H2-6.

• Implementation points

  Default-deny ACLs, per-stream policing for anything that crosses domains, and a minimal set of management services exposed (no “open” discovery flooding).

• Measurable acceptance

  Cross-domain counters show only expected flows; blocked attempts are logged; policy violations do not consume critical TSN queues.

• Evidence fields

  cross_domain_allow_hits, cross_domain_denies, qci_violations, storm_counters, queue_drop_by_class.

• Example MPNs (TSN switch context)

  NXP SJA1105 (TSN switch family), Microchip LAN9662 (TSN switch family) — platforms where schedule IDs, policing counters, and ACL hits can be exposed as evidence fields.

Maintenance “Evidence Pack” (minimum fields to export per incident)

Category	Minimum fields	When to capture + how to interpret
Firmware trust	fw_version, fw_signature, secure_boot, anti_rollback_counter	Capture on every boot and every update. If behavior changed without a version change, suspect config drift; if signature fails, block run.
Config integrity	cfg_version, cfg_signature, cfg_audit_hash, tsn_schedule_id	Capture before/after any change. If schedule changes but hash does not, logging is broken; if hash changes without actor/session, treat as integrity incident.
Mgmt isolation	mgmt_auth, mgmt_session_id, mgmt_acl_drops, rate_limit_hits	Capture on remote access attempts. Rising drop/limit counters indicate probing or misrouted traffic leaking into the management plane.
Cross-domain control	cross_domain_denies, allow_hits, qci_violations, storm_counters	Capture during outages/latency spikes. Denies + storms often precede queue congestion; Qci violations reveal which stream is breaking the contract.

The goal is operational proof: a technician can show “this firmware and this schedule were active,” and every cross-domain access is attributable to an authenticated session.

Security & integrity acceptance checklist

1. Boot refuses unsigned firmware and logs the failure with a persistent event ID.
2. Anti-rollback is enforced by a monotonic counter (TPM/secure element/HSM-backed).
3. TSN/VLAN/ACL bundles are signed; signature is verified before activation; active policy exposes version + audit hash.
4. Maintenance plane is isolated: default-deny from maintenance to control; only whitelisted flows may cross domains.
5. Every change is attributable: authenticated session ID + actor + timestamp + before/after config hash.

Figure H2-11 (F10). The gateway security surface is about integrity: root-of-trust keys validate firmware and configuration, anti-rollback prevents silent downgrades, and a whitelist gate enforces cross-domain rules with auditable evidence fields.

Cite this figure: Root-of-Trust + Signed Configuration Chain (F10) — Secure boot • Signed config • Anti-rollback • Whitelist gate (SVG)

Keep the scope operational: integrity and auditability for firmware + configuration, plane isolation for remote maintenance, and least-privilege cross-domain access enforced by whitelist rules and measurable counters.

Request a Quote

Name

Email

Company

Part Number(s) / BOM

Quantity & Target Lead Time

Alternates Allowed

Pin-compatible only Close electrical + minor layout ok Functionally equivalent ok

Temperature Grade

Any Commercial Industrial Automotive

Package / Footprint

Compliance

RoHS REACH OK RoHS Required REACH Required No restriction

Budget Window

Lot Size / Qty

Message

Attachment

Accepted Formats

pdf, csv, xls, xlsx, zip

Attachment

Drag & drop files here or use the button below.

Send

FAQs (Evidence-Driven Troubleshooting, Accordion)

Each answer follows a fixed troubleshooting pattern: 1-sentence conclusion, 2 evidence checks, and 1 first fix, with a chapter mapping so results can be verified using logged evidence fields.

1) PTP clock jumps occasionally — GM switch, asymmetry, or drifting hardware timestamp path? → H2-5 / H2-10

Conclusion: Occasional PTP jumps are most often explained by a GM role change or a time-path imbalance that breaks the servo’s assumptions, rather than “random jitter.”

• Evidence check #1H2-10: Compare gmState / GM ID changes and the jump timestamp; confirm whether a BMCA-driven switch occurred near the offset spike.
• Evidence check #2H2-5/H2-10: Check TX/RX delay asymmetry indicators (skew flags, path-delay delta, residence-time anomalies) and whether timestamp source moved (MAC vs PHY).
• First fixForce a stable GM priority plan and lock the timestamp point (prefer hardware timestamping consistency); then re-baseline asymmetry calibration and validate offset p95 after relock.
• Example MPNsJitter-cleaning/holdover clock: SiTime SiT5xxx (family); Secure time/attestation helper: Microchip ATECC608B (for signed evidence bundles).

2) TSN still jitters even with Qbv — gate list mismatch, or guard band / preemption not effective? → H2-4 / H2-10

Conclusion: Qbv jitter typically comes from schedule inconsistency across nodes or from a missing “protection margin” (guard band/preemption) that lets best-effort frames bleed into critical windows.

• Evidence check #1H2-10: Verify gate schedule version/hash is identical on all relevant ports; correlate jitter bursts with a schedule update or partial rollout.
• Evidence check #2H2-4/H2-10: Inspect preemption status/counters (Qbu/802.3br) and queue watermark/drops during the critical window to confirm interference.
• First fixFreeze configuration, push a single audited schedule version to all nodes, then add/validate guard band or enable preemption where supported; re-measure latency p99 and queue watermark in the same test profile.
• Example MPNsTSN-capable switch SoC (examples): NXP SJA1105/SJA1110 (family), Microchip LAN966x (family) (verify feature set vs Qbv/Qbu/Qci needs).

3) After consist coupling, WTB/MVB data latency grows — shaping buffer too deep or priority mapping wrong? → H2-6 / H2-4

Conclusion: Coupling usually changes burst patterns, and the gateway’s domain-crossing buffer can become the dominant latency source if shaping depth or priority mapping is not aligned to TSN streams.

• Evidence check #1H2-6: Inspect bridge metrics for buffer depth / enqueue delay on the WTB/MVB ingress side; confirm whether bursts are being absorbed with excessive holding time.
• Evidence check #2H2-4: Confirm priority-to-queue mapping and stream classification; check whether control/event frames were downgraded into a non-critical queue class.
• First fixReduce shaping depth for the critical class and align periodic frames to cycle boundaries; re-map event/control frames into the intended TSN stream/queue and verify end-to-end latency after coupling.
• Example MPNsDigital isolator for bus-domain separation (examples): TI ISO7721, Analog Devices ADuM140x (family) (choose per interface/CM requirements).

4) Gateway resets when the network is busy — brownout threshold too aggressive or watchdog tied to workload? → H2-8 / H2-10

Conclusion: Load-triggered resets almost always point to either a supply dip tripping brownout (power integrity) or a watchdog strategy that fails under CPU/ISR pressure during peak traffic.

• Evidence check #1H2-10: Correlate brownout events / PMIC faults with the reset timestamp; confirm whether voltage rail warnings precede the reboot.
• Evidence check #2H2-10: Check reset cause and watchdog logs; look for missed service windows during queue spikes or IRQ storms.
• First fixSeparate watchdog servicing from traffic-heavy tasks (dedicated low-jitter service loop), then tune brownout thresholds and add short holdup to complete safe logging before reset; verify no resets during stress replay.
• Example MPNsWindow watchdog (examples): TI TPS3435, Maxim MAX6369 (family); Supervisor (examples): TI TPS38xx (family).

5) Broadcast storm after swapping two ports — missing loop control or storm/Qci limits not set? → H2-9 / H2-10

Conclusion: A storm after a simple port swap usually indicates the design relies on “correct wiring,” and lacks hard containment (loop protection + storm control + per-stream policing).

• Evidence check #1H2-10: Confirm spikes in broadcast/unknown-unicast counters and queue watermarks; check whether CPU/management plane load rose simultaneously.
• Evidence check #2H2-9/H2-10: Check loop events (topology change logs) and Qci violation counters to see whether policing engaged or remained inactive.
• First fixEnable loop protection appropriate to the deployment and apply storm control limits per port/VLAN; then add Qci policing for critical classes so a flood cannot starve time-sensitive queues.
• Example MPNsCommon-mode choke for Ethernet port robustness (examples): TDK ACM/ACT series (family) (select by impedance/current) + TVS (examples): Littelfuse SMF/SMCJ series (family).

6) Noticeable packet loss during redundant link switchover — PRP/HSR issue or queue/buffer policy wrong? → H2-9 / H2-4

Conclusion: Perceivable loss during failover usually means redundancy is not truly “hitless” in implementation, or buffering/queue policy cannot absorb transient duplication or topology convergence.

• Evidence check #1H2-9: Compare failover event timestamps with duplicate/de-dup counters (PRP/HSR) to confirm whether de-dup is dropping valid frames or timing out.
• Evidence check #2H2-4/H2-10: Inspect queue watermark, tail-drop counters, and gate-window alignment during failover to see whether critical queues starve.
• First fixIncrease transient buffering only for the affected class, tighten de-dup window rules, and validate schedule continuity across redundancy events; then rerun a scripted failover test and confirm loss window meets acceptance.
• Example MPNsRedundancy-capable TSN switch families (examples): NXP SJA1110 (family) (feature-dependent); verify PRP/HSR handling path and counters availability.

7) After port ESD, link is up but BER rises — damaged PHY or common-mode return injecting EMI? → H2-7 / H2-10

Conclusion: “Link up but errors rise” typically points to marginal analog front-end health (PHY stress) or a worsened common-mode return path that couples interference into the receiver.

• Evidence check #1H2-10: Review PCS error counters / FEC counters (if present) and BER trend before/after the ESD event; confirm persistent degradation rather than a short transient.
• Evidence check #2H2-7: Inspect chassis/SHIELD reference continuity and common-mode suppression performance; correlate error spikes with nearby switching events or cable handling.
• First fixReplace or isolate the suspect port (A/B swap to confirm), and improve common-mode return control (shield termination strategy + choke/TVS placement); re-validate error counters under the same EMC stimulus.
• Example MPNsEthernet ESD/TVS examples: Nexperia PESD series (family), Littelfuse SPxxxx (family); Digital isolator examples: TI ISO7741.

8) Cold start fails or is slow — PMIC sequencing/soft-start or crystal start-up/PLL lock time? → H2-8 / H2-5

Conclusion: Low-temperature boot issues are usually sequencing-related (rails not meeting thresholds in time) or clock-related (oscillator/PLL start-up stretch), and the fix depends on which timestamped evidence leads.

• Evidence check #1H2-10: Compare power-good timing, rail ramp logs, and reset release time; confirm whether PMIC asserts faults or delays at cold start.
• Evidence check #2H2-5/H2-10: Check clock/PLL lock indicators and PTP servo lock time after boot; confirm whether time sync becomes stable late or never locks.
• First fixAdjust PMIC soft-start/sequencing margins and reset release timing, then select a clock plan with predictable cold-start behavior; validate by repeating cold boots while recording PG/lock timestamps.
• Example MPNsSupervisor/reset examples: TI TPS38xx (family); Industrial oscillators (example family): SiTime SiT8xxx (family) (verify rail temp range and lock spec).

9) Only some trains misbehave after a config change — config drift or inconsistent version/signature checks? → H2-11 / H2-10

Conclusion: “Fleet-specific” anomalies after a change strongly suggest configuration divergence or partial rollout where integrity checks are not enforced consistently across devices.

• Evidence check #1H2-10/H2-11: Compare config audit hash / schedule version / VLAN-ACL version across affected vs unaffected trains; confirm mismatch with the same symptom pattern.
• Evidence check #2H2-11: Verify signature status for firmware and config bundles; check whether any node runs “unsigned/legacy mode” or accepts non-audited changes.
• First fixEnforce signed config + strict version gating (no “best-effort apply”), then re-deploy as a single audited release; validate by retrieving and comparing audit hashes from every gateway in the fleet.
• Example MPNsSecure element for signing/attestation: Microchip ATECC608B; TPM option (example family): Infineon OPTIGA TPM (family) (verify interface and lifecycle).

10) After connecting the maintenance port, abnormal flows appear in the control domain — isolation gap or VLAN/ACL boundary not sealed? → H2-11 / H2-9

Conclusion: If maintenance access perturbs the control domain, the boundary is not truly enforced (physical separation, VLAN/ACL, or whitelisted cross-domain flows), and the control plane is being exposed.

• Evidence check #1H2-10: Inspect ACL deny/hit counters and VLAN membership changes during maintenance sessions; confirm whether unexpected VLAN tags/ports became permitted.
• Evidence check #2H2-9/H2-10: Check storm/unknown-flood counters and topology events; confirm whether the maintenance side introduced loops or broadcast propagation into control VLANs.
• First fixLock the maintenance port into a dedicated domain (physical/logical), enforce explicit whitelists for any cross-domain streams, and validate with a scripted “maintenance attach” test that control-domain counters remain stable.
• Example MPNsIsolated transceiver approach examples (by interface): TI ISO1042 (CAN), TI ISO1410 (RS-485 family) (choose per bus; Ethernet uses magnetics + CM strategy).

11) TSN stream is dropped occasionally but counters look quiet — Qci policing or tail drop from congestion? → H2-4 / H2-10

Conclusion: Silent-looking drops usually come from (a) Qci policing silently discarding violating frames, or (b) brief congestion that causes tail drop before aggregate counters become obvious.

• Evidence check #1H2-10: Check per-stream Qci violation counters and rule IDs; correlate the drop time with policing events rather than port-level drops.
• Evidence check #2H2-4/H2-10: Inspect queue watermark peaks and microbursts (short-duration depth spikes); confirm whether tail drops occur in the exact queue serving that stream.
• First fixTemporarily relax Qci thresholds for the stream to confirm causality, then fix upstream burst shaping; if congestion-driven, adjust queue sizing/schedule alignment and verify drop-free behavior under the same replay trace.
• Example MPNsTSN switch families that expose per-stream policing counters (examples): NXP SJA11xx (family), Microchip LAN966x (family) (verify telemetry availability).

12) WTB/MVB frames look normal but controller acts late — which time tags / event-trigger fields are missing? → H2-6 / H2-10

Conclusion: “Frames look fine” can still hide timing ambiguity: without consistent event tagging and correlation IDs at the domain boundary, the controller cannot attribute cause-and-effect quickly or deterministically.

• Evidence check #1H2-6/H2-10: Verify whether the bridge logs include ingress timestamp, egress timestamp, and a stable event/correlation ID per control action.
• Evidence check #2H2-10: Compare controller action time to gateway’s event chain; confirm whether the “late action” aligns with buffer/shaping delay, not with bus-level frame correctness.
• First fixAdd minimal time tags at the crossing (ingress/egress + correlation ID) and log them as evidence fields; then tune shaping so event-trigger control frames are mapped into the correct TSN class and validated by end-to-end timing traces.
• Example MPNsSecure logging/identity anchor: Microchip ATECC608B (for signed event bundles); Supervisor examples: TI TPS3435 (robust reboot evidence).

Figure H2-12 (F12). A compact map for field work: start from the symptom, verify with evidence fields, then apply the first fix and re-measure the same counters.

Cite this figure: FAQ Troubleshooting Map (F12) — Symptom → Evidence → First Fix (SVG)

MPNs listed are examples to speed up BOM discussions; final selection must be validated against rail standards, interface requirements, temperature range, and lifecycle constraints.