BANGLADESH RESEARCH PUBLICATIONS JOURNAL

ISSN: 1998-2003, Volume: 5, Issue: 4, Page: 402-411, July -August, 2011

FORMAL VERIFICATION OF REQUIREMENTS ENGINEERING
OF ROAD TRAFFIC CONTROL SYSTEM USING PETRI NETS
Kamruddin Md. Nur
1

Kamruddin Md. Nur (2011). Formal Verification of Requirements Engineering of Road
Traffic Control System Using Petri Nets. Bangladesh Res. Pub. J. 5(4): 402-411. Retrieve from
http://www.bdresearchpublications.com/admin/journal/upload/09250/09250.pdf
Abstract
A centralized road traffic management system aims at managing all
traffic lights of a geographical area concurrently in order to minimize
overall traffic congestion. An Automated Centralized Road Traffic
Control System (ACRTCS) involves detecting, communicating and
managing all traffic lights of the particular geographical area to
maintain least traffic congestion at all intersections. By nature, Traffic
intersections are discrete, partially observable, stochastic, episodic,
dynamic and continuous. For a high volume traffic intensive geographic
area, a robust, stable and reliable traffic control system is scarce. This
paper presents a formal verification of the Petri Net design model based
on requirements of a high quality automated centralized traffic control
system using Petri Net simulator HPSim, which detects traffic volume at
different traffic intersections, communicates with other intersections and
finds the best traffic routing in a busy geographic area.
Key Words: Formal Verification of Requirements Engineering; Formal Verification of
Requirements Engineering of Traffic Control System; Software Requirements
Engineering.
Introduction
A busy traffic intensive area may have hundreds of roads on which
thousands of vehicles running each day. Traffic lights are put in place in order to
avoid traffic congestion. Traffic congestion may get influenced by a variety of
factors including number of vehicles, hour of the day, road capacity, entry or exit
point of the area etc. The desired road traffic control system of a traffic intensive
geographical area is required for minimal traffic congestion by overcoming all
factors hindering a smooth traffic control. The desired system should optimize
traffic control and ensure smooth traffic flow among intersections. A centralized
real time traffic control is required in order to monitor and manage traffics
automatically as well as preempt traffic flow directions manually when necessary
in case of emergency and importance and thus achieve the optimal resource
usage. At present, all traffic lights are timed control traffic lights with no
intersection to intersection communication in place. There is no sensor in place for
traffic detection or traffic light signal change (RED light to GREEN light and vice
versa). Typical traffic intersections shape could be in two basic form, a '+' shape
or a 'T' shape. A roundabout is considered as '+' shape and a 'K' shape
intersection is formed when two 'T' shape intersection merges.

Corresponding Authors email: kamruddin.nur@gmail.com
1Senior Lecturer, Department of Computer Science, Stamford University Bangladesh.
Road Traffic Control System Using Petri Nets
http://www.bdresearchpublications.com/journal/
403










Fig. 1. Typical Traffic Intersections
ACRTCS Requirements
An Automated Centralized Road Traffic Control System (ACRTCS) has two
high level requirements traffic lights requirements, controller requirements, and
sensor requirements whose details are presented below -
Requirements 1. Traffic lights requirements
A traffic light should direct traffics to {straight + left} or {right}. A '+' shape
traffic light should have two sets of traffic lights each having two light post
in each set. A T shape traffic light has three sets of traffic lights each
having a one light post. A roundabout traffic lights have similar to a '+'
shape traffic intersection.











Fig. 2. Typical Traffic Intersection Types ('+' shape and 'T')

Requirements 2. traffic controller requirements
There are both local and central traffic signal change controllers. The local
controller of a particular intersection (node) detects traffic volume from the
sensor and looks up the intersection controller table (Table 1) for signal
processing as well as waits for central control system to inform the traffic
volume status of the neighbor intersections for better decision making. The
central controller system has all intersections (nodes) in its decision table
(Table 2).
Table 1. Typical Intersection (node) decision table
N (=Node_ID)
L1 (=Light Set 1) L2 (=Light Set 2) L3 (=Light Set 3) D (=Direction)
1 Red Green - Straight

