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

1 Algorithms

The time constants used in the proposed algorithms are provided in Table 1.1. The following internal size order is implied: $T_{M a n} > T_{D} \geq T_{A}$ and $T_{M} > T_{A}$ .

$T_{M}$	Period of membership protocol
$T_{A}$	Period of agent registry update
$T_{D}$	Upper bound on transmission delay between vehicles
$T_{M a n}$	Upper bound on manoeuvre execution time

Table 1.1: Time constants used in Algorithm 2 and 3. Observe that we assume that

T_{M a n} > T_{D} \geq T_{A}

and

T_{M} > T_{A}

1 Structures:

S e g m e n t = (x s, x e)

;

// positions: start, end

A g e n t S t a t e = (t a, x, v, a)

;

// timestamp, position, velocity, acceleration

A g e n t = (a I D, A S)

;

// agent ID, AgentState structure

M e m b e r s h i p = (t m, M O, S M)

;

// timestamp, MO flag,

S M

IDs of agents in the membership

2 Constants:

s I D

: the segment ID;

S := g e t S e g m e n t D a t a (s I D)

;

// Segment registry

4 Variables:

M R \leftarrow \emptyset

;

// Membership registry

6 Interfaces:

c l o c k ()

: read current time;

g e t S e g m e n t D a t a (s I D)

: read Segment registry for segment

s I D

from the storage service;

g e t A R S e t (s I D)

: read all Agent Registries for segment

s I D

from the storage service;

s t o r e M R (a I D, M R)

: write

M R

(Membership registry) for agent

a I D

on the storage service;

g e t H i g h e r P r i o r i t y A g e n t s (A R, t)

: uses

n o P r i o r i t y V i o l a t i o n S t r i c t

(Section 0.11.4) to obtain the sets of agents with whom the agent

a I D

identified by

A R

may cause a priority violation for the different possible turns defined by

g e t P o s s i b l e T u r n s (A R)

. We assume that this set includes all the agents of higher priority than

a I D

that could possibly arrive to the intersection by the time

t

;

g e t R e a c h a b l e A g e n t s (A R, t)

: obtain the set of agents that will be within communication range from the agent identified by

A R

until

t

. ;

g e t P o s s i b l e T u r n s (A R)

: obtain a list of possible turns for an agent;

15 do forever (once in every

T_{M}

time units) begin

16 let

A = g e t A R S e t (s I D ())

;

17 foreach $A R$ in $A$ do

18 if $A R . A S . x > S . x s \land A R . A S . x < S . x e$ then

19 let

t = c l o c k ()

;

20 let

U = g e t H i g h e r P r i o r i t y A g e n t s (A R, t + 2 T_{M} + 2 T_{D} + T_{M A N})

;

21 let

R = g e t R e a c h a b l e A g e n t s (A R, t + 2 T_{M} + 2 T_{D} + T_{M A N})

;

22 foreach $t u r n$ in $g e t P o s s i b l e T u r n s (A R)$ do

23 let

t_{m i n} = m i n (α . A S . t a : (α \in A) \land (α . a I D \in U [t u r n]))

;

24 if $U [t u r n] \subset R$ then

M R [t u r n] \leftarrow (t_{m i n}, T r u e, U)

else

M R [t u r n] \leftarrow (t_{m i n}, F a l s e, \emptyset)

;

s t o r e M R (A R . a I D, M R)

;

Algorithm 2 The membership algorithm.

Data types: $M e s s a g e T y p e \in {G E T, D E N Y, G R A N T, R E L E A S E}$ $S t a t u s T y p e \in {N O R M A L, G E T, G R A N T, T R Y G E T, G R A N T G E T, E X E C U T E}$ Structures: $A g e n t S t a t e = (t a, x, v, a)$ ;

// timestamp, position, velocity, acceleration

A g e n t = (a I D, A S)

;

// agent ID, AgentState structure

A g e n t T a g = (t s, a I D, t u r n)

;

// timestamp, agent ID, intended turn

M e m b e r s h i p = (t m, M O, S M)

;

// timestamp, MO flag,

S M

set of agent IDs

M e s s a g e = (s e n d e r I D, t, t y p e, (d a t a))

;

// agent ID,timestamp,message type,message data Constants:

a I D

: a hard-coded agent identifier Variables:

A R \leftarrow \emptyset

;

// Agent registry

M R \leftarrow \emptyset

;

// Membership registry, set of Memberships

