The slides of our paper presented at The 2015 International Conference on Software Engineering Research and Practice. The paper can be found here, https://www.researchgate.net/publication/290325167_Modeling_Elevator_System_With_Coloured_Petri_Nets

1. MODELING
ELEVATOR
SYSTEM
WITH
COLOURED
PETRI
NETS
Assiri
M.,
Alqarni
M.,
and
Janicki
R.
1

2. 1. Introduction
2. The Elevator System
3. Coloured Petri Nets
4. CPN-based Modelling of Elevator System
5. Analysis
6. Conclusion
Outline:
2

3. • The elevator system is one of the software engineering benchmarks
[Ghezzi et al. (2003)]*
• It has been modeled many times the in past and that includes Petri Nets:
1. Petri net based dynamic scheduling of an elevator system [Lin and Fu
(1996)].
2. Dynamic scheduling of elevator systems over hybrid Petri net/rule modeling
[Huang and Fu (1998)].
3. Timed Petri net based approach for elevator group controls [Cho et al.
(1999)].
4. Abstract Petri net based approach to problem solving in real time
applications [Etessami and Hura (1989)]
5. Petri net-based modeling and control of the multi-elevator systems
[Ahmad et al. (2014)]
6. Simulation of the intelligent control circuit based on Petri net [Ye et al.
(2011)].
* Fundamentals of Software Engineering. Pearson Prentice Hall, 2nd edition.
1. Introduction
3

4. 7. Requirements Engineering for Reactive Systems: Coloured Petri
Nets for an Elevator Controller [Fernandes et al. (2007)]
8. Modeling and analysis of elevator system based on timed-Coloured
Petri net [Liqian et al. (2004)]
Nevertheless, all of these previous models are either static or dependent on a
particular number of elevators and floors, the concept of colour as a data type
was not fully utilized, or other formalisms such as UML were substantially
involved.
Our model is independent of the number of floors and elevators and
covers different stages of the elevator system in substantial detail.
We believe our model is flexible enough to be adapted to different
algorithms and rules, and may eventually evolve into a ’standard’
formal model of the elevator system.
1. Introduction (Cont.)
4

5. Ø Integral aspect of buildings from the point at which they are first
designed
Ø The complexity of these elevator systems arises from factors such
as scheduling needs, resource allocation, and stochastic control, to
name a few. Handling these jobs usually results in systems
behaving as discrete event systems [P. J. Ramadge et al. (1989)]*
Ø The elevator system is usually defined as follows [Ghezzi et al.
(2003)]**: (next slide)
* The control of discrete event systems,” in Proceedings of the IEEE 77.1, 1989, pp. 81–98.
** Fundamentals of Software Engineering. Pearson Prentice Hall, 2nd edition.
2. The Elevator System
5

6. An elevator system is to be installed in a building with m floors and n cars. The
elevator and the control mechanisms are supplied by the manufacturer. The
problem concerns the logistics of moving cars between floors according to the
following :
a. Each elevator’s car has a set of buttons - one for each floor. Pressing
these buttons signals the elevator to move to the corresponding floor.
b. On the wall outside the elevator each floor has two buttons (with the
exception of the ground and the top floors). One button is pressed to
request an upward moving elevator and another button is pressed to
request a downward moving elevator. If both buttons are pressed, then
each direction is assigned to a different car.
c. When an elevator has not received any requests for service, it should be
held at its parking floor with its doors closed until it receives further
requests.
d. All requests for elevators from floors (i.e. hall calls) must be serviced
eventually. The applied algorithm controls the priority of floors. All requests
for floors within elevators (i.e. car calls) must be serviced eventually, with
floors usually serviced sequentially in the direction of travel.
e. Each elevator’s car has an emergency button which when pressed causes
an alarm. The elevator is then deemed "out of service". Each elevator has
a mechanism to cancel its "out of service" status.
v The Definition:
6

