Traffic Control Simulations in Boolean, Human and Fuzzy Logic

Transcription

1 COMPUTING DEPARTMENT Traffic Control Simulations in Boolean, Human and Fuzzy Logic CO600 Group Project Adeel Ahmad, Craig Blackman, Nicholas McDowall

2 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 Abstract 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 implementations. 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 settheory 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 2

3 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. 1 0 Universe The set operations mentioned for crisp sets are also applicable for fuzzy sets with the exception of middle axioms [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 Rule Based Systems 1 Figure 1 0 Universe 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 Inference IF a AND b THEN c Antecedents connected by an AND connective 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 Defuzzification Figure 2 Consequent 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. 3

4 3. Aims The main aim of the project is to compare the performance of Fuzzy, Boolean and Human Logic within the context of a traffic simulation, with the subobjective of comparing and contrasting the approaches used for Prototype 1 and Prototype 2. Through designing and developing these prototypes we desire to increase our knowledge of fuzzy logic by applying theory to a real world problem. We envisage and hope that the usefulness of fuzzy logic will become apparent by undertaking the implementation of these prototypes. Utilising the latest software and technologies such as NetBeans and CSProjects/Trac will expand each group member s skill set while learning from and contributing to a common knowledge base for the project. User Control Logic Simulation GUI Parameters Inputs Options Cycle-Time Figure 3: Overview Diagram Main GUI Sim Logic Stats 4. Prototype 1 This prototype looked at simulating traffic on two roads that share a single junction. Access to the junction is controlled by traffic lights. Three instances of the simulation are run where the traffic lights are controlled by different logic controllers. These controllers are Fuzzy Logic, Boolean Logic and Fixed- Time. The fixed-time controller can be overridden by a human at the initiation of the simulation. The purpose of the prototype is to compare the performance of the logics given identical initial traffic conditions. We hypothesise that the fuzzy controller will shorten queue lengths, reduce delays and manage the traffic flow more effectively when compared to the other controllers. We do also expect Boolean Logic to perform better than the naive Fixed-Time controller but to be less flexible and therefore perform worse than the Fuzzy Controller. The prototype was developed in Java 1.6 using several IDEs including BlueJ, Eclipse and NetBeans. External Java libraries [4] were used in order to generate the graphs that are displayed on the Simulation GUI. 4.1 Overview A high level overview of the process flow is included in Figure 3. The main GUI is used to set the initial traffic conditions. The logic controllers are initialised and they start the simulations by passing a cycle-time (length of time the signal remains green for the active road) to the simulations. After each cycle the simulation logics pass two inputs (congestion scores [5]), one for each road. The class interaction diagram [6] lists all of the classes used to construct the prototype. 4.2 Simulation Logic We tried to keep the logic separate from the Simulation GUI wherever possible. The main purpose of the simulation logic is to move cars along each time an update request is received. The current signal value and active road is also passed during the update call. The pseudo code below gives an overview of how each road is updated. FOR (EACH CAR) IF (car in front) THEN Position = Position ELSE IF (at junction and light == red) THEN Position = Position ELSE Position ++ END IF 4.3 Control Logic There are three controllers that are able to access the traffic lights of the simulation they are associated with. The controllers are assigned to their simulations when the start button is pressed on the Main GUI. We will now look at the differences between the three controllers in more detail Fuzzy & Boolean Logic Controller We attempted to keep the operation of these two controllers identical apart from one fundamental difference. The Fuzzy Controller fuzzifies the inputs 4

5 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 fired. 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 For this reason the Boolean Controller is only capable of three possible outputs to keep the cycletime 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 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 differences. 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 fixedtime 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 time. 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 5

6 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 Boolean Fixed-Time Total Delay % +127% Measured Variables 4.7 Evaluation Wasted Slots Max Delay Longest Queue +3-50% % +60% +114% +5% +40% 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 constraints 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. 6

7 User Graphs & Data Data Control GUI Window Fuzzy Controller Boolean Controllers Actuated/Fixed-Time 5.2. Fixed-Time Controller SIM SIM Parameter s Fuzzy Parameter s Boolean Parameter s 5.4. Fuzzy Controller Fuzzification Inference Defuzzification Rule Base 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]. 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. Time = 0 Time = 60 Time = 90 Time = 120 Adjustable states: greenns/redew redns/greenew greenns/redew redns/greenew...and so on depending on simulation time 5.3. Actuated Controller Initial set Interval 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 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 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 7

8 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. [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, 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 8