Membership-based Manoeuvre Negotiation in Autonomous and Safety-critical Vehicular Systems

A fault-tolerant negotiation-based intersection crossing protocol is presented. Rigorous analytic proofs are used for demonstrating the correctness and fault-tolerance properties. Experimental results validate the correctness proof via detailed computer simulations and provide a preliminary evaluation of the system performances. The results are compared to the ones that can be achieved via a risk estimator with and without combining the proposed protocol. Our fault model considers packet-loss, noisy sensory information and malicious driving. Our preliminary results show a reduction in the number of dangerous situations and vehicle collisions.


Thread Homeostasis: Real-Time Anomalous Behavior Detection for Safety-Critical Software

Safety-critical systems must always have predictable and reliable behavi...

Towards Formal Verification of HotStuff-based Byzantine Fault Tolerant Consensus in Agda: Extended Version

LibraBFT is a Byzantine Fault Tolerant (BFT) consensus protocol based on...

Actuator Fault-Tolerant Vehicle Motion Control: A Survey

The advent of automated vehicles operating at SAE levels 4 and 5 poses h...

Proof of Compositionality of CFT Correctness

In the paper Compositionality of Component Fault Trees, we present a dis...

Mistakes of A Popular Protocol Calculating Private Set Intersection and Union Cardinality and Its Corrections

In 2012, De Cristofaro et al. proposed a protocol to calculate the Priva...

Online Adaptive Fault Tolerant based Feedback Control Scheduling Algorithm for Multiprocessor Embedded Systems

