CENELEC EN 50126 / EN 50128 / EN 50129 & TSI CCS (EU Directive 2016/797)

Document ID**: RBC_Template-SAF-PLN-001
Target Integrity**: CENELEC SIL 4 / TSI CCS Class A Trackside Subsystem
Status**: APPROVED BASELINE

1. Executive Summary & Regulatory Context

This document establishes the official certification, independent assessment, and conformity roadmap for the software products comprising the RBC_Template Reference CCS Architecture (RCA).

Railway safety and interoperability in the European Union (and international adoptions) operate under two distinct, complementary legal and normative frameworks:

1. The CENELEC Safety Framework (Directive (EU) 2016/798, CSM-RA Regulation (EU) 402/2013):
   • Governed by EN 50126 (RAMS Lifecycle), EN 50128 (Software SIL 4), and EN 50129 (Electronic Systems for Signalling).
   • Audited and certified by an Independent Safety Assessor (ISA).
   • Outputs: Safety Assessment Report (SAR) and SIL 4 Safety Certificate.
2. The Interoperability Framework (Directive (EU) 2016/797, TSI CCS Regulation (EU) 2023/1695):
   • Evaluated by an accredited Notified Body (NoBo).
   • Assesses compliance with Mandatory Specifications (UNISIG Subset-026, Subset-037, Subset-039, Subset-098, etc.).
   • Outputs: EC Certificate of Conformity for Interoperability Constituents (IC) (enabling CE Marking) and EC Certificate of Verification for Trackside CCS Subsystems.

2. Product Architecture & Constituent Classification

flowchart TB
    SA["RBC Specific Application (SA) - Track Topology & Rules<br/>→ CENELEC EN 50129 Specific Application Safety Case (SA-SC)"]
    GA["RBC Generic Application (GA) - Signaling & Route Logic<br/>→ CENELEC EN 50128 SIL 4 Generic Application Safety Case (GA-SC)"]
    GP["RBC Generic Platform (GP) - 2oo2 Voter & Redundancy Executive<br/>→ Trackside CCS Subsystem (TSI CCS Module SB+SD / SH1)<br/>→ CENELEC EN 50129 Generic Product Safety Case (GP-SC)"]

    SA --> GA --> GP

    GP -->|PI-API / Logical Channel Service| RTE

    subgraph RTE["Platform_RTE - Safe Computing Platform / RTE (delivered composition)<br/>→ thin composite safety case: integration, interface, application conditions"]
        direction LR
        CORE["Platform core (Platform_RTE)<br/>+ OSAdapter (Platform_OS_POSIX)<br/>→ own EN 50128 SIL 4 evidence"]
        SCOMM["Safe communication (Platform_Protocol_SafeComm)<br/>SS-037 / SS-098 / RaSTA hook<br/>→ own EN 50128 / EN 50159 evidence<br/>→ TSI IC with CE mark"]
    end

    RTE --> POSIX["Platform_OS_POSIX (OSAdapter SIL 4)<br/>repo: Platform_OS_POSIX"]
    RTE --> SCADAPT["Platform_Protocol_SafeComm<br/>repo: Platform_Protocol_SafeComm"]
    RTE --> DDS["Platform_Protocol_DDS (Trackside bus adapter, STUB today)<br/>repo: Platform_Protocol_DDS"]

2.1 Assessment units and the RTE composition

Decision (2026-09): five assessed units and one delivered composition.

• An RTE release is a tuple: (Platform core tag, OSAdapter tag, safe communication tag). GP/GA/SA evidence references the tuple, not the individual repositories.
• Safe communication is a separate product so it can be reused (EVC, other RBCs, RBC-RBC), and it is delivered inside the RTE. The reuse claim is only partial today: safecomm::cfm uses the RBC_Template OAL and TCP transport, so only safecomm::safety (SaF, MAC) has no dependency on the core. Either claim reuse for the safety part only, or state that reusing the full stack means taking the RTE.
• safecomm::ale is non-vital (role-C gateway). If the RTE contains it, the RTE case must show the vital / non-vital separation of ADR-002.
• The hardware platform (not chosen yet) carries its own certificate; the common-cause-failure argument for identical CPUs belongs to the SA / system level (IEC 61508-6 Annex D style beta-factor analysis, compiler diversity per ADR-008, physical separation, independent V&V).

3. Product-by-Product Assessment Matrix

4. Detailed Independent Assessment Strategies

4.1 Product 1: Platform_Protocol_SafeComm (Standalone Interoperability Constituent)

Platform_Protocol_SafeComm is deliberately architected to be vendored, validated, and certified completely independently of any specific RBC or EVC application.

A. Scope of Delivery

• Vital C99 Library: libsafecomm_safety.a (Pure SIL 4: SaF, 3DES CBC-MAC, KSMAC derivation, 2oo2 split-send).
• Non-Vital Gateway Library: libsafecomm_ale.a (Application Layer Entity: bearer concentration & peer mapping).
• RBC_Template Protocol Adapter Binding: libsafecomm_adapter.a (Pluggable rte_protocol_adapter_ops_t).