s t a t u s \leftarrow N O R M A L

t a g \leftarrow ⊥

;

// Unique tag for each manoeuvre

g r a n t I D \leftarrow ⊥

;

// ID of the agent with an active GRANT

M \leftarrow \emptyset

;

// Set of received messages

D \leftarrow \emptyset

;

// Set of destination agent IDs

R \leftarrow \emptyset

;

// Set of expected response agent IDs

t R E T R Y

;

// Timer for keeping track of when to next try starting a new request round Interfaces:

c l o c k ()

: read current time

p o s i t i o n ()

: read current agent position

v e l o c i t y ()

: read current agent velocity

a c c e l e r a t i o n ()

: read current agent acceleration

s t a r t T i m e r (t i m e r, d e l a y)

: start named

t i m e r

for

d e l a y

time units

s t o p T i m e r (t i m e r)

: stop named

t i m e r

s t o r e A R (A R)

: write an

A R

registry to the storage service

g e t M R (a I D)

: read from the storage service the

M R

for agent

a I D

d o M a n o e u v r e

: execute the manoeuvre by setting the intention to go

n o P r i o r i t y V i o l a t i o n D y n a m i c (A R, t u r n)

: check if the agent specified in

A R

have sufficient time to cross the intersection without violating the priority of the ego vehicle, see Section 0.11.5

l a s t ()

: returns

T r u e

R \cap D \cap M R . S M = \emptyset

F a l s e

otherwise

m y P r i o r i t y (m)

: returns

T r u e

p_{a I D}

has an on going request and that request has the priority over the request of message

m

, eg having an earlier time stamp, or if equal, lower agent ID.

h a s L e f t C r i t i c a l S e c t i o n (a I D)

: returns

T r u e

when the agent

p_{a I D}

’s location is known to be outside the boundaries and heading out from the intersection.

n t f y E s t i m a t (g r a n t, a I D / r e v o k e)

: Notify the risk estimator about priority changes of either a grant of agent

a I D

or the revoke of a grant

Figure 1.1: Structures, variables and interfaces for the manoeuvre negotiation protocol

1 do forever (once in every

T_{A}

time units) begin

A R \leftarrow (a I D, (c l o c k (), p o s i t i o n (), v e l o c i t y (), a c c e l e r a t i o n ()))

;

s t o r e A R (A R)

;

M R \leftarrow g e t M R (a I D)

;

M \leftarrow {m \in M : m . s e n d e r I D \in (D \cap M R . S M)}

;

6 if $s t a t u s = G E T \land l a s t ()$ then // All expected answers received

s t o p T i m e r (t R E T R Y)

;

// No need for a retry

7 if $\exists̸ m \in M : m . t y p e = D E N Y$ then

s t a t u s \leftarrow E X E C U T E

;

n t f y E s t i m a t (g r a n t)

;

8 else {

s t a t u s \leftarrow T R Y G E T

; multicast

⟨ a I D, c l o c k (), R E L E A S E, (A R, t a g) ⟩

D

;

s t a r t T i m e r (t R E T R Y, T_{A})

;};

10 if $s t a t u s = E X E C U T E \land h a s L e f t C r i t i c a l S e c t i o n (a I D, M R . S M)$ then

multicast

⟨ a I D, c l o c k (), R E L E A S E, (A R, t a g) ⟩

D

;

// Explicit release

s t a t u s \leftarrow N O R M A L

;

n t f y E s t i m a t (r e v o k e)

;

12 if $s t a t u s \in G R A N T, G R A N T G E T \land h a s L e f t C r i t i c a l S e c t i o n ($ grantID $, M R . S M)$ then

n t f y E s t i m a t (r e v o k e)

;

g r a n t I D \leftarrow ⊥

;

14 if $s t a t u s = G R A N T G E T$ then

s t a t u s \leftarrow T R Y G E T

;

t r y M a n o e u v r e (t a g . t u r n)

;

15 else if $s t a t u s = G R A N T$ then

s t a t u s \leftarrow N O R M A L

;

19procedure

t r y M a n o e u v r e (t u r n)

begin

20 if $s t a t u s \in {N O R M A L, G R A N T}$ then

t a g \leftarrow (c l o c k (), a I D, t u r n)

;

21 if $s t a t u s \in {N O R M A L, T R Y G E T}$ then

22 let

t s = c l o c k ()

;

