The Capella models exported on 2026-10-02 are the architecture this workspace implements. Where they and an older page in this folder disagree, the model wins; LOGICAL_ARCHITECTURE_AND_HW_ALLOCATION.dox (the 2026-09-25 draft that was entered into Capella) is kept for its history and its LC/IF/PC numbering only.

The exports themselves are not in the repository. They live in the project's document store and are read-only from here: change the model, re-export, then update this page.

Sources

Document	Model	Version	Scope
RBC-GP-ARCH-CAP	RBC_GP	0.1 (2026-10-02, product 0.6)	Whole RBC: system analysis, logical architecture of all products, GP physical architecture and EPBS
RBC-GA-NCBIR-ARCH-CAP	RBC_GA_NCBIR	0.1 (product 0.3, base modules 0.4)	Generic application for PKP PLK: base GA modules plus PL modules
OSA-ARCH-CAP	OSA	0.1 (product 0.2)	OS adapter / SOUP POSIX RTOS
HWP-ARCH-CAP	SCP	0.1 (product 0.5)	Safety Computing Platform hardware, vendor-neutral (candidate: Kontron VPX DEV)
CSV-ARCH-CAP	TrainCommServer	0.1 (product 0.5)	ISDN / FRMCS access server, SIL 0
AID-ARCH-CAP	AI_Diagnostic	0.1 (product 0.5)	Off-line log analysis, SIL 0

Realisation chain in the model: SA -> GA -> GP -> RTE / SafeComm / RTEC (RTE + OSA) -> SCP. Each product model is derived from RBC_GP (system -> subsystem) with GenericTrace links; shared exchange items live in LIB_RBC_Interfaces.

Model product to repository product

Model element (LA)	SIL	Repository product
Generic Product (RBC-GP)	4 (Gateway 0)	application/RBC_GP
Generic Application (RBC-GA) / RBC_GA_NCBIR	4	application/RBC_GA (base modules only; no PL modules yet)
Site Application (RBC-SA)	4 (data)	application/RBC_SA
Safe Framework (RTE)	4	platform/Platform_RTE
OS Adapter (part of Safe Framework) / OSA SOUP	4	platform/os_adapters/Platform_OS_POSIX
Safe Communication Framework (SafeComm)	4 (ALE, config: 0)	platform/protocol_adapters/Platform_Protocol_SafeComm
Key Management Client (in GP)	4	application/Platform_Protocol_KM114, used by RBC_GP ab_gp_km114_client.c
Event Forwarder (JRU/Syslog) (in GP Gateway)	0	platform/protocol_adapters/Platform_Protocol_JRU
Maintenance Web UI (in GP Gateway)	0	application/RBC_Maintenance_Web
Communication Server (ISDN/FRMCS)	0	services/RBC_TrainCommServer (placeholder)
AI Diagnostic	0	services/RBC_AI_Diagnostic_Server (placeholder)
Hardware / SCP	4	none (containers stand in for CPUA, CPUB, Gateway)

RBC_GP logical components

Model component	Code today
ERTMS Procedure Engine	RBC_GP/src/application/AB/GP/ertms, ertms_procedures, state_machines
Route & Train Database	GP/db, GP/train
MA Logic Gate (calls GA through ga_interface.h, ab_ga_ma_adaptation_init)	GP/ma_logic, GP/ga_interface
Key Management Client	GP/com/ab_gp_km114_client.c
Site Role Client (IF-05, declarative)	GP/com/ab_gp_channel_negotiate.c (state codec, transfer policy, local facts), GP/com/ab_gp_site_status.c (readiness); negotiation is in RTE rte_site_role since ADR-040 step 2, but GP still forwards the A/B peer-link frames until step 5 (gap G1)
Gateway: Train / IXL / CTC relays, Status Broker, Key File Relay, Takeover Confirmation Relay	RBC_GP C/gateway_c_* (role C processes); the takeover token builder is C/status/gateway_c_takeover_confirm.cpp, the interim issuer RBC_Maintenance_Web (POST /api/takeover/confirm, mTLS)

RBC_GA_NCBIR

Model component	Code today
CTC Adapter	RBC_GA/src/AB/ctc, src/C/ctc
IL Adapter	RBC_GA/src/AB/il, src/C/il
MA Logic Adaptation	RBC_GA/src/AB/ma_logic_adaptation
Site Projection (implemented by RBC-SA, consumed by GA)	RBC_GA/include/ab_siteGA.h + RBC_SA generated tables
PL modules: CMI / CTC desk, srk adaptation (signalling, line blocks, level crossings), traffic rules (shunting / OSM, level borders LTA / RADIOSTOP, manual route release), PKP PLK parameters	not started

