MBSE in Rail and Transit: Where It’s Delivering and Where It’s Still Struggling

Rail is not a domain that moves fast. Procurement cycles run in decades. Certification dependencies stretch programs by years. And the cost of a safety failure — regulatory, financial, reputational — is existential in a way that few other industries match. These characteristics have historically made rail conservative about engineering process change, and understandably so.

That conservatism is cracking. Not because the industry has suddenly become adventurous, but because the complexity of modern rail systems has outrun the capacity of document-based engineering to manage it safely and economically. The systems that are now being specified, procured, and certified — ETCS Level 2 and Level 3 signaling, CBTC for urban metros, next-generation TCMS platforms, hydrogen and battery propulsion integration — involve interface densities, safety argument depths, and variant management challenges that traditional systems engineering was not designed to handle at this scale.

Model-Based Systems Engineering is the response. Adoption is uneven, implementation quality varies widely, and the relationship between MBSE practice and regulatory expectation is still being negotiated in real time. But the direction is clear, and the organizations that are getting it right are seeing measurable returns.

What’s Driving Adoption Now

Two pressures are converging simultaneously: technical complexity and commercial pressure.

On the technical side, modern signaling architecture has become the forcing function. ETCS Level 2, which relies on continuous communication between the ERTMS Radio Block Controller and onboard equipment, involves a large and precisely specified interface set between trackside, onboard, and control systems. A single ETCS deployment across a mainline corridor can involve dozens of suppliers, multiple Subset-026 compliance checkpoints, and interface control documents running to thousands of requirements. Managing that in a document-based environment — with spreadsheet RTMs, Word-format ICDs, and manual change control — creates a latent failure mode that doesn’t show up until integration testing, when it’s expensive to fix.

CBTC environments add a different dimension of complexity. Urban transit operators running mixed fleets — legacy rolling stock alongside new vehicles, potentially from different manufacturers — face interface management challenges at the wayside-to-vehicle boundary that are genuinely difficult to trace and verify without a shared model. When a wayside software upgrade affects the onboard ATP interface in ways that weren’t explicitly modeled, the discovery mechanism is often a failed test or, worse, an operational incident.

On the commercial side, rolling stock manufacturers are under sustained margin pressure on new vehicle programs. The economics of a modern EMU or DMU platform program depend heavily on the ability to deliver derivatives efficiently — airport express variants, regional versus commuter configurations, accessibility upgrades — without re-running full verification campaigns. If your systems engineering artifacts are documents, variant management is manual and error-prone. If they’re models, variant configurations can be systematically derived, changes can be propagated with traceability, and the verification evidence can be scoped to what actually changed.

Where MBSE Is Delivering Real Value

Interface Management

This is the clearest win. Rail systems are systems of systems by definition — rolling stock interfaces with infrastructure, signaling, power supply, and maintenance systems, each managed by a different organization under a different contractual and regulatory regime. Interface management at program level has historically been a documentation exercise with a coordination overhead that grows nonlinearly with system complexity.

MBSE changes the leverage point. When interfaces are defined in a shared model — with formal definitions of interface types, protocol specifications, and constraint sets — interface change requests can be evaluated against the model before they become contractual events. The impact of a proposed change to an ATP interface parameter can be traced to every requirement that references that interface, every verification test that exercises it, and every safety argument that depends on it. That’s not possible with a document architecture.

Several major European rolling stock programs — at Alstom, Siemens Mobility, and Stadler — have now institutionalized SysML-based interface models as program artifacts. The approach isn’t uniform, and the toolchain choices differ, but the principle is consistent: interfaces live in the model, not in email threads and manually maintained ICD spreadsheets.

Safety Case Development Under EN 50126 and EN 50129

EN 50126 defines the RAM (Reliability, Availability, Maintainability, Safety) lifecycle for railway applications. EN 50129 governs the safety case for electronic systems used in signalling and train control. Together, they define the evidentiary framework within which a safety argument must be constructed, reviewed, and accepted by a notified body.

Neither standard mandates MBSE. What they do mandate is rigorous, traceable, configuration-managed safety evidence — and those requirements are architecturally aligned with model-based practice.

The safety case under EN 50129 requires a structured argument linking hazards to safety requirements, safety requirements to design decisions, and design decisions to verification evidence. That’s a traceability graph. Organizations that maintain that graph in a model — where link integrity is enforced, where every requirement node has a defined owner, status, and verification method — are in a materially better position during NoBo assessment than those that reconstruct the argument from disconnected document sets.

The specific value shows up in configuration management. EN 50129 requires that the safety case remain valid through the entire lifecycle, including post-approval modifications. If a software change affects a safety function, the safety case must be updated to reflect that. In a document-based environment, this is a manual review process that is both expensive and unreliable. In a model-based environment, the impact set of a proposed change can be computed against the safety architecture before the change is implemented — enabling scoped re-assessment rather than full safety case review.

Derivative Platform and Change Management

The commercial case for MBSE in rolling stock is most visible on derivative programs. When a manufacturer has an existing platform — say, a diesel multiple unit that has been delivered to three operators — and is now developing an electric variant or an accessibility-upgraded derivative, the question is: what actually changed, and what do we need to re-verify?

In a document-based environment, this question is answered slowly and conservatively. Engineers review documents, try to identify differences, often over-scope the verification effort because the boundary between “changed” and “unchanged” is ambiguous. In a model-based environment with a properly managed baseline, the comparison is computational. The model tells you exactly what changed, what depends on what changed, and what the verification scope is.

