A refinement-based development of a distributed signalling system

The decentralised railway signalling systems have a potential to increase capacity, availability and reduce maintenance costs of railway networks. However, given the safety-critical nature of railway signalling and the complexity of novel distributed signalling solutions, their safety should be guaranteed by using thorough system validation methods. To achieve such a high-level of safety assurance of these complex signalling systems, scenario-based testing methods are far from being sufficient despite that they are still widely used in the industry. Formal verification is an alternative approach which provides a rigorous approach to verifying complex systems and has been successfully used in the railway domain. Despite the successes, little work has been done in applying formal methods for distributed railway systems. In our research we are working towards a multifaceted formal development methodology of complex railway signalling systems. The methodology is based on the Event-B modelling language which provides an expressive modelling language, a stepwise development and a proof-based model verification. In this paper, we present the application of the methodology for the development and verification of a distributed protocol for reservation of railway sections. The main challenge of this work is developing a distributed protocol which ensures safety and liveness of the distributed railway system when message delays are allowed in the model.


Introduction
Railway signalling is a safety-critical system whose responsibility is to guarantee a safe and efficient operation of railway networks. In the last few decades there have been proposals to utilise distributed system concepts in the railway signalling as a way of increasing railway network capacity and reducing maintenance costs (e.g. [HP00,WK12]). These emerging distributed railway signalling concepts propose to use a radio-based communication technology and novel distributed signalling protocols for decentralising contemporaneous signalling systems.
Because of their complex concurrent behaviour, distributed systems are notoriously difficult to validate and this could curtail the development, and deployment of novel distributed signalling solutions. To achieve a highlevel of safety assurance of novel distributed signalling systems popular railway system validation methods, such as scenario-based testing methods, would be far from being sufficient. In recent years, there has been a push by industries with a strong focus on distributed systems to incorporate formal methods into their system development processes [HHK+17,New14]. The railway domain has proved to be a fruitful area for applying various formal methods, but considerably less has been done in applying them for distributed railway systems by industry and academia [BBFM99,ED06]. Therefore, the long-term aim of our research is to lower the barriers of applying formal methods for the development of complex railway signalling systems, including distributed [SIK+20], heterogeneous [SI17] and hybrid [SDS+19] railway systems.
In order to manage the modelling and verification complexity of complex railway systems we are working towards a multifaceted formal development methodology. The methodology primarily relies on three concepts: a refinement-based model development, communication modelling patterns [SIA+19] and a proof-based model verification. The methodology is built upon the Event-B method [Abr13] which provides an expressive modelling language, flexible refinement mechanism and proof-based verification. It is also paramount that the methodology should support quantitative evaluation; as stated by Fantechi and Haxthausen [FH18], signalling solutions will only be adopted in practice if system availability is demonstrated. Therefore, in our proposed multifaceted methodology we also integrate a stochastic simulator for a quantitative railway system analysis.
In this paper, we present our work on a refinement-based formal development of a novel distributed signalling protocol. The paper attempts to demonstrate the advantages of the proposed methodology and refinement-based formal development, particularly, in the early stages of the system development (system prototyping) where specifications and requirements are incomplete. The main objective of the developed protocol was to guarantee a safe allocation of railway sections while ensuring liveness of the distributed signalling system. In our work, the liveness property of the system had to be guaranteed by the protocol in a model where message delays are permitted. The authors of related researches did not consider liveness and fairness properties which, as discussed in [FH18], can directly affect system availability. The consideration of message delays has also introduced modelling and deductive verification challenges as subtle deadlock scenarios were discovered.
Related work. In [FH18] the authors formalise the railway interlocking problem as a distributed mutual exclusion problem and discuss the related literature on distributed interlocking (e.g. [HP00,FHN17,WK12]). In principle all railway models share similar high-level safety, liveness and fairness requirements, as summarised on page 2 in [FH18]. One difference between our work and the studies overviewed in [FH18] is the interlocking engineering concept and the system model (e.g. allowed message delays). Another difference is the formal consideration of liveness and fairness requirements. In our work we not only prove the safety properties of the protocol, but also ensure systems liveness, fairness and analyse performance. A similar distributed signalling concept is presented as a case study in [Pro16]. The authors verified their system design via a simulation approach and only considered scenarios with up to two trains. In our verification approach we prove the distributed signalling system mathematically and hence guarantee its safety for any number of trains. In the study by Morley [Mor96] the author formally proved a distributed protocol, which is used in the real-world railway signalling systems to reserve a route, which is jointly controlled by adjacent signalling systems. Even though the distributed signalling concepts of our works are different, the effects of message delays to the safety were considered in both works. Our developed distributed signalling protocol is also based on serialisability and similar to ones defined from transactions processing [EGLT76,BSR80,GR92] in centralised and distributed database systems.
Paper structure. The rest of the paper is organised in the following way. Section 2 revisits a previously proposed multifaceted methodology and provides background information on the Event-B formal specification language. In Sect. 3 we elicit high-level distributed system requirements and specifications as well as provide a semi-formal description of the distributed resource allocation protocol. In Sect. 4 we present the formal protocol model development with the Event-B method. In the last section, Sect. 5, we summarise our work and discuss future work directions.

Multifaceted formal development methodology
The generally accepted approach to any formal system development is starting a development process by first informally describing system specifications and requirements. Therefore, this is the first step (Step 1 in Fig. 1) in our formal development process. At the moment we do not suggest or provide a systematic approach to defining requirements and specifications of a distributed system, however, we require labelling each requirement with a unique label. By labelling requirement and specifications we intend to ensure the traceability between informal and formal methodology artefacts. The traceability aspect guarantees the completeness of the model, meaning, that all informal specifications and requirements have been captured by the formal model. On the formal Event-B artefact, we require to annotate events and invariants of the Event-B model with labelled references to a specific informal artefact (see Fig. 2).
The following step ( Step 2) in our methodology is a development and verification of a functional formal Event-B model. The purpose of formally modelling a distributed system is to have a formal artefact, which can be animated, analysed and formally verified. For the development and verification of functional system models we selected the Event-B [Abr13] specification language, which has been successfully used for a formal development of various distributed protocols (e.g. [CM06,HKBA09,ILTR11]). The Event-B method provides an expressive modelling language, flexible refinement mechanism and is also proof-driven, meaning that model correctness is demonstrated by generating and discharging proof obligations with available automated theorem provers [DFGV14,ISAYR16]. The method is also supported by tools such as ProB [LB03] which makes it possible to animate a model and validate it via model-checking. ProB can be particularly useful in early modelling stages where it could be too onerous to deductively verify a model. On the other hand, the Event-B method does not have an adequate probabilistic reasoning support, which was essential to verifying our distributed railway section reservation protocol. Therefore, it was decided to integrate a well-known stochastic model checker, PRISM [HKNP06], into the framework, so the probabilistic properties of a system can be verified.
The last step (Step 3) in the proposed formal development process is analysing performance of the developed distributed system. For analysing system's performance we have implemented a high-fidelity protocol simulator which could help to evaluate a protocol under normal or stressed conditions. Because of the paper focus on Steps 1 and 2, in the following sections we provide more detail on the functional Event-B model development and the Event-B method.
Tc(s, c) END Fig. 3. Event-B model structure

