How the RBC_Template workspace maps onto the Reference CCS Architecture (RCA) and the OCORA Safe Computing Platform (SCP) model. Product responsibilities and interfaces are in ../architecture/ARCHITECTURE.md; the PI-API surface is in RCA-OCORA-PI-API.dox.

1. Executive Summary & RCA Objectives

The Reference CCS Architecture (RCA) initiative defines a modular, standardized architecture for railway command, control, and signaling systems (such as Radio Block Centres, Interlockings, and Onboard units). Its core objectives are:

Decoupling Application from Platform: Independent lifecycles and certifications for railway signaling logic vs. underlying compute and communication infrastructure.
Standardized Interfaces: Use of standard APIs (OCORA Safe Computing Platform - SCP Runtime Environment / PI-API) so application software is strictly platform-independent.
Transport & Hardware Independence: Elimination of direct dependencies on network protocols, IP addresses, or hardware drivers inside safety applications.
Interoperability & Multi-Vendor Interchangeability: Clear layering allowing Generic Applications (GA) and Specific Applications (SA) to run on any compliant Safe Computing Platform (SCP/GP).

2. RCA layering in RBC_Template

flowchart TB
    SA["Specific Application (SA): RBC_SA<br/>Site data, topology, operational rules"]
    GA["Generic Application (GA): RBC_GA<br/>Route logic, Interlocking / CTC / Train state logic"]
    GP["Generic Platform (GP): RBC_GP<br/>2oo2 redundancy executive, safety voters<br/>Opens logical channels to SCP RTE"]
    RTE["Safe Computing Platform (SCP) / RTE: Platform_RTE<br/>Channel Service, Safe State, Clocksync, Diagnostics<br/>Resolves channel/flow configuration to ProtocolAdapters"]

    SA --> GA --> GP --> RTE

    subgraph PA["ProtocolAdapters"]
        direction TB
        PA1["Platform_RTE UDP Adapter"]
        PA2["Platform_RTE TCP Adapter"]
        PA3["Platform_Protocol_DDS"]
        PAD["Encapsulates transport protocols;<br/>uses raw sockets from active OSAdapter to transmit data."]
    end

    subgraph OA["OSAdapters"]
        direction TB
        OA1["Platform_OS_POSIX (Linux)"]
        OA2["Platform_OS_QNX (planned)"]
        OA3["Platform_OS_FreeRTOS (planned)"]
        OAD["Encapsulates OS primitives:<br/>memory, timers, tasks, mutexes, NVM, raw sockets."]
    end

    RTE --> PA
    RTE --> OA

Layer Responsibilities

Specific Application (SA):
- Contains track topology, site rules, and station data.
- Decoupled from generic railway algorithms and platform code.
Generic Application (GA):
- Implements signaling rules (ETCS Level 2/3 RBC, Interlocking state machines).
- Platform-independent; compiled as shared or static libraries consumed by the Generic Platform.
Generic Platform (GP):
- Houses the dual-channel (2oo2 / 2x2oo2) redundancy management, cross-comparators, and synchronized cycle execution.
- Communicates strictly via SCP logical channels (ab-peer, ab-negotiate, ab-crosscompare, ab-relay-*).
- Does not include OS, socket, or transport headers.
Safe Computing Platform (SCP) Runtime Environment (Platform_RTE):
- Provides deterministic execution, safety voters, safe-state enforcement, and the Channel Service.
- Evaluates channel configuration and binds logical channels to concrete ProtocolAdapters.
ProtocolAdapters (rte_protocol_adapter):
- Provide protocol-specific message framing and serialization (UDP, TCP, DDS).
- Completely agnostic of the underlying operating system by calling raw socket operations (rte_os_socket_ops_t) provided by the active OSAdapter.
- Configured per channel or flow (e.g. DDS for trackside bus, UDP for local peer links).
OSAdapters (rte_osadapter):
- Abstract the host operating system (POSIX, QNX, FreeRTOS).
- Expose OS primitives (timers, memory pools, mutexes, threads, NVM, reboot) and raw socket operations.

3. OCORA terminology