Manufacturers who have invested in this capability — and it requires upfront investment in model governance, baseline management, and tool integration — are reporting significant reductions in verification scope on derivative programs, and corresponding reductions in the cost and duration of NoBo assessments.

Where Implementation Is Challenging

Honest assessment requires naming the difficulties, and in rail MBSE, they’re substantial.

Tool Proliferation and Integration Gaps

Rail programs typically involve multiple organizations — operator, prime integrator, subsystem suppliers, safety assessor — using different tools under different contracts. A program where the systems integrator uses IBM DOORS Next, a signaling supplier uses Polarion, and the onboard electronics supplier uses a proprietary requirements management system is not uncommon. Building a coherent model across that landscape requires interface agreements, data exchange standards, and governance overhead that many programs underestimate.

The OSLC (Open Services for Lifecycle Collaboration) standard was supposed to solve this. It helps, but it doesn’t eliminate the integration problem, and the effort required to maintain live connections between heterogeneous tools in a long-duration program is significant.

NoBo Consistency

The relationship between MBSE practice and regulatory assessment remains inconsistent. Notified bodies in the EU operate under EN 50129 and its associated Technical Specifications for Interoperability, but they have significant discretion in how they assess evidence. A model-based safety case that is accepted as primary evidence by one NoBo may require supplemental traditional documentation from another. This inconsistency creates a risk-aversion dynamic: programs produce both the model and the documents, which eliminates much of the efficiency gain.

The ERA (European Union Agency for Railways) has been working on guidance for model-based safety cases, and some NoBos have developed internal frameworks for assessing MBSE artifacts. But at the program level, the safe assumption is still that you need to be able to generate readable, auditable document outputs from your model — which means the model and the document both need to be maintained, at least for high-SIL functions.

Cultural and Organizational Resistance

This is the most underreported obstacle. Rail engineering organizations — particularly those that grew up in a heavily regulated, document-centric environment — have deep institutional processes built around documents as the authoritative engineering artifact. A requirements review meeting built around a DOORS export, a formal interface agreement represented as a signed ICD, a safety case structured as a document set: these are not just tools, they’re social and contractual artifacts with established legal standing.

Transitioning to model-based practice requires changing not just the tools but the processes, the contract language, the review mechanisms, and the skills of the people involved. Organizations that approach MBSE as a tool change — “we’re switching from DOORS to SysML” — consistently struggle. Organizations that approach it as a process redesign, with tool adoption as one element, fare better.

EN 50128 and Software Tool Qualification

EN 50128 applies to software for railway control and protection systems and includes requirements for the tools used in software development and verification. When an MBSE tool is used to generate artifacts that feed into a SIL-qualified software development process, there may be tool qualification obligations — specifically, the need to demonstrate that the tool doesn’t introduce errors into the safety-relevant output.

This is a non-trivial requirement. MBSE tools are not typically developed with EN 50128 tool qualification in mind, and the qualification effort can be significant. Programs that discover this late in the process face a choice between a costly retroactive qualification effort and a manual verification layer that negates much of the model-based efficiency gain.

How Modern Tooling Is Addressing These Constraints

The tooling landscape has matured considerably in the last three years. Modern requirements and systems engineering platforms are increasingly designed with the specific traceability and configuration management demands of safety-critical programs in mind.

Flow Engineering, an AI-native requirements and systems engineering platform built for hardware and systems teams, has been adopted by a number of complex systems programs precisely because it treats requirements as a connected graph rather than a document hierarchy. That architectural choice — where every requirement, interface, and verification artifact is a node with explicit, navigable relationships — aligns well with the traceability demands of EN 50126 and EN 50129 safety cases. The ability to compute impact sets from proposed changes, and to generate structured traceability reports that a safety assessor can follow, directly addresses the NoBo evidence problem.

Flow Engineering’s focus on graph-based models rather than document-based management also addresses one of the core failure modes in rail MBSE: the disconnection between the requirements baseline and the live engineering model. When the system model and the requirements are in the same connected environment, change propagation is continuous rather than periodic, and the safety case stays synchronized with the design rather than lagging behind it.

For organizations navigating the tool proliferation problem — multiple suppliers, multiple toolchains — the availability of structured export formats and API-based integration matters more than any single tool’s internal capability. The programs that are succeeding are those building an integration architecture first and selecting tools against it, rather than selecting tools and hoping integration follows.

Honest Assessment

MBSE is not a solution to rail’s systems engineering challenges. It’s a methodology that, when implemented well, makes those challenges more tractable. The distinction matters because “implementing MBSE” has become a procurement event in too many programs — organizations buy a tool, run a training course, and then find that the hard problems haven’t gone away.

The hard problems in rail MBSE are organizational: getting suppliers to use compatible methods, getting NoBos to accept model-based evidence consistently, building the internal capability to maintain a living model across a program lifecycle that may span fifteen years. Those problems don’t have tool solutions. They have discipline solutions.

The organizations that are seeing real returns — reduced integration test failures, faster NoBo assessments, lower cost on derivative programs — share a common characteristic: they treated MBSE as a capability investment, not a procurement decision. They built governance processes around the model, trained engineers on the methodology before they trained them on the tools, and defined contractual requirements for supplier model contributions before they signed supply contracts.

That’s not a dramatic conclusion, but it’s the honest one. MBSE works in rail when it’s treated seriously. When it isn’t, it adds overhead and complexity to an already complex environment. The pressure driving adoption — signaling system complexity, derivative platform economics, safety case depth — is real and increasing. The question for each program is whether the implementation approach is serious enough to match it.