Traffic Control Simulations in Boolean, Human and Fuzzy Logic

machinebrainySoftware and s/w Development

Jun 8, 2012 (4 years and 10 months ago)


Traffic Control Simulations in
Boolean, Human and Fuzzy Logic

CO600 Group Project

Adeel Ahmad, Craig Blackman, Nicholas McDowall


Traffic Control Simulations in Boolean, Human, and Fuzzy Logic

Adeel Ahmad Craig Blackman Nick McDowall
University of Kent University of Kent University of Kent
Computing Laboratory Computing Laboratory Computing Laboratory


Traffic Control Simulations are used to study, in
isolation, real-time traffic patterns in order to
understand and attempt to solve the optimization
problem of traffic flow through intersections. However,
increasingly this has also been recognized as an
adaptive issue. We apply different logic controllers on
an isolated intersection to both appreciate the dynamic
behavior as well as to compare and implement the
logic controllers for their performances. We extend our
study towards understanding, implementation, and
evaluation of Fuzzy, Actuated, Fixed-Time, and Human
Control. We draw awareness on different control
methods and traffic simulations through related
research work in the field. The controller
performances are measured using control variables
that dictate real-time traffic conditions on an
intersection. Furthermore, we present our findings on
logic controller performances from two prototypical
1. Introduction

Out project was inspired by wanting to apply a
Fuzzy Logic approach to a simulated problem in order
to compare how the approach differs from a non-fuzzy
approach but also to learn more about the stages
involved when creating a Fuzzy Controller.
This project looks at two different approaches of
controlling traffic simulations. We have called them
Ptototype1 and Prototype2. Each of the prototypes will
be looking at the effectiveness of a fuzzy controller in
comparison to other non-fuzzy controllers. For
example prototype1 looks at a Boolean controller and a
fixed-time (naïve) controller. The simulations will be
run several times to capture the performances of the
different controllers over a range of varying traffic and
input conditions. Finally the results from the two
prototypes will be analysed to determine whether they
reach the same conclusions.

2. Background

Max Black was one of the first to challenge the use
of probability to express uncertainty with his studies of
vagueness in 1973 but it was the work by Lofti Zadeh
on fuzzy sets in 1965 that had a significant influence on
the way people think about uncertainty. Fuzzy logic or
multivalence to use the formal term deals with ideas of
partial truths where something can be both true and
false at the same time. Grey can exist as well as black
and white and everything is not rounded to fit either
true or false. Bivalence or Boolean logic on the other
hand deals with opposites, true or false. You either
belong to a set or you do not. “Everything must either
be or not be, whether in the present or in the future.”
[1] In bivalent logic values are rounded to fit into a set
to give all or nothing, accuracy is lost for the sake of
simplicity. One side-effect is that paradoxical situations
can occur. Trying to round 0.5 to 0 or 1 could be
rounded either way but according to bivalent logic
everything must be or not be however in this case it
could be either which causes problems. In mathematics
such paradoxical situations where A=NotA are treated
as ‘special’ conditions and are regularly found in set-

2.1. Set Theory

At school we are taught classical set theory where
we have a universe that contains all possible values and
sets that contains parts of the universe. The objects
within the universe either belong to a set or they do not.
There are several operations that can be applied to
classical sets such as Union, Intersection and
Difference. These operations are used to describe the
elements according to which sets they belong to or do
not belong to. The membership of elements to sets is
said to be ‘crisp’ because the membership is very well
defined and abrupt. For fuzzy sets this membership is
much more casual and the boundaries are more
ambiguous allowing elements to have a degree of
membership. A function can be used to determine the

level of membership to a set and is called a
Membership Function. So in Fuzzy logic a set is able to
have various elements that belong to the set in varying
degrees from the extremes of zero and total
membership (as in bivalent logic) as well as values in
between. Bivalent logic is therefore a special case of
fuzzy logic. The elements in a fuzzy set can also of
course belong to more than one set. Figure1 shows
functions describing the degree of membership for two
universes. The graph on the right shows an example of
a membership function for a classical set and the graph
on the left a membership function for a fuzzy set.

The set operations mentioned for crisp sets are also
applicable for fuzzy sets with the exception of middle
axioms [2].

2.2. Fuzzification

Although most of the information around us is fuzzy
the computers and mathematics we use need crisp
values to work. Therefore in order to create a fuzzy
controller we would have to ‘fuzzify’ some input
values and defuzzify the final output values too. By
fuzzifying the input values we enable the use of natural
linguistic variables to solve problems. Words such as
heavy or hot can be represented using membership
functions so that a range of values can belong to these
linguistic variables to some degree. With this in place it
is possible to approach problems in an intuitive way
since this attempts to replicate the way a human thinks.
For example when driving along in a car if a car
immediately ahead breaks ‘sharply’ (linguistic
variable) then we may respond by pressing the break
‘firmly (linguistic variable). This allows humans to
solve many complex problems in a comparatively
simple and efficient way.

