Node roles (useful for planning clusters later)

• HMI / inputs: door handle/button, window switch, HVAC panel, key/entry triggers.
• Sensors: position, temperature, light/rain, occupancy, latch status.
• Actuators: motors (window/seat), valves/flaps, lighting drivers, locks.
• Module ECUs: door module / seat module combining multiple roles in one harness segment.

Practical takeaway: treat a LIN cluster as the smallest design unit (power, wake, scheduling, diagnostics), then decide how to aggregate it upward.

Three layers the gateway must provide

1. Aggregation layer: compress many low-rate signals into a stable, few-frame uplink.
2. Policy layer: sleep/wake responsibility chain, burst shaping, and state reconstruction after resets.
3. Service layer: diagnostics/logging, OTA/service access boundaries, and domain-to-backbone interoperability.

• Owned here: system topology (LIN clusters → gateway → CAN-FD), wake/power responsibility chain, and gateway policy logic.
• Mention-only: electrical-layer tuning (slew, waveform, timing knobs). Use one sentence + link.
• See also: LIN Transceiver (ISO 17987 / J2602) and CAN-FD Transceiver .

• Physical zone: doors / cabin / rear-trunk to minimize harness length and connector complexity.
• Harness routing: align clusters with the harness trunk and avoid long cross-zone branches.
• Fault containment: a single cluster fault should not disable unrelated comfort functions.
• Wake domain: group nodes that share wake sources to avoid “wake diffusion” and simplify attribution.

• N (node count): include module-internal sub-nodes if they consume schedule slots or diagnostics bandwidth.
• T (schedule cycle): the full main schedule loop period (not a single frame period); define event windows explicitly.
• L (load): record two values: L_avg (steady state) and L_peak (event burst).

• BCM-centric: simpler integration; risk of longer harness runs and broader wake impact if poorly partitioned.
• Zonal gateway: shortest harness and scalable clustering; requires stronger policy/logging consistency across zones.
• Domain control: good for unified service boundaries; zone responsiveness depends on backbone behavior and prioritization.

• IGN OFF: transition window into low-power policy; close open sessions and arm wake monitors.
• Sleep: only minimum monitors remain active; all nonessential buses and tasks are off.
• Partial Wake: a small “confirm set” wakes up to validate the wake source; heavy tasks are blocked.
• Full Wake: domain network and essential services come up; user-facing functions become responsive.
• Run: normal operation plus diagnostics and background services as allowed by policy.

• Local wake: button/handle/sensor triggers. Risk: noise/ESD bounce → requires debounce + plausibility check.
• Bus wake: CAN remote wake / gateway wake request. Risk: wake diffusion → requires filtering + attribution to a source frame group.
• Timed wake: periodic heartbeats/maintenance tasks. Risk: forgotten timers → requires explicit allow-list and shutdown hygiene.

• Sleep Iq (system): define measurement boundary and steady-state window; track mean and worst-case.
• Wake latency: time from wake trigger edge to “function-ready” (e.g., unlock response, courtesy light on).
• False-wake rate: wakes per time unit (e.g., per 24h) bucketed by wake reason category.
• Wake attribution: a fixed event record that answers “who woke the domain and why”.

Wake event record (recommended fields)

wake_reason · wake_source · confirm_action · confirm_result · duration_ms · next_state

1. Trigger: accept a wake event only from approved sources (local/bus/timed).
2. Confirm: execute a minimum confirm action in Partial Wake (debounce / plausibility / allow-list).
3. Escalate: only after confirm passes, bring up Full Wake (scope-limited to required clusters).
4. Return: if confirm fails or times out, return to Sleep and write a wake event record.

Signal buckets (recommended)

• State: slow-changing values (status, position); uplink at a fixed cadence.
• Event: bursts (unlock/open/lighting); uplink on change with shaping.
• Service: diagnostics/background; never allowed to starve user-visible functions.

• Input shaping: merge duplicate toggles, debounce bursts, and collapse rapid sequences into a single event.
• Output shaping: use prioritized CAN-FD transmit queues; allow defer/drop for noncritical frames under load.
• Budget visibility: define normal vs peak behavior so “unlock storms” do not become bus storms.

