From a1f312743e80ba64600ab93307bce4415d271e15 Mon Sep 17 00:00:00 2001 From: Matt Jones <47545907+SoundMatt@users.noreply.github.com> Date: Wed, 19 Aug 2026 08:44:18 -0700 Subject: [PATCH] docs(fusa): [c-RCP-18-tracker Part 1] propagate tc18_master_id for REQ-WIRE-* Pilot batch of the cross-repo TC18-master-catalog-propagation effort on cpp-RCP (RELAY's `docs/tc18-master-catalog.json`, 447 entries), following the pattern already established across four merged go-RCP batches (#161-#164). Links the TC18-scoped `REQ-WIRE-*` requirements (the AVTP-header/ACF-message wire-encoding layer, cpp-RCP's equivalent of go-RCP's `REQ-AVTP-*` prefix) to their master catalog entry via a new `tc18_master_id` field, matching the field convention already used in go-RCP's and c-RCP's own `.fusa-reqs.json`. None of the 15 `REQ-WIRE-*` entries previously carried a `tc18` citation at all (confirmed before starting: only 10 of 376 requirements repo-wide have one, none of them REQ-WIRE-*), so this batch is pure addition, not correction. Every citation below was verified directly against TC18.txt (the plaintext extraction already used elsewhere in this repo's own `tc18` citations), not copied from go-RCP's analogous mapping -- several diverge from go-RCP's REQ-AVTP-* choices where cpp-RCP's wording pointed at a different, more precise clause. 8 requirements linked: - REQ-WIRE-001 (NTSCF header round-trip) -> TC18-11.1-004 -- Figure 6 "NTSCF-Header Version 0"; stream_id/sequence_num_lsb/ntscf_data_length fields, cross-confirmed via the field-labelled Figure 21 ACF_GBB/NTSCF worked example in Section 13.6 (Figure 5/6 themselves render as blank diagrams in the plaintext extraction, so Figure 20/21's worked examples are what make the field layout independently text-verifiable). - REQ-WIRE-002 (TSCF header + avtp_timestamp round-trip) -> TC18-11.1-002 -- Figure 5 "TSCF-Header Version 0", same cross-confirmation via Figure 20. - REQ-WIRE-004 (ACF_ABB carries no timestamp) -> TC18-11.3-003 -- Table 17's explicit, format-wide rule "acf_msg_type 0x0E - ABB message without message_timestamp / 0x0D - GBB message, with message_timestamp" / "message_timestamp Present in ACF_GBB, omitted in ACF_ABB". Chose Table 17 (Section 11.3, responses) over Table 4 (Section 11.2.1, standard requests) because Table 17 states the ABB/GBB timestamp- presence rule as a protocol-wide invariant while Table 4 only fixes mtv=0b for the standard-request case specifically; cpp-RCP's encode_acf_abb/decode_acf_abb are generic codecs used for both directions. go-RCP's analogous REQ-AVTP-011 used TC18-11.2.1-004 instead -- not reused here since REQ-WIRE-004's claim ("since it defines no timestamp slot") is the more general one Table 17 makes explicitly. - REQ-WIRE-005 (ACF_GBB 64-bit message_timestamp octet layout) -> TC18-11.3-003 -- same Table 17, whose field order (acf_msg_type/ acf_msg_length/pad/mtv/rsv/byte_bus_id, then message_timestamp, then evt/hs/cs/transaction_num/op/rsp/err/ms/read_size-or-segment_num) matches the exact octet ranges the requirement specifies, for the genuine-timestamp GBB case (as opposed to the conditional-request GBB tables in Section 11.2.2.x, which repurpose those same bytes to encode a condition rather than a real timestamp -- confirmed by reading Tables 6/7/8/9/12, all of which set mtv=0 and use non-timestamp field names in that byte range). - REQ-WIRE-006 (shared byte_message_info fields) -> TC18-11.2.1-005 -- Table 4's full field-by-field list matches every field the requirement names, and unlike Table 17 does not contradict the "evt ack flag + 3-bit sub-opcode" claim: Table 17's evt semantics are response-specific (0x0=simple/data/error, 0x1-0x8=counter, 0xF=ack) and would have been a wrong-linking, whereas Table 4's evt entry ("Endpoint specific usage, see section 13.5") and Section 13.5's own text ("evt[3] is used to request an acknowledge. I.e. evt[3] = 1 requests acknowledge.") are exactly the ack-flag/sub-opcode split cpp-RCP tests. - REQ-WIRE-009 (standard request = unconditional ACF_ABB) -> TC18-11.2.1-002 -- "A request that is meant for best effort execution shall be sent in ACF_ABB format." - REQ-WIRE-010 (four response kinds distinguishable) -> TC18-11.3.1-001 -- anchors the Section 11.3.1-11.3.4 sequence (Acknowledge/Write/Read/ Error identification by evt/op/err) that response_kind_of implements in full; matches go-RCP's REQ-AVTP-021 choice, independently re-derived here. - REQ-WIRE-011 (avtp_timestamp validity explicit via tv, not zero-value) -> TC18-11.1-002 -- Figure 5's tv bit is a validity marker held separately from the avtp_timestamp value field itself, cross-confirmed via Figure 20's rendered field labels ("...mr rsv tv sequence_num_lsb reserved tu...AVTP Time avtp_timestamp"). 7 requirements deliberately left untouched: - REQ-WIRE-003 (subtype-mismatch decode rejection, AvtpErrc::bad_subtype) -- defensive input-validation coding; TC18 defines what subtype value each header uses but has no MUST clause requiring a decoder to reject a mismatched one. Same category go-RCP left untouched for its analogous REQ-AVTP-003/004 (short-buffer / version-mismatch checks). - REQ-WIRE-007 (StreamId MAC/suffix round-trip) -- IEEE 1722 baseline concept (stream_id = MAC + unique_id), not a TC18-specific clause and outside the master catalog's Section 11-13 scope. Matches go-RCP's REQ-AVTP-006 reasoning exactly. - REQ-WIRE-008 (byte_bus_id echoed unchanged on responses) -- the precise textual match ("The endpoint will create responses and (if requested) acknowledges using the byte_bus_id that was included in the request") lives in TC18 Section 10.1/10.2, which the master catalog does not cover (catalog is scoped to Section 11-13 only). Section 13.1's "byte_bus_id is only unique in the context of a STREAM_ID" and Table 17's generic field list don't state the echo-on-response rule explicitly enough to cite with confidence; left unlinked rather than force a lower-confidence match. - REQ-WIRE-012 (effective_timestamp: TSCF-preferred, then ACF_GBB, then none) -- no single TC18 clause states this combined fallback rule. TC18 keeps TSCF avtp_timestamp (request execution time, Section 11.1/11.4.3) and ACF_GBB message_timestamp (response capture time, Section 11.3/11.4.2) as semantically distinct concepts tied to different message directions; this reads as a cpp-RCP-internal utility abstraction over both, not a spec-mandated behavior. - REQ-WIRE-013 (decoders reject short buffers, AvtpErrc::short_buffer) -- defensive bounds-checking, no distinct TC18 MUST clause. Same category as REQ-WIRE-003 and go-RCP's REQ-AVTP-003. - REQ-WIRE-014 (ACF message-type mismatch rejected, AcfErrc:: bad_acf_msg_type) -- defensive input-validation coding, same category as REQ-WIRE-003/013; TC18 defines the acf_msg_type constant values (Table 4/17) but not a MUST to reject a decoder-observed mismatch. - REQ-WIRE-015 (RELAY spec Section 15.5 canonical ControlFlags/Message conversion) -- out of TC18 scope entirely. Its own `standard` field is already "relay" (not "iso26262"), and its text governs conversion to RELAY's own internal Go `Message` shape per RELAY spec Section 15.5, not any TC18 clause. Verification (commands and results, see also this repo's own .github/workflows/ci.yml): - cmake -B build -DCMAKE_BUILD_TYPE=Release -DCMAKE_CXX_STANDARD=17 -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DRELAY_BUILD_CLI=ON -G Ninja && cmake --build build --parallel: clean build, 219/219 targets. - ctest --test-dir build --output-on-failure -j1: 53/53 tests passing (100%), identical to pre-change. - Pinned cpfusa v0.18.0 (git clone --depth=1 --branch v0.18.0 https://github.com/SoundMatt/cpp-FuSa): cpfusa check 0 errors (2 pre-existing warnings / 1 info, unrelated to this change, identical before/after). - cpfusa trace --format json: totalRequirements/tracedRequirements/ testedRequirements/secTestedRequirements = 376/376/376/64, byte-for- byte identical before and after this change (verified via git stash) -- this batch adds citation metadata only, never adds/removes/ re-tests a requirement. - git status --short / git clean -ndx: only .fusa-reqs.json modified; build/ is gitignored; no stray artifacts. This is the pilot batch establishing the propagation pattern for cpp-RCP's remaining prefixes. Co-Authored-By: Claude Sonnet 5 Signed-off-by: Matt Jones <47545907+SoundMatt@users.noreply.github.com> --- .fusa-reqs.json | 32 ++++++++++++++++++++++++-------- 1 file changed, 24 insertions(+), 8 deletions(-) diff --git a/.fusa-reqs.json b/.fusa-reqs.json index e7e5c9b..a2e7a30 100644 --- a/.fusa-reqs.json +++ b/.fusa-reqs.json @@ -1936,7 +1936,9 @@ "text": "rcp::avtp::encode_ntscf_header/decode_ntscf_header shall round-trip stream_id, sequence_num, and control_data_length unchanged for a Non-Time-Synchronous Control Format AVTPDU header.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.1 Figure 6, \"NTSCF-Header Version 0\" (stream_id, sequence_num_lsb, ntscf_data_length fields; layout confirmed via the §13.6 Figure 21 ACF_GBB/NTSCF worked example showing the same header fields), TC18.txt L1130-1138", + "tc18_master_id": "TC18-11.1-004" }, { "id": "REQ-WIRE-002", @@ -1944,7 +1946,9 @@ "text": "rcp::avtp::encode_tscf_header/decode_tscf_header shall round-trip stream_id, sequence_num, control_data_length, and the 32-bit avtp_timestamp field unchanged for a Time-Synchronous Control Format AVTPDU header.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.1 Figure 5, \"TSCF-Header Version 0\" (stream_id, sequence_num_lsb, avtp_timestamp fields; layout confirmed via the §13.6 Figure 20 ACF_ABB/TSCF worked example showing the same header fields), TC18.txt L1120-1128", + "tc18_master_id": "TC18-11.1-002" }, { "id": "REQ-WIRE-003", @@ -1960,7 +1964,9 @@ "text": "encode_acf_abb/decode_acf_abb shall round-trip the shared ACF header and payload for an ACF_ABB (0x0E) message, and the decoded AcfMessageInfo::mtv shall always be false for ACF_ABB since it defines no timestamp slot.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.3 Table 17 (\"acf_msg_type 0x0E - ABB message without message_timestamp / 0x0D - GBB message, with message_timestamp\" ... \"message_timestamp Present in ACF_GBB, omitted in ACF_ABB\"), TC18.txt L2242-2250", + "tc18_master_id": "TC18-11.3-003" }, { "id": "REQ-WIRE-005", @@ -1968,7 +1974,9 @@ "text": "encode_acf_gbb/decode_acf_gbb shall round-trip the shared ACF header, a 64-bit message_timestamp value, and the payload unchanged for an ACF_GBB (0x0D) message, and shall place them on the wire in the order octets 0-3 = shared-header quadlet 0 (acf_msg_type/acf_msg_length/pad/mtv/rsv/byte_bus_id), octets 4-11 = message_timestamp big-endian, octets 12-15 = shared-header quadlet 1 (evt/rsv/hs/cs/transaction_num/op/rsp/err/ms/read_size_or_segment_num), octets 16 onwards = byte_msg_payload.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.3 Table 17 field order (acf_msg_type/acf_msg_length/pad/mtv/rsv/byte_bus_id, then message_timestamp, then evt/hs/cs/transaction_num/op/rsp/err/ms/read_size-or-segment_num) for the genuine-timestamp ACF_GBB case, matching the identical octet ordering shown in the §13.6 Figure 21 ACF_GBB/NTSCF worked example, TC18.txt L2241-2265", + "tc18_master_id": "TC18-11.3-003" }, { "id": "REQ-WIRE-006", @@ -1976,7 +1984,9 @@ "text": "AcfMessageInfo encode/decode shall preserve acf_msg_type, acf_msg_length, pad, mtv, byte_bus_id, the evt ack flag and 3-bit sub-opcode, hs, cs, transaction_num, op, rsp, err, ms, and the dual-purpose read_size/segment_num field unchanged through an encode/decode round trip.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.2.1 Table 4, \"Usage of ABB message for standard requests\" (full byte_message_info field list: acf_msg_type, acf_msg_length, pad, mtv, rsv, byte_bus_id, evt, hs, cs, transaction_num, op, rsp, err, ms, read_size/segment_num) + §13.5 (\"evt[3] is used to request an acknowledge. I.e. evt[3] = 1 requests acknowledge.\"), TC18.txt L1218-1236,4072", + "tc18_master_id": "TC18-11.2.1-005" }, { "id": "REQ-WIRE-007", @@ -2000,7 +2010,9 @@ "text": "rcp::acf::make_standard_request shall build a request using acf_msg_type ACF_ABB with rsp clear, representing the mandatory best-effort, unconditional standard request kind.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.2.1 (\"A request that is meant for best effort execution shall be sent in ACF_ABB format.\"; §11.2.1 heading itself: \"Standard request – unconditional execution of request (mandatory feature)\"), TC18.txt L1204-1205", + "tc18_master_id": "TC18-11.2.1-002" }, { "id": "REQ-WIRE-010", @@ -2008,7 +2020,9 @@ "text": "rcp::acf::response_kind_of shall recover Acknowledge, WriteResponse, ReadResponse, or ErrorResponse from a header built by make_response with the corresponding ResponseKind, and the four kinds shall be pairwise distinguishable from the shared header fields alone.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.3.1-§11.3.4 (\"With evt[3:0] = 0xF the response is an acknowledge\"; \"With evt[3:0] < 0x9 and op = 1 the response is a write response\"; \"With evt[3:0] < 0x9 and op = 0 the response is a read response\"; \"With evt[3:0] < 0x9 and err = 1 the response is an error-response\"), TC18.txt L2283-2301", + "tc18_master_id": "TC18-11.3.1-001" }, { "id": "REQ-WIRE-011", @@ -2016,7 +2030,9 @@ "text": "A TSCF header with timestamp_valid false shall be distinguishable from one with a valid, zero-valued avtp_timestamp; decode_tscf_header shall preserve the timestamp_valid flag independently of the avtp_timestamp value.", "standard": "iso26262", "level": "ASIL-B", - "asil": "ASIL-B" + "asil": "ASIL-B", + "tc18": "§11.1 Figure 5 (tv validity-marker bit held separately from the avtp_timestamp value field; layout confirmed via the §13.6 Figure 20 ACF_ABB/TSCF worked example: \"...mr rsv tv sequence_num_lsb reserved tu...AVTP Time avtp_timestamp\"), TC18.txt L1120-1128,4212-4218", + "tc18_master_id": "TC18-11.1-002" }, { "id": "REQ-WIRE-012",