Kamruddin Md. Nur
http://www.bdresearchpublications.com/journal/
404
Table 2. Typical central controller decision table having all node status Table 2. Typical central controller decision table having all node status
N (=Node_ID) N (=Node_ID) L1 (=Light Set 1) L1 (=Light Set 1) L2 (=Light Set 2) L2 (=Light Set 2) L3 (=Light Set 3) L3 (=Light Set 3) D (=Direction) D (=Direction)
1 Red Green - Straight
2 Red Green - Right
3 Green Red Red Straight
4 Red Green Red Right
5 Red Green - Straight
A local controller decision table is programmable hardware and a central
controller is software developed with a high-level programming language for real
time decision making algorithm calculation.
Requirements 3. traffic sensor requirements
Sensor senses traffic volume and report local controller as well as central
controller. A local controller makes decision with the help of central
controller. In case, central controller unreachable by local controller, the
local controller makes decision on its own indicating central controller is
unreachable.
Methodology
At first, an ideal software system whose behavior is discrete, partially
observable, stochastic, episodic, dynamic and continuous such as ACRTCS is
chosen and specified. Then an ideal Petri Net simulator HPSim is selected in order
to design discrete event system (DES) models according to requirements. Then all
working DES models are run and behaviors are observed with HPSim simulator.
After visually satisfied observation of each DES models, corresponding Incidence
matrix analysis are presented for the mathematical verification of requirements.
Petri Nets
A Petri net (also known as a place/transition net or P/T net) is a graphical
and mathematical modeling tools for many systems including distributed systems
(Murata 1989, DiCesare et. al. 1993, Desrochers and Al'Jaar, 1995, Proth and Xie,
1997, Reisig 1998, Zhou and Venkatesh, 1999). A Petri net is a directed bipartite
graph, in which the nodes represent transitions and places. The directed arcs
describe which places are pre- and/or postconditions for which transitions
signified by arrows. As a mathematical tool, it is possible to compute state
equations, algebraic equations, incidence matrix etc. in order to verify a system
behavior with simulators before actually a system is built. Formally, a Petri Net is a
5-tuple (Murata 1989), PN = (P, T, F, W, M0) where -
P = {p1, p2, ., pm} is a finite set of places ,
T = {t1, t2, ., tn} is a finite set of transitions ,
is a set of arcs ,
W: F {1,2,3,...} is a weight function ,
M0: P {0,1,2,3,...} is the initial marking,
P T = , P U T
Road Traffic Control System Using Petri Nets
http://www.bdresearchpublications.com/journal/
405
A petri net structure without any initial marking is denoted by N = (P, T, F,
W), and a petri net with a given initial marking is denoted by (N, M0). A petri net
models are a effective and useful means of system verification where a system is
discrete, partially observable, stochastic, episodic, dynamic and continuous
(Murata, 1989, Haas, 2002) such as ACRTCS.
Requirements Modeling With Petri Nets
The low-level requirements (LLR) of discrete event system (DES) models
(decomposed from high-level requirements discussed earlier) of ACRTCS is shown
below -
LLR1: Global sense polling
Transitions:
T6 = Sense State from global table
Places:
P1 = Global Sense Output buffer
P8 = Global Sense Input Buffer
Fig. 3. Global Sense Polling
LLR2: Distributing Global Sense
Transitions:
T0 = Distribute Global Sense
Places:
P1 = Input buffer
P2 = Local Sensor input buffer
P5 = global sensor input buffer
Fig. 4. Distributing Global Sense
LLR3: Broadcasting Present Light State
Transitions:
T1 = Change Local Light State
Places:
P0 = Present Light State
P2 = Input state from global table
P3 = Possible Light State
Fig. 5. Broadcasting Present Light State
Kamruddin Md. Nur
http://www.bdresearchpublications.com/journal/
406
LLR4: Light State Change Sequence
Transitions:
T0 = RED to GREEN
T1 = GREEN to ORANGE
T2 = ORABGE to RED

Places:
P0 = RED
P1 = GREEN
P2 = ORANGE
Fig. 6. Light State Change Sequence
LLR5: Local State Table Lookup

Transitions:
T2 = lookup local state table
Places:
P3 = state before lookup
P4 = state after lookup
Fig. 7. Local State Table Lookup
LLR6: Global State Table Lookup
Transitions:
T5 = lookup global state table
Places:
P6 = state before lookup
P7 = state after lookup
Fig. 8. Global State Table Lookup
LLR7: Unison Decision Making Using Local and Global Decision
Transitions:
T3 = unison state change and
broadcast using local and global
decision input
Places:
P4 = local state decision
P7 = global state decision
P8 = notify global table
P0 = notify the present state buffer
Fig. 9. Unison Decision Making Using Local and Global Decision
Road Traffic Control System Using Petri Nets
http://www.bdresearchpublications.com/journal/
407
LLR8: Sensor Poll and Communication
Transitions:
T0 = spool sense
T1 = send / receive sense
T2 = spool sense
T3 = send / receive sense