B. ISA Assessment Activities (EN 50128 / EN 50159)

1. Safety Plan & Life-Cycle Verification: Review of EN 50128 phase outputs (Requirements, Architecture, Design, Implementation, Verification, Validation).
2. Defensive Programming & MISRA Compliance: Verification of MISRA C:2023 (Mandatory & Required) with zero deviations; any deviation recorded per MISRA Compliance:2020. Static analysis via cppcheck / PC-lint.
3. Transmission Safety Case (EN 50159 Cat 2/3):
   • Hazard mitigation against: Message corruption (3DES CBC-MAC), Replay (Monotonic sequence counters), Delay & Loss (Supervision timers T_SUPERVISION), Insertion (KSMAC authentication), Masquerade (AU1/AU2/AU3 mutual identification).
4. V&V Evidence:
   • 100% Statement, Branch, and MC/DC code coverage.
   • Memory verification: Zero dynamic memory allocation (malloc/free strictly prohibited).
   • Side-channel timing verification: Constant-time MAC comparison (safecomm_mac_verify).

C. NoBo Assessment Activities (TSI CCS / CE Marking)

1. Conformity Assessment Module: Module CB (EC-Type Examination) + Module CD (Quality Management System) OR Module CH1 (Full Quality Management with Design Examination).
2. Test Specifications:
   • Verification against UNISIG Subset-037 (EuroRadio FIS).
   • Verification against UNISIG Subset-098 (RBC-RBC Safe Communication Interface).
   • ERTMS/ETCS functional conformity test campaign: scenarios from Subset-026 and the subset applicability matrix, scope agreed with the NoBo.
3. Deliverable: EC Certificate of Conformity as Interoperability Constituent (IC) with official CE Marking.

4.2 Product 2: Platform_RTE (Safe Computing Platform RTE)

A. Scope & Justification

• Platform_RTE fulfills the OCORA Safe Computing Platform (SCP) runtime specification.
• Because TSI CCS regulates railway functional subsystems rather than generic compute engines, Platform_RTE is certified as an EN 50128 SIL 4 Pre-Certified Software Platform via the ISA.

B. Deliverables for Application Developers

1. Generic Platform Safety Case (GP-SC): EN 50129 SIL 4 demonstration for 2oo2 voting, safe-state latching, and clock synchronization.
2. Safety Manual for Application Developers (Safety Application Conditions - SRACs):
   • Mandatory rules for application tasks (e.g. static memory layout, stack margin, maximum execution cycle time).
   • Constraints on channel creation and flow registrations.

4.3 Product 3: RBC_GP + RBC_GA (Generic RBC Product)

A. Scope & Integration

• The Generic Platform (GP) executable integrates the RTE, OSAdapter, and GA signaling logic into the full Generic RBC Product.
• Manages 2oo2 redundant worker instances (Channel A and Channel B) and platform failover.

B. ISA & NoBo Activities

1. ISA: Issues the SIL 4 System Safety Certificate based on the Generic Product Safety Case (GP-SC).
2. NoBo: Conducts the EC Verification of the Trackside CCS Subsystem (Module SB + SD or SH1):
   • Full validation against UNISIG Subset-026 (ERTMS Functional Rules).
   • Full validation against UNISIG Subset-039 (RBC Handover Procedures).
   • Full validation against UNISIG Subset-094 (Interlocking Interface).

4.4 Product 4: RBC_SA (Specific Application Deployment)

A. Scope

• Instantiates the track geometry, balise placement, signaling boundaries, and operational rules for a concrete railway line.

B. Safety Assurance

1. Data Preparation V&V:
   • Independent verification of engineering data against source signaling plans.
   • Automated rule checking with Tool Class T2 validators.
2. Specific Application Safety Case (SA-SC):
   • Demonstrates that all Generic Platform SRACs and Generic Application constraints are fulfilled by the site data.
   • Authorizes revenue service with passenger trains on the target infrastructure.

4.5 Current implementation status (evidence gaps)

Sections 3 and 4 describe the target assessment scope. The code today:

Open assessment risks

1. GA runs inside the GP process (shared library). Separate GA assessment needs either a freedom-from-interference argument (address space, MPU) or GA developed to SIL 4. The strongest existing barrier is GP's MA gate (the only path that grants Movement Authority) plus validated setters; whether it is sufficient has not been assessed.
2. ga_interface.h is the assessed boundary between GP and GA, and GA/SA also need GP's headers at build time. Version the interface and record it in the compatibility table; any change invalidates evidence on both sides.
3. Diversity on identical CPUs (2oo2 with redundancy on one hardware platform): compiler diversity (gcc/clang, ADR-008) mitigates systematic faults only; physical and temporal separation and independent V&V must carry the rest of the common-cause argument.

5. Certification Roadmap & Milestones