Temporal Logics Express reactive properties (order of events in time) - e.g. “Always” when a packet is sent it will “Eventually” be received Linear Time Temporal Logic Every state has unique time successor Infinite sequences Computation Tree Logic A state may have multiple time successors Infinite tree Dr. Vered Gafni

pOp, (pOp), (XisZero), (close)U(stop) Propositional Linear Temporal Logic (LTL) Extension of propositional logic with temporal operators. Syntax - Atomic propositions: a,b,c,…, and constants tt, ff - For every formulae p, q p, pq, Op, p, p, pUq  next until always eventually Examples: pOp, (pOp), (XisZero), (close)U(stop) Dr. Vered Gafni

 is a model of  iff 0 LTL Semantics Semantic domain of LTL formula [P]: , where = 2P Given , =012…, i2P (j=jj+1j+2…, j0) jtt, jff jp Iff pj j iff j j j or j jO j+1 j kj k j kj. k jU kj. jik i and k Note for every j s.t. j also jU  is a model of  iff 0 Dr. Vered Gafni

LTL Examples I Op: 1p p: k0. kp p: k0 kp Dr. Vered Gafni

LTL Examples II pUq: k0. 0ik ip and kq (pUq): j0. jpUq, i.e. kj. jik i p and k q Dr. Vered Gafni

LTL interpretation over Transition Systems Oq p u rUs s O(rqUs) Note – every model is composed of a finite prefix and a loop. If a certain state in the loop satisfies a temporal formula that is not prefixed by ‘next’ then every state In the loop satisfies this formula Dr. Vered Gafni

Identities q  ttUq   ttUq iff k0 s.t. 0ik i tt and k q iff k0 s.t. k q iff   q q  q (exercise). Hence, O, U form a compact set of temporal operators Dr. Vered Gafni

Common implications (tautologies) p  q  (p  q) p  q  (p  q) p  p Op  p p  p  p  p p  p  p  p q  pUq q  (pUq) idempotency Last terms: whenever q is satisfied pUq is satisfied Dr. Vered Gafni

LTL   regular language Given [P], define =2P By definition  for every model  of , L(), the set of all models of , is an -regular language proof: by induction on the structure of   Is the converse:  regular language  LTL, true ? Dr. Vered Gafni

Properties Classification Safety:  - “something bad never happens” (actually invariants) - can be proved false within a finite prefix of a run. -- traffic and pedestrian lights never show green simultaneously (T_Green  P_Green) – no deadlock (action1  …  actionn) Liveness:  - “something good will happen” can be proved false only along an infinite run. -- program termination Pstart  Pterminates Dr. Vered Gafni

Some Typical Property Patterns Response p  q initial p is followed by q (pq) responsiveness (p q) every p is followed by q Recurrence p infinitely often p eventually always Precedence pU(qUr) -- order of occurrence is preserved (pUq)Ur -- order of occurrence ? (pUq)p -- weak until pWq -- p cannot occur before q p  q def (pq) p  q pWqdef (pUq)p Dr. Vered Gafni

((Q  R  OR )  R)  (R)U(O(P  R))) Interval Properties P is true during [Q,R] : ((Q  R)  PU(PR) P occurs within (Q,R): ((Q  R  OR )  R)  (R)U(O(P  R))) First, third - always Dr. Vered Gafni

Example: Chained Until Between the time an elevator is called at a floor and the time it opens its doors at that floor the elevator can pass that floor at most twice. Let Move  AtFloor Stop  AtFloor DoorOpen Open  AtFloor DoorOpen Then, ((call  Open)  (Move U (Open  (Stop U (Open  (Move U (Open  (Stop U (Open  (Move U Open)))))))))) Dr. Vered Gafni

Build system interface System Formalization Build system interface Input: events, discrete (finite domain) variables Output: variables, actions (events) Specify system assumptions Specify system requirements {Assumptions}  {Program}  {Requirements} LTL formulae over system interface Dr. Vered Gafni