7. • Coloured Petri Nets (CPN) [Jensen (1981)*] are an extension of Petri Nets
which are often used to model behaviours of rather complex systems.
• CPN have preserved the useful properties of Petri Nets while at the same
time extending the initial formalism to allow for distinction between tokens.
• It is a graphical language for constructing models of concurrent systems
and analyzing their properties.
* Coloured Petri Nets and the Invariant Method, Theoretical Computer Science
3. Coloured Petri Nets
7

8. • CP-nets is a discrete-event modelling language combining the capabilities
of Petri Nets with the capabilities of a high-level programming language.
• Petri Nets provide the foundation of the graphical notation and the basic
primitives for modelling concurrency, communication, and synchronisation.
• Coloured Petri Nets allow tokens to have a data value attached to them.
This attached data value is called token colour. Although the colour can be
of any arbitrarily complex type, places in CPNs usually contain tokens of
one type. This type is referred to as the colour set of the place.
• CPN support hierarchical modeling and are equipped with a modeling
language called CPN ML which is based on the standard functional
programming language ML.
3. Coloured Petri Nets (Cont.)
8

9. • Semi-formal definition:
A Coloured Peter Net is a tuple :
CPN = (P,T,A,Σ,C,N,E,G,I)
• For more details and theory of CPN, please refer to Coloured Petri Nets
Modelling and Validation of Concurrent Systems by Jensen and
Kristensen (2009)
v Definition
9

10. 4. CPN-based Modelling of Elevator System
10

11. 4.1. Car-Structure Sub-Model
11
CarsCarsCars DatabaseDatabaseDatabase
Database
initialize_database()
Cars
initialize_cars()

12. Colour
Sets
Defini1ons
Car
ID
{
i
|i
∈
Z+
∧
i
≤
total
number
of
cars}
Range
{
r
|
r
∈
Z+
∧
lowest
floor
≤
r
≤
highest
floor}
Status
{
idle,
emergency,
out
of
service,
up,
down
}
Desired
Floors
{
[l]
|
l
∈
Range}
Call
Issuer
{
request,
system,
non,
reservacon}
Cars
{
(car
id,
current
floor,
status,
parking
floor,
desired
floors,
call
issuer)
|
car
id
∈
Car
ID,
current
floor
∈
Range,
status
∈
Status,
parking
floor
∈
Range,
desired
floors
∈
Desired
Floors,
call
issuer
∈
Call
Issuer}
v The Definition of The Colour Set “Cars”
12

13. 13
The initial value of the parking floor is calculated generally by:
1. Floors′ Number = (highest floor − lowest floor ) + 1
2. Scope = |floors′ number ÷ cars′ number|
3. Scope Head = ((scope ∗ car id) − (scope − 1)) + (lowest floor′s − 1)
4. Scope Tail = (scope ∗ car id) + (lowest floor − 1)
∴ Spot(car id) = scope′s head (car id)

14. Colour
Sets
Defini1ons
Car
Info
{(current
floor,
status,
descnacons,
car
id)
|
current
floor
∈
Range,
status
∈
Status,
descnacons
∈
Desired
Floors,
car
id
∈
Car
ID}
Database
{[d]
|
d
∈
Car
Info}
v The Definition of The Colour Set “Database”
14

15. 4.2 The Hall-Call Sub-Model
15
counter
selected
floor's num
requested call
floor's
number
CarsCars
DatabaseDatabasePrk SysPrk SysPrk Sys
all floors'
numbers
watch
generators
log
Release Random
Number
Release
Assign Hall Call
Assign
Direction
n
rn_random()
new_call
new_call
car
hall_call
snd_hcall
(car,hall_call)
n+1
i i-1
i
i new_call
hall_call
i
i+1
asn_dir(new_call)
hall_call
db
upd_db
(hall_call,
db,car)
INT
1`1
()
Range
Range
selected_floor
INT
1`1
Hall_Call
Hall_Call
[rn_guard(n,i)]
[r_guard(i)]
[asn_hcall_guard
(hall_call,car,db)]
Hall_Call
Database
Database
initialize_database()
initialize_cars()
Cars
Cars

