Descriptive notations

Logic-based specifications
 First-order logic
• First-order logic symbols:
– variables: x, y, z, …
– constants: 1, 2, John, Mary, …
– functions: +, -, age(p), …
– predicates: >, =, is_father(p1, p2), …
– connectors: Ù (and), Ú (or), ¬ (not), Þ (implies), Û (iff)
– quantifiers: $ (exists), " (for all)
• Examples of first-order formulas:
– x=2Ùy=1Þx>y
– is_father(John, Mary) Þ age(John) > age(Mary)
– " x, y (is_father(x, y) Þ age(x) > age(y))
Descriptive Notations: Logic 2
 Case study (repeat)

An n-elevator system is to be installed in a building with m floors. The

elevators and the control mechanisms are supplied by the
manufacturer. The internal mechanisms of these are assumed given.
The problem concerns the logic to move elevators between floors
according to the following constraints:
– Each elevator has a set of buttons, one for each floor. These
light up when pressed and cause the elevator to visit the
corresponding floor. The lights switch off when the
corresponding floor is visited by the elevator.

Descriptive Notations: Logic 3

 Case study (cont.)

– Each floor has two buttons (except the ground and the top
floors), one to request an up elevator and one to request a
down elevator. These buttons light up when pressed. The
lights switch off when the elevator visits the floor and is either
moving in the desired direction, or has no outstanding
requests. In the latter case, if both floor-request buttons are
pressed, only one is canceled. The algorithm to decide which
to service first should minimize the waiting time for both
requests.

Descriptive Notations: Logic 4

 Case study (cont.)

– When an elevator has no requests to service, it should remain at

its final destination with its doors closed and await further
requests.
– All requests for elevators from floors must be serviced
eventually, with all floors given equal priority.
– All requests for floors within elevators must be serviced
eventually, with floors being serviced sequentially in the direction
of travel.
– Each elevator has an emergency button which, when pressed,
causes a warning signal to be sent to the site manager. The
elevator is then deemed “out of service”. Each elevator has a
mechanism to cancel its “out of service” status.

Descriptive Notations: Logic 5

 Descriptive logic specifications
• Formalization of the informal specification through
elementary predicates and rules
• Elementary predicates
– at(E, F, T)
• elevator E is at floor F at time T
– start(E, F, T, dir)
• elevator E left floor F at time T in direction dir (which can be up or down)
– on(E, F, T)
• the button of elevator E referring to floor F is switched on at time T
• Rules
– (at(E, F, T) Ù on(E, F1, T) Ù F1 > F) Þ start(E, F, T, up)

Descriptive Notations: Logic 6

 A word on quantifiers
• We leave quantifiers (∃, ∀) implicit in formulas
• Rule for introducing quantifiers:
– Variables that appear on both sides of the implication are
universally quantified (i.e., with ∀)
– Variables that appear only on one side of the implication are
existentially quantified (i.e, with ∃)
• The quantifier “hugs” the variables as close as possible

Descriptive Notations: Logic 7

 Example of implicit quantifiers

• (at(E, F, T) Ù on(E, F1, T) Ù F1 > F) Þ start(E, F, T, up)

stands for:

∀E, F, T( (at(E, F, T) Ù ∃F1(on(E, F1, T) Ù F1 > F) )

Þ
start(E, F, T, up) )

Descriptive Notations: Logic 8

 States and events
• Elementary predicates are partitioned into
– states, having non-null duration
standing
• standing(E, F, T1, T2)
– assumption: closed at left, open at right
T1 T2 time
– events
• instantaneous (caused state change occurs at same time)
• represented by predicates that hold only at a particular time instant
– arrival(E, F, T) arrival

• For simplicity, we assume T time

– zero decision time

– no simultaneous events of the same type
– (temporal domain is continuous, T Î R)
Descriptive Notations: Logic 9
 Events
• arrival(E, F, T)
– E in [1..n], F in [1..m], T ³ t0, (t0 initial time)
• does not say if it will stop or will proceed, nor where it comes from
• departure(E, F, D, T)
– E in [1..n], F in [1..m], D in {up, down}, T ³ t0
• stop(E, F, T)
– E in [1..n], F in [1.. m], T ³ t0
• stop to serve an internal or external request
• new_list(E, L, T)
– E in [1..n], L in [1.. m]* is the list of floors to visit associated with elevator
(scheduling is performed by the control component of the system)
• call(F, D, T) external call
• request(E, F, T) internal reservation

Descriptive Notations: Logic 10

 States

• moving(E, F, D, T1, T2)

• standing(E, F, T1, T2)
• list(E, L, T1, T2)
We implicitly assume that state predicates hold for any
sub-interval (i.e., the rules that describe this are
assumed to be automatically added)
Nothing prevents that it holds for a larger interval

Descriptive Notations: Logic 11

 Rules relating events and states

