2. Index
1. Assumptions .............................................................................................................. 1
2. Modelling .................................................................................................................. 2
2.1 Floor State Variables......................................................................................... 2
2.2 Request variables ............................................................................................. 3
2.3 Movement Variables......................................................................................... 3
2.4 Door Control Variables ...................................................................................... 4
2.5 Transition Examples.......................................................................................... 4
3. Properties.................................................................................................................. 6
4. Verification Time......................................................................................................... 7
3. 1
1. Assumptions
According to the description of the required elevatorsystem, I made the following assumptions:
a. The elevator takes 2 time units to move between two consecutive floors. The whole moving
process between two consecutive floors, for example, from floor 1 to floor 2 includes 2 period.
First period, the moving period, which starts after the door is closed, takes 1 time unit. Second
period, the arriving period, after which the elevator will stop at floor 2 and the door will be
opened, happens right after the moving period. This assumption is showed as the figure 1.1.
Figure 1.1 Assumption on the movement between two consecutive floors.
b. When the OpenDoor button is pressed, the doorsremain open for an extra time unit. However,
the user should not be able to keep the door open infinitely often if there is a request for
service. This means there is a door opening time limit when there is a request, and I set this
time limit as 3 time unit. And I suppose there is a door closing state, in which whether the
Opendoor button is pressed or not can’t prevent the door from closing. So, if there is a request,
then after at most 3 time units the door of the elevator will be closed, as shown in figure 1.2.
Figure 1.2 Assumption on the door control when there is request
4. 2
2. Modelling
In order to model this elevator system, I defined some variables and simple transitions between
the states. In this section, I will describe the meaning of variables and show some basic transitions
which are set based on the requirement.
2.1 Floor State Variables
In this elevator system, I defined 5 variables to denote the state of floor for the elevator, as shown
in table 2.1:
Table 2.1 Floor state variables
Variable Meaning
F1 Elevator is staying at 1st floor.
F12 Elevator is ready to arrive either 1st floor or 2nd floor.
F2 Elevator is staying at 2nd floor.
F23 Elevator is ready to arrive either 2nd floor or 3rd floor.
F3 Elevator is staying at 3rd floor.
The simplified transitions between these states areshown in the figure 2.1 and figure 2.2.
Figure 2.1 Simplified floor state transitions (moving upward)
Suppose initially the elevator is staying at 1st floor (F1), and there is a request to go to 2nd floor,
then it will enter the F12 after moving period and then arrives at F2 state. And if there is only a
request to go to 3rd floor, then it will starts from F1 and then arrives F12 after 1 unit time of
movement and then arrives F23 after the second unit time of movement and finally arrives at F3.
If both 2nd floor and 3rd floor have requests then the transition will be F1->F12->F2->F23->F3.
For moving downward, things are same as moving upward just with the difference in direction. For
more complicated situations like while moving upward in F12 and have the request for F1, F2, and
F3 at the same time, I will discuss it later in section 2.3.
5. 3
Figure 2.2 Simplified floor state transitions (moving downward)
2.2 Request variables
Since there are two buttons for request of each floor, one is inside the elevator and the other is
outside, so I defined 6 Boolean variables to denote these requests. And they have the same
properties that once the variable is set to TRUE, which means there is a corresponding request, it
will not become FALSE until the required floor is served. For other cases, it can be TRUE or FALSE
non-deterministically. The code for the transition of variable inside1 (the request button inside the
elevator for 1st floor) is shown as the following:
next(inside1):=
case
state=F1:FALSE;
state!=F1&inside1:TRUE;
TRUE:{TRUE,FALSE};
esac;
2.3 Movement Variables
These variables record the movement state of the elevator, which can be used as the guide of the
next transition.
Table 2.2 Movement variables
Variable Meaning
direction The current moving direction, 1 means upward, 2 means downward, 0
means none.
predirection The moving direction of the previous state.
restime The rest time of movement between floors.
6. 4
The main reason to introduce the direction variable is to solve the complicated situationmentioned
in section 2.1. Suppose the elevator is going upwards between 1st floor and 2nd floor, and now we
have the request for every floors. So after the arrival of the 2nd floor, we need to decide whether
to go up to the 3rd floor first or down to the 1st floor first. If it is set to go down first, then the
elevator could just move between 1st floor and 2nd floor forever, thus the 3rd floor will never be
served. So I use the direction variable to denote the current moving direction. And in the case of
the complicated situation I just mentioned, the elevator will stick to the current direction, as going
up first to serve 3rd floor, and then go down (symmetrically, if there are requests for every floors, it
will not go upward againuntil it arrives at 1st floor).
And the restime variable is used to denote the rest time before its next arrival, so the range of its
value is {0, 1, 2}.
2.4 Door Control Variables
These variables are introduced for the controllment of the door during the operation of the
elevator.
Table 2.3 Door control variables
Variable Meaning
Opendoor It denotes the current pressed state of OpenDoor button, TRUE for pressed,
FALSE for non-pressed.
door It denotes the current door state, TRUE for opened, FALSE for closed.
doortime It records the door opened time to determine whether the elevator should
enter the door closing state.
Initially the doortime is set as 1, if there is request and the Opendoor is TRUE, then the door
remains opened and the doortime increased by 1. Either not pressing the OpenDoor button or the
doortime reaches 3 will set the doortime to 0 (door closing state, after which the door variable will
be set FALSE) in the next state. If there is no request, then the doortime will stay as 1. With the
combination of these three variables, the control of the door can be accomplished.
2.5 Transition Examples
Initially, set state=F1, door is TRUE, doortime=1, direction=0. And some basic transitions are shown
following:
Figure 2.3 Simple transition from 1st floor to 2nd floor
7. 5
As shown in the figure 2.3, the most straight forward operation of the elevator, which is simply
moving from 1st floor to 2nd floor, no other buttons pressed. It first enters the door closing state,
and then after the door is closed, it moves upward. After 1 time unit, it is ready to arrive 2nd floor
with 1 time unit left, and then the floor stateturns to F2 and the door opens at the next state,
the moving direction is set back to 0, and in the state after that, the request is served.
Figure 2.4 Simple transition from 1st floor directly to 3rd floor.
The movement from 1st floor directly to the 3rd floor is shown in figure 2.4. As can be seen, the
difference is on the restime variable and the transition of the floor statevariables.
Figure 2.5 Transition for the complicated situation discussed in section 2.3.
And the figure 2.5 shows the details of the situation mentioned in the section 2.3. The elevator
takes advantageof the direction variable to ensure the liveness of system on requests, which is
the requests of the elevator will be served eventually.
Figure 2.6 Transition of the door control function
8. 6
And the figure 2.6 shows the details of the transitions for door control when there is request for
the elevator and the OpenDoor button is keeping pressed. From the picture, it can be seen that
the elevator can stayed opened at most for 3 time units before it goes to door closing state.
3. Properties
For the properties mentioned in the description of the assignment, I have the following CTL
specifications:
a. Calls to the elevatorfrom floors (i.e., floor button) areeventually serviced.
AG ((outside1 -> AF (state=F1&door)) & (outside2 -> AF (state=F2&door)) & (outside3 -> AF
(state=F3&door)))
b. Calls from within the elevator (elev. button) are eventually serviced.
AG ((inside1 -> AF (state=F1&door)) & (inside2 -> AF (state=F2&door)) & (inside3 -> AF
(state=F3&door)))
c. The elevator never moves with its doors open.
AG ((state=F12 | state=F23) -> !door)
d. The elevator doors remain open until there is a request to use it.
AG (!(outside1|outside2|outside3|inside1|inside2|inside3)-> door & AX door)
e. It takes exactly 2 time units for the elevator to move between two consecutive floors.
AG(((state=F1)&!door&(inside2|outside2)-> AX ((state!=F2)&!door) & AX AX ((state=F2)&
door))&((state=F3)&!door&(inside2|outside2) -> AX ((state!=F2)&!door) & AX AX ((state=F2)&
door))&((state=F2)&!door&(inside3|outside3)& direction=1 -> AX ((state!=F3)&!door) & AX
AX((state=F3)&door))&((state=F2)&!door&(inside1|outside1)&direction=2->AX((state!=F1)&!
door) & AX AX ((state=F1)& door)))
f. If there areno requests for another floor, the elevator should not move.
AG(((state=F1)& !(outside2|outside3|inside2|inside3)-> AX (state=F1)) &
((state=F2)& !(outside1|outside3|inside1|inside3)-> AX (state=F2)) &
((state=F3)& !(outside2|outside1|inside2|inside1)-> AX (state=F3)))
g. The elevator cannot change direction between floors.
AG(( state=F12|state=F23) -> predirection=direction)
The additional specification and the corresponding CTL arethe following:
1. If there is request, and the Opendoor button is pressed, within the time limit the door can
remain open for a certain time.
AG (((state=F1)&(outside2|outside3|inside2|inside3)&Opendoor&(doortime>0)&door ->
AX(state=F1)&door)|((state=F2)&(outside1|outside3|inside1|inside3)&Opendoor&(doortim
e>0)&door->AX(state=F2)&door)|((state=F3)&(outside2|outside1|inside2|inside1)&Opendo
or&(doortime>0)&door -> AX(state=F3)&door))
2. The door will be closed within 4 steps when there is request to other floors even the Opendoor
button is pressed.
AG((((state=F1)&(outside2|outside3|inside2|inside3))|((state=F2)&(outside1|outside3|insid
e1|inside3))|((state=F3)&(outside2|outside1|inside2|inside1)))&Opendoor&door -> AX
(!door|AX(!door|AX(!door|AX(!door)))))
9. 7
4.Verification Time
Since the door will remain opened when there is no request to other states, and the door will enter
the closing state, where the door must be closed in next state. So the situation that the request for
the current floor keep happening won’t result in the forever suspension at some floors. All I need
for the correct model checking of the specifications is to ensure the predication of every
implication in the CTL specification holds. So I set the FAIRNESS constraints of the test paths on
those implications.
With the constraints on the test paths, the verification for all 9 specification is run and the total
running time is 0.18s.