• Contain noisy sources: stop repeating fault spam; report health transitions once, then enter a quiet mode.
• Prevent retry storms: cap retries and throttle update frequency during degraded conditions.
• Preserve essential signals: keep a minimal “safe set” alive while isolating the failing cluster.

Recovery steps (recommended)

1. Re-sample: re-collect critical LIN states before emitting uplink deltas.
2. Mark cold start: tag the first uplink window so upstream logic does not misread it as a sudden change.
3. Gate bursts: apply temporary shaping during recovery to avoid transient spikes.
4. Restore priorities: critical UX frames resume first; service traffic follows later.

Human-perceived latency targets (placeholders)

• Unlock response: ≤ X ms
• Courtesy light on: ≤ X ms
• Panel feedback: ≤ X ms

• Periodic frames: stable refresh for core UX states; keep jitter small and predictable.
• Event window: absorb bursts (unlock/open/lighting) without disrupting periodic timing.
• Service lane: diagnostics/maintenance run only in reserved time and must yield under load.

• Sensors: mostly periodic; rare step changes should be published through the event window.
• Actuators: command/critical feedback belong to periodic (or high-priority event), noncritical telemetry can be slower.
• HMI nodes: user-driven bursts are expected; require debounce and coalescing before uplink.

• Reserve time: run diagnostics only in the service lane or a low-priority window.
• Cap bursts: apply backoff when events peak; split long service transfers into fragments.
• Protect UX: periodic and critical events must have guaranteed access to slots.

Budget placeholders (recommended)

diag_budget (per cycle) · diag_backoff (under load) · diag_fragment_size (service slicing)

• Coalesce: multiple toggles in a short window collapse into a final state update.
• Debounce/confirm: reject noise-like triggers before they hit the schedule.
• Throttle: cap event rate during storms; delay or drop low-value event frames first.

Loggable counters (placeholders)

event_bucket · event_coalesce_count · event_drop_count

• Node missing: enter a degraded schedule; publish a single health transition rather than spamming.
• Cluster instability: tighten event throttle and reduce service rate to protect periodic stability.
• Power drop: keep a minimal safe set alive; defer noncritical updates until stable recovery.

• Normal: stable periodic uplink (gateway-packed states).
• Peak: event storms (unlock/open/lighting) shaped by rate limits and coalescing.
• Diagnostic bursts: service traffic constrained by budget and backoff rules.

Placeholders for a testable peak envelope

• Storm window: W = X ms
• Peak events: E = X events within W
• Packed frames: F = X gateway frames per storm
• Backoff: throttle service and low-value events first

• Critical UX: bounded latency (unlock response, safety-relevant status) → TX Q0.
• Normal comfort: periodic refresh and noncritical events → TX Q1.
• Service: diagnostics/maintenance/log bursts → TX Q2 with backoff.

• Q0: never starved; maintains bounded latency for critical UX frames.
• Q1: deferrable under storms; may stretch update cadence within limits.
• Q2: backoff and drop allowed first; service traffic must not destabilize the bus.

Queue telemetry placeholders (recommended)

txq_depth_q0 · txq_depth_q1 · txq_depth_q2 · defer_count_q1 · drop_count_q2

• Single node fault: heartbeat missing / frozen state → local impact → isolate event bursts, keep cluster timing stable.
• Single cluster fault: error rate spikes / schedule overruns → zone impact → enter degraded schedule, throttle events, suspend service lane.
• Gateway fault: gateway alive missing / reset loops → aggregation impact → keep minimum local behavior, report a single health transition upstream.
• Power anomaly: brownout / transient drop → multi-node impact → freeze unsafe actions, rebuild state before resuming uplink.
• Wake anomaly: false wake / wake propagation → battery & UX impact → raise confirmation threshold, rate-limit wake attempts, enforce return-to-sleep closure.

Recommended observability placeholders

health_state · fault_counter · cluster_error_rate · gateway_reset_count · wake_reason

• Door lock/unlock: preserve local intent handling and avoid repeated retries; prohibit oscillation.
• Windows/sunroof: disable automation under instability; keep a safe manual path; prohibit risky unintended motion.
• Lighting: clamp event storms into coalesced updates; prohibit flicker loops and battery-drain patterns.
• HMI feedback: prefer “last-known stable state + limited refresh” over noisy rapid toggles.