2.3. Rule Based Systems

Fuzzy rule based systems are used to model
complex systems by using linguistic variables for the
antecedents and consequents. They allow us to apply
heuristics and expert knowledge to problems. The
variables used within the rules are based on fuzzy sets
and therefore can be true to some degree according to a
given membership function.

To obtain the overall consequent of the rule in
Figure 2 it is necessary to aggregate the two
antecedents. Since the connective is an ‘and’ we need
to find the fuzzy intersection of the antecedents which
is basically the minimum firing strength of the two
antecedents. So the consequent of the rule will fire to
some degree which maps to the minimum degree of
membership of the two inputs. This makes sense since
if one of the inputs has a zero membership the rule will
fire at zero strength which we expect due to the AND
connective. Once each of the rules have fired we need
to infer an overall output value.

2.4. Inference
The inference method involved mapping the inputs
values to the output values. There are several inference
methods however by far the most common is the
Mamdani (max-min) method. All the rule consequents
are aggregated to produce an output fuzzy set. The next
stage involves turning this fuzzy output set into a single
crisp output value.

2.5. Defuzzification
The process of producing a crisp output value from
a fuzzy output set is called defuzzification. Once again
there are several different methods that can be used.
Some common methods include the centroid, weighted
average [3] and bisector methods. Where the output
membership functions are evenly distributed and
symmetric the weighted average method also knows as
root-sum-square method appears to produce good
results. It takes into account all the rules that fire and
scales the functions by their magnitude.





Figure 1

a AND b



Figure 2
Antecedents connected by
an AND connective


and therefore fuzzy set theory is used, the membership
functions [7] and more than one rule is fired. The
Boolean controller follows the same steps [8] however
the inputs are not fuzzified, crisp sets are used, there is
no cross-over in membership sets and only one rule is

For this reason the Boolean Controller is only
capable of three possible outputs – to keep the cycle-
time as it is, to double it or reduce it to zero. The Fuzzy
Controller potentially has an infinite amount of output
values. However the inputs and cycle-time are
restricted to integer values thus reducing the range of
possible outputs, but the range is still significantly
larger than for the Boolean Controller. This allows
more flexibility and sensitivity which is what we
believe will result in a superior performance. The
inputs received are congestion scores [5] for each of
the roads A and B. It is the difference in the score that
is significant because when the scores are equal the
cycle-time will remain the same. When the scores are
uneven then the cycle-time will be adjusted so that the
road with a higher score gets a longer cycle-time and
the road with a smaller score a shorter cycle-time.

4.3.2 Fixed-Time Controller

The fixed-time controller dictates the traffic flow of
the roads simply by switching the signal every 15
seconds. It is a naive controller as it does not take into
account any conditions of the road when switching the
signal. Its cycle time will never adapt or change. The
controller will probably perform reasonably well when
congestion is approximately equal on each road. Thus
it is expected to perform poorly when the roads have
imbalanced congestion as it is oblivious to these
When the simulation is initiated and manual logic
mode is not selected then the fixed-time controller will
overrun the manual simulation by default. The user is
made aware of this within the user guide [9]. Many real
world conventional traffic light systems still use fixed-
time phase change, which is only really acceptable in
situations where traffic levels do not vary significantly.

4.4 Simulation GUI

The Simulation GUI is used to display the status of
the simulations as well as useful statistics, graphs and a
few user controls. The user guide [9] lists the options
in more detail. The user is able to alter the speed of the
simulation, pause/resume and stop the simulation. The
three simulations, each of which are controlled by the
different logics all run simultaneously and can be
viewed by flicking through each of the simulation tabs.
The ‘Graphs’ tab displays several graphs that are used
for a direct comparison of the performance measures of
the logics. Since separate threads are used for each of
the simulations the best time to compare the graphs is
at the end of a simulation because it is possible that the
threads will not always be in sync at a given moment in

4.5 Testing

Testing for prototype 1 consisted of three main
parts, namely unit testing, pair programming and UAT
(user acceptance testing). Unit tests were built up to
allow a small amount of regression testing to be carried
out. Some of the tools utilised for unit testing included
JUnit within the BlueJ environment which was chosen
for its familiarity. NetBeans was also used for its
flexible testing features. Pair programming was used
throughout the development phase. Any issues found
were recorded and tracked to ensure they were resolved
to a satisfactory level [10]. User testing towards the end
of the overall development cycle allowed us to verify
the program functioned as expected when deployed on
different machines. Users were given a user guide and
asked to run a simulation and then observed while
doing so to see if any usability or operational bugs
became apparent. They also completed a questionnaire
[11] for feedback. A more detailed overview of testing
[12] and the associated documents are available in the
corpus material.

