• Inputs: in-vehicle frames (CAN/LIN/FlexRay/Ethernet), diagnostic sessions (DoIP/service tool), OTA campaigns, security policies, timing base.
• Outputs: policy-compliant forwarding/bridging, bounded latency/throughput behavior, auditable security events, traceable diagnostic logs, OTA state transitions with recovery.
• Deliverables: architecture boundary map, rule tables (filter/limit/route), minimal observability schema (fields + counters), verification hooks.

• Classification keys: bus type, source ECU, service class (control / diagnostics / OTA / logging), and safety criticality.
• Queue model: dedicate queues per service class; protect real-time control from diagnostic bursts via strict priority or minimum service.
• Rate limiting: enforce per-session/per-source caps; apply backoff to misbehaving testers to avoid starvation and watchdog resets.
• Congestion policy: define drop order (e.g., bulk logs before control), and record drops with reasons for field analysis.
• Fault containment: circuit-breaker rules for repeated timeouts/resets; isolate the port rather than rebooting the entire gateway.

Diagnostic/OTA incidents are rarely reproducible without a consistent schema. Define a minimal field set and enforce it across sessions.

• Session: session_id, tester_id, auth_level, start/stop timestamp, timeout reason.
• Routing: rule_pack_version, mapping_id, source_port, dest_port, action (forward/drop/shape).
• Performance: queue_id, queue_depth_peak, drop_count, p99_latency (X ms), throughput (X Mbps).
• Security: cert_version, key_id, policy_decision, violation_type, audit_id.
• Reliability: reboot_cause, watchdog_stage, power_event_flag, recovery_state.

• Allowed: “port type, throughput class, error model, wake/sleep impact, diagnostics session behavior”.
• Forbidden: “sample point, termination components, SIC waveform symmetry, TVS/CMC parasitic tuning”.
• Action: when forbidden terms appear, provide a one-line context and link to the dedicated PHY/EMC page.

• Filter keys: port, source ECU, service class (control / diagnostics / OTA / logs), and session identity.
• Admission control: bound concurrent diagnostic sessions; reject excess sessions with a reason code and audit log.
• Rate caps: apply per-session and per-source limits; add backoff when repeated timeouts indicate retry storms.
• Congestion policy: define drop order that protects control traffic; record drop reason for field triage.
• Safe defaults: unknown traffic is shaped or denied (never broadcasted) and always audited.

• Service-class queues: Control / Diagnostics / OTA / Logs as the primary split.
• Fairness knobs: per-ECU or per-session sub-queues to prevent single-source starvation.
• Scheduling: strict priority or minimum-service guarantees for control; diagnostics are shaped, not “randomly dropped”.
• Explainability: every throttle/drop should map to a policy rule and emit a reason code.

• Isolation domains: by port, by session, and by service class (preferred for service stability).
• Circuit breaker states: Closed → Open → Half-open; transitions require explicit reasons and timers.
• Degrade modes: keep control + restrict diagnostics + pause OTA; or service-only mode for recovery.
• Auditability: every isolation event produces an audit_id and correlates with queue and session metrics.

Implementation rule: every forward/drop/shape decision must be attributable to a single policy row and emit a stable reason code.

• Session overload: too many concurrent sessions or retries can starve control traffic; check admission counters and queue watermarks first.
• Mapping drift: address-table version mismatch can look like random timeouts; verify mapping_id and rule_pack_version alignment.
• Policy mismatch: an auth-level downgrade may cause silent rejects; require explicit reason codes and audit IDs.
• Resource collapse: CPU/memory spikes or encryption overhead can trigger watchdog resets; correlate session events with health logs.

• Goal: translate DoIP-side logical addressing into stable target identities without ambiguity.
• Versioning: every mapping must carry mapping_id and rule_pack_version for field correlation and rollback.
• Conflicts: duplicates and gaps must resolve to safe defaults (reject/shape + audit) rather than “best-effort forward”.
• Self-check: validate coverage, uniqueness, and default actions before enabling service mode in production.

• Read-only: lowest risk, still requires session identity and rate limits.
• Write: requires elevated auth_level and strict per-target quotas; reject is never silent.
• Programming/flash: highest risk; enforce strong authorization, maintenance mode constraints, and mandatory audit trails.
• Reject behavior: always return a stable reason_code and record an audit_id with timestamps and latency.

• Time: timestamp (unified timebase), duration/latency_ms.
• Session: session_id, tester_id, auth_level, start/stop reason.
• Target: target_ecu, logical_addr, physical_addr (or stable target ID).
• Operation: service_id, payload_len, status (ok/fail/timeout/reject), reason_code.
• Resources: queue_id, queue_depth, drop_count_delta, throttle_events.
• Versions: rule_pack_version, mapping_id, cert_version (if applicable).

