Purpose:** Help you choose the right hardware configuration for your safety-critical railway application.
Audience:** System architects, hardware engineers, safety managers
Standards:** EN 50128 (Software Safety), EN 50129 (Functional Safety), EN 50126 (RAM)
Implementation Status by Hardware Pattern (updated 2026-09)
This guide describes hardware patterns that can be built with Platform_RTE. Status against the current code:
| Hardware Pattern | Support | Notes |
| 1oo1 (single system) | Implemented | All modules, watchdog included |
| 2oo2 (dual channel) | Implemented | rte_cross_comparator (2-way), rte_checkpoint, rte_watchdog, safe-state transition on disagreement |
| 2oo2 with redundancy (two sites, each 2oo2) | Implemented, warm and cold standby | rte_dual negotiation, rte_state_transfer, rte_redundancy_config (topology = 2oo2_redundant). This is the commercial project's choice (Kontron platform) |
| 2oo3 / NMR | Voter implemented, mesh not | rte_voter votes N inputs; registering N-way mesh channels between replicas is not implemented, so a real 2oo3 deployment is not yet possible |
| Hot standby | Not implemented | Needs platform-controlled invocation cadence in rte_appmanager |
| Online mode (active-active), centralized voter, distributed gossip | Design only | |
| Heterogeneous systems | Supported | CPU diversity is a hardware choice; see ADR-008 and safety/CCF_ANALYSIS.dox |
Project decision.** Sections below that recommend 2oo3 for an ERTMS RBC are general guidance from the time this guide was written. The reference RBC and the commercial project use 2oo2 with redundancy; 2oo3 is kept as a possible future change (see docs/architecture/OVERVIEW.dox in the workspace root). Redundancy is a configuration (a JSON file, see rte_redundancy_config), not application code.
The framework is not independently assessed; see SAFETY_APPLICATION_CONDITIONS.dox. See REDUNDANCY_ARCHITECTURE.dox for the design record of the redundancy APIs.
Safety Fundamentals: Why Hardware & Software Together
What is Functional Safety?
Functional safety means a system reliably performs its safety function, even when faults occur. For ERTMS systems like RBC:
Safety Function Example: Movement Authority (MA)
Normal Operation:
├─ Train sends position
├─ RBC calculates safe distance
├─ RBC grants movement authority
└─ Train accelerates safely
With Faults:
├─ If RBC FAILS to grant MA
│ └─ System must STOP train (fail-safe)
├─ If RBC grants WRONG MA
│ └─ System must STOP train (detect & correct)
└─ If RBC grants MA TOO LATE
└─ System must STOP train (timeout protection)
A safety-critical system must:
- Perform correctly under normal conditions
- Detect faults as they occur
- Recover or go safe when faults are detected
The Safety Equation: Hardware + Software
Building a SIL X system requires BOTH hardware techniques and software techniques working together:
SIL Integrity = Hardware Techniques + Software Techniques + Verification
Hardware Techniques (Redundancy & Fault Tolerance):
├─ Redundant processors (2oo2, 2oo3, NMR voting)
├─ Watchdog timers (detect hangs/timing failures)
├─ Memory protection (prevent corruption spread)
├─ Diverse CPUs (prevent common-mode failures)
├─ Network redundancy (detect communication faults)
└─ Power/cooling monitoring (detect environmental faults)
Software Techniques (Safety Logic):
├─ Safe-state transitions (known safe states)
├─ Defensive programming (check every assumption)
├─ Error detection (checksums, assertions, voting)
├─ Bounded latency (deterministic timing)
├─ No dynamic allocation (predictable behavior)
├─ Type safety (fixed-width types, explicit casts)
└─ Traceability (every function linked to requirements)
Verification Methods:
├─ MISRA C:2012 static analysis
├─ Formal methods (timing proofs)
├─ Testing (unit, integration, system)
├─ Failure mode analysis (FMEA)
├─ Code reviews (design & safety)
└─ Certification audits
Without both:**
- Only software = Can't survive hardware faults (no redundancy)
- Only hardware = Can't make correct decisions (bad logic)
Common Failures vs. Random Failures
This distinction is fundamental to safety design:
Random Failures (Systematic Faults)
Characteristics:
├─ Unpredictable timing
├─ Independent events
├─ Follow statistical distribution
├─ Example: Cosmic ray flips memory bit
├─ Example: Network packet lost due to noise
├─ Example: Component aging wears out after years
├─ Example: Transient power glitch
How to detect:
├─ Voting (2 out of 3 agree = detects 1 random fault)
├─ Checksums (data integrity check)
├─ Parity bits (detect bit flips)
├─ Timeouts (detect halted processor)
How to survive:
├─ Redundancy (2oo2, 2oo3)
├─ Restart faulty component
├─ Failover to backup
└─ Majority vote (NMR)
Example: A random bit flip in RBC's state can be detected
by voting—other RBCs will have different values, voting
detects disagreement, system recovers.
Common-Mode Failures (Systematic Errors)
Characteristics:
├─ Same root cause affects multiple components
├─ Deterministic (happens every time under same conditions)
├─ Design flaws, not random events
├─ Example: CPU microcode bug affects all identical CPUs
├─ Example: Compiler bug generates wrong code in all copies
├─ Example: Algorithm error exists in all identical software
├─ Example: Library vulnerability exploited on all instances
Why redundancy FAILS against common-mode:
├─ 2 identical CPUs + same software
│ └─ Both fail identically (voting detects NOTHING)
├─ 3 identical servers + same algorithm
│ └─ All make same wrong decision (voting useless)
└─ Result: Redundancy provides NO SAFETY
How to detect:
├─ CPU diversity (different architectures fail differently)
├─ Software diversity (different code paths, different compilers)
├─ Cross-verification (independent calculations)
├─ Formal verification (prove algorithm correctness)
How to survive:
├─ Use DIFFERENT CPU vendors (Intel vs. AMD vs. ARM)
├─ Use DIFFERENT software stacks
├─ Use DIFFERENT algorithms (diversity)
├─ Use formal proof (mathematically guarantee correctness)
Example: If all RBC instances have the same compiler bug,
voting is useless—all make the same wrong decision.
Defense: Use different compilers, different CPU architectures,
different implementation teams.
Comparison
| Aspect | Random Failures | Common-Mode Failures |
| Cause | Independent events (cosmic ray, noise, wear) | Design flaws (bug in code/CPU shared by all) |
| Detection | Voting, timeouts, checksums | Diversity, formal proofs, reviews |
| Redundancy Helps? | ✓ YES (identical redundancy works) | ✗ NO (identical redundancy fails) |
| Example | One random bit flip in memory | Compiler generates same bug in all copies |
| Solution | 2oo2 voting (detects mismatch) | Different CPUs/compilers (prevent mismatch) |
Platform_RTE's Role: The API Abstraction Layer
RteFramework provides an API ABSTRACTION LAYER that isolates safety-critical application logic from OS/RTOS implementation details:
Complete Safety System:
┌──────────────────────────────────────────────────┐
│ ERTMS RBC Application │
│ (Your railway safety logic) │
│ (Does NOT directly call OS APIs) │
└────────────────────┬─────────────────────────────┘
│
┌───────────▼──────────────────┐
│ RteFramework API │ ← Platform_RTE (THIS PACKAGE)
│ (Abstraction Only) │
│ │
│ Interface definitions for: │
│ ✓ Vital channels │
│ ✓ Voting & synchronization │
│ ✓ Watchdog monitoring │
│ ✓ Timers, memory, IPC │
│ ✓ Logging, safe-states │
│ ✓ Application lifecycle │
│ │
│ (Platform_RTE = API only, │
│ NOT implementation) │
└───────────┬──────────────────┘
│
┌─────────────┴──────────────────────┐
│ │
┌───▼──────────────────────┐ ┌──────▼──────────────┐
│ OS/RTOS OSAdapter │ │ Hardware │
│ (Your implementation) │ │ (Your choice) │
│ │ │ │
│ Must implement: │ │ ✓ 1oo1 single CPU │
│ ✓ Timer OSAdapter │ │ ✓ 2oo2 dual CPUs │
│ ✓ IPC (sockets, pipes) │ │ ✓ 2oo3 triple CPUs │
│ ✓ Memory management │ │ ✓ Watchdog timers │
│ ✓ Watchdog driver │ │ ✓ Network (UDP/TCP)│
│ ✓ Thread/task scheduler │ │ ✓ CPU diversity │
│ ✓ Non-volatile storage │ │ ✓ Redundancy │
│ ✓ Reboot mechanism │ │ ✓ Failover logic │
│ ✓ Logging sink │ │ │
│ │ │ + Certification │
│ For QNX: QNX-specific │ │ + Verification │
│ For Linux: POSIX-specific│ │ + Testing │
│ For bare-metal: HW-direct│ │ + FMEA, reviews │
└───────────────────────────┘ └─────────────────────┘
Critical Design Point:**
- OS/RTOS OSAdapter — Concrete implementation for your specific OS
- Timer operations (start, stop, wait)
- IPC operations (sockets, shared memory, message queues)
- Memory allocation (static buffers, pools)
- Watchdog integration (if OS provides it)
- Non-volatile storage (file system, EEPROM, flash)
- Task scheduling (if multi-threaded)
- Reboot mechanism (OS-specific)
- Logging sink (serial, syslog, database)
- Hardware Configuration — Choose based on SIL requirements
- Single processor (1oo1) for SIL 1/2
- Dual/Triple redundancy (2oo2, 2oo3) for SIL 3/4
- CPU diversity (prevent common-mode failures)
- Watchdog hardware (detect hangs)
- Network redundancy (if multi-site)
- Safety Strategy — Define how redundancy/voting works
- Which components are vital (must be redundant)
- Which are service (best-effort only)
- Voting rules (2oo2, 2oo3, NMR)
- Checkpoint synchronization strategy
- Failover/recovery procedures
- Verification & Certification — Prove system safety
- MISRA C:2012 static analysis
- FMEA (failure mode analysis)
- Testing (unit, integration, system)
- Code reviews
- EN 50128 compliance audit
Building a SIL X System: The Integration Model
Step 1: RBC Application Code
├─ Your safety logic (route calculation, MA creation, etc.)
└─ Uses Platform_RTE APIs (does NOT call OS directly)
↓
Step 2: Select Hardware Configuration
├─ Choose redundancy pattern based on SIL target:
│ ├─ SIL 1/2: 1oo1 (single processor)
│ ├─ SIL 3: 2oo2 or 2oo2D (dual redundancy)
│ └─ SIL 4: 2oo2 with redundancy, 2oo3, or others (see "Choosing a pattern")
└─ Choose specific CPUs, network topology, watchdog strategy
↓
Step 3: Implement OS-Specific OSAdapter
├─ Platform_RTE expects these OS services:
│ ├─ Memory (rte_memory_allocate for init-time, static for runtime)
│ └─ Reboot (rte_reboot_system when safe-state fails)
│
└─ Register your OS OSAdapter at startup:
└─ etc. for each service
↓
Step 4: Implement Hardware Strategy
├─ Deploy processors (single, dual, triple sites)
├─ Setup network (UDP for voting, TCP for checkpoint sync)
├─ Configure watchdog timers (system, task, channel, checkpoint)
├─ Setup CPU diversity (if needed for common-mode protection)
├─ Configure failover (if using hot-standby or cluster redundancy)
└─ Implement monitoring (health checks, diagnostics)
↓
Step 5: Verification & Certification
├─ Static analysis: MISRA C:2012 compliance
├─ FMEA: Failure mode analysis (what can go wrong)
├─ Testing: Unit, integration, system-level
├─ Timing analysis: Prove bounded latencies
├─ Code review: Safety-critical logic inspection
├─ EN 50128 audit: Confirm mandatory techniques
└─ Certification body review (if required)
↓
Certified SIL X System
rte_status_t rte_ipc_receive(rte_ipc_handle_t handle, void *out_message, size_t buffer_size, rte_duration_ms_t timeout_ms)
Receives one message, blocking at most timeout_ms.
rte_status_t rte_ipc_send(rte_ipc_handle_t handle, const void *message, size_t message_size, rte_duration_ms_t timeout_ms)
Sends one message, blocking at most timeout_ms.
void rte_log_write(rte_log_level_t level, const char *tag, const char *message)
Emits one log message. Non-blocking; never fails the caller's control flow even if the message is dro...
rte_status_t rte_nvm_read(rte_nvm_handle_t handle, size_t offset, void *out_buffer, size_t buffer_size)
Reads and integrity-checks data from an NVM region.
rte_status_t rte_timer_start(rte_timer_handle_t handle)
Starts (or restarts) a created timer.
rte_status_t rte_watchdog_kick(rte_watchdog_t watchdog)
Kick (pet) watchdog - prove liveness.
rte_status_t rte_osadapter_ipc_register(const rte_osadapter_ipc_t *adapter)
Registers the OSAdapter IPC implementation.
rte_status_t rte_osadapter_memory_register(const rte_osadapter_memory_t *adapter)
Registers the OSAdapter memory implementation.
rte_status_t rte_osadapter_timer_register(const rte_osadapter_timer_t *adapter)
Registers the OSAdapter timer implementation.
Key Insight:**
Platform_RTE provides the **API contract**—your application uses Platform_RTE APIs instead of OS calls. This means:
- Same RBC code works on Linux, QNX, or bare-metal (just swap OSAdapter)
- Same RBC code works for SIL 1 through SIL 4 (just swap HW + verification)
- You control the actual redundancy/voting via hardware configuration
- Platform_RTE stays small, portable, and easy to certify
- Implementation complexity (OS-specific OSAdapters) is decoupled from application safety logic
How Failures Determine SIL Requirements
System Requirement: "RBC must safely grant or deny movement authority"
Fault Analysis:
├─ Random fault in RBC's calculation
│ └─ Detected by: Voting (2oo2 detects disagreement)
│ └─ Survived by: Fallback to safe state (deny MA)
│ └─ SIL 3 acceptable
│
├─ Common-mode fault (compiler bug in all RBCs)
│ └─ NOT detected by identical voting
│ └─ Must prevent with: CPU diversity + formal proof
│ └─ Needs a common-cause argument (voting alone is insufficient)
│
├─ Network delay (RBC votes but answer arrives late)
│ └─ Detected by: Watchdog timeout
│ └─ Recovered by: Safe state (deny MA) + failover
│ └─ SIL 3+ required
│
└─ Multiple faults (RBC hangs AND network down)
└─ Must tolerate: 2+ simultaneous faults
└─ Requires: an availability/exposure argument (site failover, 2oo3 or better) plus the safety-case argument
Standards and Techniques
Platform_RTE defines the API interface through which you implement these mandatory EN 50128 techniques:
| Technique | How Platform_RTE Helps | You Must Implement |
| Defensive Programming | API forces explicit error handling | Every OS OSAdapter validates inputs |
| Diverse Redundancy | Voting API (2oo2, 2oo3, NMR) | Deploy multiple diverse CPUs |
| Monitoring & Watchdog | Watchdog API interface | Integrate OS/hardware watchdog timer |
| Safe-State Machine | Safe-state API (RTE_SAFESTATE) | Verify safe-state logic in your app |
| Initialization & Failure Handling | Init/shutdown API | Implement recovery procedures |
| Error Detection & Correction | Checkpoint, voting APIs | Implement checkpoint logic in your app |
| Bounded Time & Space | No dynamic allocation after init | Static buffers, no recursion |
| Formal Verification | Requirement traceability (REQ-IDs) | Prove timing, prove algorithm correctness |
| Traceability | REQ-ID linking in Platform_RTE headers | Map your application to requirements |
| Testing & Validation | Framework is testable | Create test suites for your OSAdapters |
Implementation Reality:**
- Platform_RTE API surface is ~50KB of headers (small, easy to verify)
- OS OSAdapters are ~10-50KB each (you write for your target OS)
- Application logic is your domain-specific code
- Together they form a SIL X system (SIL level determined by HW config + verification rigor, NOT by Platform_RTE alone)
Choosing a pattern
Safety and availability are different questions
- Safety is fail-safe behaviour: a fault is detected and the system reaches a safe state (for an RBC, it withholds or restricts authority). Detection comes from comparison between independent channels.
- Availability (RAM, EN 50126) is how often the service is up. Most differences between redundancy patterns are about availability: whether a first fault is masked (2oo3, NMR) or leads to a safe stop and, where there is a second site, a failover.
- A 2oo2 pair detects a single fault and stops safely; it does not mask it. 2oo3 masks a minority fault and continues.
An earlier version of this guide stated that SIL 4 requires continued operation after a first fault and therefore excludes a single 2oo2 site. That statement is not adopted. As far as this project has established, EN 50128 and EN 50129 set a tolerable hazard rate and require a safe reaction to detected faults; continued operation after a fault is an availability requirement. Whether an architecture reaches SIL 4 is an argument in the safety case (hazard rate, diagnostic coverage, common-cause failures, repair and exposure time), assessed by the independent safety assessor. Confirm the argument with the ISA before relying on it. A second fault that arrives while one channel is out is a hazard only if it can go undetected; after a safe stop the concern is common-cause failure of both channels, which site redundancy, diversity and separation address (see safety/CCF_ANALYSIS.dox).
Pattern catalog
| Pattern | Detects a single fault | Masks it | After a first fault | Platform_RTE status | Typical use |
| 1oo1 | No (watchdog only, with 1oo1+WD) | No | Continues undetected | Implemented | Development, non-vital, SIL 1-2 |
| 2oo2 | Yes | No | Safe stop | Implemented | Vital single site |
| 2oo2 with redundancy (two 2oo2 sites, ONLINE and STANDBY) | Yes, per site | Site failover | Standby site takes over | Implemented, warm and cold standby | Project choice for the RBC |
| 2oo3 | Yes | Yes | Continues degraded to 2oo2 | Voter only; mesh registration not implemented | Single site needing availability |
| NMR (N of M) | Yes | Yes, up to (N-1)/2 | Continues | Voter only | Rare, very high reliability |
| Online (active-active) | Yes | Depends on voting | Continues | Design only | Latency-tolerant multi-site |
| Hot standby (independent computation) | Yes | Site failover | Standby already current | Not implemented; needs platform-controlled cadence | Low failover time |
| Heterogeneous | Yes | n/a | n/a | Supported (hardware choice) | Diversity against common cause |
| Centralized voter / distributed cross-comparison | Yes | Yes | n/a | Design only | Multi-site voting topologies |
Detailed descriptions of each configuration follow in the configuration reference below. Cost and schedule figures that an earlier version carried were unsupported estimates and were removed.
Decision questions
- What is the safety target and who assesses it? SIL and tolerable hazard rate come from the hazard analysis; the independent safety assessor accepts the argument.
- What availability is required? If a safe stop of one site is acceptable because another site takes over, 2oo2 with redundancy fits. If a single site must keep running through a fault, 2oo3 or NMR is needed.
- How many independent processors or sites exist? One: 1oo1. Two per site and two sites: 2oo2 with redundancy. Three in one site: 2oo3.
- What latency is tolerable? Tight: 1oo1, 2oo2, hot standby. Loose: 2oo3, online, NMR (comparison and checkpoint cost time).
- What common-cause budget applies? Identical CPUs need a documented mitigation: compiler diversity (ADR-008), temporal and data diversity, physical separation, independent verification (ADR-008, safety/CCF_ANALYSIS.dox).
- What is supported? See the status column; a pattern marked design-only cannot be deployed yet.
Project decision
The reference RBC and the commercial project use 2oo2 with redundancy on the Kontron platform: fail-safe detection in each site by cross-comparison, availability from the second site through negotiated ONLINE and STANDBY roles, and a simple per-site design. Redundancy is a configuration (rte_redundancy_config) and the application is agnostic of it, so a later change to 2oo3 is possible once mesh registration exists. See REDUNDANCY_ARCHITECTURE.dox and the workspace docs/architecture/OVERVIEW.dox.
Configuration reference
Descriptions of the nine hardware configurations. Terminology: in this reference "hot standby" means a standby that replicates state from the primary; in the project's terms that is warm (see REDUNDANCY_ARCHITECTURE.dox, terminology). API sketches and deployment scripts that the earlier configuration guide carried were removed because they used names that do not exist; use the headers under include/rte/redundancy/ and the examples.
Configuration 1: Single System (Non-Redundant)
Use Case
- Scenario: Non-critical applications, SIL 1/2 systems, development/testing
- Availability: Single point of failure (no fault tolerance)
- Example: Diagnostic logger, simulation, test harness
Architecture
┌─────────────────────────────────────┐
│ Single Processor / Board │
├─────────────────────────────────────┤
│ │
│ ┌──────────────────────────────┐ │
│ │ RBC Application │ │
│ │ (single-threaded or │ │
│ │ multi-threaded on 1 core) │ │
│ └────────────┬─────────────────┘ │
│ │ │
│ ┌──────▼──────────┐ │
│ │ RteFramework│ │
│ │ (13 modules) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────▼─────────┐ │
│ │ POSIX/QNX OAL │ │
│ │ (OSAdapter) │ │
│ └────────┬─────────┘ │
│ │ │
│ ┌────────▼─────────┐ │
│ │ Linux/QNX OS │ │
│ │ or Bare Metal │ │
│ └──────────────────┘ │
│ │
└─────────────────────────────────────┘
Deployment Example
Linux Development Machine:**
QNX Single Node:**
Safety Notes
- ❌ No fault tolerance
- ❌ Single-point failures not detected
- ✅ Good for SIL 1/2 or non-critical paths
- ✅ Suitable for testing Platform_RTE modules
Configuration 2: Dual-Channel System (2oo2)
Use Case
- Scenario: SIL 3 systems, dual-core processors, dual-redundant boards
- Availability: Detects any single fault immediately
- Example: ERTMS signal controller, safety-related device
Architecture
┌────────────────────────────────────┐
│ Dual-Channel System (2oo2) │
├────────────────────────────────────┤
│ │
│ CPU A CPU B │
│ ┌──────────────────────────────┐ │
│ │ RBC Logic │ RBC Logic │ │
│ │ (identical) │ (identical) │ │
│ ├──────────────────────────────┤ │
│ │ Platform_RTE (vital) │ Platform_RTE (vital) │ │
│ │ (2oo2 mode) │ (2oo2 mode) │ │
│ └──────┬───────────────┬───────┘ │
│ │ Data Exchange │ │
│ │ (shared mem │ │
│ │ or network) │ │
│ ┌──────▼───────────────▼───────┐ │
│ │ Voting Logic │ │
│ │ (both must agree) │ │
│ └──────┬─────────────────────────┘ │
│ │ │
│ ┌──────▼─────────┐ │
│ │ Output Module │ │
│ │ (to field) │ │
│ └────────────────┘ │
│ │
└────────────────────────────────────┘
2oo2 Voting Rule
Input A = X ┐
Input B = X ├──→ Output X (agreement)
┘
Input A = X ┐
Input B = Y ├──→ FAULT (disagreement)
┘ └─→ Safe-State Immediate
Hardware Topologies
Topology A: Dual-Core Processor**
┌──────────────────────────┐
│ Single Processor │
├──────────────────────────┤
│ Core A Core B │
│ ┌──────────┐ ┌──────┐ │
│ │ RBC A │ │ RBC B│ │
│ └──────────┘ └──────┘ │
│ ↕ Shared Memory ↕ │
│ [Voting on Core A/B] │
└──────────────────────────┘
Topology B: Dual Processor Board**
┌──────────────────────────┐
│ Single Board │
├──────────────────────────┤
│ CPU A CPU B │
│ ┌──────────┐ ┌──────┐ │
│ │ RBC A │ │ RBC B│ │
│ └──────────┘ └──────┘ │
│ ↕ PCB Bus / SPI / I2C ↕ │
│ [Voting on CPU A/B] │
└──────────────────────────┘
Topology C: Dual-Site Network**
┌─────────────────────────────────────┐
│ Redundant Network (2oo2) │
├─────────────────────────────────────┤
│ │
│ Site A Network Site B │
│ ┌──────────┐ ┌──────────┐│
│ │ RBC A │ Ethernet/CAN │ RBC B ││
│ │ Platform_RTE (A) │◄─────────────────►│ Platform_RTE (B) ││
│ └──────────┘ (replicated) └──────────┘│
│ │
│ Voting Decision: │
│ - Both sites must agree │
│ - Network latency < 100ms │
│ - Timeout on network failure │
│ │
└─────────────────────────────────────┘
Deployment Example
QNX Dual-Core:**
Safety Notes
- ✅ Detects single-point failures immediately
- ✅ No output on disagreement (fail-safe)
- ❌ Tolerates 0 faults (2 simultaneous failures = catastrophic)
- ✅ Suitable for SIL 3 systems
Configuration 3: Triple-Channel System (2oo3)
Use Case
- Scenario: SIL 4 systems, triple-core/triple-processor, triple-redundant
- Availability: Tolerates 1 channel failure, continues with 2oo2
- Example: ERTMS RBC (typical), safety-critical control systems
Architecture
┌──────────────────────────────────────┐
│ Triple-Channel System (2oo3) │
├──────────────────────────────────────┤
│ │
│ CPU A CPU B CPU C │
│ ┌──────────────────────────────┐ │
│ │ RBC A │ RBC B │ RBC C │ │
│ │(vote) │(vote) │(vote) │ │
│ └────┬────────┬────────┬───────┘ │
│ │ │ │ │
│ ┌────▼────────▼────────▼────────┐ │
│ │ Voting Engine (2oo3) │ │
│ │ Majority vote logic: │ │
│ │ - Count votes │ │
│ │ - ≥2 same = decision │ │
│ │ - Minority = fault │ │
│ └────┬──────────────────────────┘ │
│ │ │
│ ┌────▼──────────────────────────┐ │
│ │ Output (if consensus) │ │
│ │ or Safe-State (if fault) │ │
│ └──────────────────────────────┘ │
│ │
└──────────────────────────────────────┘
2oo3 Voting Rule
Outputs: A=X, B=X, C=X → Output = X (3-way agreement)
Outputs: A=X, B=X, C=Y → Output = X (2oo3: majority wins)
Outputs: A=X, B=Y, C=Y → Output = Y (2oo3: majority wins)
Outputs: A=X, B=Y, C=Z → FAULT (no consensus)
Hardware Topologies
Topology A: Triple-Core Processor**
┌───────────────────────────────┐
│ Single Processor │
├───────────────────────────────┤
│ Core A Core B Core C │
│ ┌────────┐ ┌────┐ ┌────────┐│
│ │ RBC A │ │RBC │ │ RBC C ││
│ │ │ │ B │ │ ││
│ └────────┘ └────┘ └────────┘│
│ ↕ Shared L3 Cache / Memory ↕ │
│ [2oo3 Voting] │
└───────────────────────────────┘
Topology B: Triple-Processor Board**
┌───────────────────────────────┐
│ Single Board │
├───────────────────────────────┤
│ CPU A CPU B CPU C │
│ ┌────────┐ ┌───┐ ┌────────┐ │
│ │ RBC A │ │RBC│ │ RBC C │ │
│ └────────┘ │ B │ └────────┘ │
│ └───┘ │
│ ↕ PCB Bus / SPI / Switched ↕ │
│ [2oo3 Voting] │
└───────────────────────────────┘
Topology C: Triple-Site Cluster (ERTMS RBC)**
┌──────────────────────────────────────────┐
│ Triple-Redundant Cluster (2oo3) │
├──────────────────────────────────────────┤
│ │
│ Site A Site B Site C │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐│
│ │ RBC A │ │ RBC B │ │ RBC C ││
│ │ (Vote) │ │ (Vote) │ │ (Vote) ││
│ └────┬─────┘ └────┬─────┘ └────┬─────┘│
│ │ │ │ │
│ ┌────▼────────────▼────────────▼───┐ │
│ │ Distributed Voting (Gossip) │ │
│ │ or Centralized Voter │ │
│ │ Majority decision (2oo3) │ │
│ └────┬─────────────────────────────┘ │
│ │ │
│ ├─→ Signaling System │
│ ├─→ Train Detection │
│ └─→ Speed Enforcement │
│ │
│ Fault tolerance: │
│ - 1 site fails → system continues │
│ - 2 sites fail → safe-state │
│ - Network delay < 200ms │
│ │
└──────────────────────────────────────────┘
Deployment Example
QNX Triple-Core RBC:**
Safety Notes
- ✅ Tolerates 1 channel failure
- ✅ Continues operation with 2 healthy channels (2oo2 mode)
- ✅ Detects faulty channel via voting
- ✅ Suitable for SIL 4 systems
- ✅ Proven in ERTMS deployments
Configuration 4: N-Modular Redundancy (NMR)
Use Case
- Scenario: High-reliability systems (N ≥ 4), aerospace, critical control
- Availability: Tolerates ⌊(N-1)/2⌋ faults
- Example: Railway signaling with 4+ redundant sites
Architecture
N=4 (4oo3 - Tolerates 1 fault):
Channels: A=X, B=X, C=X, D=Y
Majority vote: 3 votes for X, 1 for Y → Output = X
N=5 (5oo3 - Tolerates 2 faults):
Channels: A=X, B=X, C=X, D=Y, E=Y
Majority vote: 3 votes for X, 2 for Y → Output = X
N=7 (7oo4 - Tolerates 3 faults):
Channels: A=X, B=X, C=X, D=X, E=Y, F=Y, G=Y
Majority vote: 4 votes for X, 3 for Y → Output = X
Safety Notes
- ✅ Tolerates multiple simultaneous faults
- ✅ Scales to arbitrary N
- ❌ Higher complexity (voting logic more complex)
- ✅ Suitable for ultra-high-reliability systems
Configuration 5: Online Mode (Active-Active Cluster)
Use Case
- Scenario: Multi-site ERTMS RBC with simultaneous processing
- Availability: All sites active, must agree before output
- Example: Dual-site or triple-site RBC coordination
Architecture
┌─────────────────────────────────────┐
│ Online Mode (Active-Active) │
│ All sites processing simultaneously│
├─────────────────────────────────────┤
│ │
│ ┌─────────┐ ┌─────────┐ │
│ │ Site A │ │ Site B │ │
│ │ [Active]│ │[Active] │ │
│ ├─────────┤ ├─────────┤ │
│ │ Process │ │ Process │ │
│ │ Signal │ │ Signal │ │
│ │ X │ │ X │ │
│ ├─────────┤ ├─────────┤ │
│ │ Result: │ │ Result: │ │
│ │ GREEN │ │ GREEN │ │
│ └────┬────┘ └────┬────┘ │
│ │ │ │
│ ┌────▼─────────────▼────┐ │
│ │ Checkpoint Barrier │ │
│ │ (synchronize timing) │ │
│ └────┬─────────────────┘ │
│ │ │
│ ┌────▼──────────────────┐ │
│ │ Exchange Results │ │
│ │ (data sync) │ │
│ └────┬──────────────────┘ │
│ │ │
│ ┌────▼──────────────────┐ │
│ │ Voting │ │
│ │ (both must agree) │ │
│ └────┬──────────────────┘ │
│ │ │
│ ┌────▼──────────────────┐ │
│ │ Commit & Output │ │
│ │ (atomic decision) │ │
│ └───────────────────────┘ │
│ │
│ Properties: │
│ - All sites work continuously │
│ - Higher detection latency │
│ - Better resource utilization │
│ - Synchronization required │
│ │
└─────────────────────────────────────┘
Safety Notes
- ✅ High availability (all nodes active)
- ✅ Good utilization (all resources used)
- ❌ Requires synchronization (network latency sensitive)
- ✅ Detects failures quickly (both nodes must respond)
Configuration 6: Hot Standby Mode (Active-Passive Cluster)
Use Case
- Scenario: Multi-site ERTMS RBC with primary-backup pattern
- Availability: Primary active, backup replicates state
- Example: Primary RBC + Backup RBC with automatic failover
Architecture
┌────────────────────────────────────┐
│ Hot Standby (Active-Passive) │
│ Primary processing, Backup ready │
├────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Primary │ │ Backup │ │
│ │ (ACTIVE) │ │ (READY) │ │
│ ├──────────┤ ├──────────┤ │
│ │ Process │ │ Replicate│ │
│ │ Signal X │ │ State │ │
│ │ Result: │ │ received │ │
│ │ GREEN │ │ Standby │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ Heartbeat │ Ack │
│ ├───────────────→ │ │
│ │ State Update ←│ │
│ │ (synchronous) │ │
│ │ │ │
│ ┌────▼──────────────────▼───┐ │
│ │ Output (from Primary) │ │
│ │ (only if Backup in sync) │ │
│ └──────────────────────────┘ │
│ │
│ If Primary fails: │
│ ├─ Heartbeat missed │
│ ├─ Backup detects loss │
│ ├─ Backup takes over │
│ └─ Backup becomes new Primary │
│ │
│ Properties: │
│ - Lower latency (1 active) │
│ - Redundant state (both aware) │
│ - Failover time < 1s │
│ - Backup ready (hot standby) │
│ │
└────────────────────────────────────┘
Failover Sequence
State 1: NORMAL
├─ Primary: processing, sending heartbeat
├─ Backup: replicating, receiving heartbeat
└─ Output: from Primary only
State 2: PRIMARY FAILURE DETECTED
├─ Backup: no heartbeat for 500ms
├─ Backup: initiates failover
└─ Output: temporarily halted
State 3: FAILOVER IN PROGRESS
├─ Backup: becomes new Primary
├─ Backup: starts processing
└─ Old Primary: isolated
State 4: NEW NORMAL
├─ Old Backup (now Primary): processing
├─ Old Primary (now Backup): offline or rejoining
└─ Output: from new Primary
Safety Notes
- ✅ Lower latency (primary-only processing)
- ✅ Automatic failover (fast recovery)
- ✅ Backup keeps state (hot standby = ready)
- ❌ Single point of failure during failover (brief gap)
- ✅ Good for SIL 4 systems with strict latency
Configuration 7: Heterogeneous Systems (Mixed Processors)
Use Case
- Scenario: Systems with different processor types, architectures
- Challenge: Ensuring equivalent processing across different HW
- Example: ARM + x86 dual-channel system
Architecture
┌──────────────────────────────────┐
│ Heterogeneous 2oo2 │
│ (Different Processors) │
├──────────────────────────────────┤
│ │
│ Processor A (ARM) Processor B (x86)
│ ┌──────────────┐ ┌──────────────┐│
│ │ RBC Logic A │ │ RBC Logic B ││
│ │ (ARM binary) │ │ (x86 binary) ││
│ │ │ │ ││
│ │ Process │ │ Process ││
│ │ Signal X │ │ Signal X ││
│ │ │ │ ││
│ │ Result: 42 │ │ Result: 42 ││
│ └────┬─────────┘ └────┬─────────┘│
│ │ Network │ │
│ │ Serialized Data │ │
│ └────┬─────────────┘ │
│ │ │
│ ┌────▼──────────────┐ │
│ │ Voting │ │
│ │ (compare values) │ │
│ └────┬──────────────┘ │
│ │ │
│ ┌────▼──────────────┐ │
│ │ Output (if agree) │ │
│ └───────────────────┘ │
│ │
│ Challenges: │
│ ✓ Endianness (Platform_RTE handles it) │
│ ✓ Floating point (avoid, use int) │
│ ✓ Timing (clock sync needed) │
│ ✓ Compilation (verify bitwise) │
│ │
└──────────────────────────────────┘
Safety Notes
- ✅ Platform_RTE handles endianness conversion
- ✅ Network-based communication works
- ❌ Clock synchronization required
- ❌ Compilation verification needed (bitwise comparison)
- ✅ Supported with care and testing
Configuration 8: Voting Topology - Centralized Voter
Use Case
- Scenario: Dedicated voter processor or central coordination
- Advantage: Decouples voting from application logic
- Example: ERTMS with central voting unit
Architecture
┌──────────────────────────────────────┐
│ Centralized Voter Topology │
├──────────────────────────────────────┤
│ │
│ Application Nodes Voter Node │
│ │
│ ┌──────────┐ ┌────────┐│
│ │ Node A │ │ Voter ││
│ │ (RBC) │ │ (Vote) ││
│ │ │ │ ││
│ │ Result A │────┐ │ ││
│ └──────────┘ │ │ ││
│ ├──────→│ ││
│ ┌──────────┐ │ │ ││
│ │ Node B │ │ │ Compare││
│ │ (RBC) │ │ │ Majority
│ │ │ │ │ ││
│ │ Result B │────┤ │ ││
│ └──────────┘ │ │ ││
│ ├──────→│ ││
│ ┌──────────┐ │ │ ││
│ │ Node C │ │ │ ││
│ │ (RBC) │ │ │ Decide ││
│ │ │ │ │ ││
│ │ Result C │────┘ │ ││
│ └──────────┘ │ ││
│ │ ││
│ ┌──────▼─────┐ │
│ │ Output or │ │
│ │ Safe-State │ │
│ └────────────┘ │
│ │
│ Advantages: │
│ ✓ Separates voting from processing │
│ ✓ Simpler application logic │
│ ✓ Centralized policy │
│ ✓ Easier debugging │
│ │
│ Disadvantages: │
│ ✗ Voter becomes single point │
│ ✗ Network latency critical │
│ ✗ Voter must be certified │
│ │
└──────────────────────────────────────┘
Configuration 9: Voting Topology - Distributed Cross-Comparison
Use Case
- Scenario: Peer-to-peer voting, no central point
- Advantage: No single voter, gossip consensus
- Example: ERTMS with decentralized RBC nodes
Architecture
┌──────────────────────────────────────┐
│ Distributed Voting (Gossip) │
│ Peer-to-Peer Consensus │
├──────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ │
│ │ Node A │ │ Node B │ │
│ │ (RBC) │ │ (RBC) │ │
│ │ Result A │ │ Result B │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ │ Exchange │ │
│ ├────────────→│ │
│ │ │ │
│ ┌────▼─────┐ ┌────▼─────┐ │
│ │ A knows: │ │ B knows: │ │
│ │ A=X, B=X │ │ A=X, B=X │ │
│ └────┬─────┘ └────┬─────┘ │
│ │ │ │
│ ┌────▼─────────────▼────┐ │
│ │ Node C (latecomer) │ │
│ │ Result C: Y │ │
│ └────┬──────────────────┘ │
│ │ Request A,B results │
│ │ │
│ ┌────▼──────────────────┐ │
│ │ C learns: A=X, B=X │ │
│ │ but C=Y (disagree) │ │
│ │ → C is faulty │ │
│ └───────────────────────┘ │
│ │
│ Message Exchange (Gossip): │
│ Round 1: A→B (A's result) │
│ Round 2: B→A (B's result) │
│ Round 3: C→A,B (C's result) │
│ Round 4: A,B→C (consensus) │
│ │
│ Advantages: │
│ ✓ No single point of failure │
│ ✓ Peer-to-peer trust │
│ ✓ Byzantine-fault tolerant │
│ │
│ Disadvantages: │
│ ✗ Higher latency (gossip delay) │
│ ✗ More complex protocol │
│ ✗ Network bandwidth overhead │
│ │
└──────────────────────────────────────┘
Service Unit: Non-Vital Software Layer
Definition:** A Service Unit (also called "General Purpose Processor" or "Service Processor") is a non-vital component that runs non-safety-critical software alongside the vital safety-critical channels. It does NOT participate in safety decisions and failure does not affect system safety.
Service Unit vs. Vital Channels
System Architecture:
┌─────────────────────────────────────────────────┐
│ SAFETY-CRITICAL LAYER │
├──────────────┬──────────────┬──────────────────┤
│ Vital Ch.A │ Vital Ch.B │ Vital Ch.C │
│ (SIL 4) │ (SIL 4) │ (SIL 4) │
│ 2oo3 voting │ │ │
└──────────────┴──────────────┴──────────────────┘
▲
│ Critical outputs
│ (voted, verified)
┌─────────────────────────────────────────────────┐
│ SERVICE UNIT (Non-Vital) │
├─────────────────────────────────────────────────┤
│ ✓ Logging, diagnostics, monitoring │
│ ✓ Optimization, performance tuning │
│ ✓ User interface, visualization │
│ ✓ Historical data, statistics │
│ ✓ System administration │
│ ✓ Non-critical features │
│ │
│ ✗ Does NOT vote on safety decisions │
│ ✗ Does NOT control vital outputs │
│ ✗ Does NOT need redundancy │
│ ✗ Failure is NON-CRITICAL │
└─────────────────────────────────────────────────┘
Why Service Units are Needed
In real ERTMS systems like RBC, operators need:
Critical Functions (Safety): Non-Critical Functions (Service):
├─ Route calculation ├─ Train history logging
├─ Movement authority creation ├─ Performance statistics
├─ Conflict detection ├─ Predictive maintenance
├─ Train position validation ├─ Operator dashboard
├─ Emergency braking logic ├─ Data export
└─ Safety-critical timing ├─ System tuning
├─ Remote diagnostics
└─ Historical analysis
A Service Unit handles all the non-critical functions, so:
- Vital channels stay lean and highly certified (faster verification)
- Service Unit can use standard software practices (logging, database, web UI)
- System provides both safety AND operational value
- Cost is optimized (vital channels expensive, service unit inexpensive)
Service Unit Architecture Patterns
Pattern 1: Isolated Service Unit (Recommended for SIL 3/4)
┌─────────────────────┐
│ 2oo3 Vital │ Voting on safety outputs
│ Channels (SIL 4) │
└──────────┬──────────┘
│
[Safety Outputs]
│
┌─────▼──────┐
│ Voter │ Enforces majority vote
└─────┬──────┘
│
[Verified Decisions]
│
┌─────▼──────────────┐
│ Service Unit │ Can read results
│ (Single instance) │ Cannot affect voting
└────────────────────┘
Characteristics:
✓ Service Unit isolated from vital voting
✓ Reads vital decisions after voting complete
✓ No timing constraints on service unit
✓ Service unit failure ≠ safety loss
✓ Simplest architecture for SIL 4
Platform_RTE Code Example:**
Pattern 2: Service Unit with Read-Only Access
Pattern 3: Asynchronous Service Unit (High-Volume Logging)
Vital Channels Service Unit
├─ Process safely └─ Process non-critical data
├─ Make decisions asynchronously
├─ Send outputs
└─ Queue results ─────→ Log queue
├─ Flush periodically
├─ Compress logs
├─ Send to disk/network
└─ No time pressure
When to use:** When service unit is logging high-frequency vital decisions but can't keep up in real-time.
The vital channel puts each decision into a bounded queue and returns immediately; the service unit drains the queue asynchronously and does the slow work (compression, storage). The queue is application code; Platform_RTE provides no rte_queue.
Service Unit Failure Scenarios
| Scenario | Impact | Response |
| Service Unit crashes | Logging lost, dashboard unavailable | Vital channels continue, restart service unit when ready |
| Service Unit hangs | Diagnostics delayed | Vital channels unaffected, restart service unit |
| Service Unit out of disk | Historical data not stored | Alert operator, continue vital operation |
| Service Unit network down | Cannot send remote diagnostics | Vital channels continue locally |
| Service Unit memory corruption | Corrupted logs/stats | Vital channels unaffected (isolated) |
Key:** Service unit failures NEVER affect safety decisions or vital outputs.
EN 50128 Treatment of Service Units
EN 50128 Section 6.7.4: Layered Architecture
"Non-vital functions shall be isolated from vital safety-critical
layers to prevent common-mode failures or timing effects."
Requirements:
✓ Service unit separated from vital processing
✓ Service unit does NOT vote or control safety outputs
✓ Service unit reads vital outputs AFTER decision
✓ Service unit failure has no safety impact
✓ Service unit verification can use standard methods
(not required to be SIL 4)
Service Unit Software Stack
Service unit CAN use software practices that SIL 4 vital channels cannot:
Vital Channels (SIL 4 strict):
├─ No dynamic memory
├─ Fixed-size buffers
├─ Deterministic timing
├─ MISRA C:2012 mandatory
└─ High verification cost
Service Unit (Best-effort):
├─ Standard malloc/free OK
├─ Dynamic data structures OK
├─ Standard libraries OK
├─ Standard POSIX/RTOS APIs OK
├─ Database OK
├─ Web server OK
├─ Python/scripting OK
└─ Low verification cost
Example: Service Unit in Python**
import logging
from datetime import datetime
from database import RBCDatabase
logging.basicConfig(level=logging.INFO)
db = RBCDatabase()
def process_vital_results(vital_decision):
"""Service unit processes non-vital data asynchronously"""
db.insert_log({
'timestamp': datetime.now(),
'decision': vital_decision['value'],
'latency_ms': vital_decision['latency']
})
stats = db.compute_hourly_statistics()
logging.info(f"Decision rate: {stats['decisions_per_sec']}/sec")
dashboard_html = generate_dashboard(stats)
return dashboard_html
Vital channels use Platform_RTE (strict C), Service Unit uses anything needed.
Typical Service Unit Functions
1. Logging & Audit Trail
Vital Channel: Service Unit:
├─ Make decision └─ Log every decision
├─ Output result (with timestamp, latency,
└─ Send to next decision value, etc.)
channel
└─ Store in database
or file system
2. Performance Monitoring
Vital Channels run fast (deterministic)
Service Unit monitors:
├─ Latencies (decision time, voting time)
├─ Fault detection rates
├─ Watchdog recovery statistics
├─ Network delays
└─ Processor load
3. Predictive Maintenance
Service Unit analyzes:
├─ Fault patterns (which faults occur most?)
├─ Recovery time trends
├─ Component health
├─ Upcoming maintenance windows
└─ Spare parts inventory
4. Operator Dashboard
Service Unit provides:
├─ Real-time system status
├─ Trend graphs
├─ Alert history
├─ Configuration UI
├─ Training/simulation mode
└─ Remote diagnostics
5. Optimization Tuning
Service Unit can:
├─ Adjust timeouts based on network conditions
├─ Tune voting parameters
├─ Optimize checkpoint intervals
├─ Suggest configuration changes
├─ Manage resource allocation
Service Unit Deployment Options
Option A: Separate Physical Processor
┌──────────────┐ ┌──────────────┐
│ CPU A (SIL) │ │ CPU B (SIL) │
│ Vital Ch.A │ │ Vital Ch.B │
└──────┬───────┘ └───────┬──────┘
│ │
└────────────┬────────────┘
│ Results
│
┌─────────▼──────────┐
│ Separate Service │
│ Unit Processor │
│ │
│ Logging │
│ Database │
│ Dashboard │
└────────────────────┘
Pros:
✓ Complete isolation from vital channels
✓ Can use different OS/RTOS
✓ Scaling: add/remove service units independently
✓ Minimal security risk to vital functions
Cons:
✗ Additional hardware cost
✗ Network communication overhead
✗ One more device to manage
Option B: Same Processor, Different Memory
┌─────────────────────────────────────┐
│ Single Processor CPU │
├────────────────────┬────────────────┤
│ Vital Code/Data │ Service Code/ │
│ (Protected Memory)│ Data (Open) │
│ │ │
│ ✓ SIL 4 │ ✓ Best-effort │
│ ✓ Deterministic │ ✓ Optimized │
│ ✓ Certified │ ✓ No timing │
│ (Memory- │ constraints │
│ protected) │ │
└────────────────────┴────────────────┘
Pros:
✓ Lower cost (single CPU)
✓ No inter-processor communication
✓ Simpler deployment
Cons:
✗ Memory protection required
✗ Service unit can still affect vital functions
if protection fails
✗ More complex certification argument
Option C: Containerized Service Unit
┌──────────────────────────────────────┐
│ Safety-Critical Container (SIL 4) │
├──────────────────────────────────────┤
│ Platform_RTE Vital Channels │
│ Safety logic, voting, outputs │
└──────────────────────────────────────┘
│ API
▼
┌──────────────────────────────────────┐
│ Service Container (Best-Effort) │
├──────────────────────────────────────┤
│ Logging, monitoring, diagnostics │
│ User interface │
│ Data analytics │
└──────────────────────────────────────┘
Pros:
✓ Modern cloud-native deployment
✓ Easy scaling and updates
✓ Service unit can restart independently
✓ Resource limits enforced by orchestrator
Cons:
✗ Adds container overhead
✗ Different verification model
✗ Distributed debugging more complex
Service Unit Integration Checklist
Before integrating a service unit with your vital channels:
- Service unit architecture selected (separate processor / same CPU / containerized)?
- Data flow defined (what vital data does service unit access)?
- Failure scenarios analyzed (service unit failure doesn't affect safety)?
- Access control designed (service unit cannot modify vital state)?
- Timing analyzed (service unit latency doesn't affect vital decisions)?
- Certification scope clear (vital channels SIL 4, service unit SIL 0)?
- Recovery mechanism defined (how to restart service unit)?
- Logging capacity estimated (how much data does service unit generate)?
- Security reviewed (service unit isolated from safety functions)?
- Real-world ERTMS use case validated?
Real-World ERTMS Service Unit Example
Siemens RBC Configuration:**
Vital Layer (SIL 4):
├─ Siemens S7-1500F (SIL 4 controller)
└─ 2oo3 voting on movement authority
Service Layer (Best-Effort):
├─ Separate Linux server
├─ PostgreSQL database (train history)
├─ Grafana dashboards (operator UI)
├─ ELK stack (logging and analysis)
├─ Python scripts (predictive maintenance)
└─ REST API (remote diagnostics)
Integration:
- Vital channels write critical decisions to queue
- Service unit reads queue asynchronously
- Service unit feeds data to database/dashboard
- Operator sees real-time RBC status
- Engineers can analyze historical data
CPU Diversification for SIL 4
Critical Safety Consideration:** Using identical CPUs in redundant channels can lead to common-mode failures where both CPUs fail in the same way (e.g., same design flaw, same timing bug, same cosmic ray vulnerability).
Types of Diversification
1. Vendor Diversification (Recommended for SIL 4)
Different CPU manufacturers reduce systematic design faults
Example: 2oo2 with diverse vendors
├─ Channel A: Intel Core i7
├─ Channel B: AMD Ryzen
└─ Benefit: Different microarchitectures, instruction sets
Why it matters:**
Identical CPUs:
├─ Both have same instruction set bugs
├─ Both affected by same errata
├─ Design flaw in CPU → Both fail identically
└─ Result: Common-mode failure ✗
Diverse CPUs:
├─ Different instruction sets
├─ Different design teams
├─ Flaws unlikely to manifest identically
└─ Result: Independent failures ✓
2. Architecture Diversification
Different CPU architectures (ISA level)
Example Combinations:
├─ ARM (RISC) + x86 (CISC)
├─ ARM Cortex-A + ARM Cortex-M
├─ PowerPC + x86
└─ MIPS + ARM
Benefits:**
3. Generation Diversification
Using different CPU generations
Example:
├─ Channel A: Intel Core i7 (9th gen)
├─ Channel B: Intel Core i7 (12th gen)
└─ Benefit: Different silicon, different errata
Consideration:** Less effective than vendor/architecture diversity
4. Non-Diversified (What NOT to do)
Identical CPUs = Risk of common-mode failures
Example (RISKY for SIL 4):
├─ Channel A: Intel Xeon E5-2690
├─ Channel B: Intel Xeon E5-2690 ← Same exact model
├─ Channel C: Intel Xeon E5-2690 ← Same exact model
│
└─ Problem: All 3 fail identically if:
├─ Design flaw in Xeon E5
├─ Microcode bug
├─ Power supply issue
└─ Thermal issue affecting all
CPU Diversification by Architecture Type
2oo2 (Dual-Channel)
Recommended:**
Vendor or Architecture Diversification ESSENTIAL
2oo2 Intel A + Intel B = ✗ RISKY (same design flaws)
2oo2 Intel + AMD = ✓ BETTER (different designs)
2oo2 ARM + x86 = ✓ BEST (completely different)
Why: With only 2 channels and no fault tolerance, you must prevent common-mode failures. If both identical CPUs fail the same way, voting fails.
2oo3 (Triple-Channel)
Recommended:**
Diverse vendors across sites
2oo3 Intel + Intel + Intel = ✗ RISKY (common-mode)
2oo3 Intel + AMD + Intel = ✓ GOOD (majority diverse)
2oo3 Intel + AMD + ARM = ✓ BEST (all diverse)
2oo3 x86 + ARM + PowerPC = ✓ EXCELLENT (maximum diversity)
Why: With 3 channels, you can tolerate 1 identical failure, but 2 simultaneous identical failures would be catastrophic. Diversity reduces this risk.
Cluster-2oo2 (Site-Level Redundancy)
Recommended:**
Each site can be identical (failover redundancy),
BUT within each site, consider diversity
Site A: 2oo2 (Intel + AMD) ← Diverse internally
Site B: 2oo2 (Intel + AMD) ← Diverse internally
Result: ✓ Both sites resilient to CPU-level faults
OR simpler:
Site A: Single Intel ← Accepts risk
Site B: Single Intel ← Accepts risk
(Failover provides system-level fault tolerance,
but CPU-level faults not addressed)
EN 50128 Requirements for Diversification
EN 50128 Section 7.2.3: Defensive Programming
"Diverse redundancy shall be used to protect against
systematic faults in the same failure mode."
EN 50129 Functional Safety Requirements:
"Redundant channels shall use diverse implementations
to prevent common-mode failures."
Diversification Trade-offs
| Aspect | Identical CPUs | Diverse CPUs |
| Systematic Fault Risk | ✗ High (common-mode) | ✓ Low |
| Verification Effort | ✓ Low | ✗ High (2 toolchains) |
| Cost | ✓ Low | ✗ Higher |
| Development Time | ✓ Shorter | ✗ Longer |
| SIL 4 Confidence | ✗ Lower | ✓ Higher |
| Real ERTMS Systems | Diverse | Used worldwide |
Real-World ERTMS Example
Siemens ERTMS RBC (Typical):**
Site A: Siemens SIM3+ processor (custom safety ASIC)
Site B: Different Siemens platform or alternate vendor
Site C: Redundant diverse system (if 2oo3)
Why:
├─ Different designs from different vendors
├─ Different silicon manufacturers
├─ Different firmware/software implementations
└─ Reduces risk of all sites failing identically
Recommendation for Diversification
For 2oo2 Systems (SIL 3/4):
✓ STRONGLY RECOMMENDED: Vendor or architecture diversity
├─ Intel + AMD (x86)
├─ ARM + x86
└─ Different FPGA vendors if FPGA-based
Rationale: With only 2 channels, common-mode failure
would lose all redundancy immediately
For 2oo3 Systems (SIL 4):
✓ RECOMMENDED: At least vendor diversity
├─ Option 1: Intel + AMD + third vendor
├─ Option 2: ARM Cortex + x86 + PowerPC
└─ Option 3: Different FPGA + different CPU
Rationale: Reduces probability that 2+ sites fail
identically (need >1 fault to lose redundancy)
For Cluster-2oo2 (SIL 4):
✓ OPTIONAL at site level, but RECOMMENDED within each site
Within Site A (2oo2): Use diverse CPUs (Intel + AMD)
Within Site B (2oo2): Use diverse CPUs (Intel + AMD)
Benefit: Each site resilient to CPU-level faults
Cluster failover provides site-level redundancy
CPU Selection for SIL 4
Certification Status
Before choosing CPU, verify ERTMS certification:
Certified for ERTMS:
├─ Siemens safety controllers
├─ Alstom CBTC platforms
├─ Hitachi Rail systems
├─ Thales CBTC solutions
└─ Intel/AMD commercial with certified software stack
NOT directly certified:
├─ Consumer-grade CPUs (unless in certified platform)
├─ Uncertified FPGA vendors
└─ Experimental processors
Practical Diversification Example
SIL 4 RBC with 2oo3 architecture:
OPTION A: All diverse (BEST but expensive)
├─ Site A: Siemens SIM platform
├─ Site B: Alstom Urbalis platform
├─ Site C: Thales cBridge platform
OPTION B: Diverse vendors, same architecture family
├─ Site A: Siemens S7-1500
├─ Site B: Rockwell CompactLogix
├─ Site C: Mitsubishi Q-series
OPTION C: Same vendor, diverse models
├─ Site A: Siemens S7-1500
├─ Site B: Siemens S7-400
├─ Site C: Siemens S7-300
│
└─ Trade-off: Less diverse but simpler verification
Diversification Checklist for SIL 4
Before finalizing CPU selection:**
- Different CPU vendors or architectures chosen?
- All CPUs ERTMS or equivalent certified?
- Verification required for each CPU type?
- Development toolchains compatible?
- Cost and schedule impact acceptable?
- Common-mode failure analysis completed?
- FMEA includes CPU-diversity impact?
- Safety case argues for diversity benefit?
Summary by pattern
See the pattern catalog above for detection, masking and status. Selection follows the decision questions; this project uses 2oo2 with redundancy.
References
1.18.0