Status: draft for management presentation and for transfer to Capella, 2026-09-25.

Superseded by the Capella model (2026-10-02): see Capella architecture baseline (2026-10-02). Kept for its LC/IF/PC numbering. Where they differ the model wins; notably LC-05 site negotiation now belongs to RTE Redundancy Services. Written for: top managers (sections 1 to 4) and the modeller who will enter this in Capella (sections 5 to 8).

The names, responsibilities and status below come from the repository. The hardware layout is a proposal (section 4): the workspace tests the software in containers, and the commercial target platform is named in ARCHITECTURE.dox but its board layout is not defined in the code. Items that need a decision by the hardware architect are listed in section 8.

1. Summary

The RBC is a redundant Radio Block Centre for ERTMS/ETCS. It is built as two identical sites (WEST and EAST). At any moment one site is ONLINE and serves trains, the other is STANDBY and can take over.

Each site has three kinds of processing element:

Two vital channels, A and B. They run the same safety logic independently and compare every result (2oo2, SIL 4 target). If they disagree the platform enters the safe state.
One non-vital Gateway. It connects the vital channels to the outside world (train, interlocking, CTC), collects health and log data, and hosts the maintenance web page. It can carry bytes but cannot be trusted: the vital channels verify everything they receive.
A platform underneath (Safe Computing Platform) that provides voting, cross-comparison, checkpointing, safe state, site negotiation and communication, so the application does not depend on the operating system.

Two further servers, each on its own hardware, are planned: a Train Communication Server (radio/ISDN access) and an AI Diagnostic Server (log analysis). Neither is implemented; both are placeholders.

2. Context: who the RBC talks to

Actor	What it exchanges with the RBC	Today
Train (onboard EVC)	Position reports, session and movement-authority messages (Subset-026)	Simulator
Interlocking (IL)	Route commands and route/signal status	Simulator
CTC / dispatcher system	Train information, alarms	Simulator
Dispatcher / operator	Confirmation that the other site is not ONLINE; maintenance actions	Interim file trigger
Key Management Centre (KMC)	Off-line key files (Subset-114)	Files relayed by Gateway
Log collector / JRU	Event log (RFC 5424 syslog)	Optional
Customer network (GSM-R ISDN / FRMCS)	Radio path to trains	Not built

3. Logical breakdown

Numbering is the proposed Capella Logical Component id. "Tier" is the safety tier from the safety plan. "Status": built exists and is tested; stub exists as a stub; partial works with a stated limit; planned** placeholder only.

3.1 RBC application (runs in the vital channels)

Id	Logical module	Responsibility	Tier	Status
LC-01	ERTMS Procedure Engine (RBC_GP)	Runs the Subset-026 procedures per train: session start and end, position handling, movement-authority grant, emergency stop, shunting, handover.	Vital	built
LC-02	IL and CTC Adaptation (RBC_GA)	Turns interlocking route state and CTC requests into route and movement-authority decisions for the engine.	Vital	built
LC-03	Site Data (RBC_SA)	Track layout, signals, balises and routes for one site, generated from the railML model. Also builds the installers.	Vital data	built
LC-04	A/B Cross-Comparison	Each cycle both channels compare their computed sessions and outputs. A mismatch is a fault.	Vital	built
LC-05	Site Negotiation and Standby Sync	Decides which site is ONLINE, exchanges the state snapshot between sites, promotes and demotes.	Vital	partial (see 3.5)
LC-06	Key Management Client (Subset-114)	Verifies and decrypts key files delivered by the Gateway, writes the resulting key for the safe-communication layer.	Vital	partial (nothing consumes the key yet)

3.2 Safe Computing Platform (runs in the vital channels)