• Node containment: a bad node cannot collapse the schedule or flood the cluster.
• Cluster containment: a bad cluster cannot saturate the CAN-FD backbone or trigger global wake storms.
• Gateway containment: gateway faults produce one health transition, not repeated noisy state churn.

• When to reset: deadlock, total scheduling loss, or critical health loops that cannot converge.
• Anti-storm guard: enforce cooldown and maximum resets per time window (placeholders).
• Recovery order: rebuild state → enable periodic → enable events → enable service lane last.

Guardrail placeholders

cooldown_ms · max_resets_per_hour · state_rebuild_timeout_ms

• Long trunk + branches: common-mode conversion and return-path discontinuities drive emissions and fragility.
• Connector hot-plug: transient injection and contact bounce can look like events or wake sources.
• Human touch & ESD: direct discharge at handles/panels produces sharp current paths into the harness.
• Ground offset: imperfect chassis reference creates ground bounce and threshold surprises.

• Return path continuity: plan where current returns (shield/chassis/reference) across connectors and branches.
• Entrance protection intent: place protection where the surge enters, and ensure a short, low-inductance return.
• Reference stability: avoid letting a noisy return path redefine logic thresholds during transients.

• Protection too far from the entry: the surge travels on the board first → later clamping does not protect logic.
• Long return to ground: clamp current loops through inductive paths → ground bounce creates false triggers.
• Parasitics treated as “free”: extra C/L distorts edges → intermittent mis-detect and wake anomalies.

• Log during ESD/hot-plug: correlate wake_reason, fault_counter, and cluster/backbone error counters.
• Post-event fragility checks: verify the system does not become “more fragile” after a surge.
• A/B path experiments: change the return path geometry and confirm symptom shift before changing components.

Minimal log fields (placeholders)

event_time · injection_point · wake_reason · cluster_error_rate · fault_counter

• Source: node_missing / schedule_overrun / cluster_error_rate / local_reset (placeholders).
• Normalize: severity, scope, debounce window, confirmation result.
• Aggregate: merge repetitive signals into one stable event per zone/cluster.
• Publish: CAN-FD event + DTC + snapshot + counters, with bounded rate.

• Class A — Battery drain / wake anomalies: prioritize wake attribution and false-wake counters.
• Class B — Functional degraded: stable fallback behavior + cluster health snapshots.
• Class C — Intermittent observation-only: log + counters, avoid aggressive actions.
• Class D — Infrastructure faults: gateway resets, persistent cluster errors, mapping integrity alarms.

Required fields (minimum viable record)

wake_reason · wake_source · timestamp_start · timestamp_end · duration_ms · debounce_ms · confirm_pass

Optional fields (high value for root-cause)

cluster_id · node_id · battery_v · temp · reset_reason · injection_point

• bus_utilization: average/peak window (placeholders) for storm detection.
• error_counters: cluster-level and backbone-level deltas per time window.
• reset_reason_count: track reset causes and recurrence rate.
• false_wake_count: per wake_source and per wake_reason.
• event_drop/defer: queue shaping visibility (why some events were delayed or collapsed).

• Bench: reproducible harness emulation, hot-plug/ESD injection, power-state entry/exit measurements.
• Vehicle: real harness, real concurrency, false-wake statistics across environment boundaries.
• Production: fast screening, configuration/version lock, mandatory log fields exported.

• Harness emulation: trunk/branch variants (placeholders) to reproduce branch-driven fragility.
• Hot-plug + ESD: verify wake attribution, confirmation gating, and post-event fragility checks.
• Sleep current definition: entry conditions, stabilization wait time, and instrument connection intent.
• Black box completeness: ensure required fields are always recorded.

• False-wake rate: track by wake_source and wake_reason (placeholders per day).
• Boundary matrix: temperature/voltage corners and soak transitions.
• Concurrency storms: multi-door actions, lighting bursts, seat adjustments; verify rate shaping and containment.
• Containment proof: one bad cluster cannot destabilize the rest of the domain.