Since some years ago, use of Feedback Control Scheduling Algorithm (FCSA...

ASYMP: Fault-tolerant Mining of Massive Graphs

We present ASYMP, a distributed graph processing system developed for th...

1 Algorithms

The time constants used in the proposed algorithms are provided in Table 1.1. The following internal size order is implied: and .

Period of membership protocol
Period of agent registry update
Upper bound on transmission delay between vehicles
Upper bound on manoeuvre execution time
Table 1.1: Time constants used in Algorithm 2 and 3. Observe that we assume that and .
1 Structures:
  // positions: start, end
  // timestamp, position, velocity, acceleration
  // agent ID, AgentState structure
  // timestamp, MO flag, IDs of agents in the membership
2 Constants:
3 : the segment ID;
  // Segment registry
4 Variables:
  // Membership registry
6 Interfaces:
7 : read current time;
8 : read Segment registry for segment from the storage service;
9 : read all Agent Registries for segment from the storage service;
10 : write (Membership registry) for agent on the storage service;
11 : uses (Section 0.11.4) to obtain the sets of agents with whom the agent identified by may cause a priority violation for the different possible turns defined by . We assume that this set includes all the agents of higher priority than that could possibly arrive to the intersection by the time ;
12 : obtain the set of agents that will be within communication range from the agent identified by until . ;
13 : obtain a list of possible turns for an agent;
15 do forever (once in every time units) begin
16        let ;
17        foreach  in  do
18               if   then
19                      let ;
20                      let ;
21                      let ;
22                      foreach  in  do
23                             let ;
24                             if   then else ;
26                      ;
Algorithm 2 The membership algorithm.

Data types: Structures: ;

  // timestamp, position, velocity, acceleration ;
  // agent ID, AgentState structure ;
  // timestamp, agent ID, intended turn ;
  // timestamp, MO flag, set of agent IDs ;
  // agent ID,timestamp,message type,message data Constants: : a hard-coded agent identifier  Variables: ;
  // Agent registry ;
  // Membership registry, set of Memberships ;
  // Unique tag for each manoeuvre ;
  // ID of the agent with an active GRANT ;
  // Set of received messages ;
  // Set of destination agent IDs ;
  // Set of expected response agent IDs ;
  // Timer for keeping track of when to next try starting a new request round  Interfaces:: read current time  : read current agent position  : read current agent velocity  : read current agent acceleration  : start named for time units  : stop named : write an registry to the storage service   : read from the storage service the for agent : execute the manoeuvre by setting the intention to go  : check if the agent specified in have sufficient time to cross the intersection without violating the priority of the ego vehicle, see Section 0.11.5: returns if , otherwise  : returns if has an on going request and that request has the priority over the request of message , eg having an earlier time stamp, or if equal, lower agent ID.: returns when the agent ’s location is known to be outside the boundaries and heading out from the intersection.  : Notify the risk estimator about priority changes of either a grant of agent or the revoke of a grant 
Figure 1.1: Structures, variables and interfaces for the manoeuvre negotiation protocol
1 do forever (once in every time units) begin
2        ;
3        ;
4        ;
5        ;
6        if  then // All expected answers received
                // No need for a retry
7               if  then  ; ;
8              else  {; multicast to ; ;};
10       if   then
               multicast to ;
                // Explicit release
11               ; ;
12       if grantID  then
13               ; ;
14               if  then ; ;
15               else if  then ;
19procedure begin
20        if  then  ;
21        if  then
22               let ;
23               ;
24               if  then
25                      ;
26                      multicast to ;
27                      ;
29               else ;
31        else if  then ;
34upon timer expires begin
35        if  then
36               ; multicast to ; ;
37       ;
40upon message received at time begin
41        if   then // Message is timely
42               if   then  ;
43               else if   then
44                      if   then
45                             if   then ;
46                             else if   then
47                                    ;
48                                    if  then multicast to ;
49                                    ;
51                            ; send to ;
53                      else send to ;
55               else if  then
56                      ;  ;
57                      if  then ;
58                      if  then  ; ;
Algorithm 3 The Manoeuvre Negotiation protocol

1.1 Algorithm description

This section provides a line by line description of the Membership Algorithm (Algorithm 2) and Manoeuvre Negotiation Algorithm (Algorithm 3).

1.1.1 Description of the Membership Algorithm

The Membership Algorithm (Algorithm 2) periodically updates the membership set for every vehicle in a specified geographical section called a segment. A membership set holds multiple memberships. A membership in the membership set for a vehicle consists of a set called Safety Membership () made up of the IDs of all other vehicles of higher priority in the same segment of the road, a flag called Manoeuvre Opportunity () that indicates whether or not the membership is valid, and a time stamp. There has to be one membership per manoeuvre can perform in the segment since traffic priorities are manoeuvre-based and we want the protocol to preserve the initial traffic priorities if possible. The segment in this case is a 4-way intersection. The possible manoeuvres therefore correspond to turning left, going straight, and turning right.

The Membership Algorithm provides a periodic update of memberships every time units (line 2). The procedure starts by retrieving all agent registries of the vehicles in the selected segment from a storage server (line 2). The algorithm iterates through these agent registers and for each agent checks if is still in the section (line 2). If so, the algorithm calculates which agents have higher priority than and may reach the intersection in the time it would take for to reach and perform a manoeuvre through the same intersection (line 2)xixixiFor more details see Section 0.11.4. will have 3 entries for the 3 possible manoeuvres described above. In addition to , the set of all vehicles that are within communication distance from are determined (line 2). The earliest time stamps of the agent states in for each specific turn are also determined (line 2). These time stamps will be used as a measure of how current the memberships are. A far back in time indicates that the membership was calculated using old data and that the membership may be too old to be used safely.

The next step is to determine the value of the s for the manoeuvre specific memberships. is set to if and only if all agents in are also in (line 2), which implies that all agents that can cause a priority violation for are also reachable by . It’s also possible to use the -flag to indicate that the provided memberships are invalid due to, for example, limited capacity of the membership service.

The value assigned to depends on the value of . is assigned the value of for the specific manoeuvre described by if , and is assigned the empty set if (line 2). The use of thereby provides a way to both reduce the number of sent messages – since vehicles will not send a request if – and a way to indicate if an empty membership is valid.

Finally, all memberships in the membership set are stored on the storage server accessible by all agents (line 2).

1.1.2 Description of the Manoeuvre Negotiation Algorithm

The Manoeuvre Negotiation Algorithm (Algorithm 3) consists of four main components: the core state-update procedure that is called periodically (lines 3 to 3), a procedure that is called when an agent seeks permission to perform a manoeuvre (lines 3 to 3), a timer-triggered procedure used to ensure algorithm progression in the event of network failures (lines 3 to 3), and a message processing procedure(lines 3 to 3).

The state-update procedure itself has four main parts, the first of which handles communication with the storage server. Every vehicle in our system measures their current position, heading, velocity, and acceleration every time units (line 3) and then stores that information on the storage server (line 3). This vehicle information is used by the membership service to calculate memberships in Algorithm 2. Every vehicle also fetches the latest version of their membership set from the storage server and stores it locally (line 3).

The second part of the procedure determines if a vehicle that is requesting a permission to perform a manoeuvre – a requester – has been fully granted. Replies from vehicles that are not a part of the intersection between the membership that was valid when the request was initiated () and the current membership () are filtered out from the set of received replies (line 3). Vehicles that in but not must have already left the intersection, so their replies are considered irrelevant. Vehicles that are in but not are considered too far away to have any impact on the requested manoeuvre. Vehicles in neither set are also either too far away, or have at most equal priority to the requester and therefore should not be allowed to affect the decision process.

Next, the requesters – having the status – confirm that all expected replies to the sent request have arrived by calling (line 3). If all expected replies have arrived then the is stopped to mark the end of the current request round (line 3). In order to assess if the requester is fully granted, is searched for any replies and, if none are found, the requester changes status to and is thereby free to enter the intersection (line 3). Otherwise the requester will send a message to all vehicles in telling them to stop considering the requester granted and the timer will be started again to continue the request into a new round (line 3).

The third part of the procedure determines when a fully granted vehicle should release its grant. A fully granted agent – having status – will use their measured position and knowledge regarding the intersection’s geometry to determine if it has left the intersection (line 3) and should therefore send a of the grant to every vehicle in (line 3). The agent will then return to status and call to also inform the RE about the revoked grant (line 3).

The last part of the state-update procedure handles implicit release of a grant which enables a grant to be released even when the explicit release message is lost. An agent that is currently granting another agent, having status or , checks if the latest measured position of the granted agent lies outside and is heading away from the intersection (line 3). If the condition is then the agent notifies the RE about the priority change by calling and clears (3). An agent previously prevented from starting a request round, denoted by having status , takes on status and calls to try to start a new request round (line 3). An agent with status instead goes back to status (line 3).

The request initiating procedure is invoked when starting a new round of a requests. During the first round of a request, where the vehicle has status or , the procedure generates an identification tag for the request, then stores: the time stamp of when the first request round started, the ID of the requester, and the manoeuvre the requester wants to perform (line 3). Requesters that are not currently granting another agent, having status or , proceed to measure their current agent state and fetch the latest membership from the storage server (line 3).

Starting a request round further requires a valid membership, implying that the membership is based on data no older than time units and with a (line 3). If the membership is valid, then the state variables , , and will be assigned the values , , and respectively, where is the set of agents that are expected to reply and the status is changed to (line 3). A request is then sent to all agents in along with the request tag. The timer is set to to limit the duration of the request round (line 3). An agent without a valid membership will wait for a new membership from the membership server by starting the timer and try starting a request round at a later point in time 3. A potential requester that is currently granting another agent, having status , is not allowed to start a request round until the grant is released, but a status change to is made to signify that the agent wants to send out a request later when it is allowed (line 3).

Upon expiry of the timer, an agent currently in a request round, having status , will end it by sending a to all agents in , changing its status to and starting the timer again (line 3 and 3). The agent did not get all expected replies in the set time frame and must therefore stop the current round to avoid deadlocks. If the timer expires for an agent without an ongoing request round, having status , then the agent will try to start a new request round by calling the procedure (line 3).

The final part of the Manoeuvre Negotiating algorithm determines how incoming messages are processed depending on the agent’s current status and the agent state of the sender. Messages sent more than time units ago are discarded in order to avoid messages from previous request rounds interfering with the current round (line 3).

The first type of messages that are processed are request replies on the form
and . Any requester will store these messages in the set and remove the sender ID from the set of agents whose expected responses have not yet arrived, , (line 3).

The second message type that is processed is which symbolises a permission request (line 3). The receivers have to decide if the request should be granted or denied. Firstly, a call to determines if the sender can, while following normal driving patterns, cross the intersection without blocking the receiver (line 3). In addition to the non-blocking criteria, the receiver has to check its own status to see if it allows the agent to grant the sender.

Status and imply that the agent does not have an active request round and is therefore allowed to grant another agent (line 3).

Agents with status or are currently holding a grant for another agent. If this is the same agent as the sender then the receiver is allowed to reply with a (line 3).

The last status that allows the receiver to reply with a grant occurs where the receiver both has status – meaning that it has an active request round – and the sender has higher priority than the receiver – determined by a call to the interface (line 3). The interface will return if either the sender’s request was started before the receiver’s request or if they were started concurrently and the sender’s ID is lower than the receiver’s.

A receiver fulfilling both the non-blocking and status criteria will store the ID of the granted agent if it has not yet done so, and change its status to either – if it has status – or to – if it has status or (lines 3, 3, and 3). Changing from status or to also implies both that the timer has to be stopped and that any ongoing round must be stopped by sending a to all agents in , since an agent in is not allowed to either start or have an ongoing request round (lines 3 and 3). The risk estimator is then notified with that the priorities have changed and a reply is sent to the request sender (line 3). If these criteria are not fulfilled, a is sent in reply (line 3).

The last type of messages to be processed are messages. An agent with status or that receives a release message from the holder of the grant will call to inform the risk estimator of the expiry of the granted vehicle’s higher priority (3). A agent will return to status while a agent switches to status and calls in order to try to start a request round (line 3 to 3).

1.2 Correctness Proof

By the stature of Algorithm 3, we can observe the correctness of Corollary 1.1.

Corollary 1.1

Let be an execution of the proposed solution. At any system state, it holds that , where is a predicate that represents the fact that timer has been started (by the function ), and has not stopped (by the function ) or expired without triggering the event bounded to timer . Furthermore, an active timer expires within time units.

Lemma 1.2 (Membership)

Let be a synchronous execution of algorithms 2 and 3. Requirement 0.1 holds throughout .

Proof. To prove that Requirement 0.1 holds throughout it needs to be shown that a fresh membership of an agent with contains all agents that could potentially cause a priority violation with from the current time until . We say that a membership is valid if this property holds for the membership. We refer to all other memberships as non-valid. It needs to be proven that, when is the timestamp bound to (line 2), can only be non-valid if or is no longer fresh, i.e., .

Algorithm 2 (lines 2 to 2) defines the procedure in which memberships are created and stored. We review this procedure and show its key properties.

Algorithm 2 considers all potential priority violations.   The procedure calls
to determine all agents that have higher priority than and that could potentially reach the intersection at some point from to (line 2). These agents are the ones that could potentially lead to a priority violation with according to our definition in Section 0.11.3.

Algorithm 2 assigns correct values.   For a given turn, the membership is assigned the set if, and only if, is assigned the value , otherwise is assigned the empty set (line 2). The variable thereby distinguishes a valid empty membership set from a non-valid empty membership set.

Algorithm 2 assigns correct time stamps.   The time stamp associated with a membership is assigned the value of the earliest time stamp of the agents in (line 2). This implies that a fresh membership is valid from to where due to the freshness of . This proves Requirement 0.1 since we assume that vehicles do not drive backwards on highways.

Theorem 1.3 (Safety)

Let be an execution of algorithms 2 and 3 that is not necessarily synchronous in which Requirement 0.3 holds throughout. Requirements 0.20.3, and 0.5 hold throughout .


  1. Requirement 0.2:   By the structure of Algorithm 3, we can observe that an agent that aims to perform a manoeuvre, has to call (line 3) and be granted a permission before reaching the status . In detail, is the only interface procedure for agent , which includes lines 3 to 3 in which requests are sent. By line 3, we see that sends such a request only when (i) its membership is fresh and (ii) there is an positive indication for a manoeuvre opportunity. Otherwise, checks conditions (i) to (iii) after time units (line 3). Thus, Requirement 0.2 is fulfilled.

  2. Requirement 0.3:  

    Algorithm 3 defines how a message is sent (lines 3 to 3) and received (line 3 to 3). We note that sends a message only if the if-statement condition at line 3, i.e., which implies that the first assumption of Requirement 0.3 holds. To show that the second assumption holds, we note that processes a request message from at a time only when its delivery is timely (line 3). Thus, we only need to prove that a request sent by a requester at a time to a requestee in ’s membership is replied to with a if, and only if, at a time when the request is delivered to , and is in one of the states presented in the cases (i) to (iii) described in Requirement 0.3.

    From line  3 we observe that is a mandatory condition for a request to be granted. From line 3, we can also observe that if (a) has status or , (b) ’s status is and the granted agent is , or (c) ’s status is and has higher priority according to , then will send a and call (line  3). Moreover, reply with a if is in a state different from cases (a) to (c) or if (line 3). The cases (a) to (c) indeed correspond to (i) to (iii), which Requirement 0.3 defines. Since the lines 3 and 3 are the only locations in the algorithm where a or is sent, Requirement 0.3 is satisfied.

  3. Requirement 0.4:  

    From Algorithm 3 we see that a message is sent to all agents in only on the lines 3, 3, 3, and 3. We need to show that these lines are reached if, and only if, any of the cases (i) to (iv) presented in Requirement 0.4 hold. We further need to show that is only called when an agent receives a from another agent and is currently holding a grant for or when is in state and has left the intersection.

    To reach and execute line 3, the requesting agent (with status ) needs to receive replies before the time , where is the time when ’s request was sent, otherwise the timer will expire before the if-state condition on line 3 evaluates to . The agent ’s timer will be stopped immediately after discover that all needed replies have arrived to stop the timer from interfering (line 3). Furthermore, any received message before time from another agent will be stored by (line 3). However, ’s will only be kept if ), where is ’s current membership (line 3). The agent will then execute line 3 since ’s (line 3). This case correspond exactly to case (i).

    If not all messages arrive before time , then the timer set by when sending the request (line 3) expires and will execute line 3. The agent will then reach and execute line 3 since has status . This corresponds to case (ii). An agent cannot reach line 3 in any other way since all other cases in which starts the timer (lines 3, 3, and 3) the agent will have status .

    To execute line 3, agent ’s status has to be and has to have left the intersection so that evaluates to (line 3). This correspond to case (iii).

    The last line in which a can be sent, line 3, can be reached only if an agent has status when receiving a message from another agent and if , and (lines 3, 3, 3, and 3). This corresponds to case (iv).

    We consider the case in which agent has the status and holding a grant for while receiving a message from . In this case, calls (line 3). The only other line where
    is called is line 3. This line can only be reached if an agent has status and if evaluates to (line 3). Requirement 0.4 is thus satisfied.

  4. Requirement 0.5:   Note that does not remove messages that are needed (such as in line 3). By line 3 to 3 and the definition of the function in Figure 1.1, agent does not change its status to before it receives all the needed responses. This change to depends on the absence of a response that includes a , i.e., the case of being fully-granted. Otherwise, changes to , sends a release message to all agents in and restarts the request process after time units.