Places:
P0 = sense buffer
P1 = spooled sense buffer
P2 = temp buffer of send / receive
P3 = temp buffer of send / receive
P4 = sense buffer
P5 = spooled sense buffer
Fig. 10. Sensor Poll and Communication
LLR9: Unison Local and Global Traffic Light State Change

Transitions:
T0 = change state,
GREEN local & GREENglobal = GREEN
T1 = change state,
GREEN local AND REDglobal = RED
T2 = change state,
RED local AND GREENglobal = GREEN
T3 = change state,
RED local AND REDglobal = RED

Places:
P0 = local GREEN state
P1 = local RED state
P2 = global GREEN state
P3 = global RED state
P4 = Final state (GREEN or RED)
Fig. 11. Unison Local and Global Traffic Light State Change
LLR10: Two-set Traffic Light State Change

Transitions:
T0 = change RED to GREEN (set 1)
T1 = change GREEN to ORANGE (set 1)
T2 = change ORANGE to RED (set 1)
T3 = change RED to GREEN (set 2)
T4 = change GREEN to ORANGE (set 2)
T5 = change ORANGE to RED (set 2)

Places:
P0 = light set 1 RED
P1 = light set 1 GREEN
P2 = light set 1 ORANGE
P3 = light set 2 RED
P4 = light set 2 GREEN
P5 = light set 2 ORANGE
P6 = communication buffer
Fig. 12. Two-set Traffic Light State Change

Kamruddin Md. Nur
http://www.bdresearchpublications.com/journal/
408
Formal Verification Analysis with Petri Nets
A major strength of Petri net is their support for analysis and of many
properties and problems associated with concurrent systems (Murata1989, Girault
and Valk 2002). Two major types of properties can be studies with Petri nets
behavioral properties and structural properties. Behavioral properties are marking
depended; those are depended on initial marking and structural properties are
marking independent. Through simulation we can test our Petri Net model work as
desired. Simulation gives logical visual feedback of how it is working and how it
should work according to the requirements. A good simulator like HPSim (Petri
Nets tools, 2011) helps identifying places, transitions, arcs and their corresponding
weights. A DES model simulation helps identifying early design mistakes or
limitations before actual implementation. Basic behavioral properties that could
be studied are -
Reachability
A marking Mn is said to be reachable from a marking M0 if there exists a
sequence of firings that transforms M0 to Mn. A firing or occurrence sequence is
denoted by = M0 t1 M1 t2 ... Mn tn
Boundedness
A Petri net (N, M0) is said to be k-bounded or simply bounded if the number of
tokens in each place does not exceed a finite number k for any marking
reachable from M0, i.e., M (p) k for every marking M R (M0).
Liveliness
Liveliness refers to the concept of complete absence of deadlock. A Petri net
(N, M0 ) is said to be live, if no matter what marking has been reached from
M0, it is possible to ultimately fire any transition of the net by progressing
through some further firing sequence.
Reversibility and Home State
A Petri net (N, M0) is said to be reversible; if for each marking M in R (M0) is
reachable from M.
Synchronic Distance
Synchronic distance is a measure of degree of mutual dependence between
two events (i.e. transitions) in a condition / event system.
Simulation and Results
In this section we present the outcome of the low level requirement (LLR)
model simulation with HPSim (HPSim Simulator, 2011) incidence matrix analysis
result which shows the no traps and flawless system work and thus verifies
requirements formally.
Mathematically, incidence matrix analysis is able to detect if there is any
blocking or deadlock in the system which verifies the works as requirements
specified. A net is pure if it has no seloops, i.e., if [P re (p, t) = 0 P ost (p, t) = 0]
for every place p and for every transition t. If a net is pure the incidence functions
Road Traffic Control System Using Petri Nets
http://www.bdresearchpublications.com/journal/
409
can be represented by a single matrix, the incidence matrix of the net, dened as
C (p, t) = P ost (p, t) P re (p, t) (Giua and DiCesare, 1994a, Murata 1989).
The preset and postset of a transition t are respectively
t = {p P | P re (p, t) > 0},
t = {p P | P ost (p, t) > 0}.
The preset and postset of a place p are respectively
p = {t T | P ost (p, t) > 0},
p = {t T | P re (p, t) > 0}.

A trap is a set of places T P such that



Table 3. Incidence Matrix for LLR7
Incidence Matrix