(s t a t u s, A R, M R) \leftarrow (T R Y G E T, (a I D, (t s, p o s i t i o n (), v e l o c i t y (), a c c e l e r a t i o n ()), g e t M R (a I D) [t u r n])

;

24 if $(t s < M R . t m + 2 T_{M} \land M R . M O)$ then

(M, D, R, s t a t u s) \leftarrow (⊥, M R . S M, M R . S M, G E T)

;

26 multicast

⟨ a I D, t s, G E T, (A R, t a g) ⟩

D

;

s t a r t T i m e r (t R E T R Y, 2 T_{D})

;

29 else

s t a r t T i m e r (t R E T R Y, T_{A})

;

31 else if $s t a t u s = G R A N T$ then

s t a t u s \leftarrow G R A N T G E T

;

34upon timer

t R E T R Y

expires begin

35 if $s t a t u s = G E T$ then

s t a t u s \leftarrow T R Y G E T

; multicast

⟨ a I D, c l o c k (), R E L E A S E, (A R, t a g) ⟩

D

;

s t a r t T i m e r (t R E T R Y, 2 T_{D})

;

t r y M a n o e u v r e (t a g . t u r n)

;

40upon message

m

received at time

t r

begin

41 if $t r - m . t \leq T_{D}$ then // Message is timely

42 if $m . t y p e \in {G R A N T, D E N Y} \land s t a t u s = G E T$ then

(M, R) \leftarrow (M \cup {m}, R ∖ {m . A R . a I D})

;

43 else if $m . t y p e = G E T$ then

44 if $n o P r i o r i t y V i o l a t i o n D y n a m i c (r e q u e s t e e, m . A R) \land (s t a t u s \in {N O R M A L, T R Y G E T} \lor (s t a t u s \in {G R A N T, G R A N T G E T} \land g r a n t I D = m . A R . a I D) \lor (s t a t u s = G E T \land \neg m y P r i o r i t y (m)))$ then

45 if $s t a t u s = N O R M A L$ then

(s t a t u s, g r a n t I D) \leftarrow (G R A N T, m . A R . a I D)

;

46 else if $s t a t u s \in {G E T, T R Y G E T}$ then

s t o p T i m e r (t R E T R Y)

;

48 if $s t a t u s = G E T$ then multicast

⟨ a I D, c l o c k (), R E L E A S E, (A R, t a g) ⟩

D

;

(s t a t u s, g r a n t I D) \leftarrow (G R A N T G E T, m . A R . a I D)

;

n t f y E s t i m a t (g r a n t, m . A R . a I D)

; send

⟨ a I D, t r, G R A N T, ⊥ ⟩

m . A R . a I D

;

53 else send

⟨ a I D, t r, D E N Y, ⊥ ⟩

m . A R . a I D

;

55 else if $m . t y p e = R E L E A S E \land s t a t u s \in {G R A N T, G R A N T G E T} \land g r a n t I D = m . A R . a I D$ then

n t f y E s t i m a t (r e v o k e)

;

g r a n t I D \leftarrow ⊥

;

57 if $s t a t u s = G R A N T$ then

s t a t u s \leftarrow N O R M A L

;

58 if $s t a t u s = G R A N T G E T$ then

s t a t u s \leftarrow T R Y G E T

;

t r y M a n o e u v r e (t a g . t u r n)

;

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 $p_{i}$ consists of a set called Safety Membership ( $S M$ ) made up of the IDs of all other vehicles of higher priority in the same segment of the road, a flag called Manoeuvre Opportunity ( $M O$ ) that indicates whether or not the membership is valid, and a time stamp. There has to be one membership per manoeuvre $p_{i}$ 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 $T_{M}$ 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 $p_{i}$ checks if $p_{i}$ is still in the section (line 2). If so, the algorithm calculates which agents $U$ have higher priority than $p_{i}$ and may reach the intersection in the time it would take for $p_{i}$ to reach and perform a manoeuvre through the same intersection (line 2)^xi^xixiFor more details see Section 0.11.4. $U$ will have 3 entries for the 3 possible manoeuvres described above. In addition to $U$ , the set of all vehicles $R$ that are within communication distance from $p_{i}$ are determined (line 2). The earliest time stamps $t_{m i n}$ of the agent states in $U [t u r n]$ 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 $t_{m i n}$ 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 $M O$ s for the manoeuvre specific memberships. $M O$ is set to $T r u e$ if and only if all agents in $U$ are also in $R$ (line 2), which implies that all agents that $p_{i}$ can cause a priority violation for are also reachable by $p_{i}$ . It’s also possible to use the $M O$ -flag to indicate that the provided memberships are invalid due to, for example, limited capacity of the membership service.

The value assigned to $S M$ depends on the value of $M O$ . $S M$ is assigned the value of $U [t u r n]$ for the specific manoeuvre described by $t u r n$ if $M O = t r u e$ , and is assigned the empty set if $M O = f a l s e$ (line 2). The use of $M O$ thereby provides a way to both reduce the number of sent messages – since vehicles will not send a request if $M O = f a l s e$ – 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 $T_{A}$ 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 ( $D$ ) and the current membership ( $M R . S M$ ) are filtered out from the set of received replies $M$ (line 3). Vehicles that in $D$ but not $M R . S M$ must have already left the intersection, so their replies are considered irrelevant. Vehicles that are in $M R . S M$ but not $D$ 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 $G E T$ – confirm that all expected replies to the sent request have arrived by calling $l a s t ()$ (line 3). If all expected replies have arrived then the $t R E T R Y$ is stopped to mark the end of the current request round (line 3). In order to assess if the requester is fully granted, $M$ is searched for any $D E N Y$ replies and, if none are found, the requester changes status to $E X E C U T E$ and is thereby free to enter the intersection (line 3). Otherwise the requester will send a $R E L E A S E$ message to all vehicles in $D$ telling them to stop considering the requester granted and the $t R E T R Y$ 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 $p_{i}$ – having status $E X E C U T E$ – 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 $⟨ R E L E A S E ⟩$ of the grant to every vehicle in $D$ (line 3). The agent $p_{i}$ will then return to status $N O R M A L$ and call $n t f y E s t i m a t (r e v o k e)$ 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 $G R A N T$ or $G R A N T G E T$ , 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 $T r u e$ then the agent notifies the RE about the priority change by calling $n t f y E s t i m a t (r e v o k e)$ and clears $g r a n t I D$ (3). An agent previously prevented from starting a request round, denoted by having status $G R A N T G E T$ , takes on status $T R Y G E T$ and calls $t r y M a n o e u v r e$ to try to start a new request round (line 3). An agent with status $G R A N T$ instead goes back to status $N O R M A L$ (line 3).

The request initiating procedure $t r y M a n o e u v r e$ is invoked when starting a new round of a requests. During the first round of a request, where the vehicle has status $N O R M A L$ or $G R A N T$ , 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 $N O R M A L$ or $T R Y G E T$ , 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 $2 T_{M}$ time units and with a $M O = t r u e$ (line 3). If the membership is valid, then the state variables $M$ , $D$ , and $R$ will be assigned the values $⊥$ , $M R . S M$ , and $M R . S M$ respectively, where $R$ is the set of agents that are expected to reply and the status is changed to $G E T$ (line 3). A $⟨ G E T ⟩$ request is then sent to all agents in $D$ along with the request tag. The $t R E T R Y$ timer is set to $2 T_{D}$ 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 $t R E T R Y$ 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 $G R A N T$ , is not allowed to start a request round until the grant is released, but a status change to $G R A N T G E T$ is made to signify that the agent wants to send out a request later when it is allowed (line 3).

Upon expiry of the $t R E T R Y$ timer, an agent currently in a request round, having status $G E T$ , will end it by sending a $R E L E A S E$ to all agents in $D$ , changing its status to $T R Y G E T$ and starting the $t R E T R Y$ 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 $T R Y G E T$ , then the agent will try to start a new request round by calling the $t r y M a n o e u v r e$ 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 $T_{D}$ 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
$⟨ G R A N T ⟩$ and $⟨ D E N Y ⟩$ . Any requester will store these messages in the set $M$ and remove the sender ID from the set of agents whose expected responses have not yet arrived, $R$ , (line 3).

The second message type that is processed is $⟨ G E T ⟩$ which symbolises a permission request (line 3). The receivers have to decide if the request should be granted or denied. Firstly, a call to $n o P r i o r i t y V i o l a t i o n$ 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 $N O R M A L$ and $T R Y G E T$ imply that the agent does not have an active request round and is therefore allowed to grant another agent (line 3).

Agents with status $G R A N T$ or $G R A N T G E T$ 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 $⟨ G R A N T ⟩$ (line 3).

The last status that allows the receiver to reply with a grant occurs where the receiver both has status $G E T$ – meaning that it has an active request round – and the sender has higher priority than the receiver – determined by a call to the interface $m y P r i o r i t y$ (line 3). The interface $m y P r i o r i t y$ will return $F a l s e$ 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 $G R A N T$ – if it has status $N O R M A L$ – or to $G R A N T G E T$ – if it has status $G E T$ or $T R Y G E T$ (lines 3, 3, and 3). Changing from status $G E T$ or $T R Y G E T$ to $G R A N T G E T$ also implies both that the $t R E T R Y$ timer has to be stopped and that any ongoing round must be stopped by sending a $⟨ R E L E A S E ⟩$ to all agents in $D$ , since an agent in $G R A N T G E T$ is not allowed to either start or have an ongoing request round (lines 3 and 3). The risk estimator is then notified with $n t f y E s t i m a t (g r a n t)$ that the priorities have changed and a $⟨ G R A N T ⟩$ reply is sent to the request sender (line 3). If these criteria are not fulfilled, a $⟨ D E N Y ⟩$ is sent in reply (line 3).

The last type of messages to be processed are $⟨ R E L E A S E ⟩$ messages. An agent with status $G R A N T$ or $G R A N T G E T$ that receives a release message from the holder of the grant will call $n t f y E s t i m a t (r e v o k e)$ to inform the risk estimator of the expiry of the granted vehicle’s higher priority (3). A $G R A N T$ agent will return to status $N O R M A L$ while a $G R A N T G E T$ agent switches to status $T R Y G E T$ and calls $t r y M a n o e u v r e$ 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 $E$ be an execution of the proposed solution. At any system state, it holds that $(s t a t u s \in {T R Y G E T} ⟹ a c t i v e (t R E T R Y))$ , where $a c t i v e (t)$ is a predicate that represents the fact that timer $t$ has been started (by the function $s t a r t T i m e r (t)$ ), and has not stopped (by the function $s t o p T i m e r (t)$ ) or expired without triggering the event bounded to timer $t$ . Furthermore, an active $t R E T R Y$ timer expires within $B_RETRY=max{2TD,TA}$ time units.

Lemma 1.2 (Membership)

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

Proof. To prove that Requirement 0.1 holds throughout $E$ it needs to be shown that a fresh membership $M$ of an agent $p_{i}$ with $M O = T r u e$ contains all agents that could potentially cause a priority violation with $p_{i}$ from the current time $T$ until $T + 2 T_{D} + T_{M A N}$ . 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 $t$ is the timestamp bound to $M$ (line 2), $M$ can only be non-valid if $M O = F a l s e$ or $M$ is no longer fresh, i.e., $t \geq T - 2 T_{M}$ .

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
$n o P r i o r i t y V i o l a t i o n S t r i c t (t + 2 T_{M} + 2 T_{D} + T_{M A N})$ to determine all agents $U$ that have higher priority than $p_{i}$ and that could potentially reach the intersection at some point from $t$ to $t + 2 T_{M} + 2 T_{D} + T_{M a n}$ (line 2). These agents $U$ are the ones that could potentially lead to a priority violation with $p_{i}$ according to our definition in Section 0.11.3.

Algorithm 2 assigns correct $M O$ values. For a given turn, the membership $M$ is assigned the set $U [t u r n]$ if, and only if, $M O$ is assigned the value $T r u e$ , otherwise $M$ is assigned the empty set (line 2). The variable $M O$ 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 $t_{m i n}$ of the agents in $U [t u r n]$ (line 2). This implies that a fresh membership is valid from $T$ to $T + 2 T_{D} + 2 T_{M} + T_{M A N} - (T - t_{m i n})$ where $T - t_{m i n} \leq 2 T_{M}$ due to the freshness of $M$ . This proves Requirement 0.1 since we assume that vehicles do not drive backwards on highways. $■$

Theorem 1.3 (Safety)

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

Proof.

Requirement 0.2: By the structure of Algorithm 3, we can observe that an agent $p_{i}$ that aims to perform a manoeuvre, has to call $t r y M a n o e u v r e ()$ (line 3) and be granted a permission before reaching the status $E X E C U T E$ . In detail, $t r y M a n o e u v r e ()$ is the only interface procedure for agent $p_{i}$ , which includes lines 3 to 3 in which requests are sent. By line 3, we see that $p_{i}$ sends such a request only when (i) its membership is fresh and (ii) there is an positive indication for a manoeuvre opportunity. Otherwise, $p_{i}$ checks conditions (i) to (iii) after $T_{A}$ time units (line 3). Thus, Requirement 0.2 is fulfilled.
Requirement 0.3:

Algorithm 3 defines how a $⟨ G E T ⟩$ message is sent (lines 3 to 3) and received (line 3 to 3). We note that $p_{i}$ sends a $⟨ G E T ⟩$ message only if the if-statement condition at line 3, i.e., $(t_{i} < M . t m + 2 T_{M} \land M R . M O)$ which implies that the first assumption of Requirement 0.3 holds. To show that the second assumption holds, we note that $p_{j}$ processes a request message $⟨ G E T ⟩$ from $p_{i}$ at a time $t_{j} \in [t_{i}, t_{i} + T_{D}]$ only when its delivery is timely (line 3). Thus, we only need to prove that a request sent by a requester $p_{i}$ at a time $t_{i}$ to a requestee $p_{j}$ in $p_{i}$ ’s membership $M$ is replied to with a $⟨ G R A N T ⟩$ if, and only if, at a time $t_{j} \in [t_{i}, t_{i} + T_{D}]$ when the request is delivered to $p_{j}$ , $n o P r i o r i t y V i o l a t i o n D y n a m i c (A R_{j}) = T r u e$ and $p_{j}$ is in one of the states presented in the cases (i) to (iii) described in Requirement 0.3.

From line 3 we observe that $n o P r i o r i t y V i o l a t i o n D y n a m i c (A R_{j}) = T r u e$ is a mandatory condition for a request to be granted. From line 3, we can also observe that if (a) $p_{j}$ has status $N O R M A L$ or $T R Y G E T$ , (b) $p_{j}$ ’s status is $G R A N T$ and the granted agent is $p_{i}$ , or (c) $p_{j}$ ’s status is $G E T$ and $p_{i}$ has higher priority according to $m y P r i o r i t y$ , then $p_{j}$ will send a $⟨ G R A N T ⟩$ and call $n t f y E s t i m a t (g r a n t)$ (line 3). Moreover, $p_{j}$ reply with a $⟨ D E N Y ⟩$ if $p_{j}$ is in a state different from cases (a) to (c) or if $n o P r i o r i t y V i o l a t i o n D y n a m i c () = F a l s e$ (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 $⟨ G R A N T ⟩$ or $⟨ D E N Y ⟩$ is sent, Requirement 0.3 is satisfied.
Requirement 0.4:

From Algorithm 3 we see that a $⟨ R E L E A S E ⟩$ message is sent to all agents in $D$ 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 $n t f y E s t i m a t (r e v o k e)$ is only called when an agent $p_{j}$ receives a $⟨ R E L E A S E ⟩$ from another agent $p_{i}$ and $p_{j}$ is currently holding a grant for $p_{i}$ or when $p_{j}$ is in state $E X E C U T E$ and has left the intersection.

To reach and execute line 3, the requesting agent $p_{i}$ (with status $G E T$ ) needs to receive replies before the time $T = t_{i} + 2 T_{D} - T_{A}$ , where $t_{i}$ is the time when $p_{i}$ ’s request was sent, otherwise the $t R E T R Y$ timer will expire before the if-state condition on line 3 evaluates to $T r u e$ . The agent $p_{i}$ ’s $t R E T R Y$ timer will be stopped immediately after $p_{i}$ discover that all needed replies have arrived to stop the timer from interfering (line 3). Furthermore, any received $⟨ D E N Y ⟩$ message before time $T$ from another agent $p_{j}$ will be stored by $p_{i}$ (line 3). However, $p_{j}$ ’s $⟨ D E N Y ⟩$ will only be kept if $p_{j} \in (D \cap M$ ), where $M$ is $p_{i}$ ’s current membership (line 3). The agent $p_{i}$ will then execute line 3 since $p_{j}$ ’s $⟨ D E N Y ⟩ \in M$ (line 3). This case correspond exactly to case (i).

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

To execute line 3, agent $p_{i}$ ’s status has to be $E X E C U T E$ and $p_{i}$ has to have left the intersection so that $h a s L e f t C r i t i c a l S e c t i o n (p_{i}, M)$ evaluates to $T r u e$ (line 3). This correspond to case (iii).

The last line in which a $⟨ R E L E A S E ⟩$ can be sent, line 3, can be reached only if an agent $p_{i}$ has status $G E T$ when receiving a $⟨ G E T ⟩$ message $m$ from another agent $p_{j}$ and if $\neg m y P r i o r i t y (m) = T r u e$ , and $n o P r i o r i t y V i o l a t i o n D y n a m i c (A R_{j}) = T r u e$ (lines 3, 3, 3, and 3). This corresponds to case (iv).

We consider the case in which agent $p_{j}$ has the status $G R A N T$ and holding a grant for $p_{i}$ while receiving a $⟨ R E L E A S E ⟩$ message from $p_{i}$ . In this case, $p_{j}$ calls $n t f y E s t i m a t (r e v o k e)$ (line 3). The only other line where
$n t f y E s t i m a t (r e v o k e)$ is called is line 3. This line can only be reached if an agent has status $E X E C U T E$ and if $h a s L e f t C r i t i c a l S e c t i o n (a I D)$ evaluates to $T r u e$ (line 3). Requirement 0.4 is thus satisfied.
Requirement 0.5: Note that $p_{i}$ does not remove messages that are needed (such as in line 3). By line 3 to 3 and the definition of the function $l a s t ()$ in Figure 1.1, agent $p_{i}$ does not change its status to $E X E C U T E$ before it receives all the needed responses. This change to $E X E C U T E$ depends on the absence of a response that includes a $⟨ D E N Y ⟩$ , i.e., the case of being fully-granted. Otherwise, $p_{i}$ changes $s t a t u s$ to $T R Y G E T$ , sends a release message to all agents in $D$ and restarts the request process after $T_{A}$ time units.

$■$

Theorem 1.4 (Progression)

Let $E$ 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 $E$ .

Proof. Let $p_{i}$ be an agent that is the closest to the intersection from its direction and that aims at crossing the intersection, i.e., it calls $t r y M a n o e u v r e ()$ (line 3). By lines 3 and 3, immediately after the execution of $t r y M a n o e u v r e ()$ , the state of $p_{i}$ cannot be in ${N O R M A L, G R A N T}$ . This proof shows that the states $G E T$ , $T R Y G E T$ , and $G R A N T G E T$ must lead to $E X E C U T E$ before returning to the state $N O R M A L$ by demonstrating that $p_{i}$ indeed reaches the status $E X E C U T E$ and crosses the intersection.

Without loss of generality, suppose that $E$ is an execution in which $p_{i}$ ’s status is not in ${N O R M A L$ , $G R A N T}$ during the first system state of $E$ . Moreover, suppose that immediately after $E$ ’s starting system state, we have a period of $T_{a d m i s s i b l e} > B_R E T R Y + 2 T_{A}$ time units in which $p_{i}$ has an admissible crossing opportunity, where $B_RETRY=max{2TD,TA}$ . 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 $p_{i}$ always occurs eventually (within a finite period).

The rest of the proof considers $p_{i}$ ’s status in $E$ ’s starting system state, which can be one of $G E T$ , $T R Y G E T$ , and $G R A N T G E T$ , and shows that it indeed reaches status $E X E C U T E$ .

Suppose that $s t a t u s_{i} = G E T$ . Note that the do forever loop (line 3) of Algorithm 3 starts a new iteration once in every $T_{A}$ time units. Therefore, within $T_{A}$ time units, agent $p_{i}$ 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 $p_{i}$ is $= G E T$ , the definition of the function $l a s t ()$ (Figure 1.1) and the assumption that during the

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

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

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

Actuator Fault-Tolerant Vehicle Motion Control: A Survey

Proof of Compositionality of CFT Correctness

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

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

ASYMP: Fault-tolerant Mining of Massive Graphs

1 Algorithms

1.1 Algorithm description

1.1.1 Description of the Membership Algorithm

1.1.2 Description of the Manoeuvre Negotiation Algorithm

1.2 Correctness Proof

Corollary 1.1

Lemma 1.2 (Membership)

Theorem 1.3 (Safety)

Theorem 1.4 (Progression)

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

Related Research

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

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

Actuator Fault-Tolerant Vehicle Motion Control: A Survey

Proof of Compositionality of CFT Correctness

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

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

ASYMP: Fault-tolerant Mining of Massive Graphs

1 Algorithms

1.1 Algorithm description

1.1.1 Description of the Membership Algorithm

1.1.2 Description of the Manoeuvre Negotiation Algorithm

1.2 Correctness Proof

Corollary 1.1

Lemma 1.2 (Membership)

Theorem 1.3 (Safety)

Theorem 1.4 (Progression)