Event-B
The Event-B mathematical language [Abr13] used in the system development and analysis is an evolution of the classical B method [Abr96] and Action Systems [Bac90]. The formal specification language offers a fairly highlevel mathematical language based on a first-order logic and Zermelo-Fraenkel set theory as well as an economical yet expressive modelling notation. The formalism belongs to a family of state-based modelling languages where a state of a discrete system is simply a collection of variables and constants whereas the transition is a guarded variable transformation. A cornerstone of the Event-B method is the step-wise development that facilitates a gradual design of a system implementation through a number of correctness preserving refinement steps. The model development starts with a creation of a very abstract specification and the model is completed when all requirements and specifications are covered. The Event-B model is made of two key components-machines and contexts which respectively describe dynamic and static parts of the system (see Fig. 3). The context contains modeller declared constants c and associated axioms A(s, c) which can be made visible in machines. The dynamic part of the model contains variables v which are constrained by invariants I (s, c, v ) and initialised by an action. The state variables are then transformed by actions which are part of events and the modeler may use predicate guards G(s, c, v , x ) to denote when event is triggered.
The Event-B method is a proof driven specification language where model correctness is demonstrated by generating and discharging proof obligations-theorems in the first-order logic. Table 1 shows a few of more important proof obligations of the Event-B language. The model is considered to be correct when all proof obligations are discharged.
Rodin [The06] is an open source Eclipse-based integrated development environment (IDE) for Event-B model development. The Rodin is a core set of plug-ins for project management, formal development, syntactic analysis, proof assistance and proof-based verification.

Developing functional protocol models in Event-B
A formal functional Event-B model can have a multitude of uses, but the main application is for formally proving properties about the distributed system. The completed distributed system's model in Step 2 should cover all requirements and specifications, and would be considered correct when all generated proof obligations are proved. The model development approach we utilise (visualised in Fig. 4) is a rather standard and starts with the abstract model m ab. which formally specifies the objective of the distributed protocol. In fact, distributed aspects of the system are ignored at this model level and the abstract model considers a centralised configuration. The following group of refinement steps (m 0..n ) introduce more details about the model by primarily modelling communication aspects. For protocol modelling we propose to use backward unfolding style where the next refinement step introduces the preceding protocol step. The communication modelling patterns are primarily made of patterns for defining communicating actors of a system, introducing new messages into a model through context models (and machine variables) and machine event patterns for message exchanges. The previously developed communication modelling patterns and a generic model refinement plan are described in more detail in [SIA+19].
A key aspect of our methodology is the scenario validation and analysis. Particularly, in early protocol development stages, it might be too onerous to verify a model only to discover design mistakes. To facilitate design exploration we apply animation and model-checking enabled by ProB. Nonetheless, the final (concrete) model should be proved by adding invariants to the model and proving generated proof obligations with available automated theorem provers.  5. An example of a distributed railway system and its abstract model: sub-route mapping to resources SR 0 → r 0 , · · · , SR 3 → r 3 and trains to agents mapping T 0 → a 0 , T 1 → a 1 . The bold arrows illustrate resources locked by agents while dashed arrows show resources which will need to be locked by an agent. For example, if train T 1 wants to travel to sub-route SR 2 it must simultaneously lock sub-routes SR 1 and SR 2 . Table 2. High-level distributed signalling system specifications SYS 1 | The distributed railway system is made of agents and resources (respectively represent trains and railway subsections). SYS 2 | Agents are only allowed to communicate with resources and not other agents. SYS 3 | Agents have an objective, which is a set of resources agents have to reserve before proceeding with the next objective. SYS 4 | Agents have a memory in which sent messages are stored. SYS 5 | Resources have a memory where agents allocation order can be stored. SYS 6 | Resources have a promised pointer (ppt) of the memory, which indicates a currently available resource allocation order. SYS 7 | Resources have a read pointer (rpt) of the memory, which specifies a memory slot (with an associated agent) that currently uses a resource. ENV 1 | Message delays are permitted in the distributed signalling system model.

High-level distributed signalling system model
We abstract the railway model and instead of trains, routes, and switches our system model consists of agents and resources (resources controllers). The system model permits message exchanges only between agents and resources, and messages can be delayed. Each resource controller has an associated queue-like memory, where the order of agent allocation can be stored. A resource also has a promise (ppt) and read pointers (rpt), which respectively indicate the currently available slot in the queue and the reserved slot (with an associated agent) that currently uses the resource (abstract railway model visualised in Fig. 5). An agent has an objective, which is a collection of resources an agent will attempt to reserve (all at the same time) before using and eventually releasing them. In Fig. 6 we visualise a simple resource locking protocol and illustrate how ppt and rpt variables are updated. In Table 2 high-level distributed system specifications are elicited in the format, which is suggested by the proposed methodology.
The main objective of the protocol is to enable safe and deadlock-free distributed atomic reservation of collection of resources. Where by a safe resource reservation we mean that no two different agents have reserved the same resource at the same time. The protocol must also guarantee that each agent eventually gets all requested resources-partial request satisfaction is not permitted. These are fundamental requirements of railway signalling systems which ensure a safe train separation by utilising a so-called fixed-block signalling [FH18]. Table 3. High-level system safety and liveness requirements SAF 1 | A resource will not be allocated to different agents at the same time. SAF 2 | An agent will not use a resource until all requested resources are allocated. LIV 1 | An agent must be eventually allocated requested set of resources. LIV 2 | Resource allocation must be guaranteed in the presence of message delays. The main high-level safety and liveness requirements of the distributed system are expressed in Table 3. The following section attempts to justify the need for an adequate distribute protocol by discussing problematic distributed resource allocation scenarios.

