diff --git a/ROADMAP.md b/ROADMAP.md index 03632be..a88b6b8 100644 --- a/ROADMAP.md +++ b/ROADMAP.md @@ -1,27 +1,111 @@ # cpp-RCP Roadmap +## Status: Full Protocol Replacement — Breaking Changes Ahead + +A conformance gap analysis against the real industry specification this +project is named for — the OPEN Alliance TC18 Remote Control Protocol +("RCP") — found that cpp-RCP's existing implementation shares **nothing at +the wire level** with that specification. What exists today is a +self-consistent but entirely home-grown protocol: a `Zone` enum addressed +`Command`/`Response`/`Status` model over a bespoke 16-byte header, plus +roughly forty satellite packages (discovery, power-state management, +watchdog, an ad-hoc E2E CRC wrapper, priority queueing, and protocol bridges +to CAN/LIN/DoIP/UDS/SOME-IP/MQTT/DDS/gRPC/REST) built on top of it. + +This roadmap plans a **full replacement**, not an incremental gap-patch: the +goal is for cpp-RCP's `RCP` to eventually **be** the OPEN Alliance TC18 +Remote Control Protocol, wire-compatible with other conformant +implementations, rather than a look-alike with a similar name. That is a +deliberate, explicit decision — spelled out here so it is not a surprise +later. + +**This breaks every current consumer of the library.** `rcp::Zone`, +`rcp::Command`, `rcp::CommandType`, `rcp::Response`, `rcp::Status`, the +16-byte wire frame in `rcp/wire.hpp`, and the `Controller`/`Registry` +interfaces in `rcp/rcp.hpp` do not exist in the target protocol and will be +removed, not deprecated-and-kept. Anything — application code, the CLI, the +protocol bridges, the RELAY adapter — that sends a `Command` to a `Zone` and +gets back a `Response` will need to be rewritten against the new +request/endpoint model described below. There is no incremental migration +path at the API level because the two protocols do not share a wire format, +an addressing scheme, or a data model to migrate incrementally *between*. + +**No compatibility shim is planned, and that is a deliberate call, not an +oversight.** A shim mapping `Zone`/`Command`/`Response` onto TC18's +`stream_id`/`byte_bus_id`-addressed endpoint requests would have to either +(a) silently drop protocol semantics that have no equivalent on the other +side — dangerous in a codebase that targets ISO 26262 ASIL-B — or (b) +become a second protocol implementation that has to be maintained forever +alongside the real one, which defeats the entire point of this replacement. +cpp-RCP has no external fleet of already-deployed zone controllers speaking +the old protocol that this repository is aware of; this is a greenfield +rewrite relative to the real spec, not a live migration. If that changes, +a shim should be reconsidered explicitly at that time — it is not being +ruled out forever, just not built speculatively now. + +Traceability note: detailed field names, register layouts, and behavior +described below come from an internal structured extraction of the OPEN +Alliance TC18 Remote Control Protocol Specification v0.5.1_RC prepared for +this effort. Section numbers cited in parentheses (e.g. "extraction §3.2") +refer to that internal document's own section numbering for traceability +during implementation review, not to page/section numbers in the OPEN +Alliance document itself. + +--- + ## Vision -cpp-RCP is a C++17-native Remote Control Protocol for automotive zonal architecture. +cpp-RCP is a C++17-native implementation of the OPEN Alliance TC18 Remote +Control Protocol. The project focuses on: -- Reliable command delivery from a central computer to distributed zone controllers -- Safety-first design with traceability to ISO 26262 ASIL-B requirements -- Modern C++ developer experience — header-only core, pure interfaces, swappable transports +- Wire-level conformance with the real TC18 specification — an RC Client + built on this library and an RC Server built on any other conformant + implementation must interoperate +- Safety-first design with traceability to ISO 26262 ASIL-B requirements, + carried forward from the pre-replacement codebase and re-scoped to the + new requirement set as each phase lands +- Modern C++ developer experience — header-only core, pure interfaces, + swappable transports (native IEEE 1722 over Ethernet, IEEE 1722 over + UDP/IP, or CAN(FD/XL) as the underlying network) - Deterministic latency suitable for hard real-time automotive contexts -- Observability by default — metrics, heartbeats, and watchdog support built in - ---- +- Observability and safety mechanisms by default, rebuilt on the + spec's own primitives (per-stream watchdog, E2E CRC safe points, sequencer + state) rather than bespoke ones ## Guiding Principles -1. Pure C++17 first — no OS-specific headers in core interfaces -2. Safety as a first-class concern — requirements in `.fusa-reqs.json`, traced to tests -3. Simplicity over completeness — clean interfaces, not a protocol kitchen sink -4. Testability by default — mock backend ships with the library -5. Zonal architecture native — Zone is a first-class type, not an afterthought -6. Transport-agnostic — swap in-process mock for UDP or TLS without API changes +1. Conformance first — every core-protocol phase below is scoped directly + from the specification, not from what the old implementation happened + to already do +2. Pure C++17 first — no OS-specific headers in core interfaces +3. Safety as a first-class concern — requirements in `.fusa-reqs.json`, + traced to tests; re-derived against the new protocol surface rather than + patched onto the old one +4. Dependency-ordered delivery — nothing in a later phase is built before + the phase it depends on is usable (see sequencing rationale below) +5. Explicit about what's optional — the specification itself marks several + features optional for "RCP version 1.0" (fragmentation; most conditional + request kinds; enhanced cancellation); this roadmap makes an explicit, + justified go/no-go call on each rather than silently deferring them +6. Every satellite package gets an individual decision — no package is + carried forward, dropped, or rewritten by default; see the disposition + table near the end of this document + +## Sequencing Rationale + +The phase order below follows the conformance-priority guidance produced +during the gap-analysis extraction (extraction §9): the three highest-impact +structural changes are the RC Server lifecycle state machine, the discovery +mechanism, and the E2E/safe-state mechanism, because nearly everything else +in the specification — register locking, request validation, error +handling — assumes those three already exist. Endpoint types are then +sequenced simplest-first (GPIO/SPI before UART/ADC's multi-field payloads, +before LIN/CAN/ISELED's raw-bus-passthrough model), and the register-map +reorganization (generic vs. functional config split) is treated as a +mechanical but pervasive refactor that has to land before *any* endpoint +work, since every endpoint type's functional config block depends on it. --- @@ -29,434 +113,627 @@ The project focuses on: | Phase | Version | Theme | Summary | |---|---|---|---| -| **Foundation** | v0.1.0 | Foundation | Core interfaces, mock backend, CI, cpp-FuSa, Docker quickstart ✅ | -| **Foundation** | v0.2.0 | Requirements | 198 atomic SEOOC ASIL-B requirements, full cpp-FuSa coverage ✅ | -| **Safety groundwork** | v0.3.0 | Hardening | Mock correctness fixes, benchmarks, safety timing evidence ✅ | -| **Safety groundwork** | v0.4.0 | HARA expansion | Comprehensive hazard analysis H-001..H-010, SG-001..SG-010 ✅ | -| **Transport stack** | v0.5.0 | UDP transport | Pure-C++ UDP command/response transport with zone discovery ✅ | -| **Transport stack** | v0.6.0 | mDNS discovery | Zero-configuration zone controller discovery via mDNS/DNS-SD ✅ | -| **Transport stack** | v0.7.0 | TLS transport | Mutual TLS channel for zone-controller communication ✅ | -| **Transport stack** | v0.8.0 | Shared memory | Zero-copy intra-host command delivery via shared memory ✅ | -| **Transport stack** | v0.9.0 | Loaned samples | LoaningController interface extending zero-copy to all transports ✅ | -| **Transport stack** | v0.10.0 | TSN transport | IEEE 802.1Qbv-aware UDP transport for hard real-time Ethernet delivery ✅ | -| **Safety mechanisms** | v0.11.0 | Watchdog & heartbeat | CmdWatchdog scheduling, zone health state machine, liveness API ✅ | -| **Safety mechanisms** | v0.12.0 | Deadline monitoring | Zone-to-HPC liveness: alert when Status stops arriving within deadline ✅ | -| **Safety mechanisms** | v0.13.0 | Power state | CmdSleep/CmdWake, zone power state machine, bus-off recovery ✅ | -| **Safety mechanisms** | v0.14.0 | E2E protection | Sequence counter, CRC-16, replay guard on command frames ✅ | -| **Safety mechanisms** | v0.15.0 | Priority queuing | Per-zone priority queue honouring PriorityCritical/High/Normal ✅ | -| **Safety mechanisms** | v0.16.0 | Rate limiting | Per-zone token-bucket admission control against command flooding ✅ | -| **Verification** | v0.17.0 | Zone simulator | Timing-realistic zone controller simulator for SiL/HIL testing ✅ | -| **Verification** | v0.18.0 | Fault injection | Structured fault injection to validate watchdog, E2E, and replay-guard mechanisms ✅ | -| **Security** | v0.19.0 | Authorization | Command-level access control; ISO 21434 SL-2 policy enforcement ✅ | -| **Security** | v0.20.0 | Firmware update | CmdUpdate and `firmware/` module for zone controller OTA delivery ✅ | -| **Topology** | v0.21.0 | Zone groups | Atomic multi-zone command broadcast with typed zone group sets ✅ | -| **Topology** | v0.22.0 | Zone proxy | Transparent zone proxy for multi-hop zonal topologies ✅ | -| **Topology** | v0.23.0 | Redundancy | Hot-standby Registry and HPC failover for ASIL-B fault tolerance ✅ | -| **Topology** | v0.24.0 | Multi-HPC federation | Multi-HPC active coordination over shared zone bus ✅ | -| **Tooling** | v0.25.0 | Observability | OpenTelemetry traces and Prometheus metrics adapter ✅ | -| **Tooling** | v0.26.0 | Admin API | HTTP admin interface for runtime registry inspection and control ✅ | -| **Tooling** | v0.27.0 | Record & replay | Record command/response/status streams to disk; replay for regression and forensics ✅ | -| **Tooling** | v0.28.0 | Config | YAML/JSON zone registry configuration ✅ | -| **Tooling** | v0.29.0 | Code generation | Zone manifest schema; generator interface stub ✅ | -| **Tooling** | v0.30.0 | Dynamic data | Runtime schema registry and typed payload codec for schema-less command payloads ✅ | -| **Remote access** | v0.31.0 | gRPC bridge | gRPC transport interface stub ✅ | -| **Remote access** | v0.32.0 | REST bridge | HTTP/SSE bridge interface stub ✅ | -| **Protocol bridges** | v0.33.0 | SOME/IP bridge | Bridge RCP commands to SOME/IP service methods (stub) ✅ | -| **Protocol bridges** | v0.34.0 | CAN bridge | Bridge RCP commands to CAN frames (stub) ✅ | -| **Protocol bridges** | v0.35.0 | DDS bridge | Bridge RCP Status to DDS topics (stub) ✅ | -| **Protocol bridges** | v0.36.0 | MQTT bridge | Bridge RCP Status to MQTT topics (stub) ✅ | -| **Protocol bridges** | v0.37.0 | LIN bridge | Bridge RCP commands to LIN frames (stub) ✅ | -| **Protocol bridges** | v0.38.0 | UDS bridge | Bridge RCP commands to ISO 14229 UDS service calls (stub) ✅ | -| **Protocol bridges** | v0.39.0 | DoIP bridge | Bridge zone controller diagnostics over ISO 13400 (stub) ✅ | -| **Platform** | v0.40.0 | RTOS / bare-metal | C API (`capi.h` + `capi_impl.hpp`) for Zephyr/FreeRTOS targets ✅ | -| **Certification** | v0.41.0 | Formal verification | TLA+ specs for health SM, watchdog protocol, anti-replay guard ✅ | -| **Certification** | v0.42.0 | ISO 21434 | TARA-ANALYSIS.md, CYBERSECURITY.md, IEC 62443 SL-2 gap analysis ✅ | -| **Certification** | v0.43.0 | Certification | ASIL-D gap analysis, structural coverage report, AUDIT_PACK.md ✅ | +| **Phase 13** | v2.0.0 | Wire format core | IEEE 1722 AVTPDU/NTSCF/TSCF framing, ACF_ABB/ACF_GBB, `byte_message_info` header, stream/byte_bus_id addressing | +| **Phase 13** | v2.1.0 | RC Server lifecycle | 3-state lifecycle machine, register-map model, generic/functional config split, EP0 | +| **Phase 13** | v2.2.0 | Discovery | Discovery request/response, discovery-stream claiming, `Discovery_TimeOut` | +| **Phase 13** | v2.3.0 | Basic endpoints I | GPIO and SPI — simplest request/response shapes | +| **Phase 13** | v2.4.0 | Basic endpoints II | I²C, UART, ADC, PWM_OUT, PWM_IN | +| **Phase 13** | v2.5.0 | Conditional requests | Compound / compound-wait / triggered / chained / timed requests, sequencers | +| **Phase 13** | v2.6.0 | E2E safe points | CRC32 safe-point mechanism, safety-request (`0x8x`) variants, per-stream watchdog/safe-state config | +| **Phase 13** | v2.7.0 | Remaining endpoints | LIN, CAN (incl. CAN XL), ISELED, MDIO, Wakeup control; DAC explicitly out of scope | +| **Phase 13** | v2.8.0 | Fragmentation decision | Explicit go/no-go call — **no-go for this cycle** (see rationale) | +| **Phase 14** | v2.9.0 | Power management rebuild | Normal/StandBy/Sleep/Unpowered model, cold/hot start, replaces `powerstate.hpp` | +| **Phase 14** | v2.10.0 | Watchdog & liveness rebuild | Per-stream watchdog config replaces the `CommandType::Watchdog` client-kick model | +| **Phase 14** | v2.11.0 | Authz & admission rebind | `authz.hpp`, `ratelimit.hpp` rebound to endpoint/stream addressing | +| **Phase 14** | v2.12.0 | Test & simulation rebuild | `mock.hpp`, `sim.hpp` rebuilt as RC Server simulators | +| **Phase 15** | v2.13.0 | Native transport rebuild | `udp.hpp` / `wire.hpp` rebuilt to carry real AVTPDU frames (IEEE1722-over-UDP/IP, Annex J) | +| **Phase 15** | v2.14.0 | Auxiliary transport rebind | `mdns.hpp`, `tls.hpp`, `tsn.hpp`, `shmem.hpp`, `loan.hpp`, `record.hpp`, `observe.hpp` | +| **Phase 15** | v2.15.0 | App-layer bridge rebind | `mqttbr`, `ddsbr`, `someipbr`, `restbridge`, `grpcbridge`, `udsbr`, `doipbr` | +| **Phase 15** | v2.16.0 | C ABI & CLI rebuild | `capi.h`/`capi_impl.hpp`, `cli.hpp` rebuilt against the new request model | +| **Phase 16** | v2.17.0 | Deprecation sweep | Remove packages with no TC18 analog (see disposition table) | +| **Phase 16** | v2.18.0 | Certification refresh | HARA/TARA/FMEA/formal verification/audit pack regenerated against the new requirement set | +| **Phase 16** | v3.0.0 | **TC18 RCP — General Availability** | First release where cpp-RCP *is* the OPEN Alliance TC18 Remote Control Protocol | --- ## Milestones --- -### Phase 1 — Foundation +### Phase 13 — TC18 Wire Format & Server Core --- -### 1. Foundation (v0.1.0) ✅ - -- Core `include/rcp/rcp.hpp` interfaces: `Controller`, `Registry`, `Command`, `Response`, `Status` -- `include/rcp/mock.hpp` in-process backend -- CI: unit tests (cross-platform), clang-tidy, cpp-FuSa, DCO -- Release workflow: safety artifact regeneration on tag -- Safety artifacts: `.fusa.json`, `.fusa-reqs.json`, `.fusa-hara.json`, `.fusa-iec62443.json` -- Docs: README, SAFETY_PLAN, SECURITY, INCIDENT-RESPONSE, CONTRIBUTING - -### 2. Requirements (v0.2.0) ✅ - -- 198 atomic SEOOC requirements across 24 groups (REQ-ZONE, REQ-PRI, REQ-CMD, REQ-STATUS, REQ-ERR, REQ-CMDSTRUCT, REQ-RESP, REQ-STAT, REQ-CTRL, REQ-REG, REQ-UDP, REQ-E2E, REQ-WDG, REQ-DL, REQ-PWR, REQ-PQ, REQ-RL, REQ-SIM, REQ-FI, REQ-LOAN, REQ-TLS, REQ-SHMEM, REQ-TSN, REQ-MDNS) -- Full cpp-FuSa v0.30.0+ trace and check compliance +This phase is one continuous breaking rewrite of the protocol core; the +version numbers below mark internal milestones within it, not independently +stable public releases — nothing in Phase 13 is wire-conformant until v2.6.0 +lands (the point at which the mandatory baseline plus safe-points exist), +and full endpoint coverage is not reached until v2.7.0. + +### 44. Wire Format Core (v2.0.0) + +- Replace the bespoke 16-byte `wire.hpp` header entirely with real IEEE 1722 + framing: NTSCF (non-time-synchronous, server-only-outbound) and TSCF + (time-synchronous, client-only) AVTPDU headers (extraction §2.2) +- Implement the two ACF message types RCP defines on top of IEEE 1722: + ACF_ABB (`0x0E`, no timestamp field) and ACF_GBB (`0x0D`, 64-bit + `message_timestamp` field) (extraction §2.3) +- Implement the shared `byte_message_info` header fields common to both + message types: `acf_msg_type`, `acf_msg_length`, `pad`, `mtv`, `rsv`, + `byte_bus_id`, `evt` (ack flag + 3-bit sub-opcode), `hs`, `cs`, + `transaction_num`, `op`, `rsp`, `err`, `ms`, and the dual-purpose + `read_size`/`segment_num` field (extraction §2.4) +- Implement `stream_id` (sender MAC + locally-assigned suffix) and + `byte_bus_id` addressing, including the rule that `byte_bus_id` is only + unique within a stream, not globally, and must be echoed back unchanged + on responses/acks (extraction §2.1) +- Implement the mandatory "standard request" kind (best-effort, + unconditional, ACF_ABB) and the four response semantic types + (acknowledge / write response / read response / error response) mapped + onto the shared header fields (extraction §2.7, §2.8) +- Implement `avtp_timestamp` (32-bit, TSCF only) and `message_timestamp` + (64-bit, ACF_GBB) semantics, including the timestamp-validity fallback + rules (extraction §2.6, §2.9) +- Explicitly support running the transport over Ethernet directly, + IEEE1722-over-UDP/IP, **or** CAN(FD/XL) as the underlying network — do not + hard-assume a pure-Ethernet transport anywhere in this layer, since the + specification calls out CAN-as-transport explicitly (extraction §2.1, + §1.4) +- No dependency on any endpoint type, lifecycle state, or discovery + behavior — this milestone is pure wire codec + +### 45. RC Server Lifecycle & Register-Map Model (v2.1.0) + +- Implement the 3-state lifecycle machine: `HW_UNCONFIGURED` (`0x00`), + `HW_CONFIGURED` (`0x55`), `RCP_CONFIGURED` (`0xAA`), with their documented + transition guards, register-locking behavior, and the + `HW_CFG_INCONSISTENT` / `RCP_CFG_INCONSISTENT` plausibility checks on + state-advance requests (extraction §3.2) +- Implement the split between an endpoint's **generic** (server-owned, + pin-mapping/queue-size) config block and its **functional** config block + — this split is itself new relative to the pre-replacement design and + every subsequent endpoint milestone depends on it existing first + (extraction §4.2 vs. §4.4/§5.x, §6 item 5) +- Implement EP0 (RC Server as a pseudo-endpoint): whole-register-map + read/write, the root-client concept (`svr_root_client_index`, one stream + with full-register-map write access), and per-endpoint write restriction + for every other client (extraction §5.1, §4.1) +- Implement the general register map fields needed to bootstrap everything + else: magic number, protocol version, vendor/device ID, endpoint count, + stream/queue capacity registers, `svr_implemented_options` bitmask, + and the pointer/capacity fields for the HW pin-map, request-stream, + response-stream, EP-ID mapping, and functional-config tables (extraction + §3.6) +- Implement HW pin-mapping config (extraction §3.7), request-stream config + including the `rx_*` fields needed later for watchdog/safe-state + (extraction §3.8 — full behavioral wiring of the safety-relevant `rx_wd_*` + /`rx_safety_measure` fields is deferred to v2.6.0, but the fields must + exist in the register model now), the EP-ID/`byte_bus_id` mapping table + (extraction §3.9, including the documented risk that ordering is + client-guaranteed, not server-enforced — flag this explicitly in code + comments rather than silently assuming correct ordering), and + response/ack queue config (extraction §3.10) +- Implement sequencer-state registers as persistent 8-bit values (used + starting in v2.5.0) (extraction §3.11, §3.16) +- Implement the mandatory error codes needed once register access exists: + `UNAUTHORIZED_ACCESS`, `LOCKED_MEM_ACCESS`, `REQUEST_REJECTED`, + `INVALID_PARAMETER` (extraction §3.15) + +### 46. Discovery (v2.2.0) + +- Implement the discovery request: a broadcastable ACF_ABB read addressed + to `byte_bus_id 0`, NTSCF-only (a TSCF-headed discovery request is + dropped), reading from register-map address 0 (extraction §3.5) +- Implement discovery-stream claiming: the first discovery request received + in `HW_UNCONFIGURED`/`HW_CONFIGURED` reserves the discovery stream for + configuration writes; the reservation lapses after a configurable + `Discovery_TimeOut` (~20 ms default) if no configuration request follows; + other clients can still read via discovery concurrently but cannot + configure while a claim is active (extraction §3.5) +- Ensure a server answers discovery in **any** lifecycle state, per the + mandatory baseline (extraction §3.1, §3.5) + +### 47. Basic Endpoint Types I — GPIO & SPI (v2.3.0) + +- GPIO (`ep_type 0x02`): 4-byte bitmask request/response, the 8 + write-semantics selected by `evt[2:0]` (replace / OR / AND / XOR / + reserved / add / subtract / reconfigure), per-pin change/rising/falling + trigger signals (extraction §5.3, §4.5 Group C) +- SPI (`ep_type 0x03`): up to 6 pre-configured channels selected by + `evt[2:0]` values `0`-`5`, raw PICO-out/POCI-in byte transfer, the + compound-wait truncation rule (compares only the first 4 of up to 20 + status bytes), transfer-complete and per-CS assert/de-assert triggers + (extraction §5.4, §4.5 Group A) +- These two endpoint types establish the endpoint-registration and + request-dispatch pattern (functional config block, `evt[2:0]` decoding, + trigger-signal table) that every later endpoint type reuses — deliberately + sequenced first because they are the simplest fully-specified payload + shapes +- Implement the arithmetic-add/subtract saturation rule shared by GPIO and + PWM_OUT now, since GPIO exercises it (extraction §4.5) + +### 48. Basic Endpoint Types II — I²C, UART, ADC, PWM_OUT, PWM_IN (v2.4.0) + +- I²C (`ep_type 0x04`): controller-only, raw byte stream including address + bytes, compound-wait against arbitrary received-bit-sequence match; flag + the unresolved `i2c_mode` high-speed enum ambiguity in code comments as an + open item pending a later spec errata pass rather than guessing at a + mapping (extraction §5.7, §7) +- UART (`ep_type 0x05`): independent TX/RX queues, RX FIFO fill/drain + semantics, read completion on either `read_size` reached or `uart_timeout` + elapsed, payload-less "pure" read requests, sub-octet bit-width padding + rules; because fragmentation is being deferred (v2.8.0), size the RX FIFO + and bound configurable `read_size` so a single-AVTPDU response is always + achievable — document this explicitly as the accepted limitation rather + than leaving it implicit (extraction §5.8) +- ADC (`ep_type 0x09`): the three-level averaging model + (`adc_sample_interval` → `adc_avg_intervals_per_request` → + `adc_combine_avg_values`), request-driven sampling only, the two + self-triggering cadence patterns, and the `PWM_IN_NO_SIGNAL`-style + no-signal timeout handling equivalent for the request path (extraction + §5.9) +- PWM_OUT (`ep_type 0x07`) and PWM_IN (`ep_type 0x08`): the shared + period/active-duration two-field payload shape, PWM_OUT's 8-way + write-semantics reuse from GPIO, PWM_IN's response-only read model and + `PWM_IN_NO_SIGNAL` error path, and the mid-pulse trigger signal used later + to key ADC sampling cadence (extraction §5.5, §5.6) + +### 49. Conditional-Request Taxonomy & Sequencers (v2.5.0) + +- Implement the `message_timestamp`-field-repurposing trick: when + `mtv=0` on an ACF_GBB message, the first byte of the otherwise-unused + 64-bit timestamp slot becomes a `request_type` opcode, with the + remaining 7 bytes carrying kind-specific parameters (extraction §2.7) +- Implement all five conditional request kinds and their optional-feature + bundling: compound (`0x0F`) and compound-wait (`0x0B`) as one bundle + (requires ≥4 sequencers and clear-non-safestate cancellation to also be + implemented — a repo cannot claim "compound support" without both); + triggered (`0x0E`) and chained (`0x01`) as independently-flagged + capabilities; timed (`0x0A`) as part of the time-sync bundle alongside + TSCF and timestamped acks/responses (extraction §3.1, §2.7) +- Implement sequencer state registers as the supporting primitive for + compound/compound-wait (persistent 8-bit state, default `1`, advanced + only on compound-request finalization while the sequencer is still in its + expected start state) (extraction §3.11, §3.14) +- Implement the three cancellation request kinds: clear-all (`0x05`, + mandatory baseline), clear-non-safestate (`0x06`, part of the compound + bundle), clear-single (`0x07`, part of the enhanced-cancellation bundle), + and their shared cancellation semantics (already-executing requests + finish; cancelling a chained request cancels its successors; + `REQUEST_CANCELED`/`REQUEST_NOT_FOUND` error codes) (extraction §2.7) +- Implement the full request lifecycle state machine (pending → started → + under execution → finalized) with the type-specific sub-behavior at each + transition, and the execution-priority ordering across simultaneously-due + requests: cancellation → triggered → timed → compound → compound-wait → + chained → standard, ties resolved FIFO (extraction §3.14) +- Implement the `cs` (conditional-start) field's two meanings depending on + request kind (compound-wait immediate-vs-after-change check; chained + execute-regardless-vs-abort-on-predecessor-error) (extraction §2.4) + +### 50. E2E CRC Safe Points & Safety-Request Variants (v2.6.0) + +- Implement the specification's actual end-to-end CRC: 32-bit, polynomial + `0xF4ACFB13`, initial value `0xFFFFFFFF`, final XOR `0xFFFFFFFF`, both + input and output reflection enabled — **not** the ad-hoc CRC-16/CCITT + scheme the pre-replacement `e2e.hpp` used (extraction §4.7) +- Implement CRC coverage exactly as specified: `stream_id` + + `avtp_timestamp` (zero-filled stand-in under NTSCF) + the full ACF header + + payload, with the message-length pre-adjustment (+1 quadlet on + `acf_msg_length`, +4 octets on the frame length field) needed to account + for the trailing CRC bytes (extraction §4.7) +- Implement per-endpoint opt-in "safe mode" via `ep_req_crc_enable` / + `ep_ack_crc_enable` / `ep_response_crc_enable`, and the `CRC_ERROR` + failure path (extraction §4.4, §4.7, §3.15) +- Implement the safety-tagged (`0x8x`) MSB-set variants of compound + (`0x8F`), compound-wait (`0x8B`), and triggered (`0x8E`) requests: these + execute only once the endpoint is actually in its configured safe state, + and on watchdog overflow the *normal* variants are purged from the + endpoint's queue while the *safety* variants remain and drive the system + through its safe state — this is the load-bearing safety mechanism new + relative to the pre-replacement design and the reason this milestone is + sequenced before the remaining endpoint types (extraction §2.7, §6 item 4) +- Implement the per-request-stream watchdog and safe-state config fields: + `rx_wd_timeout_interval`, `rx_wd_enable`, `rx_wd_safestate_enable`, + `rx_enforce_e2e` (per-request drop vs. whole-stream latch), `rx_enforce_seq` + / `rx_seq_safestate_enable` (monotonic sequence check, distinct from and + orthogonal to the watchdog), `rx_ovrflw_safestate_enable`, + `rx_safety_measure` (force-high-impedance vs. run-a-sequencer-based + safety-sequence), `rx_safestate_sequencer`, `rx_safe_sequencer_state`, and + `rx_wd_info_enable` (repeating notification while in safe state) + (extraction §3.8) +- This is the third of the three highest-priority structural changes + identified during gap analysis (alongside the lifecycle state machine and + discovery) — deliberately landed before the remaining, lower-priority + endpoint types in v2.7.0 + +### 51. Remaining Endpoint Types — LIN, CAN (incl. CAN XL), ISELED, MDIO, Wakeup Control (v2.7.0) + +- LIN commander (`ep_type 0x06`): raw-byte-pusher model with no + frame-level concepts (no checksum selection, no PID generation, no + schedule tables) — validate explicitly against any assumption in the + deprecated `linbr.hpp` bridge that the endpoint understood LIN frame + structure; it does not, per the specification, and client-side driver + logic must absorb that responsibility instead (extraction §5.10, §6 item + "significant behavioral-scope question") +- CAN controller (`ep_type 0x0B`): Classical/FD/XL frame formats via an + explicit `FrameFormat` sub-field, data frames only (no remote-frame + support), CAN XL's extra 6-byte header region and up to 2054-byte payload + (necessarily spanning multiple AVTPDUs — see the fragmentation decision + below), separate bit-timing register sets per phase (arbitration / FD data + / XL data), and CAN-XL-specific acceptance/receive filters; note in code + that the specification defines no trigger-signal table for this endpoint + type at all, unlike every other device-facing endpoint (extraction §5.11, + §7) +- ISELED (`ep_type 0x0C`): native ISELED daisy-chain framing + (Instruction/Address/Data request shape, Address/Data/optional-native-CRC + response shape), the endpoint's own native CRC as a mechanism additional + to (not a replacement for) the general RCP-level E2E CRC from v2.6.0 + (extraction §5.12) +- MDIO (`ep_type 0x0D`): Clause-22/Clause-45-style mode-selected register + access, essentially no type-specific functional config beyond the common + block — note this endpoint type is fully specified but omitted from the + specification's own informative "ten interfaces" scope list, so treat it + as in-scope regardless of that omission (extraction §5.13, §1.2, §7) +- Wakeup control (`ep_type 0x01`): the fixed `SleepCMD` (`0xA5`) request + distinct from the generic request taxonomy, wake-source pin monitoring, + and the repeating `WakeUp` message handshake used during hot-start-from- + Sleep — this is the endpoint type the Phase 14 power-management rebuild + (v2.9.0) depends on directly (extraction §5.2, §3.3) +- **DAC is explicitly out of scope for this cycle.** The specification + enumerates a DAC `ep_type` (`0x0A`) and a `DAC_OUT` pin signal, but no + functional-config chapter exists anywhere in the source document — it is + reserved-but-undefined in v0.5.1_RC. Do not build against it; revisit only + if and when a later spec revision actually defines DAC's register model + and request semantics (extraction §1.2, §7, §8) + +### 52. Fragmentation — Go/No-Go Decision (v2.8.0) + +**Decision: no-go for this cycle.** Fragmentation (the `ms`/`segment_num` +mechanism for splitting one logical request/response across multiple +AVTPDUs) is explicitly called out in the specification itself as optional +"for RCP version 1.0" (extraction §2.5, §7) — even the specification's own +authors do not require it. Given that: + +- it interacts non-trivially with the E2E CRC mechanism landed in v2.6.0 + (only the *last* segment of a fragmented message carries a CRC, computed + across all segments combined, with its own length-accounting adjustment + rule) — implementing it correctly means re-touching the safety-critical + CRC code path a second time; +- every place it would matter (UART RX-FIFO sizing, CAN XL's up-to-2054-byte + payloads, full register-map discovery reads) has a workable single-AVTPDU + fallback that this roadmap already plans for (bounded UART `read_size`, + documenting CAN XL frames larger than one AVTPDU as an accepted + limitation, and chunked discovery reads); and +- cpp-RCP's certification posture (ASIL-B traceability, formal verification + of safety state machines) benefits more from a smaller, fully-verified + wire surface at the v3.0.0 GA milestone than from broader payload-size + support that isn't required for conformance, + +fragmentation is deferred to a dedicated future milestone, to be scoped +once the unfragmented core has shipped and been field-proven. This is +tracked as an explicit, documented limitation of the v2.x/v3.0.0 line, not +a silent omission — any endpoint whose natural payload can exceed one +AVTPDU (UART, CAN XL, full-register discovery) must have that bound +documented in its own functional-config comments once implemented. --- -### Phase 2 — Safety Groundwork +### Phase 14 — Safety & Control-Plane Package Rebuild --- -### 3. Hardening (v0.3.0) ✅ - -**Mock correctness fixes** (already in v0.1.0 mock) -- `Registry::lookup` returns `ErrClosed` after `close()` -- `Controller::send` returns `ErrZoneMismatch` when `cmd.zone != controller.zone()` -- Payload copy-on-send prevents cross-zone aliasing - -**Benchmarks** (`tests/bench_mock.cpp`) ✅ -- `Send_RoundTrip`, `Send_RoundTrip_WithPayload`, `Send_Concurrent` (8 threads), `Publish_FanOut`, `Registry_Lookup` - -**Safety timing evidence** (`tests/command_latency_test.cpp`) ✅ -- 30-second workload; P99 < 1 ms and Max < 10 ms gates enforced -- Writes `COMMAND_LATENCY.md` as FuSa audit evidence - -### 4. HARA Expansion (v0.4.0) ✅ - -`.fusa-hara.json` expanded to H-001..H-010 and SG-001..SG-010: - -- **H-001..H-003**: Original hazards (delivery loss, misrouting, watchdog failure) -- **H-004**: Replay of stale commands → SG-004 (E2E replay guard) -- **H-005**: Zone falsely reported alive → SG-007 (deadline monitor) -- **H-006**: Priority inversion → SG-005 (priority queue Critical bypass) -- **H-007**: Rate limiter blocks watchdog → SG-003, SG-005 -- **H-008**: Unauthorized command injection → SG-006 (mTLS) -- **H-009**: Power-state management failure → SG-001, SG-008 -- **H-010**: Fault injection persists across power cycles → SG-009 -- `HARA.md` documents ASIL decomposition rationale - ---- -### Phase 3 — Transport Stack ---- - -### 5. UDP Transport (v0.5.0) ✅ - -- Length-framed binary command/response protocol over UDP (SOME/IP-aligned framing: message ID, session ID, length prefix) -- `include/rcp/udp.hpp`: `udp::Controller`, `udp::ZoneServer`, `udp::Registry`, frame codec -- Static unicast zone discovery; optional multicast announcement -- Integration tests with loopback interface -- `rcptool` gains `--transport udp --addr ` flag - -### 6. mDNS Discovery (v0.6.0) ✅ - -- `include/rcp/mdns.hpp`: zero-configuration zone controller discovery via mDNS (RFC 6762) and DNS-SD (RFC 6763); Avahi-compatible -- Zone controllers self-announce as `_rcp._udp.local` service records carrying zone ID, address, and port -- `Discoverer` abstract base: `discover(ctx, events_channel)` with add/remove events -- `Registry::auto_register(ctx, discoverer)` wires discovered controllers into the registry automatically -- Configurable service-instance name format: `.._rcp._udp.local` - -### 7. TLS Transport (v0.7.0) ✅ - -- `include/rcp/tls.hpp`: mutual TLS transport via system TLS (OpenSSL or platform API) -- Certificate pinning for zone controller identity verification -- Addresses SG-006: zone identity authenticated via certificate before command acceptance - -### 8. Shared Memory Transport (v0.8.0) ✅ - -- `include/rcp/shmem.hpp`: zero-copy intra-host command delivery via POSIX shared memory (`shm_open`/`mmap`) for zone controllers co-located on the same ECU -- `shmem::Controller` implements the `Controller` interface; swappable with UDP/TLS without API change -- Initial `LoaningController` implementation: `loan()` returns a pre-allocated `Command` buffer from the shared region; `send_loaned()` delivers it without copying -- Linux only; falls back to UDP transport gracefully on other platforms via `auto::new_controller` - -### 9. Loaned Samples (v0.9.0) ✅ - -- `LoaningController` interface extending `Controller` with `loan(int size, std::unique_ptr&)` and `send_loaned(ctx, loan, response)` -- `LoaningRegistry` wraps any registry; `lookup_loaning(zone)` returns a `LoaningController` if the underlying transport supports it -- Implementations across all transports: - - `shmem`: full zero-copy into the shared memory region (no allocation, no copy) - - `mock`: pre-allocated pool; `BenchmarkSend_Loaned` must report 0 allocs/op - - UDP/TLS: pool-backed `Command` buffers eliminate per-call allocation; one copy to the socket send buffer remains unavoidable -- Guarantee: `LoaningController::send_loaned` on the shmem and mock paths must not allocate — enforced by benchmark gate in CI -- `auto::new_loaning_controller` selects shmem if available, falls back to pool-backed UDP - -### 10. TSN Transport (v0.10.0) ✅ - -- `include/rcp/tsn.hpp`: IEEE 802.1Qbv (Time-Aware Shaper) aware UDP transport for hard real-time Ethernet delivery -- Credit-Based Shaper (CBS, 802.1Qav) integration for bandwidth reservation per zone stream -- Frame preemption (802.1Qbu) support to protect `Priority::Critical` commands from frame bursts -- Deployment guide: required `SO_PRIORITY` socket options, VLAN tagging, and NIC configuration on Linux (Nvidia Orin / Renesas R-Car H3) -- Timing evidence: `tests/tsn_latency_test.cpp` — loopback measurements with TSN shaper active, demonstrating bounded worst-case delivery latency +These four milestones rebuild the satellite packages whose current +implementation is safety- or liveness-relevant and therefore cannot be left +running against the old Zone/Command model once Phase 13 lands — see the +disposition table below for the full reasoning per package. + +### 53. Power Management Rebuild (v2.9.0) + +- Replace `powerstate.hpp`'s ad-hoc `Active`/`Sleeping`/`BusOff` model + entirely with the specification's actual `Normal`/`StandBy`/`Sleep`/ + `Unpowered` power modes, the `StandBy`-is-always-hot-start / + `Sleep`-is-always-cold-start distinction, and the documented entry-refusal + conditions (unacknowledged wake-up event, a non-idle endpoint, or a + non-empty response/ack queue) (extraction §3.3, §3.4) +- Implement the hot-start-from-Sleep handshake: network-interface + re-enablement, the repeating `WakeUp` message via the Wakeup endpoint + (v2.7.0) until echoed or a repeat limit is hit, then re-enabling other + response/ack queues (extraction §3.3) +- Depends on: Wakeup control endpoint (v2.7.0), RC Server lifecycle + (v2.1.0) + +### 54. Watchdog & Liveness Rebuild (v2.10.0) + +- Replace `watchdog.hpp`'s client-driven periodic `CommandType::Watchdog` + kick model — that command type does not exist in the target protocol — + with the specification's per-request-stream watchdog: reset by *any* + inbound request on that stream, tied directly into the safe-state + mechanism from v2.6.0 rather than a separate client-side health poll + (extraction §3.8) +- Rework `deadline.hpp`'s zone-liveness monitor to key off the + response/ack queue's `Flush_time`-driven periodic heartbeat and/or the + EP0 lifecycle-state-changed trigger signal, since there is no `Status` + subscription concept to poll in the new model (extraction §3.10, §5.1) +- Depends on: RC Server lifecycle & register map (v2.1.0), E2E safe points + (v2.6.0) + +### 55. Authorization & Admission-Control Rebind (v2.11.0) + +- Rebind `authz.hpp`'s access-policy check from + (`Identity`, `Zone`, `CommandType`) to (`Identity`, target server, target + endpoint, request kind) — the root-client/per-endpoint-client access + model from v2.1.0 already provides half of this natively at the protocol + level, so this package's job narrows to policy *on top of* that, not + replacing it +- Rebind `ratelimit.hpp` from per-`Zone`/`Priority` token buckets to + per-endpoint or per-stream admission control, protecting against a + client overrunning an endpoint's finite request-queue capacity — the + specification defines queue overflow as an unconditional drop with no + server-side flow control, explicitly leaving overrun-avoidance as "the + client's job" (extraction §3.14), which is exactly what this package + already does one layer up +- Depends on: RC Server lifecycle & register map (v2.1.0) + +### 56. Test & Simulation Harness Rebuild (v2.12.0) + +- Rebuild `mock.hpp` as an in-process RC Server simulator implementing the + lifecycle state machine, register map, and a representative endpoint set, + replacing the old in-process `Controller`/`Registry` mock entirely +- Rebuild `sim.hpp` as a timing-realistic RC Server simulator for SiL/HIL + testing, carrying forward the existing latency/jitter modeling concept + but re-implemented against the new request/response shapes and the new + watchdog model from v2.10.0 +- Depends on: everything in Phase 13 through v2.6.0 at minimum, to have a + representative register map and safe-state model to simulate --- -### Phase 4 — Safety Mechanisms +### Phase 15 — Transport & Ecosystem Bridge Migration --- -### 11. Watchdog & Heartbeat (v0.11.0) ✅ - -- `include/rcp/watchdog.hpp`: periodic `CommandType::Watchdog` scheduling with configurable interval per zone -- Zone health state machine: Healthy → Degraded → Faulted with configurable thresholds -- `Registry::watch_health()` returns a `StatusChannel`-like stream for health state change events -- New requirements: REQ-WD-001..REQ-WD-00N (ASIL-B) — addresses SG-003, SG-007 - -### 12. Deadline Monitoring (v0.12.0) ✅ - -- `include/rcp/deadline.hpp`: zone-to-HPC direction: alert when `Status` updates from a zone controller stop arriving within a configured deadline -- `DeadlineMonitor` wraps any `Controller`; calls a `missed_deadline_fn` callback if no `Status` is received within the deadline window -- Integrates with `Registry::watch_health()`: a deadline miss transitions the zone to Degraded after one miss, Faulted after N consecutive misses (configurable) -- Complements the watchdog (HPC→zone) to give full bidirectional liveness -- New requirements: REQ-DL-001..REQ-DL-00N (ASIL-B) — addresses SG-001, SG-004 - -### 13. Power State (v0.13.0) ✅ - -- `include/rcp/powerstate.hpp`: `CommandType::Sleep` and `CommandType::Wake` already in `CommandType` -- Zone power state machine: Active → Sleeping → WakePending → Active; transitions driven by RCP commands and watchdog timeouts -- `Controller::power_state()` returns the current zone power state -- `Registry::watch_power()` stream for zone power state change events -- Bus-off recovery: automatic `CommandType::Wake` retry with configurable backoff when a zone transitions from Sleeping unexpectedly -- New requirements: REQ-PWR-001..REQ-PWR-00N (ASIL-B) - -### 14. E2E Protection (v0.14.0) ✅ - -- `include/rcp/e2e.hpp`: 32-bit sequence counter per zone controller; rejects out-of-window frames -- CRC-16 frame check on command and response payload -- Anti-replay guard with configurable window size -- New requirements: REQ-E2E-001..REQ-E2E-00N (ASIL-B) — addresses SG-005, SG-010 - -### 15. Priority Queuing (v0.15.0) ✅ - -- `include/rcp/prioqueue.hpp`: per-zone send queue with three priority levels -- `Priority::Critical` bypasses normal queue backpressure -- Backpressure metrics exposed via OpenTelemetry counter -- Queue depth and drop rate added to `Status` telemetry -- New requirements: REQ-PQ-001..REQ-PQ-00N (ASIL-B) — addresses SG-008 - -### 16. Rate Limiting (v0.16.0) ✅ - -- `include/rcp/ratelimit.hpp`: per-zone token-bucket admission control on the HPC send path -- Configurable burst and sustained rate limits per priority level (`Priority::Critical` exempt by default) -- `ErrBusy` returned immediately when bucket is exhausted; no blocking -- Rate limit state exposed in `Status` telemetry and Prometheus metrics -- New requirements: REQ-RL-001..REQ-RL-00N (ASIL-B) — addresses SG-009 +### 57. Native Transport Rebuild — UDP/IP (Annex J) (v2.13.0) + +- Rebuild `udp.hpp` to encapsulate real AVTPDU frames per IEEE 1722's own + Annex J UDP/IP encapsulation, instead of the bespoke `R`/`C`-magic 16-byte + header it uses today — `wire.hpp` is retired outright, not adapted, since + it *is* the old wire format this whole roadmap replaces +- Depends on: Wire format core (v2.0.0) + +### 58. Auxiliary Transport & Cross-Cutting Rebind (v2.14.0) + +- `mdns.hpp`: narrow its scope to the UDP/IP transport variant specifically + — TC18 defines its own wire-level discovery over an Ethernet-addressed + stream (v2.2.0) that does not need a name service, so mDNS/DNS-SD only + earns its keep when host:port discovery is separately needed for the + IEEE1722-over-UDP/IP path +- `tls.hpp`: rebuild as a transport option specifically for the UDP/IP + variant (as DTLS or an application-layer channel), and flag in the same + change that the specification's own preferred link-security mechanism is + MACsec (802.1AE) at layer 2 (extraction §3.12, §1.3), which this package + does not currently address at all +- `tsn.hpp`: rebind its PCP-mapping from the old 3-level `Priority` enum + (which is being removed) to the specification's own execution-priority + ordering across request kinds (v2.5.0), and prefer genuine IEEE 1722 + stream reservation where available over socket-level `SO_PRIORITY` hints +- `shmem.hpp`: rebuild the zero-copy in-process channel against the new + request/response shapes; the "avoid serialization overhead for + co-located RC Client/RC Server" value proposition is unaffected by the + protocol replacement +- `loan.hpp`: rebind zero-copy buffer loaning to whatever the new + client-side request-building API turns out to be — likely to matter more + here than before, since AVTPDU construction has more framing overhead to + avoid copying than the old 16-byte header did +- `record.hpp`: rework the on-disk entry format to capture raw AVTPDU + frames (or RC-Client-level request/response pairs) instead of + `Command`/`Response`/`Status` structs +- `observe.hpp`: rebind span/counter recording to wrap the new client-side + send-equivalent call; the OpenTelemetry-style approach itself is + unaffected +- Depends on: Wire format core (v2.0.0); UDP/IP transport (v2.13.0) for the + `mdns`/`tls` items specifically + +### 59. Application-Layer Protocol Bridge Rebind (v2.15.0) + +- Rebind `mqttbr.hpp`, `ddsbr.hpp`, `someipbr.hpp`, `restbridge.hpp`, + `grpcbridge.hpp`, `udsbr.hpp`, `doipbr.hpp` to the new client-side + request/response types. These bridges translate between an RC Client's + application-level view and another ecosystem (MQTT topics, DDS samples, + SOME/IP methods, REST, gRPC, UDS services, DoIP) — that job is + conceptually unaffected by which wire protocol RCP itself now speaks, so + each of these is a mechanical interface update, not a redesign. All seven + are currently unimplemented stubs (`function_not_supported`), so there is + no working behavior to preserve, only an interface shape to update before + a real implementation is ever built behind it +- `canbr.hpp` and `linbr.hpp` are **not** part of this rebind — see the + disposition table: both are deprecated outright, because the target + specification makes CAN and LIN native endpoint types of an RC Server + (v2.7.0) rather than something external to bridge to from an RCP + "Zone" — the bridge direction the old packages assumed is inverted by + the real protocol +- Depends on: Wire format core (v2.0.0) at minimum; each bridge's own + external dependency (an MQTT/DDS/SOME-IP/UDS library) is unchanged by + this rework + +### 60. C ABI & CLI Rebuild (v2.16.0) + +- Rebuild `capi.h`/`capi_impl.hpp`: the current C structs + (`rcp_command_t`, `rcp_response_t`, `rcp_zone_t`) are Zone/CommandType- + specific and do not generalize by adaptation — this is a from-scratch + redesign of the RTOS/bare-metal C surface against the new request model, + landed last in this phase because it is the smallest-audience, + highest-effort-per-user surface +- Rebuild `cli.hpp` (and the `cli/main.cpp` wrapper): the RELAY-conformant + `version`/`capabilities`/`status` triad (RELAY spec §11/§12) carries + forward unchanged in *shape*, but `send` needs a new addressing form + (target server + endpoint instead of `--zone`), and `capabilities_json()` + needs updated `transports`/`features` fields once the new transports and + endpoint set exist +- Rework `rcp/adapt.hpp`'s `Adapt()`/`ToMessage()`/`FromMessage()` mappings + so `relay::Message` continues to bridge to *something* meaningful on the + RCP side once `Controller`/`Command`/`Zone` no longer exist — likely a + per-endpoint request/response pair keyed by a server+endpoint identifier + in `relay::Message.id` instead of a PascalCase zone name; `relay/relay.hpp` + itself (the protocol-agnostic `Message`/`Channel`/`Node`/`Caller` types) + needs no change +- Depends on: at least the basic endpoint types (v2.3.0/v2.4.0) to have + something for `send` to address --- -### Phase 5 — Verification +### Phase 16 — Deprecation & Certification Refresh --- -### 17. Zone Simulator (v0.17.0) ✅ - -- `include/rcp/sim.hpp`: timing-realistic zone controller simulator for SiL/HIL testing without physical ECUs; implements the full `Controller` interface -- Configurable response latency distribution (constant, normal, or jitter model) and processing load -- Zone health and power state machines driven by injected fault schedules: Healthy → Degraded → Faulted → Recovering -- Watchdog miss detection: simulator transitions to Faulted if `CommandType::Watchdog` is not received within the configured deadline -- Deadline monitoring simulation: publishes `Status` at a configured rate; stops publishing on fault injection to trigger `DeadlineMonitor` -- Composable with the fault injection harness (v0.18.0) -- Ships alongside `include/rcp/mock.hpp` - -### 18. Fault Injection (v0.18.0) ✅ - -- `include/rcp/faultinject.hpp`: structured fault injection harness for validating safety mechanisms introduced in v0.11.0–v0.16.0 -- Fault types: missed watchdog kick, missed Status deadline, corrupted CRC frame, replayed sequence number, late response (> timeout budget), dropped response, zone-mismatch command, admission-control exhaustion, spurious sleep transition -- Each fault is a typed value injected via a `FaultSchedule` applied to a `sim::Controller` or live UDP transport -- Regression suite: `tests/fault_injection_test.cpp` — for each fault type, assert the correct sentinel error is returned and the health/power state machine transitions correctly -- Writes `FAULT_INJECTION.md` — FuSa evidence cross-referencing HARA hazards H-001..H-010 +### 61. Deprecation Sweep (v2.17.0) + +Remove, rather than adapt, every package whose current abstraction has no +analog in the target specification and cannot be meaningfully repositioned +on top of it. See the disposition table for the individual justification +per package; this milestone is the mechanical removal once Phase 13-15 have +landed and nothing else in the tree still depends on these headers: +`canbr.hpp`, `linbr.hpp`, `federation.hpp`, `proxy.hpp`, `zonegroup.hpp`, +`prioqueue.hpp`, `firmware.hpp`. + +### 62. Certification Refresh (v2.18.0) + +- Regenerate `.fusa-reqs.json`, `.fusa-hara.json`, `HARA.md`, `TARA-ANALYSIS.md`, + `CYBERSECURITY.md`, `fmea.csv`/`fmea.json`, the formal-verification TLA+ + specs in `tla/`, and `AUDIT_PACK.md` against the v2.x requirement set — + the old `REQ-ZONE-*`/`REQ-CMD-*`/`REQ-STATUS-*` requirement groups are + retired alongside the API surface they trace to, and every phase above + needs its own new `REQ-*` group +- Re-run the ASIL-B decomposition and structural-coverage analysis against + the new endpoint and safe-state code paths specifically, since the E2E + CRC / safe-state mechanism (v2.6.0) is the most safety-relevant new + surface in this whole roadmap + +### 63. TC18 RCP — General Availability (v3.0.0) + +- First release where cpp-RCP's `RCP` conforms to the OPEN Alliance TC18 + Remote Control Protocol Specification at the wire level: an RC Client + built on this library and an RC Server built on any other conformant + implementation (and vice versa) can interoperate +- Major version bump (v2.x → v3.0.0) marks this as the intended stable line + going forward, distinct from the v2.x pre-GA milestones that got the + implementation there +- Fragmentation support remains an explicitly documented future item (see + v2.8.0), not a GA blocker --- -### Phase 6 — Security ---- - -### 19. Authorization (v0.19.0) ✅ -- `include/rcp/authz.hpp`: command-level access control: a signed `AccessPolicy` declares which HPC identities may send which `CommandType` values to which zones -- `AuthController` wraps any `Controller`; verifies the caller's certificate against the access policy before forwarding commands -- Policy format: YAML/JSON, signed with the zone controller's TLS private key — policies are unforgeable without the zone's key -- `ErrForbidden` sentinel error returned on policy violation; logged to audit trail -- Aligns with IEC 62443 SL-2 target in `.fusa-iec62443.json`: authenticated identity + command-level authorisation -- New requirements: REQ-AUTH-001..REQ-AUTH-00N (ASIL-B / IEC 62443 SL-2) — addresses SG-006 - -### 20. Firmware Update / OTA (v0.20.0) ✅ - -- `include/rcp/firmware.hpp`: `CommandType::Update` added to `CommandType` -- Chunked firmware delivery over RCP with integrity check (SHA-256) and rollback support -- `FirmwareSession` manages the multi-command exchange: Initiate → Transfer (N chunks) → Verify → Activate → Reset -- Zone controller authentication required before any `CommandType::Update` is accepted (depends on v0.19.0 Authorization) -- Delta update support: binary diff to minimise transfer size over constrained links -- `rcptool update ` subcommand +## Satellite Package Disposition + +Every header under `include/rcp/` and `include/relay/` that exists +alongside the core protocol today gets an individual, justified call +below. "REPLACE" means the package's current implementation is discarded +and rebuilt from spec; "ADAPT" means the concept survives but the interface +is rebound to the new core types; "DEPRECATE" means the package is removed +with no direct successor; "KEEP AS-IS" means the package is genuinely +orthogonal to the protocol replacement. + +| Package | Call | Reason | +|---|---|---| +| `rcp.hpp` | REPLACE | Core `Zone`/`Command`/`Response`/`Status`/`Controller`/`Registry` model has no TC18 analog; becomes the new stream/endpoint/register-map model (v2.0.0-v2.1.0) | +| `wire.hpp` | REPLACE | *Is* the old wire format; rebuilt as the AVTPDU/ACF codec (v2.0.0) | +| `udp.hpp` | REPLACE | Bespoke 16-byte-header UDP transport rebuilt to carry real AVTPDU frames (v2.13.0) | +| `mock.hpp` | REPLACE | In-process mock is entirely `Zone`/`Command`-shaped; rebuilt as an RC Server simulator (v2.12.0) | +| `sim.hpp` | REPLACE | Timing-realistic simulator implements the full old `Controller` interface; rebuilt against the new register/endpoint model (v2.12.0) | +| `e2e.hpp` | REPLACE | Ad-hoc CRC-16 + replay-window wrapper superseded by the spec's actual CRC32 (poly `0xF4ACFB13`) safe-point mechanism and `rx_enforce_seq` monotonic check (v2.6.0) | +| `powerstate.hpp` | REPLACE | Ad-hoc Active/Sleeping/BusOff model superseded by the spec's Normal/StandBy/Sleep/Unpowered model with cold/hot start (v2.9.0) | +| `watchdog.hpp` | REPLACE | Client-driven `CommandType::Watchdog` kick has no analog; superseded by per-stream watchdog config tied to safe-state (v2.10.0) | +| `capi.h` / `capi_impl.hpp` | REPLACE | C structs are `Zone`/`CommandType`-specific; RTOS/bare-metal surface rebuilt from scratch against the new request model (v2.16.0) | +| `adapt.hpp` | ADAPT | `Adapt()`/`ToMessage`/`FromMessage` rebound to the new request/response shapes; `relay::Message` addressing moves from zone name to server+endpoint identifier (v2.16.0) | +| `cli.hpp` (+ `cli/main.cpp`) | ADAPT | `version`/`capabilities`/`status` triad unaffected in shape; `send` gets new server/endpoint addressing (v2.16.0) | +| `config.hpp` | ADAPT | Zone-registry JSON manifest loader rebuilt around a server/endpoint manifest schema; still useful for bootstrapping known topologies alongside discovery | +| `admin.hpp` | ADAPT | Zone listing/SSE/Prometheus rebuilt around discovered RC Servers and their endpoints instead of registered zones | +| `authz.hpp` | ADAPT | Policy check rebound from (identity, zone, cmd type) to (identity, server, endpoint, request kind); protocol already provides root-client vs. per-endpoint access natively (v2.1.0), this package adds policy on top (v2.11.0) | +| `ratelimit.hpp` | ADAPT | Token-bucket rebound from per-zone/priority to per-endpoint/stream; the spec explicitly leaves queue-overrun avoidance to the client, which is this package's existing job one layer up (v2.11.0) | +| `deadline.hpp` | ADAPT | Zone-liveness-via-`Status`-subscription rebuilt around response-queue heartbeat cadence / EP0 lifecycle triggers, since `Status` subscription doesn't exist in the new model (v2.10.0) | +| `mdns.hpp` | ADAPT | Rescoped to the UDP/IP transport variant only — TC18's own wire-level discovery (v2.2.0) makes a name-service layer unnecessary for native Ethernet deployments (v2.14.0) | +| `tls.hpp` | ADAPT | Rebuilt for the UDP/IP transport variant; the spec's own preferred link security is MACsec (802.1AE) at layer 2, which this package doesn't address and should be flagged as the longer-term preferred mechanism (v2.14.0) | +| `tsn.hpp` | ADAPT | PCP mapping rebound from the removed `Priority` enum to the spec's request-kind execution-priority ordering (v2.5.0); prefer real IEEE 1722 stream reservation where available (v2.14.0) | +| `shmem.hpp` | ADAPT | Zero-copy in-process channel rebuilt against new request/response shapes; the co-location value proposition is unaffected (v2.14.0) | +| `loan.hpp` | ADAPT | Zero-copy payload loaning rebound to the new request-building API; arguably more valuable now given AVTPDU framing overhead (v2.14.0) | +| `record.hpp` | ADAPT | Record/replay format reworked to capture raw AVTPDU frames or RC-Client-level request/response pairs (v2.14.0) | +| `observe.hpp` | ADAPT | Span/counter wrapper rebound to the new send-equivalent call; OTel-style approach itself unaffected (v2.14.0) | +| `dyndata.hpp` | KEEP AS-IS | `SchemaRegistry`/`DynamicPayload` operate on raw bytes + a schema ID with no dependency on `Zone`/`Command`; genuinely orthogonal to the wire-protocol replacement | +| `mqttbr.hpp` | ADAPT | Unimplemented stub; interface rebound to new request/response types, no working behavior to preserve (v2.15.0) | +| `ddsbr.hpp` | ADAPT | Same as above (v2.15.0) | +| `someipbr.hpp` | ADAPT | Same as above (v2.15.0) | +| `restbridge.hpp` | ADAPT | Same as above (v2.15.0) | +| `grpcbridge.hpp` | ADAPT | Same as above (v2.15.0) | +| `udsbr.hpp` | ADAPT | Same as above (v2.15.0) | +| `doipbr.hpp` | ADAPT | Same as above (v2.15.0) | +| `canbr.hpp` | DEPRECATE | The spec makes CAN a native RC Server endpoint type (v2.7.0), not something bridged to from a `Zone`; the bridge *direction* this package assumes is inverted by the real protocol, and it is currently an empty stub with no behavior to preserve | +| `linbr.hpp` | DEPRECATE | Same reasoning as `canbr.hpp` — LIN is a native endpoint type (v2.7.0), not a bridge target | +| `federation.hpp` | DEPRECATE | Multi-HPC lease-based zone-ownership forwarding is a bespoke zonal-architecture concept with no TC18 analog; the spec's multi-client arbitration is the root-client/discovery-stream-claim mechanism (v2.1.0/v2.2.0), which is architecturally a different idea, not a superset | +| `proxy.hpp` | DEPRECATE | TC18 has no "proxy node" concept — an RC Client addresses an RC Server directly via `stream_id`/`byte_bus_id`; multi-hop is a network-layer (switching/routing) concern the spec explicitly leaves out of scope | +| `zonegroup.hpp` | DEPRECATE | No direct analog; the spec's own way to batch multiple targets is packing several ACF messages with different `byte_bus_id`s into one AVTPDU (extraction §3.14), which is a different mechanism (one frame, many targets) from this package's fan-out-to-N-independent-zones model | +| `prioqueue.hpp` | DEPRECATE | The `Priority::Critical/High/Normal` enum this package reorders by is removed; the spec's own priority concept is a fixed execution-priority ordering across request *kinds* (cancellation > triggered > timed > compound > compound-wait > chained > standard), enforced server-side, not a client-side send-order wrapper | +| `firmware.hpp` | DEPRECATE | `CommandType::Update` and the whole Initiate/Transfer/Verify/Activate session model have no TC18 analog — OTA is an application-layer concern the spec doesn't define; could be rebuilt later atop raw UART/SPI endpoint byte transfer if ever needed, but that is speculative and out of scope here | +| `version.hpp` | KEEP AS-IS | Single version-string constant; mechanically bumped per release, no design dependency on the protocol | +| `relay/relay.hpp` | KEEP AS-IS | Protocol-agnostic `Message`/`Channel`/`Node`/`Caller`/`Errc` types have no dependency on `rcp::` internals; only the RCP-side mapping in `adapt.hpp` needs rework | +| Safety/certification tooling (`.fusa*.json`, `fmea.*`, `HARA.md`, `TARA-ANALYSIS.md`, `SAFETY_PLAN.md`, `CYBERSECURITY.md`, `AUDIT_PACK.md`, `tla/`, `cmake/`, `tooling/`) | KEEP AS-IS | Genuinely orthogonal process/tooling scaffolding; regenerated with new requirement IDs at the Certification Refresh milestone (v2.18.0) rather than redesigned | --- -### Phase 7 — Topology & Scalability +### Appendix A — Legacy Roadmap (v0.1.0–v1.11, superseded) --- -### 21. Zone Groups (v0.21.0) ✅ - -- `include/rcp/zonegroup.hpp`: `ZoneGroup` is a typed set of `Zone` values with named constants (e.g. `GroupRearPassenger`, `GroupAllZones`) -- `Registry::send_group(ctx, group, cmd)` dispatches a command atomically to all zones in the group and collects responses -- Partial-failure semantics: returns a `GroupResponse` carrying individual per-zone `Response` and `std::error_code` values; caller decides whether to treat partial success as failure -- `Priority::Critical` group commands are dispatched concurrently with a single shared deadline context - -### 22. Zone Proxy (v0.22.0) ✅ - -- `include/rcp/proxy.hpp`: transparent proxy for cascaded zonal topologies (HPC → proxy → zone MCU) -- Command routing table: zone → upstream proxy address -- Latency budget enforcement at proxy boundary; budget violation → `ErrTimeout` - -### 23. Redundancy (v0.23.0) ✅ - -- `include/rcp/redundancy.hpp`: `RedundantRegistry` wraps a primary and hot-standby `Registry`; promotes standby automatically on health-state change -- Heartbeat-based HPC liveness detection: standby activates if primary HPC misses N consecutive heartbeats -- Configurable promotion policy: automatic (zero-touch) or operator-confirmed -- State synchronisation: in-flight commands at failover are retried against the new primary with deduplication via `Command::id` -- New requirements: REQ-RED-001..REQ-RED-00N (ASIL-B) - -### 24. Multi-HPC Federation (v0.24.0) ✅ - -- `include/rcp/federation.hpp`: multiple active HPCs each owning disjoint zone subsets on the same zone bus -- `FederatedRegistry` coordinates zone ownership: each HPC registers a lease on the zones it owns; a lease server arbitrates conflicts -- Cross-HPC command forwarding: HPC-A can send a command to a zone owned by HPC-B via the federation layer; transparent to the caller -- Ownership transfer: zones can be migrated between HPCs at runtime (e.g. powertrain HPC hands off body zones during shutdown) - ---- -### Phase 8 — Tooling ---- - -### 25. Observability (v0.25.0) ✅ - -- `include/rcp/observe.hpp`: OpenTelemetry trace spans for every `send` and `subscribe` call -- Prometheus-compatible metrics: command latency histogram, error rate, zone health gauge, power state distribution, deadline miss counter -- `monitor` subcommand in `rcptool` for live zone status dashboard - -### 26. Admin API (v0.26.0) ✅ - -- `include/rcp/admin.hpp`: HTTP admin interface -- `GET /zones` — list all registered zones with health, power state, and last-seen timestamp -- `GET /zones/{zone}` — single-zone detail: health history, command rate, deadline miss count -- `POST /zones/{zone}/send` — send a command via JSON body; returns response JSON -- `GET /events` — SSE stream of all health, power, and deadline-miss events -- `GET /metrics` — Prometheus scrape endpoint -- Bearer auth enforced on all write endpoints (depends on v0.19.0 Authorization) - -### 27. Record & Replay (v0.27.0) ✅ - -- `include/rcp/record.hpp`: records all `Command`, `Response`, and `Status` streams to a structured binary log on disk -- Ring-buffer mode for always-on black-box recording with configurable retention window -- Replay: feed a recorded log back through any `Controller`/`Registry` implementation for regression testing against a new version -- `rcptool record` and `rcptool replay` subcommands -- Log format is append-only and checksummed — suitable as FuSa incident forensics evidence - -### 28. Config (v0.28.0) ✅ - -- `include/rcp/config.hpp`: YAML/JSON zone registry configuration (zone ID, transport, address, certificates) -- Hot-reload of zone addresses without restart via filesystem watcher - -### 29. Code Generation (v0.29.0) ✅ - -- Zone manifest schema (YAML/JSON): declares zone IDs, supported command types, payload schemas, and ASIL levels -- `rcptool gen ` generates typed C++ controller stubs with `// fusa:req` annotations pre-populated -- Generated stubs implement the `Controller` interface; the generator emits matching `_test.cpp` skeletons and `.fusa-reqs.json` entries -- Eliminates hand-written boilerplate when adding a new zone type; keeps requirements, code, and tests in sync from declaration - -### 30. Dynamic Data (v0.30.0) ✅ - -- `include/rcp/dyndata.hpp`: runtime payload schema registry: named types (e.g. `"braking.BrakeCommand"`) registered with a C++ struct and a codec at startup -- `DynamicPayload` carries a schema name alongside raw bytes; `decode(p)` reconstructs the typed value without compile-time knowledge of all payload types -- Admin API and `rcptool monitor` display decoded payload fields when a matching schema is registered; fall back to hex for unregistered types -- Code generation (v0.29.0) emits `register_schema` calls for each declared payload type, wiring the two features together -- Useful for cloud tools and dashboards that connect after deployment and need to interpret payloads without a recompile - ---- -### Phase 9 — Remote Access ---- - -### 31. gRPC Bridge (v0.31.0) ✅ - -- `include/rcp/grpcbridge.hpp`: gRPC transport for cloud-connected zone controllers and remote HPC diagnostic access -- `Subscribe` server-streaming RPC: cloud consumer receives `Status` updates in real time -- `Send` unary RPC: remote caller dispatches a `Command` and receives the `Response` -- Bearer auth interceptors; filter and transform hooks; YAML config -- Enables remote diagnostic tools and cloud dashboards to interact with zone controllers without a local HPC connection - -### 32. REST Bridge (v0.32.0) ✅ - -- `include/rcp/restbridge.hpp`: HTTP/SSE bridge for browser-based tooling and cloud integration -- `POST /zones/{zone}/commands` — dispatch a `Command` as JSON; returns `Response` JSON -- `GET /zones/{zone}/status` — SSE stream of `Status` updates for a single zone -- `GET /zones` — SSE stream of all zone health and power-state change events -- Bearer auth on all write endpoints; CORS support for browser clients -- Complements the gRPC bridge: REST/SSE for interactive dashboards and scripts; gRPC for high-throughput cloud consumers - ---- -### Phase 10 — Automotive Protocol Bridges ---- - -### 33. SOME/IP Bridge (v0.33.0) ✅ - -- `include/rcp/someipbr.hpp`: bridge `CommandType::Set`/`CommandType::Get` to SOME/IP service method calls via cpp-SOMEIP -- Bidirectional: SOME/IP events → RCP `Status` updates - -### 34. CAN Bridge (v0.34.0) ✅ - -- `include/rcp/canbr.hpp`: bridge `CommandType::Set`/`CommandType::Get` to CAN frames via cpp-CAN -- Configurable CAN ID mapping per zone and command type - -### 35. DDS Bridge (v0.35.0) ✅ - -- `include/rcp/ddsbr.hpp`: bridge RCP `Status` updates to DDS topics via cpp-DDS (sensor-fusion consumers receive zone telemetry as typed DDS samples) -- Bridge DDS samples → RCP `CommandType::Set`/`CommandType::Get` for ADAS pipeline → zone actuator control -- Bidirectional QoS mapping: DDS Reliability/Durability → RCP `Priority` - -### 36. MQTT Bridge (v0.36.0) ✅ - -- `include/rcp/mqttbr.hpp`: bridge RCP `Status` to MQTT topics for cloud telemetry and fleet management via cpp-mqtt -- Bridge MQTT command messages → RCP `CommandType::Set` for remote zone actuation -- Configurable topic prefix per zone (e.g. `rcp/zone/front-left/status`) - -### 37. LIN Bridge (v0.37.0) ✅ - -- `include/rcp/linbr.hpp`: bridge `CommandType::Set`/`CommandType::Get` to LIN frames via cpp-LIN for low-bandwidth zone actuators (seat motors, mirror adjustment, window regulators) -- Configurable LIN frame ID and field mapping per zone and command type -- LIN schedule table management: RCP commands inserted as unconditional or event-triggered frames - -### 38. UDS Bridge (v0.38.0) ✅ - -- `include/rcp/udsbr.hpp`: bridge RCP commands to ISO 14229 UDS service calls for zone controller diagnostics -- `CommandType::Reset` → UDS ECUReset (0x11); `CommandType::Get` → ReadDataByIdentifier (0x22); `CommandType::Set` → WriteDataByIdentifier (0x2E) -- Configurable UDS addressing mode per zone (physical, functional, extended) -- UDS negative response codes surfaced as typed `ResponseStatus` values - -### 39. DoIP Bridge (v0.39.0) ✅ - -- `include/rcp/doipbr.hpp`: ISO 13400 Diagnostics over IP transport for workshop and EOL diagnostic access to zone controllers -- `DoIPController` implements the `Controller` interface; routes `CommandType::Get`/`CommandType::Reset` to UDS services over the DoIP wire protocol -- Logical address and routing activation management per zone -- Enables `rcptool` to act as a DoIP tester for factory-floor zone controller flashing and diagnostics - ---- -### Phase 11 — Platform ---- - -### 40. RTOS / Bare-Metal (v0.40.0) ✅ - -- Zone controller client library targeting Zephyr, FreeRTOS, and NuttX RTOS -- Pure C API header (`include/rcp/capi.h`) with `extern "C"` linkage; no heap allocation on the RTOS side: all buffers statically allocated at compile time -- Implements the same UDP framing, E2E protection, and watchdog protocol as the C++ library -- Integration test: Zephyr zone controller on QEMU communicating with cpp-RCP HPC over loopback - ---- -### Phase 12 — Certification & Formal Methods ---- - -### 41. Formal Verification (v0.41.0) ✅ - -- TLA+ specification of the zone health state machine (Healthy → Degraded → Faulted → Recovering) - - Properties verified: no deadlock, no livelock; liveness (a zone that becomes healthy is eventually detected as Healthy); safety (a Faulted zone is detected within 2× the watchdog period) -- TLA+ specification of the watchdog protocol: HPC sends `CommandType::Watchdog` at interval T; zone resets if no kick arrives within deadline D - - Properties verified: if kicks cease, zone reaches Faulted within D + network round-trip; a resumed kick stream returns zone to Healthy -- TLA+ specification of the anti-replay guard: sequence counter window W; frames outside the window are rejected - - Properties verified: no valid in-window frame is ever rejected; a replayed frame is always rejected -- Model-checking results and counter-example traces published in `FORMAL_VERIFICATION.md` — ASIL-D evidence that the safety state machines are correct by construction -- `tla/` directory contains all `.tla` and `.cfg` files; reproducible via the TLC model checker - -### 42. ISO 21434 / Cybersecurity (v0.42.0) ✅ - -- Threat Analysis and Risk Assessment (TARA) covering command injection, replay attacks, rogue zone controller registration, OTA firmware tampering, and denial-of-service via command flooding -- Security requirements mapped to TARA findings; implemented controls (TLS, Authorization, E2E replay guard, rate limiting, mDNS authentication) traced as countermeasures -- IEC 62443 SL-2 gap report (`iec62443-gap-report.json`) — closes open items from `.fusa-iec62443.json` -- Penetration test evidence: structured attack scenarios against UDP, TLS, admin HTTP, gRPC, and REST endpoints -- `TARA-ANALYSIS.md` and `CYBERSECURITY.md` published alongside the safety case - -### 43. Certification (v0.43.0) ✅ - -- ASIL-D gap analysis report (decomposition paths from current ASIL-B) -- Structural coverage report: statement, branch, MC/DC -- Audit pack for customer qualification (requirements traceability matrix, FMEA, safety case, TARA cross-reference, formal verification summary) +Everything below this line is the completed roadmap for the pre-replacement, +non-conformant `Zone`/`Command`/`Response` protocol. It is kept for +historical record only — none of it describes the OPEN Alliance TC18 Remote +Control Protocol work above, and no future work should be planned against +it. See the Breaking Change Notice at the top of this document. + +### Vision (superseded) + +cpp-RCP was, prior to this roadmap, a C++17-native Remote Control Protocol +for automotive zonal architecture, feature- and API-equivalent to +[go-RCP](https://github.com/SoundMatt/go-RCP). That framing is retired: the +project's name now refers to the real OPEN Alliance TC18 protocol, not a +same-named home-grown one. + +### Legacy Milestones (v0.1.0 – v1.11, all shipped) + +1. Foundation (v0.1.0) — core interfaces, mock backend, CI, cpp-FuSa, safety artifacts +2. Requirements (v0.2.0) — 198 atomic SEOOC ASIL-B requirements +3. Hardening (v0.3.0) — mock correctness fixes, benchmarks, safety timing evidence +4. HARA Expansion (v0.4.0) — H-001..H-010, SG-001..SG-010 +5. UDP Transport (v0.5.0) +6. mDNS Discovery (v0.6.0) +7. TLS Transport (v0.7.0) +8. Shared Memory Transport (v0.8.0) +9. Loaned Samples (v0.9.0) +10. TSN Transport (v0.10.0) +11. Watchdog & Heartbeat (v0.11.0) +12. Deadline Monitoring (v0.12.0) +13. Power State (v0.13.0) +14. E2E Protection (v0.14.0) +15. Priority Queuing (v0.15.0) +16. Rate Limiting (v0.16.0) +17. Zone Simulator (v0.17.0) +18. Fault Injection (v0.18.0) +19. Authorization (v0.19.0) +20. Firmware Update / OTA (v0.20.0) +21. Zone Groups (v0.21.0) +22. Zone Proxy (v0.22.0) +23. Redundancy (v0.23.0) +24. Multi-HPC Federation (v0.24.0) +25. Observability (v0.25.0) +26. Admin API (v0.26.0) +27. Record & Replay (v0.27.0) +28. Config (v0.28.0) +29. Code Generation (v0.29.0) +30. Dynamic Data (v0.30.0) +31. gRPC Bridge (v0.31.0) +32. REST Bridge (v0.32.0) +33. SOME/IP Bridge (v0.33.0) +34. CAN Bridge (v0.34.0) +35. DDS Bridge (v0.35.0) +36. MQTT Bridge (v0.36.0) +37. LIN Bridge (v0.37.0) +38. UDS Bridge (v0.38.0) +39. DoIP Bridge (v0.39.0) +40. RTOS / Bare-Metal (v0.40.0) +41. Formal Verification (v0.41.0) +42. ISO 21434 / Cybersecurity (v0.42.0) +43. Certification (v0.43.0) +44. RELAY conformance uplift (v1.0.0 – v1.11) — protocol-agnostic `relay::` namespace, crossbar spoke CLI, cross-language module conventions + +Full detail for each of these has been removed from this file to keep the +document focused on the active replacement plan; see git history for +`ROADMAP.md` prior to this revision if the original per-milestone +bullet points are needed.