T3
P0 1
P4 -1
P7 -1
P8 1
Current Marking
P0 P4 P7 P8
0 1 1 0
Table 4. Incidence Matrix for LLR8
Incidence Matrix

T0 T1 T2 T3
P0 -1 1 0 0
P1 1 -1 0 0
P2 0 1 0 -1
P3 0 -1 0 1
P4 0 0 -1 1
P5 0 0 1 -1
Current Marking

P0 P1 P2 P3 P4 P5
1 0 0 1 0 1
Table 5. Incidence Matrix for LLR9
Incidence Matrix

T0 T1 T2 T3
P0 -1 -1 0 0
P1 0 0 -1 -1
P2 -1 0 -1 0
P3 0 -1 0 -1
P4 1 1 1 1
Current Marking

P0 P1 P2 P3 P4
1 0 0 1 0

Kamruddin Md. Nur
http://www.bdresearchpublications.com/journal/
410
Table 6. Incidence Matrix for LLR10
Incidence Matrix

T0 T1 T2 T3 T4 T5
P0 -1 0 1 0 0 0
P1 1 -1 0 0 0 0
P2 0 1 -1 0 0 0
P3 0 0 0 -1 0 1
P4 0 0 0 1 -1 0
P5 0 0 0 0 1 -1
P6 -1 0 1 -1 0 1
Current Marking

P0 P1 P2 P3 P4 P5 P6
1 0 0 1 0 0 1
Incidence matrix generated above from corresponding Petri Nets models
along with visual continuous run of these Models with HPSim simulator verifies all
working requirements are correct. A further verification may be studied with
Integer programming techniques (Giua and DiCesare, 1994b), which is out of
scope of this paper.
Conclusion
In this paper a new approach of formal verification of software
requirements using Petri Nets have been shown. Petri Nets discrete event system
(DES) are working models whose simulation can be observed by Petri Net
simulators while mathematically its design correctness of requirements can be
proven. The use of Petri Nets ensures that requirements specified are exactly what
the system should function. This paper presents an ideal case of a discrete,
partially observable, stochastic, episodic, dynamic and continuous software
system such as ACRTCS in order to show the DES model requirements formal
verification using Incidence matrix analysis.
References
Murata, T. (1989). Petri Nets: Properties, Analysis and Applications. In Proceedings
of the IEEE, Vol. 77, No 4, pp. 541-580.
DiCesare, F., Harhalakis, G., Proth M., J., Silva, M. and Vernadat B., F. (1993).
Practice of Petri Nets in Manufacturing. Chapman and Hall.
Giua, A. and DiCesare, F. (1994a). Blocking and Controllability of Petri Nets in
Supervisory Control. IEEE Trans. on Automatic Control, Vol. 39, No. 4, pp.
818-823.
Giua, A. and DiCesare, F. (1994b). Petri Net Structural Analysis for Supervisory
Control. IEEE Trans. on Robotics and Automation, Vol. 10, No. 2, pp. 185-195.
Desrochers A., A. and Al'Jaar Y., R. (1995). Applications of Petri nets in
Manufacturing Systems: Modelling, Control and Performance Analysis. IEEE
Press, ISBN: 0-87942-295-5.
Proth M., J. and Xie, X. (1997). Petri Nets: A Tool for Design and Management of
Manufacturing Systems. John Wiley & Sons, Inc., ISBN: 0-471-96770-X.
Reisig, W. (1998). Elements of Distributed Algorithms: Modeling and Analysis with
Petri nets. Springer-Verlag, ISBN: 3-540-62752-9.
Zhou, M. and Venkatesh, K. (1999). Modeling, Simulation, and Control of Flexible
Manufacturing Systems : A Petri Net Approach. Series in Intelligent Control
Road Traffic Control System Using Petri Nets
http://www.bdresearchpublications.com/journal/
411
and Intelligent Automation - Vol. 6, World Scientific Publishing Company,
ISBN: 981-02-3029-X.
Haas J., P. (2002). Stochastic Petri Nets: Modelling, Stability, Simulation. Springer-
Verlag, New York, ISBN: 0-387-95445-7.
Girault, C. and Valk, R. (2002). Petri Nets for Systems Engineering: A Guide to
Modeling, Verification, and Applications. Springer-Verlag, ISBN: 3-540-
41217-4.
Petri Nets tools. (2011). Complete Overview of Petri Nets Tools Database. Retrieve
from, http://www.informatik.uni-
hamburg.de/TGI/PetriNets/tools/complete_db.html
HPSim Simulator. (2011). WinPeSim. Retrieve from, http://www.winpesim.de/3.html