Theorem 1.4 (Progression)

Let be a synchronous execution of algorithms 2 and 3 in which admissible crossing opportunities occur infinitely often (for every direction of the intersection). Requirement 0.6 holds throughout .

Proof. Let be an agent that is the closest to the intersection from its direction and that aims at crossing the intersection, i.e., it calls (line 3). By lines 3 and 3, immediately after the execution of , the state of cannot be in . This proof shows that the states , , and must lead to before returning to the state by demonstrating that indeed reaches the status and crosses the intersection.

Without loss of generality, suppose that is an execution in which ’s status is not in , during the first system state of . Moreover, suppose that immediately after ’s starting system state, we have a period of time units in which has an admissible crossing opportunity, where . Generality is not lost due to the statement in the beginning of this proof and because Requirement 0.6’s assumptions, which means that an admissible crossing opportunity for always occurs eventually (within a finite period).

The rest of the proof considers ’s status in ’s starting system state, which can be one of , , and , and shows that it indeed reaches status .

  • Suppose that .   Note that the do forever loop (line 3) of Algorithm 3 starts a new iteration once in every time units. Therefore, within time units, agent executes line 3. Once that occurs, the if-statement condition in line 3 holds, due to the assumption of this case that the status of is , the definition of the function (Figure 1.1) and the assumption that during the