AVP Contracts

Chapter IV: Directive-response Assume-guarantee Contracts for an Auto-

4.4 AVP Contracts

Table 4.4: Trackerdirective-response system.

Interval variables/constantsvar𝑋

𝛿 Corridor map.

𝜀_{min, 𝑐 𝑎𝑟} Minimum safety distance to other cars.

𝜀_min, 𝑝 𝑒𝑜 𝑝𝑙 𝑒 Minimum safety distance to pedestrians.

Outputsvar𝑌

Tracker_→Planner An output channel of type ˜B(Tracker).

Tracker→CustomerInterface An output channel of type ˜A(Tracker).

Inputsvar𝑈

Tracker_←Planner An input channel of type ˜A(Planner).

Constraintscon𝑀

Corridor constraints In our implementation, we define the𝛿-corridor for any path𝑝to be the open set containing points whose distance to the closest point in𝑝does not exceed 3 meters.

𝜀_{min, 𝑐 𝑎𝑟},𝜀_min, 𝑝 𝑒𝑜 𝑝𝑙 𝑒 These values are determined based on the dynamics and the uncertaintyΔ𝐶 𝑎𝑟.

l Figure 4.2: Contracts between the components of the AVP system.

Tracker

A Tracker system is responsible for the safe control of cars that are accepted into the garage by a Supervisor. It receives directives from a Planner consisting of executable paths to track and send responses based on the task status to aPlanner.

See Table 4.4.

Contract 1(CCustomerInterface). The following is the contract for theCustomerInter- face.

• Assumes

– If theCustomerInterfacesends a request to theSupervisor, then they will receive a response from theSupervisor:

∀𝑐 ∈C:: ( [𝑚, 𝑐] ∈sendCustomerInterface→Supervisor {

∃𝑟 ∈B(Supervisor) ::[𝑟 , 𝑐] ∈receiveCustomerInterface←Supervisor).

(4.10)

– If the car is healthy and accepted by the garage, it will be returned after being summoned:

∀𝑐∈C:: (^≥0(𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦)

∧( [Accepted, 𝑐] ∈receiveCustomerInterface←Supervisor∧ [Retrieve, 𝑐] ∈sendCustomerInterface→Supervisor) { [Returned, 𝑐] ∈receiveCustomerInterface←Supervisor).

(4.11)

• Guarantees

– When the request is accepted, theCustomerInterfaceshould not tamper with the car controls until the car is returned (i.e., control signals should match the directive) :

∀𝑐∈C::∀𝑡::∀(𝑣 , 𝜑) ∈I::

( [Accepted, 𝑐] ∈receiveCustomerInterface←Supervisor(𝑡)

∧¬( [Returned, 𝑐] ∈receiveCustomerInterface←Supervisor(𝑡)) ⇒ ( [(𝑣 , 𝜑), 𝑐] ∈receiveCustomerInterface_←Tracker(𝑡)

∧∀𝑡⁰ < 𝑡:: [(𝑣 , 𝜑), 𝑐] ∉receiveCustomerInterface_←Tracker(𝑡⁰) ⇒ 𝑐 .𝑐𝑜𝑛𝑡𝑟 𝑜𝑙 𝑠.𝑣(𝑡) =𝑣∧𝑐 .𝑐𝑜𝑛𝑡𝑟 𝑜𝑙 𝑠. 𝜑(𝑡) =𝜑)).

(4.12)

– When the CustomerInterface is not receiving any new input signal, then it keeps the control inputs at zero:

∀𝑐 ∈C::∀𝑡::

( [Accepted, 𝑐] ∈receiveCustomerInterface←Supervisor(𝑡)

∧¬( [Returned, 𝑐] ∈receiveCustomerInterface←Supervisor(𝑡)) ⇒ (∀(𝑣 , 𝜑) ∈I::[(𝑣 , 𝜑), 𝑐] ∈receiveCustomerInterface_←Tracker(𝑡)

⇒ ∃𝑡⁰ < 𝑡:: [(𝑣 , 𝜑), 𝑐] ∈receiveCustomerInterface_←Tracker(𝑡⁰)) ⇒ 𝑐 .𝑐𝑜𝑛𝑡𝑟 𝑜𝑙 𝑠.𝑣(𝑡) =0∧𝑐 .𝑐𝑜𝑛𝑡𝑟 𝑜𝑙 𝑠. 𝜑(𝑡) =0))).