Water Level Control (WLC) valve Water-level sensor H L The valve should be open as long as water level  L, and close as long as water level  H. An open valve, stays open until level  H, similarly, a closed valve stays closed until level L. At startup, water level  H. Problem simplified, in practice timing requirements due to: Change of valve state occurs at an interval, not a time instant. Rates of water inlet and outlet flow. Dr. Vered Gafni

WLC: Ontology Controller Input: WaterLevel: { low, inter, high } Valve position command Water-level sensor H valve L Input: WaterLevel: { low, inter, high } Output: ValvePosition: { closed, opened } Dr. Vered Gafni

WLC: Interface Propositional Representation Interpreted by logic, hence use Booleans WaterLevel : { low, inter, high }  Conditions: LowLevel, InterLevel, HighLevel (LowLevel  InterLevel  HighLevel) LowLevel  (InterLevel  HighLevel) InterLevel  (LowLevel  HighLevel) HighLevel  (InterLevel  LowLevel) ValvePosition: { ValveClosed, ValveOpened } (ValveClosed  ValveOpened) ValveClosed  (ValveOpened)  In practice, enumeration types are used and proof systems automatically deploy them into Booleans with the proper axioms (assumptions). Ontological Assumptions Add precise definition of ValveStatus w.r.t. the levels L, H Dr. Vered Gafni

WLC Assumptions Given properties, relevant to the system implementation External environment (controlled process) behavior -- At startup water level < H. ¬HighLevel - Open valve will eventually raise water to high level (ValveOpened  HighLevel) (ValveClosed  HighLevel) Design dependent (sensors, actuators, processor, etc.) Ontological definitions, and abstract variables Platform Assumptions: - Change of valve state occurs at an interval, not a time instant. - Container volume, and rates of water inlet and outlet flow. Dr. Vered Gafni

(HighLevel ValveClosed)  (LowLevel ValveOpened) WLC: Requirements The valve is open as long as water level  L, and close as long as water level  H. (HighLevel ValveClosed)  (LowLevel ValveOpened) An open valve, stays open until level  H, similarly, a closed valve stays closed until level  L ValveOpened  ValveOpened W HighLevel ValveClosed  ValveClosed W LowLevel We do not use the valve commands in the requirements Dr. Vered Gafni

Railroad Crossing Dr. Vered Gafni

Case Study: Railroad Crossing Design a controller that handles the passage of a train in a one-way railroad crossing. The plant consists of a pair of reliable sensors that indicate train entering and exiting the crossing region (XR), a signal for entering trains, and a gate for blocking passage of cars from a side road. We assume that at startup no train enters, is already in, or exits XR. The minimal delay between successive trains is 40 seconds, and incoming trains do not traverse the signal as long as it shows ``stop''. It takes a train 6 seconds to arrive at the signal, and further 15-25 seconds to traverse the crossing (depending on whether the train had to stop at the signal, or not). It is required that: The gate is closed when a train moves in the gate area (between the signal and the exit point). The gate is open whenever the crossing is empty for more than 10 seconds. Every train that arrives at the signal is allowed to continue beyond the signal within 10 seconds. No train enters XR while another train is still there. Dr. Vered Gafni

opened when no train more than 10 sec Train stoped for no more Railroad Crossing opened when no train more than 10 sec Train stoped for no more than 10 sec No less than 40 sec 6sec (15-25)sec Initially empty closed when train in No more than 1 train in XR Dr. Vered Gafni

The Railroad Crossing Ontology Events Tin - Train enters XR Tout - Train exits XR Operations Up - Raising the gate up (opening) Down - Lowering the gate (closing) Stop - Signal turned to show stop Pass - Signal turned to show pass Operation K: @K initiation event K! termination event. Synchronous K: @K, K! occur simultaneously, denoted by K Dr. Vered Gafni

