Skip to content

[cpp-RCP v3.0.0] Full ground-up rewrite ported from c-RCP #129

Description

@SoundMatt

Why

A 2026-08-21 parity audit against c-RCP (the project's reference implementation) found cpp-RCP behind on nearly every axis — no MC/DC, no requirement-atomicity audit, no fixed-capacity architecture, a replay-detection mechanism implemented but never wired into dispatch, a 26-commit tag/main drift — tracked in #122-127 (master #128).

Then a bigger problem surfaced: cpp-RCP was never rebaselined to TC18 v0.5.1_RC5 at all. README.md/ROADMAP.md cite v0.5.1_RC, the exact pre-RC5 baseline c-RCP itself started from before spending a real multi-issue program (c-RCP #96, #339, #341, #434) reconciling to RC5. Confirmed concretely, not just by citation: c-RCP's RC5 rebaseline found spi_nr_cs narrowed to a 4-bit (count-1) field plus a new deassert_cs_pause bit (RC5 ticket NXP_100) — cpp-RCP's spi.hpp has neither. That's a real wire-format defect, not a stale comment.

Given the scale of what's wrong at once — spec version, requirement catalog, safety evidence, and architecture — the decision is a full ground-up rewrite rather than another patch effort: clear cpp-RCP's implementation and rebuild it from scratch, using c-RCP's current (RC5-conformant, atomicity-audited, ASIL-D-hardened) implementation as the content source of truth, re-expressed in idiomatic modern C++.

This is cpp-RCP's own v3.0.0 — its ROADMAP.md already names "Phase 16, v3.0.0: TC18 RCP — General Availability" as the destination. This rewrite fulfills that directly.

Where the work happens

Branch rewrite/v3-from-c-rcp, not main — so main stays green/deployable for however many sessions this takes, and existing tags remain a rollback point. Each module is rebuilt in its own PR against this branch (delete-old + add-new in the same PR, so the branch stays buildable and CI-green throughout rather than broken for the whole multi-session effort). Final cutover merges this branch into main and tags v3.0.0.

Full plan: see the session's plan file (module-by-module mapping, phase sequencing, verification discipline) — summarized in the checklist below.

Supersedes

Closing, with a pointer here: #122 (release integrity), #123 (CI reliability), #124 (requirement schema/atomicity), #125 (ASIL-D SEOOC), #126 (allocation architecture), #127 (CAN XL fragmentation decision), #128 (parity master tracker). All of that work is subsumed by porting c-RCP's already-hardened equivalents directly, rather than incrementally patching the code being replaced.

Not superseded, still real, independent bugs: #58 (cs-bit polarity — will simply not exist in the ported code, verify during the port), #23 (go-RCP tooling-package parity — orthogonal, revisit post-rewrite).

Phases (see plan file for full detail)

  • Phase 0 — branch setup, issue cleanup (this tracker), ROADMAP.md v3 section
  • Phase 1 — core wire/protocol: acf, avtp, request(+sequencer+scheduler folded), fragment (new), respqueue (new), loan
  • Phase 2 — safety layer: e2e, lifecycle, watchdog, allocation seam (DI-based, fixed-capacity, fault-injection tests)
  • Phase 3 — per-endpoint modules (batched): can, lin, iseled, adc, pwm, gpio, spi, uart, mdio, wakeup
  • Phase 4 — server/dispatch: regmap, mock (wire in classifier/Table-30/E2E-guard/fragmentation), server/endpoint.hpp, discovery, adapt
  • Phase 5 — transport: udp, l2, shmem, admin; re-verify tls/capi
  • Phase 6 — requirement catalog: re-derive .fusa-reqs.json from c-RCP's 1282 entries
  • Phase 7 — formal verification + MC/DC + release-pipeline hardening
  • Phase 8 — remaining modules + re-integrate dyndata/redundancy/sim
  • Phase 9 — cutover: full verification, merge to main, tag v3.0.0, update RELAY's docs/RCP-ARCHITECTURE.md

Scale, honestly

Multi-session — comparable to building c-RCP's current maturity from scratch, since it includes standing up infrastructure c-RCP itself took many dedicated efforts to build (fragmentation, respqueue, MC/DC, fixed-capacity architecture, formal-verification CI) and more than tripling cpp-RCP's test suite (730 → ~2350+ test cases). Progress tracked here, one comment per phase batch, same as c-RCP's own tracker-issue pattern.

Metadata

Metadata

Assignees

No one assigned

    Labels

    documentationImprovements or additions to documentationenhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions