1 / 39

Temporal Logics

Linear Time Temporal Logic Every state has unique time successor Infinite sequences. Computation Tree Logic A state may have multiple time successors Infinite tree. Temporal Logics. Express reactive properties (order of events in time)

collin
Download Presentation

Temporal Logics

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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

  3. LTL Semantics Semantic domain of LTL formula [P]: , where = 2P Given , =012…, i2P (j=jj+1j+2…, j0)  is a model of  iff 0 Dr. Vered Gafni

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

  5. 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

  6. LTL interpretation over Transition Systems Oq p u rUs s O(rqUs) Dr. Vered Gafni

  7. 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

  8. 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 Dr. Vered Gafni

  9. 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

  10. Properties Classification Safety: - “something bad never happens” (actually invariants) - can beproved 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 beproved false only along an infinite run. -- program termination Pstart Pterminates Dr. Vered Gafni

  11. Some Typical Property Patterns p q def(pq) Response p  qinitial 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 pWqdef(pUq)p Dr. Vered Gafni

  12. 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))) Dr. Vered Gafni

  13. 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

  14. 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

  15. Water Level Control (WLC) valve Water-level sensor 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. H L Dr. Vered Gafni

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

  17. 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 Dr. Vered Gafni

  18. 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

  19. 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 Dr. Vered Gafni

  20. Railroad Crossing Dr. Vered Gafni

  21. Case Study: Railroad Crossing Design a controller that handles the passage of a train in a one-wayrailroad 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 onwhether 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

  22. 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

  23. 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: • @Kinitiation event • K!termination event. • Synchronous K: @K, K! occur simultaneously, denoted by K Dr. Vered Gafni

  24. 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 ? Dr. Vered Gafni

  25. 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 Next State = Next time instant Dr. Vered Gafni

  26. 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] Dr. Vered Gafni

  27. 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

  28. Conditions (Abstract Variables) Represented by event that occurs iff the conditionis true • ShowStop- the signal shows “stop” (abstract variable). (Stop!  ShowStop)  (O(Stop!)  (ShowStop  O(@Pass))) O(ShowStop) • Any operation K, let • @K initiation event • K! termination event of its execution. Dr. Vered Gafni

  29. 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) Dr. Vered Gafni

  30. Past & Since Operators Past •  -  occurred in the previous step - j iffj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 Now, ShowStop can be defined as: (@Pass)S(Stop!) ShowStop Dr. Vered Gafni

  31. 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!) Dr. Vered Gafni

  32. Assertions (revised) • At startup no train is inXR ? • 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

  33. Requirements • Every train that arrives at the signal is allowed to continue beyond the signalwithin 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!) Dr. Vered Gafni

  34. 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!) • Add ontology assumption: • Startup  OStartup, or Startup  true Assumptions Dr. Vered Gafni

  35. About Abstract Variables • Tin  O6(AtSignal)AtSignalcan 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

  36. 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

  37. Counting in LTL (the N Train Assumption) Goal: Direct expression of empty and busy XR Ground assumption: The number of exits does not exceed thenumber 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

  38. 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 toN=2 • Tcr2  (Tout  (Tout  Tin))  O(Tcr2) These are axioms that define the meaning of Tcr0,Tcr1,Tcr2 Dr. Vered Gafni

  39. Properties Specification - At startup no train is inXR Tcr0 - No train enters XR while another train is still there. (Tcr2) Dr. Vered Gafni

More Related