Skip to content

AUDIT_PACK.md

Latest commit

 

History

History
170 lines (137 loc) · 8.26 KB

AUDIT_PACK.md

File metadata and controls

170 lines (137 loc) · 8.26 KB
Raw

Audit Pack — cpp-RCP Certification Evidence (Milestone 62)

Document version: 2.0.0 Date: 2026-07-28 Standards: ISO 26262 (ASIL-C — corrected from ASIL-B, see HARA.md H-001), IEC 61508 (SIL-2), ISO 21434, IEC 62443 SL-2

This revision (ROADMAP.md milestone 62, "Certification Refresh", v2.18.0) supersedes the pre-replacement audit pack authored at milestone 43. All figures below (requirement count, coverage module list, CI gate thresholds) are re-derived against the full v2.x requirement set built up across Phase 13-16 (v2.0.0-v2.17.0).

1. Document Index

Document Location Status
HARA (Hazard Analysis & Risk Assessment) HARA.md Complete
TARA (Threat Analysis & Risk Assessment) TARA-ANALYSIS.md Complete
Cybersecurity Architecture CYBERSECURITY.md Complete
Formal Verification FORMAL_VERIFICATION.md Complete
Safety Requirements .fusa-reqs.json 417 requirements across 55 groups
Safety Case Generated via cpfusa safety-case CI gate
Release Badge Generated via cpfusa badge CI gate

2. ASIL-D Gap Analysis (ISO 26262 §7)