Id	Logical module	Responsibility	Tier	Status
LC-10	Application Manager	Runs the application in ordered stages every cycle and starts the checkpoint.	Vital	built
LC-11	Redundancy Services	Voting, cross-comparator, checkpoint (commit or discard the cycle's output), dual-channel link, state transfer, redundancy configuration.	Vital	built
LC-12	Safe State Manager	Owns the reaction to any fault: safe state or controlled reboot; the application only registers cleanup.	Vital	built
LC-13	Communication Services (PI-API, Flow)	Named data flows between processes, independent of transport.	Vital	built
LC-14	Operating-System Abstraction	Timer, log, memory, non-volatile storage and channel services behind one interface.	Vital	built
LC-15	POSIX OS Adapter	Implements LC-14 and the transport on Linux and macOS.	Vital target	built
LC-16	DDS Protocol Adapter	Intended to carry flows over DDS.	Non-safety today	stub
LC-17	Safe Communication (Subset-037, Subset-098)	Safety and authentication layer on the train and interlocking links. The library exists; it is not yet terminated in the vital channels.	Vital	partial

3.3 Gateway (non-vital)

Id	Logical module	Responsibility	Tier	Status
LC-20	Train Relay	Carries train traffic between the outside and both vital channels.	Non-vital	built
LC-21	Interlocking Relay	Same for the interlocking.	Non-vital	built
LC-22	CTC Relay	Same for CTC.	Non-vital	built
LC-23	Status and Health Broker	Collects status from every unit and publishes one site health summary.	Non-vital	built
LC-24	Log Forwarding (JRU)	Sends the channels' event log to a log collector as RFC 5424 syslog. Off unless configured.	Non-vital	built
LC-25	Key File Relay	Passes off-line key files from a directory to both channels without reading them.	Non-vital	built
LC-26	Maintenance Web	Read-only status page and JSON for maintenance staff.	Non-vital	built (no software update, no login)
LC-27	Takeover Confirmation Relay	Delivers the dispatcher's confirmation that the other site is not ONLINE to both channels.	Non-vital	in progress, interim file trigger

3.4 Separate servers and tooling

Id	Logical module	Responsibility	Tier	Status
LC-30	Train Communication Server	Access point between the customer network (GSM-R ISDN, FRMCS) and the RBC, reaching it through the Gateway.	Non-vital	planned
LC-31	AI Diagnostic Server	Collects logs from the RBC and the Train Communication Server and looks for likely problems with AI models.	Non-vital	planned
LC-40	Test Access Point and Simulators	Stand-ins for train, interlocking, CTC and the access point, plus the end-to-end test suite. Not deployed.	Tooling	built

3.5 Site role rules (agreed requirement)

A site never becomes ONLINE by itself. It becomes ONLINE only in one of three ways:

Negotiation between the two sites decides (normal start-up).
The other site announces that it is about to reach the safe state and reboot.
The other site stops responding and the dispatcher confirms (through the Maintenance tool) that it is not ONLINE. Silence alone never promotes a site.

If a site that lost contact meets a counterpart that took over meanwhile, it yields and becomes STANDBY. Status: rule 3 and the yield are being implemented; rules 1 and 2 exist. Standby synchronisation modes (cold, warm, hot) are described in application/RBC_GP/docs/STANDBY_AND_SITE_LINK_ARCHITECTURE.dox; warm is built behind a setting and not yet verified, hot is not built.

3.6 Product structure

The products that implement these modules, their grouping, dependencies and hand-over artifacts are a separate document: PRODUCT_STRUCTURE.dox.

4. Allocation to hardware (proposal)

Physical elements. "Site" elements exist once per site (WEST and EAST), so the RBC contains two of each.

Id	Hardware element	Per	Holds
PC-01	Vital Unit A	site	One vital channel. Built with one compiler (channel A).
PC-02	Vital Unit B	site	The second vital channel. Built with a different compiler (channel B) for diversity.
PC-03	Gateway Unit	site	The non-vital Gateway. Same enclosure or rack as the vital units, separated from them by process and network.
PC-10	Train Communication Server	RBC (one or more)	Own dedicated hardware. Planned.
PC-11	AI Diagnostic Server	RBC	Own dedicated hardware. Planned.
PC-20	KMC workstation	outside the RBC	Off-line key management. External.
PC-21	Maintenance terminal	outside the RBC	Browser for the maintenance page and the dispatcher confirmation.

Physical links:

Id	Link	Between	Carries
PL-01	Channel peer link	Vital Unit A and Vital Unit B of the same site	Cross-comparison and checkpoint
PL-02	Inter-site link	Vital Unit A (WEST) and A (EAST); B (WEST) and B (EAST)	Site negotiation, state snapshot
PL-03	Relay links	Gateway Unit and each vital unit of the same site	Train, interlocking and CTC envelopes, status, key files, takeover confirmation
PL-04	Customer network	Train Communication Server and trains	GSM-R ISDN or FRMCS radio path
PL-05	Service network	Gateway Unit, servers, maintenance terminal	Logs, status, maintenance access

4.1 Allocation matrix (logical module to hardware element)

X = runs there. The same module is instantiated on every element in its column, in each site.

Logical module	PC-01 Vital A	PC-02 Vital B	PC-03 Gateway	PC-10 Train Comm Server	PC-11 AI Server
LC-01 ERTMS Procedure Engine	X	X
LC-02 IL and CTC Adaptation	X	X
LC-03 Site Data	X	X
LC-04 A/B Cross-Comparison	X	X
LC-05 Site Negotiation and Standby Sync	X	X
LC-06 Key Management Client	X	X
LC-10 to LC-15 Platform (manager, redundancy, safe state, communication, OS abstraction, POSIX adapter)	X	X	X (subset)
LC-16 DDS Adapter	(stub)	(stub)
LC-17 Safe Communication	X	X		X (access-layer part)
LC-20 Train Relay			X
LC-21 Interlocking Relay			X
LC-22 CTC Relay			X
LC-23 Status and Health Broker			X
LC-24 Log Forwarding (JRU)	X (source)	X (source)	X
LC-25 Key File Relay			X
LC-26 Maintenance Web			X
LC-27 Takeover Confirmation Relay	X (receiver)	X (receiver)	X
LC-30 Train Communication Server				X
LC-31 AI Diagnostic Server					X

4.2 Deployment view

flowchart TB
  subgraph EXT[Outside the RBC]
    TRAIN[Train EVC]
    IL[Interlocking]
    CTC[CTC]
    KMC[KMC workstation]
    MT[Maintenance terminal]
  end
  subgraph SRV[Dedicated servers]
    TCS[PC-10 Train Communication Server]
    AI[PC-11 AI Diagnostic Server]
  end
  subgraph WEST[Site WEST]
    GW1[PC-03 Gateway Unit]
    A1[PC-01 Vital Unit A]
    B1[PC-02 Vital Unit B]
    GW1 <-->|PL-03| A1
    GW1 <-->|PL-03| B1
    A1 <-->|PL-01| B1
  end
  subgraph EAST[Site EAST]
    GW2[PC-03 Gateway Unit]
    A2[PC-01 Vital Unit A]
    B2[PC-02 Vital Unit B]
    GW2 <-->|PL-03| A2
    GW2 <-->|PL-03| B2
    A2 <-->|PL-01| B2
  end
  A1 <==>|PL-02| A2
  B1 <==>|PL-02| B2
  TRAIN <-->|PL-04| TCS
  TCS <--> GW1
  TCS <--> GW2
  IL <--> GW1
  IL <--> GW2
  CTC <--> GW1
  CTC <--> GW2
  KMC -.->|key files| GW1
  KMC -.->|key files| GW2
  MT -->|PL-05| GW1
  MT -->|PL-05| GW2
  GW1 -->|logs| AI
  GW2 -->|logs| AI
  TCS -->|logs| AI

4.3 Logical view

flowchart LR
  subgraph VITAL[Vital channel A or B]
    LC01[LC-01 ERTMS Procedure Engine]
    LC02[LC-02 IL and CTC Adaptation]
    LC03[LC-03 Site Data]
    LC04[LC-04 Cross-Comparison]
    LC05[LC-05 Site Negotiation]
    LC06[LC-06 Key Client]
    LC17[LC-17 Safe Communication]
    PLAT[LC-10..15 Safe Computing Platform]
    LC01 --> PLAT
    LC02 --> LC01
    LC03 --> LC01
    LC04 --> PLAT
    LC05 --> PLAT
    LC06 --> LC17
    LC17 --> PLAT
  end
  subgraph GW[Gateway non-vital]
    LC20[LC-20 Train Relay]
    LC21[LC-21 IL Relay]
    LC22[LC-22 CTC Relay]
    LC23[LC-23 Status Broker]
    LC24[LC-24 JRU Forwarding]
    LC25[LC-25 Key File Relay]
    LC26[LC-26 Maintenance Web]
    LC27[LC-27 Takeover Confirmation]
    LC23 --> LC26
  end
  LC20 <--> LC17
  LC21 <--> LC17
  LC22 <--> LC17
  LC25 --> LC06
  LC27 --> LC05
  LC24 -.-> LC23

5. Interfaces (for Capella component exchanges)

Id	From to	Content	Vital data?
IF-01	Train Communication Server to Train Relay (LC-30 to LC-20)	Train messages	Carried, not trusted
IF-02	Train Relay to Vital channels (LC-20 to LC-01)	Train envelopes, both channels	Verified by channel
IF-03	Interlocking / CTC relays to Vital channels	IL and CTC envelopes	Verified by channel
IF-04	Vital A to Vital B (LC-04)	Cross-comparison samples, checkpoint	Vital
IF-05	Vital channel to its counterpart in the other site (LC-05)	Role negotiation, state snapshot	Vital
IF-06	Vital channels to Status Broker (LC-23)	Status, log events	Non-vital
IF-07	Key File Relay to Key Client (LC-25 to LC-06)	Opaque key files	Verified by channel
IF-08	Takeover Confirmation Relay to Site Negotiation (LC-27 to LC-05)	Dispatcher confirmation	Non-vital trigger, acted on by vital side
IF-09	Maintenance Web to maintenance terminal	Status page and JSON	Non-vital
IF-10	Log Forwarding to log collector or AI server	RFC 5424 syslog	Non-vital

6. Design rules the model must show

Vital never depends on non-vital. The Gateway and servers carry bytes; every vital channel verifies what it receives.
A and B are independent. Separate processes, separate builds, compared every cycle.
Outputs leave only after the cycle's checkpoint confirms both channels took the same path.
The platform decides fault reactions; applications never trigger the safe state themselves.
Only one site is ONLINE. Promotion follows the three rules in 3.5.

7. How to enter this in Capella

Capella element	Use
System Analysis: actors	The rows of section 2
Logical Architecture: components	LC-xx from section 3. Group LC-01..06, 10..17 under "Vital channel", LC-20..27 under "Gateway"
Logical Architecture: exchanges	IF-xx from section 5
Product breakdown (PBS)	PRODUCT_STRUCTURE.dox; product = configuration item, linked to its LC-xx
Physical Architecture: node components	PC-xx from section 4
Physical Architecture: physical links	PL-xx from section 4
Allocation	Deploy each LC onto the PC columns of the matrix in 4.1
Properties	Add "tier" and "status" as property values on each LC

The existing model specification is architecture/capella/. It models the products; this document adds the RBC-level logical and physical view above it.

8. Open points for the hardware architect

Are Vital Unit A, Vital Unit B and the Gateway Unit three boards, or partitions of shared hardware? The code supports either; the safety case for A/B independence depends on the answer.
Where does the Train Communication Server sit relative to the two sites: one per site, or shared?
Is the KMC workstation on the service network or fully off-line (files carried by media)?
How is the dispatcher's confirmation authorised? The interim trigger is an unauthenticated file on the Gateway Unit; the real one needs the Maintenance tool with login (its own scoping item).
Time source and real-time settings for the vital units on the target platform.