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 |
Data types: Structures: ;
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
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)
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)
Proof.
-
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.
-
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.
-
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. -
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)
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