On Some Aspects of Distributed Control Logic in Intelligent Railways

Abstract

A comfortable, reliable, safe and environmentally friendly high-speed train journey that saves time and offers an unforgettable experience for passengers is not a dream. Passengers can enjoy panoramic views, delicious cuisine and use their mobile devices without restrictions. High-speed trains, powered by environmentally friendly methods, are a sustainable form of transport, reducing harmful emissions. Integrating intelligent control and management into railway networks has the capacity to increase efficiency and improve reliability and safety, as well as reduce development and maintenance costs. Future intelligent railway network architectures are expected to focus on integrated, multi-layered systems that deeply embed artificial intelligence (AI), the Internet of Things (IoT) and advanced communication technologies (5G/6G) to ensure intelligent operation, improved reliability and increased safety. Distributed intelligent control in railways refers to an advanced approach in which decision-making capabilities are distributed across network components (trains, stations, track sections, control centers) rather than being concentrated in a single central location. The recent advances in AI in railways are associated with numerous scientific papers that enable intelligent traffic management, automatic train control, and predictive maintenance, with each of the proposed intelligent solutions being evaluated in terms of key performance indicators such as latency, reliability, and accuracy. This study focuses on how different intelligent solutions in railways can be implemented in network components based on the requirements for real-time control, near-real-time control, and non-real-time operation. The analysis of related works is focused on the proposed intelligent railway frameworks and architectures. The description of typical use cases for implementing intelligent control aims to summarize latency requirements and the possible distribution of control logic between network components, taking into account time constraints. The considered use case of automatic train protection aims to evaluate the added latency of communication. The requirements for the nodes that host and execute the control logic are identified.

1. Introduction

The development of rail transport is linked to increased speeds, autonomous and digitalized trains and improved sustainability through the promotion of green energy sources. The aim is to create a more competitive and attractive alternative mode of transport for both passengers and freight.

From a passenger perspective, high-speed rail travel saves time waiting at the airport and offers enjoyable, relaxing or productive experiences during the journey. Spacious carriages provide more opportunities for walking during the journey, enjoying nature, working on laptops, reading, watching video on demand or even shopping online. The provision of real-time information on train schedules and improved punctuality and reduced train cancelations build passenger confidence. Improved rail infrastructure conditions and a sense of safety on-board, platforms and stations reinforce passengers’ belief that rail is the most reliable and safe mode of transport.

Rail operators benefit from cost-effectiveness, high load capacity, reduced fuel costs, more reliable and scalable scheduled operations, and less congestion. As the most environmentally friendly form of transport, it contributes to reducing greenhouse gas emissions and road wear due to low friction between the rails and wheels [1].

In recent years, significant advances in key Industry 4.0 technologies have revolutionized rail transport and revealed its advantages over other modes of transport. Digitalization and artificial intelligence (AI) enable predictive maintenance, intelligent systems, improved passenger experience and cybersecurity. The Internet of Things (IoT) and AI enable the collection and analysis of sensor data to prevent failures and thus improve reliability and costs [2,3,4,5,6,7,8]. Real-time monitoring of train positions and track conditions addresses potential hazards and can prevent collisions, thereby improving safety. Data collection and processing in train systems helps drive data-driven decision-making to make more informed decisions about performance trends [9,10,11,12,13,14,15]. Smart ticketing, real-time information, on-board services, virtual assistants and personalized journey planning are just some of the improvements for passengers [16,17,18,19,20,21]. Digitalization makes railway systems more connected and thus exposed to threats, which is a challenge for protecting railway operations and passenger safety, and AI can become a powerful assistant against attackers [22,23,24,25,26,27].

According to the European Rail 2050 vision, the intellectualization of railway transport began with its digitalization [28]. Digitalization transforms railway assets into digital resources capable of sensing, detecting, processing, receiving, transmitting and analyzing digital information over secure, reliable and ubiquitous networks. With distributed cognitive computing, railway systems will be able to be aware of and understand their environment, recognize patterns, generate valuable information from large amounts of distributed data and learn. The goal of Intelligent Railway 2.0 is to create safer, more efficient and more comfortable railway transport [29]. Railway systems will incorporate self-perception, self-learning, self-decision-making and self-control to sense their environment, analyze data to train models, make decisions autonomously and control their operations without human intervention [30,31,32]. Key capabilities include automated control, predictive maintenance, real-time obstacle detection and smart ticketing and passenger access to real-time information. The focus is on increasing safety and operational efficiency to minimize incidents and operational disruptions by implementing proactive measures and real-time monitoring, as well as more optimized operations. The European Union’s 2050 vision for rail transport recognizes the need for rail to be adaptable and able to accommodate future technological advances [28]. Key technologies from the transition from Intelligent Railway 1.0 to Intelligent Railways 2.0 include AI and Machine Learning (ML), the Internet of Things (IoT), big data, communications and automation.

AI and ML enable the railway system to actively learn and adapt, to make proactive rather than preemptive decisions, and to implement a proactive approach to safety to detect potential risks and avoid them. IoT can enable ubiquitous interconnection of trains, tracks, signals and stations to ensure seamless data sharing between rolling stock, infrastructure and control centers. By analyzing vast amounts of data from sensors, tracking systems and operational logs, railways can predict maintenance needs, optimize operational strategies for different trains and services and improve safety by monitoring performance trends. Future railway communications are centered on FRMCS (Future Railway Mobile Communication System), a new global standard based on 5G that will replace the aging GSM-R. FRMCS is the foundation for Intelligent Railway 2.0 because it provides higher bandwidth, low latency, and ultra-reliable connectivity for a wide range of applications [33].

Automation refers to a fully digitalized railway ecosystem—including rolling stock, infrastructure and control systems—and is networked within the IoT framework. Each component has built-in artificial intelligence, giving it the autonomy to efficiently perform targeted tasks. Smart, self-adjusting trains communicate with each other and with smart infrastructure, ensuring safe, high-capacity operations while minimizing train distances and reducing long-term costs. This evolution is in line with next-generation traffic management systems, such as the European Railway Traffic Management System (ERTMS) and Communication-Based Train Control (CBTC). Decentralized autonomous train operations dynamically adapt to transport demand, increasing capacity and flexibility in urban, high-speed, freight, rural and mass transport networks. Fully automated trains, AI-driven vehicles and remotely controlled systems provide unparalleled safety. Furthermore, autonomous operations unlock innovative mobility solutions, such as self-driving light modules or shuttles, enabling seamless connectivity across diverse rail infrastructure [34,35,36,37].

Smart railway architectures are multi-layered systems that integrate various technologies such as the Internet of Things (IoT), artificial intelligence (AI), cloud computing, and advanced networks to enable intelligent operations, management, and maintenance. Key components include a physical layer with smart trains and infrastructure, an information integration platform for data fusion, and intelligent decision-making layers that support functions such as autonomous driving, predictive maintenance, and real-time traffic management.

The physical layer includes the physical assets of the railway system, such as smart trains, smart lines (rails), smart stations and distribution platforms, as well as smart security systems. Information integration platforms are the core layer that collects and integrates data from the physical layer to support higher-level functions. This layer includes ubiquitous perception and sensor networks, cloud and edge computing for data processing, and advanced communication networks, potentially using 6G for high-speed, low-latency and secure data transmission. The highest intelligent decision-making layer uses data from the integration platform to enable intelligent functions, such as the optimization of train schedules and routes, intelligent passenger services, predictive and preventive maintenance, and intelligent lifecycle management of railway assets.

Distributed intelligent control in railway transport aims to overcome the limitations of traditional centralized traffic management systems, such as scalability and real-time processing limitations in large, high-density networks. The aim of this study is to define the criteria for distributing intelligent logic for railway operations management among railway network components. The analysis of different use cases allows us to summarize the latency injected by different intelligent solutions proposed and evaluated in existing related works and to illustrate the role of different railway network components in terms of real-time, near-real-time and non-real-time control. The delay introduced by communication in the case of near-real-time and non-real-time operation is important to consider in FRMCS-based automatic train control. As the FRMCS standards are still under development, the presented example of a critical communication application illustrates a method for defining reusable functionality and evaluating the introduced delay. The use cases considered are the basis on which the requirements for distributing intelligent control logic across network components are identified.

