Status: draft, 2026-10-23. Product breakdown of the RBC workspace: what the products are, how they are grouped, how they depend on each other, and what each one hands over. Written for managers and for anyone entering the product breakdown into a model. Logical modules (LC-xx) and hardware elements (PC-xx) are defined in LOGICAL_ARCHITECTURE_AND_HW_ALLOCATION.dox; the cross-product rules are in ARCHITECTURE.dox. Each product's own README is the source of truth for its internals.
This workspace is a proof of concept: it exists to test the architecture's assumptions in running code, so the product breakdown below describes what is built here, and section 6 lists what an RBC needs that is not built yet.
Product = configuration item = separately versioned Git repository.** Folder name, product name and repository name are the same (see the root CLAUDE.md). Every product has a VERSION file and is released by Git tag. All products are at 0.1.0 except the two placeholders (0.0.0). The hierarchy below groups products by what they belong to, which is not always the folder they sit in: Platform_Protocol_JRU is part of RBC_GP but sits under platform/protocol_adapters/ because it implements a seam Platform_RTE defines (section 7).
Safety levels use the EN 50129 terms: SIL 4 (safety-related) and SIL 0 (not safety-related). Tooling is never deployed and carries no SIL.
1. Hierarchy
flowchart TB
SYS["RBC system"]
SYS --> PRTE["Platform_RTE group"]
SYS --> GP["RBC_GP"]
SYS --> GA["RBC_GA"]
SYS --> SA["RBC_SA"]
SYS --> TST["Test environment (not deployed)"]
SYS --> SRV["Dedicated servers (placeholders)"]
PRTE --> RTE["Platform_RTE"]
PRTE --> SCM["Platform_Protocol_SafeComm"]
PRTE --> OSA["Platform_OS_POSIX"]
PRTE --> DDS["Platform_Protocol_DDS (stub)"]
PRTE --> TC["Platform_Toolchain_MacOS / Linux / QNX / FreeRTOS (not deployed)"]
GP --> KM["Platform_Protocol_KM114, Platform_Protocol_KM038"]
GP --> JRU["Platform_Protocol_JRU"]
GP --> MW["RBC_Maintenance_Web"]
TST --> TENV["RBC_Test_Env, RBC_Test_CommServer"]
TST --> SIM["RBC_Test_Sim_Core / Train / IL / CTC"]
SRV --> TCS["RBC_TrainCommServer"]
SRV --> AID["RBC_AI_Diagnostic_Server"]
Folder rules (the root CLAUDE.md): a product under services/ gets its own hardware and reaches the RBC only through the Gateway; a product under application/ runs on the same hardware as an RBC process; a product under platform/protocol_adapters/ implements a seam the platform defines.
2. Product catalogue
Logical modules and hardware elements refer to the numbering in the logical architecture document.
2.1 Platform_RTE group
| Product | Purpose | SIL | Logical modules | Hardware | Hands over |
| Platform_RTE | Safe Computing Platform core: application manager, voting, cross-comparator, checkpoint, dual-channel link, site role, state transfer, safe state, OS abstraction, flows | SIL 4 | LC-10 to LC-14 | PC-01, PC-02, PC-03 (subset) | Static libraries and headers, CMake package RteFramework, Conan rteframework |
| Platform_Protocol_SafeComm | Safe communication library (Subset-037 and Subset-098 profiles); train link terminated in A/B, off by default | SIL 4 (safety and crypto layers), SIL 0 (address and config) | LC-17 | PC-01, PC-02 | Libraries, Conan safecommframework |
| Platform_OS_POSIX | POSIX implementation of the OS adapter and transport | SIL 4 target | LC-15 | PC-01, PC-02, PC-03 | Library, Conan rteposixosadapter |
| Platform_Protocol_DDS | Flow adapter stub delegating to the platform transport; no DDS yet, kept as a placeholder for a future protocol adapter | Stub | LC-16 | none yet | Library |
| Platform_Toolchain_MacOS, _Linux, _QNX, _FreeRTOS | Compiler and target wiring for each platform (QNX is scaffold only; FreeRTOS builds the platform, not the RBC) | Tooling | none | none | CMake toolchain files |
2.2 RBC_GP and its sub-products
| Product | Purpose | SIL | Logical modules | Hardware | Hands over |
| RBC_GP | The RBC itself: ERTMS procedure engine, the A/B channel pair with cross-comparison, the site role client, and the Gateway services | SIL 4 (A/B), SIL 0 (Gateway) | LC-01, 04, 05, 06, 20-25, 27 | PC-01, PC-02, PC-03 | RBC executables, shared library librte_gp, dist/<platform>/, Conan rterbc2oo2gp |
| Platform_Protocol_KM114 | Subset-114 key-file codec (encode, verify, decrypt); linked into the A/B channels only, never into the Gateway; A and B cross-check the decoded KMAC over the peer link | Security function; runs inside the SIL 4 channel process | LC-06 | PC-01, PC-02 | Library |
| Platform_Protocol_KM038 | Subset-038 KMC-to-KMC codec; no consumer in the RBC | Security function | none | none | Library |
| Platform_Protocol_JRU | Event log sink, RFC 5424 syslog; implements the platform's rte_osadapter_log_t | SIL 0 | LC-24 | PC-03 | Library |
| RBC_Maintenance_Web | Status page and JSON, linked into the Gateway process; opt-in mTLS-gated software update of the four SIL 0 Gateway binaries; interim issuer of the dispatcher takeover confirmation | SIL 0 | LC-26 | PC-03 | Library |
2.3 RBC_GA and RBC_SA
| Product | Purpose | SIL | Logical modules | Hardware | Hands over |
| RBC_GA | Generic application: route and movement-authority logic, interlocking adapter (A/B) and CTC adapter (Gateway) | SIL 4; CTC adapter SIL 0, its commands checked on the SIL 4 side | LC-02 | PC-01, PC-02, PC-03 | Shared library librte_rbc2oo2_ga; no Conan recipe (built with GP) |
| RBC_SA | Site data (tracks, signals, balises, routes for one site) generated from railML, and the installer packaging | SIL 4 data | LC-03 | PC-01, PC-02 | Site data libraries, self-extracting installers, Conan rterbc2oo2sa |
2.4 Test environment (not deployed)
| Product | Purpose | Hands over |
| RBC_Test_Env | End-to-end test environment: Docker topology, Robot suites, web runner | Scripts, test suites |
| RBC_Test_CommServer | SIL 0 access-point stub used in tests | Executable, image |
| RBC_Test_Sim_Core | Shared simulator code and the Python mirror of the RBC wire format | Wheel |
| RBC_Test_Sim_Train, _IL, _CTC | Train, interlocking and CTC simulators | Wheels, images |
2.5 Dedicated servers (placeholders)
| Product | Purpose | SIL | Logical modules | Hardware | State |
| RBC_TrainCommServer | Access point between the customer network (GSM-R ISDN, FRMCS) and the RBC, through the Gateway | SIL 0 | LC-30 | PC-10 | Placeholder repository, not scoped |
| RBC_AI_Diagnostic_Server | Collects RBC and access-point logs and analyses them with AI models | SIL 0 | LC-31 | PC-11 | Placeholder repository, not scoped |
3. Dependencies between products
Direction is always downward; nothing depends on the test environment or the toolchains. The one place the direction is not strict is that RBC_GA and RBC_SA read RBC_GP headers at build time, which is why the GP-GA boundary is a versioned interface.
flowchart TB
GP[RBC_GP] --> RTE[Platform_RTE]
GP --> POSIX[Platform_OS_POSIX]
GP --> SA[RBC_SA]
GP --> GA[RBC_GA]
GP --> SC[Platform_Protocol_SafeComm]
GP --> JRU[Platform_Protocol_JRU]
GP --> K114[Platform_Protocol_KM114]
GP --> MW[RBC_Maintenance_Web]
GA -.->|"headers, versioned interface"| GP
SA -.->|"headers at build time"| GP
POSIX --> RTE
SC --> RTE
JRU --> RTE
DDS[Platform_Protocol_DDS] --> RTE
RTE --> OS["Operating system and hardware"]
POSIX --> OS
| Rule | Meaning |
| Application depends on platform, never the reverse | A platform change that breaks the RBC is absorbed by the RBC |
| Products consume each other only through dist/ or a Conan package, never through another product's src/ or build/ | Keeps products independently buildable; the documented exceptions are the header-only reaches between RBC_GP, RBC_GA and RBC_SA |
| SIL 4 code never depends on SIL 0 code | Gateway, servers and the access-point stub carry bytes; the SIL 4 channels verify everything they receive |
4. Product to logical module to hardware
| Product | Logical modules | Hardware elements |
| RBC_GP | LC-01, 04, 05, 06, 20-25, 27 | PC-01, PC-02 (SIL 4), PC-03 (Gateway) |
| RBC_GA | LC-02 | PC-01, PC-02, PC-03 (CTC adapter) |
| RBC_SA | LC-03 | PC-01, PC-02 |
| Platform_RTE, Platform_OS_POSIX | LC-10 to LC-15 | PC-01, PC-02, PC-03 |
| Platform_Protocol_SafeComm | LC-17 | PC-01, PC-02 |
| Platform_Protocol_JRU | LC-24 | PC-03 |
| Platform_Protocol_KM114 | LC-06 | PC-01, PC-02 |
| RBC_Maintenance_Web | LC-26 | PC-03 |
| RBC_TrainCommServer | LC-30 | PC-10 |
| RBC_AI_Diagnostic_Server | LC-31 | PC-11 |
| Test products | LC-40 | none (test machine) |
5. Entering this in a model
| Model element | Source in this document |
| Product breakdown structure (or a configuration-item tree) | The hierarchy in section 1 |
| Configuration item | One per product in section 2, with SIL, version and state as properties |
| Traceability to the logical view | Section 4: each product realises the listed LC-xx |
| Deployment to hardware | Section 4: each product is deployed on the listed PC-xx |
| Product dependencies | Section 3 |
6. Not built in this proof of concept
| Piece | Note |
| RTE composition | Today only the rule that an RTE release is a tuple of the Platform_RTE, OSAdapter and SafeComm tags; no product records which versions were integrated and qualified together |
| Maintenance and diagnostics adapter | Publishing SIL 4 diagnostic data to maintenance systems; RBC_Maintenance_Web covers only a status page |
| Configuration tool | Building and checking the site configuration outside the RBC_SA generators |
| Peer-RBC, JRU and maintenance simulators | The test environment simulates trains, interlocking and CTC only |
| Hardware platform | Containers stand in for channels A, B and the Gateway; the hardware platform is not chosen |
7. Open points
- Platform_Protocol_JRU is part of RBC_GP but sits under platform/protocol_adapters/, because it implements a seam (rte_osadapter_log_t) that Platform_RTE defines. Decide whether the repository moves or the folder rule gets an exception.
- The two key-management codecs could be one product (Subset-038 and Subset-114 share their crypto and framing); today they are Platform_Protocol_KM114 and Platform_Protocol_KM038.
- Key management is a security function, not a SIL 4 safety function, yet Platform_Protocol_KM114 is linked into the SIL 4 channel processes. Running it there needs a freedom-from-interference argument, or the codec is developed to SIL 4.
- Each A/B channel decodes the whole KMAC. A split key (one part per channel, so no channel alone can produce or accept a valid message) would need a different KM114 consumption design; worth testing here.
- The redundancy and quorum configuration lives in application/RBC_GP/etc/config/, while the rest of the site data is in RBC_SA. Decide whether it is site data.
- RBC_Maintenance_Web serves status, the SIL 0 software update and, for now, the takeover confirmation; dispatcher commands are not built, and their safety-related path must stay on the SIL 4 side.
- The SIL 4 and SIL 0 parts of RBC_GP share one repository. Whether they should be split into separate configuration items for the safety assessment is a question for the safety manager (../safety/CERTIFICATION_PLAN.dox defines the assessment units).
1.18.0