cpp-RCP targets ASIL-C for the RC Client/RC Server communication subsystem (corrected from a previously-stated ASIL-B; see HARA.md's H-001 rationale — S3/E4/C2 maps to ASIL-C, not ASIL-B, and no decomposition is claimed for it). The table and decomposition paragraph below predate that correction and still frame this subsystem's derogation from ASIL-D as an ASIL-B(D) = ASIL-A + ASIL-B decomposition — per HARA.md's own H-001 rationale, no such decomposition is actually claimed (ASIL-C is met directly). This section has not yet been re-derived for an ASIL-C target and is flagged as a follow-up, not resolved by this pass — re-deriving which ASIL-D requirements still warrant derogation, and on what rationale, at an ASIL-C (rather than ASIL-B) target is a safety-case judgment call outside the scope of a documentation-consistency fix.

ASIL-D Requirement Derogation Rationale ASIL-B Coverage
Redundant communication paths Not required at ECU boundary for ASIL-B Single channel with E2E CRC + sequence + watchdog protection
Formal proofs of absence of deadlock TLA+ liveness proofs deferred to ASIL-C/D upgrade path TLC exhaustive model check on bounded state space (tla/)
MISRA C++:2023 compliance MISRA advisory rules selectively suppressed with justification clang-tidy clean on safety-critical rules
100% MC/DC structural coverage 80% branch coverage enforced in CI 80% branch + path coverage reported by cpfusa coverage

ASIL decomposition (pre-dates the ASIL-C correction above — see this section's own flagged-follow-up note): the RC Client/RC Server link was previously described as decomposed as ASIL-B(D) = ASIL-A + ASIL-B per ISO 26262-9 §5 (independent channel decomposition). HARA.md's current per-hazard rationale for H-001 claims no such decomposition.

3. Structural Coverage Report

Coverage is measured by the cpfusa coverage tool on the CI test suite, against coverage.info collected from ctest --test-dir build-cov.

Module Line Branch MC/DC
e2e.hpp See coverage-report.json (regenerated at release)
watchdog.hpp See coverage-report.json (regenerated at release)
lifecycle.hpp See coverage-report.json (regenerated at release)
regmap.hpp See coverage-report.json (regenerated at release)
avtp.hpp / acf.hpp See coverage-report.json (regenerated at release)
authz.hpp See coverage-report.json (regenerated at release)
Overall See coverage-report.json's summary block

coverage-report.json is regenerated on every tagged release by .github/workflows/release.yml (cpfusa coverage --profile coverage.info --dal DAL-B) — it is not hand-maintained here to avoid this document drifting from the actual per-release measurement, the drift this revision itself was written to correct.

Required threshold: 80% branch coverage. MC/DC coverage target of 80% is tracked as an open item for an ASIL-C upgrade path.

Real MC/DC (condition/decision) evidence, distinct from the cpfusa coverage --mcdc/--dal DAL-B branch-coverage fallback above, is now measured in CI by .github/workflows/ci.yml's mcdc job (Phase 7 batch 2 / cpp-RCP #129): LLVM's own -fcoverage-mcdc instrumentation, built and run against the full ctest suite, exported via llvm-cov export (not cpfusa coverage --mcdc-file, whose parser expects JSON keys real llvm-cov export output does not produce — see the job's own header comment; filed upstream as SoundMatt/cpp-FuSa#64-class). Freshly measured immediately before this PR (Homebrew LLVM 18.1.8, matching the CI job's own clang-18, on include/rcp/*.hpp): 313/466 = 67.17% real MC/DC condition-pair coverage (corroborated by a second local run on LLVM 22.1.8: 426/629 = 67.73%, close agreement across a 4-major-version toolchain gap). The mcdc job ratchet-gates a 60% floor — real margin below that measurement, not a 100% or 80% claim — so this stays open-item/informational for the 80% ASIL-C target above while still catching a real regression today.

4. DO-178C (DAL-C) Applicability

If cpp-RCP is used in an airborne system under DO-178C DAL-C:

  • Source code traceability to LLR: via // fusa:req annotations
  • Tool qualification: cpfusa is a Tool Qualification Level (TQL-5) analysis tool
  • Decision coverage: MC/DC required at DAL-C — see shortfall above
  • Structural coverage artifacts: generated by cpfusa coverage

5. CI Gate Summary

All of the following gates must pass for a tagged release:

Gate Tool Threshold
Static analysis cpfusa check Zero errors
Lint cpfusa lint Zero violations
MISRA/safety analysis cpfusa analyze Zero safety violations
Cyber review cpfusa cyber Zero cyber violations
Requirement coverage cpfusa trace --req-coverage 100 100% covered (RELAY §20.1)
Formal verification TLC on tla/*.tla No error found
ASIL qualification cpfusa qualify Qualified
Vulnerability scan cpfusa vuln No critical/high CVEs
Safety case cpfusa safety-case Complete
ISO 26262 report cpfusa iso26262 Gap report generated (advisory)
IEC 61508 report cpfusa iec61508 Gap report generated (advisory)
DO-178C report cpfusa do178 Gap report generated (advisory)
Coverage cpfusa coverage ≥ 80% branch
MC/DC (real, LLVM) ci.yml's mcdc job (llvm-cov export) Ratchet floor: ≥ 60% (not 100%; see §3)
SCI (Software Change Impact) cpfusa sci No unmitigated impacts
Audit pack cpfusa audit-pack Generated
Release badge cpfusa badge Green

The requirement-coverage threshold is 100% (cpfusa trace --req-coverage 100, enforced in ci.yml's cpfusa-trace job per RELAY §20.1), not the 80% this document previously recorded — the gate was tightened at milestone 60 and this document had not been updated to match until now. The ISO 26262/IEC 61508/DO-178C gap reports are generated by release.yml with || true — they record gaps against those standards' own certification targets without blocking a release, since the seven application-layer protocol bridges (mqttbr.hpp/ddsbr.hpp/etc.) remain unimplemented stubs by design (see CYBERSECURITY.md §1 and TARA-ANALYSIS.md §6).

6. Traceability Matrix

Requirements → implementation tracing is maintained in .fusa-reqs.json (417 requirements across 55 groups as of this milestone). Traceability is validated by cpfusa trace --req-coverage 100 in CI.

Implementation → test tracing: each // fusa:req annotation in a header maps to one or more // fusa:test annotations and test cases in tests/.

7. Change Impact Procedure

For any change to a safety-relevant source file:

  1. Run cpfusa impact --strict to generate the change impact report
  2. Review all impacted requirements in the SCI report
  3. Re-run regression tests for all affected modules
  4. Update .fusa-reqs.json if the change introduces new requirements
  5. Re-generate the audit pack with cpfusa audit-pack
  6. Obtain safety team review approval before merging