RCA (Reference CCS Architecture): the modular, vendor-open architecture for Command, Control and Signalling.
OCORA (Open CCS Onboard Reference Architecture): the onboard-focused sibling initiative and the source of the concrete API. SCP (Safe Computing Platform) is its term for the hardware plus runtime that hosts safety-relevant application logic, specified in OCORA-TWS03-030_SCP_Specification_of_the_PI_API_between_Application_and_Platform.pdf (v2.0, July 2022, github.com/OCORA-Public/Publications, release R6).
Three layers: the Safe Computing Platform (hardware, hypervisor, virtual machines and the Run-Time Environment that provides deterministic scheduling, voting, fault and redundancy management and hardware supervision); the PI API (the boundary: a POSIX subset plus extensions, notably flows.h with fl_open, fl_close, fl_send, fl_receive, fl_getattr, fl_setattr); and the Functional Actor (the safety-relevant application logic, deployed as N replicas that the Platform manages).
Voting is transparent below the API. The Platform votes the outputs of all replicas of an actor, and a replica cannot see that others exist. In RBC_Template, GP's cross-compare is still partly visible to the application (see ../safety/SAFETY_AND_QUALITY_PLAN.dox, known gaps).

RBC_Template product	OCORA role
Platform_RTE	RTE: scheduling, voting, redundancy, watchdog, timers, safe state
Platform_OS_POSIX	Hardware and OS layer beneath the RTE
Platform_Protocol_SafeComm	A Platform-provided service: the PI API expects the platform to supply network security, redundancy and replication so applications do not implement them
Platform_Protocol_DDS	Flow messaging OSAdapter (stub); OCORA's own reference uses DDS for Flows
rte_flow (in Platform_RTE)	The PI-API-shaped surface a Functional Actor may call. It is a boundary, not a product
RBC_GP, RBC_GA, RBC_SA	The Functional Actor and its data
RBC_Test_CommServer, RBC_Test_Sim_*, RBC_Test_Env	Outside the stack: external systems and test tooling
Platform_Toolchain_*	Build infrastructure

The boundary is still leaky: RBC_GP calls the voter, cross-comparator, checkpoint, watchdog and safe-state services directly rather than only through a Flow-shaped surface. Closing it (moving the cross-compare decision and the resulting safe-state transition beneath rte_flow) is tracked in the root TODO.dox.

4. How RBC_Template fulfils the RCA principles

3.1 Strict Separation of Concerns

No Transport Leakage into Applications: Functional applications only call rte_channel_* or rte_flow_*. They never touch IP addresses, ports, DDS topics, or POSIX file descriptors.
Pluggable ProtocolAdapters: Transport choices (UDP, TCP, DDS) are determined declaratively by configuration, allowing seamless transitions from test environments (UDP) to production trackside deployments (DDS).

3.2 Standard Configuration Management

In accordance with RBC_Template project rules:
- All configuration files and templates are centralized in the [product]/etc directory (e.g. RBC_GP/etc/config/, RBC_GA/etc/, RBC_SA/etc/).
- This ensures consistent deployment across environments without code modification.

3.3 Deterministic Redundancy and Safe State

RBC_Template implements 2oo2 voting, cross-comparison, and deterministic state synchronization.
Any integrity violation or protocol disagreement triggers transition to a well-defined Safe State (SIL 4 compliance under CENELEC EN 50128).

5. RTE composition and assessment units

In RCA the Safe Computing Platform (RTE) delivers safe communication together with the execution environment. In this workspace the RTE is therefore a composition of two separately assessed products:

Platform core (platform/Platform_RTE plus the OSAdapter for the target OS), and
Safe communication (platform/protocol_adapters/Platform_Protocol_SafeComm), kept as its own product so it can be reused outside an RBC.

An RTE release is identified by the tuple (Platform core tag, OSAdapter tag, safe communication tag). docs/safety/CERTIFICATION_PLAN.dox section 2.1 defines what is assessed once, what is assessed per application class, and what is assessed per project. architecture/capella/ models the same split (one Capella library per assessed product, composed in the project model).

6. Open questions

Whether Platform_Protocol_SafeComm should be pulled fully under the RTE as a required Platform service or stay an optionally linked library (today it is delivered inside the RTE composition but remains a separate product).
Sequencing of the PI-API work: transparent voting under rte_flow, a real DDS OSAdapter, then moving GP's live A/B links and the site-negotiation link onto it. Tracked in the root TODO.dox.
Whether to route a real DDS library's network hooks through the OSAdapter (see Platform_Protocol_DDS/CLAUDE.md).

7. Sources

OCORA PI API specification: OCORA-TWS03-030_SCP_Specification_of_the_PI_API_between_Application_and_Platform.pdf (v2.0, July 2022), github.com/OCORA-Public/Publications, release R6.
DB Digitale Schiene Deutschland, "SIL4 Cloud" research report, https://digitale-schiene-deutschland.de/Downloads/Report%20-%20SIL4%20Cloud.pdf.
RCA OCORA: Safe Computing Platform using open standards, High Integrity Software Conference, https://www.his-conference.co.uk/session/rca-ocora-safe-computing-platform-using-open-standards.