The paper is structured as follows. Section 2 first reviews the literature on intelligent railway platforms and architectures, then defines and summarizes typical use cases for intelligent control in railway transport and their time constraints. Section 3 first analyzes aspects of the distribution of control logic between components of an intelligent railway architecture in terms of real-time, near-real-time and non-real-time requirements and then provides an example of a critical communication application of FRMCS related to automated train protection to evaluate the communication delay. Section 4 highlights the benefits of the proposed architecture and identifies the requirements for the logic functions as well as the interfaces between them. The conclusion summarizes the contributions and their significance. The list of abbreviations is provided at the end of the paper, just before the list of references.

2. Materials and Methods

2.1. Related Works

Intelligent railway frameworks often combine hierarchical, systems- and data-centric approaches, using self-organizing methods to achieve autonomy. Architectures are structured to manage complex cyber–physical systems and typically include technical, standard and system data frameworks to guide implementation from construction to intelligent operation. A key trend is the use of microservices for modularity and flexibility in areas such as control and management of artificial intelligence models.

Recent developments in intelligent railways include a delay-aware traffic management framework [38,39], a multi-objective optimization framework for efficiency and safety [40], a human-centered approach for assessing energy technologies for railways [41], and a deep reinforcement learning framework for speed control to reduce vibration [42]. Other research papers propose decision-making models for intelligent transport system selection [43,44] and frameworks for active safety systems and rail degradation prediction [45,46].

In [38], a railway traffic management system for high-speed trains is proposed, which can be used in emergency situations to reschedule schedules. The system is composed of modules that reflect risk event scenarios, predict delay times, generate rescheduling schemes, and evaluate strategic systems. Metaheuristic algorithms and deep reinforcement learning are used to predict delays and generate rescheduling schedules. In [39], a railway traffic management framework that takes into account both passenger and train delays is presented. The framework includes a demand forecasting module, a passenger demand allocation module, and a traffic management module for predictive optimization. In [40], a multi-objective optimization framework for resource management is investigated. Based on sensor data, the framework uses predictive models to flexibly allocate control resources, such as signal phase splitting, variable speed limits, ramp measurement speeds, and route guidance incentives. In [41], a new integrated, human-centric framework for energy management in railway transport is proposed. The framework integrates innovative technological capabilities and human factors related to behavioral responses. The authors use Long Short-Term Memory models to predict the trajectories of technical developments and their social consequences, based on both innovation patterns and deployment potential. In [42], a framework for pantograph-friendly automatic speed control of urban rail trains based on deep reinforcement learning is proposed. The authors use deep reinforcement learning to reduce the impact of vertical vibrations on the rigid contact pantograph and to learn driving strategies based on the condition, safety, and comfort of the pantograph. In [43], the authors present an intuitive fuzzy set model to derive criteria for assessing the safety and reliability of intelligent railway systems and propose a new decision-making model that takes into account the requirements. A robust decision-making framework that can be used to assess the development of railway transport is presented in [44]. The authors identify 15 indicators weighted using the fuzzy best–worst method and propose a stochastic approach that takes into account uncertainty in project evaluation. The frameworks for active safety systems and rail degradation prediction use a multi-step process including data input and pre-processing, vehicle and rail response modeling, surrogate modeling, and safety assessment to identify key inputs, predict future conditions, and optimize maintenance. These frameworks often incorporate advanced techniques such as physically informed artificial intelligence, probabilistic models, and statistical analysis to improve prediction accuracy and automate maintenance decisions, thereby increasing safety and operational efficiency [45]. A framework for improving rail geometry deterioration analyses that can be used for railway asset management is presented in [46].

Research on intelligent rail architectures focuses on integrating advanced technologies such as artificial intelligence, the Internet of Things and 5G to create more efficient, safe and autonomous systems. Key areas of development include building comprehensive system frameworks, creating unified standards for technologies such as digital twins and using artificial intelligence for predictive maintenance, traffic management and energy optimization. Other important areas are the development of 5G-based communication systems for real-time monitoring and the creation of data-driven platforms for analysis and decision-making.

Recent developments in hybrid cloud–edge architectures for intelligent railways focus on combining edge computing for real-time, latency-sensitive tasks with cloud computing for heavy processing and storage [47]. This hybrid model addresses challenges such as the huge data volumes in intelligent dispatching, sensor data for condition monitoring, and predictive maintenance by offloading tasks based on their needs. Studies have explored architectures that use edge nodes for local processing and data filtering, while the cloud handles complex, offline computations such as machine learning model training and long-term analysis. A novel hybrid cloud–edge intelligent system suitable for complex application scenarios combined with efficient and intelligent scheduling strategies is presented in [48]. The authors apply a deep reinforcement learning approach to the task scheduling system to reduce the total time required to complete a task. In [49], the authors first discuss the basic concept of the collaborative “cloud-side” architecture, which integrates cloud computing, edge computing, and terminal devices to achieve more efficient data processing and analysis, and then discuss in detail the application areas of the collaborative “cloud-side” architecture in the power system.

Key architectures for smart railways include multi-layered logical and physical structures for data processing and management, such as a multi-layered framework with physical, perceptual, and analytical layers for system functions. In [50], the authors propose a logical multi-level hierarchical framework for smart railways 2.0. The framework includes both central and peripheral computing and manages the complexity of smart dispatching by dividing tasks between different layers. The physical layer covers the physical infrastructure and sensors, the state perception layer collects real-time data from sensors, the information fusion layer combines and processes data from multiple sources, the intelligent analysis layer uses artificial intelligence and algorithms to analyze the fused information, the business optimization layer uses insights from the analytical layer to improve operations, and the joint services layer manages the interaction and services in the network. The authors also present an active safety system with a hierarchical structure that addresses the challenges of railway safety. Another important architecture includes the concept of a digital twin, which creates a virtual replica of the railway to aid in design, operation, and maintenance [51,52,53,54]. These architectures are evolving from discrete subsystems to creating holistic, large-scale platforms that enable communication and synchronization across the entire railway network, including tracks, vehicles, and civil structures.

In our previous research, we proposed a holistic approach to designing an intelligent railway system [55,56,57]. The approach uses virtualization and software-defined networks to control and orchestrate all railway elements, including rolling stock and trackside equipment. The proposed cloud-based system architecture enables automation for better resource utilization. It separates the control logic into near-real-time functions embedded in the time-sensitive intelligent railway controller (TS-IRC) and non-real-time functions embedded in the time-tolerant intelligent railway controller (TS-IRC). The TS-IRC handles real-time control applications, such as train stopping and collision protection, while the TT-IRC handles non-real-time functions, such as policy guidance and AI/ML model workflow. The design of the intelligent railway system follows the principles of service-based architecture, where the functionality of the system is divided into a collection of small, independently deployable services. This offers greater modularity, scalability, and reusability, allowing different AI/ML applications to be developed and deployed independently.

Figure 1 shows the proposed high-level architecture of an intelligent railway control system.

There can be many management areas in a railway network, such as train management, track management, etc. The Railway Management Automation and Orchestration (RMAO) system acts as a centralized platform to manage, orchestrate and automate the entire lifecycle of the railway network. This includes provisioning, configuration and optimization to improve reliability and safety, reduce operating costs and improve network performance and passenger experience. TS-IRC handles safety-critical actions with millisecond-level response, preventing collisions. TT-IRC is part of the RMAO framework and uses predictive algorithms to optimize train speeds, train schedules and tracks, using historical data to minimize overall delay and improve energy efficiency.