Problematic distributed resource allocation scenarios
Let us consider Scenarios 1-2 (visualised in Fig. 7) to see how requirement LIV 1 could not be guaranteed (while ensuring SAF 2 ) without an adequate distributed resource allocation protocol.
Scenario 1 In this scenario, agents a 0 and a 1 are attempting to reserve the same set of resources {r 0 , r 1 }. Agents start by firstly sending request messages to both resources. Once a resource receives a request message, it replies with the current value of the promised pointer ppt(r k ) and then increments the ppt(r k ). For instance, in this scenario, resource r 0 firstly received a request message from agent a 0 and thus replied with the value ppt(r 0 ) = 0, which was then followed by a message to a 1 with an incremented ppt(r 0 ) value of 1. In Fig. 7, we denote a * n as the ppt(r k ) value sent to a n . Request messages at resource r 1 have been received and replied in the opposite order.
In this preliminary protocol, once an agent receives promised pointer values from all requested resources, it sends messages to requested resources to lock them at the promised queue-slot. In this scenario, agent a 0 was promised queue-slots {(r 0 , 0), (r 1 , 1)} while a 1 queue-slots {(r 0 , 1), (r 1 , 0)}. If agents would lock these exact queueslots, resource r 0 would allow a 0 to use it first, while r 1 would concurrently allow a 1 . The distributed system would deadlock and fail to satisfy LIV 2 requirement as both agents would wait for the second use message to ensure SAF 2 .
In order to prevent the cross-blocking type of deadlocks, an agent should repeatedly re-request the same set of resources (and not lock them) until all received promised queue slot values are the same. We define a process of an agent attempting to receive the same promised queue slots as an agent forming a distributed lane (dl).
Definition 1 A distributed lane dl of an agent a is a set of pairs dl(a) {(r k , s), · · · , (r k+m , s)} where {r k , · · · , r k+m } are all resources requested by an agent a and s is a natural number representing a slot value of the queue promised by all requested resources.  Important to note, that this solution relies on the assumption, that there is a non-zero probability of distinct messages arriving at the same destination in different orders, even if they are simultaneously sent by different sources.
Scenario 2 However, simply re-requesting the same resources might result in a different problem. In Scenario 2, agent a 1 has requested and has been allocated a single resource r 1 which in turn modified ppt(r 1 ) to 1 while ppt(r 0 ) remained 0. If another agent a 0 attempts to reserve resources {r 0 , r 1 }, it will never receive the same promised pointer value from both resources per (re)-requesting round, and hence, will not be able to lock them.

