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

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

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

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 SystemsOq 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

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
Last terms: whenever q is satisfied pUq is satisfied
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 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

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

12. ((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

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

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

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

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
Add precise definition of ValveStatus w.r.t. the levels L, H
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. (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

20. Railroad Crossing
Dr. Vered Gafni

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

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

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:
@K initiation event
K! termination event.
Synchronous 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 ?
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

25. Inserting Time Model into LTL
Adopt discrete time model (N).
Detrmine time unit.
States are fixed rate snapshots of the system.
s s s s s s5
We could define constrained eventually and always operators (also simplifies the decision tableau
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]
We could define constrained eventually and always operators (also simplifies the decision tableau
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 condition is true
ShowStop - the signal shows “stop” (abstract variable).
(Stop!  ShowStop) 
(O(Stop!)  (ShowStop   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

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

30. (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   ShowStop
Since
S -  occurred in the past and since then 
- j S iff 0k j s.t. k and ki j i
 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 
ShowPass - the signal shows “pass”.
ShowPass 
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

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

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

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

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

36. @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!, @Pass  Pass!,
  Hence, we use Stop, Pass as initiated events.
We need specify deadline (causality) constraints for gate operations:
  O0,10(Up!)) 
  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 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

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

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