Safe Framework (RTE) components

Model component	Code today (platform/Platform_RTE/src)
Application Manager	app/appmanager
Redundancy Services (dual transfer, cross-comparison, checkpoint, site role, state transfer, takeover verification)	redundancy/{dual,cross_comparator,voter,checkpoint,state_transfer,election,site_role} - site role and takeover verification in redundancy/site_role (ADR-040 steps 1-4); remaining G1 work is step 5
Safe State Manager	utils/safestate, oal/reboot
Communication Services (Flows / PI API)	oal/flow - GP still bypasses it for peer links (G3)
OS Abstraction Layer	oal/*
Watchdog & Health Supervision	redundancy/watchdog
Redundancy Configuration (JSON per role and site)	redundancy/config
OS Adapter	Platform_OS_POSIX

Gaps between model and code

Each gap is a work item in TODO.dox (section "Capella architecture baseline"), which holds the plan, the order and the progress: G1 (ADR-040, steps 1-4 done) and G4 (audit, items 1-2 done) are in progress, the rest not started.

G1 - Site role decided by the platform, not the application. The model moves LC-05 into RTE Redundancy Services: RTE negotiates ONLINE/STANDBY, supervises the partner site, verifies the dispatcher's takeover confirmation and transfers state; RBC_GP keeps only the Site Role Client (IF-05: receive the role, provide readiness and the state to replicate, pass the confirmation on). Negotiation, partner supervision, the A/B role agreement check and the authenticated takeover token check are in RTE rte_site_role; RBC_GP's ab_gp_channel_negotiate.c is the Site Role Client. What remains is ADR-040 step 5: the site link and the A/B peer link on rte_flow, rte_site_role reading the sibling state itself instead of GP forwarding it, and a peer-link exchange replacing the /tmp startup-timestamp file shared by A and B. Overlaps the deferred Phase 2b (transparent voting under rte_flow).
G2 - Output permission to the FSOU. The SCP model has a hardware Fail-Safe Output Unit that passes a site's outputs only when both channels gave a permission in the current cycle window (IF-SCP-02/03). RTE has no per-cycle output-permission output after the checkpoint yet; it needs a seam (OSAdapter vtable entry) that the container build implements as a no-op or a simulated FSOU.
G3 - Application uses only the PI API. The model states that PI API flows are the application's only access to communication. RBC_GP still calls rte_netlink, rte_voter and rte_cross_comparator directly (also in the DDS item of TODO.dox).
G4 - OSA rules. OSA requires threads with static priorities and fixed stacks created only in SYS_INIT, priority-inheritance mutexes, every wait with a timeout, fixed-size non-blocking IPC, no dynamic allocation in operation, and violations reported to RTE diagnostics as critical. Platform_OS_POSIX has not been checked against this list.
G5 - RBC_GA_NCBIR PL modules. The four PL modules (sources PL-OS-01..16 of PKP PLK) have no code; the base GA has no adaptation points (KONF, RUCH, SRK, CMI) for them to plug into. The CMI module also owns the dispatcher side of the takeover confirmation: it takes over token issuing from RBC_Maintenance_Web, and the takeover key moves off the non-vital Gateway.
G6 - GP functions modelled but not implemented. TSR (add, remove, revoke, applicability), text messages, level transitions (entry / exit L2), conditional / unconditional emergency and MA shortening, handover to an adjacent RBC (Subset-039/098), SW update. Each needs its own scoping against the code before work starts.
G7 - Interfaces to the separate servers. IF-01 (TrainCommServer -> Train Relay, untrusted), IF-AI-01 (Event Forwarder -> AI Diagnostic, one-way), IF-AI-02 (TrainCommServer logs -> AI Diagnostic) and IF-AI-03 (AI report -> maintenance) are defined in the model; both server products are placeholders.

Rules the code must keep (from the model)

Redundancy, voting, cross-comparison and safe state belong to the platform; applications contain no redundancy code and get their role declaratively (IF-05).
Any data crossing SIL 0 -> SIL 4 is untrusted until verified in the channel (SafeComm SFM, KM114, IF-08).
A site never goes ONLINE on silence: negotiation, partner restart announcement, or authenticated dispatcher confirmation only; two ONLINE sites are excluded.
An output leaves the site only after both channels agree in the cycle (checkpoint in software, FSOU in hardware).
Maintenance, diagnostics and AI never act on the SIL 4 part (FFI); JRU and maintenance receive data only.