(4.13)

– From sending a request until receiving a response, the car must stay in the deposit area:

∀𝑐∈C::^≥0( [Park, 𝑐] ∈sendCustomerInterface→Supervisor

∧[Accepted, 𝑐] ∉receiveCustomerInterface←Supervisor

∧[Rejected, 𝑐] ∉receiveCustomerInterface←Supervisor

⇒𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒∈G.𝑒𝑛𝑡𝑟 𝑦_𝑐𝑜𝑛 𝑓 𝑖𝑔𝑢𝑟 𝑎𝑡𝑖 𝑜𝑛𝑠).

(4.14)

– After the car is deposited, the customer will eventually summon it:

∀𝑐 ∈C::[Accepted, 𝑐] ∈receiveCustomerInterface←Supervisor { [Retrieve, 𝑐] ∈sendCustomerInterface←Supervisor.

(4.15)

– Pedestrians will only walk on “walkable” area:

∀𝑐 ∈C::≥0( (𝑐 .𝑥 , 𝑐 . 𝑦) ∈G.𝑤 𝑎𝑙 𝑘 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎). (4.16)

– Pedestrians will not stay on crosswalks forever:

∀𝑐 ∈C::( (𝑐 .𝑥 , 𝑐 . 𝑦) ∈G.𝑤 𝑎𝑙 𝑘 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎∩G.𝑑𝑟 𝑖 𝑣 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎 { (𝑐 .𝑥 , 𝑐 . 𝑦)∉G.𝑤 𝑎𝑙 𝑘 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎∩G.𝑑𝑟 𝑖 𝑣 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎).

(4.17)

– If the car is not healthy and not towed, it cannot move:

∀𝑐 ∈C::≥0(¬𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦∧ ¬𝑐 .𝑐𝑎𝑟 .𝑡 𝑜𝑤 𝑒 𝑑 ⇒ 𝑐 .𝑐𝑜𝑛𝑡𝑟 𝑜𝑙 𝑠.𝑣=0∧𝑐 .𝑐𝑜𝑛𝑡𝑟 𝑜𝑙 𝑠. 𝜑=0).

(4.18)

– Sending aRetrievemessage must always be preceded by receiving anAccepted message from theSupervisor:

∀𝑐 ∈C::[Accepted, 𝑐] ∈receiveCustomerInterface←Supervisor

[Retrieve, 𝑐] ∈sendCustomerInterface→Supervisor.

(4.19)

– If a customer receivesRejectedorReturnedfrom theSupervisor, then they must leave the lot forever:

∀𝑐 ∈C::∀𝑡 ::[Rejected, 𝑐] ∈receiveCustomerInterface←Supervisor(𝑡)

∨[Returned, 𝑐] ∈receiveCustomerInterface←Supervisor(𝑡) ⇒

∃𝑡⁰> 𝑡 ::≥𝑡⁰( (𝑐 .𝑐𝑎𝑟 .𝑥 , 𝑐 .𝑐𝑎𝑟 . 𝑦) ∉G.𝑖𝑛𝑡 𝑒𝑟 𝑖 𝑜𝑟).

(4.20)

Contract 2(C_Supervisor). The contract for theSupervisoris as follows.

• Assumes

– Towing eventually happens after theSupervisoris alerted of car failure:

∀𝑐 ∈C::∀𝑡::[Failed, 𝑐] ∈receiveSupervisor_←Planner(𝑡) ⇒

∃𝑡⁰::^≥𝑡0(𝑐 .𝑐𝑎𝑟 .𝑡 𝑜𝑤 𝑒 𝑑∧ (𝑐 .𝑐𝑎𝑟 .𝑥 , 𝑐 .𝑐𝑎𝑟 . 𝑦) ∉G.𝑖𝑛𝑡 𝑒𝑟 𝑖 𝑜𝑟).

(4.21)

– If a car fails, then thePlannerreportsFailed:

∀𝑐 ∈C::¬𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦 { [Failed, 𝑐] ∈receiveSupervisor_←Planner. (4.22) – Cars making requests are deposited correctly by the customer:

∀𝑐 ∈C::≥0( [Park, 𝑐] ∈receive_Supervisor←CustomerInterface

∧( [Accepted, 𝑐] ∉send_Supervisor→CustomerInterface

∨[Rejected, 𝑐] ∉sendSupervisor→CustomerInterface)

⇒𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒∈G.𝑒𝑛𝑡𝑟 𝑦_𝑐𝑜𝑛 𝑓 𝑖𝑔𝑢𝑟 𝑎𝑡𝑖 𝑜𝑛𝑠).

(4.23)

– If a car is healthy and summoned, then it will eventually appear at the return area and thePlannerwill send aCompletedsignal to theSupervisor:

∀𝑐∈C:: (≥0𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦∧ [Retrieve, 𝑐] ∈receive_{Supervisor←Planner} {( [Completed, 𝑐] ∈receiveSupervisor_←Planner∧ 𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒∈G.𝑟 𝑒𝑡 𝑢𝑟 𝑛_𝑐𝑜𝑛 𝑓 𝑖𝑔𝑢𝑟 𝑎𝑡𝑖 𝑜𝑛𝑠)).

(4.24)

• Guarantees

– All requests from customers will be replied:

∀𝑐∈C:: ( [𝑚, 𝑐] ∈receive_Supervisor←CustomerInterface {

∃𝑟 ∈B(Supervisor):: [𝑟 , 𝑐] ∈sendSupervisor→CustomerInterface).

(4.25)

– The Supervisor cannot send a Returned message to the CustomerInterface unless it has received aCompletedmessage from thePlannerand the car is in the return area:

∀𝑐 ∈C::[Completed, 𝑐] ∈receive_{Supervisor←Planner}

∧𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒∈G.𝑟 𝑒𝑡 𝑢𝑟 𝑛_𝑐𝑜𝑛 𝑓 𝑖𝑔𝑢𝑟 𝑎𝑡𝑖 𝑜𝑛𝑠 [Returned, 𝑐] ∈sendSupervisor→CustomerInterface.

(4.26)

– If a car is healthy and aRetrievemessage is received, then the last thing sent to thePlannershould be a directive to the return area (the second configuration

should be one of the return configurations).

∀𝑐 ∈C:: (≥0𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦 ⇒ [Retrieve, 𝑐] ∈receiveSupervisor_←Planner∧

∃𝑝₀, 𝑝₁ ∈R³:: [(𝑝₀, 𝑝₁), 𝑐] ∈sendSupervisor_→Planner ∧ ∀𝑝⁰

0, 𝑝⁰

1∈R³::

[(𝑝⁰

0, 𝑝⁰

1), 𝑐] ∈send_{Supervisor→Planner} [(𝑝₀, 𝑝₁), 𝑐] ∈send_{Supervisor→Planner}

⇒ 𝑝₁ ∈G.𝑟 𝑒𝑡 𝑢𝑟 𝑛_𝑐𝑜𝑛 𝑓 𝑖𝑔𝑢𝑟 𝑎𝑡𝑖 𝑜𝑛𝑠.

(4.27) – If the car is healthy and if it is ever summoned, then theSupervisorwill send a

Returnedmessage to its owner:

∀𝑐 ∈C::(^≥0𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦 ⇒ [Retrieve, 𝑐] ∈receiveSupervisor←CustomerInterface { [Returned, 𝑐] ∈sendSupervisor→CustomerInterface).

(4.28)

– If there is a not-yet-responded-toParkrequest and the parking lot capacity is not yet reached, then theSupervisorshould accept the request:

∀𝑐∈C::∀𝑡::∃[Park, 𝑐] ∈receive_Supervisor←CustomerInterface(𝑡)

∧∀𝑡⁰≤ 𝑡::[Rejected, 𝑐] ∉sendSupervisor→CustomerInterface(𝑡⁰)

∧[Accepted, 𝑐] ∉sendSupervisor→CustomerInterface(𝑡⁰)

∧𝑛𝑢𝑚_𝑎 𝑐𝑡𝑖 𝑣 𝑒_𝑐𝑢 𝑠𝑡 𝑜𝑚 𝑒𝑟 𝑠(𝑡) <G. 𝑝 𝑎𝑟 𝑘 𝑖𝑛𝑔_𝑠 𝑝 𝑜𝑡 𝑠

⇒ ∃𝑡⁰⁰ > 𝑡:: [Accepted, 𝑐] ∈send_Supervisor→CustomerInterface(𝑡⁰⁰).

(4.29)

– For everyAcceptedto orRetrievefrom theCustomerInterfaceorBlocked from thePlanner, theSupervisorsends a pair of configurations to thePlanner, the first of which is the current configuration of the car and such that there exists a path of allowable curvature :

∀𝑐 ∈C:: [Accepted, 𝑐] ∈send_Supervisor→CustomerInterface

∨[Retrieve, 𝑐] ∈receiveSupervisor←CustomerInterface

∨[Blocked, 𝑐] ∈receive_{Supervisor←Planner} {

∃𝑘₀, 𝑘₁∈R³:: [(𝑘₀, 𝑘₁), 𝑐] =Supervisor_→Planner

∧𝑘₀ =𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒∧ ∃𝑝 ∈P::𝜅-feasible(𝑝)

∧𝑝˜(0) =𝑘₀∧𝑝˜(1) =𝑘₁.

(4.30)

Contract 3(C_Planner). The contract for thePlanneris as follows:

• Assumes

– When theTrackercompletes its task according to the corridor map𝛿, it should send a report to thePlanner:

∀𝑐 ∈C::∃𝑝 ∈P::∀𝑝⁰ ∈P::

[𝑝⁰, 𝑐] ∈send_{Planner→Tracker} [𝑝, 𝑐] ∈send_{Planner→Tracker}∧ 𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒∈Γ𝛿(𝑝,1) { [Completed, 𝑐] ∈receive_{Planner←Tracker}.

(4.31)

– If theTrackersees a failure, it should report to thePlanner:

∀𝑐 ∈C::¬𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦 { [Failed, 𝑐] ∈receivePlanner←Tracker. (4.32)

• Guarantees

– When receiving a pair of configurations from theSupervisor, thePlannershould send a path to theTrackersuch that the starting and ending configurations of the path match the received configurations, or if this is not possible, sendBlocked to theSupervisor:

∀𝑐∈C::∃(𝑝₀, 𝑝₁) ∈R⁶:: [(𝑝₀, 𝑝₁), 𝑐] ∈receivePlanner←Supervisor

{ (∃𝑝 ∈P:: ˜𝑝(0)= 𝑝₀∧𝑝˜(1) = 𝑝₁∧ [𝑝, 𝑐] ∈send_{Planner→Tracker}

∨[Blocked, 𝑐] ∈send_Planner→Supervisor).

(4.33)

– Only send safe paths with𝜅-feasible curvature:

∀𝑐 ∈C::∃𝑝 ∈P:: [𝑝, 𝑐] ∈send_{Planner→Tracker} ⇒ 𝜅-feasible(𝑝) ∧Γ𝛿(𝑝) ⊆G.𝑑𝑟 𝑖 𝑣 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎 .

(4.34)

– If receiving a task status update from theTracker, eventually forward it to the Supervisor:

∀𝑐 ∈C::[𝑚, 𝑐] ∈receivePlanner←Tracker

∧𝑚 ∈ {Failed,Completed}{ [𝑚, 𝑐] ∈send_Planner→Supervisor.

(4.35)

– If thePlannerreceives aBlockedsignal from theTracker, it attempts to fix it, otherwise forwards it to theSupervisor:

∀𝑐 ∈C::∀𝑡 ::[Blocked, 𝑐] ∈receive_{Planner←Tracker}(𝑡) ⇒

∃𝜀 ∈R≥0:: (∃𝑝 ∈P::[𝑝, 𝑐] ∈send_{Planner→Tracker}(𝑡+𝜀)∧

∀𝑡⁰ < 𝑡+𝜀:: [𝑝, 𝑐] ∉sendPlanner→Tracker(𝑡⁰)

∨[Blocked, 𝑐] ∈sendPlanner→Supervisor(𝑡+𝜀)).

(4.36)

Contract 4(C_Tracker). The contract for the tracking component is as follows:

• Assumes

– Any path command from thePlanneris always𝜅-feasible, the corresponding corridor is drivable, and the car configuration upon receiving the command is in the initial portion of the corridor:

∀𝑐 ∈C::∀𝑝 ∈P::∀𝑡:: starts_at( [𝑝, 𝑐] ∈receive_{Tracker←Planner}, 𝑡)∧

𝜅-feasible(𝑝) ∧𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒(𝑡) ∈Γ𝛿(𝑝,0) ∧Γ𝛿(𝑝) ⊆G.𝑑𝑟 𝑖 𝑣 𝑎 𝑏𝑙 𝑒_𝑎𝑟 𝑒 𝑎 . (4.37) – Commands are not modified by theCustomerInterface:

See (4.12) and (4.13). (4.38)

• Guarantees

– Make sure car stays in the latest sent𝑝’s corridorΓ𝛿(𝑝):

∀𝑐 ∈C::∀𝑡::∃𝑝 ∈P::∀𝑝⁰ ∈P::

( ( [𝑝, 𝑐] ∈receiveTracker←Planner(𝑡) ∧ [𝑝⁰, 𝑐] ∈receiveTracker←Planner(𝑡)) ⇒ ( [𝑝⁰, 𝑐] ∈receiveTracker←Planner [𝑝, 𝑐] ∈receiveTracker←Planner)) ⇒ 𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒(𝑡) ∈Γ𝛿(𝑝).

(4.39) – Tracking command inputs are compatible with cars:

∀𝑐 ∈C::≥0( [(𝑣 , 𝜑), 𝑐] ∈sendTracker→CustomerInterface ⇒ 𝑣_min ≤𝑣∧𝑣 ≤𝑣_max∧𝜑_min ≤ 𝜑∧𝜑 ≤𝜑_max).

(4.40)

– Never drive into a dynamic obstacle (customer or car):

∀𝑐₁, 𝑐₂ ∈C::≥0( (𝑐₁≠𝑐₂⇒ k (𝑐₁.𝑐𝑎𝑟 .𝑥 , 𝑐₁.𝑐𝑎𝑟 . 𝑦) − (𝑐₂.𝑐𝑎𝑟 .𝑥 , 𝑐₂.𝑐𝑎𝑟 . 𝑦) k ≥𝜀_{min, 𝑐 𝑎𝑟})∧

k (𝑐₁.𝑐𝑎𝑟 .𝑥 , 𝑐₁.𝑐𝑎𝑟 . 𝑦) − (𝑐₂.𝑥 , 𝑐₂. 𝑦) k ≥ 𝜀_min, 𝑝 𝑒𝑜 𝑝𝑙 𝑒)).

(4.41)

– If a car fails, it must report to thePlanner:

∀𝑐∈C::¬𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦 {[Failed, 𝑐] ∈sendTracker←Planner. (4.42) – If a car is healthy, then it must “track” the last sent path from thePlanner:

∀𝑐∈C::≥0𝑐 .𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦∧ ∃𝑝 ∈P::∀𝑝⁰ ∈P::

[𝑝⁰, 𝑐] ∈receive_{Tracker←Planner} [𝑝, 𝑐] ∈receive_{Tracker←Planner}

⇒ ∃𝑡::𝑐 .𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒(𝑡) ∈Γ𝛿(𝑝,1).

(4.43)

Figure 4.3: Implementation of the Planner component.

– When theTrackercompletes its task according to a corridor map𝛿, it should send a report to thePlannermodule:

See (4.31). (4.44)

– If a car is blocked (i.e., there is a failed car in its current corridor), then the Tracker must reportBlockedto thePlanner:

∀𝑐∈C::∀𝑡::∃𝑝 ∈P:: ( [𝑝, 𝑐]receiveTracker←Planner(𝑡)::

∀𝑝⁰∈P:: [𝑝⁰, 𝑐] ∈receiveTracker←Planner(𝑡⁰)

⇒ [𝑝⁰, 𝑐] ∈receive_{Tracker←Planner} [𝑝, 𝑐] ∈receive_{Tracker←Planner}) ⇒ (∃𝑐⁰∈C::𝑐⁰≠𝑐∧ ¬𝑐⁰.𝑐𝑎𝑟 . ℎ𝑒 𝑎𝑙 𝑡 ℎ 𝑦∧𝑐⁰.𝑐𝑎𝑟 .𝑠𝑡 𝑎𝑡 𝑒(𝑡) ∈Γ𝛿(𝑝) {[Blocked, 𝑐] ∈sendTracker→Planner).

(4.45)