• Fast screening: wake chain sanity, counter readout, reset reason visibility.
• Version/config lock: ensure calibration and mapping tables match the build identity.
• Mandatory exports: wake black box record schema + key counters (same field names).
• Failure tagging: tag by symptom class to support fast rework and yield analytics.

• Sleep is measurable: system Sleep Iq is repeatable and attributable (wake reasons never “unknown”).
• Wakes are intentional: false-wake rate is bounded; wake latency has a defined budget.
• Faults are contained: a single LIN cluster failure does not cascade to the CAN-FD backbone.
• Service is actionable: DTC mapping + wake “black box” fields enable field diagnosis.

• LIN interface: LIN transceiver or LIN “SBC-like” device with regulator/wake support.
• CAN-FD backbone interface: CAN-FD transceiver (plus PN/selective wake if required).
• System Basis Chip: regulators + watchdog + wake I/O + (optionally) CAN/LIN transceivers integrated.
• Gateway controller: MCU with enough CAN/LIN channels, low-power modes, safety/security hooks.
• Protection: low-cap TVS/ESD arrays suitable for bus lines (matched where needed).

Shortlist buckets (example material numbers; non-exhaustive)

Use these as reference “known-good families” to match integration level and wake/diagnostics expectations. Exact grade/package variants follow OEM requirements.

• PHY timing (sample point, loop delay tuning) belongs to the CAN-FD transceiver page.
• LIN electrical behavior (slew/ESD wave shaping details) belongs to the LIN transceiver page.
• EMC/TVS/CMC selection math belongs to the EMC / Protection pages.

Sleep Iq spikes sporadically — wake storm or a cluster never actually sleeps?

Likely cause: repeated wake triggers (bus/local/timed) or one LIN cluster stuck “awake” due to a node that never reaches sleep-ready.

Quick check: compare wake_reason histogram + cluster_awake_flags; confirm whether spikes align with false_wake_count or persistent LIN activity in one cluster.

Fix: add confirm gate (debounce + second condition), enforce cluster sleep handshake (sleep-ready ACK), and rate-limit repeated wake attempts per source.

Pass criteria: system Sleep Iq ≤ X mA after settle T_settle=Y s, measured over W=Z s, with 0 “unknown” wake reasons in the same window.

Sleep current varies run-to-run — measurement artifact or periodic wake activity?

Likely cause: current measured before rails settle, or periodic timed wakes (heartbeat / maintenance tasks) polluting the measurement window.

Quick check: log mode_state timeline + wake_reason=timed frequency; repeat measurement with a longer T_settle and the same fixed window W.

Fix: standardize the Sleep Iq procedure (enter-final-sleep → settle → sample) and move timed activities to an explicit “partial-wake” budgeted mode.

Pass criteria: sleep mean within ±X% across N repeats (same harness, same temperature), and timed wakes ≤ Y per 24h in the configured sleep mode.

Battery drain persists even though Sleep Iq “passes” — what accounting check first?

Likely cause: rare wake bursts (false wakes) or an always-on rail/peripheral not covered by the “Sleep Iq” measurement setup.

Quick check: correlate battery drain with false_wake_count and wake_duration_ms; audit rails: verify “sleep” disables all non-essential regulators and peripherals.

Fix: enforce rail gating policy, add a “sleep audit” self-check (report enabled rails), and improve attribution so every wake has a source and duration.

Pass criteria: drain rate ≤ X mAh/day under a defined parking script; wake attribution completeness ≥ 99.9% with per-wake duration_ms recorded.

False wakes increase mainly in winter — ESD/grounding or debounce/confirm policy?

Likely cause: dry-air ESD coupling into wake inputs/harness, or debounce too short with no second-stage confirmation.

Quick check: compare wake_reason distribution winter vs normal; check if wakes are dominated by a single input and fail confirmation (confirm_result=false).

Fix: strengthen confirm logic (two-condition or time-separated confirm), harden wake input filtering, and ensure return path/ground reference is stable for wake sensing.

Pass criteria: false wakes ≤ X/24h under a defined winter/ESD interaction script; confirm-fail wakes auto-return to sleep within Y ms.

Wake source often shows “unknown” — what attribution chain is missing?