Assumptions At startup no train enters, or exits XR. (Tin  Tout) At startup no train is in XR. (Tout)W(Tin Tout) ?  40 seconds minimal delay between trains ? It takes a train 6 seconds to arrive at the signal ?  It takes a train 15 to 25 seconds to traverse gate area ? Trains do not pass in 0 time (Tin and Tout of same train do not occur together. Train properties. We have no indication in the system whether a train is moving or not. But can represent by another assumptions such as the occurrence of Tout after Tin. Second formula does not represent the case: train is in XR, then another train enters, then the first train exits Dr. Vered Gafni

Inserting Time Model into LTL Adopt discrete time model (N). Detrmine time unit. States are fixed rate snapshots of the system.   s0 s1 s2 s3 s4 s5 0 1 2 3 4 5 We could define constrained eventually and always operators (also simplifies the decision tableau Next State = Next time instant Dr. Vered Gafni

Expressing Durations in LTL This approach makes the satisfaibility problem EXPSPACE-hard Op - p holds after one time unit. OOp - p holds after two time units. Onp - p holds after n time units (O0p=p ). Om,np def Omp  Om+1p  …  Onp -- p holds continuously in the interval [m,n] Om,np def Omp  Om+1p  …  Onp -- p holds sometimes in the interval [m,n] We could define constrained eventually and always operators (also simplifies the decision tableau Dr. Vered Gafni

Assertions (revised) At startup no train enters, is in, or exits XR. (Tin  Tout)  “is in XR” ? 40 seconds minimal delay between trains. Tin  O1,39Tin It takes a train 6 seconds to arrive at the signal. Introduce abstract variable AtSignal - the train arrives at the signal - defined by: Tin  O6(AtSignal) It takes a train 15 to 25 seconds to traverse gate area ? We need to characterize the instant a train enters the critical section ! (either immediately, if signal shows pass, or after being stopped when signal turns to show pass Dr. Vered Gafni

Conditions (Abstract Variables) Represented by event that occurs iff the condition is true ShowStop - the signal shows “stop” (abstract variable). (Stop!  ShowStop)  (O(Stop!)  (ShowStop  O(@Pass)))  O(ShowStop) The problem of representation of conditions in PLTL. The definition of past operator O*. Fixed point of OO*. Operational interpretation: compute derived events each step and add them to the current step. The problem of iff w.r.t. the definition of derived events. Any operation K, let @K initiation event K! termination event of its execution. Dr. Vered Gafni

(O(Stop!)  (ShowStop  O(@Pass)))  O(ShowStop) Entering the Crossing EnterGR – train passes the signal (EnterGR  (AtSignalTwait))  O(EnterGR) O(AtSignal Twait)(Twait O(Twait)) Twait - train waiting at signal ((AtSignal  ShowStop)  Twait)  (O(AtSignal  ShowStop)  (Twait  O(ShowStop)))  O(Twait) ShowStop - the signal shows “stop”. (Stop!  ShowStop)  (O(Stop!)  (ShowStop  O(@Pass)))  O(ShowStop) The problem of representation of conditions in PLTL. The definition of past operator O*. Fixed point of OO*. Operational interpretation: compute derived events each step and add them to the current step. The problem of iff w.r.t. the definition of derived events. Dr. Vered Gafni

(Stop!  (ShowStop  @Pass))  ShowStop (@Pass)S(Stop!)  ShowStop Past & Since Operators Past  -  occurred in the previous step - j  iff j1 and j-1 (0 ) Now, ShowStop can be defined as: (Stop!  (ShowStop  @Pass))  ShowStop Since S -  occurred in the past and since then  - j S iff 0k j s.t. k and ki j i (@Pass)S(Stop!)  ShowStop Dr. Vered Gafni

EnterGr rewritten EnterGR – train passes the signal EnterGR  (AtSignal  ShowPass)  (Twait  Pass) Twait - train waiting at signal Twait  (ShowStop)S(AtSignal  ShowStop) ShowStop - the signal shows “stop”. ShowStop  (@Pass)S(Stop!) ShowPass - the signal shows “pass”. ShowPass  (@Stop)S(Pass!) The problem of representation of conditions in PLTL. The definition of past operator O*. Fixed point of OO*. Operational interpretation: compute derived events each step and add them to the current step. The problem of iff w.r.t. the definition of derived events. Dr. Vered Gafni

Assertions (revised) At startup no train is in XR ? 40 seconds minimal delay between trains. Tin  O1,39Tin It takes a train 6 seconds to arrive at the signal. Tin  O6(AtSignal) It takes a train 15 to 25 seconds to traverse gate area. EnterGR  O15,25Tout Dr. Vered Gafni

Closed  (@Up)S(Down!) Requirements Every train that arrives at the signal is allowed to continue beyond the signal within 10 seconds. AtSignal  O0,10(Twait) No train enters XR while another train is still there. Tin  O(TinUTout) The gate is closed when a train traverses GR. EnterGR  ClosedUTout Abstract variable Closed - the gate is closed (assumption) Closed  (@Up)S(Down!) We cann’t use ShowPass instead of (not Twait) because it will not occur if occurred before AtSignal. Sim. Not (not ShowStop) because it will occur but does not mean that the signal does not shows Stop. Dr. Vered Gafni

Requirements (cont.) The gate is open whenever the crossing is empty for more than 10 seconds. Empty_10s  Open Empty_10s - XR is empty at least 10 seconds. Empty_10s  (Tin)S(Bempty_10s) Bempty_10s - XR is empty 10 seconds (exactly) (10(Startup Tout)  0,10(Tin))  Bempty_10s Open - the gate is open Open  (@Down)S(Up!) This is true only if we had already proved the requirement that only one train at a time can be in XR - legal (later we show independent rep.). Add ontology assumption: Startup  OStartup, or Startup  true Assumptions Dr. Vered Gafni

About Abstract Variables Tin  O6(AtSignal) AtSignal can be replaced by 6(Tin) (Stop!  ShowStop)  (O(Stop)  (ShowStop  O(@Pass)))  O(ShowStop) (Stop!  (ShowStop  @Pass))  ShowStop (@Pass)S(Stop!)  ShowStop Dr. Vered Gafni

@Stop  Stop!, @Pass  Pass!, Design Assumptions Specify design constraints that are not explicitly expressed in the controller program (usually time constraints), but are essential in an attempt to prove its correctness. We may want to assume that signal operations are actions (synchronous operations):  @Stop  Stop!, @Pass  Pass!,   Hence, we use Stop, Pass as initiated events. We need specify deadline (causality) constraints for gate operations: (@Up  (@Down)U(Up!)  O0,10(Up!))  O0,10(@Down)) (@Down  (@UpU(Down!)  O0,10(Down!))  O0,10(Up!)) Dr. Vered Gafni

Counting in LTL (the N Train Assumption) Goal: Direct expression of empty and busy XR Ground assumption: The number of exits does not exceed the number of entries. Problem: LTL is not expressive enough to allow counting. Possible solution: Assume that there are at most N trains in the system (makes sense in real world). Dr. Vered Gafni

N Train Assumption Say N=2: Tcr0, Tcr1, Tcr2 indicate 0,1,2 trains in XR then: (Tcr0  Tcr1  Tcr2) Tcr0  (Tcr1  Tcr2) Tcr1  (Tcr0  Tcr2) Tcr2  (Tcr1  Tcr0) Tcr0  Tout Tcr0  Tin  O(Tcr0) Tcr0  Tin  O(Tcr1) Tcr1  Tin  Tout  O(Tcr2) Tcr1  Tout  Tin  O(Tcr0) Tcr1  ((Tout  Tin)  (Tout  Tin))  O(Tcr1) Tcr2  Tout  Tin  O(Tcr1) Tcr2  Tout  Tin -- here we make the restriction to N=2 Tcr2  (Tout  (Tout  Tin))  O(Tcr2) These are axioms that define the meaning of Tcr0,Tcr1,Tcr2 Derived atoms have np semantics in the domain. We must give their semantics by axioms (true for conditions as well). Dr. Vered Gafni

Properties Specification - At startup no train is in XR Tcr0 - No train enters XR while another train is still there. (Tcr2) Note that we only need to assume N+1 trains where N is the number of allowed trains in XR. Dr. Vered Gafni