In the proposed intelligent railway control architecture, the information exchange via the interface between TS-IRC and TT-IRC is based on REST (Representational State Transfer). This interface provides a policy management service, an information enrichment service and an ML model management service. TT-IRC defines policies that are provided to TS-IRC in order to guide the automated train towards the overall goal of safety and reliability. The enrichment information is provided in addition to the publicly available information that can be obtained from various sources (e.g., infrastructure status, route planning, logistics, etc.). It is provided by TT-IRC to TS-IRC to improve performance. The ML model management service manages the AI/ML workflow. Both TT-IRC and TS-IRC interact with trains and trackside signals to obtain performance data that provide information about the state of the railway network. Data communication between the TS-IRC application and on-board/trackside applications is based on the FRMCS standard. The Railway Cloud is a cloud computing platform composed of hardware and software that hosts and manages virtualized rail functions. It provides a flexible and shared infrastructure for deploying rail functions, enabling hardware/software separation and automation.

The main contributions of this study are as follows:

• Specification of potential use cases described at a very high level, focusing on how the proposed intelligent rail architecture enables the use, along with the main expectations for input data and resulting actions. The use cases are not related to specific AI/ML solutions that are already presented and evaluated in related scientific papers; rather, they summarize the role and time requirements of different components of the railway network in distributed intelligent control.
• Modeling a critical communication application for automatic train protection and estimating the injected latency from the RESTful interface. FRMCS-critical communication applications are needed when the intelligent control logic is deployed and executed centrally and instructions need to be sent to trains or infrastructure. The communication delay based on RESTful interfaces also needs to be taken into account, considering the distribution of the control logic.
• Architectural mapping of AI-/ML-assisted control functions onto real-time, near-real-time and non-real-time control loops. The study provides a general vision of how different AI/ML algorithms can be embedded in an intelligent railway architecture, without describing, evaluating and recommending any specific solutions (this is conducted in the relevant literature sources) that should be applied to the use cases.
• Identifying of criteria for determining deployment scenarios that decide whether a given ML application should be included in a real-time, near-real-time, or non-real-time control loop. Some criteria regarding the location of the ML training host and the location of the ML inference host are also discussed.
• Identifying of functional requirements to the railway nodes that host near real-time control and non-real-time operation.

2.2. Use Cases of Intelligent Railway Control

In this subsection, we provide a detailed description of some use cases related to Automatic Train Control (ATC). According to [58], ATC includes Automatic Train Protection (ATP) and Automatic Train Operation (ATO) applications.

ATP applications are crucial for railway safety. They continuously monitor the speed and position of the train, trackside signals and temporary speed restrictions, and based on the braking capacity, issue a Limit Movement Authorization (LMA) to the train. In addition to speed supervision, ATP applications ensure that safe distances between trains are maintained to avoid collisions, prevent a train from passing a signal that is set to “danger”, and help the driver mitigate the effects of human error [59].

ATO applications are responsible for automating train functions such as accelerating to the permitted speed, slowing down where necessary due to speed restrictions, and stopping at certain stations at the correct location, as well as opening and closing doors. ATO offers a number of advantages over traditional manual control, such as improved safety, increased capacity and accuracy, higher energy efficiency, and greater flexibility [60].

The provided use cases are an attempt to generalize existing intelligent solutions. The idea is not to describe and evaluate specific AI/ML algorithms, but to define the role of each network component in distributed intelligent control and to indicate typical time constraints requirements when performing the corresponding functions. Related works used to summarize the functionality of the use case and the time constraints are given at the end of the use case description.

2.2.1. Intelligent Negotiation in Multi-Train Conflict Points

Motivation

According to [28], traditional railway systems use fixed schedules and centralized control, causing:

• 15–30% delay during peak hours due to conservative safety margins.
• Manual intervention required for dynamic conflicts (e.g., train delays).
• Suboptimal resource utilization at junctions.
• Collision risk during unexpected events (e.g., signal failure).

For example, there may exist a conflict at junction “Point X” during track crossing. If the train A approaches the point X from the north (route: N→X) with a speed of 85 km/h and its current position is 5.2 km from X, and at the same time, the train B approaches the point X from the east (route: E→X) with a speed of 92 km/h and its current position is 3.8 km from X, then both trains will reach the point X within 42 s (train A in 28 s, train B in 24 s) at current speed.

Solution

To avoid conflict at the intersection, distributed control with real-time negotiation between participants can be implemented with a significant reduction in delay while maintaining safety.

Actors in conflict resolution are the train control systems, the trackside system, TS-IRC and TT-IRC. Trains report their location, speed, acceleration and safety status, execute commands and self-check. The trackside system sends information about the status of track segments, signal states, speed limits, updates the signal state and imposes physical restrictions. The TS-IRC is responsible for collision avoidance, emergency braking, and dynamic speed regulation. It uses information about the location, speeds, emergency state and safety zones of trains. Its main function is to make immediate decisions critical to safety (0–2 s reaction). The TT-IRC is responsible for route optimization, delay compensation and resource allocation. It uses information about train schedules, infrastructure constraints and historical data. Its main function is to optimally re-plan the schedule within 10 s to 10 min. An example of the conflict negotiation process is Figure 2.

The trains broadcast their speed/position. The infrastructure detects two trains entering Zone X (1 km from junction Point Y) via track sensors. Train A approaches from the north with a speed of 85 km/h and its current position is 5.2 km from Point Y. Train B approaches from the east with a speed of 92 km/h and it is 3.8 km away from Point Y. There exists a risk of conflict within 42 s when both trains will reach Point Y (Train A: 28 s, Train B: 24 s) at their current speeds. The TS-IRC calculates collision risk and sends an emergency STOP command to train B with higher priority due to the shorter distance. Train B executes the stop command, which is verified by the on-board system. The TT-IRC receives a conflict alert and calculates the optimal reschedule. The TT-IRC sends revised schedules to both trains. The infrastructure updates the signal status at Point Y to “STOP” for the train B. The TS-IRC monitors train B’s deceleration (confirms safe stop at 1.5 m/s²). The TT-IRC adjusts train A’s schedule to compensate for train B’s delay (no additional delay). Train A safely passes Point Y at 80 km/h. The infrastructure switches the signal to “GO” for the train B. The TS-IRC confirms conflict resolved.

Benefits of intelligent conflict resolution in railways

Intelligent conflict resolution in railway transportation can predict the conflict between multiple trains before it occurs, so as to re-plan schedules and prevent collisions. This leads to a 100% safety guarantee during conflicts, reduces delays compared to traditional systems, contributes to optimizing the use of junctions, and improves scalability as it has the capacity to handle multiple trains at complex junctions [61,62,63,64].

2.2.2. Intelligent Railway Route Optimization

Motivation

Traditional rail routing uses static tracks optimized for average conditions. A key component is the interlocking system, which ensures that signals and switches work together to prevent a train from being directed onto an already occupied track or into a conflict. Fixed routes are established for each train movement using a combination of signal and switch settings. At junctions, a single-track route may not be possible if different railways are involved. In such “inter-line” routes, junctions are used to transfer cars between different carriers, and traditional methods are used to control traffic through these critical transfer points. Routes are built around a pre-existing timetable that specifies when trains are scheduled to run and where they should go. According to [65], this leads to 32% higher energy consumption during peak demand, 27% longer travel times due to unoptimized path selection, failure to adapt to real-time disruptions (weather, congestion, faults), and suboptimal energy use from constant speed changes.

Solution

To optimize route plans, a distributed intelligent control could be applied where each actor handles specific decision layers based on latency requirements and data availability. The TS-IRC could be used for safety-critical micro-adjustments. The TT-IRC could perform prediction and strategic optimization.