16. v The Processing of Hall-Calls
16
requested call
Hall_Call
CarsCars
initialize_cars()
DatabaseDatabase
initialize_database()
Prk SysPrk Sys
Hall_Call
log
Hall_Call
Assign Hall Call
[asn_hcall_guard
(hall_call,car,db)]
car
hall_call
snd_hcall
(car,hall_call)
hall_call
hall_call
db
upd_db
(hall_call,
db,car)
Hall
Call
{(hall
call
floor,
status)
|
hall
call
floor
∈
Range,
status
∈
Status}

17. 17
The Rules
1. The selected car is either idle or
travelling toward the direction of the hall call,
2. The selected car is not reserved, and
3. The selected car is elected by the applied algorithm.

18. v The Processing of Hall-Calls
18
requested call
Hall_Call
CarsCars
initialize_cars()
DatabaseDatabase
initialize_database()
Prk SysPrk Sys
Hall_Call
log
Hall_Call
Assign Hall Call
[asn_hcall_guard
(hall_call,car,db)]
car
hall_call
snd_hcall
(car,hall_call)
hall_call
hall_call
db
upd_db
(hall_call,
db,car)
Hall
Call
{(hall
call
floor,
status)
|
hall
call
floor
∈
Range,
status
∈
Status}

19. v The Adopted Algorithms:
19
• The nearest-car algorithm [Barney (2003)*]:
1. Analysing the token of place Database.
a. The cars with proper status are extracted from the token.
b. The distances between hall-call floor and cars’ current floors are calculated.
2. The hall call is assigned to the car with minimum distance to the hall call floor.
• The minimum waiting algorithm:
3. Calculating the stop times consumed by the already placed and being served calls
between the floor of the new hall call and each car’s current floor.
4. The car with the expected minimum waiting-time is assigned to serve the new hall call
• The scope algorithm:
H ≤ A ≤ T.
where:
H = the head floor of car’s scope
A = the answered hall-call floors
T = the tail floor of car’s scope
* Elevator Traffic Handbook: Theory and Practice.

20. v Producing Floors’ Numbers:
20
counter
selected
floor's num
floor's
number
all floors'
numbers
watch
generators
Release Random
Number
Release
n
rn_random()
new_call
new_call
n+1
i
i
INT
1`1
()
Range
Range
selected_floor
INT
1`1
[rn_guard(n,i)]
[r_guard(i)]

21. v The Parameters of Hall-Call Sub-Model
21
Parameters
Legal
values
Producing
mode
{finite,
infinite}
Times
of
finite
hall
calls
{y
|
y
∈
Z
∧
0
≤
y}
The
most
requested
floor
{r
|
r
∈
Range}
Duplicacon
of
most
requested
floor
{d
|
d
∈
Z
∧
0
≤
d}
The
applied
algorithm
{minimum
waicng,
nearest,
scope}
Producing’
pause
number∗
{p
|
p
∈
Z
∧
0
<
p}

22. v Associating Floors’ Numbers with Directions
22
requested call
floor's
number
Assign
Direction
new_call
asn_dir(new_call)
Range
Hall_Call

23. 23
• If the produced number equates the highest floor, then it is associated
restrictedly with the down direction,
• Else if the produced number equates the lowest floor, then it is associated
restrictedly with up direction.
• Otherwise, a produced number is associated non-deterministically with up
direction or down direction.
ü Thus, a hall call of a valid floor’s number and an appropriate direction is
produced correctly and completely.

