With the development of railway systems towards intelligence, informatization and networking, their architecture design becomes increasingly complex. Traditional safety analysis methods (such as failure mode and effects analysis (FMEA), fault tree analysis (FTA) and event tree analysis) can no longer realise integrated safety analysis across disciplines, domains and life cycles amid requirement drift, architecture iteration and operational scenario evolution. This paper aims to introduce a systematic, integrated, model-driven safety analysis framework for the entire life cycle of railway systems to address these complex safety challenges and improve the overall safety level of railway systems.
First, the paper conducts a literature review of traditional railway safety analysis techniques and their applications, and analyzes the technical framework, core elements (modelling languages, methods, and tools), and advantages of Model-Based Systems Engineering (MBSE). Then, it studies the integration of MBSE and system safety analysis, focusing on typical international research cases (e.g., the Methodology for the Description and Safety Analysis of Interoperable Systems (MeDISIS), the European Train Control System (ETCS) safety verification project SafeSysE, and the Reference Architecture for Model-Based System and Software Engineering in the Railway Domain (RAMSAS), etc.) and domestic research progress, and summarizes the core idea of integrating MBSE with safety analysis in the design process. Finally, it explores the key technologies of MBSE-based railway system safety analysis, including automatic mapping of architecture models to Fault Tree Analysis (FTA), dynamic linkage between behaviour models and Failure Mode and Effects Analysis (FMEA), multi-model collaboration and dynamic update, as well as technologies in three aspects: safety requirement analysis driven by railway operational tasks, integrated safety-function design analysis, and simulation-based safety verification via train-fleet operation modelling. The development and validation platform Platform for Integrated Systems and Mechatronic Engineering (PRISME) and tools such as the Dependability Engineering and Innovation System (DEIS), Behavior-Driven Development (BDD) frameworks, and International Business Machines (IBM) engineering suites were also utilized to support this research.
The MBSE-based railway system safety analysis technique embeds safety activities into the forward-engineering workflow of MBSE-driven development, enabling concurrent safety and functional design. It solves the problems of model heterogeneity, data silos and process discontinuities in traditional safety analysis and realises end-to-end traceability and consistency from system requirements to safety analysis results. This technique not only provides a rigorous foundation for standardised, efficient and accurate safety assessment of railway systems but also offers technical support for early identification of potential safety issues, reduction of late-stage design changes and continuous optimisation of system safety performance.
The innovation of this paper mainly includes three aspects:(1) It breaks the limitations of traditional document-driven safety analysis methods, constructs an MBSE-based integrated safety analysis framework covering the entire life cycle of railway systems and turns safety work from an ad-hoc add-on into a systematic, goal-oriented activity. (2) It proposes key integration technologies such as automatic mapping of SysML-based architecture models to FTA, dynamic linkage between behaviour models (state machine diagram/activity diagram) and FMEA and multi-model (FTA/FMEA/hazard and operability analysis) collaborative dynamic update, which guarantee the consistency and traceability of safety analysis data and improve the efficiency of safety analysis iteration. (3) It develops a set of MBSE-based railway safety analysis implementation paths, including task-driven safety requirement decomposition, integrated safety function failure propagation modelling and train-fleet operation simulation-based verification, providing a practical technical solution for the safety design and analysis of complex railway systems.
1. Introduction
Railway system safety is a key indicator of operational quality and service reliability and a strategic prerequisite for the continuous, stable and healthy operation of the country's transportation infrastructure. As the railway system progresses towards intelligence, informatization and networking, its requirements are constantly changing and architecture design becomes increasingly complex (Qin et al., 2019). Traditional safety design methods based on failure mode and effects analysis (FMEA), fault tree analysis (FTA) or event tree analysis (ETA) are unable to achieve integrated safety analysis across disciplines, domains and life cycles during requirement drift, architecture iteration and operational scenario evolution. Therefore, it is urgent to introduce a systematic, integrated and model-driven safety analysis framework for the entire railway system life cycle to address these increasingly complex safety challenges.
1.1 Literature review
Commonly used railway safety analysis techniques include failure modes, effects and criticality analysis (FMECA), FTA, ETA, Petri nets and Bayesian networks. FMECA enumerates component failure modes, evaluates their system-level effects and assigns severity levels. FTA links basic events to the undesired top event through a graphical logic diagram (Zhang, Wang, & Feng, 2023). ETA starts from an initiating event and branches to quantify the probabilities of subsequent outcomes (Fan, Yu, Liao, Sun, & Xi, 2018). Petri nets describe concurrent and synchronous behaviour, permitting simulation of train operation and signalling processes under various scenarios (Wang, 2022). Bayesian networks represent conditional dependencies among random variables, supporting risk assessment and decision-making under uncertainty (Kang, Zheng, & Niu, 2018). Combined application of these methods characterises the safety properties of railway systems and improves overall performance; their validity and utility are well established in both research and practice.
Valis and Koucky (2011) applied an enhanced FMECA to perform a risk assessment of the ETCS Level-2 system and identified its critical effects and latent hazards (David et al., 2010). Chang et al. introduced an integrated weighting algorithm to improve railway signal safety risk analysis (Liu, Yang, Cui, & Yang, 2020). Liu et al. (2020) constructed an FTA with railway system failure as the top event and calculated the corresponding failure probability (Liu et al., 2025). Chen, Yan, and Liu (2024) defined rules for converting fault tree models to binary-decision-diagram models and proposed an improved multi-state multi-valued decision-diagram method to analyse the failure probability of high-speed-railway traction-power-supply systems (Chen et al., 2024).
1.2 Motivation and contributions
Model-based systems engineering (MBSE) is a systematic modelling approach that constructs models to improve system design quality, reduce cost and risk and shorten development cycle time. In contrast to traditional systems engineering, MBSE establishes multi-level, multi-view models that provide comprehensive support for requirements analysis and management, overcome the limitations of current modelling techniques in requirements analysis and architecture design and are widely applied in defence and aerospace industries (Hu, Wang, Wang, & Fu, 2020).
MBSE-based railway safety analysis embeds safety activities within the forward-engineering workflow of MBSE-driven development, enabling concurrent safety and functional design. By examining MBSE fundamentals and its railway applications, we propose an integrated modelling and safety analysis technique for railways; the associated key technologies supply a systematic methodological framework, raising overall railway safety.
2. Analysis of the current state of MBSE technology research
2.1 Model-based system engineering technology
The MBSE technical framework underpins requirements, design, analysis, verification and validation (V&V) activities, thereby spanning the entire life cycle from concept design through development and into subsequent operational phases (Zhu, Yang, Gao, & Yao, 2016). The corresponding process flow is illustrated in Figure 1. MBSE is the ensemble of related processes, methods and tools employed for systems engineering in a model-based environment (Delligatti, 2013); its deployment hinges on three principal elements: modelling languages, modelling methods and modelling tools (Friedenthal, Moore, & Steiner, 2014).
The diagram shows labeled rectangular boxes arranged along two slanted sides that meet at a point at the bottom. On the left, descending side of the V shape, four boxes are arranged from top to bottom and connected by straight black arrows sloping downward toward the center. These boxes are labeled, in order: “Requirement Definition”, “Demand analysis”, “Function analysis”, and “Architecture Design”. At the bottom center of the V shape is a box labeled “Design implementation”. This box represents the lowest point of the model. An arrow from “Architecture Design” connects to “Design implementation”. On the right, ascending side of the V shape, four boxes are arranged from bottom to top and connected by arrows sloping upward away from the center. These boxes are labeled, in order: “Component integration and verification”, “Subsystem integration and verification”, “System integration and verification”, and “Comprehensive verification and validation”. Horizontal arrows connect corresponding stages on the left and right sides of the V shape. Each of these horizontal connections is labeled with the repeated text “Verification and validation plan”, indicating alignment between development and verification activities at each level. At the lower left of the diagram, an arrow points diagonally downward toward the center of the V shape and is labeled “Requirement decomposition and definition”. At the lower right, an arrow points diagonally upward away from the center and is labeled “Integration and Verification”.Model-based system engineering flow diagram. Source: Author’s own work
The diagram shows labeled rectangular boxes arranged along two slanted sides that meet at a point at the bottom. On the left, descending side of the V shape, four boxes are arranged from top to bottom and connected by straight black arrows sloping downward toward the center. These boxes are labeled, in order: “Requirement Definition”, “Demand analysis”, “Function analysis”, and “Architecture Design”. At the bottom center of the V shape is a box labeled “Design implementation”. This box represents the lowest point of the model. An arrow from “Architecture Design” connects to “Design implementation”. On the right, ascending side of the V shape, four boxes are arranged from bottom to top and connected by arrows sloping upward away from the center. These boxes are labeled, in order: “Component integration and verification”, “Subsystem integration and verification”, “System integration and verification”, and “Comprehensive verification and validation”. Horizontal arrows connect corresponding stages on the left and right sides of the V shape. Each of these horizontal connections is labeled with the repeated text “Verification and validation plan”, indicating alignment between development and verification activities at each level. At the lower left of the diagram, an arrow points diagonally downward toward the center of the V shape and is labeled “Requirement decomposition and definition”. At the lower right, an arrow points diagonally upward away from the center and is labeled “Integration and Verification”.Model-based system engineering flow diagram. Source: Author’s own work
In the system design phase, MBSE employs models to execute the technical activities of systems engineering, thereby minimising requirement-transfer errors and enabling multi-disciplinary collaborative design. MBSE models describe and analyse system states, behaviours and interactions under defined scenarios and tasks; these models are used to verify and derive functional requirements and logical architectures, accommodate requirement changes rapidly and guide subsequent detailed design, production, testing and verification activities (Figure 2).
The table is divided into four horizontal sections, each with a colored left column, a central text column, and a right column containing labeled lists connected by bracket symbols. The top section is labeled “System requirements analysis” in the left column. In the central column, bullet points read: “Integrate the requirements of stakeholders”. “Drafting system requirements”. “System requirements mutual confirmation”. “Establish a traceability relationship”. In the right column, a labeled list reads “System Requirements”. Inside this section, four items are listed vertically: “Function Performance”. “Quality characteristics”. “Physical properties”. “Constraint/Interface”. Each item is preceded by a small square icon labeled “R subscript q”. The second section is labeled “Functional architecture design” in the left column. The central column lists: “Clarify the main functional scenario”. “Main Function”. “Implementation Plan”. “Completing the functional scheme trade-off”. The right column shows “System-level main function”. Inside this section, four items are listed vertically: “Behavior process”. “Flowing item”. “Usage scenario”. “Temporal sequence relationship”. Each item is preceded by a small square icon labeled “F subscript n”. The third section is labeled “Logical architecture design” in the left column. The central column lists: “Function allocation at each level of the system”. “Parameter indicator allocation”. “Port or interface parameters”. The right column shows “Functional logic decomposition”. Inside this section, four items are listed: “Requirements”. “Structure”. “Behavior”. “Main parameter”. Each item is preceded by a small square icon labeled “L subscript g”. The bottom section is labeled “Physical architecture design” in the left column. The central column lists: “Selection of physical components”. “Physical component trade-off analysis”. “Decision on the realization approach”. The right column shows “Physical system architecture”. Inside this section, four items are listed: “Component Model”. “Cost-benefit analysis”. “Characteristic Analysis”. “Use case verification”. Each item is preceded by a small square icon labeled “P subscript d”.The hierarchical process and element decomposition diagram for MBSE system architecture design. Source: Author’s own work
The table is divided into four horizontal sections, each with a colored left column, a central text column, and a right column containing labeled lists connected by bracket symbols. The top section is labeled “System requirements analysis” in the left column. In the central column, bullet points read: “Integrate the requirements of stakeholders”. “Drafting system requirements”. “System requirements mutual confirmation”. “Establish a traceability relationship”. In the right column, a labeled list reads “System Requirements”. Inside this section, four items are listed vertically: “Function Performance”. “Quality characteristics”. “Physical properties”. “Constraint/Interface”. Each item is preceded by a small square icon labeled “R subscript q”. The second section is labeled “Functional architecture design” in the left column. The central column lists: “Clarify the main functional scenario”. “Main Function”. “Implementation Plan”. “Completing the functional scheme trade-off”. The right column shows “System-level main function”. Inside this section, four items are listed vertically: “Behavior process”. “Flowing item”. “Usage scenario”. “Temporal sequence relationship”. Each item is preceded by a small square icon labeled “F subscript n”. The third section is labeled “Logical architecture design” in the left column. The central column lists: “Function allocation at each level of the system”. “Parameter indicator allocation”. “Port or interface parameters”. The right column shows “Functional logic decomposition”. Inside this section, four items are listed: “Requirements”. “Structure”. “Behavior”. “Main parameter”. Each item is preceded by a small square icon labeled “L subscript g”. The bottom section is labeled “Physical architecture design” in the left column. The central column lists: “Selection of physical components”. “Physical component trade-off analysis”. “Decision on the realization approach”. The right column shows “Physical system architecture”. Inside this section, four items are listed: “Component Model”. “Cost-benefit analysis”. “Characteristic Analysis”. “Use case verification”. Each item is preceded by a small square icon labeled “P subscript d”.The hierarchical process and element decomposition diagram for MBSE system architecture design. Source: Author’s own work
Presently, MBSE models of system requirements, architecture and behaviour are built with SysML; the corresponding model structure is summarised in Figure 3 (Wolny, Mazak, Carpella, Geist, & Wimmer, 2020). Behavioural views comprise activity diagrams (behaviour flow), sequence diagrams (inter-module interactions during behaviour execution), state machine diagrams (system state transitions) and use-case diagrams (required system functions) (Friedenthal et al., 2014).
A legend at the bottom identifies three types of boxes: A solid-outline box reads “Same as U M L 2”. A solid-outline highlighted box reads “Modified from U M L 2”. A dashed-outline box reads “New diagram type”. At the top center, a box reads “S y s M L Diagram (Same as U M L 2)”. Below it, three boxes are arranged horizontally and connected upward to “S y s M L Diagram”. The left box reads “Behavior Diagram (Same as U M L 2)”. The dashed center box reads “Requirement Diagram (New diagram type)”. The right box reads “Structure Diagram (Same as U M L 2)”. Under “Behavior Diagram”, four boxes are arranged horizontally and connected upward to it. These boxes read: “Activity Diagram (Modified from U M L 2)”, “Sequence Diagram (Same as U M L 2)”, “State Machine Diagram (Same as U M L 2)”, and “Use Case Diagram (Same as U M L 2)”. Under “Structure Diagram”, three boxes are arranged horizontally and connected upward. These boxes read: “Block Definition Diagram (Modified from U M L 2)”, “Internal Block Diagram (Modified from U M L 2)”, and “Package Diagram (Same as U M L 2)”. Below “Internal Block Diagram”, a dashed-outline box is connected with an upward arrow. This box reads “Parametric Diagram (New diagram type)”.SysML model composition diagram. Source: Wolny et al. (2020)
A legend at the bottom identifies three types of boxes: A solid-outline box reads “Same as U M L 2”. A solid-outline highlighted box reads “Modified from U M L 2”. A dashed-outline box reads “New diagram type”. At the top center, a box reads “S y s M L Diagram (Same as U M L 2)”. Below it, three boxes are arranged horizontally and connected upward to “S y s M L Diagram”. The left box reads “Behavior Diagram (Same as U M L 2)”. The dashed center box reads “Requirement Diagram (New diagram type)”. The right box reads “Structure Diagram (Same as U M L 2)”. Under “Behavior Diagram”, four boxes are arranged horizontally and connected upward to it. These boxes read: “Activity Diagram (Modified from U M L 2)”, “Sequence Diagram (Same as U M L 2)”, “State Machine Diagram (Same as U M L 2)”, and “Use Case Diagram (Same as U M L 2)”. Under “Structure Diagram”, three boxes are arranged horizontally and connected upward. These boxes read: “Block Definition Diagram (Modified from U M L 2)”, “Internal Block Diagram (Modified from U M L 2)”, and “Package Diagram (Same as U M L 2)”. Below “Internal Block Diagram”, a dashed-outline box is connected with an upward arrow. This box reads “Parametric Diagram (New diagram type)”.SysML model composition diagram. Source: Wolny et al. (2020)
In complex system development, MBSE offers three concrete advantages. First, it decomposes and traces requirements through multi-view, multi-level models, creating an unbroken path from top-level mission requirements to intermediate product requirements and, ultimately, to low-level component physical specifications. Second, its standardised modelling syntax yields a single, consistent data set that all disciplines can share during collaborative design. Third, MBSE integrates diverse simulation techniques, enabling multi-domain, multi-physics and high-fidelity analyses early in development.
The approach is already operational in aerospace, defence and automotive programmes. The “systems engineering ellipse” model, for instance, iterates through requirement definition, system analysis, design, implementation and verification, with explicit feedback loops between life cycle stages. Likewise, automotive functional-safety standard International Organization for Standardization 26262 mandates that safety analyses proceed in parallel with development and that a complete safety case be delivered for review (Cuenot, Ainhauser, & Adler, 2014) (Figure 4).
The flow diagram is divided into two main sections, indicated by thick horizontal arrows at the top. At the top left, a thick horizontal arrow points to the right and is labeled “Definition and Design”. At the top right, a thick horizontal arrow also points to the right and is labeled “Testing and Integration”. Left section: Definition and Design: At the upper left, a rectangular box is labeled “Safety plan”. To its right, another rectangular box is labeled “Project Definition or Operational Scenario”. Below “Safety plan”, a rectangular box labeled “Safety objective or system H A R A” is connected by a diagonal downward arrow. Below this, another box labeled “Subsystem H A R A” is connected by a further diagonal arrow. Below “Subsystem H A R A”, a box labeled “Software and hardware security requirements” appears, connected by a diagonal arrow. Below “Project Definition or Operational Scenario”, a rectangular box labeled “System Requirements” is connected by a diagonal downward arrow. Below “System Requirements”, a box labeled “Function and Physical Architecture Definition” is connected by a diagonal arrow. Below this, a box labeled “Detailed Design” is connected by another diagonal arrow. Right section: Testing and Integration: At the top of the right section, two rectangular boxes appear side by side. The left box is labeled “System confirmation”, and the right box is labeled “Safety confirmation”. Below “System confirmation”, a box labeled “System verification” is connected by an upward-pointing arrow. Below “Safety confirmation”, a box labeled “System security verification” is connected by an upward-pointing arrow. Below “System verification”, a box labeled “Subsystem verification” is connected by an upward-pointing arrow. Below “System security verification”, a box labeled “Subsystem security verification” is connected by an upward-pointing arrow. Below “Subsystem verification”, a box labeled “Unit testing” is connected by an upward-pointing arrow. Below “Subsystem security verification”, a box labeled “Hardware and software security verification and validation” is connected by an upward-pointing arrow. In the center of the diagram, horizontal arrows connect stages from the left section to corresponding stages on the right section: A leftward-pointing arrow connects “System Requirements” on the left to “System verification” on the right. The text above this arrow reads “Verify the fault operation scenario”, and the text below reads “Check the system requirements and security objectives”. Another leftward-pointing arrow connects “Function and Physical Architecture Definition” to “Subsystem verification”. The text above this arrow reads “Revise the advanced design”, and the text below reads “Update system security analysis”. A third leftward-pointing arrow connects “Detailed Design” to “Unit testing”. The text above this arrow reads “Revise the detailed design”, and the text below reads “Update subsystem security analysis”. Along the bottom of the diagram, two curved arrows arc from left to right. These arrows originate near “Detailed Design” and “Software and hardware security requirements” on the left side and curve upward toward “Unit testing” and “Hardware and software security verification and validation” on the right side, indicating iterative feedback between design and verification stages.Automotive industry standard V model development process. Source: Cuenot et al. (2014)
The flow diagram is divided into two main sections, indicated by thick horizontal arrows at the top. At the top left, a thick horizontal arrow points to the right and is labeled “Definition and Design”. At the top right, a thick horizontal arrow also points to the right and is labeled “Testing and Integration”. Left section: Definition and Design: At the upper left, a rectangular box is labeled “Safety plan”. To its right, another rectangular box is labeled “Project Definition or Operational Scenario”. Below “Safety plan”, a rectangular box labeled “Safety objective or system H A R A” is connected by a diagonal downward arrow. Below this, another box labeled “Subsystem H A R A” is connected by a further diagonal arrow. Below “Subsystem H A R A”, a box labeled “Software and hardware security requirements” appears, connected by a diagonal arrow. Below “Project Definition or Operational Scenario”, a rectangular box labeled “System Requirements” is connected by a diagonal downward arrow. Below “System Requirements”, a box labeled “Function and Physical Architecture Definition” is connected by a diagonal arrow. Below this, a box labeled “Detailed Design” is connected by another diagonal arrow. Right section: Testing and Integration: At the top of the right section, two rectangular boxes appear side by side. The left box is labeled “System confirmation”, and the right box is labeled “Safety confirmation”. Below “System confirmation”, a box labeled “System verification” is connected by an upward-pointing arrow. Below “Safety confirmation”, a box labeled “System security verification” is connected by an upward-pointing arrow. Below “System verification”, a box labeled “Subsystem verification” is connected by an upward-pointing arrow. Below “System security verification”, a box labeled “Subsystem security verification” is connected by an upward-pointing arrow. Below “Subsystem verification”, a box labeled “Unit testing” is connected by an upward-pointing arrow. Below “Subsystem security verification”, a box labeled “Hardware and software security verification and validation” is connected by an upward-pointing arrow. In the center of the diagram, horizontal arrows connect stages from the left section to corresponding stages on the right section: A leftward-pointing arrow connects “System Requirements” on the left to “System verification” on the right. The text above this arrow reads “Verify the fault operation scenario”, and the text below reads “Check the system requirements and security objectives”. Another leftward-pointing arrow connects “Function and Physical Architecture Definition” to “Subsystem verification”. The text above this arrow reads “Revise the advanced design”, and the text below reads “Update system security analysis”. A third leftward-pointing arrow connects “Detailed Design” to “Unit testing”. The text above this arrow reads “Revise the detailed design”, and the text below reads “Update subsystem security analysis”. Along the bottom of the diagram, two curved arrows arc from left to right. These arrows originate near “Detailed Design” and “Software and hardware security requirements” on the left side and curve upward toward “Unit testing” and “Hardware and software security verification and validation” on the right side, indicating iterative feedback between design and verification stages.Automotive industry standard V model development process. Source: Cuenot et al. (2014)
3. Research on the integration of MBSE and system safety analysis
In the early phases of systems engineering development, both researchers and industry focused on merging safety, structural and behavioural models into a single framework that would allow safety and performance to be analysed together, with the goal of improving analytical accuracy and efficiency. At that time, however, modelling technology was immature: no universally accepted modelling language existed, and modelling methods lacked standardisation. Consequently, the field splintered into several strands that relied on incompatible functional models, most of which lay outside mainstream design practice, thereby limiting the wider adoption of model-based safety analysis.
MBSE provides the technical scaffolding needed to embed safety and reliability analyses into every phase of system development. By prescribing clear objectives and well-defined inputs/outputs for each stage, MBSE turns safety work from an ad-hoc add-on into a systematic, goal-oriented activity. Equally important, MBSE delivers a single, authoritative digital model that serves as the sole data source for all downstream analyses. This eliminates the heterogeneous and often inconsistent functional models that historically plagued safety studies, guaranteeing that safety analysts and performance designers operate on identical, fully synchronised data. The resulting homogeneity at the data level is a prerequisite for rigorous, repeatable and traceable model-based safety analysis.
In this research direction the dominant approach is to follow the MBSE design flow and use model integration and/or mapping to achieve joint development of system function and safety.
The French PRISME laboratory proposed MeDISIS (David, Idasiak, & Kratz, 2010), a reliability and safety analysis process aligned with mainstream MBSE. In the requirements stage, preliminary hazard analysis defines functional failure states; during functional analysis, functional FMEA derives additional design requirements; in the design-integration stage, component FMEA, performance-reliability analysis and fault-injection verification are performed to evaluate and refine the architecture.
Mhenni presented SafeSysE, an MBSE-integrated safety method (Mhenni, Choley, Nguyen, & Frazza, 2016). In requirements analysis a top-level function list is established and subjected to functional-risk analysis; in functional design functional FMEA is executed to identify critical functional failures and to formulate safety-derived requirements; in architecture design preliminary component FMEA is carried out to verify whether the architecture controls functional faults and to optimise the design (Figure 5).
The flow diagram is divided vertically into two main sections by a solid vertical line. The left section is titled “System engineering procedure” at the top, and the right section is titled “Safety analysis program”. System engineering procedure section: At the top left corner, a diamond-shaped symbol is shown. Adjacent to this arrow, a filled circular dot appears, labeled “Initial requirements”. Below the “Initial requirements” label, a rounded rectangular box is labeled “Requirement Definition and Analysis”. From the diamond and Initial requirements, a dashed arrow points downward to a box “Requirement Definition and Analysis”. To the right of “Requirement Definition and Analysis”, a rectangular blue box labeled “Data storage” contains the following stacked text: Requirement Diagram, B D D environment, System (operating mode), Use case diagram, and Sequence Diagram. A right-pointing arrow connects “Requirement Definition and Analysis” to this data storage box. Below “Requirement Definition and Analysis”, a dashed downward arrow leads to a rounded rectangular blue box labeled “Functional architecture definition”. To the right of this box, another rectangular “Data storage” box contains: Requirement Diagram, B D D (Layered Functionality), and Demand update. A right-pointing arrow connects “Functional architecture definition” to this data storage box. A dashed horizontal arrow from “Functional architecture definition” extends across the diagram, crossing the vertical divider into the safety analysis program section. Below “Functional architecture definition”, a dashed downward arrow leads to a rounded rectangular blue box labeled “Logical architecture definition”. To the right of this box, a rectangular blue “Data storage” box contains: The composition of B D D logic, I B D logical architecture, and Configuration. A right-pointing arrow connects “Logical architecture definition” to this data storage box. Another dashed horizontal arrow from “Logical architecture definition” extends across the diagram at this level, again extending into the safety analysis program section. Below “Logical architecture definition”, a dashed downward arrow leads to a rounded rectangular blue box labeled “Physical architecture definition”. No data storage box is shown to the right of this box. Dashed arrows from the diamond shape also point downward to “Functional architecture definition” and “Logical architecture definition”. Safety analysis program section (right side) On the right side of the vertical divider, three rounded rectangular green boxes are arranged vertically, forming the safety analysis workflow. At the top right, a rounded rectangular box is labeled “Functional risk assessment”. A dashed arrow extends upward from this box to the diamond shape in the system engineering procedure. To the right of “Functional risk assessment”, a rectangular box labeled “Data storage” contains: Function F M E A and Derived security requirements. A right-pointing arrow connects “Functional risk assessment” to this data storage box. Below “Functional risk assessment”, another rounded rectangular box is labeled “Establishment of Layer Risk Assessment”. To the right of this box, a rectangular blue “Data storage” box contains: Initial and Component F M E A. A right-pointing arrow connects “Establishment of Layer Risk Assessment” to this data storage box. Below this, a third rounded rectangular box is labeled “Fault Propagation and Reliability Assessment”. This box is connected upward and downward by arrows within the safety analysis flow. Below “Fault Propagation and Reliability Assessment”, a rectangular box labeled “Fault storage” contains the text: Fault tree. A downward arrow connects “Fault Propagation and Reliability Assessment” to this fault storage box. A dashed arrow downward arrow from “Establishment of Layer Risk Assessment” points to a diamond shape. The box “Fault Propagation and Reliability Assessment” connects upward to the diamond shape. A dashed line extends from this diamond shape, runs horizontally to the left, and turns vertically upward to the diamond shape in the system engineering procedure. AN arrow from “Initial Component F M E A” points to “Fault Propagation and Reliability Assessment”. Upward arrows labeled “System requirements” from Functional risk assessment“ and ”Establishment of Layer Risk Assessment“ point upward to a horizontal connector. From the connector, an arrow labeled ”Safety Ret“ points to ”Requirement Definition and Analysis“ in the system engineering procedure. An arrow from ”The composition of B B D logic“ in the system engineering procedure points to ”Fault Propagation and Reliability Assessment“ in safety analysis program.Integration process of SafeSysE. Source: Mhenni et al. (2016)
The flow diagram is divided vertically into two main sections by a solid vertical line. The left section is titled “System engineering procedure” at the top, and the right section is titled “Safety analysis program”. System engineering procedure section: At the top left corner, a diamond-shaped symbol is shown. Adjacent to this arrow, a filled circular dot appears, labeled “Initial requirements”. Below the “Initial requirements” label, a rounded rectangular box is labeled “Requirement Definition and Analysis”. From the diamond and Initial requirements, a dashed arrow points downward to a box “Requirement Definition and Analysis”. To the right of “Requirement Definition and Analysis”, a rectangular blue box labeled “Data storage” contains the following stacked text: Requirement Diagram, B D D environment, System (operating mode), Use case diagram, and Sequence Diagram. A right-pointing arrow connects “Requirement Definition and Analysis” to this data storage box. Below “Requirement Definition and Analysis”, a dashed downward arrow leads to a rounded rectangular blue box labeled “Functional architecture definition”. To the right of this box, another rectangular “Data storage” box contains: Requirement Diagram, B D D (Layered Functionality), and Demand update. A right-pointing arrow connects “Functional architecture definition” to this data storage box. A dashed horizontal arrow from “Functional architecture definition” extends across the diagram, crossing the vertical divider into the safety analysis program section. Below “Functional architecture definition”, a dashed downward arrow leads to a rounded rectangular blue box labeled “Logical architecture definition”. To the right of this box, a rectangular blue “Data storage” box contains: The composition of B D D logic, I B D logical architecture, and Configuration. A right-pointing arrow connects “Logical architecture definition” to this data storage box. Another dashed horizontal arrow from “Logical architecture definition” extends across the diagram at this level, again extending into the safety analysis program section. Below “Logical architecture definition”, a dashed downward arrow leads to a rounded rectangular blue box labeled “Physical architecture definition”. No data storage box is shown to the right of this box. Dashed arrows from the diamond shape also point downward to “Functional architecture definition” and “Logical architecture definition”. Safety analysis program section (right side) On the right side of the vertical divider, three rounded rectangular green boxes are arranged vertically, forming the safety analysis workflow. At the top right, a rounded rectangular box is labeled “Functional risk assessment”. A dashed arrow extends upward from this box to the diamond shape in the system engineering procedure. To the right of “Functional risk assessment”, a rectangular box labeled “Data storage” contains: Function F M E A and Derived security requirements. A right-pointing arrow connects “Functional risk assessment” to this data storage box. Below “Functional risk assessment”, another rounded rectangular box is labeled “Establishment of Layer Risk Assessment”. To the right of this box, a rectangular blue “Data storage” box contains: Initial and Component F M E A. A right-pointing arrow connects “Establishment of Layer Risk Assessment” to this data storage box. Below this, a third rounded rectangular box is labeled “Fault Propagation and Reliability Assessment”. This box is connected upward and downward by arrows within the safety analysis flow. Below “Fault Propagation and Reliability Assessment”, a rectangular box labeled “Fault storage” contains the text: Fault tree. A downward arrow connects “Fault Propagation and Reliability Assessment” to this fault storage box. A dashed arrow downward arrow from “Establishment of Layer Risk Assessment” points to a diamond shape. The box “Fault Propagation and Reliability Assessment” connects upward to the diamond shape. A dashed line extends from this diamond shape, runs horizontally to the left, and turns vertically upward to the diamond shape in the system engineering procedure. AN arrow from “Initial Component F M E A” points to “Fault Propagation and Reliability Assessment”. Upward arrows labeled “System requirements” from Functional risk assessment“ and ”Establishment of Layer Risk Assessment“ point upward to a horizontal connector. From the connector, an arrow labeled ”Safety Ret“ points to ”Requirement Definition and Analysis“ in the system engineering procedure. An arrow from ”The composition of B B D logic“ in the system engineering procedure points to ”Fault Propagation and Reliability Assessment“ in safety analysis program.Integration process of SafeSysE. Source: Mhenni et al. (2016)
The DEIS group at the University of Calabria proposed RAMSAS (Alfredo & Andrea, 2012), a four-step reliability, availability, maintainability and safety analysis and simulation method (requirements analysis → system modelling → system simulation → system evaluation) that is iterated throughout the design process; the method is simulation-centred and does not include early-architecture reliability analysis.
Xie developed an MBSE-centric reliability and safety design and analysis process that links the equipment design model and the reliability/safety model bidirectionally, enabling concurrent design and reliability and/or safety work (Xie et al., 2025). Wang, Qin, and Liu (2024) addressed the all-electronic safety system of torpedoes. Building on conventional safety and reliability analysis, they developed a safety system modelling procedure grounded in systems engineering. Functional requirements, system architecture, activity views and temporal-logic control were adopted as the constituent elements for safety and operational-reliability analysis, and fault propagation was modelled within the system functional model (Wang et al., 2024). Qi, Jin, Peng, Zhang, and Cai (2024), adopting a model-based systems engineering perspective, proposed a method that identifies potential faults concurrently along three dimensions – function, performance and structure – during the forward-design and modelling phases of complex systems (Qi et al., 2024).
Overall, the main idea of integrating MBSE and system safety analysis in the design process is as follows: during the system requirements analysis phase, the system function list and usage requirements in the MBSE model are used to conduct preliminary functional failure analysis and hazard analysis, refining safety requirements; in the system function analysis and logical architecture design phase, a comprehensive analysis model is built on the basis of the system normal function model with the support of the fault mode database, focusing on architecture improvement; after the system physical architecture design is completed, dynamic simulation evaluation of the system normal and fault behaviours is carried out, further optimising the fault control logic and algorithms of the system.
4. Research on safety analysis technology of railway systems based on MBSE
4.1 Integrated key technologies for safety analysis method of railway system based on MBSE
MBSE leverages standardised modelling languages such as systems modelling language (SysML) to create a coherent, lifecycle-wide system model. By unifying requirements elicitation, architectural design, integration verification and operational optimisation within a single normative framework, MBSE eliminates the model heterogeneity, data silos and process discontinuities that plague conventional railway safety analyses. Consequently, it offers a rigorous foundation for standardised, efficient and demonstrably accurate safety assessment of railway systems.
Automatic mapping of the architecture model to FTA
The fidelity of any fault tree analysis (FTA) is governed by the rigour with which system constituents and their interactions are encoded. In MBSE practice the block-definition diagram (BDD – a SysML artefact – serves as the canonical repository of this information. A single BDD captures the complete decomposition of the railway asset from top-level function to lowest replaceable unit, prescribes the interfaces between siblings and explicitly traces data and energy flows. The train braking system illustrates the principle: the BDD simultaneously declares the brake controller (brake-demand computation), the hydraulic actuator (pressure modulation) and the speed sensor (velocity feedback), while binding each element to its functional boundary, failure-relevant attributes and peer connectors. Such a structured, semantically rich description guarantees that the subsequent FTA is both complete and traceable to the system architecture.
By exploiting the automation capabilities of MBSE environments such as IBM Rhapsody, the system architecture model can be translated into a fault tree without human intervention. Model-transformation rules that map SysML to analysable languages (e.g. AltaRica 3.0) automatically generate the fault tree, eliminating the transcription errors inherent in manual construction. Because the same SysML source is reused, the functional definitions and component interactions captured during architecture design remain traceably consistent with the failure logic and event couplings elaborated in the subsequent safety analysis. This end-to-end consistency provides the rigorous, repeatable foundation required for standardised and efficient safety assessment of railway signalling systems.
Dynamic linkage between the behaviour model and FMEA
Fault mode and effects analysis (FMEA) is a widely adopted method for safety verification in railway systems. Its primary objective is to systematically identify potential functional failure modes throughout the system's life cycle, analyse the root causes of these failures and quantitatively assess their impacts on system functionality, the operating environment and personnel safety. The accuracy of this analysis largely depends on a clear representation of the system's dynamic behavioural logic. Within MBSE, the state machine diagram and activity diagram of the SysML offer standardised modelling frameworks. Specifically, the SysML state machine diagram can accurately describe the behavioural patterns and state transition conditions of a system or subsystem under various operating scenarios through discrete states and transitions. Meanwhile, the activity diagram visually illustrates the execution steps, resource dependencies and parallel or branching logic of system functions using process nodes and control flows. Together, these diagrams provide a comprehensive technical framework for modelling the dynamic behaviour of railway systems.
Focusing on the train dispatching system as a critical subsystem, its SysML State Machine model defines typical operational states – such as “normal dispatching,” “temporary speed restriction,” “fault downgrade” and “emergency takeover” – centred on the core dispatching functions and explicitly specifies the triggering conditions for transitions between these states. By extending the SysML profile, the behavioural model can be associated with failure modes, enabling the automatic generation of FMEA tables that include fields such as failure mode, cause and impact level (S/O/D). Through bidirectional “requirement–model” traceability, consistency between FMEA results and system implementation can be ensured. This traceability mechanism not only guarantees that the FMEA analysis covers all key functions and requirements but also establishes a dynamic link between FMEA outcomes and system design. When the behavioural model is modified due to requirement changes, the FMEA table can be automatically updated via tools, effectively avoiding the issues of information lag and inconsistency associated with traditional manual FMEA maintenance, thereby supporting the dynamic and accurate analysis of failures in railway systems.
Multi-model collaboration and dynamic update
Complex railway systems exhibit deep hierarchical structures, tight functional coupling and highly dynamic operating contexts. A single safety analysis technique is therefore no longer capable of covering every risk dimension. A coherent combination of FTA, FMEA and hazard and operability analysis (HAZOP) is required to obtain mutually complementary coverage. MBSE eliminates the “information islands” generated by these stand-alone techniques by establishing a single, living model repository under a dynamic update regime. The repository enables concurrent model interaction and guarantees consistency across the entire life cycle, thereby supplying an integrated, model-driven backbone for the safety analysis of complex railway systems.
The unified model library acts as the core data carrier for multi-model collaboration; its value lies in standardised storage and cross-project reuse of safety analysis resources. The library contains common basic data modules for railway systems – typical failure-mode libraries for key train components (wheelsets, braking systems and traction inverters) and generic safety design templates – and a rule library for safety analysis methods, including the mapping between fault tree basic events and FMEA failure modes and the correspondence between HAZOP deviation scenarios and system behaviour model states. This structured approach allows project teams to retrieve standardised resources directly, eliminating repeated construction of basic models, reducing modelling cost and ensuring consistent safety analysis standards across projects.
The dynamic update mechanism is essential for ensuring the synchronised evolution of multiple models and system design. Its primary function is to enable the MBSE tool to trace inter-model relationships and automatically identify the scope of safety analysis models affected by design changes. Specifically, based on a predefined change impact analysis algorithm, the tool traverses nodes in the system architecture and behavioural models that depend on the modified elements, thereby locating affected fault tree branches in FTA, failure mode items in FMEA and deviation scenarios in HAZOP. For instance, when redundant communication channels are added to a train system, the tool identifies this design change and automatically introduces a new basic event branch in the FTA, representing “simultaneous failure of redundant communication channels.” It then updates the top event's failure probability based on the reliability parameters of the new channels. Simultaneously, in the FMEA, it incorporates “redundant channel switching delay” as a new failure mode, includes its impact on train operation safety and recalculates the corresponding risk priority number. This entire update process eliminates the need for manual inspection of individual models. It significantly shortens the safety analysis iteration cycle following design changes and reduces the risk of overlooking affected models, thereby ensuring dynamic consistency between system design and safety analysis. This capability effectively addresses the safety analysis challenges posed by frequent design iterations throughout the lifecycle of complex railway systems.
In addition, a dual-layer structure comprising a “core traceability chain” and an “associated traceability chain” is established. The core chain addresses safety-critical requirements – such as train braking and signal control – and enforces rigid, lifecycle-long traceability. The associated chain accommodates non-safety-critical functional extensions; it adopts a “requirement–module–verification result” pattern that shortens the traceability path by omitting redundant intermediate nodes. For example, when a train dispatching system is augmented with a non-safety-related data-statistics function, only the direct links among the functional requirement, its implementation module, and the corresponding test case are recorded; traceability to low-level hardware components is not required.
Concurrently, an automatic mapping rule base for traceability relations is defined by extending the SysML meta-model. Whenever requirements evolve, a plug-in developed for the MBSE platform (e.g. IBM Rhapsody) automatically identifies the scope of change: for functional-expansion requirements, new traceability links are created; for performance-optimisation requirements, the traceability attributes of the affected model nodes are updated and invalid links are removed. Version control and differencing capabilities are integrated to capture the change history of every traceability relation and to enable one-click rollback, thereby significantly reducing manual-maintenance overhead.
4.2 Key technologies for safety analysis of railway systems based on MBSE
MBSE transforms the traditional document-driven approach into a model-driven one by employing models as the primary means of information exchange and system specification throughout the system lifecycle. It supports functional analysis during the early stages of railway system design, facilitating the identification of potential issues and bottlenecks. Early detection helps minimise late-stage design changes. Additionally, simulation enables the evaluation of various operational scenarios and failure conditions, contributing to the verification that the system meets its safety objectives. The MBSE-based railway system safety analysis method integrates key technologies across three main areas: requirements analysis, comprehensive modelling and simulation-based verification.
Safety requirement analysis driven by railway operational tasks
In railway safety analysis, task-oriented safety requirement analysis is essential to guarantee that both design and operation satisfy the specific demands of each operational task. Its primary objective is to create an accurate functional profile that maps system functions to railway operational tasks. In conventional design, the coarse granularity of task descriptions usually prevents such a mapping from being established with sufficient precision. MBSE overcomes this limitation by employing operational-view and functional-view models that tightly couple usage requirements with system requirements. The task-scenario model and the top-level functional model generated by MBSE are combined to produce a task-to-function mapping table. Building on this table, a functional failure analysis model is constructed to decompose high-level safety requirements down to individual system functions.
Integrated safety–function design analysis
The objective is to derive a comprehensive failure propagation model that captures how faults originating in any constituent subsystem or component propagate through the railway system and degrade overall performance. Because railway systems are highly interconnected, a local fault can escalate to system-level failure; quantifying these propagation paths is, therefore, central to safety analysis.
Using MBSE, we embed component failure modes directly into the system functional model, quantify their effects on each output and link these local failure data into a unified model that couples function design with safety analysis. The resulting model automatically yields the fault-logic structure of the railway system and supports subsequent safety assessment.
Model construction proceeds in four steps.
Baseline functional model extraction. Core MBSE artefacts – functional operations, functional timing and system composition – are extracted and organised into a hierarchical, nominal-function model.
Local failure-logic definition. For each unit, the local input–output failure relation, internal state transition function, temporal and logical fault dependencies and any functional reconfiguration behaviour are formally specified.
System-level failure model integration and validation. Local failure-logic blocks are composed into the global failure propagation model, which is then verified for completeness and consistency against the baseline functional model.
Automatic generation of fault-logic structures. Causal relationships encoded in the integrated model are exported as fault trees, Bayesian networks or FMEA/FMECA tables, enabling exhaustive analysis of single and combined failure scenarios.
- (3)
Simulation-based safety verification via train-fleet operation modelling
Safety verification by simulation faces several practical challenges: accurate modelling of complex systems, management of large data volumes, assurance of environmental fidelity, model V&V, integration of multi-disciplinary knowledge, interpretation of results, selection or development of suitable tools, efficient allocation of computational resources and demonstration of result reliability.
To address these issues, we propose a train-fleet operation simulation method for railway system safety verification. An MBSE-compliant model of the railway system – incorporating track topology, stations, signalling, rolling stock and supporting infrastructure – is first constructed so that its behaviour and performance match those of the real system. A simulation platform is then selected or developed to reproduce fleet operation under representative, abnormal and emergency conditions.
Hazardous events and accident scenarios are injected into the runs to observe system response, quantify accident likelihood and evaluate consequence severity. Simulation outputs are compared with theoretical predictions and field data to identify weak points and to prioritise design or operational improvements. Iterative V&V ensures that the model remains valid while the safety level of the railway system is progressively enhanced.
5. Conclusion
Increasing complexity and tighter integration in railways raise both the difficulty of safety analysis and the required safety level. To meet these challenges, we propose an MBSE-based railway safety analysis technique that employs systems engineering practices: safety requirements are decomposed and allocated through models that originate in the system requirement set, and both analytical calculations and simulation-based verification are performed. This approach provides end-to-end technical support for the safety design and analysis of railway systems. Future work should therefore concentrate on railway system requirements and design models, deepen the investigation of safety design procedures and methods within the MBSE framework and advance intelligent modelling techniques for railway safety, thereby ensuring safe and reliable operation and improving overall railway safety performance.