Actors involved in intelligent railway route optimization are the train control system, trackside system, TS-IRC, and TT-IRC. The infrastructure is involved in track monitoring, which enables track fault detection of obstacles, signal management related to the control of signal states, and environmental sensing, including weather, temperature, snow. Trains are involved in data collection and command execution with latency between 10 and 50 ms. They ensure positioning tracking by means of GPS and inertial sensor data with accuracy ±5 m, energy monitoring by recording consumption per segment, and execution of a speed command issued by the TS-IRC. The TS-IRC is responsible for tactical execution within 50–200 ms including route enforcement, micro-adjustments (10–50 ms) for safety, and fail-safe monitoring that validates all decisions against safety rules. For real-time speed adjustment, the TS-IRC may use ML when the train approaches a slow zone to adjust speed. The input data for the optimal speed prediction include the current train speed, zone length, speed limit in the zone and energy constrained model. Based on the predicted optimal speed, the TS-IRC validates the decision against safety rules, sends a speed command to the train, and logs for TT-IRC retraining if the energy saving is bigger than 15%. The TT-IRC is responsible for strategic route planning within 5–10 s latency. It runs multi-objective optimization (energy, time, safety) using historical and predictive data, resolves conflicts by coordinating the routes of hundreds of trains across regional networks, and performs model training using the latest historical data. For daily optimization workflow, the TT-IRC uses historical rail data for the last few, e.g., three days, current conditions regarding weather and congestion data, ML model prediction with objectives related to energy consumption, safety and punctuality, and generates the optimized plan, including speed profiles with calculated energy profiles, and optimized plans for possible conflict alerts.

Figure 3 shows two use cases of intelligent route optimization—one for real-time speed adjustments and one for daily optimization workflow.

Benefits of applying distributed intelligent control

TT-IRC handles slow changes, while TS-IRC handles fast changes. TS-IRC validates TT-IRC decisions against safety rules and takes into account speed profiles optimized for energy efficiency, not just speed. Distributed intelligent control is scalable, as TT-IRC handles regional planning, while TS-IRC handles individual trains. Compared to traditional systems, distributed intelligent control contributes to energy consumption, minimizes conflict resolution, and allows for real-time adaptation [66,67,68,69].

2.2.3. Adaptive Train Control

Motivation

Traditional train control systems face a fundamental conflict with energy optimization and schedule adherence. On the one hand, the trains must maintain low speed to reduce energy consumption, and on the other hand, they have to maintain high speed to meet arrival times. This leads to suboptimal performance—either excessive energy use or missed schedules. Adaptive speed control could dynamically balance these objectives in real-time using AI-driven decision-making.

Solution

Solutions for energy-schedule conflicts in railways include integrating energy efficiency into scheduling models, using real-time rescheduling that considers speed profiles and buffer times, and implementing advanced algorithms that find conflict-free and energy-efficient paths. These solutions often involve adjusting train speed profiles, strategically placing buffer times, and rerouting or re-timing trains to minimize both delays and energy consumption simultaneously.

Actors involve the TS-IRC, TT-IRC and train control system. The TS-IRC executes speed control commands every 100 ms, processes real-time sensor data from trains and infrastructure, implements safety constraints (speed limits, distance to next train), and adjusts speed based on current conditions (weather, track curvature). It is also responsible for coordination with neighboring trains for safe spacing. The TS-IRC handles real-time execution because the speed control requires sub-100 ms response times to prevent collisions and maintain stability. The TT-IRC is responsible for AI model training using historical operational data and the optimization of long-term energyschedule tradeoffs. It generates model updates for TS-IRC (weekly), performs predictive analytics for route planning, and manages model retraining with new data. The train control system executes speed commands from the TS-IRC, measures actual speed and position, and sends real-time sensor data to the TS-IRC. It is responsible for monitoring the safety systems (emergency brakes) and for reporting anomalies to the TS-IRC. The TT-IRC processes operational data, retrains the ML model weekly and pushes a new model to the TS-IRC. The TS-IRC receives the train position at every 100 ms, calculates its optimal speed using the TT-IRC model and sends a command to train. The train executes the speed command, measures its actual speed and sends it to the TS-IRC. The TS-IRC continuously checks against safety constraints (speed limit, distance to the next train) and adjusts the command if needed. The TS-IRC sends the performance metric to the TT-IRC once a week, and the TT-IRC uses these metrics for the next model iteration.

Figure 4 shows the information flow and control logic distribution for intelligent train route optimization.

Benefits of adaptive speed control

The intelligent adaptive speed control architecture provides real-time performance, as TS-IRC only processes immediate needs within a 100 ms cycle. This allows for long-term optimization, as TT-IRC improves the model without disrupting operations. This type of speed control is scalable, as new trains can join the network without the need to retrain the entire system. Robustness is also ensured, as safety constraints are checked in each control loop [70,71,72].

2.2.4. Adaptive Track Scheduling

Motivation

Traditional railway scheduling uses fixed track allocations based on historical data. According to [65], this causes 58% of delays from track conflicts, 23% underutilization of track segments during off-peak hours, and 37% longer recovery times when disruptions occur.

Solution

Adaptive track scheduling could dynamically allocate track segments based on real-time conditions, predictive analytics, and collaborative decision-making between all system actors.

The actors are the TS-IRC, TT-IRC, infrastructure, station management system and the train control system. The TS-IRC manages the immediate track allocation within a response time of 0 to 60 s. It receives data from the infrastructure (sensor data), trains (position/state), stations (platform status), resolves immediate track conflicts (e.g., two trains approaching the same segment), adjusts train speeds to a safe distance and sends track authorization commands to trains, manages station platform allocation during arrivals/departures, and performs emergency rerouting (e.g., track obstructions). The TT-IRC optimizes daily schedules over a planning horizon of 24–72 h. It is responsible for creating an initial daily rail allocation plan, optimizing peak/off-peak demand patterns, generating predictive conflict warnings, and updating the TS-IRC with weekly schedule optimizations. The TT-IRC receives historical performance data from the TS-IRC. It sends optimized schedules to the TS-IRC and stations. The infrastructure is the physical track network with embedded sensors. Its responsibilities include monitoring track occupancy via magnetic sensors, reporting track conditions (weather, maintenance), provisioning real-time train position data via ATP (automatic train protection), and managing the signal states (red/green lights). It sends occupancy data to the TS-IRC and receives track authorization from the TS-IRC. The station management system coordinates platform operations. It manages platform door operations, coordinates passenger flow with train schedules, reports platform occupancy to the TS-IRC, and adjusts platform access during disruptions. It also receives train arrival/departure times from the TS-IRC. The train control system reports real-time position and speed, receives track authorization from the TS-IRC, adjusts speed based on TS-IRC commands, and communicates with the station systems for door operations.

The train control system sends the train location to the TS-IRC every 1 s. The infrastructure sends track occupancy data to the TS-IRC every 0.5 s and track condition data every 5 min. The TS-IRC, in turn, reports track usage and schedule deviations to the TT-IRC in real time. The TT-IRC processes the data, generates peak load models and sends them to the TS-IRC. The TT-IRC also predicts conflict warnings within a 24 h horizon. It updates the daily schedule’s optimization once a week. The TS-IRC sends feedback on the effectiveness of conflict resolution.

An example of daily recovery scenario is shown in Figure 5.

Benefits of adaptive track scheduling

Adaptive path planning provides significantly better performance compared to the traditional approach, namely, improvements in path conflict resolution time, path utilization, and delay propagation reduction [73,74,75,76].

2.2.5. Intelligent Traffic Management

Motivation

Traditional rail systems suffer from reactive delays (68% of disruptions caused by uncoordinated responses to minor events), suboptimal resource allocation (tracks used at 65% capacity during peak hours), and slow adaptation to dynamic conditions (e.g., weather conditions, incidents) [65,77]. Conventional systems rely on human dispatchers, but intelligent systems automate traffic control decisions to prevent incidents caused by human error. This is particularly important for high-speed rail, where the risks of incidents are increased. Intelligent traffic management can detect potential conflicts and dangerous situations, such as trains moving too fast, and automatically intervene to apply the brakes. Traditional traffic management systems are limited by their static, fixed-time approach that cannot adapt to real-time traffic changes, such as incidents or heavy congestion, leading to inefficiencies, delays, and increased emissions. In contrast, intelligent systems use real-time data and adaptive strategies to optimize flow, prioritize emergency vehicles, and better respond to unpredictable events, although they can be expensive to implement and may have privacy issues.