4.6 Results

A Results Harness was created to produce the
results. Its function was to run the simulations one
hundred times and record the respective results [13] for
each of the logic controllers. The main reason for
creating the harness was to automate the results
gathering process, as running and recording the
simulation manually was time consuming. Secondly,
basing conclusions on one hundred runs is more
accurate than only a handful of runs as it allows
IF active road = low AND non-active = low
THEN no change
IF active road = low AND non-active = high
THEN reduce cycle
IF active road = high AND non-active = low
THEN increase cycle
IF active road = high AND non-active = high
THEN no change

meaningful averages to be obtained. In the real world,
traffic patterns will change hundreds or even thousands
of times within a day – so the simulation and results
attempt to reflect this. The values captured by the
harness were then imported into an excel template. The
data was then normalised and plotted on an XY-Scatter
diagram with trend lines to show the overall
performance of the logics in comparison to each other
[14]. Table 1 summarises the findings.

Table 1
Performance comparison overview table
(Compared to Fuzzy Logic)
Logic Controller

+23-35% +127%
+3-50% +100-150%
+60% +114%
+5% +40%

4.7 Evaluation

The Fuzzy Controller was able to perform better
across a wide range of traffic situations. Having
analysed the results we have concluded that Fuzzy
logic can help improve traffic flow and reduce delays
within a dynamic traffic environment. Its extra
flexibility allowed the controller to outperform the
Boolean logic where the imbalances were less extreme
and match or better it where the imbalances were
extreme. Both logics outperformed the naive controller
significantly and even when traffic levels were well
balanced the naive controller was outperformed on a
consistent basis by both of the other logics.
We feel that we have created a usable piece of
software that fulfils the objective of running traffic
simulations to compare the effectiveness of the
respective logics. The limitations of prototype1 include
losing a possible range of fuzzy outputs due to
restricting inputs and cycle-times to integer values. The
simulation does not allow for acceleration or
deceleration of cars or cars travelling at different
speeds. The simulation also only looks at a single
junction with one-way traffic. We appreciate the real
world behaves in a more complicated manner than this;
therefore these variables could perhaps be factored into
further development of the prototype.
The next stage in this simulation might be to look at
extending the roads to incorporate two-way traffic and
have left or right turns and so forth. A further
improvement might involve the fuzzy controller
monitoring traffic continuously and changing a given
cycle time mid-cycle if conditions change significantly.
At the moment the controller only evaluates the traffic
congestion once per cycle.

5. Prototype Two

This prototype uses two way lanes on a four way
isolated intersection. Cars enter and leave from north,
south, east and west. All cars go either from north to
south, south to north, east to west or west to east.
Turnings are considered. All roads have equal
weighting. The simulation can be configured using the
graphical user interface. This allows for information
hiding of complicated components from user view.
However, the simulation is constructed in a way that
allows for understanding of both the traffic simulation
as well the different controllers. Controllers
implemented for performance comparison include:
Fuzzy (Mamdani), Fixed-Time, Actuated, and Human.
These Boolean and Fuzzy controllers can be adjusted
for use from the user interface. However, the Human
option can be used as well for which a signal change
button is available. Graphs are produced for controllers
as well as an option for summary comparison when
multiple controllers are sequenced for a simulation. In
this case, the total time of simulation is divided equally
by the set parameters for the number of controllers. It is
also possible to save data from traffic control to
compare after simulation.
However, due to time constraints a lot of
complexities were reduced from the system so to allow
for some level of manageability. The work originally
was planned to incorporate Fuzzy Mamdani and Fuzzy
Sugeno Type Controllers as well as one Adaptive
Fuzzy Controller. This would have added more control
variables for performance measurements. Also,
initially, the objective was to allow for 1, 2, 4
intersection options but this was removed in order to
manage complexity of the implementation within time

5.1. Design Overview

This high level diagram illustrates how the different
components interact. Most of the components are
hidden away from the users view behind the GUI
window implementation which interacts with parameter
windows, which act as wrappers, in order to adjust the
state of the controller in order to apply signal changes.


5.2. Fixed-Time Controller

The Fixed-Time Controller was setup to allow for
cycle time adjustments between signal state changes.
However, this was done through the GUI which was
then updated within the Boolean (Fixed-Time)
Controller. The Boolean Parameter Window displays
the fixed-time state changes and allows for user to
change the cycle times for the next simulation phase.
The user can then run the simulation and view the
graphs and formulated data for the controller.
Adjustable states:

Time = 0 greenNS/redEW
Time = 60 redNS/greenEW
Time = 90 greenNS/redEW
Time = 120 redNS/greenEW

.....and so on depending on simulation time

5.3. Actuated Controller
Initial set Extended Interval
Actuated Controller extends a phase of a signal
controlling in a particular direction of car movements
over an intersection. The cars are detected using color
as a detector. These different colors related to: waiting
car, moving car, greater then average waiting car.
However, in real-world these colors would be actual
sensors embedded nearby or on the lane of a road.

5.4. Fuzzy Controller

The Fuzzy Controller type adapted for this prototype
was Mamdani [15]. It uses the standard centroid
method for defuzzification which translates linguistic
variable [16] input into crisp output. The fuzzification
method translates the crisp inputs into linguistic
variables. The system is able to draw inference using
linguistic variable weights and adjusting the
membership functions [16].
5.5. Testing

Testing for prototype two consisted of automated
testing using the robot for user interface components to
check for functionality. Another aspect that was looked
at was the controller logics implemented to check that
they were meeting specified functional requirements. A
lot of testing was done using outputs from a terminal
window to gather feedback about event calls that are
generated through each component during a simulation.

5.6. Evaluation

Results of comparisons for two phase controlling
show that when traffic volumes are evenly spread out
over the intersection the fuzzy performance is about the
same as an actuated controller. However, when traffic
volumes are unevenly fluctuated the fuzzy controller is
seen to perform better then actuated controller. The
fixed-time controller failed miserably in controlling
fluctuations in traffic flow. However, when traffic was
consistent the fixed-time controller was seen to be
slightly more effective then fuzzy. Human control on
the other hand was more time consuming, but reduced
in effectiveness when both traffic volumes and
simulation speeds were increased dramatically. Fuzzy
controller, on the other hand, generally performed
better with increased speed and traffic volumes
depending on the cycle time of inference. Generally,
the fuzzy controller was effective enough to optimize
traffic flow as well as adapt to fluctuations. The
efficiency of the fuzzy controller could be increased by



& Data




applying hedges into the linguistic variables to add to
the granularity of generated rules. However, too many
configured rules for a fuzzy controller also reduce the
efficency of the inference and defuzzification methods.

6. Conclusions

We were able to apply two different approaches
when comparing the performances of various traffic
control logics. Fuzzy logic appeared to outperform the
other logics overall but especially when traffic levels
were unbalanced across the roads. Our knowledge and
understanding of fuzzy logic has increased significantly
and now we have a clearer understanding of how fuzzy
logic can be applied to a problem in the form of a fuzzy
controller. Given more time we would have liked to
experiment with more fuzzification and defuzzification
methods to determine whether we could fine-tune the
performances of our controllers even further. Overall
we feel we have achieved our main objectives that were
set at the start of the project.
7. Acknowledgements

We would like to thank our supervisor, Dr Colin
Johnson for his guidance and communication
throughout the project. Additionally we would like to
thank Prof. Lotfi Zadeh and the BISC team for
providing us resources to formulate an understanding
of Fuzzy logic.
8. Bibliography

[1] p64, Aristotle as quoted, B Kosko, Fuzzy Thinking The
Science of Fuzzy Logic, Flamingo, USA, 1994
[2] p30, Ross, T.J., Fuzzy Logic with Engineering
Applications, John Wiley & Sons, UK, 2005
[3] p101, Ross, T.J., Fuzzy Logic with Engineering
Applications, John Wiley & Sons, UK, 2005
[4] JFreeCharts, “A Java chart library that aids developers in
producing high quality charts within applications”, [Online]:
, (2008)

[5] Congestion Scores, Corpus Ref: 1D4
[6] Class Interaction/Dependency Diagram, Corpus Ref: 1D6

[7] Membership Functions: Corpus Ref: 1D5
[8] Flow Chart Diagram Comparing Fuzzy & Boolean
Control Processes, Corpus Ref: 1D2
[9] Prototype 1 User Guide, Corpus Ref: 1U1
[10] Bug Tracking, Corpus Ref: 1T2
[11] User Questionnaire, Corpus Ref: 1T4
[12] Testing Overview, Corpus Ref: 1T1
[13] Final Results from Harness – csv file, Corpus Ref: 1R2

[14] Results Summary, Corpus Ref: 1R1
[15] p23-95, K.M. Passino & S.Yurkowich, Fuzzy Control,
Addison-Wesley, USA, 1998
[16] L.A. Zadeh, Fuzzy Sets, vol 8, Information and Control,
USA, 1964