Semi-formal protocol description
In order to address the issues described in the previous section, we developed a two-stage protocol, where the stage 1 of the distributed protocol specifies how an agent forms a distributed lane and stage 2 of the protocol addresses deadlock scenarios, which can occur after agents form distributed lanes. In the following paragraphs we semi-formally describe both stages of the protocol, which then will be formally modelled with the Event-B specification language (Algorithm 1-agent's algorithm for stage 1 , Algorithm 2-resource's algorithm for both stages and Algorithm 3-agent's algorithm for stage 2 ). Stage 1 An agent, which intends to reserve a set of resources starts by sending request messages to resources. The messages are sent to those resources which are part of the agent's current objective. In the provided pseudocode excerpt, we first denote relations sent requests and objective where they are mappings from agents to resource collections (ln. 1-3 Algorithm 1). The messages request are sent by an agent a n to a resource r k (r k ∈ objective[a n ]) until sent requests[a n ] = objective[a n ] (images are equal) (ln. 4-7 Algorithm 1). When a resource r k receives a request message from an agent a n it responds with a reply message which contains the current promised pointer value of resource ppt(r k ) to that agent and increments the promised pointer (ln. 6-8 Algorithm 2). After sending all request messages an agent waits until reply messages are received from requested resources (ln. 8 Algorithm 1) and then makes a decision.
If all received promised pointer values are the same (a distributed lane can be formed) an agent will complete stage 1 by sending write messages which contain the negotiated index to all requested resources (ln. 20-24 Algorithm 1). But if one of the received promised pointer values is different an agent will start a renegotiation cycle (ln. 9-19 Algorithm 1). An agent will now send a srequest messages which contain a desired slot index to resources.
Algorithm 1 Agent stage 1 communication algorithm 1: variables sent requests, received replies, sent srequests, sent write typeof AGT ↔ RES init ∅ 2: variables objective typeof AGT ↔ RES init objective :∈ AGT ← ↔ RES 3: variables replies typeof AGT ↔ N init ∅ 4: while sent requests[a n ] objective[a n ] do requesting resources which belong to the objective 5: request(a n ) → r k 6: sent requests : sent requests ∪ {(a n , r k )} 7: end 8: wait until received replies[a n ] objective[a n ] 9: while | replies[a n ] | 1 do enter while loop if all received indices are not the same 10: sent srequests[a n ] : ∅ 11: received replies[a n ] : ∅ 12: replies[a n ] : ∅ 13: while sent srequests[a n ] objective[a n ] do 14: m : max(replies[a n ]) + 1 15: srequest(a n , m) → r k send a special request message with a desired slot index m 16: sent srequests : sent srequests ∪ {(a n , r k )} write(a n , m) → r k 23: sent write : sent write ∪ {(a n , r k )} 24: end A desired index is computed by taking the maximum of all received promised pointer values and adding a constant (one is sufficient) -ln. 14 Algorithm 1. A resource will reply to srequest message with the higher value of the current ppt(r k ) or received srequest message value and will update the promised pointer (ln. 9-11 Algorithm 2). After sending all srequest messages, an agent will wait for reply messages (ln. 18 Algorithm 1) and will restart the loop if received slot indices are not the same (ln. 9 Algorithm 1).
It is important to note that the stage 1 protocol solution to the described deadlock scenarios has a stochastic nature and one needs to guarantee that a desirable state is probabilistically reachable. In Table 4 we elicit additional safety and liveness requirements for the stage 1 of the protocol, which will need to be proved in the formal model. Stage 2 Once an agent completes sending all write messages it will wait for all pready messages from resources (ln. 4 Algorithm 3). A pready message is sent by a resource firstly if it has received a write message and no other agent is consuming that resource at that moment-resource is not locked (ln. 12-15 Algorithm 2). Secondly, a pready message will only be sent to an agent if it is distributed lane is the new minimum. In our protocol resources read pointer always take a new minimum value in the queue, once an agent sends a release message and allocation is removed from the queue. Table 4. Low-level protocol stage 1 safety and liveness requirements SAF 3 | An agent will not send write (form a distributed lane) messages until all receive promised pointer values are identical. SAF 4 |Agents with overlapping resource objectives will negotiate distributed lanes with different index. LIV 3 | An agent will eventually negotiate a distributed lane.
Algorithm 2 Resource communication algorithm case request(a n ) a resource replies to a request message with a slot index ppt(r k ) 7: reply(ppt(r k ), r k ) → a n 8: case srequest(a n , n) a resource replies to a special request message with a slot index ppt(r k ) or n 10: reply(max(ppt(r k ), n), r k ) → a n 11: ppt(r k ) : max(ppt(r k ), n) + 1 12: case write(a n , m) a resource replies to a write message with a pready message if 13: if rlock(r k ) ∅ ∧ m rpt(r k ) a resource is not locked and read pointer is at slot m 14: mem(r k , m) : a n 15: pready(r k ) → a n 16: case lock(a n ) 17: if rlock(r k ) ∅ a resource replies with a ready message if a resource is not locked 18: rlock(r k ) : a n a resource is locked and ready message is sent 19: response(r k , READY) → a n 20: if rlock(r k ) ∅ 21: response(r k , DENY) → a n resource replies with a deny message if a resource is locked 22: case release(a n , m) a resource will unlock itself and remove an agent from memory slot m if mem(r k ) ∅ if memory is not empty a resource will 26: rpt(r k ) : min(dom(mem(r k ))) update a read pointer to the next reserved slot 27: a n : mem(r k )(rpt(r k )) and send pready message to that agent 28: pready(r k ) → a n 29: When an agent receives all pready messages it will send lock messages to requested resources (ln. 5-8 Algorithm 3). If a resource is unlocked upon receiving lock message it will reply with ready message and lock itself, meaning, that it will stop sending pready messages (even to agent with smaller distributed lanes) until a release message is received from that agent (ln. 17-19 Algorithm 2). However, if, a resource is locked upon receiving lock message, it replies with deny message (ln. 20-21 Algorithm 2). If for every lock message an agent received a ready message, it can proceed to use resources and eventually release them. If, at least, one message is a deny message an agent will send release messages to resource (ln. 11-14 Algorithm 3) which sent ready messages to unlock them and will wait for pready messages again to repeat the process.
Algorithm 3 Agent stage 2 communication algorithm 1: variables received response, received pready, sent lock, sent release, consumed, released typeof AGT ↔ RES init ∅ 2: variables response typeof RES ↔ (AGT ↔ {DENY, READY}) init ∅ 3: while received response[a n ] objective[a n ] do 4: wait until received pready[a n ] objective[a n ] wait until all pre-ready messages are received 5: while sent lock[a n ] objective[a n ] do attempt to lock all requested resources 6: lock(a n ) → r k 7: sent lock : sent lock ∪ {(a n , r k )} 8: wait until received response[a n ] objective[a n ] wait until all ready messages are received 10: if DENY ∈ ran(response)[a n ] do 11: while sent release[a n ] response −1 [(a n , DENY)] do resources which sent DENY message 12: release(a n ) → r k 13: sent release : sent release ∪ {(a n , r k )} consumed : consumed ∪ {(a n , r k )} 23: end 24: while released[a n ] objective[a n ] do all consumed resources are eventually released 25: release(a n ) → r k 26: released : released ∪ {r k , a n } 27: end

Formal protocol development with Event-B
We apply the Event-B formalism to develop a high-fidelity functional model and prove the protocol functional correctness requirements. We follow the modelling process presented in Section 2. Important to note that the protocol model was redeveloped multiple times as various deadlock scenarios were found with ProB animator and model-checker. In following sections we present the final (verified) model.

A refinement strategy of the distributed protocol
The model development approach we utilise is model refinement, which starts with the abstract model that formally specifies the objective of the protocol. In fact distributed aspects of the system are ignored at this model level and the abstract model considers a centralised configuration. The abstract resource allocation protocol model was captured by two machines (m 0 and m 1 ). The former model essentially summarises the high-level objective of the protocol which is agents safely capturing and releasing collection of resources (objectives). This abstract model contains individual events for capturing and releasing objectives. The next refinement step introduces resources into the model and decomposes two previously introduced events according to the loop modelling pattern defined in [SIA+19].
The following group of refinement steps introduces more details about the model by primarily modelling aspects of communication. For protocol modelling, we propose to use the backward unfolding style where the next refinement step introduces the preceding protocol step. The abstract models were firstly refined with stage 2 segment of the protocol. In the refinement, m 2 , we introduced lock, response and release messages and associated events into the model. In this step we also demonstrated that the protocol stage 2 ensures safe distributed resource reservation by proving an invariant. The invariant states that no two agents will be both at resource consuming stage if both requested intersecting collections of resources. The following refinement, m 3 , is the bridge between protocol stages stage 1 and stage 2 and introduces two new messages write and pready into the model. In the final refinement step (m 4 ) we model stage 1 of the distributed protocol which is responsible for creating distributed lanes. The remaining messages request, reply, srequest and associated events are introduced together with the distributed lane data structure. In this refinement, we prove that distributed lanes are correctly formed.

Abstract Model Context
The abstract model context introduces agents, resources and objectives into the model as finite carrier sets. The context also contains the enumerated set for the agent's status.
Message Context All messages in the protocol were defined in individual context models according to the communication pattern presented in [SIA+19].

Abstract Model
The initial machine (abstract model) summarises the purpose of the protocol. The high-level objective of the protocol is to facilitate the reservation of collection of resources (objectives) by agents. The abstract model captures an agent reserving and eventually releasing an objective.

Refinement 1 (Abstract ext.)
In this refinement we introduce resources into the model and now an agent tries to fulfil the objective by locking individual resources (and releasing). To model the iterative process of locking/releasing resources we use loop modelling pattern.

Refinement 2
Because of the backward unfolding style the model is then refined with stage 2 part of the protocol. In the refinement lock, response and release messages are introduced. With this refinement step we also demonstrate that the protocol's stage 2 ensures safe distributed resource reservation by proving an invariant. The invariant states that no two agents will be both at resource consuming stage if both requested intersecting collections of resources.

Refinement 3
This refinement can be considered as a bridge between the protocol's stages stage 1 and stage 2 . Here, two new messages-write and pready-are introduced into the model.

Refinement 4
The final refinement step captures the stage 1 of the distributed protocol which is responsible for creating distributed lanes. The remaining messages request, reply, srequest and associated events are introduced together with the distributed lane data structure. In this refinement, we prove that distributed lanes are correctly formed (req. SAF 3−4 ).

Protocol Event-B model: abstract context
The formal protocol modelling was started by defining static model information such as carrier sets, constants and axioms. First of all we create a context for the abstract model which contains three finite size carrier sets representing agents (AGT), resources (RES) and objectives (OBJ) as shown in Listing 1. The latter carrier set is used as an extractor operator for groups of resources in a constant function (objr).
We also introduce an enumerated set (AST) to denote agent status or in other words agent's program counter values in a separate context model context agent state (Listing 2). For the abstract model only (CONSUME) and (RELEASE) elements are needed whereas remaining elements will be introduced in the following subsections.

Protocol Event-B model: machine m 0
In modelling the distributed resource allocation protocol we follow a standard Event-B modelling approach where the abstract model summarises the protocol with a centralised view of the system. As previously discussed, the objective of the distributed protocol is to enable safe resource locking. This can be abstracted as agents consuming and releasing objectives (visualised in Fig. 8). In the abstract model we want to prevent agents consuming identical objectives.
To begin with, we introduce two variables for storing consumed objectives (cons) and agents status (pct0) as shown in Listing 3. The agent consume event updates the variable cons with a new pair (act 1 in Listing 4) if an objective has not been consumed (guard grd 1 ) and an agent is not consuming any other objectives (guard grd 2 ). In addition the event updates agent's program counter-variable which helps to track the steps of the agent and discharge proof obligations (guard act 2 ).
The second event (Listing 5) models the release of an objective by removing a pair which belonged to the cons variable and updating the program counter. The correctness of the abstract model can be verified by proving invariant (inv saf in Listing 3) which asks to prove that an objective is only consumed by a single agent. The Rodin platform automatically generates proof obligations, like one below, which requires to prove that an invariant inv saf is preserved by the agent consume event.
a 0 a 1 · · · a n ob 0 ob 1 · · · ob n consume consume a 0 a 1 · · · a n ob 0 ob 1 · · · ob n release X Fig. 8. A visualisation of the abstract resource allocation model (m 0 ): model consists of agents which consume free objectives and then release them Guards (and other invariants, axioms) of the agent consume event become hypothesis of the proof obligation and if they are strong enough make it is possible for available automatic theorem provers to prove them automatically. A similar proof obligation was generated and automatically proved for the agent release event.

Protocol Event-B model: machine m 1
The refinement step m 1 expands on the previous refinement by introducing resources into the model. Instead of simply consuming an objective, an agent captures resources until an objective is fulfilled (visualised in Fig. 9). Captured resources are stored in newly created variable capt whereas objective an agent will try to complete in the function objt (shown in Listing 6).
In contrary to capturing a single objective, an agent might need to consume multiple resources in order to fulfill its objective. For the iterative process, we previously introduced a two event pattern which we instantiate in this refinement step for capturing and releasing events (see Section IV.D in [SIA+19]). The loop body event agent consume b (Listing 7) takes any agent with previously initialised objective and assign a new resource rs to the variable capt (action act 1 in Listing 7). The agent must be at CONSUME state (guard grd 5 ), the resources must be within agent's objective (guard grd 2 ) and not yet be captured by any agent (guard grd 3 ).
inv 1 cons ∈ AGT → OBJ £ variable which maps agents to consumed objectives inv 2 pct0 ∈ AGT → AST £ variable which maps agents to its current program counter status inv saf cons −1 ∈ OBJ → AGT £ safety invariant which requires an objective to be consumed by only a single agent EVENT agent consume ANY ag, ob £ agent (ag) and objective (ob) WHERE grd 1 ob ∈ OBJ \ ran(cons) £ take an objective that has not been consumed grd 2 ag ∈ AGT \ dom(cons) £ take an agent that has not consumed an objective grd 3 pct0(ag) CONSUME £ program counter of the agent (ag) must be CONSUME THEN act 1 cons(ag) : ob £ assign (consume) an objective (ob) to an agent (ag) act 2 pct0(ag) : RELEASE £ update program counter END Listing 4. Events modelling an agent consuming an objective EVENT agent release ANY ag, ob WHERE grd 1 ag ∈ dom(cons) £ take an agent that has consumed an objective grd 2 ob ∈ cons(ag) £ objective consumed by agent ag grd 3 pct0(ag) RELEASE THEN act 1 cons : cons \ {ag → ob} £ remove agent and its consumed objective act 2 pct0(ag) : CONSUME £ update program counter END Listing 5. Events modelling an agent releasing resources an objective a 0 a 1 · · · a n r 0 r 1 r 2 r 3 · · · r n ob 0 ob 1 ob 3 · · · ob n capture belongs Fig. 9. A visualisation of the (m 1 ) refinement model: agents are capturing free resources to fulfil an objective (a resource can belong to different objectives) inv 1 capt ∈ AGT → P(RES) £ a variable mapping agents to captured resources inv 2 objt ∈ AGT → OBJ £ variable mapping an agent to an objective it tries to fulfil . . . inv saf ∀ a 1 , a 2 · a 1 ∈ dom(capt) ∧ a 2 ∈ dom(capt) ∧ a1 a2 ⇒ capt(a1) ∩ capt(a2) ∅ Listing 6. Variables and invariants of the refinement step m 1 EVENT agent consume b ANY ag, rs £ agent (ag) and resource (rs) WHERE grd 1 ag ∈ dom(capt) £ take some agent (ag) from domain of variable captured grd 2 rs ∈ objr(objt(ag)) £ take a resource (rs) which is part of ag objective (objt(ag)) grd 3 rs ∈ union(ran(capt)) £ resource must not be captured by other agent grd 4 union(ran({ag} ¡ capt)) ∩ objr(objt(ag)) ∅ £ no resources from the objective can be captured grd 5 pct1(ag) CONSUME £ program counter of agent must be at CONSUME THEN act 1 capt(ag) : capt(ag) ∪ {rs} £ add resource (rs) to agent s captured set END Listing 7. The event modelling an agent consuming a free resource: loop body event The agent ag will also capture a resource rs only if none of the resources from its objective have been captured by other agents (guard grd 4 ). The guard grd 4 prevents a deadlock scenario in which agents with overlapping objectives are unable to complete their objective as remaining resources are captured by the other overlapping agent.
The loop completion event agent consume c (Listing 8) would be triggered as soon as the objective has been fulfilled (guard grd 1 in Listing 8) and program counter would be updated to new state-RELEASE (action act 1 in Listing 8). Similarly, in this refinement we transform agent release event according based on the event pattern presented. To show correctness of the extended model, we prove an invariant (inv saf in Listing 6) which states that no two agents can have the same resource captured.
EVENT agent consume c ANY ag WHERE grd 1 capt(ag) objr(objt(ag)) £ guard which checks wheter resource obective has been fulfilled grd 2 pct1(ag) CONSUME In this refinement step, we start to consider communication as we introduce protocol (described in Section 3) into the model. Because of backward unfolding style we introduce stage 2 part of the protocol first (sequence diagram shown in Fig. 10). At this stage of the protocol three types of messages are sent: lock and release by an agent and response message by a resource. In this refinement step, we apply communication modelling patterns described in Section IV.C of the paper [SIA+19]. First of all, machine m 2 is extended with three context models-separately defining each message type according to the generic message context pattern (response message context model shown in Listing 12). Then, by following machine communication modelling pattern we create variables lck, rsp and rel which represent communication channels of each message. In addition an agent's variable lcke is created to store already sent lck messages (shown in Listing 9).
In the stage 2 an agent tries to lock resources associated with negotiated distributed lane by sending lock messages. To model that, we apply loop modelling patterns and create two new events: agent lock b and agent lock c (Listings 10 and 11). Since, preceding protocol messages are modelled in the next refinements, we model lock message as a initiating message at this stage but later convert it to a reply event type. The first event is the body of a message sending loop which sends a new lock message (action act 1 in Listing 10) if a message lc has not been sent before (guard grd 1 ) and destination (resource) is within agent's objective (guard grd 3 ). The program counter of the agent must be in LOCK protocol phase (guard grd 4 ). An agent also saves a local copy of the sent message with the event action act 2 .
The second event in the loop pattern is a loop completion event agent lock c which detects the end of the loop and updates the program counter (Listings 11). For the lock message sending event-an agent must detect when all messages have been sent or in other words the objective has been fulfilled (guard grd 2 ).

EVENT agent lock b ANY
lc £ lc (lock) message which will be sent WHERE grd 1 lc ∈ LCK \ lck £ only a new lock message will be sent (lc message not already in the lck channel) grd 2 lckd(lc) ∈ lcke(lcks(lc)) grd 3 lckd(lc) ∈ objr(objt(lcks(lc))) £ a lock message is sent to a resource which belongs to agent s objective grd 4 pct2(lcks(lc)) LOCK £ lock message can only be sent by an agent with LOCK program status THEN act 1 lck : lck ∪ {lc} £ a new lock message is added to lock message channel act 2 lcke(lcks(lc)) : lcke(lcks(lc)) ∪ lckd(lc) £ message sending receipt is saved locally by an agent END This event simply updates the program counter to CONFIRMC state with the action (action act 1 ). According to the protocol, after sending all lock messages an agent will wait for replies before it proceeds to consuming resources.
In order to model a resource's response to the lock message first we created a read pointer variable rdpt to work as a resource lock for an agent. The resource lock is released once a resource receives a release message from an agent who locked the resource (see Listing 9). A resource sending a response message is a reply type message therefore we used a reply event modelling pattern (Listings 13 and 14). A resource sends response message when lock message has been received-guard grd 1 in both events. The following two guards (grd 4 and grd 5 ) define the source and destination of the new message which are respectively destination and source of received lock message.

CONTEXT
Listing 12: The context model of the resource response type message Lastly, the response message also carries a value and guards grd 6 define the value in both events. The message carries READY value if the resource is not locked by other agent (grd 3 in Listing 13) otherwise a DENY message is sent (grd 3 in Listing 14). In addition to sending a message, the resource response ready event also removes answered message and if READY message was sent resource locks itself for that agent with action act 3 .
EVENT resource response ready ANY lc, rs £ lock (lc) and response (rs messages) WHERE grd 1 lc ∈ lck £ a response READY message will be only sent if a lock message was was sent grd 2 rs ∈ RSP \ rsp £ only a previously not sent response READY message will be sent grd 3 rsps(rs) ∈ dom(rdpt) £ a response READY message is sent by a resource only if it is not locked grd 4 rsps(rs) lckd(lc) £ source of the response message is destination of received lock message grd 5 rspd(rs) lcks(lc) £ destination of the response message is source of received lock message grd 6 rspn(rs) READY £ response message contains READY value THEN act 1 rps : rsp ∪ {rs} £ response message is added (sent) to response channel act 2 lck : lck \ {lc} £ received and replied lock message is removed from the channel act 3 rdpt : rdpt ¡− {rsps(rs) → rspd(rs)} £ resource which sent READY response message is locked for the agent

END
Listing 13: The event modelling a resource sending a response message: READY type EVENT resource response deny ANY lc, rs WHERE grd 1 lc ∈ lck £ a response DENY message will be only sent if a lock message was was sent grd 2 rs ∈ RSP \ rsp grd 3 rsps(rs) ∈ dom(rdpt) £ a response DENY message is sent by a resource if it is locked grd 4 rsps(rs) lckd(lc) grd 5 rspd(rs) lcks(lc) grd 6 rspn(rs) DENY £ response message contains DENY value THEN act 1 rps : rsp ∪ {rs} rps : rsp ∪ {rs} £ response message is added (sent) to response channel act 2 lck : lck \ {lc} lck : lck \ {lc} £ received and replied lock message is removed from the channel END Listing 14: The event modelling a resource sending a response message: DENY type Once an agent sends all lock messages it must receive all response messages before it can progress. In the model, we created a new event agent decide (Listing 15) which checks the values of received response messages and selects the new program counter value. In principle this event is a loop completion event but in the model we decided to model decision events separately to reduce events complexity. The main difference from the basic loop completion event is that depending on conditions different program counter values can be selected. In agent decide event if all messages contained READY value (guard grd 2 ) then the event will update program counter to CONSUME. But if a DENY message (guard grd 3 ) was received program counter is changed to UNLOCK state. In the latter scenario an agent must then send release messages to resources, which sent READY messages and locked their resources, so protocol can progress.
For selecting correct message from the channel we use messages constant functions and a channel variable-[rsp ∩ rspd −1 [{ag}] selects all rsp messages which were sent to agent ag. Inserting the result to the rsps constant function we get sources (resources) of these messages. This message extraction guard pattern is used widely when relevant messages need to be selected. Events of the unlocking phase are modelled using reply communication pattern and hence not covered in this subsection. Once relevant resources are unlocked agent tries to lock them again in this refinement step.

INVARIANTS
SAF 1 ∀ a1, a2 · pct2(a1) CONSUME ∧ pct2(a2) CONSUME ∧ a1 a2 ⇒ objr(objt(a1)) ∩ objr(objt(a2)) ∅ Listing 16. The safety invariant for prohibiting mutual resource locking by different agents In this refinement step, which specifies stage 2 of the distributed protocol, we were required to prove invariant expressed in Listing 16. The safety invariant relates to the mutual exclusion safety protocol property SAF 1 specified in Fig. 3. The property requires proving that if any two agents are in the CONSUME state their objectives (set of resources) must not be overlapping. The Rodin platform has generated five proof obligations based from the SAF 1 invariant. Four out of five proof obligations were proved automatically, however, the safety invariant relating to SAF 1 property and agent decide event had to be proved interactively. The interactively discharged proof obligation is shown below, where the guards and invariant form the hypothesis of the proof obligation while the invariant modified by the agent decide event action is goal of the sequent.

Protocol Event-B model: machine m 3
In this refinement step we continue to unfold protocol backwards and introduce two new messages write and pready. In fact this refinement step can be thought as an intermediate step gluing protocol stages stage 1 and stage 2 (sequence diagram shown in Fig. 11). Events for capturing write message sending were developed using the initiating message pattern. Since they were structurally identical to the previous refinement events agent lock b and agent lock c events we do not discuss them here. The more interesting challenge of this refinement step was correctly capturing the pready message. A variable of type mem ∈ RES → P(AGT) was created to abstract queue like resource memories (see Listing 17) which are introduced in the next refinement step.
A resource sends pready message to inform an agent of its availability for consumption and that it can be locked now. There are two different cases when this message should be sent and instead of constructing a single event to cover all scenarios it was decided to create more trivial events for each of the cases. In the model we created a reply type resource write preready event which creates a new message and removes the answered message from the wrt channel if a resource is not locked. A pready message will be sent if a write message has been received and resource is not locked by an agent.
The second event resource release pready was necessary to cover a scenario where pready message was sent to an agent in response to its write message but in the end the agent was not able to lock all resources. This would mean that write messages have been removed and resource write preready guards would never be satisfied for that agent. Yet an agent would be still waiting to receive pready messages eventually. Therefore we introduced initiating message resource release pready event which sends a new pready message to any agent which is interested in that resource if a resource is not locked. The final refinement step m 4 introduces the remaining part of the protocol-stage 1 . This stage starts with an agent requesting a set of resources and finishes with agent forming a distributed lane by sending a write messages to the same resources. In between, an agent might need to send a special request message srequest if a distributed lane was not negotiated in the first attempt. To allow distributed lane forming-a resource memory introduced in the previous refinement now must be refined to queue-like data structure with corresponding variables (e.g. read pointer, promised pointer). To begin with we start with introducing communication channel variables for request, reply and srequest messages. In addition two local variables rqst and rqts were created to store messages on the agent side (shown in Listing 18). Following the loop and initiating message modelling patterns we introduced two events agent request b and agent request c for requesting resources (Listings 19 and 20).
grd 1 rq ∈ REQ \ req £ send a new request message grd 2 reqd(rq) ∈ rqst(reqs(rq)) grd 3 reqd(rq) ∈ objr(objt(reqs(rq))) £ request message destination (resource) must be part of the objective grd 4 pct4(reqs(rq)) REQUEST THEN act 1 req : req ∪ {rq} £ send a request message act 2 rqts(reqs(rq)) : rqts(reqs(rq)) ∪ {reqd(rq)} END  If an agent was not able to negotiate a distributed lane it must send a new, special message-srequest. This time instead of requesting an arbitrary index a new srequest message contains a desired index which is computed by adding a non-zero constant to the highest reply index. To send srequest messages we created two reply type events: agent renegotiate b and agent renegotiate c.
As a standard reply type event agent renegotiate b creates a new message and removes the answered reply message from the channel. Whereas agent renegotiate c event updates the program counter again to CONFIRMW state -this cycle repeats until a distributed lane is negotiated.
Lastly in this refinement we introduce distributed lane data structure and accordingly update relevant events. Two variables ppt and rpt are created to respectively represent promise pointer and read pointer of a resource. For each resource the promised pointer is initialised to zero and only two reply events resource reply general and resource reply special (Listing 23) modify a promised pointer variable. The first event simply increments the current ppt(r) value after reply message has been sent whereas the latter event updates the ppt(r) by computing action act 3 , where maximum function parameters are the current ppt(r) value and received srequest message value.
EVENT resource reply special ANY rp, rq £ reply message (rp) and special request message (rq) WHERE grd 1 rq ∈ rqs grd 2 rp ∈ REP \ rep grd 3 repd(rp) rqss(rq) grd 4 reps(rp) rqsd(rq) grd 5 repn(rp) max({ppt(reps(rp)), rqsn(rq)}) £ reply message value is a larger value between resources ppt value and value from received special request message THEN act 1 rep : rep ∪ {rp} act 2 rqs : rqs \ {rq} act 3 ppt(reps(rp)) : max({ppt(reps(rp)), rqsn(rq)}) + 1 £ update resource s promised pointer END Listing 23: The event modelling a resource replying to a srequest message Read pointers are updated by two events which send pready messages. In contrary to the previous variable the read pointer rpt(r) is always set to the minimum value of the request pool. This is necessary as some agent might negotiate a distributed lane with lower index than others but its write messages are delayed (or even lost) so the protocol would halt. Allowing agents with higher distributed lane indexes but sooner write message arriving to consume resources introduces fault-tolerance into the protocol. Guards of these two events were also strengthened to only send pready messages to newly incoming agents if their index is the lowest in the request pool.

INVARIANTS
his wr ∈ RES → N inv saf4 ∀ r, n 1 , n 2 · r ∈ RES ∧ n 1 , n 2 ∈ dom(his ppt (r)) ∧ n 1 < n 2 ⇒ his ppt (r)(n1) < his ppt (r)(n2) inv his ppt ∀ res · (his wr (res) 0 ∧ his ppt (res) ∅) ∨ (dom(his ppt (res)) 0 . . his wr (res) − 1 ∧ his ppt (res)(his wr (res) − 1) ppt(res) − 1) Listing 25. Additional variables and invariants added for provind safety property SAF 4 Proving SAF 3−4 Safety Properties. As shown in Section 3.2 (Scenarios 1 -2) high-level system requirements can only be met if an agent invariably and correctly forms a distributed lane. The probabilistic lane forming eventuality (LIV 3 ) is discussed in [SIK+20] while in the following paragraphs we describe proving requirements SAF 3−4 in the Event-B model. First of all, requirement SAF 3 (see Table 4) relates to SAF 2 (see Table 3) and is needed to ensure that that an agent is not allocated only a part of resources it has requested. In the model we ensure that SAF 3 requirement is satisfied by strengthening event guards which restrict enabling states of the event that generates an outgoing write message. To cross-check this implementation we add an invariant that directly shows that SAF 3 is maintained in the model (Listing 24).
In the following paragraphs we provide details on proving a slightly more interesting case of SAF 4 which assumes that SAF 3 property is proven. Requirement SAF 4 addresses potential cross-blocking deadlock scenarios described in Section 3.1 or a resource double locking due to distributed lane overriding. The strategy to proving the SAF 4 requirement is to formally prove that agents with intersecting objectives (at least one common resource) always form distributed lanes with differing indices. Based on a distributed lane definition (Definition 1 in Section 3.1) we could formally express the safety invariant as expression (1) which states if two different agents (a 1 , a 2 ) have formed a distributed lane (dl) over an intersecting set of resources (dom(dl(a m )) {r 0 , r 1 , ..r n }) then slot values s of their distributed lanes must be different.
∀ a 1 , a 2 · a 1 , a 2 ∈ AGENTS ∧ a 1 a 2 ∧ dom(dl(a 1 )) ∩ dom(dl(a 2 )) ∅ ⇒ ran(dl(a 1 )) ∩ ran(dl(a 2 )) ∅ Instead of directly including predicate (1) into the Event-B model and completing a complex interactive SAF 4 property proof, it was realised that property (1) can be expressed (and proved) as a simpler verification condition. Let's first assume that agents only form distributed lanes if all received indices are the same (proved as SAF 3 ). If the same resource is requested by different agents and they are replied with different promised pointer values, these promised pointer values (slots) will be distributed lane deciders as all other slots from remaining resources must be the same in order to form a distributed lane. Therefore, to prove that model preserves SAF 4 requirement it is enough to show that a resource always replies to a request or special request message with a unique promised pointer value. We can prove that a resource always replies with a unique promised pointer value by introducing a history variable into our model.
To prove this property we first extend our model with a variable his ppt and an entry variable his wr or time-stamp as shown in Listing 25. The former variable stores each resources chronological promised pointer updates and latter works as a write pointer for history variable. After introducing history variables, we updated two events resource reply {general, special} which update promised pointer variables (after sending reply messages) by adding two new actions act 4 and act 5 as shown in Listing 26 (identical extension for resource reply special event).
Action act 4 updates a history variable for a resource res with the current write stamp and promised pointer (ppt(res)) value sent. The next action act 5 simply updates the resource's write stamp. We can then add the main invariant to prove (inv saf4 in Listing 25) which states that if we take any two entries n1, n2 of the history variable for the same resource where one is larger, then that larger entry should have larger promised pointer value.
To prove that resource reply {general, special} preserve inv saf4 , the following properties play the key role: (1) the domain of his ppt (i.e., 'indices' of his ppt ) is {0, . . . , his wr − 1}, (2) his ppt (his wr − 1) < his ppt (his wr ). Property (2) holds because his ppt (his wr ) is the maximum of promised pointer (ppt) and special request slot number and promised pointer is incremented as resource reply {general, special} occurs. We also specified these properties as an invariant (inv his ppt ) and proved they are preserved by the events which helped to prove inv saf 4 . Proof statistics. In Table 5 we provide an overall proof statistics of the Event-B protocol model which may be used as a metric for models complexity. The majority of the generated proof obligations were automatically discharged with available solvers and even a large fraction of interactive proofs required minimum number of steps. We believe that a high proof automation was due to modelling patterns [SIA+19] use and the SMT-based verification support [ISAYR16,DFGV14].

Conclusions and future work
In this paper, we demonstrated how a previously proposed formal development methodology of distributed systems can be used to developing a distributed signalling system protocol. Starting only with high-level system requirements, we developed an early formal protocol prototype model, which with the help of ProB model checker was refined as subtle deadlock scenarios were discovered. Because of the stepwise modelling principle and our refinement strategy, re-modelling efforts were significantly reduced as only a part of the complete functional Event-B model needed to be reworked. For example, issues discovered in the stage 1 of the distributed protocol only affected final refinement step m 4 and so machine models m 0..3 and associated (completed) proofs were preserved. The stepwise distributed protocol development, as also shown before [CM06,HKBA09,ILTR11], together with adequate tools [ISAYR16,DFGV14] helped to achieve fairly high verification automation. The final protocol model was formally proved to guarantee a safe and deadlock free distributed signalling operation. We demonstrated this by expressing and deductively proving invariants which stated that a distributed lane would be correctly and eventually formed by an agent. An alternative deadlock-freedom proving strategy would have been proving a deadlock freedom proof obligation (page 5 DLK [Hoa14]) which was considered in our work. The resulting proof obligation results in a complex proof obligation to be discharged in the Rodin platform.
In this work, we have also demonstrated that the previously developed communication modelling patterns [SIA+19] can model a variety of message sending/receiving scenarios, and therefore, provide a more systematic communication modelling method. On the other hand, the proposed formal development methodology does not provide a systematic process to refine the generic communication-based signalling model. Formalising refinement steps would fully utilise the benefits of the Event-B stepwise modelling and further reduce modelling and verification effort.
We believe that the future work of defining refinement patterns can be built around some initial refinement ideas in our paper [SIA+19]. Furthermore, the modelling effort with our methodology could be significantly reduced by providing an automatic refinement of communication models from a high-level protocol specification, for example, sequence diagrams, which are a widely used method to specify protocols in the railway industry. Another important direction we would like to explore in the future work is protocol's viability to be deployed in practice. At the moment the distributed resource allocation protocol solves railway resource allocation problem at a high abstraction level and in the future work the protocol model should be refined to consider other railway signalling elements such as switches, signals and routes as in [HP00]. The refined version of the protocol would also need to solve another type of deadlock scenario which would occur once railway routes are introduced into the model. Specifically, the head-to-head deadlock scenario, which can occur when two trains cannot progress as each train is preventing the other one from locking the next set of resources (example discussed in Section 7.1.4 of [GH21]). In the future work we could address this issue by extending the protocol to specify how objectives are formed and selected. Finally, in the future work, we would like to prototype a physical distributed signalling system with the extended distributed resource allocation protocol could be implemented by using, for example the CLEARSY Safety Platform [LDFO20] as suggested in paper [Pro16].