• Campaign: define target set, allowed windows, rollout groups, and dependency rules as a versioned contract.
• Download: chunked transfer with resume; rate caps protect control traffic under weak links.
• Verify: signature and hash checks; reject on mismatch with explicit reason codes and audit IDs.
• Install: write to staging/A-B slot; keep the current image untouched until activation is safe.
• Activate: switch pointers/slots via an atomic flag; ensure a deterministic boot path.
• Confirm: commit only after health signals pass; otherwise trigger rollback or safe service mode.

• Durable progress: each step persists minimal fields to resume or roll back without guessing.
• Atomic boundaries: define where interruption is allowed (download, staged install) vs guarded (activate switch).
• Restart rules: on reboot, recover from the last durable state and follow deterministic transitions.
• Failure semantics: verification failures never activate; install failures keep the old image bootable.

• Triggers: boot-loop counters, health-check failure, missing critical services, or explicit negative confirmation.
• Confirm window: commit only after stable operation across defined cycles/time; otherwise rollback automatically.
• Non-rollback cases: if rollback is disallowed (e.g., mandatory security update), fail into a restricted safe mode with full diagnostics.
• Auditability: every rollback records audit_id, reason_code, and the last known durable state.

• Version matrix: define compatible sets and minimum versions; reject activation when dependencies are not satisfied.
• Ordering: enforce explicit sequences per domain role (gateway services, targets, then optional modules) with rollback points.
• Stop-loss: if any critical ECU fails, pause the campaign and keep the vehicle in a known serviceable mode.
• Confirm scope: confirmation checks both ECU health and dependency satisfaction as a whole.

Implementation rule: durable fields must be sufficient to determine the next state after reboot without heuristic guesses.

• Campaign: campaign_id, target_set_hash, rollout_group, policy_window
• Download: package_id, received_ranges, bytes_done, chunk_hash_state
• Verify: signature_ok, hash_ok, verified_version, audit_id
• Install: staging_slot, write_offset, install_progress, install_result
• Activate: next_boot_slot, activation_flag, activation_time
• Confirm: confirm_deadline, health_signals, confirm_result, reason_code
• Audit: audit_id, mapping_id, rule_pack_version (for correlation with gateway policies)

• Secure boot: establishes a trusted software identity for the gateway/TCU runtime.
• HSM/root key: anchors cryptographic operations; private roots remain non-exportable.
• Runtime identity: produces stable device_id/cert_id used by sessions and policy decisions.
• Policy tie-in: identity + session attributes map to allow/deny/shape decisions with audit IDs.

• Lifecycle: issue → activate → rotate → revoke/expire with explicit ownership and audit trails.
• Rotation: time-based and event-based rotation; support rollback of configuration but not of root identity.
• Revocation: define behavior on expired/revoked credentials (restricted mode vs deny-all) by policy.
• Factory injection: bind identity to hardware roots; record injection batch and provisioning version.
• Service updates: update credentials in service mode without breaking diagnostics access.

• Termination point: terminate at the gateway for fine-grained audit/policy, or upstream for simplified roles; make it explicit.
• Certificate ownership: define who rotates and who revokes; enforce a single source of truth for cert versions.
• Failure semantics: handshake failure routes to restricted mode or deny by policy; never fall back silently.
• Audit: record peer_id, cert_id, channel, and reason_code for every deny or downgrade.

• Network allowlist: permitted peers, ports, and services; default deny for unknown traffic.
• Diagnostics privilege: read/write/flash mapped to auth_level; enforce quotas per session and per target.
• OTA authorization: campaign must be signed/approved; activation depends on dependency satisfaction and policy windows.
• Domain isolation: cross-domain flows require explicit permits; log every cross-boundary decision.

• Rate anomalies: sudden spikes per peer/service; link to throttling and circuit-breaker triggers.
• Session anomalies: abnormal failures, timeouts, or concurrency patterns; tie to admission gates.
• Replay-like patterns: repeated identical requests in short windows; enforce policy-based rejection and auditing.
• Actionability: anomaly signals must trigger degrade/isolation/audit escalation instead of being passive dashboards.

• Fail-Operational: preserve a minimal set of essential functions under fault, typically via controlled degradation.
• Fail-Silent: stop emitting potentially harmful effects, isolate external connectivity, and block cross-domain propagation.
• Per-function decision: control, diagnostics, OTA, and external connectivity do not share the same allowed outcome.
• Evidence requirement: every degrade/isolate decision must be explainable with audit_id and reason_code.

Implementation note: safety objectives must map to explicit degraded modes; “undefined behavior” is treated as a design failure.

• Deadlock / stalls: heartbeat gaps, scheduling delay spikes, and unresponsive service endpoints.
• Memory pressure: heap high-watermark, allocation failures, handle growth, and leak-rate estimates.
• Queue blockage: queue depth saturation, tail latency, drops, and backpressure trigger counts.
• Session health: abnormal timeouts, failed handshakes, and runaway concurrency.