24. 4.3 The Car-Call Sub-Model
24
CarsCarsCars log
car call
all floors'
numbers
counter
specific
floors' num
DatabaseDatabase
watch
generator
Coordinate
Release Floor's Number
Reproduce
archive(car,car_call,
new_call,sf)car_callcar
snd_ccall(car,
new_call,sf)
new_call
rn_random()
n+1
n
sf
place_calls
(car,sf)
db
upd_db_
(new_call,
db,car,sf)
i+1
i
i
i-1
car_call
reproduce(sf)sf
car
INT
1`1[rfn_guard(n,i)]()
RangeINT
1`1
Specific_Floors
initialize_sfloors()
[rep_guard
(sf,car,car_call)]
0Car_Calls
initialize_log()initialize_cars()
CarsDatabase
initialize_database()
[coord_guard(car_call,car,sf,new_call)]
Database

25. v The Coordination between Cars and Car-Calls
25
CarsCars log
car call
specific
floors' num
DatabaseDatabase
Coordinate
archive(car,car_call,
new_call,sf)car_callcar
snd_ccall(car,
new_call,sf)
new_call
sf
place_calls
(car,sf)
db
upd_db_
(new_call,
db,car,sf)
Range
Specific_Floors
initialize_sfloors()
Car_Calls
initialize_log()initialize_cars()
CarsDatabase
initialize_database()
[coord_guard(car_call,car,sf,new_call)]
Specific
Floors
{(car
id,
specific
calls,
repeated
cmes)
|
car
id
∈
Car
ID,
Specific
calls
∈
Desired
Floors,
repeated
cmes
∈
Z}

26. v Producing Car-Calls
26
car call
all floors'
numbers
counter
watch
generator
Release Floor's Number
rn_random()
n+1
n
i+1
i
INT
1`1
[rfn_guard(n,i)]()
RangeINT
1`1
specific
floors' num
Reproduce
reproduce(sf)sf
Specific_Floors
initialize_sfloors()
[rep_guard
(sf,car,car_call)]

27. v The Parameters of Car-call Sub-model
27
Parameters
Legal
values
Producing
mode
{finite,
infinite}
Times
of
finite
car
calls
{x
|
x
∈
Z
∧
0
≤
x}
Most
desired
floors
{[f]
|
f
∈
Range}
Frequency
of
desired
floors
{d
|
d
∈
Z
∧
0
≤
d}
Producing
pause
number
{p
|
p
∈
Z+
}

28. 4.4 The System-Cycle Sub-Model
28
CarsCars
Cars
initialize_cars()
Cars
out of service
Cars
error log
Cars
DatabaseDatabase
Database
initialize_database()
Databasesuccess log
Cars
Doors
Doors
initialize_doors ()
Database
Database
initialize_database()
Database
Maintain
[mnt_guard(car)]
0
Restart
[rst_guard(car)]
Transfer
[trn_guard(car)]
Arrive
[arr_guard(car,door)]
suspend
(car)
car
car
car
restart(car)
car
transfer(car)
upd_trn(car,db) db
cararrive(car)
car
doordoor
upd_arr(car,db)
db
upd_susp
(car,db)
db
db upd_rst
(car,db)

29. Parameters
Legal
values
Cars’
number
{n
|
n
∈
Z+}
Lowest
floor
number
{f
|
f
∈
Z+
∧
f
<
highest
floor}
Highest
floors
number
{h
|
h
∈
Z+
∧
lowest
floor
<
h}
v The Parameters of System-Cycle Sub-Model
29

30. v The Maintenance Stage
30
CarsCars
out of service
error log
Database
Database
Maintain
Restart
suspend
(car)
car
car
car
restart(car)
upd_susp
(car,db)
db
db upd_rst
(car,db)
Cars
initialize_cars()
[rst_guard(car)]
Cars
initialize_database()
[mnt_guard(car)]
0
Cars
Parameter
Legal
value
Restart
pending
cars
automaccally
{”yes”,”no”
}