Solution

The solution is an intelligent architecture combining real-time precision with strategic planning, eliminating siloed decision-making while maintaining safety-critical responsiveness.

The actors involve the TS-IRC, TT-IRC, infrastructure, station management system and the train control system. The main functions of TS-IRC are related to safety-critical control, which enforces a minimum distance between trains (100 m) and speed restrictions during incidents, dynamic conflict resolution, which corrects train routes within 50 ms of detected conflicts, immediate response, which triggers emergency stops in case of obstacles (e.g., fallen objects), and local coordination, which manages traffic within a radius of 5 km from the current incident. The TT-IRC is responsible for optimizing daily schedules, resource allocation, long-term planning and disaster recovery planning. It adjusts schedules based on forecasted demand (e.g., events, weather conditions), allocates train paths taking into account maintenance time slots, optimizes 24 h capacity (e.g., 70% utilization vs. 65% in legacy systems) and generates rerouting plans for major disruptions (e.g., station closures). The infrastructure systems are built with sensor data, allowing the detection of track defects, weather conditions and obstacles (latency 200 ms). They control the signals, executing TS-IRC commands to move the trains (response time 200 ms) and regulate the voltage for energy efficiency during periods of low demand. Train control systems are responsible for on-board safety by implementing speed limits based on TS-IRC commands (with a response time of 0.5 s), for location reporting by sending GPS data to TS-IRC every 500 ms, and for passenger information by showing them real-time updates (with a response time of 5 s). The main functions of station systems include passenger flow management (adjusting platform access based on arriving trains), providing real-time information (updating digital displays with train status within 1 s of delay), and managing elevator/escalator usage during peak hours.

Figure 6 shows the information flow and decision-making workflow for incident detection and intelligent traffic management. A rail sensor detects debris on the tracks and alerts the TS-IRC within 200 ms. The TS-IRC calculates a safe braking distance, sends an emergency stop command to the affected train, and adjusts the speed of neighboring trains within 50 ms. The TS-IRC then sends incident data to the TT-IRC, which, in turn, generates a rerouting plan for the next 2 h within 10–100 s. The TT-IRC sends the optimized schedule to the TS-IRC, which implements the changes within 100 ms. The station system updates the digital displays, and the train systems send notifications to passengers (100 ms–1 s). The TT-IRC performs post-incident optimization by analyzing incident data and updating predictive models for future disruptions.

The architecture enforces a strict 100 ms decision boundary:

• Below 100 ms: TS-IRC-only decisions (safety-critical: train stops, speed adjustments)
• Above 100 ms: TT-IRC-assisted decisions (e.g., rerouting, schedule changes)

This prevents TS-IRC from being overloaded with strategic decisions while ensuring TT-IRC does not delay safety-critical actions.

Benefits of intelligent traffic management

Intelligent traffic management in rail transport offers benefits, including increased track utilization and efficiency through real-time monitoring and automated corrections, increased safety through incident detection and enabling predictive maintenance, improved sustainability through reduced energy consumption and emissions, and improved on-time operation [78,79,80].

3. Results

3.1. Mapping of AI/ML-Assisted Control onto Loops in an Intelligent Railway Control Architecture

Supervised learning is an approach in machine learning that focuses on learning a functional relationship between input features and their corresponding outputs using this labeled dataset. Components such as the ML training host and the ML model host/actor can reside in either the TT-IRC or the TS-IRC, depending on their role and latency requirements. In supervised learning systems, the TT-IRC operates as part of the RMAO, operating within the management layer. It can host model training, including offline and online training using data collected from the TS-IRC, train control systems, infrastructure systems, and station systems. The TT-IRC can also be an ML inference host, which hosts the ML model during model execution, as well as any online training, and an actor, which hosts an ML-assisted decision using the output from the ML inference of the model.

In unsupervised learning, the input data does not have predefined labels or outputs. This type of machine learning focuses on discovering hidden patterns or structures in unlabeled datasets. For unsupervised learning tasks, the machine learning training host and the machine learning model host/actor can reside in either the TT-IRC or the TS-IRC, depending on the computational complexity and latency requirements of the particular task.

Figure 7 shows the possible location of model training and actors applicable for supervised and unsupervised learning.