• Connector / shield: define the physical entry and shield bonding point(s).
• Surge layer: manage energy and return paths; keep surge loops out of sensitive signal ground.
• ESD layer: clamp fast events close to the entry; minimize inductive distance to the return path.
• Common-mode layer: suppress radiated/common-mode energy before the clean IC domain.
• Clean domain: keep protocol ICs inside a clearly defined “quiet zone” behind the protection stack.

• Keep “dirty return” away: ESD/surge return must not traverse sensitive digital/analog reference regions.
• Shield continuity: bonding must be explicit; floating or intermittent shield connections often amplify emissions.
• Single controlled tie: define where clean reference and chassis/body ground connect (if required), and keep it deterministic.
• Black-box logging: record port, trigger type, and the resulting action (reset/isolate) for service correlation.

• Slower edges: reduce emissions but shrink timing margin and increase sensitivity to noise and loading.
• Stronger drive: improves robustness but can increase crosstalk and radiated energy.
• Policy table: define profiles by harness class (length, node count, environment) and validate against a fixed checklist.

• Uncontrolled ground potential differences: domains with unpredictable reference offsets across operating conditions.
• High disturbance interfaces: external-facing ports or long harness segments with strong coupling risk.
• Security partitioning: boundaries where external connectivity must not influence safety-critical domains.
• Fault containment: when a single-port event must not impact the rest of the network.

Diagram intent: visualize protection layering at the connector and emphasize return-path direction without waveform-level details.

• Ingress: first observable entry point until classification begins (driver scheduling included).
• Classify: policy match (routing/ACL/session) and rule-pack lookup decision.
• Queue: waiting time under contention; often the dominant term in P99 latency.
• Process: forwarding/encapsulation, copy count, crypto checks, and log field assembly.
• Egress: shaping, rate limiting, and transmission scheduling to the next hop.

• CPU budget: packet/session management, policy evaluation, crypto checks, and logging pipeline overhead.
• Memory budget: session state, buffers, queue depths, retry windows, and log staging buffers.
• Copy budget: copy count is a primary multiplier for CPU and memory bandwidth under OTA payloads.
• Storage budget: write/flush policies can dominate tail latency; measure it explicitly as a stage.

• Traffic classes: Control / Diagnostics / OTA / Telemetry must not share a single “best-effort” queue.
• Watermarks: define low/high thresholds per queue to trigger shaping and admission control.
• Backpressure: reject new sessions, delay non-critical transfers, and rate-limit at the boundary.
• Drop rules: drop-by-class and drop-by-session to prevent one client from starving critical services.
• Containment: circuit breakers for floods; avoid retry/log storms that amplify congestion.

• Latency: P50/P95/P99 per stage and end-to-end, plus tail-spike counts (above X ms).
• Throughput: sustained (Y minutes) and peak (Z seconds) with resource headroom recorded.
• Sessions: max concurrent sessions with handshake success and timeout rate thresholds.
• Congestion: queue depth distribution, drop rate, and backpressure trigger counts.
• Stability: degrade/recover counts and recovery time after congestion or stress.

• Latency: end-to-end P99 ≤ X ms; stage-level P99 ≤ X ms (Queue must remain bounded).
• Sessions: max concurrent sessions ≥ X with timeout rate ≤ Y% over Z minutes.
• Throughput: peak ≥ X Mbps and sustained ≥ X Mbps while CPU ≤ Y% and memory ≤ Z%.
• Loss/timeout: drop ≤ X/1k and timeout ≤ X/1k per traffic class.
• Recovery: congestion recovery ≤ X s and no mode oscillation above X/hour.

• Inputs: architecture boundary, policy tables, minimum log fields, key/cert policy, state machines, performance budget.
• Checks: deny-by-default rules, explicit exceptions, audit fields completeness, persistence points, budget measurability.
• Outputs: frozen config_version / rule_pack_version, acceptance draft (pass criteria placeholders).
• Evidence: review record, signed tables, baseline workload definition (workload_id).

• Inputs: test tools, logging pipeline, workload profiles, congestion tests, fault-injection matrix.
• Checks: session stability, pressure and congestion behavior, P99 within budget, recovery actions verified end-to-end.
• Outputs: baseline performance report (run_id), known-good config, validated degraded-mode behavior.
• Evidence: P99 report, queue stats report, fault-injection report, recovery timing report.

• Inputs: release bundle, cert injection flow, station self-test, traceability schema.
• Checks: config/cert version alignment, self-test coverage, consistent pass criteria validation, audit attribution fields.
• Outputs: trace bundle (device_id, config_version, cert_version), factory pass report.
• Evidence: station logs, regression comparison report, sampling audit report.