# Towards Intelligent, Programmable, and Open Railway Networks
## 5 Interface between Time-Tolerant and Time-Sensitive Functions
The railPolicies resource represents all rail policies from a certain type, and the list of policies may be retrieved using an HTTP GET method, while an HTTP POST method creates a new rail policy. The railPolicyID method represents an individual rail policy. The HTTP methods supported by the railPolicyID resource include PUT, which updates an existing rail policy, GET, which retrieves information about the rail policy, and DELETE, which is used to remove the rail policy. Figure 7 shows the flow of the rail policy creation procedure. The TTICU generates the rail policy identifier and sends an HTTP POST request to the TSICU. The target URI identifies the resource under which a new rail policy has to be created. The message body carries the JSON policy description. On success, the TSICU returns a \"201 Created\" response. On failure, the respective error code is returned. Figure 8 shows the flow to query a single rail policy. The TTICU queries about an individual rail policy by sending an HTTP GET method with a URI pointing to the resource representing the rail policy of interest. The response returns the policy description and status. Figure 5: Protocol stack of the R1 interface. Figure 6: Structure of URI of the railway policy resources. Figure 7: Flow of the rail policy creation procedure. To provide policy feedback, subscriptions to rail policies have to be supported. The policySubscriptions resource represents all subscriptions for notifications related to an individual rail policy. The list of all policy subscriptions may be retrieved by the HTTP GET method. The TTICU creates a new subscription by sending an HTTP POST method with a message body describing the criteria for notifications and the callback address at which it wants to receive notifications. The policySubscriptionID resource represents an individual subscription for a specific rail policy. It supports the HTTP GET method, which is used to retrieve subscription information, the HTTP PUT method, which is used to modify the subscription, and the HTTP DELETE method, which is used to terminate the subscription. Figure 9 shows the flow of the subscription creation procedure. Figure 10 shows the flow of the notification procedure, which provides policy feedback to the callback address indicated earlier in the subscription request. The TTICU and TSICU must have synchronized views on the railway policy status. Figure 11 shows a model representing the railway policy lifecycle as seen by the TTICU, and Figure 12 shows a model representing the policy state supported by the TSICU. Both models are simplified, as they do not describe the behavior related to subscriptions and notifications. Figure 8: Flow of the rail policy query procedure. Figure 10: Flow of the notification procedure. Figure 9: Flow of the subscription creation procedure. From the TTICU's point of view, a policy may be created, updated, or deleted when predefined measurement thresholds are reached. The TTICU can request the enforcement of a newly created or updated policy or a policy deletion. Upon receiving a request from the TTICU, the TSICU converts the policy into corresponding commands, enforces the commands via the IR interface, and sends back the result. To prove that both state machines expose equivalent behaviors, they are formally described as labeled transition systems (LTSs), and the mathematical formalism of a weak bi-simulation is used. An LTS is defined as a quadruple of a set of states, a set of stimuli that trigger transitions, a set of transitions, and a set of initial states [33; 34].