Reinforcement learning is a goal-oriented learning approach in which an agent interacts with an environment to optimize a long-term goal through trial and error. For offline reinforcement learning, the ML training host and the ML model host/actor (RL agent) are co-located in the TT-ITC (Figure 8a). The model is updated periodically based on monitoring the performance of the interactions between the agent and the TS-IRC, train systems, and infrastructure. For online reinforcement learning (real-time adaptation), the ML training host and the ML model host/actor are co-located in the TS-IRC (Figure 8b). This allows for low-latency decision-making. In the case of a hybrid implementation (offline–online workflows (Figure 8c), the ML training host resides in the TT-IRC while the ML model host/actor runs in the TS-IRC to balance computational efficiency and responsiveness.

The proposed intelligent railway control architecture supports the following control loops involving intelligent railway control functions (Figure 9):

• Time-tolerant control loops responsible for non-real-time functions.
• Time-sensitive control loops responsible for near-real-time functions.
• Live control loops responsible for real-time functions.

These control loops operate on different time scales depending on the railway component being controlled. Real-time control loops operate at the train level, directly controlling the train’s speed and brakes. Time-sensitive control loops operate at the TS-IRC level, making decisions in near-real time. Time-tolerant control loops operate in non-real time, such as training an ML model. The timing of these control loops depends on the use case. Providing a robust ML solution for each use case requires that the time-tolerant control loop be significantly longer than the timing of the time-sensitive control loop and the timing of the real-time control loop for the same use case.

The deployment of AI/ML solutions for smart rail control in these chains depends on several factors: computational complexity (intensive tasks may require centralized resources, e.g., TT-RIC), data requirements related to data availability and volume, which affect training and inference locations, and latency constraints related to real-time solutions (e.g., TS-IRC).

Federated learning is a distributed machine learning approach in which multiple AI/ML entities collaborate to train a shared model without centralizing sensitive data. Instead of aggregating training data on a central server, the data remains decentralized across distributed entities (a component of the Intelligent Rail Transport Management Architecture) to reduce privacy risks. Each entity trains a local model using its own data, and only model updates (e.g., weights or gradients) are shared with a central coordinator. The central server aggregates these updates to refine the global model. Since both TT-IRC and TS-IRC are capable of AI/ML training, TT-IRC acts as a central coordinator, while connected TS-IRCs function as distributed entities, as illustrated in Figure 10. This architecture allows federated learning to scale across geographically dispersed network components.

The process of federated learning between the TT-IRC and TS-IRC involves the following (Figure 11):

• The TT-IRC distributes an initial AI/ML model to its connected TS-IRCs.
• Each TS-IRC trains the model using locally collected data. Local training data remains on the TS-IRC and it is not transmitted to the TT-IRC.
• Local AI/ML model updates (e.g., weights or gradients) are sent from the TS-IRC to the TT-IRC.
• The TT-IRC aggregates the updates to improve the global AI/ML model.
• The updated global AI/ML model is downloaded back to the TS-IRCs for further training or deployment.
• Once the AI/ML model converges (i.e., performance stabilizes), it is deployed for inference in the TS-IRCs.

The AI/ML model management in federated learning is related to model upload/aggregation, and model distribution. For example,

• The TT-IRC can request/subscribe model updates (weights/gradients) from its connected TS-IRCs.
• The TT-IRC can notify TS-IRCs to download the updated global model.

Table 1. Examples of control logic distribution for hybrid traffic management use cases.

ML Type	Use Case	Training Host	Inference Host	Distribution Motivation
Supervised Learning	Predicting freight train delays based on weather, track condition, and historical data	TT-IRC central server	TS-IRC at station junctions	Historical data requires central aggregation; real-time prediction needs edge deployment for <50 ms latency
Unsupervised Learning	Clustering train types for dynamic priority grouping	TT-IRC central server	TT-IRC (daily plan generation)	Requires full traffic dataset for cluster formation; infers daily patterns, not real-time
Reinforcement Learning	Optimizing train sequencing at junctions	TT-IRC central server (simulated environment)	TS-IRC at junction control nodes	RL training requires massive simulation; inference needs TS-IRC for real-time sequencing decisions
Federated Learning	Building shared delay prediction model without sharing raw freight data	Edge servers at freight hubs	TS-IRC at junctions	Operators retain data on-premise; only model updates shared; inference at edge for low latency

presents examples of control logic distribution for hybrid traffic management use cases. The hybrid traffic management system is responsible for dynamic traffic separation (passenger/freight) based on real-time conditions. It includes multi-layer control for safety-critical tasks (TS-IRC) and strategic optimization (TT-IRC). The system uses edge-based AI for real-time decisions and central AI for long-term planning. It allows secure data sharing between operators without exposing raw data.

3.2. An Automatic Train Protection Communication Application

According to [58], the main functions of an automatic train protection (ATP) application include monitoring train speed, enforcing safe distances between trains to prevent collisions, emergency braking in critical situations, and compliance with signaling. The users in this case are ATP applications both on-board and in the control center or trackside elements.

An important consideration when implementing control logic for ATP is the delay introduced by communication in the case of centralized control, i.e., when control decisions are made by a node that operates in near-real time (TS-IRC). The radio communication between on-board/trackside applications and TS-IRC applications is based on the FRMCS standard, which is defined to replace the old narrowband GSM-Railway communications.

Work on the FRMCS specifications is ongoing and the existing specifications only describe the user requirements [81], which postulate the necessary reusable functions that must be supported by any critical communication application. This subsection describes a method for designing a critical data communication application. The ATP critical communication application is used when the intelligent control logic in the TS-IRC decides to send ATP instructions to the train (on-board system).

The use cases related to ATP data communication include initiation of an ATP data communication and termination of an ATP data session communication. The preconditions to initiate an ATP data communication session include the following.

• Both initiating party and terminating party must register their functional identities (e.g., train system X, controller Y). This is performed by the FRMCS Role management and presence application.
• The access to the ATP application must be authorized by the FRMCS system. This is performed by the FRMCS Authorization application.

The initiating ATP application has the right to initiate the ATP data communication, and the receiving ATP application has the right to use the ATP data communication. These processes are managed by the FRMCS communication authorization application. The initiating application can negotiate with the FRMCS system the requested QoS class, and the QoS profile management is performed by the FRMCS QoS class negotiation application. During active data transfer, the FRMCS arbitration applications resolve conflicts between communications competing for the attention of the initiating or receiving application.

The ATP data communication application (or ATP application in brief) logic is built on the ATP data communication session state model. Both an ATP application and the FRMCS system must maintain the state of the ATP data session.

Figure 12 shows the simplified model of an ATP data communication session maintained by an initiating ATP application.

In the following descriptions, short names of states, inputs and outputs are given in brackets. The abbreviation “i” is used for inputs internal to the application and FRMCS system inputs, while the abbreviation “e” is used for inputs and outputs exchanged between the application and FRMCS system.

Initially, the data communication state is not established (the App.Inactive state, [s₁^a]). Upon an event (StartSession event, [i1]), the initiating FRMCS application (e.g., on-board of the train or the control center) initiates an ATP data communication to the receiving side (e.g., control center or on-board of the train) by sending a DataCommReq request, [e1], to the FRMCS system.

In the App.Setup state, [s₃^a], data communication is in the process of being established. The return to the App.Inactive state occurs if a DataCommRes(unauthorized) response, [e2], is received, which means that the ATP data communication session is not authorized. In the same state, if the data communication is an authorized (DataCommRes(authorized) response, [e3]), the application requests a specific QoS class for the data session (SetQoSClassReq, [e4]). The receipt of a SetQoSClassRes(granted) response, [e5], means that the requested QoS class is granted, and the data communication session moves to the App.Active state. The receipt of a SetQoSClassRes(rejected) response, [e6], means that the requested QoS class cannot be granted and the establishment of the data communication session is canceled. The receipt of a SetQoSClassRes(lowerQoS) response, [e7], means that a lower QoS class is offered by the FRMCS system. If the application rejects the offer (Reject, [i8]), it sends to the FRMCS system an App.Rejected response, [e9], and the data communication session establishment is canceled. If the application accepts the lower QoS class (Accept, [i7]), it sends to the system an App.Accepted response, [e8], and the data communication session moves to the App.Active state.

In the App.Active state [s₃^a], the data communication session is established, and the data transfer is ongoing. In this state, the data communication session may be terminated by the FRMCS system (Terminated notification, [e10]), which occurs in case of a new incoming session with higher priority. The application also may terminate the ongoing data communication at some time (EndSession event, [i14]) by sending a CommTermReq request, [e11], to the FRMCS system.

In the App.Disconnect state [s₄^a], the data communication session is disconnected. The receipt of a CommTermRes response, [e12], means that the FRMCS acknowledges the data communication session.

Figure 13 shows the simplified ATP data communication session model maintained by the FRMCS system.

The initial state is Idle [s₁^s]. Upon receiving an ATP data session request (DataCommReq, [e1]), the data communication session moves to the next CommunicationAuthorization state.

In the CommunicationAuthorization state, [s₂^s], the FRMCS system checks whether the initiating user is allowed to invite the destination user(s) and whether the destination user(s) is allowed to receive the communication. The authorization conditions are based on registered functional identities of both parties, and on their subscriber profiles. If the authorization is not successful (Unauthorized, [i2]), the FRMCS system sends a DataCommRes (unauthorized) response, [e2], to the application and the data communication session moves to the initial state. Otherwise, if the authorization succeeds (Authorized, [i3]), the FRMCS system sends a DataCommRes(authorized) response, [e3], and the ATP data communication session moves to the next state.

The movement to the QoSClassNegotiation state, [s₃^s], occurs when the FRMCS system receives a request to set a specific QoS to the data session (SetQoSClassReq, [e4]). The FRMCS system may grant the requested QoS class (Granted, [i4]) and in this case, it sends a SetQoSClassRes(granted) response, [e5], to the application. If the requested QoS class cannot be granted (Rejected, [i5]), the FRMCS system sends a SetQoSClassRes(rejected) response, [e6], to the application. The FRMCS system may offer a lower QoS class (Degrated, [i6]) by sending a SetQoSClassRes(lowerQoS) response, [e7], to the application. If an App.Rejected, [e9], is received, then the application has rejected the lower QoS class and the data communication session moves to the initial state. If an App.Accepted, [e8], is received, then the application has accepted the lower QoS class and the FRMCS continues with the establishment of the data communication session.

In the BearerEstablishment state [s₄^s], the bearer service for data communication has been established within a setup time specified as immediate. The movement to the next state occurs when the bearer resources are allocated to the data session (Established, [i9]).

In the DataTransfer&DataRecording state [s₅^s], the data transfer is ongoing and the FRMCS system is recording the data communication and communication-related information. In this state, the application may disconnect the session (CommTermReq request, [e11]). In the case of a new incoming call (IncommingSession event, [i10]), the FRMCS system requests arbitration.

In the Arbitration state [s₆^s], the arbitration decision may reject the new incoming session (RejectIncomSession, [i11]) and in this case, the FRMCS system continues the established APT data communication. If the arbitration decision is to accept the incoming session (AcceptIncomSession, [i12]), the FRMCS has to release the bearer resources allocated to the established ATP data session.

In the BearerRelease state [s₇^s], the bearer resources allocated to the ATP data communication session are being released. In this state, if the session termination is triggered by the FRMCS system (Release, [i13]) then it notifies the application about the termination of the data communication session (Terminated, [e10]). If the session termination is triggered by the application (App.Released, [i15]), then the FRMCS system sends a CommTermRes response, [e12], to the application and the ATP data communication session is disconnected.

The ATP application and FRMCS system must be synchronized in their views on the state of an ATP data communication session. To prove that both models have synchronized in-time views on the state of a data communication session, the models are formally described. The notation of a Labeled Transition System (LTS) is used for formal model definition [82]. The concept of synchronization in states, which is formally defined in [57], is used to prove that the models are synchronized in their views on the state of an ATP data communication session.

Definition 1.

Let A^app = (S^app, Σ^app, →^app, s₀^app) be a formal description of an ATP data communication state, maintained by an ATP application, where

S^app = {s^a₁, s^a₂, s^a₃, s^a₄} is a set of states.

Σ^app = {i₁, e₁, e₂, e₃, e₄, e₅, e₆, i₇, e₈, i₈, e₉, e₁₀, i₁₄, e₁₁, e₁₂} is a set of inputs.

→^app = {(s^a₁$\stackrel{i1}{\to }$s^a₂), (s^a₂$\stackrel{e2}{\to }$s^a₁), (s^a₂$\stackrel{e3}{\to }$s^a₂), (s^a₂$\stackrel{e7}{\to }$s^a₂), (s^a₂$\stackrel{e5}{\to }$s^a₃), (s^a₂$\stackrel{e6}{\to }$s^a₁), (s^a₂$\stackrel{i7}{\to }$s^a₃), (s^a₂$\stackrel{i8}{\to }$s^a₁), (s^a₃$\stackrel{e10}{\to }$s^a₁), (s^a₃$\stackrel{i14}{\to }$s^a₄), (s^a₄$\stackrel{e12}{\to }$s^a₁)} is a set of transitions.

s₀^app = s^a₁ is an initial state.

Definition 2.

Let F^sys = (S^sys, Σ^sys, →^sys, s₀^sys) be a formal description of an ATP data communication state, maintained by the FRMCS system, where

S^sys = {s^s₁, s^s₂, s^s₃, s^s₄, s^s₅, s^s₆, s^s₇} is a set of states.

Σ^sys = {e₁, i₂, i₃, e₄, i₄, i₅, i₆, e₈, e₉, i₉, i₁₉, i₁₁, i₁₂, i₁₃, i₁₄, i₁₅} is a set of inputs.

→^sys = {(s^s₁$\stackrel{\alpha }{\to }$s^s₂), (s^s₂$\stackrel{i2}{\to }$s^s₁), (s^s₂$\stackrel{i3}{\to }$s^s₂), (s^s₂$\stackrel{e4}{\to }$s^s₃), (s^s₃$\stackrel{i4}{\to }$s^s₄), (s^s₃$\stackrel{i5}{\to }$s^s₁), (s^s₃$\stackrel{i6}{\to }$s^s₃), (s^s₃$\stackrel{e8}{\to }$s^s₄), (s^s₃$\stackrel{e9}{\to }$s^s₁), (s^s₄$\stackrel{i9}{\to }$s^s₅), (s^s₅$\stackrel{i10}{\to }$s^s₆), (s^s₆$\stackrel{i11}{\to }$s^s₅), (s^s₆$\stackrel{i12}{\to }$s^s₇), (s^s₇$\stackrel{i13}{\to }$s^s₁), (s^s₅$\stackrel{e11}{\to }$s^s₇), (s^s₇$\stackrel{i15}{\to }$s^s₁)} is a set of transitions.

s₀^sys = s^s₁.

Proposition 1.

Let R ⊆ A^app × F^sys be a relationship between the states of A^app and F^sys, where R = {(s^a₁, s^s₁), (s^a₂, s^s₂), (s^a₃, s^s₅)}. The paired states in R are synchronized.

Proof. 

According to the formal definition of synchronization in states, it is necessary to identify a bijection function between the transitions in states of R for each LTS. The mapping of transition sequences (the bijective function) between the states in R is shown in

Table 2. Mapping of transition sequences in A^app and F^sys.

Transition Abstraction	State Mapping	Transition Sequences in Aapp	Transition Sequences in Fsys
The application initiates an ATP session and the FRMCS authorizes the communication, and the application requests setting a specific QoS class.	Initial states (sa1, ss1) Next states (sa2, ss2)	sa1$\stackrel{i1}{\to }$sa2$\stackrel{e3}{\to }$sa2	ss1$\stackrel{e1}{\to }$ss2$\stackrel{i3}{\to }$ss2
The application initiates an ATP session and the FRMCS does not authorize the communication,	Initial states (sa1, ss1) Next states (sa1, ss1)	sa1$\stackrel{i1}{\to }$sa2$\stackrel{e2}{\to }$sa1	ss1$\stackrel{e1}{\to }$ss2$\stackrel{i2}{\to }$ss1
The FRMCS system grants the requested QoS class and the data session is established in the network	Initial state (sa2, ss2) Next states (sa3, ss5)	sa2$\stackrel{e5}{\to }$sa3	ss2$\stackrel{e4}{\to }$ss3$\stackrel{i4}{\to }$ss4$\stackrel{i9}{\to }$ss5
The FRMCS system cannot grant the requested QoS class to the data session and the session establishment is terminated.	Initial state (sa2, ss2) Next states (sa1, ss1)	sa2$\stackrel{e6}{\to }$sa1	ss2$\stackrel{e4}{\to }$ss3$\stackrel{i5}{\to }$ss1
The FRMCS system offers a degraded QoS class, the application accepts it, and the data session is established.	Initial state (sa2, ss2) Next states (sa3, ss5)	sa2$\stackrel{e7}{\to }$sa2$\stackrel{i7}{\to }$sa3	ss2$\stackrel{e4}{\to }$ss3$\stackrel{i6}{\to }$ss3$\stackrel{e8}{\to }$ss4$\stackrel{i9}{\to }$ss5
The FRMCS system offers a degraded QoS class, the application rejects it, and the data session establishment is terminated.	Initial state (sa2, ss2) Next states (sa1, ss1)	sa2$\stackrel{e7}{\to }$sa2$\stackrel{i8}{\to }$sa1	ss2$\stackrel{e4}{\to }$ss3$\stackrel{i6}{\to }$ss3$\stackrel{e9}{\to }$ss1
An incoming call to the inviting party is rejected by the FRMCS system and the application is not notified	Initial state (sa3, ss5) Next states (sa3, ss5)	___	ss5$\stackrel{i10}{\to }$ss6$\stackrel{i11}{\to }$ss5
An incoming call to the inviting party is accepted by the FRMCS system, the FRMCS system terminates the existing ATP session and releases the resources assigned to the session.	Initial state (sa2, ss2) Next states (sa1, ss1)	sa3$\stackrel{e10}{\to }$sa1	ss5$\stackrel{i10}{\to }$ss6$\stackrel{i12}{\to }$ss7$\stackrel{i13}{\to }$ss1
The application terminates the ATP data session and the FRMCS systems releases the resources assigned to the session.	Initial state (sa3, ss5) Next states (sa1, ss1)	sa3$\stackrel{i14}{\to }$sa4$\stackrel{e12}{\to }$sa1	ss5$\stackrel{e11}{\to }$ss7$\stackrel{i15}{\to }$ss1

.

The identified bijection function between the transitions in A^app and F^sys shows that R is a relationship between synchronized states. □

The proof that the models are synchronized in their views on the state of an ATP data communication session is also used to check the correctness of the communication between an ATP application and the FRMCS system during data session establishment and release.

According to [83], the FRMCS system architectural design will be based on the principles of Service-Based Architecture (SBA). SBA structures applications as independent, reusable services communicating over a network. REST (Representational State Transfer) is a popular architectural style or set of constraints for designing the APIs (Application Programming Interfaces) that these services use for communication, leveraging standard HTTP methods (GET, POST, etc.) and lightweight formats like JSON for simplicity, scalability, and efficiency, especially in web and cloud environments.

An experiment was conducted in a laboratory environment, aimed to evaluate the latency injected by REST API between an ATP application and the FRMCS system. A Java-based HTTP multi-threaded client generates POST requests for setting a specific QoS class with the domain-specific data in JSON format. The server, as a virtualized REST endpoint, responds with 200 OK. The server also acts as a virtualized Cassandra client and virtualized Cassandra server, providing a lightweight storage service.

Figure 14 shows the raw sequence of latency values for the tenth group of 1000 transactions, out of a 20,000 in total, over the RESTful endpoint.

In Figure 15, the Probability Mass Function (PMF) is shown for the distribution of 20,000 latency values.

The emulation results show that the main part of the latency values is below 2 ms, which is acceptable for near-real-time operations. While the peak value of the latency values is over 30 ms, 95% of data strengthen the conclusion that the main part of latency values is below 2 ms. The value of 1.3 ms approximately became the mean of the latency values of this experiment.

Therefore, the viability of the proposed ATP model is proved to increase the latency budget as much as the requirements about the data exchange delays are kept within the predefined limits for use by the AI-based application traffic.

4. Discussion

Maintaining reliability and safety in mission-critical systems is a complex task, as real-time interactions, hardware variability, and unexpected events make time validation difficult. To address these complexities and meet critical time requirements, advanced modeling (predictive analytics, artificial intelligence), data-driven approaches, and robust algorithms are used. The distinguishing aspect of the proposed architecture is its time-constrained design. By mapping intelligent railway functions onto architectural components based on time constraints, it is possible to manage complex interactions like minimum headways (separation), travel times, and dwell times, preventing conflicts, minimizing delay propagation, optimizing resource use, and enabling real-time rescheduling for reliable, high-capacity operations.

Distributed intelligent control in rail transport increases safety (less human error, real-time hazard response), efficiency (better energy use, optimized traffic), resilience (single fault tolerance) and flexibility, allowing autonomous “thinking” agents to adapt to changes, manage complex situations such as virtual connectivity, and enable predictive maintenance for reduced downtime, creating a smarter and more connected network. Time constraints are crucial for distributed intelligent rail control because they ensure safety (prevention of collisions by managing block occupancy), punctuality (minimizing delays by real-time rescheduling) and efficiency (optimizing resource use). Missing deadlines in these hard real-time systems (time-sensitive and “live” control) can lead to catastrophic failures, while soft time control (time-tolerant control) allows for dynamic adjustments (such as changing the idle/work time) to deal with disruptions, preventing a domino effect of delays across the network, which is essential for capacity and reliable service. For example, real-time control ensures that only one train occupies a section of track (block) at a time, which is a key safety feature (e.g., using track circuits), and missing a deadline for a train entering a block means a potential collision, making time accuracy paramount. An example of time-tolerant control is time-sensitive rescheduling, where in the event of disruptions (primary delays), time constraints (dwell time, travel time) are used to make quick decisions, preventing cascading secondary delays, and this ensures that the system remains stable and predictable despite uncertainties, which is crucial for high traffic densities. An example of time-tolerant control is resource optimization, where optimal schedules minimize costs and maximize track capacity by using available resources efficiently, which relies heavily on accurate timing, and this improves system efficiency and capacity, as intelligent systems use sophisticated models to solve complex scheduling problems, but only if time constraints are met.

TT-IRC is a logical function responsible for non-real-time railway operation control and optimization, and AI/machine learning workflow including model training and updates, and policy-based targeting of applications/functions in TS-IRC. The functional requirements for TT-IRC are related to model training and deployment, inference support, and performance feedback as follows:

• It must be able to request ML model training (regardless of deployment location) and trigger ML model retraining or performance evaluation, as well as maintain catalogs for ML designers of published/installed, trained models (executable components) and detect model compatibility with the target ML inference host.
• It should allow for the deployment of models via containerized execution (e.g., ML engines as packaged software libraries) and support dynamic model switching policies (e.g., based on traffic load or seasonal patterns).
• It must be able to access real-time machine learning performance metrics (accuracy, key performance indicators) and failure alarms via R2 interface, as well as pass performance management/failure management statistics for model evaluation and allow for the retraining of triggers based on performance degradation.

The requirements of both TT-IRC and TS-IRC are related to ML application registration, data matching, ML data subscription management, data mediation and termination workflow as follows:

• ML inference hosts (both TT-IRC and TS-IRC) must validate data type and frequency specifications during ML application registration. ML applications must declare their data production/consumption patterns (type and frequency) when registering with the inference host.
• Inference hosts must match consumed data requirements to available sources (other ML applications or host-mediated sources). Registration fails if no valid source matches consumed data requirements (applies to both TT-IRC and TS-IRC).
• ML inference hosts (both TT-IRC and TS-IRC) must process scoped data subscription requests, coordinating with RMAO, TT-IRC, or TS-IRC to establish data routing (e.g., R2 to ML application, inter-ML application data forwarding). ML applications producing data must handle subscription requests via the inference host, determining and generating required additional subscriptions to fulfill data requests.
• ML inference hosts (TT-IRC or TS-IRC) must mediate shared data requests from multiple ML applications without burdening the source ML application. TT-IRC must evaluate performance metrics against termination conditions and trigger actions when thresholds are breached. Inference hosts must execute model termination upon command, activate redundant models per backup instructions, and notify RMAO/TT-IRC of termination/activation outcomes via acknowledgements.

R2, as a non-real-time interface between RMAO/TT-IRC and TS-IRC, trains the systems, and the infrastructure systems provide management and operational control, enabling tasks such as troubleshooting, configuration, accounting, performance, security, software management, and file management. The requirements for the R2 interface for machine learning orchestration should allow for containerized deployment and updates of ML models as executable artifacts, collect detailed performance metrics and inference-specific counters for model training/optimization, and list the inference capabilities (e.g., compute resources, latency constraints) of the target deployment function.

Distributed intelligent control in rail transport, along with its advantages, also reveals disadvantages, mainly related to increased cybersecurity risks, complex communication requirements, challenges in ensuring safety levels compared to centralized systems, and potential problems with system stability and passenger comfort if not implemented properly. Time constraints are a challenge in coordinating between local controllers for global feasibility (avoiding deadlocks, ensuring smooth transitions), computational complexity (especially in large networks), difficulties in dealing with real-world uncertainties such as driver behavior or weather conditions, issues with data integration with legacy systems, and ensuring resilience against outages when relying on simplified local views.

5. Conclusions

In distributed systems, components manage local sections, but their interactions must respect time throughout the network, allowing for modular, extensible, and scalable management. The global goal is to balance local decision-making with overall network goals (capacity, reliability) by carefully managing constraints.

In smart railways, control logic can be distributed in a hierarchical system (trains, stations, control centers) to move from centralized solutions to local, real-time, safety-critical autonomy, increasing efficiency and safety through local processing of data from blocking sensors, traffic management and optimized speed profiles, and balancing centralized supervision with decentralized, autonomous operations. At the train level, intelligent “train agents” with autonomous capabilities could handle instantaneous driving, energy management (coasting, braking) and communication. At higher levels, the control logic can be divided between time-tolerant intelligent railway controllers (seconds/minutes timescale, for planning, AI/ML, policies) and time-sensitive intelligent railway controllers (milliseconds to seconds timescale, for dynamic, immediate adjustments such as QoS, resource allocation, rapid response), with TT-IRC setting high-level goals and TS-IRC performing rapid, localized optimizations, often through applications, to achieve both strategic optimization and safe and accurate operations.

This study identifies the requirements for distributed control logic in intelligent railway systems based on the analysis of different use cases and their time constraints. Since the distribution of control logic requires communications, an example of an FRMCS application for automatic train protection is considered and the latency injected by the RESTful interface between the TS-IRC and the train is evaluated.

In essence, timing constraints are the backbone of railway operations, dictating when and how fast trains move, ensuring safety while maximizing throughput in complex, dynamic environments. Distributed control logic overcomes the limitations of purely centralized systems, allowing autonomous operation and better management of complex networks.