Likely cause: missing instrumentation between wake entry and the first runnable; wake interrupts cleared before logging; or multiple sources racing.

Quick check: verify early capture of wake_source and debounce_ms before any clearing; check for concurrent flags and ordering.

Fix: implement “first-event wins” latch + timestamp, store raw wake flags, and log both raw_source and resolved_source after confirmation.

Pass criteria: unknown wake reasons ≤ X per 10,000 wakes; raw and resolved sources always present in the wake record.

CAN-FD errors during concurrent door + lighting events — gateway rate shaping or load budget?

Likely cause: event storm overwhelms gateway TX queues (burst aggregation) or peak CAN-FD utilization exceeds the budgeted threshold.

Quick check: capture bus_utilization_peak% + gateway_drop_count/defer_count during the storm script; verify if errors correlate with queue depth saturation.

Fix: add token-bucket rate limiting, coalesce events into bounded updates, and isolate critical comfort frames from diagnostic/maintenance traffic.

Pass criteria: peak utilization ≤ X% under the defined storm script; drops ≤ Y per run; comfort-critical frames meet latency ≤ Z ms.

Rate limiting reduced errors but added noticeable lag — did latency budget or priority isolation get stolen?

Likely cause: shaping applied uniformly (including comfort-critical signals), or low-priority bursts still block higher-priority traffic due to queue policy.

Quick check: split latency by signal class (comfort-critical vs non-critical); inspect per-class queue wait time and whether shaping hits critical IDs.

Fix: apply class-based shaping (strict limits on non-critical bursts), reserve queue slots for critical signals, and enforce priority-aware scheduling.

Pass criteria: critical path latency ≤ X ms (p95) while peak utilization remains ≤ Y% under the same storm script.

Diagnostics / OTA bursts cause comfort glitches — budgeting issue or missing queue isolation?

Likely cause: diagnostic traffic not budgeted for peak windows, or gateway uses a shared queue where diagnostics starve comfort signals.

Quick check: compare comfort latency and bus_utilization with diagnostics on/off; check if diagnostic IDs dominate queue occupancy.

Fix: isolate diagnostics into a lower-priority lane, enforce burst caps, and schedule diagnostic windows away from peak user interactions.

Pass criteria: comfort KPIs unchanged with diagnostics enabled: latency delta ≤ X ms, error counters not increased beyond Y per hour.

After a gateway reset, comfort states look wrong — state rebuild bug or LIN schedule not synchronized?

Likely cause: gateway restarts without rehydrating last-known state, or it resumes publishing before LIN schedule/cluster discovery is stable.

Quick check: examine restart sequence timestamps: reset_reason, first publish time, first valid cluster snapshot time; confirm if published values precede valid reads.

Fix: implement “safe boot” sequence: rebuild state from stored snapshot + re-sync clusters + publish only after validity flags are true.

Pass criteria: after reset, invalid/placeholder publishes = 0; full state consistency achieved within X ms with no user-visible misbehavior.

Latency became obvious after adding LIN nodes — schedule period too long or diagnostics crowding the bus?

Likely cause: periodic schedule length grew beyond the comfort responsiveness target, or diagnostic/service frames consume slots during peak interactions.

Quick check: compute effective update interval per signal class; compare “periodic only” vs “with diagnostics” timing under the same interaction script.

Fix: re-partition schedules (separate fast/slow groups), move diagnostics to off-peak windows, and use event windows for bursty actions.

Pass criteria: comfort-critical signals update ≤ X ms (p95); diagnostics adds ≤ Y% overhead to schedule length.

One LIN cluster fault drags the whole domain down — containment boundary missing or retry storm after failures?

Likely cause: gateway retries saturate CPU/queues, or cross-cluster coupling exists (shared resources) so one cluster blocks others.

Quick check: compare per-cluster counters: missing-node counts, schedule overruns, gateway queue depth; verify if failures align with retry loops or watchdog resets.

Fix: enforce per-cluster isolation (timeouts, circuit breakers), cap retries, and degrade locally while keeping the backbone stable.

Pass criteria: when one cluster is fault-injected, other clusters remain within latency ≤ X ms and CAN-FD errors ≤ Y per hour; no reset storm (≤ Z resets/day).