R1: When E arrives at floor F, it continues to move if there is

no request for service from F and the list is not empty.
If the floor to serve is higher, it goes up; otherwise down.

"E,F,Ta( arrival(E, F, Ta) Ù

∃L(∃T( list(E, L, T, Ta) )Ù
first(L) > F )
Þ
departure(E, F, up, Ta) )

A similar rule describes going down

Descriptive Notations: Logic 12

R2: Upon arrival at F, E stops if F must be serviced (F
appears as first of the list)

arrival(E, F, Ta) Ù
list(E, L, T, Ta) Ù
first(L) = F
Þ
stop(E, F, Ta)

R3: E stops at F if it gets there with an empty list.

arrival(E, F, Ta) Ù
list(E, empty, T, Ta)
Þ
stop(E, F, Ta)

Descriptive Notations: Logic 13

R4: Assume that elevators have a fixed time to service a floor.
If the list is not empty at the end of such interval, the elevator leaves
the floor immediately.

stop(E, F, Ta) Ù
list(E, L, T, Ta + Dts) Ù
first(L) > F
Þ
departure(E, F, up, Ta + Dts)

Descriptive Notations: Logic 14

R5: If the elevator has no floors to service, it stops until its list becomes
non empty.

stop(E, F, Ta) Ù
Tp > Ta+Dts Ù
list(E, empty, Ta+Dts, Tp) Ù
list(E, L, Tp, T) Ù
first(L) > F
Þ
departure (E, F, up, Tp)

Descriptive Notations: Logic 15

R6: Assume that the time to move from one floor to the next is
known and fixed (Dt). The rule describes movement.

departure(E, F, up, T)
Þ
arrival(E, F + 1, T + Dt)

R7: The event of stopping initiates standing for at least Dts.

stop(E, F, T)
Þ
standing(E, F, T, T + Dts)

Descriptive Notations: Logic 16

R8: At the end of the minimum stop interval Dts, E remains
standing if there are no floors to service.
stop(E, F, Ts) Ù
list(E, empty, Ts + Dts, T)
Þ
standing(E, F, Ts, T)

R9: Departure causes moving.

departure(E, F, D, T)
Þ
moving(E, F, D, T, T + Dt)

Descriptive Notations: Logic 17

 Control rules
• They express the scheduling strategy by describing
new_list events and list states
• Internal requests are inserted in the list from current
floor to top if the elevator is moving up
• External calls are inserted in the list of the closest
elevator that is moving in the correct direction, or in a
standing elevator

Descriptive Notations: Logic 18

R10: Reserving F from inside E, which is not standing at F,
causes immediate update of L according to previous policy.

request(E, F, TR) Ù
¬standing(E, F, Ta, TR) Ù
list(E, L, T, TR) Ù
LF = insert_in_order(L, F, E)
Þ
new_list(E, LF, TR )

Remember that, in this case,

¬standing(E, F, Ta, TR)
is an abbreviation for
¬$Ta(standing(E, F, Ta, TR))
Descriptive Notations: Logic 19
 R11: Effect of arrival of E at floor F. R2:
arrival(E, F, Ta) Ù arrival(E, F, Ta) Ù
list(E, L, T, Ta) Ù list(E, L, T, Ta) Ù
F = first(L) Ù F = first(L)
Lt = tail(L)
Þ Þ
new_list(E, Lt, Ta) stop(E, F, Ta)

R12: How list changes.

new_list(E,L,T1)Ù
¬(T1<T2<T3 Ù new_list(E,Ln,T2))
Þ
list(E, L, T1, T3)

abbreviation for
¬$T2Ln(…) Descriptive Notations: Logic 20
 Verifying specifications
• The system can be simulated by providing a state (set
of facts) and using rules to make deductions
• Example:
stop(2, 3, 5)
standing(2, 3, 5, 7)
elevator 2 at floor 3 at least from instant 5 to 7
list(2, empty, 5, 7)
request(2, 8, 7)
Þ new_list(2, {8}, 7)
Þ (excluding other events)
departure(2, 3, up, 7)
arrival(2, 8, 7+Dt*(8-3))
Descriptive Notations: Logic 21
 Verifying specifications

• Properties can be stated and proved via deductions

• Example:
new_list (E, L, T) Ù F Î L
Þ
new_list(E,L1,T1) Ù F Ï L1 Ù T1>T

(all requests are served eventually)

There is an implicit existential quantification, the part after Þ should be

read as
$ L1 T1(new_list(E,L1,T1) Ù F Ï L1 Ù T1>T)
Descriptive Notations: Logic 22
 Descriptive vs operational specs

• Operational specifications
– Different languages: one to describe the system and one to
define its properties
– (mostly) fully mechanized
• Descriptive specifications
– The system and its properties are described in the same
language
– Proving properties, however, cannot be fully mechanized for
most languages

Descriptive Notations: Logic 23