How the RBC_Template workspace approaches safety and quality. It defines the approach, the rules per tier and where the evidence lives. It does not repeat product internals (see each product's docs) or the assessment roadmap (see CERTIFICATION_PLAN.dox).

Status: working plan for one development team. Where a rule is a target rather than something already achieved, this document says so.

1. Scope and standards

Standard	Used for
CENELEC EN 50126	RAMS life cycle and the structure of the safety case
CENELEC EN 50128	Software (SIL 4 target for vital C code)
CENELEC EN 50129	Safety-related electronic systems; generic product, generic application, specific application
CENELEC EN 50159	Safety-related communication over open transmission systems (safeComm)
TSI CCS (2023/1695), UNISIG Subsets 026, 037, 039, 094, 098	Interoperability requirements the RBC is assessed against
MISRA C:2023, MISRA Compliance:2020	Coding standard for vital C code; deviations recorded per MISRA Compliance

Out of scope for this plan: hardware safety (the hardware platform), operations and maintenance processes, and safety authority authorisation. They feed the project safety case as inputs.

2. Safety approach

2.1 Structure

The safety argument is built in the same tiers as the products (see CERTIFICATION_PLAN.dox section 2.1):

Generic products (Platform core, safe communication, GP) each carry a generic safety case with safety related application conditions* (SRAC) for whoever uses them.
Generic application (GA) argues that its logic satisfies the SRAC of GP and the RTE.
Specific application (SA and the project model) shows that site data and configuration satisfy the SRAC of everything below, and adds the project hazard analysis.

A lower tier never assumes something a higher tier has not stated as an application condition.

2.2 Principles applied in the design

Principle	How it shows up	Where
The Platform decides, the application declares	Voting, cross-compare and the safe-state transition live in the RTE; applications register a cleanup handler	Platform_RTE ADR-004, ADR-025
Fail safe on disagreement	2oo2 cross-compare enters the safe state on any mismatch	Platform_RTE, RBC_GP
Only one path can grant authority	Movement Authority is granted only through the route-to-train gate	RBC_GP ma_logic
Vital and non-vital separation	The vital side verifies everything it receives; gateway and ALE cannot forge a decision	Platform_Protocol_SafeComm ADR-002
Transmission integrity	MAC, sequence numbers and supervision timers (EN 50159)	Platform_Protocol_SafeComm
No dynamic memory, static allocation	Enforced by review and by the coding rules	Platform_RTE CLAUDE.md
Defined setup phase	Registration is locked after setup	Platform_RTE ADR-026, ADR-032
Redundancy stays a configuration	Topology, replicas, quorum, standby mode are read from a file; the application only declares support	Platform_RTE rte_redundancy_config

2.3 Common-cause failure

Channels A and B may run on identical CPUs (2oo2 with redundancy on one hardware platform). Mitigations, in decreasing order of what the software can influence:

Software diversity: compiler diversity (gcc and clang, ADR-008), different optimisation settings, data and temporal diversity of the exchanged samples.
Separation: separate processes and hosts, staggered timing; physical and power separation is a system input.
Independent verification of each channel's build and configuration.
Quantified argument: a beta-factor style analysis at project level. The framework-level argument is in platform/Platform_RTE/docs/safety/CCF_ANALYSIS.dox; it states its own limits and names the inputs it cannot supply.

Compiler diversity mitigates systematic software faults only. It does not replace hardware diversity.

2.4 Hazard analysis and requirements

Hazards and safety requirements are captured per tier, not once: the framework SRS (platform/Platform_RTE/docs/requirements/SRS.dox), the safeComm SRS (.../Platform_Protocol_SafeComm/docs/requirements/SRS.dox), and the project hazard analysis for the specific application (template: platform/Platform_RTE/docs/templates/06_HARA_TEMPLATE.dox).
Every public function documents pre- and post-conditions and traces to a requirement identifier in a Doxygen comment (REQ-ID).
Each requirement has at least one test or analysis that references it. Gaps are recorded, not hidden (see section 5).

2.5 Application conditions

Each generic product publishes its SRAC. The framework's draft is platform/Platform_RTE/docs/SAFETY_APPLICATION_CONDITIONS.dox.

Status today.** That document states the framework is a reference implementation aligned with EN 50128, not a pre-assessed library, and that a project using it must treat it as new software. CERTIFICATION_PLAN.dox describes the target (an assessed generic platform). Both are correct at their own date: until an independent assessment is completed the framework must be treated as unassessed. Keep the two documents in step when the status changes.

3. Quality approach

3.1 Rules per tier

Tier	Products	Language rules	Verification	Review
Vital, SIL 4	Platform_RTE, Platform_OS_POSIX, RBC_GP (A/B), RBC_GA, RBC_SA libraries, safecomm::safety, ::cfm	C99, MISRA C:2023 (mandatory and required), fixed-width types, checked casts, no dynamic memory, -Wall -Wextra -Wpedantic -Wconversion -Wshadow clean	Unit tests in ctest, cppcheck MISRA addon, coverage (gcovr), ASan/UBSan, Valgrind on Linux	Peer review, documented deviations
Non-vital C	RBC_GP role C, safecomm::ale, ::config, RBC_Test_CommServer	C99, same conventions, not SIL-rated	Unit tests, warnings as errors	Peer review
Tooling	Simulators, test environment, toolchain wiring	Python with pyproject.toml packaging; light conventions	Own tests	Peer review

Where each rule is enforced today (2026-09-21).** -Wall -Wextra -Wpedantic -Wconversion -Wshadow -Werror: Platform_RTE, Platform_OS_POSIX, Platform_Protocol_SafeComm, RBC_GP and RBC_GA (set -DRTE_WARNINGS_AS_ERRORS=OFF to bring up a new compiler; the local test environment build does this on purpose). A MISRA report exists for Platform_RTE and Platform_Protocol_SafeComm only; RBC_GP, RBC_GA and Platform_OS_POSIX have none yet. CI is .github/workflows/build-test.yml at the workspace root (needs the SUBMODULES_TOKEN secret). Open items: ../../safety_quality/REVIEW_2026-09-21.dox.

MISRA findings that are real defects (uninitialised variables, scope) are fixed. Rules accepted as deviations are recorded per product in its MISRA report with a justification. They are never silenced without an entry.

3.2 Verification levels

Level	What	Where
Unit	Per-module tests, mocks one layer down	each product's tests/, run by ctest
Integration	Multi-process reference RBC, live WEST/EAST failover and cross-compare fault injection	application/RBC_GP smoke script
System	11-container Docker stack driven by Robot Framework, plus fault injection	test/RBC_Test_Env
Static	cppcheck with the MISRA addon, compiler warnings as errors	each C product
Coverage	Line, function and branch coverage; the framework requirement is 100%, target MC/DC for safeComm	platform/Platform_RTE/docs/COVERAGE_REPORT.dox
Cross-toolchain	Native macOS, Linux glibc and musl on several architectures, Docker multi-platform	test/RBC_Test_Env build scripts, platform/toolchains/

A change is complete only when the affected product builds warnings-clean, its ctest passes, static analysis shows no new findings and, for the RBC, the smoke scenarios pass (core and failover).

3.3 Independence

Independent verification and validation is required for vital code before a release used in an assessment. The developer of a module is not its independent verifier.
Test tools are classified as EN 50128 class T2 (they do not produce executable code) and need a qualification report before their results are used as evidence.
The tool versions in use and every shipped third-party component are recorded in the software bill of materials: Software bill of materials (BOM).

3.4 Configuration and change management

Version pinning. Every product has a VERSION file and is released by a git tag. The workspace root pins exact commits of all products as git submodules. A submodule pointer moves only in its own commit at the root.
Compatibility table. The RTE release is a tuple (Platform core, OSAdapter, safe communication). A project release records the tuple plus GP, GA, SA, platform image and site-data versions. Template: architecture/capella/ scaffold writes compatibility.md.
Impact analysis. A change to a public interface (section 4) requires an impact analysis for every consumer before merge. Interface changes without one are rejected.
Defects and work. ISSUES.dox records real defects (found, symptom, status, resolution); TODO.dox records planned work. A defect is moved to "Resolved" with its fix, not deleted.
Generated artefacts (dist/, build/) are never committed and never consumed across products from a source tree. A product consumes only another product's dist/ or Conan package.
Documentation is part of the product. Configuration and templates live in the product's etc/. Source comments stay short and factual; history belongs in ADRs and issue records.

4. Interfaces are where assessment risk sits

Evidence is reused only if the boundaries between products are stable. The safety-relevant interfaces are the entries of the catalog in ../architecture/ARCHITECTURE.md section 4. Rules:

Each interface is documented by the product that provides it (its README, section "Interfaces").
An interface carries a version. Changing it invalidates the evidence of both sides until the impact analysis is closed.
Interface tests live with the provider and are run by the consumer's CI.
The GP to GA boundary (ga_interface.h) needs an explicit freedom-from-interference argument, because GA runs inside the GP process.

5. How to approach the safety case (order of work)

Fix the scope and the units (CERTIFICATION_PLAN section 2.1) and agree them with the independent safety assessor and the notified body before writing evidence.
State the application conditions for each generic product, starting from the RTE.
Close the requirement-to-test gaps of the RTE and safeComm; produce the coverage and MISRA reports on tagged builds.
Write the common-cause argument for the chosen redundancy (2oo2 with redundancy on identical CPUs) with the hardware supplier's inputs.
Assess GP and GA with the interface and the freedom-from-interference argument.
Assemble the specific application case: hazard analysis, data preparation verification, configuration and compatibility table.
Qualify the test tools used as evidence.
Rehearse the assessment on one tagged tuple before the formal one.

6. Evidence map

Evidence	Location
Framework SRS	platform/Platform_RTE/docs/requirements/SRS.dox
EN 50128 alignment	platform/Platform_RTE/docs/EN_50128_ALIGNMENT.dox
Application conditions (draft)	platform/Platform_RTE/docs/SAFETY_APPLICATION_CONDITIONS.dox
CCF analysis	platform/Platform_RTE/docs/safety/CCF_ANALYSIS.dox
MISRA report, coverage report	platform/Platform_RTE/docs/
Safety plan, CM plan, HARA, review and safety-case templates	platform/Platform_RTE/docs/templates/
Safe communication SRS, subset mapping, ADRs	platform/protocol_adapters/Platform_Protocol_SafeComm/docs/
Interface control documents (train, IL, CTC)	application/RBC_GP/interfaces/
Assessment roadmap	CERTIFICATION_PLAN.dox
Open defects and planned work	../../ISSUES.dox, ../../TODO.dox

7. Known gaps

The framework is not yet independently assessed (section 2.5).
Hot standby (platform-controlled invocation cadence) and N-way voting over a mesh are not implemented; claim 2oo2 with warm or cold standby only.
Cross-compare and staging in GP are still partly redundancy-aware; they belong to the GP safety case until moved into the Platform.
The DDS adapter is a stub and cannot carry an assessment claim.
safeComm is partly implemented; CFM, EuroRadio and RBC-RBC profiles are not.
Test tools are not qualified.