Railway Digitalisation and Communication Systems: Safety, Availability and Cybersecurity
Introduction
Railway digitalisation connects rolling stock, signalling, control centres, stations, maintenance systems and operational assets through data acquisition, automation and communications. The safety value depends on trustworthy information, bounded latency, availability, secure interfaces and defined degraded operation.
As embedded products become more connected and software-intensive, design decisions must account for the complete system context: intended function, operating environment, interfaces, fault behavior, lifecycle changes and evidence. The objective of this article is to explain the concept and outline practical engineering activities without treating a high-level overview as a completed safety or security assessment.
Architecture and Context
Trackside sensors/signalling → wayside controllers and interlocking interfaces → railway communication backbone (wired/fibre/radio) → control centre/traffic management → onboard train control and HMI. Separate operational technology (OT), maintenance, passenger information and enterprise domains with controlled gateways and security zones.
Standards and Applicability
EN 50126 is commonly used for railway RAMS; EN 50129 for safety-related electronic signalling; EN 50159 for safety-related communication. Verify EN 50128/EN 50716 transition and national adoption. IEC 62443 may support OT cybersecurity. Confirm project editions and contractual requirements. Confirm the current controlled edition, amendments, national adoption, product scope and contractual basis before using a standard as a project requirement.
Lifecycle and Traceability
- Define intended use, system boundary, operating modes, stakeholders and assumptions.
- Identify hazards, failure modes, threats or dependencies relevant to the topic.
- Derive measurable requirements and allocate them to hardware, software, interfaces and operational controls.
- Document architecture decisions, safety/security mechanisms, constraints and residual risks.
- Plan reviews, analyses, tests and integration evidence against the actual configuration.
- Maintain traceability and reassess the analysis after changes, incidents or new information.
Illustrative Failure / Risk Scenarios
The following scenarios are illustrative engineering prompts. They are not a completed HARA, FMEA, FMEDA, TARA, DFA or risk classification. Severity, likelihood, ASIL/SIL, diagnostic coverage and acceptability must be established using the applicable method and evidence.
| Scenario | Potential effect / review focus |
| Stale or corrupted movement/operational data | May cause incorrect operator or control-system decisions. |
| Loss of communication between train and wayside | May force restrictive operation, degraded service or loss of a required control function. |
| Unauthorized access to operational networks | May affect availability, configuration or integrity of railway functions. |
| Time synchronization or identity error | May associate events or commands with the wrong asset or time. |
| Gateway misconfiguration | May permit unintended traffic between safety-related and non-safety domains. |
Requirements and Implementation Considerations
Define communication safety requirements, message integrity/authentication, sequence and freshness checks, timeouts, redundancy, network segmentation, gateway allow-lists, identity management, secure configuration, logging, failover, degraded-mode operating rules and recovery. Identify which communication functions are safety-related and allocate requirements accordingly.
Verification and Validation
Perform network architecture and threat reviews, protocol robustness testing, latency/jitter/load testing, packet loss/reordering/replay tests, link failover and outage tests, gateway rule verification, time synchronization tests, penetration testing under an approved scope, and end-to-end operational scenario validation. Confirm safety-related communication measures against the applicable railway standards and system safety case.
| Verification area | Evidence to retain |
| Design review | Architecture, assumptions, interface and safety/security review records. |
| Analysis | Traceable calculations, failure analysis, dependency/threat analysis and rationale. |
| Testing | Requirements-based, boundary, fault-injection, robustness and integration results. |
| Configuration | Hardware/software versions, BOM, settings, tool versions and test setup. |
| Issue closure | Anomalies, deviations, corrective actions, residual risks and approvals. |
Common Pitfalls
| Pitfall | Recommended practice |
| Treating a concept or component feature as proof of system safety | Build an end-to-end argument with system context and objective evidence. |
| Using assumptions that are not documented | Record, review and validate assumptions and dependencies. |
| Testing only nominal behavior | Include credible faults, boundary conditions, overload and recovery. |
| Using generic metrics or labels without context | Apply the correct standard definitions, boundaries and assumptions. |
| Not updating evidence after design changes | Maintain configuration control and impact analysis. |
Related Engineering Disciplines
Depending on the application, this topic intersects with system architecture, functional safety, reliability engineering, cybersecurity, embedded hardware/software development, human factors, verification and validation, production quality and field support.
Expert Engineering Deep Dive
Railway communications engineering:
Develop an end-to-end data-flow model from originator to receiver, including gateways, routers, radio bearers, protocol conversion, time sources and control-centre interfaces. Classify each data flow as safety-related, operational, passenger-facing, maintenance or enterprise. Identify the authority that may originate commands and the receiving function that validates them.
For safety-related transmission, define application-level defenses for corruption, repetition, deletion, insertion, delay, reordering, masquerade and incorrect addressing. Specify sequence counters, freshness windows, end-to-end integrity checks, source identity, timeout behavior and receiver reaction. Cryptographic protection can support authenticity and confidentiality but does not replace safety communication principles or deterministic failure handling.
Calculate a communication budget across processing, queueing, network transmission, radio access, retransmission and receiver processing. State maximum latency, jitter, message age, update rate and loss tolerance. Test under congestion, handover, coverage holes, interference, route changes, partial network partitions and clock drift. Redundancy must be assessed for shared power, backhaul, towers, antennas, software and network management dependencies.
Operational resilience requires clear degraded-mode rules. Define what the train, wayside system and control centre do when communication is lost, stale or inconsistent. Specify operator indications, movement restrictions, local fallback, recovery authorization and event logging. Validate the operational procedure as well as the protocol.
Engineering Review Matrix
| Data-flow property | Engineering control/evidence |
| Authenticity and identity | Trusted endpoint identity, command authorization and receiver validation |
| Integrity and sequence | End-to-end integrity, sequence/freshness checks and replay/reordering tests |
| Timeliness | Latency/jitter budget, timeout and stale-data rejection |
| Availability | Coverage model, redundancy dependency analysis and failover tests |
| Degraded operation | Operational rules, HMI indication, fallback and recovery validation |
- Related VerveTronics knowledge-centre and service pages may be linked where they add context; ensure links remain live before publication.
- Normative standards: use the controlled official standard and applicable edition; do not rely on summaries for normative requirements.
- ☐ Validate technical statements and standards references with a qualified reviewer.
- ☐ Check that no unsupported certification, compliance, ASIL/SIL or diagnostic-coverage claim is made.
- ☐ Review SEO title, slug, meta description, keyword placement and internal links.
- ☐ Add original or licensed diagrams and verify descriptive alt text.
- ☐ Ensure FAQ schema exactly matches visible published FAQs.
- ☐ Add author, technical reviewer, publication date and next review date.
| Concern | Engineering questions |
| System boundary | What elements, operating modes, users and external interfaces are included? |
| Fault and failure behavior | What happens when components, inputs, power, timing or communications fail? |
| Independence / isolation | Are shared resources or dependencies capable of defeating intended separation? |
| Requirements and traceability | Are assumptions and controls measurable, allocated and verifiable? |
| Verification evidence | Do analyses and tests represent the real configuration and operating envelope? |
| Lifecycle control | How are updates, suppliers, maintenance and design changes assessed? |
Potential engagement outputs include architecture and gap-review reports, requirements and traceability matrices, safety/security analyses, verification strategies, test specifications and engineering evidence packs. The exact scope should be agreed against the applicable standard, product maturity and customer/regulatory requirements. Consulting support does not itself constitute certification or regulatory approval.
- Does railway digitalisation automatically improve safety? It can improve monitoring and decision support, but new interfaces and dependencies can introduce hazards unless safety, availability and security are engineered together.
- Is encryption enough for safety-related railway communication? No. Safety communication also needs measures such as sequence, timeliness, integrity, authenticity and protection against repetition or masquerade, as required by the application.
- Should safety and cybersecurity networks always be physically separate? Not always; the architecture must justify segregation, controlled conduits, access controls and independence for the actual risk and safety requirements.