31. v The Transition Stage
31
CarsCars
DatabaseDatabase
Database
Transfer
car
transfer(car)
upd_trn(car,db) db
Cars
initialize_cars() [trn_guard(car)]
initialize_database()

32. v The Arrival Stage
32
CarsCars
Cars
initialize_cars()
DatabaseDatabase
Database
initialize_database()
success log
Cars
Doors
Doors
initialize_doors ()
Arrive
[arr_guard(car,door)]
cararrive(car)
car
doordoor
upd_arr(car,db)
db

33. 4.5 The Parking Optimizer Sub-Models
33
• Holding idle cars on or near floors where most hall-calls are placed
substantially improves passenger satisfaction and the system’s energy
usage and efficiency [Barney (2003)]*.
• Therefore, cars are initially distributed in fair distances between the lowest
and highest floors. Subsequently, the parking optimizer sub-models
continuously analyse the placed hall-calls and then assign the elected
floors to the cars.
• The parking optimizer models include the election sub-model and the
position sub-model.
* Elevator Traffic Handbook: Theory and Practice.

34. v The Election Sub-model
34
elected floor
counter
INT
1`1
sorted
list
INT_List
1`[]
candidate
floors
Floors_Statistics
processed
call counter
INT
1`0
floors
statistics
Floors_Statistics
initialize_statistics()
Prk SysPrk Sys
Hall_Call
Prk Sys
elected floors
Out
Range
Out
Lock SysLock Sys
INT
1`0
Lock Sys
Elect Floor
[elect_guard(tl,n,fs)]
3
Sort Floors' Recursion
[sort_guard(n,fs)]
2
Count Call
[count_guard(hall_call,fs,n,i)]
1
Sweepe Unelected
Floors
5
upd_pcc(n,i,tl)
hall_call
upd_efc(tl,n)
fs
fs
n
update_list(tl,n)
n
count(hall_call,fs)
i
tlsort_recursion(fs,tl)
n fsn+1
tl
update_statistics(fs)
(#floor fs)
i
1i
fs
fs

35. v The Position Sub-model
35
scopes
req
times
Scope_Statistics
cmpl
nxt
cmpl
orders
cmpl
prv
elected floors
In
Range
new
position
Identified_Floor
CarsCars
Cars
Lock SysLock Sys
Identify Scope
Count Scope's
Elected Floors
Identify Next
Scope
Decide Position
Identify Previous
Scope
Alter Car's
Parking Floor
s
s
identify_prv(s,t)
identify(s,floor)
s
s
identify_nxt(s,t)
s
count_floors(s)
decide(s)
f
car alter(car,f)
iunlocksys(i)
ii+1
t
t
floor
s
re_initialize(i)
n
INT
1`0
[scope_guard(s,floor)]
4
Scope
initialize_scope()
[n<>0]
6
Scope
[prv_guard(s,t)]
7
Scope
[nxt_guard(s,t)]
8
Scope
9
In
[alter_guard(car,f)]
10
Cars
Lock Sys
initialize_cars()

36. 5. Analysis
36
• Two analyses techniques were applied:
1. The first technique is the reachability analysis by means of the State Space tool:
This tool verified and generated an automatic report,
Ø The proposed model has dead markings that occur in cases such as a
placed hall-call with no available car.
Ø Transition Maintain and transition Restart are dead transitions which indicate
no operation failure of the proposed model.
2. The second technique is the simulation-based analysis by means of CPN Tools.
• Although this technique is flexible, it is also time-consuming.
• However, the proposed model was simulated repeatedly with different
settings, and the entire definition of the system was achievable.

37. 6. Conclusion
37
• We have provided a fairly general CPN-based model of the elevator system.
• The model covers various aspects of the elevator system and is divided into
five sub-models that can be analyzed independently.
• Such division allows for easier tracking of errors and faults in the elevator
system.
• The flexibility of the model allows for easy adaptation of different algorithms
and rules depending on the actual needs.

38. ü Questions
38