# Towards Intelligent, Programmable, and Open Railway Networks
## 5 Interface between Time-Tolerant and Time-Sensitive Functions  
The TTICU, which resides in the RMAO framework, can be connected to multiple TSICUs, which, in turn, can control trains, Euroloops, interlockings, and RIUs in their areas, as shown in Figure 4. As an alternative, the TSICU may be implemented in one physical node consisting of more logical TSICUs with specialized functions for train control and trackside equipment control. Figure 3: Train speed policy generation, policy enforcement, and policy performance evaluation. The purpose of the R1 interface is to enable the TTICU functions to provide policy-based guidance, ML model management, and enrichment information to the TSICU functions so that the railway operation be optimized under certain conditions. Based on observables such as events and trigger conditions provided via the R3 interface, the TTICU may define policies that are provided to the TSICU via the R1 interface. The TSICU enforces the policy and collects train and trackside equipment data via the R3 interface and provides the policy feedback to the TTICU via the R1 interface. The TTICU uses this information to continuously evaluate the impact of the R1 policies towards the fulfillment of railway intent. Based on internal conditions, the TTICU may decide to issue new policies or to update existing policies. The ML models can be trained and executed at different places in the intelligent railway network architecture. In one scenario, the ML models may be trained on the RMAO layer and then used by the TTICU to improve the performance monitoring and guidance of the train and trackside equipment based on the R3 observability. The training and deployment of the ML model may be handled by the internal RMAO functions and the same training data to be used for TTICU inference. In another scenario, the ML models may be trained in the RMAO layer and then used by the TTICU to optimize the train and trackside equipment performance. The training and deployment of the ML model may be handled by the internal RMAO functions, and the training data used for the TSICU inference are the same. The trained ML models may be deployed by the RMAO layer via the R3 interface. The performance evaluation of the ML model and the handling of explicit feedback from the ML model itself are based on the R3 observability. The TSICU's functions are based on its internal functionality or tsApps, the configuration received via R3, and the R1 policies. The R1 enrichment information service can be used to support the policy enforcement in the TSICU. The enrichment information, which is provided in addition to the generally available information, may enhance railway operation performance and may be gathered by the RMAO from different internal and external sources. The TTICU provides enrichment information to the TSICU via the R1 interface. Following the service-oriented approach, the time-tolerant intelligent services and time-sensitive intelligent services may be defined according to the REST principles. REST is an architectural style for distributed applications that recognizes everything as a resource. The resource is uniquely identified, supports a standard interface, and has a JSON representation that is exchanged across the network over hypertext transfer protocol secure (HTTPS). The protocol stack of the R1 interface is shown in Figure 5.  
Figure 4: Deployment of time-tolerant and time-sensitive intelligence. In REST, any resources can be created (HTTP POST method), updated (HTTP PUT method), deleted (HTTP DELETE method), and read (HTTP GET method). Figure 6 shows the uniform resource identifier (URI) structure of the railway policy resources. The railPolicyTypes resource is a container of all policy types. It supports an HTTP GET method that retrieves a list of rail policy identifiers. The railPolicyTypeID resource represents an individual rail policy type, and an HTTP GET method applied on the resource retrieves the respective policy type information.