Integrative Framework for Discrete Systems Simulation and Monitoring

Transcription

1 Integrative Framework for Discrete Systems Simulation and Monitoring A thesis submitted in partial fulfilment of the requirements of The Nottingham Trent University for the degree of Doctor of Philosophy Evtim Todorov Peytchev February 1999 This research programme was supported by an EPSRC research grant and was carried out in collaboration with the Nottingham Traffic Control Centre and Leicester Traffic Control Centre

2 Integrative Framework for Discrete Systems Simulation and Monitoring Abstract The ever growing number of vehicles in the streets demands more efficient control of urban road networks. Such an efficiency can be achieved by designing and implementing a new supervisory layer of control which will use in-vehicle and road-side dynamic route guidance. The operation of traffic control systems can be enhanced further through the use of an integrative computing framework for the interconnection of various traffic telematics applications. This thesis describes the design and development of an integrative computing framework (based on a distributed computing paradigm) which supports the supervisory traffic control and includes the following: flexible inter-module communications, predictive traffic simulation and a confidence limit analysis. The addition of new software modules to the control system introduces a computational overhead which can disrupt its normal operation. The DIstributed shared Memory Environment (DIME), presented in this thesis, has been developed as a flexible computing environment in which various new applications can be fully integrated with an existing monitoring and control system, without adversely affecting its performance. Such a processing environment has been designed to ensure the fastest possible data retrieval across different operating platforms (as opposed to the commercial architectures for distributed computers processing which achieve hardware independence at a cost of a significant computational overhead). This environment also provides a simple application programming interface, thus guaranteeing transparency of the specific physical processor connectivity to the user. Recent research results show that all established simulation models lack several essential characteristics needed for predictive control: on-line connection to the existing traffic control systems, real-time evaluation of traffic control strategies and real-time traffic flow prediction. Furthermore, the on-line predictive evaluation of traffic control strategies and the forecasting of traffic flows and queue lengths, on a large scale urban traffic network, require - mainly out of cost and computational power requirements - the consideration of average traffic flows and platoons of vehicles, rather than of individual vehicles. This has led to the design and implementation of a macroscopic predictive simulation module, capable of simulating, on-line, the entire city traffic network. The Macroscopic Simulation Module is a novel mathematical model formulated in a statespace discrete systems domain with the state defined as a vector that has two state variables: queue length and traffic density for each street. The model is used for deriving longer-term predictions of queues and traffic densities by using on-line estimates of the

3 traffic queues, corresponding to these links, and correlating this information to the measurements obtained in the up-stream links. In order to be able to use the up-stream links measurements, the model estimates the drivers turning movements coefficients and makes the results available for all modules in the integrative framework. The Microscopic Simulation Model presented in the thesis is designed to complement the Macroscopic Simulation Module described earlier. It is implemented as a simple carfollowing model. Its aim is to validate some of the traffic flow parameters used by the macrosimulation model for several particularly sensitive cross-roads in the traffic network. It assists the evaluation of the operational control in a traffic control system and serves as a graphical front-end interface to the control system. The Confidence Limit Analysis process, researched here, addresses the issue of the limited accuracy of traffic measurements and it attempts to quantify the uncertainty bounds that are associated with any traffic flow predictions. In particular, the analysis has been applied to the estimates of turning movement coefficients, which are a building block in the derivation of an origin-destination matrix.

4 The copy of this report has been supplied on the understanding that it is copyright material, and that no quotation from the report may be published without proper acknowledgement. The work described in this Report is the Author s own, unless otherwise stated, and it is, as far as he is aware, original. i

5 Acknowledgements I would like to thank Prof. A. Bargiela for his guidance throughout this work. I am most grateful for his supervision and continual encouragement. I would like to acknowledge the stimulating discussions with Prof. R. Gessing during his sabbatical with the RTTS group in the Department. I must acknowledge the support I have been given by my colleagues and friends at the Department of Computing. Substantial part of this research has been carried out in collaboration with the Nottingham Urban Traffic Control Centre and I am specially grateful to Mr. R. Berry and Mr. J. Cogan for their support for the project. I would also like to thank Dr. M. Bell, my second supervisor, for facilitating the data collection for turning movements estimation through the Instrumented City facility. Special thanks go to my family for the understanding and the patience shown to me during the writing of this report. The financial support of the EPSRC (grant GR/K 16593) is gratefully acknowledged. ii

6 Table of Contents INTRODUCTION Traffic Control Schemes - Historical Perspective Early Computer Assisted Traffic Control Systems - fixed plan control Current Traffic Control Schemes - demand responsive control Future Traffic Control Schemes - predictive management and control Supervisory layer s computer system design considerations SCOOT real-time traffic control system, Nottinghamshire installation Aims of the research Organisation of the thesis Original Contributions DISTRIBUTED HIERARCHICAL CONTROL OF URBAN TRAFFIC Design of modern traffic control systems - hierarchical spatial structure The traffic control system - hierarchy architecture of the system Design considerations not reflected in the hierarchical spatial structure of the traffic control systems Design of modern traffic control systems with supervisory control - hierarchical temporal - spatial structure Temporal structure of a traffic control system with supervisory layer - control engineering point of view Traffic control system design - building blocks of the supervisory layer of control Communication module Turning Movements Estimation and Prediction Module Surveillance Module Queue Prediction Module Control Strategy Generation Module Operational Control Generation Module Dynamic traffic model system - inter-process communication structure Concluding remarks on building elements of the traffic control system with supervisory layer Scope of this research Conclusions on Traffic Control Systems with Supervisory Layer of Control.. 30 DIME - DISTRIBUTED MEMORY ENVIRONMENT Introduction to distributed computers shared memory systems iii

7 3.2. Distributed Computers Shared Memory - Advantages Distributed Computers Shared Memory - Design Choices Structure and granularity Coherence semantics Scalability Heterogeneity Distributed Computers Shared Memory - Implementation Choices Data location and access Coherence protocol Replacement Strategy Thrashing in DCSM systems Distributed Computers Shared Memory - Basic Algorithms Central Server algorithm Migration algorithm Read-replication algorithm Full-replication algorithm DIME Shared Memory System - formulation of the problem DIME Shared Memory System - design of the system Data structures design Choice of consistency model and algorithm Scalability Heterogeneity DIME configuration Shared Memory Data Structures in DIME DIME s API Traffic Simulation and Monitoring Environment using DIME Evaluation results Conclusions of using DIME as shared memory environment for distributed simulation, monitoring and control of urban traffic PREDICTIVE MACROSCOPIC CITY TRAFFIC FLOWS SIMULATION MODEL City Traffic Flows Simulation Models - Macroscopic and Microscopic Simulation City Traffic Flows Macroscopic Simulation Models SIMAUT - hydrodynamic theory based model META - freeway traffic model iv

8 METANET - freeway traffic model CONTRAM - city traffic flows simulation model TRANSYT macrosimulation model Network and Traffic Flow Data in TRANSYT Traffic Simulation Model for ATMS/ATIS operations presented by [Ben- Akiva M., Koutsopoulos H.N., Mukundan A., 1994] Traffic Flow Microsimulation Models Car-following microsimulation model Simple Linear Car-Following Model Non-linear Car-Following Models Gipps car-following model HUTSIM microsimulation model NETSIM microsimulation model AIMSUN2 microsimulation model Summary of traffic flows microsimulation models (source - SMARTEST project report) Conclusion from the review of the simulation models Prediction of Traffic Flows Short-Term Traffic Flow Prediction Models Linear Models Using Smoothed Information General Spectral Analysis Prediction Model Prediction of traffic flows using ARIMA Model Filtering Methods Very-Short Term Traffic Flow Prediction SCOOT Prediction Model SCATS Prediction Model Conclusions on prediction of traffic flow PADSIM - Macroscopic City Traffic Flows Predictive Simulation Model Timing Model Definition Queue Length Calculation Case 1 for queue length calculation - long queue Case 2 for queue length calculation - short queue + high arrival rate Case 3 for queue length calculation - short queue + low arrival rate Traffic Density Definition v

9 Turning movements coefficients - introductory remarks Calculation of the number of cars arriving at the stop line and joining the queue in cycle c PADSIM incoming traffic flows short term prediction model Evaluation of the macroscopic traffic simulation model Evaluation of the AR model Evaluation of the macroscopic traffic simulation model Microscopic Traffic Flows Simulation Model in assistance of macroscopic simulation Microscopic simulation module environment Traffic Network Description Microsimulation model - main principles Conclusions on microsimulation in support of the macrosimulation process Development of a decision support environment to facilitate efficient interaction of the operator with the predictive simulation software - introductory remarks Design and implementation of GKS (Graphic Kernel System) for displaying operator s information The X environment The GKS - introduction Coordinate Systems GKS - user application interface specification Conclusions TURNING MOVEMENTS ESTIMATION MODEL Dynamic Estimation of Origin-Destination Traffic Flows Problem formulation Least squares estimation involving cross correlation matrices Constrained optimization method Simple recursive estimation Estimation by Kalman filtering (after [Cremer M., Keller H. 1987]) Estimation of turning movements in PRODYN Choice of traffic turning movements coefficients estimation model Turning Movements Estimation Models using insufficient traffic counts information: PADSIM estimation model Algorithm description Algorithm illustration vi

10 5.4. Validation of the PADSIM turning movement coefficients estimation model Conclusions on turning movements estimation models CONFIDENCE LIMIT ANALYSIS FOR THE TRAFFIC QUEUE AND TRAFFIC DENSITY PREDICTIONS Introduction Introducing turning movement coefficients estimation definitions for the case of the confident limit analysis process Assessment of the accuracies of the measurement data Measurement data - short description Measurement data - choice of the message type for confidence limit analysis Assessment of the accuracy of the messages used in the dynamic traffic model control system, described in Chapter Numerical data collection Video data collection Results of the quantification of the uncertainties associated with SCOOT measurements Relationship between the Link Profile Units (LPU) and the physical count of vehicles Most significant findings based on analysis of the numerical data Derivation of the error bounds on the statistical characterisation of the drivers turning movement coefficients Introduction to confidence limits analysis approach Monte Carlo method Uncertainty quantification method Using the sensitivity matrix method Derivation of the error bounds on the statistical characterisation of the drivers turning movement coefficients Algorithm for derivation of the error bounds on the statistical characterisation of the drivers turning movements coefficients Development of the state estimation algorithm State estimation algorithm Confidence Limits of the predicted traffic flows Confidence limits quantification algorithm Algorithm for quantification of the maximum prediction horizon of the simulator for which the confidence limits on the state estimates remain acceptable vii

11 6.8. Results Conclusions on confidence limit analysis for the traffic queue and traffic density predictions CONCLUSIONS AND FURTHER RESEARCH Concluding Remarks about the Project Future Research References: Appendix A. Example screens. Appendix B. Measurement data quality estimation - data tables containing real and measured data. Appendix C. Variation of the queue length in the end of the red signal - example data. Appendix D. Total vehicle count crossing the stop line in one cycle - example data. Appendix E. Correlation of total vehicle count crossing two consecutive stop-lines - example data. Appendix F. Variability of the total vehicle count for one inductive loop for two different dates - same week day. Appendix G. Representative set of AR model evaluation data. viii

12 List of Figures: Figure 2-1: A Basic Traffic Control Scheme...14 Figure 2-2: Hierarchical spatial structure of an Advanced Traffic Management System...16 Figure 2-3: Temporal Structure of a Traffic Management And Control System - control engineering approach...19 Figure 2-4: Supervisory Layer of control - functional structure Figure 2-5: Supervisory layer - interprocess communications scheme...27 Figure 3-1: Distributed computers shared memory (DCSM) model...34 Figure 3-2: Intuitive Definitions of Memory Coherence Figure 3-3: Four distributed shared memory algorithms Figure 3-4: The Central Server Algorithm Figure 3-5: The Migration Algorithm Figure 3-6: The Write Operation in Read-Replication Algorithm Figure 3-7: The Full-Replication Algorithm...48 Figure 3-8: DIME Configuration Figure 3-9: Shared Memory Structure Array Figure 3-10: Shared Memory Structure Circular Buffer...56 Figure 3-11: Using DIME in urban traffic simulation and control Figure 3-12: DIME LAN performance for 2-5 user applications Figure 3-13: DIME WAN performance for 2-5 user applications Figure 3-14: Times for a single read/write transaction on Windows platform for the client program...66 Figure 3-15: Times for a single read/write transaction on UNIX platform for the client program...66 Figure 3-16: Times for a single read/write transaction on UNIX platform for the memory manager program...67 Figure 4-1: Links and Nodes definition in TRANSYT (after [Vincent R.A., Mitchell A.I., Robertson D.I., 1980])...77 Figure 4-2: The visual angle model Figure 4-3: Principles of the SCOOT Traffic Model (after [Hunt P.B., Robertson D.I., Bretherton R.D., Winton R.I. 1981]) Figure 4-4: Time Instances Definition Figure 4-5: Queue Length Definition. Case Figure 4-6: Queue Length Definition. Case Figure 4-7: Queue Length Definition. Case Figure 4-8: Boundary and Internal Links Figure 4-9: Correlation between the squared prediction error and the depth of prediction. Data from link N60311G on 13 may 1997, h Figure 4-10: Evaluation of the AR model for predictions in the boundary link N60311G on 13 may Figure 4-11: The Mansfield traffic network Figure 4-12: Evaluation of the prediction model for predictions in the internal link N60421B on 13 may h Figure 4-13: Correlation between the squared prediction error and the depth of prediction. Data from link N60421B on 13 may 1997, h Figure 4-14: The microsimulation module environment Figure 4-15: Traffic Network Description ix

13 Figure 4-16: Traffic Network Decomposition - Example Figure 4-17: Operator s place in the supervisory layer of the real-time traffic control system Figure 4-18: The X window concept Figure 4-19: GKS Coordinate systems Figure 4-20: Normalization Transformation Figure 4-21: Aspect ratio transformations Figure 4-22: Normalization transformation and workstation transformation Figure 5-1: Topology of a 4-way intersection with O-D flows Figure 5-2: Model of the intersection N60421, for which the traffic turning movement coefficients model has been validated Figure 5-3: turning movement coefficients estimation Figure 5-4: turning movement coefficients estimation Figure 5-5: turning movement coefficients estimation Figure 5-6: turning movements prediction Figure 5-7: turning movements prediction Figure 6-1: Confidence limits analysis process - domain independent view Figure 6-2: Confidence limit analysis process for turning movement coefficients estimates Figure 6-3: Confidence limit analysis process for urban traffic flows and traffic densities prediction Figure 6-4: Information flows in Confidence Limit Analysis Process for Traffic Simulation Systems domain Figure 6-5: Numerical data collection - data flows Figure 6-6: SCOOT data: estimation of the ratio LPUs (y-axes) per car (for over 600 samples) Figure 6-7: SCOOT data: comparison between the length of the queue in the end of the red signal as estimated by SCOOT in LPUs and the data obtained from counting the number of the cars on a video-tape with reference to Figure Figure 6-8: State Estimation Process for the macroscopic urban traffic flows simulation model Figure 6-9: The Confidence Limits Estimation Procedure - Information Flows Figure 6-10: Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 1% Figure 6-11: Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 3% Figure 6-12: Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 5% Figure 6-13: Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 7% Appendix A, Figure 1: SCOOT controlled traffic network in Mansfield, Nottinghamshire....A-1 Appendix A, Figure 2: On-line connection to SCOOT system for Mansfield area, Nottinghamshire....A-2 Appendix A, Figure 3: Distributed shared memory manager program - example screen....a-3 Appendix A, Figure 4: PADSIM macroscopic simulation model - queue prediction example screen....a-4 x

14 Appendix A, Figure 5:Microscopic traffic simulation model - example screen...a-5 Appendix A, Figure 6: Nottingham Traffic Control Centre - working with SCOOT traffic control system....a-6 Appendix B, Figure 1: Observed and measured data on 29 july 1997, 09h 00m - 12h 00m....B-4 Appendix B, Figure 2: Observed and measured data on 30 july 1997, 09h 00m - 12h 00m....B-8 Appendix B, Figure 3: Observed and measured data on 31 july 1997, 09h 00m - 12h 00m....B-12 Appendix B, Figure 4: Observed and measured data on 30 july 1997, 09h 00m - 12h 00m....B-16 Appendix C, Figure 1: SCOOT data: variation of the length of the queue at the end of the red signal averaged over 1, 2, 3, 4 and 5 cycles and displayed in comparison to the averaged value calculated over 10 cycles and divided by that value....c-1 Appendix C, Figure 2: SCOOT data: variation of the length of the queue at the end of the red signal averaged over 1, 2, 3, and 4 cycles and displayed in comparison to the averaged value calculated over 5 cycles and divided by that value....c-2 Appendix C, Figure 3: SCOOT data: length of the queue at the end of the red signal averaged over 1, 2, 3, 4 and 5 cycles....c-3 Appendix C, Figure 4: SCOOT data: variation of the length of the queue at the end of the red signal averaged over 1, 2, 3, and 4 cycles and divided by the averaged value calculated over 5 cycles....c-4 Appendix D, Figure 1: SCOOT data: total count of vehicles passing the stop line averaged over 1, 2, 3, 4 and 5 cycles....d-1 Appendix D, Figure 2: SCOOT data: variation of the total count of vehicles passing the stop line averaged over 1, 2, 3, and 4 cycles and divided by the averaged value calculated over 5 cycles....d-2 Appendix D, Figure 3: SCOOT data: variation of total count of vehicles passing the stop line averaged over 1, 2, 3, and 4 cycles and displayed as comparison to the averaged value calculated over 5 cycles and divided by the averaged over 5 cycles value.....d-3 Appendix E, Figure 1: SCOOT data: all vehicles passing the stop line for the first loop divided by the same value for the second inductive loop (averaged over 1, 2, 3, 4 and 10 cycles)....e-1 Appendix E, Figure 2: SCOOT data: all vehicles passing the stop line for the first loop divided by the same value for the second inductive loop (averaged over 1, 2, 3, 4 and 10 cycles)....e-2 Appendix E, Figure 3: SCOOT data: all vehicles passing the stop line for the first loop divided by the same value for the second inductive loop (averaged over 1, 2, 3, 4 and 10 cycles)....e-3 Appendix F, Figure 1: SCOOT data: discrepancies of the total counts of the vehicles passing the stop line averaged over 1, 2, 3, 4 and 10 cycles and displayed in comparison (first day minus second day and divided by the second day).... F-1 Appendix F, Figure 2: SCOOT data: discrepancies of the total counts of the vehicles passing the stop line averaged over 1, 2, 3, 4 and 10 cycles and displayed in comparison (first day minus second day and divided by the second day).... F-2 xi

15 Appendix F, Figure 3: SCOOT data: discrepancies of the total counts of the vehicles passing the stop line averaged over 1, 2, 3, 4 and 10 cycles and displayed in comparison (first day minus second day and divided by the second day).... F-3 Appendix F, Figure 4: SCOOT data: discrepancies of the total counts of the vehicles passing the stop line averaged over 1, 2, 3, 4 and 10 cycles and displayed in comparison (first day minus second day and divided by the second day).... F-4 Appendix F, Figure 5: SCOOT data: discrepancies of the total counts of the vehicles passing the stop line averaged over 1, 2, 3, 4 and 10 cycles and displayed in comparison (first day minus second day and divided by the second day).... F-5 Appendix F, Figure 6: SCOOT data: discrepancies of the total counts of the vehicles passing the stop line averaged over 1, 2, 3, 4 and 10 cycles and displayed in comparison (first day minus second day and divided by the second day).... F-6 xii

16 List of Tables Table 3-1: Times for a single read/write transaction on Windows platform for the client program Table 3-2: Times for a single read/write transaction on UNIX platform for the client program Table 3-3: Times for a single read/write transaction on Windows platform for the client program over a serial link with speed 9600 b/s (mobile telephone link) Table 3-4: Times for a single read/write transaction on UNIX platform for the central memory manager program Table 4-1: The speed control rule set Appendix B Table 1: Data collected on 29 July B-1 Appendix B Table 2: Data collected on 30 July B-5 Appendix B Table 3: Data collected on 31 July B-9 Appendix B Table 4: Data collected on 1 August B-13 Appendix G. Table 1: Data for Inductive loop N60311G on 06 may Squared prediction error estimated for powers of the polynomial A(x) 2 to 12 and size of the prediction vector B(t) 3 to G-1 Appendix G. Table 2: Data for Inductive loop N60421A on 06 may Squared prediction error estimated for powers of the polynomial A(x) 2 to 12 and size of the prediction vector B(t) 3 to G-2 Appendix G. Table 3: Data for Inductive loop N60311G on 13 may Squared prediction error estimated for powers of the polynomial A(x) 2 to 12 and size of the prediction vector B(t) 3 to G-3 Appendix G. Table 4: Data for Inductive loop N60421A on 13 may Squared prediction error estimated for powers of the polynomial A(x) 2 to 12 and size of the prediction vector B(t) 3 to G-4 xiii

17 Chapter 1 INTRODUCTION Discrete systems, characterised by events that are indivisible entities, form an important class of real life systems. They underlie such diverse applications as telecommunications, road/rail traffic control, biomedical research etc. This research concentrates on the design and development of an integrative processing environment for urban traffic monitoring and control, predictive traffic simulation (defined in the discrete systems domain) and confidence limit analysis for the predicted traffic flows. Moreover, it is envisaged that the techniques, developed in the course of this research, can be adopted and used in the context of discrete systems in general. As the building of new roads and extension of the existing roads are becoming more and more difficult - politically and economically - the successful management of the traffic situation increasingly depends on the technological improvement of the existing control schemes. The main difficulties in this process are: extending the optimisation horizon; processing, in real-time, large amounts of data; minimizing the total travel cost (delays, vehicle stops during a journey, environmental impacts and travel time); maximizing safety on the road; automating the control decisions to the highest extent possible. The analysis of the trends of traffic control systems development showed, that the control systems developed up to date try to solve the above mentioned problems on a short time scale (typically one cycle) basis. All control actions on a larger time scale are left to the human operator and clearly there is a need for a new supervisory layer, capable of forecasting the development of the current situation and filling the gap between the operator and the existing operational control Traffic Control Schemes - Historical Perspective. Ever since the start of the development of the urban traffic control schemes, the aim has been to control the duration of the green light in each direction on an intersection and properly offset the traffic signal timings at different intersections. A number of approaches, both with and without computer aid, have been developed. The rapid advance of the computer-aided traffic signal control systems in the recent years enabled the introduction of a number of different methods for intersection traffic lights control 1

18 and for combining the intersections signal timings. Their characteristics are summarised in the subsequent subsections Early Computer Assisted Traffic Control Systems - fixed plan control Early computer assisted traffic control systems relied on fixed signal timing plans. These fixed signal timing plans were developed off-line using manual or computerised techniques and were based on statistical calculation and no on-line measurements. The change from one fixed signal plan to another fixed plan was performed by the system according to the time of day. Any variation from the pre-calculated daily traffic pattern, such as an early start for a peak period plan, required the operator s intervention to alter the plan at the desired time. These systems are generally referred to as 1 st generation traffic control systems [Euler G. 1988]. An incremental improvement on 1 st generation traffic control systems was the development of a library of timing plans which were calculated off-line. The transition from one timing plan to another was based on some traffic measurements, usually traffic volume and occupancy, in selected, critical traffic network points. In deriving the sets of timing plans, off-line models such as TRANSYT [Robertson D. I. 1969] were commonly used. These systems offered much more flexibility in comparison with previous systems implementations. For example, the Los Angeles automatic traffic surveillance and control (ATSAC) system [Rowe E. 1988] supplements its generated plans with critical intersection control to adjust its phase times on a cycle-by-cycle basis. [Euler G. 1988] refers to this class of systems as 1.5 th generation traffic control systems. These systems had a limited library of signal plans and, consequently, only limited ability to adjust its operation to current traffic conditions. Any variation of traffic flows, that was not anticipated at the stage of building timing plans, created a disruption that propagated through the network Current Traffic Control Schemes - demand responsive control. Current traffic control schemes have evolved through two stages: use of timing plans developed off-line and used on-line by the control system. use of signal timings free to evolve according to detected traffic flows without using any off-line calculated timing plans. During the first stage of development all timing plans were calculated on a time period basis (i.e for every quarter of an hour in a day) and for special occasions (football match in the city etc). Although they were calculated by taking into account traffic flow measurements, in general they have not been as effective as anticipated. Some of the reasons for such inefficiency, as indicated by [Papageorgiou M. 1991], are: 2

19 (a) Too many timing changes - The change of the signal timing in the control systems was normally performed on a periodic basis (for example every 15 minutes). However, if the traffic conditions changed and another plan was more appropriate to apply for the newly created condition, the automated choice of timing plan usually performed the change. Consequently, the system s plans were modified too frequently. The negative effects of making the transition from one plan to another very often nullified the benefits to be gained. (b) Too reliant on prediction - The way these systems developed new timing plans is one of their important features. The developed plans tried to accommodate expected traffic demands and patterns and used prediction estimates based on recently detected traffic volumes and occupancies. In some cases, the predictions were heavily weighted to measurements made during the most recent signal cycle. Because of the random nature of the traffic flow, this did not work very well. Another approach used a prediction on the basis of detector data that were smoothed over, for example, a 15 min. period. This was often not responsive enough to predict sudden changes in demand in a timely fashion. (c) Narrow objectives - Some of the systems tested were designed to give priority to the traffic along major arterials. As a result, traffic on the side streets often incurred large delays. From a global point of view, the system performance was not necessarily optimised. (d) Inflexibility - Because of their approach of applying timing plans calculated off-line and affecting the whole traffic network for a number of consecutive cycles, these systems were unable to deal effectively with unanticipated events. The end result was that these systems never became established and a new generation of traffic demand responsive systems has evolved. With the current generation traffic control systems, the signal timings are evaluated in real time in response to changing traffic conditions. These systems allow signals to evolve in an unconstrained manner, but still the length of the cycle obeys some partial constraints. Several working traffic control systems have been implemented in the field. Examples of such real-time, demand responsive traffic control systems include the Australian SCATS [Sims A. G. 1979], the British SCOOT [Hunt P.B., Robertson D.I., Bretherton R.D., Winton R.I. 1981] (see Appendix A, Figure 6.) and the Spanish CARS [Grau, R.; Barcelo, J. 1993]. The characteristic feature of these systems is the prediction of queue length in every link using the measurements of the volume of incoming traffic into each link. The time-scale of each prediction is equal to the travel time between the detector and the back of the corresponding queue and is of the order of the duration of the traffic signals cycle. Since the predictions are used in the optimisation of traffic signal timings, they also define the time horizon of optimised control. The improvement of 3

20 demand responsive control systems over the fixed timing plans systems has been found to be very significant, particularly for high traffic volumes. From the control theory viewpoint, these systems can be seen as including a feed-forward signal, which provides an advance notice to the control system about the expected length of queues and improves the system performance. In the Australian SCATS system small sub-areas of up to ten intersections share a common cycle length, which can be altered by up to 6 seconds per cycle. It can also strategically combine certain sub-areas for varying lengths of time, in order to improve the overall network performance. It draws its data from stop line detectors. In the British SCOOT system (SCOOT stands for Split, Cycle and Offset Optimisation Technique), the network shares common cycle time which is also periodically adjusted in small steps. SCOOT employs detectors, located just downstream of the intersection, to measure cyclic flow profiles in real-time. It uses these estimates to predict arrival profiles at the downstream intersection and to adjust phase times and offsets by up to 4 seconds, again once per cycle. The Spanish CARS system does not rely on the concepts of cycle split and offset settings but instead calculates acyclic settings. The system interacts with the environment on the basis of the information collected from the detectors on the streets and the traffic light changes at the intersections. Also it uses information from its underlying simulation model PACKSIM[Grau, R.; Barcelo, J. 1992a] and [Grau, R.; Barcelo, J. 1992b]. While these systems, broadly speaking, have met all expectations, a number of shortcomings remain. According to [Papageorgiou M. 1991], these are: (a) They respond only to flows measured by the traffic counts and cannot deal with specific origin destination trip demands. (b) Traffic signal control in the city traffic network is not yet integrated with traffic freeway control (i.e. ramp metering on urban clearways). Signal timing and ramp metering rates are obviously related and should be considered together, in order to achieve total system optimisation. (c) The current systems are relatively slow to respond to sudden changes in traffic flows caused, for example, by an incident or a work shift change in a factory. This is because the systems have been designed to implement small changes over time in order to overcome the problem of frequent transitions. (d) They rely on data from vehicle detectors, which are not yet 100% reliable. This reliability should improve as inductive loops, presently in use, are made obsolete by the new systems. 4

21 Future Traffic Control Schemes - predictive management and control. By its very nature, route guidance has to operate on time scales that are significantly longer than a single traffic signal cycle in order to be useful to road users. Consequently, the optimisation horizon of the control schemes must extend over several traffic signal cycles, thus necessitating correspondingly longer-term predictions of the evolution of traffic flows. This can be achieved by implementing a new layer of control, called a supervisory layer, which serves as an interface between the present control systems and a human operator. Such a layer will provide reliable predictions for the evolution of the traffic flow on a time scale comparable with the time needed for a car to cross the traffic network under control. The future generation traffic control systems will attempt to provide such a supervisory layer of optimised control by using both in-vehicle and roadside dynamic route guidance. To satisfy the objectives, posed by the necessity of technological improvement of the existing control schemes, the supervisory layer of control for a future generation traffic control system should have the following features [Euler G. 1988]: (a) integration of an urban intersection signal control system with all other traffic control systems (e.g. freeway control, public transport control etc.) - in effect this is more than just sharing information, it is coordinated control for the city. (b) fast detection of incidents and immediate response to the traffic flow - demand responsive changes to signal timing, detecting slow moving (high-occupancy) vehicles and facilitating their movements across the traffic network. (c) ability not only to take demand-responsive control decisions for queue minimisation on a separate cross-road (short time scale control), but to predict and respond to Origin- Destination information for journey time minimisation and priority paths or detours accommodation (long time scale control provided by the supervisory layer). (d) inclusion of artificial intelligence/expert systems in the decision making process. Such knowledge-based systems could be of enormous help in a control system for operator-control system type interactions. (e) real-time communication with motorists - provide timely information for trip planning purposes and for navigation in conjuction with an in-vehicle device (a vehicleto-system link should also be included for purposes of monitoring traffic flows and collecting Origin-Destination information). Once again the necessary information is a product of the prediction process in the supervisory layer of control. (f) variable speed control - determine appropriate speeds during periods of congestion and inclement weather, advise motorists of that speed and adjust control parameters based on that speed. The decision for control intervention is a direct consequence of the 5

22 existing or anticipated congestions and it is delivered by the higher (supervisory) layer of control Supervisory layer s computer system design considerations. The early control schemes (for example the first generation of traffic control systems) did not extensively use the whole range of opportunities offered by the computer systems and in some cases did not use computers at all. The current traffic control schemes usually use models running on one machine (SCOOT, SCATS etc) and implement the control decisions through a sophisticated proprietary communication network. In contrast, the designers of the future generation traffic control schemes face the challenge of building a computer system which can accommodate all software modules reflecting the requirements listed in and quite possibly a number of new, not yet envisaged, requirements. Although it may be possible to run all the necessary software on one multiprocessor super-machine, it would be impractical for economical and organisational reasons. Therefore, such a traffic control system must be implemented within a distributed computers integrated environment, which provides fast and effective communication between the modules in the system. The main requirement for such an environment is the speed of the data transfer between the modules, therefore the communication software has to be designed and implemented with the speed of the communication as a main precondition in the development. All modern cross-platform communication systems such as PVM, DCOM and CORBA use TCP/IP as an underlying message passing protocol with complex user interfaces built on, thus allowing universal object-oriented data exchange between the modules in the system. Inevitably, such a specification will be less efficient than a system designed specifically for the needs of a traffic control system for two main reasons: (a) Comparatively big software overhead. (b) Lack of data structures specifically designed to cope with the volumes of data inherent for the traffic control systems. Subsequently the integrative environment has to be designed and built on the lowest possible level (i.e. the design has to consider all implementation issues of fast data exchange between the modules and the rejection of all interface definition layers). The environment must also provide a simple and reliable application programming interface. In particular, the distributed shared memory method of communication has to be considered as a very fast, simple and reliable way of data retrieval since, for the client program, data retrieval is nothing more than reading/writing from/into a memory location. 6

23 SCOOT real-time traffic control system, Nottinghamshire installation. This research has been carried out in collaboration with The Nottingham Traffic Control Centre (see Appendix A, Figure 6 for a picture of the Nottingham Traffic Control Centre). This collaboration enabled effective collection and usage of traffic flow counts data, gathered by the real-time traffic control system SCOOT [Hunt P.B., Robertson D.I., Bretherton R.D., Winton R.I. 1981]. SCOOT is a joint research product of The Transport and Road Research Laboratory (TRRL) and British industry. It is a dynamic on-line method for signal control and, in essence, it works on the same basis on which the TRANSYT program [Robertson D. I. 1969] works. It continually measures the traffic demand on all roads in the coordinated network and optimises the signal timings for that measured traffic. Currently the Nottingham Traffic Control Centre employs an installation of SCOOT which allows on-line control and on-line traffic flow data collection for Mansfield (north Nottinghamshire) and Nottingham. Throughout this research all modules, interface links, interface connections and predictive simulation model validations have been performed on the basis of data collected for the Mansfield region. The structure of the traffic network for this region is shown in Appendix A, Figure Aims of the research. The research aim of the project is to investigate the feasibility of a flexible computing environment in which various new applications (representing the supervisory layer of control) can be fully integrated with the existing traffic control system without adversely affecting its performance. Furthermore, the integrative environment will accommodate a number of different modules: a predictive traffic flow simulation module, defined in the discrete systems domain and capable of predictions of cycles ahead in time (i.e. the prediction time scale of the supervisory layer of control); turning movements coefficients estimation module (i.e. the traffic flow splitting coefficients for every intersection in the traffic network); confidence limits analysis module for quantifying the confidence limits of the predicted traffic flows. confidence limits analysis module capable of deriving the error bounds on the statistical characterisation of the drivers turning movements. The combined system, represented by the above mentioned modules working within the integrative environment, together with an intuitive graphical interface facilitating the interaction between the operator and the traffic control system, will be deployed on a multiplatform distributed computers environment. 7

24 The separate aims of this research are: (i) The structure of the supervisory layer of control for traffic control systems should incorporate the existing real-time traffic control systems together with various software modules, such as a predictive simulation module, traffic network state estimation module, traffic congestion prediction module etc. The extensive research, that has already been carried out, on the architecture of the current traffic control systems and their computer implementations led to recognising the distributed computers environment as a suitable solution for the problem. The first specific aim of this research, therefore, is to propose a solution of the overall structure of a supervisory level of control for a traffic control system in a distributed computers environment. (ii) The second aim is to create a suitable software environment for the execution of software modules in the control scheme and to demonstrate the advantages of this approach by integrating the existing SCOOT traffic control system with the modules of the supervisory layer of control. The research investigated the suitability of the distributed shared memory system approach [Stumm M., Zhou S. 1990]; [Archibald J., Baer J.L., 1986], [Argile A., Peytchev E., Bargiela A., Kossonen I. 1996] to enable fast, easy and uniformed access to SCOOT traffic data by applications executing on distributed computing nodes without introducing computational overheads on the real-time operational traffic control system (such as SCOOT). (iii) To develop a predictive urban traffic flows simulation module and to use realtime telemetry data for calibration of the model is the third aim of the project. The module has been designed to process all available traffic control system data (more than 115 Mb per day) on-line and was used to derive short-term predictions (up to 30 minutes) of queues and traffic densities. The module was designed to help the operator in taking strategic decisions about the traffic control [Peytchev E., Bargiela A., 1998]. The telemetry data (collected within the framework described as the second objective of this research) was used to calibrate the model. (iv) The fourth aim of the research is to assess the accuracies of the physical measurements through the analysis of data sets provided by the Instrumented City project. The estimation of the accuracy of the physical measurements is the first step towards the estimation of the confidence limits of the predicted traffic flows. Comparison between video- and alpha-numerical data was used to compare the 8

25 real lengths of the queue with the lengths of the queue measured by the real-time control system (SCOOT). (v) To obtain the statistical characterisation of the drivers turning movement coefficients using data from traffic counts is the fifth aim of the project. The predictive simulation module makes use of an on-line turning movements coefficients estimation module, implemented on the basis of the ideas presented by [Cremer M., Keller H. 1987], [Kessaci A., Farges J.L., Henry J.J., 1989]. The research investigated the possibility of inclusion of equations, containing intersection stage information, in the formulation of the problem in an attempt to improve the reliability of the results, already reported by the above mentioned authors. The data was delivered by the existing traffic control systems (SCOOT) through the interface offered by the integrative environment. (vi) Sixth aim: to develop an algorithm capable of deriving the error bounds on the statistical characterisation of the drivers turning movement coefficients. Using the results produced by the turning movements coefficients estimation module and on the basis of the ideas presented in [Bargiela A., 1985], [Gabrys B., Bargiela A., 1996], [Bargiela A., Hainsworth G. D., 1989], [Hainsworth, G.D. 1988] the aim is to develop an algorithm which uses the inaccuracies of the input data to quantify the error bounds of the final solution. (vii) To develop an algorithm to quantify the confidence limits of the predicted traffic flows is the seventh aim of this research. The possibility of developing an algorithm for the formal assessment of the accuracy of the calculated state (i.e. the accuracy of the traffic queue and density predictions) was explored. This is an extension of the Confidence Limit Analysis method [Bargiela A., 1985], [Gabrys B., Bargiela A., 1996] from the continuous to the discrete systems domain. (viii) To investigate the possibility of a uniform user display across different platforms within the integrated environment, which will allow the efficient interaction of the operator with the predictive simulation software is the project s last aim. This research aim researches the issues of building a decision support software and implementing an intuitive graphical interface for the operator as a part of the distributed computers software environment. The flexibility of the software environment allows the interface to be used on desk-top computers and on lap-top computers with a mobile telephone link to the control centre. Such an 9

26 environment facilitates the operator s interaction with the real-time traffic control systems Organisation of the thesis. This thesis consists of 7 chapters. Chapter 1 This chapter presents the rationale for the development of a distributed computers environment in support of traffic telematics applications. It describes the most important features of the new generation of traffic control systems and sets the main objective - to investigate the feasibility of an integrative environment for urban traffic simulation and control. This chapter also lists 8 particular aims for this current project. Chapter 2 investigates design issues for building a distributed traffic control system. This work proposes an architecture through which isolated and subarea traffic controls, together with high level area control decision making, can evolve into a hierarchical system that achieves strategic planning for more efficient management and control of the traffic over the wider urban area and eventually over the whole city. The considered architecture of the system uses a modular approach, where all modules in the system run in a distributed processors environment and it integrates all supervisory traffic control layer modules. A prototype implementation of the proposed system is presented. Chapter 3 discusses various approaches for building a distributed shared memory system and describes the research process that has led to the identification of data structures to support the traffic control systems operation. Subsequently, a distributed computers shared memory system DIME, which stands for DIstributed Memory Environment has been designed and implemented. DIME provides a generic processing harness for the execution of software modules and administers the communications between the modules, making the network connections transparent for the traffic control software modules. It is designed to support a variety of operating systems. Chapter 4 presents a new predictive city traffic flows simulation model that provides a basis for the real-time on-line optimisation of urban traffic. Since the simulation model is used to estimate present traffic network conditions and predict future congestion conditions, the dynamic nature of traffic operations, such as the formation and dissipation of queues, is reflected in the model. It works faster than real-time in order to be able to perform a prediction for the traffic network and allows a choice of time step. It has been formulated in a state-space domain. The model satisfies the requirements for prediction of traffic flows and queue lengths on large scale (several hundred nodes) urban traffic networks. 10

27 The macrosimulation model works in an integrated environment, which includes one macrosimulation and one or more microsimulation models. It supplies traffic flow and traffic density data to the microsimulation model (or to the several copies of the microsimulation model running in a distributed environment). These data represent a harness for the running microsimulation modules. Subsequently, the microsimulation models return validated traffic flow parameters needed by the macrosimulation process. This openness of the macrosimulation module is one of the important features of the model. Since the implementation of the car-following microsimulation model is a pretty straight forward process, the research emphasis, in this part of the thesis, is on the usage of the model in the context of the supervisory layer of control. The most important issues discussed in this chapter are: using the microsimulation model for validation of the macrosimulation model s parameters for several, particularly critical, traffic network intersections. simulating one separate section of the traffic network within the predicted constraints provided by the macrosimulation process and using the car movement s information as implicit measurements. running the microsimulation model within DIME (more than one copy at a time can be used for verification of the macrosimulation process) Chapter 5 describes the developing process for the turning movements estimation module, designed and implemented in the presented supervisory layer of the traffic control system. It is used as a source of origin-destination information for both macroand microsimulation modules. This module works on the basis of the data collected by traffic counts (inductive loops in the case of the SCOOT real-time traffic control system). It takes into account all measured entry and exit flows for each controlled link. The formation of the mathematical model for this module follows the ideas of [Cremer M., Keller H. 1981] and [Kessaci A., Farges J.L., Henry J.J., 1989]. This method is well-known as crosscorrelation method for traffic movements coefficients estimation [Cremer M., Keller H. 1987]. Chapter 6 examines the accuracy of the predicted results. It is clear, that because of inherent inaccuracies of the measurement data, the predicted results will vary within certain boundaries and this can affect significantly the reliability of the system. It is important, therefore, to find a way to quantify the inaccuracies of the predicted queues and traffic densities in order to determine the prediction horizon, for which the prediction results remain acceptable. Subsequently this chapter describes the investigation of the applicability of the methods, used in the confidence limit analysis process for continuous 11

28 systems domain, into the discrete systems domain. It starts with the assessment of the accuracy of the physical measurement data, as supplied by the real-time control system SCOOT, and a comparison between video data, collected for a given cross-road and the collected alpha-numerical data is presented. The next stage in the process is to estimate the error bounds on the statistical characterisation of the drivers turning movements coefficients, on the basis of the computation process presented in Chapter 5. Subsequently, an error bounds quantification algorithm is developed and described. Next in the chapter follows the quantification of the accuracy of the predicted traffic queues and traffic densities for the traffic network. The quantification is based on the traffic queues and traffic densities prediction process of the simulation model (the simulation model is described in Chapter 4). Chapter 7 contains the final conclusions of the thesis, together with topics for future research Original Contributions. The original contributions of the research are as follows: Investigation of a suitable design for a traffic control system with predictive control and prototype implementation of its Supervisory Layer. Exploring the possibility of using the concept of distributed shared memory to design and implement an integrative environment (DIME) for simulation, monitoring and control of urban traffic. Design and implementation of PADSIM: A Predictive Macroscopic City Traffic Flows Simulation Model. Calibrating the model using telemetry data collected by an additional module connected to SCOOT using DIME. Investigation of the possibility of implementation of a car-following microsimulation traffic model within the DIME distributed environment, with emphasis on the distributed implementation of the combined macrosimulationmicrosimulation interaction. Examining the problem of estimating on-line drivers turning movement coefficients using real-time traffic count data obtained by the operational traffic control system SCOOT. Exploring the feasibility of applying the confidence limits analysis methods, developed for the water network control systems, into the traffic control systems domain. Presenting an original algorithm for deriving the error bounds on the statistical characterisation of the dynamic drivers turning movements coefficients. 12

29 Assessment of the accuracies of the data supplied by the real-time traffic control system SCOOT for the purposes of the confidence limit analysis process. Applying the confidence limits analysis algorithm for quantification of the predicted traffic queues and traffic densities. Design and development of a macrosimulation module s graphical interface for facilitating the interaction between the operator and control system as a part of the operators decision support environment. Design and implementation of an X11- based Graphical User Interface package. 13

30 Chapter 2 DISTRIBUTED HIERARCHICAL CONTROL OF URBAN TRAFFIC Viewed from the control engineering perspective traffic control schemes can be represented as follows: Predicted state of the traffic network Human operator or automated interventions Goal (min. travel time, min. stops in queue) Feedforward (traffic prediction) on-line data Input (on-line controls) Feedback (traffic controller) Control Process Predictable disturbances (historical data) Process measurements (data collection) Process (road traffic) Non-predictable disturbances Output Figure 2-1: A Basic Traffic Control Scheme The process under control (i.e. a road network) is affected by controllable inputs (e.g. traffic lights) and a variety of disturbances. Disturbances are classified as non-predictable (e.g. incidents, random nature of the traffic flow etc.) or predictable (e.g. demand variation during the day, origin-destination matrix changes during the day etc.). The 14

31 control problem is to appropriately select the controllable inputs from an admissible control region so as to satisfy the control objective (e.g. min. travel time or min. number of stops in the queue etc.) Design of modern traffic control systems - hierarchical spatial structure. The next paragraphs describe the design of the operational architecture of a generalised traffic control system starting with an overview of its hierarchy as described by [Ben- Akiva M., Koutsopoulos H.N., Mukundan A., 1994] The traffic control system - hierarchy architecture of the system. The nature of traffic control systems is such that they need to operate in real-time (e.g. concurrently with the occurrence of the traffic). This requirement demands high performance computer systems [Koutsopoulos H., 1992], [Mahmassani H., Hu T., Jayacrishnan R., 1992]. However the price of high-performance shared memory multiprocessor machines makes them, in general, uneconomical for traffic control applications so the hierarchical and distributed system architecture is the most natural solution for traffic management and control. It has been demonstrated, from applications in other fields, that hierarchically distributed systems have improved management, can collect and use large amounts of data [Kaysi I., 1992], [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994] and have improved reliability and fault tolerance. The hierarchical distribution of information and control implies system modularity, which helps the implementation and the geographical growth of the system, and supports the introduction of new technologies and the evolution of existing ones. Finally, communication links overload can be reduced by implementing some of the modules locally, thus reducing communications requirements over longer distances. An example of a hierarchical system is illustrated in Figure 2-2 [Holtz A., Much C., Goblick T., Corbett E., Waxman A., Ashok K., Ben-Akiva M., Koutsopoulos H.N., 1992]. The proposed structure puts the emphasis on the spatial hierarchy of the system. At the highest level of the hierarchy (District Node) [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994], the monitoring and the management of traffic flow is performed throughout a wide area, i.e. in the boundaries of the city, or in the case of a motorway control throughout the length of the controlled route. Directives containing new route or flow control instructions are obtained from prediction and control algorithms which use real-time traffic data, incident information and current control settings at the lower levels of the hierarchy. The next level in the hierarchy is the regional node. This level coordinates traffic signals (i.e. this is the existing real-time traffic control system SCOOT level), provides 15

32 freeway congestion advice and coordinates the control of local freeway segments. The primary tasks at a regional node include [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]: using traffic flow counts to obtain a collection of traffic flow data from a defined set of local nodes. predicting and acting according to a set of regional origin and destination data. coordinating traffic signals for optimisation of the traffic flow control within and between the local nodes. detecting accidents within the geographical boundaries defined by the set of local nodes under control. District Node Supervisory Control Level SCOOT level Regional Node SCOOT level Regional Node Cluster of local Nodes Cluster of local Nodes Figure 2-2: Hierarchical spatial structure of an Advanced Traffic Management System The lowest level of the hierarchy is the local node [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]. Typical configuration of such a node consists of the traffic sensors (inductive loops) and a linked set of local processors controlling traffic signal changes (no optimisation at this level). It collects detailed traffic flow measurements from a distributed set of sensors or from a local sensors group which measure key traffic variables in real-time (e.g. occupancy data for each link in the traffic network). 16

33 Design considerations not reflected in the hierarchical spatial structure of the traffic control systems. While representing the global view for the traffic control system, the generic traffic management node structure and the hierarchical structure of an advanced traffic management and control system do not take into account several important considerations for the development of the modern traffic control systems: (a) The control on a regional level together with the control for the clusters of local nodes is usually encapsulated into a Demand Responsive Signal Settings Real- Time Control System (such as SCOOT) and is already implemented for many urban traffic networks all around the world. Therefore, the place of such a control system has to be clearly indicated in the hierarchical spatial design of the system. (b) There are two different types of control interventions available according to the time scale on which they operate. Strategic interventions, concerning a subset of regional and district nodes (or all of them) (regional and district nodes as shown on Figure 2-2) and operational interventions, dealing with one or two cross-roads only. The strategic interventions are defined on the highest level only and their distinctive characteristics are as follows: they are real-time control system specific and reflect the way it controls all timing plans in the traffic network. the strategic interventions work on a different time scale in comparison with the control sequences used for operational control (e.g. traffic lights settings). Typically, an intervention, which has a lifecycle equal to the time needed for a vehicle to cross the traffic network (usually between 15 and 30 min.), is a strategic intervention for the system. In comparison the operational control interventions have lifecycles equal to the cycle of the traffic lights in the system (approximately 90 sec). This clearly temporal distinction between the different interventions is not reflected in any way in the design of the modern control systems. (c) The traffic signal control system uses a local area communication network or indeed, shared memory computer configuration, specifically designed to meet the requirements of the time-critical data transfer between the signal settings control system modules. By contrast, the highest level of the control system configuration is built around a general LAN/WAN network. (d) Despite the importance of fast data exchange, the design of the modern traffic control systems does not reflect explicitly the type of communication software used in the inter-process communications, considering it to be of no importance. Yet some attempts to port the simulation software into a distributed environment 17

34 found that this is a problem (for example an attempt to transfer the simulation model AIMSUN, developed at the Technical University of Barcelona, from a single machine into a distributed computers environment using PVM). Therefore, the design must take care of developing the appropriate communication routines Design of modern traffic control systems with supervisory control - hierarchical temporal - spatial structure Temporal structure of a traffic control system with supervisory layer - control engineering point of view. Taking into account the functional structure of the traffic control scheme presented in Figure 2-1 and applying the design considerations, described in 2.1.2, leads to the traffic control systems temporal structure shown in Figure 2-3. The control process reflects the requirement for prediction on short and long term bases and it is divided into two different parts: Supervisory Layer of Traffic Control System Operational Traffic Control System Layer The operational layer monitors the process and generates control sequences on a short term basis, while the supervisory layer is responsible for more general changes in the controlled process. The presence of the two layers is justified also by analysing the trends of development of the future traffic control systems as described in paragraph 1.1.3, where the presence of a supervisory layer of control is a requirement. As it is in the previous figures, the process under control is the urban traffic. All possible process measurements (traffic counts data, other surveillance data) are collected and sent to the control system. On the basis of all historical data (predictable disturbances) and all current data (process measurements data), the control system estimates the current state of the system and gives a prediction for the next controlled period (feedforward). The operational layer gives a prediction for 1-2 cycles ahead only and accordingly generates operational control sequences (for example split, cycle and offset values for the traffic lights in the traffic network) and sends them back for implementation in the process under control (feedback). Working in parallel with the operational control, the supervisory layer takes into account the existing demand in the system and, using the generated prediction state, generates control sequences valid for up to cycles (for example giving an additional 6 sec. of green light for all cross-roads in the heavily congested directions). The structure of the operational layer of control depends on the type of real-time control system implemented on the road and, in the case of this research, this is the SCOOT 18

35 Human Operator Interventions Predictive Control Goal (Performance Index Optimization) Queue Lengths Estimates (long term) long term Strategic Interventions (3-15 Cycle Controls) Supervisory Layer of Traffic Control System Goal (queue minimisation) Process Measurements (On-Line Traffic Movement Information Data) Adaptive Operational Control Queue Lengths Estimates (one cycle) On-Line Input (1-2 Cycle Controls) Operational Traffic Control System (SCOOT) Measurements Predictable Disturbances (Traffic Flow Variations) Process (Urban Network Traffic Flows) Non-predictable disturbances (random nature of the traffic flow, accidents) short term Figure 2-3: Temporal Structure of a Traffic Management And Control System - control engineering approach system. Its internal structure is considered to be of no importance for the aims of this thesis, since the SCOOT system is an accomplished commercial product and this information is proprietary and confidential. A short description of the building blocks of the supervisory layer of control is given in the next paragraphs. 19

36 Traffic control system design - building blocks of the supervisory layer of control. The design of the main building blocks of the supervisory level of control for the system is shown in Figure 2-4. The proposed structure is designed to operate in real-time using universal network communications protocol for data exchange and it contains six main modules: (a) Communication Module. (b) Turning Movements Estimation and Prediction Module. (c) Surveillance Module. (d) Queue Prediction Module (includes the Traffic Network State Estimation Task). (e) Control Strategy Generation Module. (f) Operational Control Generation Module. Turning Movements Estimation and Prediction Module Surveillance Module Queue Prediction Module Control Strategy Generation Module NETWORK Communication Module. Provides all communication links and data exchange between the modules Operational Control Generation Module (SCOOT) Figure 2-4: Supervisory Layer of control - functional structure. The functionality of each of the modules is described in the following paragraphs. 20

37 Communication module. In essence, the purpose of this component is to perform all data transfers between the program modules across the distributed environment independently of the network and transparently for the user. The design and structure of the network communication module is described in Chapter 3. Universal communication media (Internet, wide area network (WAN)) are introduced. They are used by the programming modules belonging to the district node to communicate with each other and with the real-time traffic control system and to exchange control data needed for the successful simulation, monitoring and control of the urban traffic. This approach allows some of the modules to be situated on, and make use of, relatively inexpensive machines and at the same time provide, on-line, all the data and computational power needed. The addition of a communication module reflects the underlying idea of providing each one of the supervisory layer modules and the traffic control system modules with a communication sub-part, allowing easy and module-independent access to the communication media Turning Movements Estimation and Prediction Module. One of the key inputs to the supervisory layer of control is a time dependent turning movement coefficients estimation. This estimation is a necessity for the traffic control system and the functional structure of the module is designed to provide information about the divergence of the traffic flows from their historic (diurnal, weekly or monthly) patterns. Unfortunately, historic turning movement coefficients may not always give the actual travel demand in the network. The divergence of traffic flows from their historical patterns may be caused by capacity changes on the network, such as the closure of roads or lanes, special occasions that attract a large amount of trips to a temporary destination, random fluctuations etc. Therefore, the capability to estimate and predict turning movement coefficients in real-time is one of the requirements for traffic modelling. The Turning Movement Coefficients Module includes a model that can be used for real-time prediction (using historical data and measures of actual flows on the network obtained by the Surveillance Module). It contains the required interfaces for data exchange with the other modules of the system. This thesis concentrates on turning movements estimation and prediction (as opposed to origin-destination matrix calculation for the whole traffic network) for two reasons: (a) all data coming from the control systems in their majority represent traffic counts data measuring traffic flows at a particular point and do not reflect the individual characteristics (such as type of the vehicle, registration number etc.) of the vehicles passing by. Therefore, it is not possible to directly obtain origin- 21

38 destination information from traffic counts. However, it is possible to obtain estimates for turning movements coefficients on the basis of the data gathered by the real-time control system (such as SCOOT). (b) both microscopic and macroscopic simulation models, presented in Chapter 4 of the thesis, consider one cross-road at a time, therefore they need to use traffic flow splitting coefficients for every particular cross road in the traffic network. Traffic turning movements coefficients are discussed in detail in Chapter 5 of this thesis. The output from this module is used either for error detection and correction, state estimation or simulation and prediction. The very nature of the calculations requires at least two instances of the program to run in parallel, where one of the instances works on simulated data and provides predicted estimates for the prediction horizon, while the second instance of the module provides estimates for the data already collected by the system. The first instance uses, in its calculations, all historical and all current data collected from the real-time traffic control system up to the moment of initiation of the calculations. It provides information about past and current coefficients estimates. In order to produce predicted estimates for the traffic movements coefficients, the second instance of the matrix solving program uses the same algorithm (the same set of equations) but works on the basis of three types of data: historical data. current data collected from the real-time traffic control system up to the moment of initiation of the calculations. simulated data. The results from the Turning Movements Estimation and Prediction Module on-line estimates for the current and past traffic movements coefficients are available permanently (i.e. the estimation is running at all times) as opposed to the results for the predicted estimates, which are available on a request only basis. This duality is resolved by running two different copies of the estimation task. The natural solution for running two instances of one program is to run them on separate processors in a distributed computers environment. A distinctive feature of this design is the fact that each of the Turning Movements Estimation and Prediction Tasks incorporates communication interface, thus allowing easy communication with the rest of the system. Therefore, a network communication component is included in each task to facilitate the interaction with the network. 22

39 Surveillance Module. The proposed design of the module and its functions were best described by [Ben- Akiva M., Koutsopoulos H.N., Mukundan A., 1994]. Information about the current traffic situation varies, depending on the type of data gathering system employed. The Surveillance Module (in an ideal system) communicates with all possible programs and devices capable of providing traffic flow information. Such programmes and devices may include traffic flow counts, in-vehicle devices, videocameras etc. In a system where there is two-way communication between the traffic control centre and every vehicle in the network, perfect information about the traffic conditions, in terms of the location of every vehicle and its origin-destination route, could be obtained. However, it is by no means certain that such detailed monitoring is socially acceptable, so for now this perfect monitoring scenario belongs to the future. Most of the existing surveillance systems are limited to vehicle presence detectors located at critical points in the network. The information provided by these sensors therefore, must be extrapolated to traffic flows, queue lengths, incidents etc. at all points on the network. Also, other information, such as police reports, input from probe vehicles, etc., must be included. In the case of the working prototype of the proposed system, however, this module is restricted to a communication link between the supervisory layer of control and the operational control system SCOOT. This research work does not concern and does not investigate or propose any surveillance module in particular. This fact does not impose any loss of generality since the distributed system, described in section 2.2.2, allows any surveillance modules to be added to the system effortlessly Queue Prediction Module. The Queue Prediction Module s task is to attempt to give an answer to what-if type of questions.the Queue Prediction Module consists of two main modules: Traffic Simulation Model and Driver Behaviour Model. The simulation of the traffic in the presented system is needed in two capacities. The first task, that requires simulation, is the State Estimation Task, where the traffic simulation is used to obtain an estimate of the current state of the network (by extrapolating incomplete information obtained from the traffic sensors and other elements of the surveillance system, if available). The second task, requiring simulation, is the Queue Prediction Task, which uses the simulation model to predict future traffic network conditions. 23

40 The requirements for the simulation model in these two capacities vary in terms of granularity and running time. The State Estimation Task needs an accurate model which works slightly faster than real-time, while the Queue Prediction Task requires a model that runs much faster than real time. However, apart from this difference, the characteristics of the two simulation models used in the state estimation and traffic flow prediction are very similar. Examples of important shared attributes for the two models are queue lengths and traffic densities. Furthermore, since the simulation model is used to estimate present network conditions (state estimation) and predict future queue prediction (predictive simulation), the dynamic nature of the traffic operations, such as the formation and dissipation of queues, spillbacks and congestions, needs to be modelled in detail. The starting point for the simulation model is always the real data provided by the Surveillance Module. The turning movement coefficients estimation module provides the required estimates of future traffic flow splitting coefficients. The successful simulation requires its own additional operational control and strategy generation modules. In response to the predicted traffic flows and queues, the control strategy generation module will supply the controls for the predicted traffic conditions. The second main part of the Queue Prediction Module is the Driver Behaviour Model, which is used to determine a driver s path choices and response to routing recommendations [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]. This research does not concern The Driver Behaviour Model. However, as it is in the case of the Surveillance Module, the design of the system allows such a module to be added to the system simply by running it with the appropriate interface within the distributed system. The output from the Queue Prediction Module consists of state estimates of the traffic network at future time points, where the state of the network is mainly determined by measures of traffic flow densities and queues. The state of the network, as defined in the simulation model, is discussed in detail in Chapter 4. The design of the Queue Prediction Module takes into account two important considerations: There are at least two tasks requiring simulation models: the State Estimation task and Queue Prediction task. This makes the presence of multiple instances of the simulation model necessary. Running several copies of the simulation program is effortless within the proposed distributed computers environment structure. They do not have to run on one computer, but simply to be present in the network environment and the Network Communication Component will perform all necessary data transactions. 24

41 The Queue Prediction Module has two inputs, conveying the control strategy which controls either the predicted or the real traffic flow: input from the Operational Control Module and input from the Control Strategy Generation Module. For the case of the simulated data the Operational Control Module receives all simulated non-averaged measurements (Traffic Counts, Queue Lengths and Traffic Flow Densities) and provides the necessary operational controls in response to the simulated measurements on a cycle-by-cycle basis. The Control Strategy Generation Module receives all simulated measurements (Traffic Counts, Queue Lengths and Traffic Flow Densities) averaged over a period of time chosen in advance (usually equal to the time duration of 2-5 control cycles of the traffic lights in the traffic network) and provides the corresponding global strategy controls (either automatically generated or as a result of operator input). Thus the design of the module reflects the structure of the system with the intersection s signal settings control sequences generated by the operational control level and the global Control Strategy Control Sequences generated by the Control Strategy Generation Module as part of a supervisory layer of control Control Strategy Generation Module. A control strategy is either route guidance information or a combination of route guidance information and traffic control measures (traffic lights setting changes). The primary objective of the Control Strategy Generation Module is to provide relatively long term (5-30 min.) route guidance information for the drivers and a relatively long term (5-30 min.) control strategy. Both the route guidance information and the control strategy are based on estimates of average values of the queue lengths, traffic densities and travel times (in contrast, the Operational Control Strategy Module s control is being calculated on an instant value basis (i.e. demand responsive)). The generation of control strategies is based on an iterative process (as presented by [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]). An iteration consists of a trial control strategy, the prediction of the state of the network under the trial strategy and the evaluation of the predicted state. The Queue Prediction Module works in parallel with the Control Strategy Generation Module to form this iterative loop. The trial control strategy, after comparison between the results from the Queue Prediction Module with the goal of the on-line control, is either accepted or rejected using predetermined evaluation criteria. If a trial control strategy is rejected, the Control Strategy Generation Module generates a new one, the Queue Prediction Module generates new average values estimates for the queue lengths, traffic densities and travel times based on the new strategy whilst taking into account all operator s interventions. Next there follows a new comparison and so forth. The iteration is continued until a control strategy is accepted. 25

42 The Network Communication Component included in the functional structure of the module guarantees proper and in-time data exchange. This research does not investigate any control strategy in particular. Instead it relies on control strategy data provided by either a second copy of the control sequences generation module or on another module capable of emulating the work of the control strategy generation module Operational Control Generation Module. The Operational Control Generation Module is an indivisible part of the real-time traffic control system implemented on a regional node level. In the overall structure of the system, this control generation module is represented by the acting operational control system (SCOOT, SCAT etc.). However, the successful operation of the Queue Prediction Module requires additional knowledge for the traffic lights settings that the real-time operational control system would implement in response to the simulated instant measurements. Thus a second copy of the Operational Control Generation Module is needed. The input data for the first copy of the module are instant flows data, queue lengths and travel times. Subsequently, the first copy generates control on the basis of the real-data collected from the traffic sensors. Input data for the second copy of the operational control generation module are simulated measurements together with the accepted future control strategy and operator interventions (if there are any). It provides the operational control sequences in response to the predicted traffic queues and densities to the Queue Prediction Module Dynamic traffic model system - inter-process communication structure. The modules described in the previous paragraphs are integrated to form a system capable of simulation, monitoring and control of urban traffic in real-time. Figure 2-5 provides an overall summary of the information flows in a dynamic traffic model system. It indicates whether only a single copy of a task is needed (i.e. Queue Prediction Module) or if the work of the control system requires several copies of the given task to run simultaneously. The system collects the sensor data obtained from the traffic sensors and uses them for state estimation. The output from this stage is the estimate of the traffic densities and queue lengths for every link in the network (future more sophisticated measurement devices and software systems will be able to extract information about vehicle locations, their origins, destinations and incident locations in the network). Subsequently the current data are used for a starting point for simulation and queue prediction. The data from the initial state of the traffic network is supplied to the second copy of the 26

43 Turning Movements Estimation and Prediction Modules queue prediction modules Traffic Flow Simulation Modules Driver Behaviour Model State Estimation Task (part of Queue Prediction Module) traffic counts, flows, queues, etc. estimates of past, current and future turning movements simulated traffic counts, flows, queues, etc. accepted control strategy accept/reject control strategy operational controls Traff. Sensors, real-time operational traffic control Operational Control Generation Modules Operator Interventions Control Strategy Generation Module Figure 2-5: Supervisory layer - interprocess communications scheme operational control generation module, which returns the appropriate traffic network control settings to the simulation model. The simulation model generates the next predicted state of the traffic system on the basis of the calculated traffic densities and queue lengths from the previous step and using traffic lights settings as supplied by the second copy of the operational control generation module. The results of the prediction are passed once again to the traffic control generation module and the new settings retrieved. The process is repeated as many times as the prediction limit of the system dictates. Subsequently, the Supervisory Layer presents the future state of the system as a result of the simulation process. The predicted state, described by traffic densities and queue lengths in the current implementation of the system, is presented to the operator. It is envisaged however, that future implementations of the system will evaluate the predicted state of the system from the point of view of the suitability of the current control generation strategy, and the control strategy will be either accepted or rejected. In the case of rejection, a new control strategy will be defined in the second copy of the control 27

44 strategy generation module and its suitability will be estimated by performing a new prediction, which will reflect the new controls. The best control strategy (i.e. the control strategy with the highest correspondence to the performance index (the performance index function is defined in the description of the TRANSYT model [Robertson D. I. 1969])) will be accepted and will become operational. The output from this stage, in the current implementation, is the future state of the network for the prediction period. The integrative framework, developed and described in this research, allows this information to be disseminated to the drivers on the road. Future implementations will include also the recommended traffic control strategy. Routing guidance based on the recommended control strategy will be provided to the drivers and the specified traffic controls will be implemented by the real-time traffic control system in the network. The Turning Movement Coefficients Estimation Module in the current implementation of the system provides estimates of current coefficients for the state estimation process, re-estimates of prior coefficients for the error detection and correction process and predicted estimates of future turning movement coefficients for the simulation and prediction process. The Driver Behaviour Model (not investigated in this research) could be used by the Queue Prediction Module for modelling driving styles, driver path choices and driver responses to guidance information. An important feature of the presented system is its distributed computers environment nature. Each one of the modules in the system connects to the others using a LAN (or WAN) connection. A special component (called the Network Communication Component) is added to each one of the modules in order to make the network connections transparent for the module. This allows easy data exchange, easy data saving and easy data retrieval. Full specification of the Network Communication Component is given in Chapter Concluding remarks on building elements of the traffic control system with supervisory layer. The functional scheme of the traffic control system described in Figure 2-3 reflects several specific features of the traffic control process: (a) Because of the random fluctuations of the traffic flow it is unreliable for the simulation module (i.e. Queue Prediction Module) to predict the exact flows and queues in any one moment of the simulation process for the purposes of operational control. It has been shown that performing an adequate control is possible only on the basis of predicting average traffic flows and queues. Therefore, it is impossible for the simulation module to accurately determine, for 28

45 every cycle in the prediction period, the exact queue length for a given cross-road, therefore the Operational Control Module could not work out what the next settings for the traffic lights duration should be. Instead the prediction module can determine the trend of the change for the control settings (strategic control generation) and leave a demand-responsive control system (such as SCOOT) to perform cycle-by-cycle optimisation (operational control generation). This underlines the necessity of a new supervisory layer of control (not defined as such in the proposed schemes to date), responsible for the implementation of a strategic (i.e. long term compared with the cycle-by-cycle) control of the traffic network. (b) Once the trend of the change is found, it is necessary to relate this trend to the demand-responsive control system (SCOOT) to implement it on a cycle-by-cycle basis. This is possible only by using the trend changing interventions available in the control system and they are specific to any particular traffic control system. Therefore, an interface module, extracting information for the trend-changing interventions available in the operational control system and for relating the optimal control strategy to the real-time control system, is needed. Such an interface module is essential for the presented control scheme. This research does not investigate such a module in detail and considers it to be a subject for a future civil engineering research project. (c) The presented structure reserves a specific place for the already existing traffic control systems such as SCOOT and SCAT and builds further layers on this basis Scope of this research. This research concentrates only on a few of the modules, discussed in the previous paragraphs. It does not attempt to design or implement the rest of the building elements of the control system (particularly if they fall within the domain of traffic engineers), because they differ from the aims of the research project and there is also a limited amount of time and resources. The list of software modules discussed, designed and/or implemented in this research project is as follow: - Structure of the overall traffic control system. - Distributed memory environment (DIME) as a software tool for running all traffic control system modules in a distributed computers environment. - Macroscopic traffic simulation module as a part of a Queue Prediction Module. - Microscopic traffic simulation module as a part of a Queue Prediction Module. 29

46 - Turning movements estimation module (implicit estimation of the Origin-Destination information). - Confidence Limit Analysis for the predicted traffic queue lengths, traffic densities and for the estimated turning movement coefficients Conclusions on Traffic Control Systems with Supervisory Layer of Control. An outline of a system for distributed urban traffic simulation, monitoring and control, giving the background for this research, has been presented. The main components of the system are: Operational traffic control real-time system - responsible for traffic counts data collection and operational traffic signal settings control. Urban traffic flows simulation module. Turning Movements Coefficients Estimation Module. Control Strategy Generation Module. Operator Interface Module. The system is defined with two hierarchical levels: an operational control layer consisting of the existing operational control real-time system and a supervisory layer for traffic management consisting of all remaining modules. The heart of the supervisory layer of the dynamic traffic control system is the simulation model. It uses a combined macroscopic-microscopic approach to simulate the traffic network. The macroscopic part of the simulation model is able to simulate the entire city traffic network, while the microscopic model (possibly several copies of the model running in a distributed computers environment) enables separate simulations for several particularly critical network intersections. All tasks freely communicate within the framework presented in this research. The macrosimulation model provides the overall constraints for the work of the microsimulation task(s), while the microsimulation supplies validated traffic flow parameters back to the macrosimulation model. Such an arrangement for the location of the simulation models in a distributed computers environment allows the use of comparatively inexpensive computers to provide significant computational power necessary for advanced simulation. The proposed structure also recognises the need of an additional control strategy generation module which will determine the control policy over an extended period of time (not the current traffic lights control settings, which are the real-time control system s responsibility). 30

47 The design of the control system considers two, temporally different, levels of control: the operational level of control and supervisory level of control. Subsequently, this research proposes two different types of interventions, available to the controlling body (be it the operator or an automated system): (i) operational control interventions; (ii) supervisory interventions. By their very nature, operational control interventions represent actions concerning one particular intersection or several intersections grouped in a region, i.e. this is the reaction of the control system to the current traffic demand, detected in the streets by the measuring devices. Examples of such interventions are: reducing the duration of the green signal in one direction and increasing it in the opposite direction for a given intersection; increasing/decreasing the length of the cycle of operation of the traffic lights for a given region; changing the offset of the start of the cycle for a given intersection against the start of the cycle of the intersection situated just up-stream etc. The supervisory interventions (also called management or strategic interventions), are sources of more global changes in the behaviour of the control system. They reflect and try to alleviate traffic congestion problems, inherent to some future state (as predicted by the simulation model) of the controlled system. Examples of such interventions are: road-side traffic/travel information; in-car traffic/travel information; change of road network layout by opening lanes in one direction and closing lanes in another direction; providing information on park-and-ride facilities; information for the anticipated environmental impact; information about road pricing etc. The supervisory interventions are evaluated first in an interactive session between the operator and the simulation and control modules of the system and subsequently delivered to the control module through an interface software, which facilitates the interaction between the operator and the system. Such a software should be capable of visualising the simulation process and accepting the changes in the control scenario on-line. This research does not investigate any further the problem with the control interventions. Areas of future research clearly include investigation of the level of automation in applying the interventions to the controlled system. Some of the interventions can be automated - the operational control interventions already are - while for the supervisory interventions the level of automation will depend on the success of the design of the simulation models. The network communication component is present in each one of the modules of the system. It is part of a software environment which is capable of providing easy data exchange interface between the modules. Such a structure is easily implemented as a part of the Internet network, which allows different modules to run on remote machines (not 31

48 situated at the traffic control centre), should the system need it. Indeed such a structure could integrate various modules, developed independently by a number of research laboratories and collaborating bodies towards a common objective. The proposed structure is implemented within the integrative framework, described in the next chapter of the thesis, which allows easy network access to the urban traffic information and makes it easily available on-line for the commuters. Since the design of the integrative framework is based on the internet protocol algorithms, the road information from the control system can be made easily available on the WWW. However, problems occur in deciding what information and in what form it should be presented to the users. This research considers these problems as yet another area of future investigation. 32

49 Chapter 3 DIME - DISTRIBUTED MEMORY ENVIRONMENT The ever growing number of vehicles in the street demands an increased performance by the current traffic control systems. Such an advanced control system can be achieved only by the provision of extensive traffic flow information and subsequent optimised control based on this information. Such an optimization is possible on a supervisory level of control which uses in-vehicle and road-side dynamic route guidance. The complexity of a supervisory layer, capable of control and optimization of urban traffic flow, has created the need for a flexible computing environment in which various applications can be fully integrated. Such an environment must allow any new module to be perfectly accommodated within the existing system without adversely affecting its performance. The most promising approach to satisfying this requirement is the use of distributed computing resources. The search for the most appropriate distributed computers environment has to consider two important issues: the type of data used in the traffic control systems and how this data can be delivered reliably and rapidly to the users. This research concentrates on a distributed computers environment with the minimum software overhead (thus sacrificing functionality) with the main aims of speed of data delivery and simplicity. The distributed computers shared memory (DCSM) system described in this chapter, provides such a processing environment for the execution of software modules of urban traffic control systems. The existing research and commercial architectures (e.g. CORBA, DCOM and most recently High Level Architecture - Run- Time Infrastructure) offer substantial functionality, but at the same time impose overhead delays. The work, presented in this chapter, describes the investigation of the suitability of the distributed shared memory approach for performing the communication tasks within an accomplished traffic control system. An implementation of a DCSM system, developed as a result of this research and based on the distributed shared memory paradigm, has been called DIME which stands for a DIstributed Memory Environment Introduction to distributed computers shared memory systems. Traditionally, communication among processes in a distributed system is based on the data-passing model [Stumm M., Zhou S. 1990]. Message passing systems or systems that support remote procedure calls (RPCs) adhere to this model. The data-passing model logically and conveniently extends the underlying communication mechanism of the system. In the general case primitives such as Send and Receive are used for interprocess communication. This functionality can also be hidden in language-level constructs, as it 33

50 is in the case of the remote procedure call mechanism. In either case, distributed processes pass shared information by value. In contrast to the data-passing model, the shared memory model provides processes in a system with a shared address space. Application programs can use this space in the same way that they use normal local memory. That is, data in the shared space is accessed through Read and Write operations. As a result, applications can pass shared information by reference. The shared memory model is a natural logical model for distributed applications running on shared memory multiprocessors. For loosely coupled distributed systems, no physically shared memory is available to support such a model. However, a layer of software can provide a shared memory abstraction to the applications. This software layer, which can be implemented either in an operating system kernel or with proper system kernel support in run-time library routines, uses the services of an underlying (message passing) communication system. The shared memory model applied to loosely coupled systems is referred to as the distributed computers shared memory (DCSM) model [Stumm M., Zhou S. 1990]. Shared Memory Memory Manager Processor Network Processor 1 Processor 2... Processor N Local Memory 1 Local Memory 2... Local Memory N Figure 3-1: Distributed computers shared memory (DCSM) model So the purpose of a DCSM system is to allow computational tasks to assume a globally shared virtual memory even though the tasks execute on nodes that do not physically share memory. Figure 3-1 illustrates the concept of a DCSM system. 34

51 3.2. Distributed Computers Shared Memory - Advantages. The primary advantage of distributed computers shared memory systems over datapassing systems is the simpler abstraction provided to the application programmer, an abstraction the programmer already understands well. The access protocol used is consistent with the way sequential applications access data, allowing for a more natural transition from sequential to distributed computations. In principle, parallel and distributed computations written for a distributed shared memory system can be executed on a shared memory multiprocessor without the need for change. The shared memory system hides the remote communication mechanism from processes and allows complex structures to be passed by reference, substantially simplifying the programming of distributed applications. Moreover, data in distributed shared memory can persist beyond the lifetime of a process accessing the shared memory. In contrast, the message passing models force programmers to be conscious of data movement between the processes at all times, since processes must explicitly use communication primitives and channels or ports. Also, since data in the data-passing model is passed between multiple address spaces, it is difficult to pass complex data structures. Data structures passed between processes must be packed before transmission and unpacked after reception by the application. For this reason, the code written for distributed shared memory is usually significantly shorter and easier to understand than equivalent programs that use data passing. The advantages of distributed shared memory have made it the focus of recent research and prompted the development of various algorithms for implementing the shared memory model [Bisiani R., Forin A., 1988], [Cheriton D.R., 1986], [Kessler R.E., Livny M., 1989], [Li K., Hudak P., 1989]. Several implementations have demonstrated that, in terms of performance, distributed shared memory can compete with the direct use of data passing in loosely coupled distributed systems [Cheriton D.R., 1986], [Li K., Hudak P., 1989], [Zhou S., Stumm M., McInerney T., 1990]. In a few cases, applications using distributed shared memory can even outperform their message-passing counterparts (even though the shared memory system is implemented on top of a message-passing system). This is possible for three reasons as indicated by [Stumm M., Zhou S. 1990]: (i) The shared memory algorithms that move data between hosts in large blocks, have a communication overhead that is split over multiple memory accesses, reducing overall communications requirements if the application exhibits a sufficient degree of locality in its data accesses. (ii) Many distributed parallel applications execute in phases, where each computation phase is preceded by a data exchange phase. The time needed for the data exchange phase 35

52 is often dictated by the throughput limitations of the communication system. Distributed shared memory algorithms typically move data on demand as they are being accessed, eliminating the data-exchange phase, spreading the communication load over a longer period of time, and allowing for a greater degree of concurrency. (iii) The total amount of memory may be increased proportionally, reducing paging and swapping activity. The advantages of DCSM can be realised with reasonably low run-time overhead and several approaches have been reported (some systems use more than one approach) [Nitzberg B., Lo V., 1991]: Hardware implementations that extend traditional caching techniques to scalable architectures. Operating system and library implementations that achieve sharing and coherence through a virtual memory-management mechanism. Compiler implementations where shared accesses are automatically converted into synchronisation and coherence primitives Distributed Computers Shared Memory - Design Choices. A DCSM system designer must make choices regarding structure, granularity, access, coherence semantics, scalability and heterogeneity [Nitzberg B., Lo V., 1991] Structure and granularity. The structure and granularity of a DCSM system are closely related. Structure refers to the layout of the shared data in memory (it is a linear array of words), but some structure the data as objects, language types or even associative memory. Granularity refers to the size of the unit of sharing: byte, word, page or complex data structure. One of the first transparent DCSM s, Ivy - implemented as software on a set of Apollo workstations - considered the shared memory as virtual memory. This memory was unstructured and was shared in 1-kilobyte pages. In systems implemented using the virtual memory hardware of the underlaying architecture, it is convenient to choose a multiple of the hardware page size as the unit of sharing. Mirage [Fleish B., Popek G., 1989] extended Ivy s single shared-memory space to support a paged segmentation scheme. Users share arbitrary-size regions of the memory (segments) while the system maintains the shared space in pages. Hardware implementations of DCSM typically support smaller grain sizes. For example Dash [Lenoski D. et al., 1990] and Memnet [Delp G., 1988] also supported unstructured sharing, but the unit of sharing is 16 and 32 bytes respectively - typical cache 36

53 line sizes. Plus system is a hybrid: the unit of replication is a page, while the unit of coherence is a 32-bit word. Because shared memory programs provide locality of reference, a process is likely to access a large region of its shared address space in a small amount of time. Therefore, larger page sizes reduce paging overhead. However, sharing may also cause contention, and the larger the page size, the greater the likelihood that more than one process will require access to the page. A smaller page size reduces the possibility of false sharing [Nitzberg B., Lo V., 1991], which occurs when two unrelated variables (each used by different processes) are placed in the same page. The page appears to be shared, even though the original variables were not. Another factor affecting the choice of page size is the need to keep directory information about the pages in the system: the smaller the page size the larger the directory. A method of structuring the shared memory is by data type. With this method, shared memory is structured as objects in distributed object-oriented systems, as in the Emerald, Choices and Clouds systems [Nitzberg B., Lo V., 1991]. Another method is to structure the shared memory as variables in the source language. Because with these systems the sizes of objects and data types vary greatly, the grain size varies to match the application. However, these systems can still suffer from false sharing when different parts of an object (for example, the top and the bottom halves of an array) are accessed by distinct processes. Yet another method is to structure the shared memory like a database. Such a system orders its shared memory as an associative memory called tuple space [Nitzberg B., Lo V., 1991]. This structure allows the location of data to be separated from its value, but it also requires programmers to use special access functions to interact with the shared memory space. In most other systems, access to shared data is transparent Coherence semantics. For programmers to write correct programs on a shared memory machine, they must understand how parallel memory updates are propagated throughout the system. The most intuitive semantics for memory coherence is strict consistency. In a system with strict consistency, a read operation returns the most recently written value. However, most recently is an ambiguous concept in a distributed system. For this reason, and to improve performance, some DCSM systems provide only a reduced form of memory coherence. For example Plus provides processor consistency [Bisiani R., Ravishankar M., 1990] and Dash provides only release consistency [Lenoski D. et al., 1990]. In accordance with RISC philosophy, both of these systems have mechanisms for forcing coherence, but their use must be explicitly specified by higher level software (a compiler) or perhaps even the programmer. 37

54 The use of relaxed coherence semantics allows more efficient shared access because it requires less synchronisation and less data movement. However, programs that depend on a stronger form of coherence may not perform correctly if executed in a system that supports only a weaker form. Figure 3-2 gives a brief description of the strict, sequential, processors, weak and release types of consistency and illustrates the hierarchical relationship among these types of coherence. Strict Consistency A read returns the most recently written value (what most programmers expect) Sequential Consistency The result of any execution appears as some interleaving of the operations of the individual nodes when executed on a multithreaded sequential machine. Processors Consistency Writes issued by each individual node are never seen out of order, but the order of writes from two different nodes can be observed differently. Weak Consistency The programmer enforces consistency using synchronisation operators guaranteed to be sequentially consistent. Release Consistency Weak consistency with two types of synchronisation operators: acquire and release. Each type of operator is guaranteed to be processor consistent. Figure 3-2: Intuitive Definitions of Memory Coherence Scalability. A theoretical benefit of DCSM systems is that they scale better than tightly coupled shared memory multiprocessors. The limits of scalability are greatly reduced by two factors: central bottlenecks (such as the bus of tightly coupled shared-memory multiprocessors). 38

55 global common knowledge operations and storage (such as broadcasting messages or full directories, whose sizes are proportional to the number of nodes). Most of the DCSM systems are currently implemented on top of an Ethernet network (itself a centralised bottleneck), which can support only about 100 nodes at a time. This limitation is most likely to be due to these systems being research tools rather than an indication of any real design flaw Heterogeneity. At first glance, sharing memory between two machines with different architectures seems almost impossible. The machines may not even use the same representation for basic data types (integers, floating point numbers, and so on). It is a bit easier if the DCSM is structured as variables or objects in the source language, then the DCSM can add conversion procedures to all accesses to the shared memory. Some systems explore a novel approach: memory is shared in pages and a page can contain only one type of data. Whenever a page is moved between two architecturally different machines, a conversion routine converts the data in the page to the appropriate format. Although heterogeneous DCSM might allow more machines to participate in a computation, the overhead of conversions seems to outweigh the benefits Distributed Computers Shared Memory - Implementation Choices. A DCSM system must automatically transform shared-memory access into interprocess communication. This requires algorithms to locate and access shared data, maintain coherence and replace data. A DCSM system may also have additional schemes to improve performance. Such algorithms directly support distributed shared memory. In addition, DCSM implementors must tailor operating system algorithms to support process synchronisation and memory management Data location and access. To share data in a DCSM system, a program must be able to find and retrieve the data it needs. If data does not move around in the system (it resides only in a single static location) then locating is easy. All processes simply know where to obtain any piece of data they need. This is not the case with some systems, which use hashing on the data to distribute the data statistically. This has the advantage of being simple and fast, but may cause a bottleneck if data is not distributed properly (for example, all shared data ends up on a single node). 39

56 An alternative is to allow data to migrate freely throughout the system. This allows data to be redistributed dynamically to where it is being used. However, locating data then becomes more difficult. In this case, the simplest way to locate data is to have a centralised server that keeps track of all shared data. The centralised server suffers from two major drawbacks: The server serialises location queries, reducing parallelism of the system. The server may become heavily loaded and may slow down the entire system. Instead of using a centralised server, a system can broadcast requests for data. Unfortunately, broadcasting does not scale well. All nodes (not just the nodes containing the data) must process a broadcast request. The network latency of a broadcast may also require accesses to take a long time to complete. To avoid broadcasts and distribute the load more evenly, several systems use an owner based distributed scheme. This scheme is independent of data replication, but is seen mostly in systems that support both data migration and replication. Each piece of data has an associated owner - node with the primary copy of the data. The owners change as the data migrates through the system. When another node needs a copy of the data, it sends a request to the owner. If the owner has given the data to some other node, it forwards the request to the new owner. The drawback with this scheme is that a request may be forwarded many times before reaching the current owner. In some cases, this is more wasteful than broadcasting. In Ivy, all nodes involved in forwarding a request (including the requester) are given the identity of the current owner. This collapsing pointer chain helps reduce the forwarding overhead and delay. When it replaces data, a DCSM system must keep track of the replicated copies. Dash [Lenoski D. et al., 1990] uses a distributed directory-based scheme, implemented in hardware. The Dash directory for a given cluster (node) keeps track of the physical blocks in that cluster. Each block is represented by a directory entry that specifies whether the block is unshared remote (local copy only), shared remote or shared dirty. If the block is shared remote, the directory entry also indicates the location of replicated copies of the block. If the block is shared dirty, the directory entry indicates the location of a single dirty copy. Only the special node known as the home cluster possesses the directory block entry. A node accesses nonlocal data for reading by sending a message to the home cluster Coherence protocol. All DCSM systems provide some form of memory coherence. If the shared data is not replicated, then enforcing memory coherence is trivial. The underlying network 40

57 automatically serialises requests in the order they occur. A node handling shared data can merely perform each request as it is received. This method will ensure strict memory consistency - the strongest form of coherence. Unfortunately, serialising data access creates a bottleneck and makes parallelism - a major advantage of DCSM systems - impossible. To increase parallelism, virtually all DCSM systems replicate data. Thus, for example multiple read can be performed in parallel. However, replication complicates the coherence protocol. Two types of protocol - write-invalidate and write-update - handle replication. In a write-invalidate protocol there can be many copies of a read-only piece of data, but only one copy of a writable piece of data. The protocol is called writeinvalidate because, (before a write can proceed) it invalidates all copies of a piece of data except one. In a write-update scheme, however, write updates all copies of a piece of data. Most DCSM systems have a write-invalidate coherence protocol. All the protocols for these systems are similar. Each piece of data has a status tag that indicates whether the data is valid, whether it is shared, and whether it is read-only or writable. For a read, if the data is valid, it is returned immediately. If the data is not valid, a read request is sent to the location of a valid copy, and a copy of the data is returned. If the data was writable on another node, this read request will cause it to become read-only. The copy remains valid until an invalidate request is received. For a write request, if the data is valid and writable, the request is returned immediately. If the data is not writable, the directory controller sends out an invalidate request, along with a request for a copy of the data, if the local copy is not valid. When the invalidate completes, the data is valid locally and writable and the original write request may complete. [Li K., Hudak P., 1989] showed that the write-invalidate protocol performs well for a variety of applications. In fact, they showed speed-up for the case of a linear equation solver and a three-dimensional partial differential equation solver, resulting from the increased overall physical memory and cache sizes. In the same time [Li K., Hudak P., 1989] rejected the use of a write-update protocol with the reasoning that network latency would make it inefficient. Further research indicated that in the appropriate hardware environment write-update protocols can be implemented efficiently. For example, Plus [Bisiani R., Forin A., 1988] is a hardware implementation of DCSM that uses a write-update protocol. Each write request starts all updates with the block s master node, then proceeds down the copy-list chain. The write operation is completed when the last node in the chain sends an acknowledgment message to the originator of the write request. 41

58 Munin [Bennett J., Carter J., Zwenepoel W., 1990] uses type-specific memory coherence, coherence protocols tailored for different types of data. For example, Munin uses a write-update protocol to keep coherent data that is read much more frequently than it is written (read-mostly data). Because an invalidation message is about the same size as an update message, an update costs no more than invalidate. However, the overhead of making multiple read-only copies of the data item after each invalidate is avoided. An eager paging strategy supports the Munin producer-consumer memory type. Data, once written by the producer process, is transferred to the consumer process, where it remains available until the consumer process is ready to use it. This reduces overhead, since the consumer does not request data already available in the buffer Replacement Strategy. In systems that allow data to migrate around the distributed environment, two problems arise when the available space for caching shared data fills up: Which data should be replaced to free space? Where should the replaced data go? In choosing the data item to be replaced, a DCSM system works almost like the caching system of a shared memory multiprocessor. However, unlike most caching systems, which use a simple least recently used or random replacement strategy, most DCSM systems differentiate the status of data items and prioritise them. For example, priority is given to shared items over exclusively owned items because the latter has to be transferred over the network. Simply deleting a read-only shared copy of a data item is possible because no data is lost. Once a piece of data is to be replaced, the system must make sure it is not lost. In the caching system of a multiprocessor, the item would simply be placed in main memory. Some DCSM systems use an equivalent scheme. The system transfers the data item to a home node that has a statically allocated place (perhaps on disk) to store a copy of an item when it is not needed elsewhere in the system. This method is simple to implement, but it wastes a lot of memory. An improvement is for the node that wants to delete the item to simply page it out onto disk. Although this does not waste any memory space, it is time consuming. Because it may be faster to transfer something over the network than to transfer it to disk, a better solution is to keep track of free memory in the system and to simply page the item out to a node with space available to it Thrashing in DCSM systems. DCSM systems are particularly prone to thrashing. For example, if two nodes compete for write access to a single data item, it may be transferred back and forth at such a high 42

59 rate that no real work can get done. Two systems Munin and Mirage attack this problem. Munin [Bennett J., Carter J., Zwenepoel W., 1990] allows programmers to associate types with shared data: write-once, write-many, producer-consumer, private, migratory, result, read-mostly, synchronisation and general read-write. Shared data of different types get different coherence protocols. To avoid thrashing with two competing writers, a programmer could specify the type as write-many and the system would use a delayed write policy ( Munin does not guarantee strict consistency in this case). Tailoring the coherence algorithm to the shared data usage patterns can greatly reduce thrashing. However, Munin requires programmers to specify the type of shared data. Programmers are notoriously bad at predicting the behaviour of their programs, so this method may not be any better than choosing particular protocol. In addition, because the type remains static once specified, Munin cannot dynamically adjust to an application s changing behaviour. Mirage [Fleish B., Popek G., 1989] uses another method to reduce thrashing. It specifically examines the case when many nodes compete for access to the same page. To stop the negative effect, Mirage adds a dynamically tunable parameter to the coherence protocol. This parameter determines the minimum amount of time a page will be available at a node. For example, if a node performed a write to a shared page, the page would be writable on that node for the period of time determined by the parameter. This solves the problem of having a page stolen away after only a single request on a node can be satisfied. Because the time parameter is tuned dynamically on the basis of access patterns, a process can complete a write request (or read request) before losing access to the page. The parameter emulates the time slicing in a multitasking operating system, except in Mirage it is dynamically adjusted to meet an application s specific needs Distributed Computers Shared Memory - Basic Algorithms. This paragraph describes four basic distributed shared memory algorithms. The algorithms described can be categorised by whether they migrate and/or replicate data as depicted in Figure 3-3. Two of the algorithms migrate data to the site where it is accessed Non-migrating Migrating Non-replicated Central Migration Replicated Full-replication Read-replication Figure 3-3: Four distributed shared memory algorithms. in an attempt to exploit locality in data accesses and decrease the number of remote 43

60 accesses, thus avoiding communication overhead. The other two algorithms replicate data so that multiple read accesses can take place and at the same time use local accesses. Implementations of distributed shared memory based on replication should make this replication transparent to the applications. In other words, processes should not be able to observe (by reading and writing shared data) that all data accesses are not directed to the same copy of data. Expressed in a more formal way [Lamport L., 1979], the result of applications using shared data should be the same as if the memory operations of all hosts were executing in some sequential order, and the operations of each individual host appear in sequence in the order specified by its program, in which case the shared memory is said to be consistent. Shared memory in a shared memory multiprocessor is expected to behave this way. This definition of consistency should not be confused with a stricter definition requiring read accesses to return the value of the most recent write to the same location, which is naturally applicable to concurrent processes running on a uniprocessor but not necessarily to those on shared memory multiprocessors with CPU caches and write-back buffers [Archibald J., Baer J.L., 1986] Central Server algorithm. The simplest strategy for implementing distributed shared memory uses a central server that is responsible for servicing all accesses to shared data and maintains the only copy of the shared data. Both read and write operations involve the sending of a request message to the data server by the process executing the operation, as shown on Figure Central Server Client Send Data Request... Receive Response Central Server Receive Request Perform Data Access Send Response Clients Figure 3-4: The Central Server Algorithm The data server executes the request and responds either with the data item in the case of a read operation or with acknowledgement in the case of a write operation. 44

61 A simple request-response protocol can be used in implementations of this algorithm. For reliability, a request is re-transmitted after each time-out period with no response. This is sufficient in itself for read requests [Stumm M., Zhou S. 1990]. For write requests, the server must keep a sequence number for each client so that it can detect duplicate transmissions and acknowledge them appropriately. A failure condition is raised after several time-out periods with no-response. Hence, this algorithm requires two messages for each data access: one from the process requesting the access to the data server. second from the server containing its response. Moreover, each data access requires four communication events: two at the requesting process (one to send the request and the other to receive the server s response), and two at the server s side. On one hand there is a potential problem with the central server that it may become a bottleneck, since it has to service requests from all clients. In an attempt to distribute the server load, some of the systems organise the shared data into a logical structure located on several servers in the network. On the other hand this is the best solution for a whole range of applications because of its simple realisation, easy tracking of data packets and minimal load of the network. The latter is especially valid when the system integrates powerful computers in a busy network. One suitable case for applying the central server algorithm is for the case when the data transactions in its majority follow the scheme: one application writes the shared data and many applications read the shared data. In that case replication of the data over several servers will be just a repetition of the read requests by the reading applications and the time spent by the overhead programmes (providing data replication) will be simply lost time Migration algorithm. In the migration algorithm, shown on Figure 3-5, the data is always migrated to the site where it is accessed. This is a single reader/single writer (SRSW) protocol, since only the threads executing on one local host can read or write a given data item at any one time. Instead of migrating individual data items, data is typically migrated between servers in a fixed size unit called a block to facilitate the management of the data. The advantage of this algorithm is that no communication costs are incurred when a process accesses data currently held locally. If an application exhibits high locality of reference, the cost of data migration is distributed over multiple accesses. However, with this algorithm, it is also possible for 45

62 pages to thrash between hosts, resulting in few memory accesses between migrations and therefore poor performance. Often, the application writer will be able to control thrashing by judiciously assigning data to blocks. Migration Request Data Block Client If block not local Determine Location Send Request Receive Response Access Data Figure 3-5The Migration Algorithm Remote Host Receive Request Send Block A second advantage of the migration algorithm is that it can be integrated with the virtual memory system of the host operating system if the size of the block is chosen to be equal to the size of a virtual memory page (or a multiple thereof). If a shared memory page is held locally, it can be mapped into the application s virtual address space and accessed using the normal machine instructions for accessing memory. An access to a data item located in a data block, not held locally, triggers a page fault so that the fault handler can communicate with the remote hosts to obtain the data block before mapping it into the application address space. When a data block is migrated away, it is removed from any local address space it has been mapped into. The location of a remote data block can be found, for example, by multicasting a migration request message to all remote hosts. There are more efficient methods described by [Li K., 1986]. One of them is to statically assign each data block to a managing server that always knows the location of the data block. To distribute the load, the management of all data blocks is partitioned across all hosts. A client queries the managing server of a data block, both to determine the current location of the data block and to inform the manager that it will migrate the block Read-replication algorithm. One disadvantage of the algorithms described so far is that only the threads on one host can access data contained in the same block at any given time. Replication can reduce the average cost of read operations, since it allows read operations to be simultaneously executed locally (with no communication overhead) at multiple hosts. However, some of the write operations may become more expensive, since the replicas may have to be invalidated or updated to maintain consistency. Nevertheless, if the ratio of reads over 46

63 writes is large, the extra expense for the write operations is more than acceptable bearing in mind the low average cost of read operations. Replication can be naturally added to the migration algorithm by allowing either one site to hold a read/write copy of a particular block or multiple sites to hold read-only copies of that block. This type of replication is referred to as multiple readers/single writer (MRSW) replication. For a read operation on a data item in a block that is currently not local, it is necessary to communicate with remote sites to acquire a read-only copy of that block and to change to read-only the access rights to any writable copy, if necessary, before the read operation can complete. For a write operation to data in a block that is either not local or for which the local host has no write permission, all copies of the same block held at other sites must be invalidated before the write can proceed. This algorithm is illustrated in Figure 3-6: Block Request Data Block Invalidate Block Client If block not local Determine Location Send Request Receive Block Multicast Invalidate Access Data Remote Host Receive Request Send Block Receive Invalidate Invalidate Block Figure 3-6. The Write Operation in Read-Replication Algorithm. This strategy resembles the write invalidate algorithm for cache consistency implemented by hardware in some multiprocessors [Archibald J., Baer J.L., 1986]. The read-replication algorithm is consistent because a read access always returns the value of the most recent write to the same location. This type of replication has been investigated extensively [Li K., 1986], [Li K., Hudak P., 1989]. In Li s implementation, each block has a server designated as its owner that is responsible for maintaining a list of the servers having a read-only copy of that block. This is called the block s copy set. A read (or write) access to a block for which a server does not have the appropriate access rights causes a read (or write) fault. The fault handler transmits a request to the server that has ownership of the appropriate block. For a read fault, the owning server 47

64 replies with a copy of the block, adds the requesting server to the copy set of the requested block and, if necessary, changes the access rights of its local copy to read-only. When a write fault occurs, ownership for the block is transferred from the previous owner to the server where the write fault occurred. After receiving the response, the write-fault handler requests all servers in the copy set to invalidate their local copy, after which the access rights to that block are set to write access at the site of the new owner and the copy set is cleared Full-replication algorithm. Full replication allows data blocks to be replicated even whilst being written to. The full-replication algorithm therefore adheres to a multiple readers/multiple writers (MRMW) protocol. Keeping the data copies consistent is straightforward for nonreplicated algorithms, since accesses to the data are sequenced according to the order in which they occur at the site where the data is held. In the case of fully replicated data, accesses to the data must either be properly sequenced or controlled to ensure consistency. One possible way to keep the replicated data consistent is to globally sequence the write operations, while only sequencing the read operations, relative to the writes, that occur local to the site where the reads are executed. For example, the write-update algorithm for cache consistency implemented by hardware in some multiprocessors maintains consistency in this fashion. According to this algorithm, its reads occur locally from the cache while writes are broadcast over the bus that sequences them automatically. A simple strategy based on sequencing uses a single global gap-free sequencer, illustrated on Figure 3-7, which is a process executing on a host participating in Write Sequencer Clients Update Client If write Send Data Receive Acknowled gement Update Local Memory Sequencer Receive Data Add Sequencer Number Multicast Hosts Receive Data Update Local Memory Figure 3-7. The Full-Replication Algorithm distributed shared memory. When a process attempts a write to shared memory, the 48

65 intended modification is sent to the sequencer. The sequencer assigns the next sequence number to the modification and multicasts the modification with this sequence number to all sites. Each site processes broadcast write operations in sequence number order. When modification arrives at a site, the sequence number is verified as the next expected one. If a gap in the sequence numbers is detected, either a modification was missed or a modification was received out of order, in which case a re-transmission of the modification message is requested. (This requires that somewhere a log of recent write modifications must be maintained.) In effect, this strategy implements a negative acknowledgement protocol. In the common case within the assumed environment, packets arrive at all sites in their proper order. Therefore, a write requires two packet events at the writing process, two packet events at the sequencer, and a packet event at each of the other replica sites. Many variants to the above algorithm exist. For example, [Bisiani R., Forin A., 1988] described an algorithm for full replication that uses the same principle as the sequencing algorithm to ensure individual data structures remain consistent. However, rather than using a single server to sequence all writes, writes to any particular data structure are sequenced by the server that manages the master copy of that data structure. Although each data structure is maintained in a consistent manner, there is no assurance with this algorithm that updates to multiple data structures are made consistently DIME Shared Memory System - formulation of the problem. The prospect of the enhancement of the performance of current traffic control systems, through the provision of a supervisory level of control using in-vehicle and road-side dynamic route guidance, has created the need for a flexible computing environment where all modules of the system can be effortlessly integrated. The most promising approach to satisfying this requirement is the use of distributed computing resources [Ashok K., Ben-Akiva M., 1993]. The distributed computers shared memory system (DCSM) described in this chapter and called DIME (DIME stands for Distributed Memory Environment), provides a communication harness for the execution of software modules of urban traffic control systems. A successful design of the DCSM system requires detailed knowledge of the data transactions in the system, therefore careful consideration of data flows in a traffic control system is given below. Following the functional structure of the urban traffic control system described in Chapter 2 and shown on Figure 2-5, two types of data flows can be recognised: 49

66 Dynamic data. This is the data collected by the real-time traffic control system (local nodes represented on Figure 2-2). It contains all information about traffic counts and local controls as they occur in the city traffic network and every second there is a new piece of information arriving. This data item has to be available for reading by several application programs: The State Estimation Module, Turning Movements Estimation Module and Predictive Simulation Module. The main characteristic of this type of data is its high volume - in excess of 65 MBytes per day. It is clear that all data can not be fitted into a shared memory structure permanently. The solution is to maintain a copy of the most recent data only. Therefore a shared memory structure, capable of storing and providing this information in a consistent way to the modules that request it, is needed. Expressed formally, this is a one writer/many readers shared memory situation. The high frequency of the write update operation has to be taken into account as well as the fact that one write operation on the data is usually followed by one read operation for each concurrently running module. One interesting characteristic of the system is that from any particular program module point of view each write operation does not have to be followed by a compulsory read operation in order for the module to obtain all relevant data, i.e. the data structures have to provide correct data (preserving the information for a certain period of time) even after several writing operations have taken place and without having read operations in between them. This characteristic allows more lengthy procedures (for example, predictive simulation for min. ahead could well take several minutes) to take place in the system without loss of vital traffic count data information. Static Data. The second type of data is updated on a much longer period of time and its purpose (in general) is to make the output results from the traffic simulation module (or from the turning movements estimation module, or from the state estimation module etc.) available for reading by the other functional modules in the system. This type of data is typical for the shared memory structures discussed in paragraphs As it is in the case of the dynamic data the situation with the shared access to a data item is a one writer/many readers. With this type of shared information every new write operation will destroy the old copy of data considering it obsolete. Another important requirement for the shared memory system is that all communication links should be transparent to the users. All software modules are designed to perform their primary task (simulation, estimation etc.) and have to refer to the shared memory system to obtain the new information available in the system. Therefore the DCSM should keep track of all inter-module data exchanges. 50

67 The portability of the system is an important factor in the system design. The communication component in the traffic control system modules has to be designed in a manner that would allow it to run across different platforms DIME Shared Memory System - design of the system Data structures design. The shared memory may be provided as an unstructured linear array of bytes or it may be structured and organized in terms of objects like lists, circular buffers, records etc. [Nitzberg B., Lo V., 1991] (see paragraph 3.3.1). The range of data structures available in the shared memory system reflects the data types required by a specific application. The data representing the dynamic data type is in fact a constant flow of uniform messages, coming from the traffic data counts. These messages have a specific (operational control system dependant) format. Therefore, to accommodate the dynamic type of data, the system needs a formation capable of accepting a number of uniform structures at a time. A list of structures is the most suitable choice for this purpose. Furthermore, this list of structures has to contain the most recent information i.e. the newest information overwrites the oldest information in the system. The solution to this requirement is a circular buffer where each element of the buffer is a user defined message structure and its size depends on the size of the urban traffic network, i.e. the system has to be flexible enough to allow the definition of the buffer s size. The (relatively) static data in the traffic control system usually reflects the value of some of the internal variables in the software modules. An example of such data is the rate of generation of vehicles at the beginning of the street. Its volume is one number only (usually 4 bytes) and the frequency of updating is once per cycle ( sec.). The static data format and volume, however, is module dependant since each simulation model has its own internal representation of the traffic and it usually differs from all other simulation models representations. In the absence of a specific internal structure of the data, therefore, the most suitable choice for the static data type is an array of bytes with a user defined size Choice of consistency model and algorithm. The situation with the shared data access in a normal operation of the traffic control system is one writer/many readers and each write operation of the shared data is followed by one read operation for every module in the system. This feature makes the replication and migration of the data unnecessary. This is because every time the write operation is executed, it would invalidate the data blocks on the site of the reading application and each read operation (because it follows the write operation in the time 51

68 scale) would involve transferring data blocks over the network (which is the same as requesting them explicitly by the user application). Therefore the simplest and fastest solution from a programming point of view is a shared memory system with the central server as a centralised memory manager. The consistency model refers to how shared memory system updates become visible to other processes (see paragraph 3.3.2). The most stringent consistency in a distributed environment is a sequential consistency. Choosing the case of a centralised memory manager for shared memory algorithm access allows also easy solution of the consistency problem of the system. Each read/write operation is sequenced already by the network (Ethernet) and the centralised memory manager simply performs the operations according to the order of their arrival i.e. conforms to the sequential consistency definition. This solution is in line with the conclusion that simple memory consistency models have - with speculative execution of microprocessors instructions - equivalent performance to the other consistency models performance [Hill M. D., 1998] Scalability. An original approach in the system design is the embedding of a new functionality in the shared memory system. In order to reflect the dynamic and static nature of the data in the system there are two different structure types: circular buffer data structure and array data structure. The system is designed to work with two functionally different read operations and two functionally different write operations (one read and one write operation for each type of data). The access to the static data is in the same manner as it is described in paragraphs Each write/read operation writes/reads the data in/ from the same place where the previous write/read operation for the same data had written/read. This is in sharp contrast with the meaning of read/write operation for the dynamic type of data in the system. For example, the writer program does not specify where in the circular buffer the new data should go. Instead the meaning of the command is: find the oldest data in the circular buffer and replace them with the new information. The meaning of the read command is: find the next portion of data the requester has not read yet and send it to the reader. Consequently, the shared memory system keeps track of every reader s readings in order to be able to provide it with consistent information. The main benefit is for the reader program. The application program does not have to check which portion of data should be read next (if there has been a lengthy procedure like simulation or estimation, several write operations might have been performed by the shared memory system) and will directly receive the relevant portion of data. This approach reduces the bottleneck effect inherent for the central server algorithm and when implemented on a comparatively powerful machine does not impose more 52

69 restrictions than the underlaying network imposes on data communication itself (local area networks based on the Ethernet, in effect, represent a bottleneck for message passing procedures) Heterogeneity. In a traffic control system there are a variety of modules performing a range of different tasks. Out of cost considerations, some may run on relatively inexpensive machines (PCs) and, out of considerations for computational power, some may run on powerful workstations. The DIME system has been designed to work in a heterogeneous environment. However, the central server algorithms do not facilitate data transactions between different machine architectures and, if the application program uses DIME s shared memory structures to store numerical data types, it should perform the conversion from one architectures format into another if it is needed DIME configuration. The DIME design considerations presented in paragraph 3.7, led to the adoption of a sequential consistency model and a centralized architecture of the memory manager. This implies that DIME does not require any virtual memory hardware to detect accesses to pages of shared memory, and consequently it could be ported to both Unix and DOS environments. The DIME system is implemented entirely as a user-level library on top of UNIX and DOS. Unix kernel modifications were unnecessary because all required communication and memory management functions are standard features of current Unix implementations. The DOS implementation of DIME makes use of socket communication libraries from 3COM, [3COM Reference manual, 1990], which provide full compatibility with the Unix implementation. Programs written in C or C++ are compiled and linked with the DIME library using any standard compiler for that language. As a result, the system is relatively portable. DIME s configuration is represented on Figure 3-8. Each user application code has an additional component linked to it, which provides the communication interface via DIME API with the shared memory system. The requests for reading/writing data from/to the shared memory (creating or removing areas) are transferred by the DIME library over the network to the memory manager task, where they are being processed and replies are sent back. There are two components of DIME: a) the shared memory manager (SMM) task which owns the shared area and b) the communication DIME libraries which are linked to user applications and the memory manager in order to interface to the network. The shared memory manager (SMM) component of DIME operates on a closed-loop basis, continually checking for the requests to access or to maintain the shared memory 53

70 data structures. These requests are typically raised by the application programs executing appropriate API routines, but a provision has also been made for a keyboard entry of requests to the memory manager. Local Data Storage Read/ Write DIME Library Memory Manager Shared Memory Manager interface Socket communication DIME Network DIME Library Socket communication interface DIME API... DIME Library Socket communication interface DIME API User Application code 1 User Application code N Figure 3-8: DIME Configuration. The DIME s API provides facilities for the creation and removal of shared memory structures and the read/write access to them. The synchronization of accesses to shared memory is implicit in the operation of the memory manager task thus it does not require the provision of separate library functions Shared Memory Data Structures in DIME. In supporting the traffic simulation, monitoring and control applications, DIME software implements two types of memory structures, an array of records and a circular buffer. These two structures are intended for use with static and dynamic data respectively. Shared Memory Structure Array.This type of structure represents the static type of data in the system and the most common description for its internal representation is an array of records. It is shown on Figure 3-9. Typically, the 54

71 array of records will store traffic network description data, that is shared between several concurrent applications and is read and updated infrequently. Because of this, it is possible to afford a simple model for accessing the shared arrays whereby always a complete array is read or written-to. Structure 1 Structure 2 Structure 3 Structure N Client Writer Client Reader Figure 3-9: Shared Memory Structure Array. For the time-varying data, such as the traffic flow measurements or the results produced by the real-time simulation and control software modules, the access to the supporting memory structures is requested by applications on a second-bysecond basis, so the efficiency of access to the shared memory is of utmost priority. The circular buffer data structure provides an efficient access to an individual record and it readily keeps track of the time sequence of messages. The buffer maintains a global insertion pointer and an individual extraction pointer for each of the readers, thus enabling applications to recover from sporadic communication delays that are inevitable in a distributed processing environment. The internal structure of the shared memory structure Circular Buffer is illustrated on Figure The design of the shared memory structures allows the application programs to specify their size. Usually the size of the circular buffer is determined by the time horizon for traffic simulation and state estimation and should be big enough to hold the accumulated data needed for the prediction time period (plus some reserve allowance). The size of the shared memory structure Array depends entirely on the size of the data to be exchanged 55

72 between the applications. The number of shared areas is limited only by the memory limitations of the machine where the centralised memory manager is running. Data Global Insertion Pointer Task 1 Extraction Pointer Task 2 Extraction Pointer Task 3 Extraction Pointer Figure 3-10: Shared Memory Structure Circular Buffer DIME s API. A simple C language interface provides easy use of the DIME s access procedures. Its description is as follows: /* initialize shared memory API interface */ Boolean init_dsm (int argc, char **argv, int MaxAreas, char *host, int port); The application program supplies C standard command line parameters argc (command line argument count) and argv (command line arguments represented as array of strings) to API. The start-up options include: a) specifying the host name (or address) of the computer where the Memory Manager Task is running; b) specifying a blocking or non-blocking mode for socket operations. The name of the Memory Manager Task s host could be supplied by using the fourth parameter of the function host, in which case there is no need to specify it in the start-up parameters. The parameter MaxAreas determines the maximum number of shared areas for this specific application and port is a parameter 56

73 required for establishing TCP/IP socket communication interface between the application tasks and the memory manager task (usually predetermined by the DIME system). /* create shared memory array */ Boolean request_create_array (String name, int recordsize, long records, char *taskname, int permission); The application program specifies parameters for the name of the array, the size of one record, the number of records in the array, the name of the requesting task and the type of access required. The request by the application program to create a shared array that already exists has an effect of checking the memory manager s specification for this array against the applications specification. If the two agree, the memory manager authorizes the application to perform subsequent read/write operations. /* remove shared memory array */ Boolean request_remove_array (String name, char *taskname); The application program specifies parameters for the name of the array and the name of the requesting task. The request results in the name of the application being removed from the memory manager s list of tasks that are permitted to access the array. If the requesting task is the last on the list, the shared array is removed. /* read from shared memory array */ Boolean request_read_array (String name, Address tolocaladdress); The application program specifies parameters for the name of the array and the address to which data go. /* write into shared memory array */ Boolean request_write_array (String name, Address fromlocaladdress); The application program specifies parameters for the name of the array and the address from which data come. /* create a circular buffer */ Boolean request_create_buffer (String name, int recordsize, long records, char *taskname, int permission); The application program specifies parameters for the name of the buffer, the size of one record in the buffer, the maximum number of records in the buffer, the name of the requesting task and the type of access required. 57

74 The request by the application program, to create a shared buffer that already exists, has an effect of checking the memory manager s specification for this buffer against the applications specification. If the two agree, the memory manager authorizes the application to perform subsequent read/write operations. /* remove a circular buffer */ Boolean request_remove_buffer (String name, char *taskname); The application program specifies parameters for the name of the buffer and the name of the requesting task. The request results in the name of the application being removed from the memory manager s list of tasks that are permitted to access the buffer. If the requesting task is the last on the list, the shared buffer is removed. /* read from buffer */ Boolean request_read_buffer (String name, Address tolocaladdress, long records, int* recordsread, void workproc()); The application program specifies parameters for the buffer s name, the address where the data go to and the maximum number of records to be read from the buffer. The actual number of records read by the system is returned in recordsread. The application program can specify a working procedure to be invoked regularly while the network message exchange continues. /* write into buffer */ Boolean request_write_buffer (String name, Address fromlocaladdress, long records, void workproc()); The application program specifies parameters for the buffer s name, the address where the data come from and the number of records to be written in the buffer. The application program can specify a working procedure to be invoked regularly while the network message exchange continues. The API functions return Boolean value True for a successfully completed request and False otherwise. The communication between the API procedures that are linked to the application programs and the memory manager has been implemented using standard TCP/IP connected sockets. The sockets operate in either blocking or non-blocking mode depending on the requirements of the application. An appropriate option is selected at the initialization stage of the DIME software ( b option in command line parameters). The underlying communication between the distributed computing nodes is fully transparent to the application programs which see only a virtual shared memory as created through the API requests. 58

75 3.11. Traffic Simulation and Monitoring Environment using DIME. An example of a typical urban traffic simulation, monitoring and control environment is given in Figure Workstation 1 Application 1 SCOOT Client Workstation 2 Application 2 Memory Manager Client Dime Library Dime Library DIME Network Dime Library Dime Library Dime Library Workstation 3 Macrosimulation Client Application 3 Workstation 3 Turning Movements Estimation Client Application 4... Workstation N Other Clients (e.g. State Estimation) Application N Figure 3-11: Using DIME in urban traffic simulation and control. The initiative for supplying the real-time messages and control data belongs to the SCOOT-client application. All information is stored in a shared memory structure buffer. These data can be retrieved by any client that has registered with DIME its intentions to read from the buffer. The simulation clients may also generate time critical data if, for example, they are interacting with another copy of SCOOT software for the purpose of generating predictions of traffic evolution. In this case two buffers may be created: one buffer, storing the simulated measurements, would be specified with a write permission to the simulation clients and a read permission to the SCOOT client, and the other buffer, storing the control responses to simulated measurements, would be specified with a write permission to the SCOOT client and a read permission to simulation clients. 59

76 The exchange of non time-critical information between the clients is performed via a shared memory structure array. In this case setting, of read/write permissions facilitates the control over the information flow. Examples of DIME client programs are shown in Appendix A, Figure 1 - Appendix A, Figure 2. Example of the Memory Manager control screen is shown in Appendix A, Figure Evaluation results. DIME software has been evaluated in the context of urban traffic monitoring and control applications. The software was tested using both LAN and WAN distributed system configurations. The WAN configuration consisted of 4 nodes: one HP/Unix workstation at the Helsinki University of Technology and one PC DOS computer and two SUN UNIX workstations at the Nottingham Trent University. The software suite included two application tasks: an emulator of the traffic monitoring and control software (SCOOT) (this program essentially replayed historical SCOOT measurements and control data) and a macrosimulation module. The data used in the tests were collected by the real-time control system SCOOT for the Mansfield traffic network (a town north of Nottingham). The shared memory manager task was placed on each of the four available computer nodes in turn and the application programs were monitored to determine whether their requests for access to the shared data are being satisfied within the timeframe defined by the monitoring frequency. In all tests the data storage/retrieval rate by the application programs was better than 0.5 kb per second (requested performance by the SCOOT system for the Mansfield region) including the case when both application programs accessed the memory manager task using WAN. Additional experiments have been carried out to evaluate the maximum throughput of information for the DIME system. For these tests 4 workstations and a PC located at NTU, Nottingham and one workstation located at HUT, Helsinki have been used. The worst case scenario has been constructed by placing the memory manager task on a remote computer, situated at HUT and the application tasks on nodes at NTU. Consequently, every access to shared memory required a network transmission. The writer task wrote data into the shared memory with a progressively increasing rate and the reader task attempted to keep-up with the writer retrieving all the data. The experiment was repeated with a different number of readers : from 1 reader in the simplest case up to 4 readers. The experiments showed that in the WAN working environment the maximum information retrieval rate was in the range kb/sec. This performance did not depend substantially on the number of readers but it did depend on the network load. The maximum retrieval rate of 6.5 kb/sec was measured with 1 to 4 readers on a lightly loaded network and similarly the maximum rate of 2.8 kb/sec was measured with 1 to 4 readers with a busy network. 60

77 Another group of tests was carried out in a LAN working environment. Using the same suite of application tasks, the performance of DIME has been found to be in the range kb/sec. Over 99% of the time was spent on negotiating message delivery by TCP/ IP and the remaining 1% on the actual shared memory accesses and housekeeping. Figure 3-12 and Figure 3-13 depict the respective performance envelopes for the LAN and WAN tests of the system. Data Received kb/sec best case worst case Data sent kb/sec. Figure 3-12: DIME LAN performance for 2-5 user applications. Data Received KB/sec best case worst case Data sent KB/sec Figure 3-13: DIME WAN performance for 2-5 user applications. Taking into account that any performance of the system will fall between the best and worst case scenarios, the tests confirm that the WAN configuration offers an adequate distributed traffic systems software development environment. However, because of the wide fluctuations of the data traffic over WANs, for the real-time operation of the system the DIME software should execute using LAN configuration, as originally intended. It must be pointed out however, that this is not a limitation on the part of DIME and the use of more efficient WAN networks may well alter the conclusions. Several tests have been conducted to estimate the amount of time needed for a single read/write transaction in the DIME environment as a function of the volume of the transferred data. In order to cover different configurations, the central memory manager was placed first on a UNIX system and the appropriate client programs (emulating real applications) ran on Windows and UNIX platforms. Subsequently, the memory manager was placed on a Windows platform and the client programs ran on Windows and UNIX platforms. The client programs tested the communication interface by sending messages 61

78 with variable length and estimated three different parameters: the average time, the minimum time and the maximum time for a single transaction. The same three parameters were also monitored for the central memory manager. The results of the tests are shown in Table Table 3-4:. Message length (bytes) Minimum time for a single read/ write transaction (ms) Average time for a single read/ write transaction (ms) Maximum time for a single read/ write transaction (ms) 50 less than less than less than less than Table 3-1: Times for a single read/write transaction on Windows platform for the client program. 62

79 Message length (bytes) Minimum time for a single read/ write transaction (ms) Average time for a single read/ write transaction (ms) Maximum time for a single read/ write transaction (ms) Table 3-2: Times for a single read/write transaction on UNIX platform for the client program.. 63

80 . Message length (bytes) Minimum time for a single read/ write transaction (ms) Average time for a single read/ write transaction (ms) Maximum time for a single read/ write transaction (ms) Table 3-3: Times for a single read/write transaction on Windows platform for the client program over a serial link with speed 9600 b/s (mobile telephone link). 64

81 Message length (bytes) The timing for the central manager program running on a Windows platform has shown that the average time for one transaction in all cases was below 10 milliseconds, but it was not possible to measure it accurately due to the inherent inaccuracies of the system clock for the platform. Minimum time for a single read/ write transaction (ms) The tables above are shown in graphical form in Figure Figure The average value of bytes (in tens of kilobytes) is shown on the x-axis of the graph with the amount of milliseconds shown on the y-axis. Average time for a single read/ write transaction (ms) Maximum time for a single read/ write transaction (ms) Table 3-4: Times for a single read/write transaction on UNIX platform for the central memory manager program. 65

82 [ms] 1400 Legend: minimum time average time + + maximum time [10 4 bytes] Figure 3-14Times for a single read/write transaction on Windows 4 platform for the client program [ms] 1200 Legend: minimum time average time + + maximum time [10 4 bytes] Figure 3-15Times for a single read/write transaction on UNIX platform 4 for the client program 66

83 [ms] 8 Legend: minimum time average time + + maximum time [10 4 bytes] Figure 3-16Times for a single read/write transaction on UNIX platform for the memory manager program Conclusions of using DIME as shared memory environment for distributed simulation, monitoring and control of urban traffic. A distributed computers shared memory system has been successfully designed, implemented and tested in a multi-client distributed environment. The data used in testing the system were provided by the real-time traffic control system SCOOT for the Mansfield region traffic network. Subsequently the DIME system has been installed on a computer situated in the Nottingham traffic control centre and at present provides a platform for the other modules in the supervisory layer to connect to the operational control system and obtain traffic data on-line. The analysis of the results from the experiments showed that: (i) The client program on a Windows platform has the optimal level of performance at around 1 kb/40-70 ms data exchange rate. The amount of data, currently available on-line for the Mansfield region, is delivered at a rate of 800 bytes/second and this is well below the data exchange rate provided by the DIME system, which is around 35 kb/sec for a single client and in the range of kb/sec for 2-5 clients. (i) The client program on the UNIX platform has the optimal level of performance at around 1 kb/170 ms, which is above the required 800 bytes/sec for the Mansfield region traffic network. (i) The memory manager programs on both UNIX and Windows platforms work extremely fast. The results show that the exchange rate is well above the speeds of 67

84 the underlying network. This is due to the buffering of data at the socket level of communication. Nevertheless, these results show that the memory manager program will process the read/write operations at a speed much higher than the speed of their deliveries across the network. (i) The speed of the communication over a telephone line (mobile telephone line, speed 9600 B/sec) has been found to be sufficient to deliver all necessary data for the Mansfield region on a 4 second basis. (i) The high speed of data processing by the memory manager program shows that the number of the clients, concurrently connected to the system, will be limited only by the capability of the network to deliver the read/write requests on time across the network and the performance of the system will depend crucially on the network load. As a result of the tests it has been found, that the design of the integrative environment could have one whole new direction if in the system there are two or more memory managers running simultaneously and communicating between each other. However this will be the subject of new research and the present thesis concentrates on systems with only one memory manager present. The results show that the system could provide a generic processing harness for the execution of software modules of urban traffic control systems. The system is based on TCP/IP communication libraries and the design of the system reflects features specific to the traffic control. It is designed to support applications for both DOS and UNIX platforms. 68

85 Chapter 4 PREDICTIVE MACROSCOPIC CITY TRAFFIC FLOWS SIMULATION MODEL A traffic simulator is generally expected to satisfy the following functions [Papageorgiou M. 1991]: It must be a tool to analyse and obtain a better understanding of traffic behaviour, namely for traffic studies. It must be built in such a way to allow a flexible design of simulation experiments for testing different modelling hypotheses about traffic behaviour. It must assist the traffic engineer with the design and computation of traffic control plans. The analysis of traffic behaviour under different modelling hypotheses should serve as a basis for the process of defining control strategies leading to improved control plans. Usually, control plans computed from a heuristic or a mathematical model must be tuned before being applied [Gershwin S.B., Little J.D.C., Gartner N. 1978], [Hall M.D., Van Vliet D., Willumsen L.G. 1980]. A traffic simulator should serve as the basis of a tuning process using its simulation experiment design capabilities to reduce the tuning times substantially. Control strategies lead, in certain circumstances, to alternative control plans that must be evaluated before a decision is made. A traffic simulator should work as a decision support system for traffic engineering purposes and must allow the operator to perform an easy evaluation of the alternative control plans. Traffic control should be understood in many cases as one of the main functions of a more complex system - a traffic management system [Gartner N., Gershwin S.B., Little J.D.C. 1980], [Hall M.D., Van Vliet D., Willumsen L.G. 1980]. Traffic management systems propose traffic management schemes involving network operation conditions (e.g. tidal flows responsive systems) and traffic control strategies. Such traffic management schemes should be tested before being implemented. Traffic simulators must be an easy-to-use testing tool. Unfortunately, most of the traffic simulators built to date fail to cover these functions properly. According to the users of traffic simulation systems, who report the difficulties found in practice, problems appear, typically, in the following areas [Papageorgiou M. 1991]: 69

86 generation of the test data required for the simulator. This difficulty stems, firstly, from the need of an enormous volume of data required to test all the branches of the software simulation module. With the advance of the automation of control systems the problem with raw data collection, in general, is solved. However, this is usually enough to test only a small part of the logic of the simulator. The problem with data reflecting all simulation runs remains, since the simulation programs are capable of producing several possible development scenarios on the same data set and, as a rule, the collected data reflect only one (at best) of the development scenarios. Secondly, the simulation needs to influence the decision making of the control systems and this is difficult to achieve because of the inherent encapsulation of the existing (commercial) traffic control systems. building of the simulation model. In many cases the internal parameters of the models do not have direct expression in every day terms and their observations and validation is impossible through direct observation. An example of such a parameter is the relationship between the speed of the traffic flow in given street and the traffic density in the same street. design and performance of the simulation experiments, including the analysis and interpretation of the results provided by the simulation run. Apart from observation of the existing traffic flows there is no other way to test the validity of the models. Staging traffic flow experiments within the city is an almost impossible task due to the enormous number of vehicles and amount of human effort required 4.1. City Traffic Flows Simulation Models - Macroscopic and Microscopic Simulation. According to the smallest entity of traffic, simulated in the model, there are two different types of traffic simulation models: macroscopic simulation model microscopic simulation model The macroscopic simulation has attracted considerable interest since the 1960s. It began with the simulation of vehicles approaching and departing from isolated signalcontrolled intersections. Since the late 1960s it has been applied to freeway traffic and related features. The expression macroscopic traffic simulation is applicable to models that use traffic characteristics such as traffic densities or volume of traffic flow to simulate the behaviour of an urban traffic network. Macroscopic traffic simulation programs range from special purpose programs directed towards studying the impact of 70

87 trucks on the traffic flow to general purpose programs that include most known variables of importance. In contrast, the approach that involves simulation of individual vehicles is known as microscopic simulation. In this type of simulation the interaction car-to-car is of utmost importance followed by simulation of the human behaviour inside the car. The area of application for this type of simulation is mainly for simulation of the intersection or a corridor. Data from the SMARTEST project put the percentage of simulators used for these purposes to 70. A careful examination of the existing models indicates that there was a lack of coordination in the development of models [Papageorgiou M. 1991]. There were no standards for the models and no application guidelines, which makes it difficult for the users to determine which model to select for their needs. Because of the lack of a universally accepted traffic flow theory and varying operational characteristics, each model was developed largely through intuition. Despite that, considerable knowledge of traffic flow phenomena has been derived through simulation. This chapter reviews the most common macro- and micro-simulation models and attempts to find the balance between them by investigating a new macrosimulation approach in macro-modelling the parameters of the traffic flow within the boundaries of the city and by using microsimulation in support of the macrosimulation model. It concentrates on the design and implementation of a macroscopic traffic simulation model as an essential part of a supervisory layer of traffic control. The model provides queue length and traffic density prediction on a larger time scale than the time scale of the operational control systems. It is intended to supplement the models already in use and not to replace them. At the same time, the aim of the research is to investigate the feasibility of a simulation model, which overcomes the difficulties in building and using traffic simulation systems, mentioned above, by: using only the data generated on-line by the existing traffic control systems for its simulation scenarios. simulating the whole city traffic network through macrosimulation and working in parallel with one or more microsimulation programs in a distributed computers environment (combined macro- micro-simulation). using the same (already validated on the field) internal traffic model parameters as the existing traffic control system. validating and dynamically updating the simulation state by only using the incoming on-line data from the installed traffic control system information. 71

88 The use of the model for on-line evaluation of traffic control strategies is an objective for future research, but the design of the model reflects such a requirement City Traffic Flows Macroscopic Simulation Models. The following sections briefly present the major macroscopic simulation models SIMAUT - hydrodynamic theory based model. The SIMAUT model is based on the hydrodynamic theory of traffic flow (shock-wave propagation), as proposed by [Morin J.M., 1985]. The model continuously monitors the propagation and collisions of shock waves and displays a photograph of the different dynamic cells along the freeway in terms of average speed, flow and density at the end of each time slice. SIMAUT simulates both the freeway and the on- and off-ramps. Apart from the physical description of the traffic network, the following parameters are to be calibrated: flow-density relationship characteristics - speed in a low traffic density section, capacity, capacity cut-down when passing to a congested section, density at capacity saturation and jam-density (maximum density). time-slice length (e.g. 2 min. for on-line use, min. for off-line use). smoothing parameters (e.g. moving average, exponential smoothing). mean vehicle length, in order to convert occupancy rate into density. occupancy rate threshold between free flow and congestion (used for detecting real congestion in certain locations and, thus specifying current measured traffic volumes). speed threshold between free flow, precongestion and saturation for display features. The model has been validated on the A1 autoroute (freeway) north of Paris, France, with many disturbances such as weaving stretches, congested exits, lane-number variation and a high percentage of lorries. These enhancements have made it possible to simulate the effect of queues backing up from the freeway (effects on exits and entrances) and from exits (effects on the main freeway stream). The input data for the model are: (a) traffic volumes at on-ramps. (b) traffic volumes and occupancy rates at off-ramps and on the carriageway immediately downstream of the off-ramp. (c) traffic volumes and occupancy rates at usual bottlenecks on the carriageway. 72

89 (d) traffic volumes entering the off-ramps to the surface street network. (e) traffic volumes exiting the off-ramps to the surface street network. (f) forecast of entering demands (main line and on-ramps), forecast of operational capacities and forecast of exit percentages at off-ramps. The output data for this simulation model are: (a) volume, speed and density in each homogeneous traffic cell (between two following shock waves) along the freeway. (b) volume, speed and occupancy rate at any location specified in advance (detector simulation) on the freeway. (c) queue lengths on the freeway and the on- and off-ramps. (d) travel times on the freeway and delays at ramps. (e) total number of vehicles observed, total travel times, total travel distances, mean speed and total and mean fuel consumption, and so on for each time slice and globally at the end of the period. For on-line use, the layout of the freeway on the screen exhibits the current status of traffic flow in terms of queue lengths, travel times and delays, and this display is updated every 2 min. At the end of a period, it is possible to obtain diagrams showing the evolution of queuing and travel times during that period. SIMAUT has only been used for off-line evaluation of control strategies and it has 6 different parameters, which have to be validated before use META - freeway traffic model. META (modele d ecoulement du traffic sur autoroutes), a freeway traffic model developed by [Papageorgiou M., Blosseville J.M., Hadj-Salem H. 1990], is based on a geometrical subdivision of a given freeway axis into several sections, the length of which may be chosen up to 1000 m. Typical section lengths are 500 m. For each freeway section, META describes the time evolution of three traffic variables: traffic density, mean speed and traffic volume. The macroscopic traffic flow model consists of four equations applying to each section of a given freeway axis. The input data apart from the geometric characteristics of the freeway sections (length, number of lanes, existence of ramps) are: (a) traffic volume at the entry of the freeway axis. (b) mean speed at the entry of the freeway axis. 73

90 (c) traffic density (or occupancy rate) at the exits of the freeway axis. (d) all on-ramp volumes and off-ramp volumes. As output data, the model provides the time evolution of density, mean speed and traffic volumes for each freeway section. META can be used [Papageorgiou M. 1991]: (a) as a simulation tool, with input data provided by the user (e.g. for testing the efficiency of coordinated on-ramp metering strategies with hypothetical or historical input data). (b) for on-line description of traffic conditions between two distant (e.g km. or more) detector stations (the input data is provided by the two detector stations and on-ramp and off-ramp detectors, and full information about the internal traffic state can be estimated by META in real-time). (c) for systematic design of control strategies (state-space form). The model is not designed for on-line evaluation, therefore its suitability as a supervisory tool is limited METANET - freeway traffic model. METANET is a program for motorway network simulation and control based on a purely macroscopic modelling approach. This leads to relatively low computational effort which makes it suitable for real-time applications [Messmer A., Papageorgiou M., 1990]. The traffic network in the model is represented by a directed graph, where junctions and on-/off-ramps are represented as nodes of the graph while the stretches between these nodes are represented as directed (one-way) links. The simulation of traffic behaviour in the network links is based on a macroscopic modelling approach originally developed by [Payne H.J., 1971]. The model s aggregate variables are as follows: traffic flow density in a link (veh./km./lane). traffic mean speed in a link (km./h). traffic flow (volume) in a link (veh./h). For modelling purposes, each link is subdivided into segments with typical length of m. and the traffic model variables are calculated for every segment i by means of a set of non-linear difference equations [Papageorgiou M., Blosseville J.M., Hadj- Salem H. 1990]. The model explicitly models the traffic network links, traffic network nodes and simulates traffic incidents in the traffic network under control. The efficiency 74

91 of the control measures is estimated on the basis of a performance criteria, defined in the model [Messmer A., Papageorgiou M., 1990]. The user input specification for the model consists of: (a) Description of the physical network (topology and characteristics of the motorway network) in terms of nodes, links, interconnections, lengths, number of lanes, free speeds, critical density capacities etc. (b) traffic data (demands and, optionally, speeds, densities and composition rates) at the boundaries of the network for the period of time to be simulated. (c) If not calculated by an appropriate software module (not included in the model) splitting rates at all nodes in the network where the possibility of alternative route choice is present. This input information can be supplied to the model by an additional traffic assignment model. (d) General simulation information such as: simulation time horizon; simulation time step T; incident modelling instructions etc. The program output consists of detailed simulation results, i.e. the model aggregate variables at specified network locations, written in an output file. This file contains additional information identifying the input data set used, the output time interval the specified locations for output etc. The model relies on the META model, mentioned earlier for simulation of the traffic in one specific lane. It is designed for evaluation purposes CONTRAM - city traffic flows simulation model. CONTRAM (Continuous Traffic Assignment Model) is a traffic assignment program which models time varying traffic demands on urban and other road networks subject to capacity restraint and transient overload, and predicts the variation through time of the resulting routes, queues and delays [Taylor, N.B. 1990]. This model was originally developed at the TRRL [Leonard D.R., Tough J.B., 1979] for use in the assessment of urban traffic management schemes, but new developments by [Kimber R.M., Daly P.N., 1986] and [Taylor, N.B. 1990] have extended the scope of the model. However, it is unlikely that CONTRAM could sensibly be adapted for use on-line [Papageorgiou M. 1991], but off-line it does offer a method of predicting the effects of traffic control strategies on traffic networks, in terms of routes variation in time, traffic queues and delays, signal timings and coordination effects, fuel consumption and numbers of stops. The models and features in CONTRAM include: Speed/flow relationship. Geometric delay. 75

92 Signal coordination. Queues and delays, with extension to allow for signal coordination. Generalised cost. Fuel consumption. Packet generation and packet sizes. Optimum routes and assignment. Program structure and performance. The model loads traffic onto the network in increments called packets, each consisting of a whole number (typically in the range 1-20) of vehicles of the same type assigned at the same time between the same origin-destination. These packets are moved during the simulation process along the traffic network according to the speed/flow relationship model in the system. The evaluation of the signal plans and coordination is based on the output queue lengths and delays from the system. The simulation of the queues in the system is vertical - that is the queuing process is formally defined as occurring at the stop line [Taylor, N.B. 1990] TRANSYT macrosimulation model. The TRANSYT macrosimulation model is presented in greater detail because it is the off-line basis of the simulation model used in SCOOT - the traffic control system installed in Nottingham and Mansfield and whose data is used throughout this research programme. TRANSYT, the traffic network study tool, is a computer model that optimises the linking and timing of traffic signals in a network. Optimisation is undertaken off-line using historic data. Several traffic flow regimes may be simulated to produce a suite of predetermined traffic signal settings to be used in different traffic situations. Changes between the signal settings may be made according to the time of the day, or according to on-line measurements of the traffic conditions, such as flow or queue length, taken at a few specific locations in the network. The TRANSYT program was first released in 1969 [Robertson D. I. 1969] and, while the basic approach remained the same, there have been several substantial revisions to enhance the facilities available to make it a more flexible tool for the traffic engineer [Vincent R.A., Mitchell A.I., Robertson D.I., 1980], [Chard B.M., Lines C.J., 1987]. One of the good descriptions of the TRANSYT method is given by [McDonald M., Hounsell N.B., 1991]. 76

93 Network and Traffic Flow Data in TRANSYT. Road network and traffic flow data need to be determined for a valid representation of the model. Each modelled section between the intersections is represented as one or more links. A link is defined as a movement that can be separately treated at the subsequent stop line. The idea is illustrated in Figure 4-1. The flow from node 1 and all incoming Figure 4-1.Links and Nodes definition in TRANSYT (after [Vincent R.A., Mitchell A.I., Robertson D.I., 1980]) flows in this simple traffic network would be considered as a single link, whereas that between nodes 3 and 1 would be identified as two parallel links with left-turning traffic having an exclusive lane and phase. Between two and five links can use a shared single stop-line, with queued traffic discharging in the order of arrivals. The most common situation occurs when ahead and left turners are identified as one link, with opposed rightturners on a separately marked lane forming an additional link with distinct queues. It is assumed, for the initial arrival profiles, that traffic flow is regular - the platooning of vehicles being the result of interruption of the arrivals by the signal control. Significant priority intersections and points of traffic generation, such as car parks, should be identified as they may form part of the modelled network. Any bottlenecks that exist should also be input into the network description and are treated as intersections with 100% green time, but with limited saturation flow that defines the bottleneck capacity. Traffic flow estimates are required for movements throughout the network. These can be given either as vehicles or as passenger car unit (pcu) equivalents. Flows are assigned to a link on the basis of historic data and no reassignment is undertaken 77

94 within the TRANSYT model. However a scaling factor may be introduced to vary traffic flows by a fixed percentage to test the sensitivity of the signal settings produced by the model to changes in demand. The program can be run to simulate any period from 1 min. to several hours. Queues and delays will build progressively on oversaturated approaches over the modelled period, and the period should be selected as close as possible to the corresponding actual period in reality. The model assumes vertical queues at the stop-line, but the control of queues to reduce the blocking upstream intersections can be obtained by invoking a facility that introduces a severe penalty into the estimation function when a predetermined queue length is reached Traffic Simulation Model for ATMS/ATIS operations presented by [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]. Another model, using an approach similar to the queue formation and dissipation employed in the modern control systems, is described in more detail in the following paragraphs. The traffic simulation model presented by the authors of the model is used in two capacities. In the first place it is used to obtain an estimate of the current state of the network by extrapolating incomplete information obtained from the traffic sensors and other elements available in a surveillance system. Secondly, it is used to obtain a prediction of future network conditions. The simulation model was designed on the basis of an object-oriented programming paradigm. The running time and accuracy of the model are controlled through: (a) aggregation of the vehicles into single units. (b) choice of time step. Network Representation: The simulation model uses four types of network elements: Links, Nodes, Segments, and Traffic Streams. A link is defined as a uni-directional section for vehicles between two intersections. Thus a two way street that crosses multiple intersections would be divided into Links, each corresponding to the part of the street in one direction between two successive intersections. Intersections, route guidance and route origin-destination points are represented as Nodes. Links are divided into Segments. Segments have a capacity constraint at the downstream end and consist of two parts: (i) a moving and (ii) queuing part. The moving part of a Segment is where vehicles can move with some velocity. The queuing part of a 78

95 Segment is where vehicles are queued up due to the downstream capacity constraint. The length of the moving part and the queuing part may vary as the simulation proceeds. The length of the queuing part is the physical length of the queued vehicles. The length of the Segment not occupied by the queuing part forms the length of the moving part. This representation provides a uniform way of modelling queues. At the same time, signals, closed lanes, incidents, etc. are represented by their effect on the capacity at the downstream end of a Segment. Another assumption taken into account in the introduction of the Segments is that only vehicles ahead of the vehicle in the moving part of the Segment influence its velocity, rather than all vehicles on a Link. The segments are objects that can be dynamically created and deleted and some of the capacity constraints can occur dynamically. Traffic Streams are used to model lanes. A Traffic Stream is defined as a flow or queue of vehicles. In the case of a detailed simulation, a Traffic Stream corresponds to a lane, while in a macroscopic simulation a number of lanes can be grouped together as a single Traffic Stream. Two types of Traffic Streams exist in the model: Moving Stream and Queuing Stream. Flow Representation: The traffic flow in the model is considered as discrete units, but the velocity calculations are made using macroscopic speed-concentration relations. At the same time, the model allows grouping of vehicles which improves the performance of the model. The simulation model accommodates two levels of vehicle aggregation. The first level defines the Traffic Cell as an indivisible moving unit which consists of one or more vehicles. All vehicles in a Cell share the same traffic characteristics.the position of the Cell is defined by a single dimensionless point and each Traffic Cell is fully contained within a Segment. Its size is taken into account only in the case of queue calculations. The maximum size of the Traffic Cell determines both the accuracy of the model and its runtime efficiency. The next level of aggregation provides the means for additional run-time improvements and defines the Packet. A Packet consists of one or more Traffic Cells. Packets are neither indivisible nor dimensionless and are defined by the number of Traffic Cells contained and the position of the lead and rear Traffic Cell in the Packet. Traffic Cells are assumed to be uniformly distributed within the length of the Packet. Traffic Dynamics: The velocity of a Traffic Cell on a Segment is assumed to be a function of the traffic density ahead of the Traffic Cell on the moving part of that Segment. Any reasonable speed-density function can be used to update the speed of a Traffic Cell i.e. () t = f k n i t, where u n i () t is the velocity of Traffic Cell n u n i 0 ()k i on Segment i during time interval t, k n i () t is the concentration (density) ahead of 79

96 Traffic Cell n on Segment i at the start of time interval t and is the jam concentration on Segment i. It is assumed that all vehicles ahead of the given Traffic Cell are uniformly distributed along the length of the Segment. A deterministic queuing model is used to calculate waiting times i.e. where w n i () t start of the time interval t, is the waiting time experienced by Traffic Cell n on Segment i at the is the number of vehicles in the queue ahead of Traffic Cell n on Segment i at the start of the time interval t and is capacity at the downstream point on Segment i during time interval t. When calculating the length of the queue ahead of a Traffic Cell, half the number of vehicles in the Traffic Cell are also taken into account to give an average wait time for the Traffic Cell. Each Segment has an output capacity and an acceptance capacity. The output capacity defines the rate at which vehicles can leave the Segment and the acceptance capacity defines the rate at which vehicles can enter the Segment. The output and acceptance capacities are dynamic in nature. They can change as the simulation proceeds due to events like incidents, lane closures, spillbacks, changes to signal settings etc. The Simulation Process: The simulation of the traffic network operations proceeds in two phases: (i) the Update Phase and (ii) the Advance Phase. The Update Phase is used for updating the values of the variables used in the simulation during each simulation cycle, while the Advance Phase is used for advancing the Traffic Cells to their new positions at the end of the simulation cycle. The Update Phase occurs at the start of every simulation cycle. Variables such as velocities, waiting times, densities and queue lengths are updated during this phase. Apart from the velocities and waiting times, the density on the moving part of the Segment and the length of the queue on the queuing part of the Segment are also calculated. These values are then assumed to be constant during the simulation cycle. Thus at the end of the Update Phase, queue lengths, density and velocity of Traffic Cells in the moving part and the waiting of Traffic Cells in the queuing part of each Segment are known. In the Advance Phase, Traffic Cells are advanced to their positions at the end of the current simulation cycle using the velocity, waiting time, density and queue length values obtained during the Update Phase. A key issue in the design of the Advance Phase is the order in which the vehicles are advanced. A Traffic Cell can move forward only when the vehicles ahead of it have moved. This approach ensures that a Traffic Cell is not moved until all Traffic Cells ahead of it on its path are advanced to their new locations. If the simulation step is chosen to be a large one, then there is possibility for Traffic Cells to move over multiple Nodes in a single time step. The simulation model reduces the negative effect of this possibility through: q n i () t w n i k 0 i () t c () t i n q () t i = c () t i 80

97 (a) processing the intersections in each cycle in random order, since the error accumulates if the same order of Node simulation is followed in every simulation cycle. (b) dividing the Advance Phase into series of smaller advance steps, so that in each step the likelihood of the Traffic Cell crossing multiple Nodes is small Traffic Flow Microsimulation Models. The functions of the microsimulation models, used within the traffic control systems, can vary substantially. The simulation model can be a basic module for traffic queues and traffic density predictions in the real-time traffic control, as a part of the Queue Prediction Module, or, alternatively, can work off-line and evaluate control strategies, which subsequently will be executed on the field according to the current situation. Subsequently, the design of the simulation model reflects the functionality of the part of the system within which the model is going to be used. The proposed system will consider the use of a macrosimulation model, used as the basis for a system s traffic queue and traffic density predictions and the use of a microsimulator module in a supportive role. It has to be recognised, therefore, that the macrosimulation model will perform predictions on a scale of up to 30 min., which is much longer than the time-scale of optimisation of the operational control system (typically up to 3-4 min.) and the time-step of the operation of the macrosimulation model will be one cycle. Subsequently, some of the internal parameters, used by the macrosimulation process, can not be verified within the process, because they require simulation on a shorter than one cycle time-scale. In order to improve the quality of the traffic queues and traffic density predictions, the Traffic Control System Model employs a microsimulation model, capable of verification of some of the parameters of the macrosimulation model (e.g. queue dissipation, number of cars joining the queue during the red signal at an intersection etc.) during the prediction process. At the same time it is impossible for the microsimulation model to represent the whole urban traffic network and to simulate every single car in the streets because of the fact that the computational power available (or available at an acceptable cost) is simply not enough. However, it is possible and necessary to employ such a model to validate the parameters of the microsimulation process for several, critical for the traffic network, crossroads. This is due to the microsimulation models ability to represent the driver s behaviour (vehicles dynamics), which on the macroscopic scale is somewhat implicit. The microsimulation model described in this chapter has been designed to be a supportive part of the macrosimulation model, included in the traffic control system. It presents one possible implementation of the car-following microsimulation model first proposed by [Reushel R., 1950] and [Pipes L.A., 1953] and significantly enhanced 81

98 recently by [Gipps P.G., 1981], [Gipps P.G., 1986]. It has to be pointed out, however, that this research envisages the use of one of the commercially available microscopic models (HUTSIM in particular) for its full completion. Thus the microscopic simulation model has been implemented to illustrate the potential of the design of the overall system for the combined work of two simulation models: macrosimulation model and microsimulation model. The most important requirements, which the design of the microsimulation model has to take into account are: to be able to verify the number of cars, joining the queue at the stop line during the green signal, for all links in the simulated sub-network (cross-road) and to validate the links discharging rates (the number of cars leaving the queue per second). These parameters will be subsequently used by the macrosimulation model. to be able to accept traffic generating/sinking functions, defining the number of incoming/outgoing vehicles into/from the simulated network. These functions will be supplied by the macrosimulation model, which as part of the dynamic traffic model system, provides the harness for every microsimulation module. to allow concurrent running of several copies of the microsimulation program in a DIME environment; to be able to simulate a sub-part of the traffic network, which had been defined in advance. The car-following microsimulation model is the basis for almost all microsimulation models to date, therefore a brief discussion of the basics of the model is presented in the paragraphs below. It is followed by a short description of some of the most common simulation models. The statistical data information, presented here, has been provided in the documents available under the SMARTEST project Car-following microsimulation model. In the field of traffic modelling, car-following models - as a sub-division of the microsimulation models - are used to describe the behaviour of the driver-vehicle system in a stream of interacting vehicles. Car-following models consist of difference equations giving the acceleration of a vehicle with respect to the behaviour of the preceding ones. The general form of carfollowing models can be represented by the expression: response(t+t)=sensitivity x stimulus(t) (EQ 4-1) 82

99 where T is the reaction time of the driver-vehicle system. Although an exact description of this stimulus-response reaction would be very complicated, it has been proved that rather simple continuous differential difference equations could give a very good approximation of the phenomenon Simple Linear Car-Following Model. This model is mathematically expressed by: V n 1 + ( t + T) = a[ V n () t V n+ 1 () t ] (EQ 4-2) where n is the number of the lead car, n+1 is the number of the follower, T is the time delay and a is the sensitivity coefficient. [Chandler R.E., Herman R.C., Montroll E.W., 1958] obtained data to verify the model and showed experimentally that T was approximately 1.5 sec. and a was approximately 0.37 sec -1. However, this very simple model is not very satisfactory as it does not take into account the distance between given vehicle and the vehicle in front of it and the speed of both vehicles, as in the case with HUTSIM [Kosonen, I., 1996] Non-linear Car-Following Models. In order to take into account the distance between vehicles in the model formulation [Gazis D.C., Herman R.C., Potts R.B., 1959] developed the following model: V n 1 [ V n () t V n + 1 () t ] + ( t + T) = a [ x n () t x n+ 1 () t ] (EQ 4-3) which shows the response to be inversely proportional to the spacing; a 0 is another sensitivity coefficient (in meters per second), Vehicle n+1 following vehicle θ x n () t x n 1 + Figure 4-2: The visual angle model. is the position of the n th vehicle at Vehicle n x n leading vehicle moment t and V n () t is its speed. [Pipes L.A., 1953] derived a car-following model based on the assumption that the acceleration for the following vehicle is proportional to the driver s perception of the rate 83

100 of change of the visual angle (shown on Figure 4-2) and presented the following nonlinear equation: V n 1 V n () t V n+ 1 () t + ( t+ T) = a [ x n () t x n+ 1 () t ] 2 (EQ 4-4) A further analysis of the driver behaviour showed that, for a given difference in velocity and a given spacing, the response is more important for the higher the velocity of the vehicle. Finally, these considerations lead to the following generalised form for a nonlinear car-following model [Gabard J.F., 1991]: V n 1 V α n () t V n+ 1 () t + ( t + T) = a 0 V n+ 1 ( t + T) [ x n () t x n+ 1 () t ] β where a 0, α and β are constants. (EQ 4-5) Gipps car-following model. More recently, [Gipps P.G., 1981] proposed a new car-following model based on the assumption that each driver sets limits to his desired braking and acceleration rates. The model has two components, which cover acceleration and braking separately. For acceleration, the formula is: V a n 1 V n + 1 t Vd n+ 1 () + ( t + T) = V n+ 1 () t + 2.5α n+ 1 T (EQ 4-6) where Va n+ 1 ( t + T) is the maximum speed to which vehicle n+1 can accelerate during the time interval ( t, t + T), Vd n + 1 is the desired speed for vehicle n+1 and α n + 1 is the maximum acceleration for vehicle n+1. For braking, the formula is: V n+ 1 t V d n+ 1 () V b n + 1( t + T) = β T n (EQ 4-7) + [ β T] 2 V n () t [ x () t l x () t ] n + 1 n n n+ 1 V n + 1 () t T β where V n+ 1 ( t + T) is the maximum safe speed for vehicle n+1 with respect to vehicle n, β n + 1 is the most severe braking the driver of vehicle n+1 wishes to undertake (<0), l n is the effective length of vehicle n and β is the estimate of β n used by the driver of vehicle n+1. In any given circumstances, the speed adopted by vehicle n+1 is min [ V a n+ 1( t + T), V b n+ 1( t + T) ] (EQ 4-8) 84

101 This model was used in MULTISIM, a program for simulating vehicular traffic in multilane arterial roads [Gipps P.G., 1986], in which special attention was devoted to the modelling of the structure of lane-changing decisions HUTSIM microsimulation model. The HUTSIM approach for modelling the driving dynamics differs from the classic carfollowing model approach in several ways [Kosonen, I., 1996]. In the classic approach it is assumed that the driver is able to observe the speed and even the acceleration of the first vehicle. In HUTSIM the only characteristic which the driver is able to observe is the distance between its car and the car moving in front (if any). Typically the reaction time in the classic model is included as a fixed time offset between an event which can induce a reaction and the reaction itself. In HUTSIM, this reaction time may vary. : 1. No Speed Change: The default case. Keep the present speed level. 2. Speed Up If: { < }and {T-T last > T acc V own } V own V des The current speed V own is less than the desired speed V des and the time elapsed from last speed-up T is more than T last acc. 3. Do Not Speed Up If: { D obs < S min ( V own, V obs ) + W stab ( V own, V obs )} The distance from obstacle D obs is less than the minimum safe distance S min plus the width of stable area. W stab 4. Slow Down If: { D obs < S min ( V own, V obs )} and Not { V own < V obs } The distance from obstacle D obs is less than the minimum safe distance S min and the current speed V own is less than the speed of the obstacle. 5. Do Not Slow Down If: { V own < V obs }or { T T last < T maxdec } Own speed V own is less than the speed of the obstacle or maximum deceleration rate is exceeded. V obs Table 4-1: The speed control rule set T maxdec V obs In the classic model, all behaviour (acceleration and deceleration) is considered as a reaction. In HUTSIM, modelling of the reactional and intentional behaviour are separated. The main principle is that a vehicle s behaviour can only be restricted (deceleration of the vehicle) and not enforced (acceleration of the vehicle) by other objects. The intentional behaviour is always allowed when the vehicle is not restricted by 85

102 other objects. Thus the vehicle s intentional desire to accelerate at a proper rate and to maintain a proper speed level is never enforced but is allowed by the other objects in the simulation. The speed control is performed on the basis of a set of rules, represented in Table 4-1 on page 85. The HUTSIM simulation model provides two different on-line outputs [Kosonen, I.; Pursula M., 1990]. The first one is the screen demo of the vehicle s movements. The second one gives numerical information about the traffic situation, consisting of incoming flows, the mean and maximum queue lengths and delays. Information about lane blockages and other signal control details are also included in the output. The off-line output of HUTSIM gives detailed information about the movements of individual vehicles and is used for analysing the signal function for an intersection NETSIM microsimulation model. TRAF-NETSIM is a microscopic, one second time-stepping, stochastic model of traffic flow for urban street networks. Drivers and their vehicles are individually modelled. Modelling details include reactions to other vehicles in the traffic stream and also reactions to traffic control devices such as traffic signals [Rathi A.K., Santiago A.J., 1990]. The physical environment in TRAF-NETSIM is represented as a network comprised of uni-directional links and nodes. Generally, the nodes of the network represent intersections and links represent one-way urban streets. The vehicles enter the network through entry links and nodes and are moved each second according to the underlying simulation model. The underlying model of traffic flow in TRAF-NETSIM is its microscopic carfollowing model in which a driver s response, in terms of an acceleration/deceleration rate, is a function of the distance between the subject vehicle and leading vehicle, relative speeds, absolute speed, desired speed, vehicle characteristics and driver characteristics. Driver characteristics are defined by a distribution function representing a range of driver types between timid and aggressive behaviour. The acceleration/deceleration rate of a vehicle is determined every second of the simulation and is used to compute the vehicle state (location and speed) for the next one second time step. Furthermore, each vehicle is identified by a category (car, car-pool, bus, lorry), a type within each category (up to 16 different vehicles types with different operational and performance characteristics), and a driver characteristic (passive, normal, aggressive). TRAF-NETSIM has the capability to simulate the effects of traffic control ranging from simple STOP sign controlled intersections to a dynamic, real-time control system. 86

103 Signal controllers may be either fixed-time, multi-dial or actuated. The model simulates bus operations, effects of blockers and parkers, spillback, overflowing turn pockets and other elements of traffic operations on urban street networks in a highly detailed manner. In general, most operational conditions experienced in an urban street network environment are realistically described. The output of the model includes a variety of measures of effectiveness (e.g. speed, volume, density, delay spillback, queuing, turn movements) and estimates of fuel consumptions and emissions on each link of the network, groups of links and the entire network over user-specified time intervals AIMSUN2 microsimulation model. The AIMSUN2 model is developed at the Departament d'estadistica i Investigacio Operativa, Seccio d'informatica, Universitat Politecnica de Catalunya. Its objective is to simulate urban and interurban traffic networks containing a wide range of advanced transport telematics systems. It provides a user friendly interface for model building and can facilitate the simulation as an assessment tool. The network model in AIMSUN2 consists of a set of nodes and a set of links (sections) decomposed into lanes and turnings from lane to lane. The very sophisticated graphical interface allows flared exits or entries. The model allows two possible distribution models: input flows and turning movement coefficients model. origin - destination matrices and route choice model. The vehicle dynamics are described by the equations for the car-following model (GIPPS) with lane changing. The vehicle representation allows the defining and using of various types of vehicles (in fact as many as there is need for). Sets of types, called classes, can be defined to group vehicle types. The traffic control entities in the model include traffic lights, stop and yield signs, and vehicle detection devices Summary of traffic flows microsimulation models (source - SMARTEST project report). Scale of application: The scale of application of microsimulation models depend on the size of the computer memory and on the computer power available. It starts from a small size type (50 nodes, 1000 vehicles), goes through medium size (200 nodes and many 87

104 thousand of vehicles) and finishes on large scale models like MICROSIM, PLANSIM-T and PARAMICS which can simulate vehicles, but they use parallel computer architectures. Objects and phenomena modelled. The objects and phenomena modelled include: queue spill back, incidents, commercial vehicles, roundabouts, public transport, traffic calming measures, parked vehicles, pedestrians, weather conditions and bicycles and motorbikes. Output indicators. The micro-simulation models provide output for some of their internal parameters in order to help the human operator arrive at proper conclusions about the simulated network. The most common indicators include: speed, travel time, congestion location, travel time variability, queue length, public transport regularity, and interactions with pedestrians. Transport telematics. Telematics functions that are most studied are vehicle detectors, adaptive traffic signals and co-ordinated traffic signals. In recent years, studies on ramp measurements, static and dynamic route guidance and incident management gained popularity. Interface. Most of the micro-simulators use Graphical User Interfaces. It is generally an online animation with which the user can visualise vehicle movements and state of traffic lights and signals, display various traffic variables and path information simply by clicking on objects and zooming in (out). Control strategies and algorithms. Each micro-simulation model uses a different set of control strategies and algorithms. No standard model or strategy is used often enough to become a benchmark in the description of the models. Validation and calibration. Validation and calibration have received various answers from micro-simulation designers. Only a few of them have made it an objective to fully validate and calibrate their models on real data. Most of the models are partially calibrated and validated. For example a driving simulator model usually uses a partially validated car following model - measured travel times and measured headway distributions Conclusion from the review of the simulation models. The heart of every dynamic traffic control system is an appropriate traffic simulation model. A variety of simulation models have been designed and implemented. Some of 88

105 them have been successfully embedded in real-time traffic control systems implemented across the world. However, there is still the lack of a unanimously accepted traffic flow model. The end result is that there are several traffic simulation models - each one representing the traffic flows in its own way. At the same time, a few real-time traffic control systems have been implemented in the field, which have proved that a successful local control is possible. On the basis of the survey of traffic simulation models, presented in the previous paragraphs, several important conclusions can be formulated: (a) Simulation on a large scale (a traffic network represented by several hundred nodes) on relatively inexpensive computers (i.e. easy to deploy in a traffic control centre and not only for research purposes) is only possible through macrosimulation i.e. representing the traffic flow as platoons of vehicles, rather than individual vehicles and considering traffic flow parameters such as density, average speed in a link, queue lengths etc. Examples for macrosimulation programs are: SIMAUT [Morin J.M., 1985], META [Papageorgiou M., Blosseville J.M., Hadj-Salem H. 1990], METANET [Messmer A., Papageorgiou M., 1990], Traffic Simulation Model for ATMS/ ATIS operations presented by [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]). (b) All models consider the simulation process as a part of the dynamic control system performing local and supervisory traffic control. However, it has to be recognised that local control needs to be performed on a very short term prediction basis (a few seconds to a minute) and it should be performed by the existing traffic control systems. At the same time predictive simulation is relevant to the longer term forecasts (a couple of minutes to tens of minutes) and should be provided within the supervisory control of the traffic network. In addition the predictive simulation should provide the control harness for the real-time traffic control system where local changes reflect the individual traffic light setting requirements and follow in the same time the trend prescribed by the control harness. (c) In the description of the simulation models the link between the model and the control system, which provides on-line data, is concealed. Therefore, there is not a clear indication how the input data from the real traffic network can become a basis for simulation. Very often it is difficult to supply on-line data to the simulation model and an additional conversion program is needed. 89

106 (d) All simulation models (except the model for ATMS/ATIS operations presented by [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994]) differ significantly from the implemented real-time traffic control systems in the way of queue formation and dissipation. (e) All simulation models assume that local control settings are an indivisible part of the traffic control strategy under consideration, while in fact there is the need for a second copy of the local control generator to be linked to the simulation program in order to provide the controls to simulated measurements. The strategy harness will be the strategy under evaluation and the simulation model will consider the behaviour of the traffic flows using the settings provided by the control strategy generation module. In this context there is a clear need for a two way data interface between the simulator and the control strategy generation module. (f) Most of the models are designed for off-line evaluation and their on-line use is limited to front-end graphical display only. Clearly more research is needed into building simulation models, whose primary purpose is on-line evaluation and on-line control. Such models have to recognise the presence of a real-time local traffic control system and work as a supervisory extension of such a system Prediction of Traffic Flows. One of the major concerns in traffic engineering is the development, implementation and evaluation of mathematical models providing real-time short-term forecasts of traffic flows and travel times along some of the links of urban and interurban networks. In fact, traffic management and control centres need accurate information about traffic parameters and variables in order to maintain a stable traffic pattern and reduce expected near-future congestions. Each simulation model is forced to use such a prediction model for its boundary nodes (i.e. nodes, which connect the traffic network under consideration to the external world). Three types of traffic volume predictions can be distinguished, depending on the time scale [Lesort J.B. 1991]: (a) long term predictions (a few months) that can be used to forecast the required capacity of transportation facilities, or else compute fixed-time coordination signal plans. (b) short term predictions (a few minutes), that can be used in adaptive regulation systems, where the implemented coordination plan is successively selected from a pre-stored package. 90

107 (c) very short term predictions (a few seconds to a minute), that can be used by real-time regulation algorithms, which are highly responsive to traffic variations. The long-term prediction models are not actually used in the control systems. Instead the emphasis is on short and very short-term prediction models. They are crucial to the development and implementation of advanced transport strategies, because they are related to within-day decisions on mode, route, time and even parking destination choice. Several kinds of predictive models based on techniques of time series analysis are used for short term prediction. Some models rely on the periodicity of traffic volume from one day or one week to another and use historical data as inputs. Others rely on the stability of traffic volumes over a short period and use current data measurements as inputs. The third group of methods uses a combination of both types of input Short-Term Traffic Flow Prediction Models Linear Models Using Smoothed Information. These methods were embedded in the simulation models by various researchers [Ross D.W. et al., 1977], [Ganslaw M.J., Schaake J.C., 1973]. They use both historical information and current day measurements as inputs. The time unit of prediction is 5-15 min. For example considering y( t 1) the measured volume at time interval ( t 1), z ( t 1) the smoothed historical volume for the time interval ( t 1) and r() t = ar ( t 1) + ( 1 a) [ y( t 1) z( t 1) ] the exponentially smoothed difference between measured and historical volumes, the model will give the predicted volume at time interval t by P() t = z() t + r() t + c() t (EQ 4-9) where c() t = β[ y( t 1) z( t 1) r( t 1) ] is the difference between the real and smoothed values of y z with a coefficient β computed by identification. The smoothed historical volume is obtained by fitting the Fourier series n z() t = A + 0 [ A cos ( ( 2πit κ) + B sin ( 2πit κ) )] i = 1 i i to a representative volume data set. (EQ 4-10) The main drawback of this kind of model is its poor responsiveness to abrupt changes in the traffic, related to the importance of historical information in the model [Papageorgiou M. 1991]. To avoid this drawback [McShane W.R., Lieberman E.B., Goldblatt R., 1976] developed a method which relies only on current-day measurements. The time unit is from one to a few traffic signal cycles and the prediction consists of two steps. Considering y() t the measured volume at the time interval t, 91

108 z() t = az ( t 1) + ( 1 a)y() t r() t = y() t z() t predicted volume P() t the exponentially smoothed volume and the difference between the real and smoothed values, the is given by where P() t = z( t 1) + βr( t 1) (EQ 4-11) The constant (EQ 4-12) is computed from a representative set of data and n is the number of data points used for this determination. This kind of model responds well to traffic changes, but always presents a certain time lag General Spectral Analysis Prediction Model. One of the various techniques used to compute smoothed historical volumes is to use spectral analysis algorithms. The technique in a more general form is used by [Nicholson H., Swann C.C. 1974]. The principle is to consider volume measurements on N days divided into c time intervals. The flow volume on day n at time interval t is defined as, for j = 1, 2,... n (EQ 4-13) where e () t is an independent expansion error and the φ() t j j are a set of orthogonal vector functions representing the characteristic modes of function. Prediction is realised by computing, at time interval t i of day n+1, the coefficients A, from data P ( 1) j + 1, i j + 1,..., P ( t i ) j Prediction of traffic flows using ARIMA Model. Box-Jenkins methods for time series analysis were initially used for the long term prediction of traffic flow. Subsequently, they have been successfully applied for shortterm prediction of traffic volumes on freeways [Eldor M., 1977]. The main interest of these methods is to provide the user with a whole class of models and to give him procedures for choosing the most appropriate one. Classical schemes, such as exponential smoothings, can be considered as particular cases of the general method. The general ARIMA method is described by β β = n 1 ( n 1) r()r t ( t + 2) t = n ( n 2) r t t 1 t P () t = A φ j () t + e () t i = 1 ti, i j () 2 P j φ ( A) c f() t = θ + θ ( A)e () t 0 (EQ 4-14) 92

109 where f () t is the series value at the time t and f() t = f() t f( t 1), c f() t = [ c 1 f() t ] (EQ 4-15) Af () t = f( t 1), A n f() t = f( t n) φ ( A) = 1 φ A φ A 2... φ A p 1 2 p θ ( A) = 1 θ A θ A 2... θ A q 1 2 q θ 0 is the overall moving average constant and time series may be either f() t or the series e() t is random noise. The predicted where historical volume at time interval t Filtering Methods. (EQ 4-16) is calculated according to (EQ 4-10) and represents the smoothed Various filtering methods using the Kalman filter have been proposed [Baras J.S., Levine W.S., Dorsey A.J., Lin T.L., 1979], resulting in queue-length predictive models using only current-day data. These methods use a number of previous measurements (usually between 10 and 30) of the wanted value and try to make a prediction on that basis. z() t Very-Short Term Traffic Flow Prediction. The problem of very short term prediction, although it has some characteristics in common with the short-term prediction problem, is very different. The most interesting available data are no longer previous measurements at the point studied, but measurements at points situated upstream, hence, the main problems in these models is to estimate travel time from upstream to downstream points, starting only from flow volume information. Since the relation between flow volume and travel time cannot be precisely formulated in an urban network, no explicit model can be realised. The models use therefore mostly linear models [Lesort J.B., Tardieu B., Lebacque P., 1982], fitted to a representative data set and eventually corrected on-line. A linear model can be defined as follows: P 0 (EQ 4-17) where P 0 () t is the predicted volume at the time interval t at the downstream point, Y i () t is the volume measured at time interval t at the upstream point, 1... n are possible values of travel time between two points and are coefficients by linear regression for a representative data set. P() t = f() t z() t n () t = a Y ( t ) i i i i = 1 a 1...a n 93

110 SCOOT Prediction Model. SCOOT (Split, Cycle and Offset Optimisation Technique) is a traffic-responsive Time now Distance along the street Traffic Flow Rate (LPU) Detector Data } Actual Queue 0 Cycle Flow Profile for 1 Cycle 1 Cycle Cruise Speed Flow adds to the back of the queue Back Saturation Flow Rate Predicted queue at time now Queue Front Stop Line Red Signal Green Signal Past Future Time now Time Figure 4-3: Principles of the SCOOT Traffic Model (after [Hunt P.B., Robertson D.I., Bretherton R.D., Winton R.I. 1981]). Urban Traffic Control System developed in the UK for optimising network traffic performance. The traffic model, which is fundamental to SCOOT, uses data that varies in time, such as green and red times of the signals and vehicle detection measurements. Together with the data constant for the area under control (detector locations, signal stage order etc.), the SCOOT system processes the information to estimate queue formation, delays and stops for each link in the area and, according to the results of the optimisation process, changes the signal settings. The SCOOT traffic model s main principles are illustrated in Figure 4-3. The data from the detectors are stored in the SCOOT computer as cycle flow profiles for each link. These reveal the variation in traffic demand during each cycle and are used during offset optimisation to ensure good signal coordination. The cycle flow profile is then projected into a number of LPUs (link profile units, defined 94

111 in SCOOT and corresponding to the occupancy value of the traffic detectors), arriving at the stop line in a future moment of time. Travelling time corresponds to the time needed for the traffic to arrive at the stop line at the cruise speed defined in the model (modified to take into account any dissipation of the traffic flow) and validated on the field. The arriving traffic flow is always added to the back of the queue. The queue dissipation is according to the discharge rate specific for any particular intersection and it is different for any specific direction in this intersection. The discharge rate d() t is presented in Figure 4-3 as straight line and denoted as saturation flow rate. Its meaning is the number of the cars leaving the queue per second and its determined during the validation of the system on the field. Thus, the overall number of cars (LPUs) leaving the queue depends on the duration of the green light in the direction under consideration and the discharge rate i.e. N() t = d() t Θ() t d() t (EQ 4-18) where d() t is the discharge rate, N () t is the number of cars leaving the queue during the green signal of the traffic light and Θ () t is the duration of the green signal in seconds. The SCOOT traffic control system models horizontal queues, i.e. it takes into account the front and the back positions of the queue to calculate precisely when the incoming traffic flow joins the back of the queue. Queues grow during the red period, according to the demand, and discharge during the green period. Any queue remaining at the end of the green signal is carried over to form the initial queue length at the start of the following green period. The total delay during the cycle is equal to the shaded area within the triangle on Figure 4-3. Other features of this modelling are that queues can not exceed a maximum queue value for the link, dependent on the location of the traffic detector for the link, and exit blocking by downstream link is modelled by assuming d() t = 0, i.e. assuming no discharge rate when the situation occurs SCATS Prediction Model. The Sydney Coordinated Adaptive Traffic System (SCATS) has been developed by the department of Main Roads, New South Wales, in response to a perceived need for a traffic adaptive UTC system to coordinate the greater proportion of Sydney s traffic signals. The most important traffic parameter used by the SCATS algorithm is a parameter analogous to the degree of saturation parameter in the SCOOT system. It is defined as the ratio of the effectively utilised green time to the total available green time [Lowrie P.R., 1982]. To determine the effectively utilised green time, the time during which unused space is crossing the stop line must be subtracted from the total available green time. There is a distinction in the system however, that not all the space crossing the stop line is unused because each vehicle has associated with it a space which is a function primarily 95

112 of speed and which can not be zero. SCATS calculates the effectively used green time Θ as Θ = Θ ( H h n) (EQ 4-19) where Θ is the available green time, H is the total time for a sensor not to be occupied by the vehicles crossing the stop line during the green in the case of constant traffic flow through the stop line, h is the time for the sensor not to be occupied by a vehicle (it is called space in the SCATS terminology), which is unavoidably associated with each vehicle crossing the stop line and n is the number of such gaps. The degree of saturation is given by DS = Θ Θ (EQ 4-20) If a platoon crosses the stop line at saturation flow, the total space is equal to the sum of the spaces which must accompany each vehicle and hence Θ = Θ as H = h nand DS = 1. Where the flow is less than saturated during green signal then H> h n, Θ < Θ and DS < 1. Where the flow is restricted by congestion beyond the stop line the parameter has a value H< h n. The basic offsets specified in these two plans will not (as a rule) be entirely appropriate for both traffic conditions and SCATS modifies them as a function of cycle length in accordance with the expression p = p[ 1 + A g( C) ] (EQ 4-21) where p is the modified offset in seconds, p is the basic offset, A is the specified modifying factor and may be positive or negative and g( C) is a linear function of cycle length where g( C) = 0 when C = C max and g( C) = 1 when C 0.75C max Conclusions on prediction of traffic flow. Traffic flow simulators require predictions of inflows in all entry nodes in the traffic network. To solve the problem several sophisticated techniques for traffic flow prediction have been proposed and implemented. According to the input information used in the models, they rely on current on-line data only or, alternatively, they rely on a combination of current on-line data and historical data. Historical data may be collected over a period of several days (weeks or months) and will represent traffic flow s daily (weekly, monthly) pattern. Out of the four prediction models, described in section 4.5.1, the AR model has been selected as offering the best flexibility to the user in terms of tuning the model parameters. 96

113 4.6. PADSIM - Macroscopic City Traffic Flows Predictive Simulation Model. The characteristic feature of SCOOT/SCAT systems is the prediction of queue length in every link using the measurements of the volume of incoming traffic into each link. The time-scale of each prediction is equal to the travel time between the detector and the back of the corresponding queue and is of the order of the duration of the traffic signals cycle. Since the predictions are used in the optimisation of traffic signal timings they also define the time horizon of optimised control. The improvement of demand responsive control systems over the fixed timing plans systems has been found to be very significant, particularly for high traffic volumes. From the control theory viewpoint, these systems can be seen as including a feed-forward signal which provides an advance notice to the control system about the expected length of queues and improves the system performance. A brief consideration of both operational control systems shows that they try to cope with the problem when it already exists (i.e. demand-responsive systems react to what has already happened in reality). Both systems have a very short prediction model (See (EQ 4-18) and (EQ 4-21)) which allows them to adjust signal settings properly according to the demand as measured by traffic counts. However for optimal traffic control this approach is not adequate. The future generation traffic control systems as outlined in Chapter 2 of this thesis, will attempt to provide a supervisory layer of optimised control by using both in-vehicle and road-side dynamic route guidance. By its very nature, route guidance has to operate on time scales that are significantly longer than a single traffic signals cycle in order to be useful to road users. Consequently, the optimisation horizon of the supervisory control schemes must extend over several traffic signal cycles thus necessitating correspondingly longer-term predictions of the evolution of traffic flows. The following paragraphs investigate the possibility of defining a simulation model which is to be used in the supervisory control layer. The model needs to reflect the requirements set in 4.4. Subsequently a novel mathematical model describing the macroscopic traffic flows is presented. The model can be used for deriving longer-term predictions of queues and traffic densities in each link using not only the corresponding measurements in a link but also, indirectly, the measurements in 'up-stream' links through the use of the estimates of drivers' turning movements on the intervening intersections Timing Model Definition. The prediction of traffic flows and queue lengths in large scale (several hundred nodes) urban traffic networks requires consideration of averaged traffic flows and platoons of vehicles, rather then individual vehicles. The simulation model has been formulated in a state-space with the state defined as a vector that has two state variables for each link i, 97

114 the queue length at the red-to-green transition time instance c, denoted as the average traffic density during the traffic signals cycle, denoted as k ( t i i c ) q ( t i i c ), and. The model is unconventional in that the state variables are not evaluated in a single, common instance of time, but in time instances that are link specific and correspond to the occurrence of the longest queues during the traffic signals cycle (Figure 4-4). Such a choice of the state vector appears to have several advantages. Since the control of traffic signals involves adjusting the cycle time, the offset of cycles on consecutive cross-roads and the split of cycle into red and green times, the model of traffic dynamics that uses the state vector evaluated at the red-to-green transitions, implicitly takes into account all cycle and offset controls and it needs to represent explicitly only the split timings. Legend: - red signal Link i 1 Link i 2 Link i 3 Link i n T.(c-1) T.c T.(c+1) t i t c 1 times for links i 1, i 2, i 3,... at the end of the red signal t c i times for links i 1, i 2, i 3,... at the end of the red signal Figure 4-4: Time Instances Definition Queue Length Calculation. The model (recursively) calculates the queue length red-to-green transition in the cycle c+1 on the basis of: q ( t i i c + 1) for link i during the the queue length q ( t i i c ) in the link i in the current cycle c ; the number of the cars c+1 ; Q ic, + 1 joining the queue in link i during the cycle 98

115 the number of cars N ic, + 1 Θ ic, + 1 the cycle c+1,. discharged from the queue during the green signal in The evaluation of the actual queue lengths needs to take into account that vehicles arriving during the green signal could cross the stop-line and not necessarily form a queue. The current model assumes a uniform distribution of the arrival rate at the stop line thus implying that if is the cycle duration and is the green light T Θ c + 1 ic, + 1 duration for the link i in the simulation step c+1, the number of cars arriving at the stop-line or joining the back of the queue during the green signal will be (EQ 4-22) and, the number of the cars arriving at the stop line during the red signal and forming part of the new queue will be Q Θ Θ ic, + 1 ic, + 1 = Q ic, + 1 T c + 1 Q T ic Θ T c + 1 Θ ic, + 1, + 1 = Q ic, + 1 T c + 1 (EQ 4-23) Three specific cases were considered in order to derive the recursive equation for the state variable: long queue; short queue + high arrival rate; short queue + low arrival rate. Stop Line q i t c i ( ) N ic, + 1 Link i in Time Step c NQ i, c + 1 q i ( t c+ 1 ) i N ic, + 1 Link i in Time Step c+1 t Figure 4-5: Queue Length Definition. Case 1. 99

116 Case 1 for queue length calculation - long queue. The first case is illustrated in Figure 4-5. Here the duration of the green light period is not enough to discharge the whole queue q ( t i i c ). The number of vehicles that are discharged, is defined by the discharge rate (a parameter validated on the N d ic, + 1 i field during the validation of the real-time traffic control system and showing the number of cars leaving the queue per second) of the link and the duration of the green light signal N = d Θ ic, + 1 i ic, + 1 Consequently the expected queue in the time instance i t c + 1 is (EQ 4-24) q i i t i = q t + Q N c + 1 i c i, c + 1 ic, + 1 (EQ 4-25) Case 2 for queue length calculation - short queue + high arrival rate. Stop Line Link i in Time Step c q i t c i ( ) Q T i, c + Θ 1 q i t c i ( ) Link i in Time Step c+1 t q i ( t c+ 1 ) i i, Q T ic, Θ c + Θ 1 N ic, + 1 Figure 4-6: Queue Length Definition. Case 2. The second case, illustrated in Figure 4-6, concerns the situation when the queue q ( t i i c ) is smaller then the maximum number of cars that can get discharged during the green signal but the number of cars that actually cross the stop-line is, as before, defined by the product of the discharge rate of the link and the duration of the green light (see (EQ 4-24)). This is due to the fact that some of the cars that arrive at the stop-line during the green signal are able to cross without forming a queue. Consequently the new queue q ( t i i c + 1) finite discharge rate is formed by those cars that arrived during the green signal but, because of the d i, were not able to cross the stop-line and by the cars that arrived 100

117 during the red signal q i t Θ Q i c + 1 i, c + 1 N q t Ț Θ = + Q i, c + 1 i c ic+ 1 (EQ 4-26) bearing in mind that Θ Q = Q ic, + 1 i, c + 1 Ț Θ + Q i c + 1 (EQ 4-27) the new queue is as in case 1 q i i t i = q t + Q N c + 1 i c i, c + 1 ic, + 1 (EQ 4-28) Case 3 for queue length calculation - short queue + low arrival rate. Stop Line Link i in Time Step c q i t c i ( ) Q T i, c + Θ 1 q i t c i ( ) Link i in Time Step c+1 t q i ( t c+ 1 ) i i, Q T ic, Θ c + Θ 1 Figure 4-7: Queue Length Definition. Case 3. N ic, + 1 The third case, illustrated in Figure 4-7, is similar to case two in that the queue q ( t i i c ) is smaller than the maximum number of cars that can be discharged during the green signal. However, all the vehicles that arrive during the green signal also cross the stopline. This case represents the general situation when the number of cars that actually cross the stop-line is less than the maximum number defined by the (EQ 4-24). The following equations describe the number of discharged cars i Θ N = q i, c + 1 i t + Q c i, c + 1 (EQ 4-29) 101

118 and the queue length q i i t Ț Θ = Q c + 1 i c + 1 (EQ 4-30) Equations (EQ 4-24) - (EQ 4-30) can be combined to give general expressions covering the above three cases and i Ț Θ i q t Q max q t Θ = + { i c + 1 i c + 1 i c + Q d Θ, 0} i, c + 1 i ic, + 1 (EQ 4-31) i Θ N = min { q t + Q, d Θ } i, c + 1 i c ic, + 1 i ic, + 1 (EQ 4-32) Traffic Density Definition. The second state variable for link i, traffic density k ( t i i c ) is defined as k( t i c + 1) = i number of cars in a link at time instance t c length of link i (EQ 4-33) The numerator in (EQ 4-33) represents the combined count of vehicles queuing on the stop-line, can be written as follows, and the vehicles that are moving along the link. Assuming q ( t i i c + 1) k ( t i i c + 1) is uniformly distributed along the link i the recursive equation for k ( t i i c + 1) k ( t i i c + 1) = k ( t i i c ) B N ic, + 1 i, c l i (EQ 4-34) where k ( t i i c ) is the traffic density in the link during the previous cycle c ; l i is the length of the link i ; B i c + 1 is the number of the cars entering the link during the cycle c+1 (note, B ic, + 1 N i, c + 1 that well approximates, + + where a is an integer representing the travel time along the link expressed in cycles); is the number of cars discharged from the queue for the duration of the green signal (calculated using (EQ 4-32)). The way the value of B ic 1 +,, in the (EQ 4-34) is calculated, depends on whether the link i is a boundary or an internal link (see Figure 4-8. for explanation of boundary and internal link). Q ic 1 a 102

119 For the boundary links the model relies on historical data representing queue length measurements for several previous cycles, days and weeks (see paragraph PADSIM incoming traffic flows short term prediction model). Boundary Links Internal Links Figure 4-8: Boundary and Internal Links For the internal links the value of the adjacent upstream links B i, c + 1 is calculated using the exit flows from B = N m ( c) i, c + 1 jc, j, i j Ω i (EQ 4-35) where Ω i N i c, is a set of indexes representing all upstream links adjacent to link i ; is the number of the cars exiting the link i ; m j, i ( c) is a turning movement coefficient determining what proportion of cars exiting link j in cycle c, N j c, estimation procedure see Chapter 5.)., enters link i (for turning movements Substituting (EQ 4-35) into (EQ 4-34), the recursive equation for traffic density, k ( t i i c + 1), in an internal link is as follows k ( t i i c + 1) = k ( t i i c ) N m ( c) j, c j, i N i, c + 1 j Ω i l i (EQ 4-36) 103

120 Similarly, assuming that B i, c + 1 is a function of the n previous measurements of the same value at the same point (see paragraph PADSIM incoming traffic flows short term prediction model), the equation for traffic flow entering link i during cycle c is B = F ( B, B, B,..., B ) ic, + 1 b i, c i, c 1 i, c 2 i, c n (EQ 4-37) and substituting (EQ 4-37) into (EQ 4-34) the recursive equation for traffic density, k ( t i i c + 1), in a boundary link is as follows k ( t i i c + 1) = k ( t i i c ) F ( B, B, B,..., B ) N b i, c i, c 1 i, c 2 ic, n i, c l i (EQ 4-38) Turning movements coefficients - introductory remarks. The definition for a turning movement coefficient between the traffic flow is simple: it is the ratio exiting link j in cycle c, and the traffic flow that enters link i in the same cycle. However, there are several important considerations, which have a significant effect on the simulation results. First of all, the turning movements coefficients are impossible to calculate on a cycle to cycle basis due to the insufficient number of independent equations needed to form a determined set (this will be explained in detail in Chapter 5). Subsequently, the assumption is that the turning movements coefficients are constant over an extended period of time (the length of the period depends on the calculation model and on the quality of input data). The meaning of this fact is: all turning movement coefficients are average estimations of the splitting of the traffic flows. Second, the output results from the macroscopic simulation model can be valid only if considered as averaged values, rather than as valid instantaneous values. Full explanation of the calculation of traffic coefficients is given in Chapter Calculation of the number of cars, + arriving at the stop line and joining the queue in cycle c+1. N j c, Q i c 1 m ji, ( c) There are two possible different ways of calculation of the number of cars arriving at the stop line and joining the queue in cycle c+1. Q i, c + 1 (a) Using the definition of the traffic density for given street i (EQ 4-33) and assuming a uniform distribution of vehicles in the link, then can be written that where: T ic, Q = k ( t i ic, + 1 i c ) is the cycle length in seconds; V ( t i i c ) T ic, (EQ 4-39) V i ( t i c ) is the average speed in the link in cycle c. 104

121 The relationship between the speed ( ) and the traffic density in a link i is given by the equation V i t i c k ( t i i c ) V i ( t i c ) = V min + ( V max V min ) 1 k ( t i i c ) k jam α β (EQ 4-40) where: V min V max k jam is the minimum speed in the link; is the free flow speed in the link; is the jam density in the link; αβ, are model parameters and α = 1.8, β = 5.0 as estimated and used by [May A., Keller H.E. 1967] and [Yang Q., 1997]. (b) Since this is a discrete model, it can be assumed, that the number of cars, entering a given link, will correspond to the number of cars joining the queue in that link after a certain period of time needed for the pack to travel along the link. As a consequence of the time instances definition in the model, the travelling time can be expressed in cycles only and the equation representing the connection between the number of cars Q i c, arriving at the stop line and joining the queue and the number of cars Q = B ic, + a i, c B i c, entering the given link is (EQ 4-41) where a is the number of cycles needed for B i c, to travel the distance to the stop line. An attempt to investigate the feasibility of the calculation case (a) has been made. Substituting (EQ 4-40) in (EQ 4-39) it can be written: Q = k ( t i i, c+ 1 i c ) V min ( V max V min ) + 1 k ( t i i c ) k jam α β T ic, (EQ 4-42) Knowing the value of from direct measurements the only unknown is. A simple iteration procedure has been written to estimate and subsequently ( t i c ). It has been found, however, that by using the chosen values α = 1.8 and β = 5.0 it is not possible to obtain sensible results in 50% of the cases. At the same time a study, that it is needed, to estimate the model parameters αβ, (possibly for every street in the traffic network) is well beyond the limitations of the current project. Q i, c + 1 k i ( t i c ) k i ( t i c ) V i 105

122 Out of consideration for availability, simplicity and speed, therefore, the results presented in paragraph are produced by employing the second method. If a section is simulated by using (EQ 4-41) and the results are inadequate, then this section is normally simulated within a copy of the microsimulation model, thus obtaining the number of cars joining the queue with the best possible precision PADSIM incoming traffic flows short term prediction model. The prediction of inflows in the boundary links relies on historical data representing the measurements of the traffic flow at the same point for several previous cycles, days or weeks. The current model employs an auto-regressive (AR) model, that weights the six most recent measurements (the evaluation of the model presented in , has found, that this is the most appropriate number of traffic flow measurements for performing short term prediction) to produce an estimate of prediction equation can be written as B ic, + 1. Thus the definition of the B = F ( B, B, B,..., B ) i, c + 1 b i, c i, c 1 i, c 2 i, c n (EQ 4-43) The enhanced implementation of the model will include terms from the previous days to instil into the ARMA model the awareness of the diurnal variation of the traffic Evaluation of the macroscopic traffic simulation model Evaluation of the AR model. Evaluation of the AR model has been carried out in the MATLAB environment. The data, used in the evaluation, were collected for 11 boundary links from the Mansfield traffic network for a period of two weeks, between 06 May 1997 and 20 May The aim was to estimate the coefficients and the power of the polynomial A( x) in the standard time series equation representation A( x)b() t = e() t (EQ 4-44) where B() t is a column vector, containing the measurements values, and e() t is white noise with known variance λ. Subsequently, tests have been carried out to establish the most appropriate values for the power of the polynomial A( x) and for the number of measurements B () t, that have to be taken into account, so that the squared prediction error is minimal. The representative set of results is shown in Appendix G. Table 1 - Appendix G. Table 4. It has been found, that this approach gives best results when setting the power of the polynomial to 2 and the number of measurements in the interval to 4-7. It has been found however, that the combination, which gives most often the minimal estimation of the squared prediction error is setting the power of the polynomial to 2 and the number of measurements in the vector for estimation of the 106

123 model s coefficients set equal to 6. These characteristics of the polynomial are subsequently used by the macrosimulation model to calculate the AR model for each step and to predict the future demand at the corresponding boundary link. Representative samples of the results for predictions accordingly 1, 3, 5, and 7 steps ahead are shown in Figure The correlation between the depth of the prediction and the squared prediction error is given in Figure 4-9. It clearly shows, that with increasing the depth of Legend: Data without averaging % (squared Data with averaging over 5 cycles prediction error) Prediction depth Figure 4-9. Correlation between the squared prediction error and the depth of prediction. Data from link N60311G on 13 may 1997, h. the prediction, the error increases (for the case of averaged data). At the same time, it can be seen that the prediction, averaged over 5 cycles, gives a very good approximation of the real data in comparison to the instantaneous data (in some cases the instantaneous error is over 300%). This comes to suggest, that using instantaneous prediction data from the simulation model is not good enough to perform control of the duration of the green lights (the error is too big), while using averaged predictions has a low error level and it is suitable for supervisory control operations Evaluation of the macroscopic traffic simulation model. The predictive macroscopic traffic flows simulation model was applied to the SCOOT controlled traffic network in Mansfield, Nottinghamshire. The traffic network consists of 21 nodes 55 links and it is shown in Figure The measurement data were collected via a communication link within the DIME environment between the real-time traffic control system SCOOT and the specially designed DIME client, capable of accepting and storing all data in a file. Representative samples of the results of the simulation experiments are presented in Figure These figures represent predictions for the link N60421B, which is one of the internal links in the network. The figure represents 107

124 LPU Legend: Real Data Simulated Data Prediction 1 step ahead. Data for 13 may 1997, h. Cycles LPU Cycles Prediction 3 steps ahead. Data for 13 may 1997, h. LPU LPU Prediction 5 steps ahead. Data for 13 may 1997, h Cycles Prediction 7 steps ahead. Data for 13 may 1997, h. Cycles Figure Evaluation of the AR model for predictions in the boundary link N60311G on 13 may

125 Figure The Mansfield traffic network. 109

126 LPU Legend: Real Data Simulated Data Prediction 1 step ahead. Data for 13 may 1997, h. Cycles LPU Prediction 3 steps ahead. Data for 13 may 1997, h. Cycles LPU LPU Prediction 5 steps ahead. Data for 13 may 1997, h Prediction 7 steps ahead. Data for 13 may 1997, h. Cycles Cycles Figure Evaluation of the prediction model for predictions in the internal link N60421B on 13 may h. 110

127 predictions with a different prediction time horizon and are compared to the real data collected by SCOOT between 10:00 and 12:00 on 13 may The experiments showed that the current model achieves greater accuracy of predictions for internal links than for the boundary links. The average prediction error is shown in Figure The Legend: Data without averaging % (squared Data with averaging over 5 cycles prediction error) Prediction depth Figure Correlation between the squared prediction error and the depth of prediction. Data from link N60421B on 13 may 1997, h. instantaneous average squared prediction error stays below 8% for predictions up to 15 cycles ahead, which is a good correspondence to the real data. The prediction error on the averaged over a 5 cycle period data is reduced even more and stays below a 4% boundary. Interesting to note at this point is the fact, that the prediction for both boundary and internal links stays around 5-6% for the prediction horizon of 1-3. Increasing the depth of prediction to up to 15 cycles ahead leads to a prediction error in the boundary link of above 15%, while the prediction error for the internal link is increased slightly to 8%. For evaluation of the speed of the macrosimulation model, there are several steps which have to be considered. (i) Step 1: Turning movements estimation. This step is common for all predictive models. Usually the model performing the estimation runs continuously on a separate machine, so that the turning movements estimation, needed for the macrosimulation process, is readily available within the DIME environment. The computational power of the machine hosting the module, and the number of cross-roads in the network under consideration are the most critical parameters for the speed evaluation of the model. On a P166 computer running a Windows 95 operating system - depending on the layout of the cross-road - it takes, on average, 1 sec for estimation of the turning movements. It will take 111

128 around 3-4 minutes to produce an estimate for a big traffic network with around 200 cross-roads. Considering the fact that these estimates are valid for a period of time equal to the duration of 15 cycles (i.e. valid for up to 20 min., see Chapter 5.), the above mentioned time of 3-4 minutes for an estimation period is acceptable. These results are based on using the standard software package MATLAB. It is expected that, by using specifically designed and compiled C/ C++ procedures, the speed of calculation will be increased. (ii) Step 2: Estimation of the parameters of AR models for all boundary links. Once again, this step is common for all prediction models, since no matter how big or how small the traffic network is, there always will be links connecting the network to the external world, whose input traffic flows will have to be estimated on the basis of the past measurements only. Subsequently, the time spent for calculations at this step, is common for all models. In the Mansfield traffic network there are 11 boundary links and it takes 3 sec to calculate the AR models for all such links. The computational performance for a big traffic network will be proportional to the number of boundary links in the network. Considering the fact that big city networks are more compact with more internal than boundary links, the expected time for calculation of the AR models for a big traffic network is 1.5 min. These results are once again based on using the standard software package MATLAB. It is expected, that by using specifically designed and compiled C/C++ procedures, the speed of calculation will be increased. (c) Step 3: Calculation of the prediction of traffic queues and traffic densities. This is the fastest step in the model, Having calculated all AR models for the boundary links, the calculation of the prediction for all internal links is a straight forward process of the calculation of linear dependencies (see the description of the model), which takes milliseconds to perform. For big traffic networks (approximately 1000 links), the calculation will take 1-5 sec., depending on the size of the network. An example of the work of the macrosimulation module is shown in Appendix A, Figure Microscopic Traffic Flows Simulation Model in assistance of macroscopic simulation Microscopic simulation module environment. The microsimulation model works within the overall constraints of the Control Strategy Generation Module, Turning Movements Estimation Module and 112

129 Macrosimulation Module. The interconnections between the microsimulation module and the rest of the control system are shown in Figure Microsimulation Model. (several copies running in a distributed environment) Network Communication Component Simulated Traffic Counts, Queues Lengths Network Turning Movements Coefficients Estimation Module Predicted Queues, Discharge Rates etc., Signal Settings Operational Control Generation Control Strategy Generation Module and Operator Interventions Traffic Counts, Queues Lengths Macrosimulation Module Figure 4-14: The microsimulation module The macrosimulation module provides a harness for the microsimulation process in terms of information about traffic counts and queue lengths for any sub-part of the traffic network (i.e. for each copy of the microsimulator) at any moment of the prediction process. The microscopic simulation also accepts additional input from the turning movements estimation module. Finally, the microsimulation module needs a prediction for the traffic light control in response to the predicted traffic flows, i.e. there is the need for an additional operational traffic control task in order to generate the would-becontrols according to the predicted demand. The output of the microsimulation process is predicted queues discharge rates and validated numbers of cars, joining the queue at the stop line during the green light and joining the queue for the duration of the whole cycle. This implementation does not include a Driver Behaviour Model and this project does not investigate the problem. Instead it should be pointed out, that the inclusion of 113

130 such a model can be performed on the basis of the structure of the system presented in Chapter 2 and using the integrated environment described in Chapter 3 of this thesis. It should be noted also, that the microsimulation module could be effortlessly replaced with another microsimulation model, as long as the new microsimulation model conforms to the input/output requirements of the predictive environment. As a consequence of this research, a joint research program is under way for the inclusion of the HUTSIM microsimulation model in the control system. The microsimulation model, implemented under the current research scheme, shares its characteristic with other modern simulation models and introduces in a unique way, a combination of several well known features. The main purpose is to illustrate the potential of the combined work of the microsimulation model and the macrosimulation model within the overall dynamic traffic control system. It relates to the previous systems as follows: (a) It provides individual car simulation (microsimulation), and thus relates to the microscopic models such as TRAF-NETSIM and HUTSIM. (b) It implements horizontal queue estimation and simulation (i.e. all cars arriving at the stop line form a queue with queue length determined by the number of the cars in the queue) as in SCOOT and PACKSIM [Grau, R.; Barcelo, J. 1992a]. Some well known models such as TRANSYT consider all cars in the queue to stay at the stop line i.e. the queue length is not a variable in the internal representation of the network (c) It implements turning movement simulation as in PACKSIM. (d) It provides simulation of a changeable speed of cars in the sections (simple linear car-following model). The microsimulation model as a part of a combined macro- microsimulation model has the following combination of specific features in support of this role: (a) It generates validated output results (number of cars joining queues and discharge rates) which are subsequently used by the macrosimulation model. (b) It requires generating/sinking information for only the boundary nodes of the traffic network from the macrosimulation model to get started (this is a comparatively small amount of data). (c) The traffic network is simulated partially and for each simulated cross-road in the network, a copy of the simulation program is run within the DIME framework and (see [Argile A., Peytchev E., Bargiela A., Kossonen I. 1996]) in a distributed computers environment. 114

131 Traffic Network Description. For the purpose of the traffic network simulation, the physical network is modelled using three basic building blocks: road sections, nodes, and traffic lights. This model is then refined by means of inclusion of some additional information regarding the preferred routes, en-route parkings etc Figure 4-15: Traffic Network Description. Nodes: The nodes represent crossroads, road junctions or the boundary points of the simulated network (or a part of it). A node which delimits the boundary of the simulated network (or a part of it) is labelled as a Boundary Node. The Boundary Node may have one or both of the following features: a random traffic generator representing incoming traffic flow from outside the simulated traffic network (or, alternatively, outgoing from the other part of the network). a sink property representing the traffic leaving the simulated network through this node. The remaining nodes are labelled as Internal Nodes and they are assumed to satisfy the criterion that the balance of traffic flows from the adjoining sections to these nodes is zero. Figure 4-15 illustrates a small network for which the nodes 1,2,4,6,7,8 are the Boundary Nodes, and nodes 3 and 5 are the Internal Nodes. Road sections: Every section connects two Nodes. It can have one or two directions and several lanes in each direction. The description of the section contains all the basic information the simulation might need such as: number of lanes, length, width, max. speed of the vehicles in the section, feasible turns from this section etc. In addition every direction in a section has an associated probability function describing the traffic flow in this direction. 115

132 Traffic lights: Every traffic light is associated with one or more lanes in a particular direction and has a number of corresponding parameters such as split, cycle and offset times specified for it Microsimulation model - main principles. Timing control. The calculations for the new state of the system are produced on a second-by-second basis. In order to accommodate the requirements of a decision support system the simulator has an in-built facility to step ahead of the real time thus producing a tool for what-if types of inquiries from the operator. Vehicle generation Vehicles are generated at the boundary points of the simulated network according to either the functions that were identified through statistical processing of road occupancy measurements or, as it is in the case of simulation within the integrated environment, the generating function obtained from the macrosimulation program. An additional component of distributed generation of vehicles has been included to account for the reactivation of parked vehicles (parkings) or the inflow of traffic from un-modelled junctions in the network. Vehicle simulation Section vehicle movement simulation Every section is divided into three parts: - part A is the part where all the vehicles in the current traffic flow are treated equally, they have no route, they have no knowledge about their next turn (yet). A vehicle can be positioned in any lane of the section according to the speed it has had assigned on entering the section. - part B is the part where the vehicle decides about the next turn (see turning movement rules). The simulator attempts to move each vehicle into an appropriate lane and to progress it with an appropriate speed taking into account the collision detection rules and the speed activation rules as in part A. - part C is the part where the queue is formed. The vehicles are stationary until there is permission for entering the cross-road (green light). The simulation of the movement in the queue is performed according to the rules which are appropriate for a given cross-road. The length of part C of the section varies according to the size of the queue. The remainder of the section is divided between part B - 30%, and part A - 70%. 116

133 Cross-road vehicle movement simulation The number of the vehicles traversing the cross-road is directly related to the dynamics of individual flows and the data provided by the Turning Movements Coefficients Estimation Module. The information provided by the Local Control Generation Module is used to calculate the current state of each traffic light. Traffic lights can be situated at some of the Nodes in the network and they are characterized by: (a) cycle time in seconds (time from one green signal to the next). (b) offset time (time difference between the local green signal and the green signal of the preceding traffic lights. (c) split of the cycle into red, amber and green times. Turning movement rules When a vehicle enters part B of a road section the simulator assigns a turning movement to this particular vehicle. This assignment is performed according to the probability function characterizing the split of the traffic flow from the current section into all of the adjoining sections at the next cross road. Vehicle dynamics The acceleration/deceleration of the vehicles in the simulation model is performed according to the simple linear car-following model V n 1 + ( t + T) = a[ V n () t V n+ 1 () t ] (EQ 4-45) where n is the number of the lead car, n+1 is the number of the follower, T is the time delay and a is the sensitivity coefficient. The model makes use of the results obtained by other researchers [Chandler R.E., Herman R.C., Montroll E.W., 1958] and assumes that T is approximately 1.5 sec. and a is approximately 0.37 sec -1. Exchange data processing Exchange data processing is performed by the simulator once in every loop cycle and it involves storing information about the queue formation and queue dissipation for all links, included in the traffic network considered by the microsimulation model. Subsequently, these validated results are made available to the macrosimulation process within the DIME system. Similarly, the retrieving of the constraints imposed by the macrosimulation model is performed once in every loop cycle and the information obtained includes generating/sinking rates for the boundary nodes of the simulated network. These data are subsequently the starting points of the next microsimulation loop. 117

134 Defining a boundary for the microsimulated traffic network I subsystem II subsystem Figure 4-16: Traffic Network Decomposition - Example. Every part of the traffic network can consist of any number of road sections, nodes and traffic lights. It is recommended, that groups of road sections that share one control strategy (e.g. correspondent to a SCOOT area) should belong to the same subsystem of the network. The actual number of nodes and road sections in a subsystem is a result of an off-line optimization which balances physical size and the traffic volumes in all subnetworks. The sub-networks are connected through Boundary Nodes (Figure 4-16). For the example of Figure 4-16 the network is divided into two subsystems. The first subsystem consists of nodes 1, 2, 3, 4, 5, 8, 10 and the road sections between them, while subsystem 2 consists of nodes 5, 8, 6, 7, 9, 11, 12 and the road sections between them. Nodes 1, 10, 5 and 8 are Boundary Nodes for the first sub-network, while 5, 8, 11, 12 are Boundary Nodes for the second sub-network. Parallel simulation in distributed environment. For the example system in Figure 4-16 two copies of the simulator program are started on two different machines. Each copy reads and renumbers the nodes and road sections of the corresponding subsystem and performs traffic flow microsimulation. The distributed shared memory system, DIME, is used for the data exchange and traffic flow coordination between the two copies of the microsimulator and the macrosimulation process. The correct simulation needs all of the data provided by the simulators to be consistent, which means that the value for the sinking feature for any particular boundary node (calculated as a result of the traffic flow simulation in that specific subsystem) should be equal to the value for the generating feature for the same node for the other subsystem (nodes 5 and 8 in the example): F(5-->7) = F(3-->5) F(5-->3) = F(7-->5) 118

135 F(8-->9) = F(4-->8) F(8-->4) = F(9-->8) The internal representation of the traffic flows (no route is assigned to the specific vehicle) does not require the simulator to track one particular vehicle through all subsystems of the whole traffic network, thus only the information for the sinking and generating of traffic at boundary nodes needs to be exchanged. The amount of this information is very small (four numbers for the example system of Figure 4-16). The microsimulation process reads the sinking/generating information from the DIME system (provided by the macrosimulation process) and subsequently stores, in the same way, the validated information - the result of the microsimulation process Conclusions on microsimulation in support of the macrosimulation process. The microsimulation module described in this chapter, as a part of the proposed structure of the dynamic traffic model system, is capable of running on a sub-part of the network in order to re-evaluate the queue formation and dissipation for the specific part of the overall network. It requires nodes generating and sinking functions only (apart from the physical description of the traffic network) to start the simulation process. In addition, it requires external traffic lights control and turning movements coefficients information. The design of the model reflects the important requirements, which need to be taken into account when considering the combined macro-microsimulation process. The model has to be able to accept constraints from the higher level simulation process (macrosimulation process) and it has to be able to perform simulation within the prescribed traffic flow boundaries, subsequently returning validated parameters to the macrosimulation process. Its suitable traffic flow representation and capability to work within the constraints of the macrosimulation process allows several copies of the microsimulator to be run simultaneously. This makes it suitable for execution in a distributed computers environment. The microsimulation module uses the DIME network communication interface which presents an easy tool for data exchange between the simulation modules within the dynamic traffic model control system. The implementation of the model illustrates the potential of using combined macrosimulation and microsimulation models for traffic queues and traffic density predictions within one traffic control system. 119

136 The novel combination of macrosimulation and microsimulation models resulted in a system where evaluation of the control strategies can be separated between different simulation models. The global control strategy evaluation can be performed mainly on the results of the macrosimulation process, which operates on an extended time scale (in comparison with the operational control). In contrast, the evaluation of the operational control can be done by the microsimulation process - the microsimulation model runs within the constraints of the results of the microsimulation and takes into account the operational control sequences which in turn, are generated in accordance to the global control strategy. The graphical output screen of the microsimulation model, proved to be informative and a clear way of representing the results of the microsimulation process and can be used as a graphical front-end of predictive traffic simulation models. An example of the work of the macrosimulation module is shown in Appendix A, Figure 5. The research envisages the inclusion of more sophisticated models (such as HUTSIM) in the system, therefore developing a fully fledged microsimulation model has been transformed into developing a model showing the potential of the combined simulation Development of a decision support environment to facilitate efficient interaction of the operator with the predictive simulation software - introductory remarks. In the supervisory layer of the dynamic traffic model control system described in Chapter 2. human operators can play an important role and they are irreplaceable components of the control loop. This is illustrated in Figure Human operators monitor the performance of the system and intervene to keep the system in the optimal operating state. Operators intervene either by changing existing control rules, or by overriding them. In the general case, one intervention will contain several correcting actions that come at different time points. Often the operators will have to choose from several alternative interventions. The support software system takes the alternatives as input, and predicts the effect of each alternative on the future state of the system using simulation methods. The operators can then select one of them and instruct the control system to implement it. Inevitably these interventions have to be supervisory layer (high level) interventions, such as opening or closing lanes in a specific direction or closing streets for the traffic flow etc. The existing operational control systems have the notion for such high level interventions, but more research is needed into finding what type of interventions are suitable for the operator to undertake for any specific implementation of the traffic control systems and how these interventions are to be conveyed to the operational control system. 120

137 Control instructions Current & future state Testing alternative interventions Predicted performances Supervisory control interventions Operational Control Monitoring & short term prediction of the state of the control system Prediction Model Supervisory Control Traffic signal controls Real data from the traffic network Supervisory layer of the Traffic Control System In-car route guidance Road-side variable messages Figure Operator s place in the supervisory layer of the real-time traffic control system The development of such an environment can be considered in the context of the supervisory layer of control. It is a huge and complex task, which requires research efforts from researchers working in different areas. The first challenging issue in on-line predictive control environments concerns devising suitable means for operators to specify interventions. The specification language should be rich enough to describe the complexities of the domain, and at the same time it should be appropriate for the skill profile of the operators. Indeed, the operators are not expected to be computer specialists nor operational research scientists, and so the language should not be oriented towards programming and/or mathematical modelling and simulation. Instead it should tap into the domain expertise of operators by providing them with task-specific constructs. Clearly this is an area for future research and the 121

138 researcher has to be a qualified specialist in the development of end-user systems using visual (graphical) domain-oriented languages. The second challenging issue in on-line control simulation environments is the potential for cognitive overload of the operators. Operators should work within two contexts: a control context, where they observe the current and predicted state of the system and control it by specifying interventions; a simulation context, where operators specify a range of interventions and obtain feedback about predicted results. In their work, operators will have to often switch between the two contexts, and this is likely to cause a cognitive overload for them. One possible way forward is to rely on the software taking over some of the operator's tasks, possibly using artificial intelligence techniques. The overloads mentioned above require rethinking of the information screens available to the operator to enquire for the state of the system. The work performed for this research concentrates on the calculation of the future state of the traffic control system and presenting this information to the operator. The Distributed Memory Environment (DIME), described in Chapter 3, offers a natural software framework for the development of supervisory control schemes by facilitating the concurrent execution of multiple copies of the simulation and other decision support software. As a complementary research strand this project undertook the development and evaluation of a representative set of user interfaces for the supervisory layer of control. Subsequently, the first step in developing such a software environment was to build a graphical representation of the traffic network on the computer screen. The editor currently used is the traffic map editor TEDI developed at the University of Barcelona, Spain [Grau, R.; Barcelo, J. 1993]. Using this editor, the whole map of Mansfield has been drawn and access to the map information has been provided by GETRAM - a software package for reading and writing the traffic maps created by TEDI [Grau, R.; Barcelo, J. 1993]. This work provided useful graphical representation of the network map of Mansfield and the next stage in the development of the software was to superimpose the queue lengths on top of the map. The GETRAM/TEDI software uses X11 graphics libraries, thus providing compatibility of graphics across UNIX. The existing GETRAM libraries for Windows provide compatibility with the Windows platform. With adopting the X11 standard as a basis for the GUI software, this project has developed a flexible graphics library that implements the main ideas of the Graphic Kernel System (GKS). 122

139 Design and implementation of GKS (Graphic Kernel System) for displaying operator s information The X environment. The X Window environment is a software environment for engineering workstations. It offers a rich and complex environment to the programmer and user of the application software. The foundation of X is the base window system. The overall X environment consists of layers upon the base window system, which is illustrated in Figure X application programs ordinarily do not use the network protocol directly, but rather work through a programming interface. A C-language subroutine package known as Xlib is provided with the X-Window system for the purpose of letting the applications Window Session Managers High-level X Toolkit Application Low-level Programming interface (Xlib) X Network Protocol Base Window System Figure The X window concept. interface to the network protocol and to the base window system. Most applications use a high-level X toolkit to mask some of the complexity of the network protocol and to gain additional functionality. As a result, the user s interface to the workstation is the combination of the capabilities provided by the base window system, the X toolkit, the window and session managers and the application program. This section of the thesis describes the GKS package implemented as an X toolkit for use in a workstations network environment The GKS - introduction. The Graphical Kernel System (GKS) for computer graphics was published as an international standard by ISO in The standard defines a graphical system which supports a wide range of drawing functions independent of the programming language or hardware. Although defined in a language independent manner, the drawing functions have to be realized as library calls in a programming language known in GKS terminology as the language layer. The thesis outlines such a language layer implementation for a sub-set of GKS, which has been developed as an X toolkit to be used for building graphical displays in a real-time traffic control system. The library is currently provided for the C language. The sub-set is not a full GKS implementation, 123

140 due to the limited time and resources, but all important graphical subroutines are included. Thirty five functions provide graphic drawing functions that can be displayed on X-terminal clients such as workstations or an IBM PC-compatible clients running Exceed. The functions provide the ability to draw lines, boxes, circles and text, and receive input from mouse or menus Coordinate Systems. Coordinate systems can be confusing in GKS, therefore a reasonable understanding of the GKS approach to transformations will be helpful to users. GKS has three coordinate systems. The world coordinate system (WCS) is the system that the application programmer uses for specifying pictures in the program s world i.e. what is being modelling. This could be thought of as a user coordinate system. So for example, a user may want to model a building, where all coordinates are defined in millimetres, or a plot graph of temperatures and time in which coordinates are in the range 0-32 for centigrade and 1-12 for months. World coordinates: A device independent Cartesian coordinate system used by the application program to specify graphical input and output. Every different type of output device will have a different device coordinate system, e.g. a PC with 600 * 400 pixels or a Tektronix 4010 with and pixels. Some devices do not place the origin in the left hand bottom screen corner. To overcome this variety of device coordinate possibilities, GKS has the concept of one single normalized device space called Normalized device coordinates (NDC). The relative positioning of the output primitives is defined by mapping all of the defined world coordinates into NDC space. Normalized device coordinates - Device independent intermediate coordinates system, normalized into the range 0 to 1.0. The NDC space is mapped onto the device coordinate (DC) system of every computer screen asked to display the picture. Device Coordinate - A device dependent coordinate system. The DC unit is normally one metre on a device that supports precise scaling. If not, an appropriate device dependent unit can be chosen, e.g. pixels. In order to display a picture the applications programmer must map all the world coordinates onto the single NDC space. This is the normalization transformation. A 124

141 further set of transformations maps the NDC space onto every active workstation. Figure 4-19 shows the transformations. Application Program normalized picture Workstation Normalization Workstation Transformation WCS NDC DC Figure GKS Coordinate systems. A normalization transformation is specified by defining the limits of the area in WCS (window) which is to be mapped onto a specified area of the NDC square (viewport). Figure 4-20 shows this WCS space W1 NT1 V Figure 4-20Normalization Transformation NDC Space A number of normalization transformations can be performed. The application can request that GKS only shows those parts of the picture that lie within the viewports associated with the picture. Cutting outside the viewport is called clipping. For every open workstation the application can independently select any part of NDC space within the unit square (0.0 to 1.0) to appear anywhere on the workstation screen. This is known as the workstation transformation and maps NDC to DC. 125

142 YWMAX XVMIN XVMAX (XW,YW) (XV,YV) YWMIN XWMAX XWMIN World Coordinates Figure Aspect ratio transformations. Normalized Coordinates Whereas the normalization transformation is used to compose a picture, the workstation transformation is used to allow different aspects of the composed picture to be viewed on different workstations. A workstation transformation is defined by specifying the limits of the area in NDC system in the range (0.0,0.0) x (1.0,1.0) (workstation window) which is to be mapped onto a specified area of the DC system (viewport). W1 NT V1 WT WV WCS Space WW Workstation DC Space Legend: Figure 4-22Normalization transformation and workstation transformation W = Window, V = Viewport, NT = Normalization Transformation, WW = Workstation Window, WV = Workstation viewport, WT = Workstation transformation. 126

143 The workstation window is defined in terms of the unit square i.e. coordinates in the range 0.0 to 1.0 and the viewport is defined in terms of the device coordinates. Note that in GKS there is no constraint to ensure that the aspect ratio of the viewport is the same as the aspect ratio of the window. Consequently, a tall thin house can be mapped to a squat house. See Figure GKS - user application interface specification. The GKS package must be first initialised using void g_initialise (int argc, char *argv); where argc and argv are the standard C language on-line parameters. The creation, deletion, activation etc. device operations are performed by the following functions: void g_opxdev (int Device, long Device_type, char *Name, long X_Size, long Y_Size, long X_Start, long Y_Start); void g_clxdev (int Device); (close device) void g_acxdev (int Device); (activate device) void g_daxdev (int Device); (delete device) void g_clrxdev (int Device); (clear device) where Device is the device number, Device_type is the type of the device, Name is its name, X_Size and Y_Size are the dimensions of the device respectively for x and y, X_Start and Y_Start define the left bottom corner of the DC window. To define a workstation to viewport mapping which defines which part of NDC space will be as seen at the workstation and where, GKS uses void g_defview (int View, float XminWorld, float YminWorld, float XmaxWorld, float YmaxWorld, double XminNormView, double YminNormView, double XmaxNormView, double YmaxNormView, int MaintainAspectRatio); void g_newview (int View); where View is the view number, XminWorld, YminWorld, XmaxWorld, YmaxWorld are the real dimensions of the picture to be drawn onto the screen and XminNormView, YminNormView, XmaxNormView, YmaxNormView are the dimensions of the normalised view, which will correspond in the transformation process to the real dimensions. MaintainAspectRatio can be True or False and determines if the ratio of the Y-coordinate has to be the same as the ratio for the X_coordinate in the normalisation process. 127

144 The graphics information is displayed on the screen by using one of the following functions: void g_num (float X, float Y, int DigitsNumber, int MantissaDigitsNumber, float Number); (display number) void g_text (float X, float Y, char *Text); (display text) void g_circle (float X, float Y, float Radius); (draw circle) void g_block (float X_LeftUp, float Y_LeftUp, float X_RightBottom, float Y_RightBottom, int Colour); (draw block and fill it with colour) void g_rect (float X_LeftUp, float Y_LeftUp, float X_RightBottom, float Y_RightBottom); (draw rectangle) void g_line (float X_Start, float Y_Start, float X_End, float Y_End); (draw line) void g_polyline (int PointsNumber, float[] X_Array, float[] Y_Array); (draw polyline) void g_settxf (int FontNumber); (set text font) void g_setlt (char * LineType); (set line type: solid, dashed etc.) void g_defcol (int ColourNumber, float Red, float Green, float Blue); (define colour) void g_selcol (int Colour); (select foreground colour as the current colour for drawing) void g_selback (int Colour); (select background colour as the current colour for drawing) void g_rqlc (int Device, float *X, float * Y); (request left mouse button click coordinates) void g_setlc (float X, float Y); (set mouse position coordinates) void g_rqch (int Device, float X, float Y, char *MenuTitle, int NumberMenuItems, char *MenuStrings, int *Choice); (request menu choice, the menu is displayed on the screen and the number of the chosen row is returned in Choice) void g_setlw (int Width); (set line width for drawing) void g_setwm (int Mode); (set window raster mode for drawing e.g. Copy, Xor etc.) void g_fillarc (float X, float Y, float Radius, float StartAngle, float EndAngle); (draw and fill arc with the current colour) void g_fillcircle (float X, float Y, float Radius); (draw and fill the circle with the current colour) void g_flshxdev (int Device); (perform all pending operations for the specified device) 128

145 int g_rqevent (int Device, long int *EventType, float *X, float *Y); (request event from the screen. The event type will be returned in EventType, X and Y contain the coordinates of the event) void g_fillblock (XPoint *Points, int PointsNumber, int Colour); (draw a block and fill it with the specified colour) void g_defxscrollbar (int Device, float ScrollBarHeight, float X_WidthMin, float X_WidthMax); (define a horizontal scrollbar for the device, specifying the height and where it starts and ends) void g_defyscrollbar (int Device, float ScrollBarWidth, float Y_HeightMin, float Y_HeightMin); (define a vertical scrollbar for the device, specifying the width and where it starts and ends) void g_updatexscrollbar (int Device); (update the appearance of the scrollbar for the specified device) void g_updateyscrollbar (int Device); (update the appearance of the scrollbar for the specified device) void g_destroyxscrollbar (int Device); (destroy the horizontal scrollbar for the specified device) void g_destroyyscrollbar (int Device); (destroy the vertical scrollbar for the specified device) The graphical front end of the simulation model has been successfully implemented using the GKS package and all images in Appendix A have been produced in both an X11 environment and in a PC-compatible Windows 95 environment using the Exceed software package Conclusions. The macrosimulation model described in this thesis has been shown to have potential for application in predictive traffic control schemes. The evaluation of the model on the real traffic flows data confirms that the state-space formulation, with link dependent discrete time, provides an adequate means for the modelling of macroscopic traffic evolution. It is expected that the accuracy of the macrosimulation model will be enhanced by the inclusion of previous day terms in the ARMA model for the estimation of boundary inflows. The current model provides also a baseline against which this research intends to assess the impact of the adopted simplifying assumptions, in particular, the impact of the assumption about the distribution of the traffic density along the link. In the current context, the model recognises two ways of calculation of the number of cars joining the queue at the stop line: uniform distribution, where the number 129

146 of cars joining the queue at the stop line is proportional to the duration of the green light in the corresponding direction (EQ 4-39), and a distribution where all cars entering a given link are thought to be moving in a group, which will join the queue in the next cycle, i.e. a lump distribution (EQ 4-41). It is anticipated, that by providing areas of different traffic density along the street (corresponding to the number of cars entering a given link during a cycle) together with investigation of the traffic density within the defined area, the movement of the cars will be presented with more accuracy. This novel mathematical model is designed and implemented as part of a supervisory layer of control for real-time traffic control systems. It works on a different time scale to the existing operational traffic control systems. It is capable of simulating and predicting queue lengths and traffic densities for a period of time up to 30 min. in accordance with externally provided traffic controls. The model can be used for evaluation of traffic control strategies (not to be mistaken with operational control optimisation). 130

147 Chapter 5. TURNING MOVEMENTS ESTIMATION MODEL The estimation of dynamic origin-destination (O-D) matrices from traffic counts in a transportation network has received increasing attention over the past two decades. Conventionally, O-D flow matrices are considered only for a certain time period of interest, and thus are estimated with the average traffic count data of that period [Chang G., Wu J., 1994]. A comprehensive review of research along this line has been presented by [Nguyen S., 1984] and [Cascetta E., Nguyen S., 1988]. Such methods are static in nature, relying on some prior O-D information and/or presume driver behavioural rules to produce a reasonable result. To extend the O-D estimation methods in a dynamic system environment, some researchers [Cremer M., Keller H. 1981], [Cremer M., Keller H. 1984], [Nihan N., Davis G., 1987] proposed the use of time-series analysis of traffic counts data to formulate the relationships. [Nihan N., Davis G., 1987] and [Cremer M., Keller H. 1987] have, respectively, presented a family of O-D estimation models for intersections or small networks based on the prediction-error minimisation methods. Since the dynamic traffic model system, presented in Chapter 2 of the present thesis includes a simulation model (Chapter 4), that uses turning movements estimates for intersections only, the models for O-D matrix estimation have to be formulated and validated for small networks or intersections only. A common feature of these models is that traffic flow through a traffic detector is considered to be a dynamic process in which O-D flows and exit flows are timedependent variables which depend on causal relationships for the time-variable patterns of entrance flows [Cremer M., Keller H. 1987] Dynamic Estimation of Origin-Destination Traffic Flows Problem formulation. To derive a mathematical model for the dynamic process of O-D flows through a traffic facility, a complex intersection with m entries and n exits will be considered (see Figure 5-1 for an illustration of O-D flows for a 4-way intersection). With regard to Figure 5-1, the following variables are introduced as discrete time functions: N ( c) i - volume which leaves entrance i during time interval ( c 1) T t< c T 131

148 B j ( c) - volume which leaves the intersection through exit j during time interval ( c 1) T + τ t< c T+ τ, where j = 1, 2, n φ ( c) ij - that part of volume N i ( c) which leaves the intersection through exit j during time ( c 1) T + τ t < c T+ τ 3 B 3 N 3 φ, φ, φ 43, 13, 23, 4 N 4 B 4 φ 3 4, φ 2 4, φ 1 4, φ 32, φ 42, φ 12, 2 B 2 N 2 φ, φ, φ 41, 31, 21, B 1 N 1 1 Figure 5-1: Topology of a 4-way intersection with O-D flows. Here T is a sampling interval defining short measurement periods. For any intersection, this interval should be chosen to be only a few minutes in order that the time variations of the volumes are expressed representatively [Cremer M., Keller H. 1987]. The parameter τ denotes the average travel time a vehicle needs to pass from an entry to an exit. Taking the balance of the departing and entering vehicles gives, for each time interval, B j ( c) = φ ij ( c) i Ω j (EQ 5-1) 132

149 since each O-D flow movements coefficient φ ij m ij ( c) ( c) is a certain portion of the entering flow, a new turning can be introduced φ ij ( c) = N i ( c) m ij ( c) (EQ 5-2) where the parameters m ij ( c) are bounded by the inequality condition for all i, j, c. (EQ 5-3) and must satisfy by the law of conservation of vehicles (since there is no queuing inside the intersection) 0 m ij ( c) 1 s ( c) = 1 m ij j = 1 for all i, c. (EQ 5-4) Assuming further that no car makes a U-turn at the intersection we have an additional condition m ii ( c) = 0 Substituting (EQ 5-2) into (EQ 5-1) gives for all i. (EQ 5-5) b j ( c) = n i ( c) m ij ( c) i Ω j for all j, c. (EQ 5-6) Introducing the 1 s row vector b' ( c) with elements b j ( c), the 1 r row vector n' ( c) with elements n i ( c) and forming r s matrix M ( c) from the elements m ij ( c), (EQ 5-6) can be rewritten for all indices j in compressed form as Equation (EQ 5-7) establishes a simple dynamic and causal model which describes how the entering flows ( c) of a facility are split into individual O-D flows φ ij ( c) which in turn are combined to the resulting exit flows ( c). It can be seen that equations (EQ 5-4) and (EQ 5-5) provide only r + s + min (r, s) - 1 (EQ 5-8) linearly independent equations for the r s unknown turning movements coefficients m ij N i b' ( c) = n' ( c) M ( c) (EQ 5-7). Thus, already for intersections with three or more entry and exit ports, this is an under-determined problem which allows a multiplicity of solutions. The solution is to consider an observation period of C sampling intervals and introduce the following mean values: b j 133

150 (EQ 5-9) Furthermore, b' ( c), n' ( c) and M ( c) can be represented as the sum of their mean and a (random) deviation b ( c) n ( c) M ( c) C 1 = --- C b' ( c) c = 1 C 1 = C --- n' ( c) c = 1 C 1 = --- C M' ( c) c = 1 b' ( c) = b' + b' ( c) n' ( c) = n' + n' ( c) (EQ 5-10) Inserting this into the model (EQ 5-7) gives or (EQ 5-11) It can be easily shown by the definition of M ( c) (EQ 5-9) that the mean turning movements coefficients ( c) must meet the restrictions of (EQ 5-3), (EQ 5-4) and (EQ 5-5), too. Following the above definitions and equation dependencies, the problem of estimating the origin-destination pattern of a facility can be formulated in the following way [Cremer M., Keller H. 1987]: M ( c) = M + M ( c) b' ( c) = n' ( c) ( M + M ( c) ) b' + b' ( c) = ( n' + n' ( c) ) ( M + M ( c) ) m ij It is assumed that (EQ 5-11) is a representative model for the timevariable flows through a traffic facility. It is assumed further that the sequences ( c) and b j ( c) of flow samples at the entries and the exits n i of the facility are given by measurements. Then find from this information estimates for the mean values of the unknown O-D flows ( c) or equivalently for the mean values of the turning movements coefficients ( c) satisfying the conditions (EQ 5-3), (EQ 5-4) and (EQ 5-5) m ij Taking the mean on both sides of (EQ 5-11) over a whole observation period it can be written (since n ( c), b ( c) and M ( c) have zero mean) φ ij b' = n' M C C n' ( c) M ( c) c = 1 (EQ 5-12) 134

151 Now it can be assumed that the sequences of deviations n ( c) of the entry flows and the sequences of the variations ( c) are un-correlated. If the measurements are averaged for more than 5-7 sampling intervals C, the summation term on the right side of (EQ 5-12) becomes rather small and can be neglected, therefore the new equation is (EQ 5-13) If the traffic counts measurements are taken of the whole observation period as it is assumed for the static procedures, the unknown matrix M has to be determined from this equation together with the conditions (EQ 5-3), (EQ 5-4), (EQ 5-5) formulated for the mean values m ij. Since this is an under-determined set of equations (see (EQ 5-8)), there is a necessity for additional equations, if a solution, acceptable in the traffic control domain, is needed. To illustrate that partitioning the observation period into subsequent time intervals and using time sequences of traffic counts provides additional information, the equation (EQ 5-12) is subtracted from (EQ 5-11), formally substituting the summation index c in (EQ 5-12) by l. This gives m ij b' = n' M b' ( c) = n' ( c) M + 1 n' ( c) M ( c) C --- n' () l M () l C l = 1 (EQ 5-14) deterministic term random noise term The expression on the right hand side of the equation may be divided into two terms. The first term provides the additional deterministic information for the unknown matrix M while the second term represents a disturbing random noise term. Assuming that the input volumes are partitioned into the corresponding O-D flows by strictly constant turning movements coefficients m ij, i.e. assuming m ij 0 (with this assumption O-D flows are not integer values any more). Then the random noise term in (EQ 5-14) vanishes and (EQ 5-14) can be written for subsequent time intervals in matrix form as (EQ 5-15) This matrix equation can be solved uniquely for the unknown matrix M if a set of r linearly independent rows n' ( c) can be found within the brackets on the right hand side. In this case the matrix b' ( 1) b' ( 2) b' ( C) n = n' ( 1) n' ( 2) n' ( K) M is determined by inverting the linear matrix equation (EQ 5-15). This condition is equivalent to the requirement that none of the variations 135

152 n i n j ( c) ( c). is totally correlated with any linear combination of the other variations The basic idea of the dynamic methods, first presented by [Cremer M., Keller H. 1987], is to utilize by appropriate techniques the deterministic information contained in (EQ 5-14) while reducing the detracting effect of the noise term Least squares estimation involving cross correlation matrices. In reality, the deviations of the actual turning movements coefficients will be non-zero, which means the random noise terms on the right hand side of (EQ 5-14) are generally nonzero, but unknown. Because of those noise terms, (EQ 5-15) becomes inconsistent when real measurements b ( c) and n ( c) are inserted and C exceeds r. In other words, there is no constant matrix M which generates the exit flow sequences b ( c) when multiplied by the entry flow measurements n ( c). Since the statistical expectation of the noise term is zero under the assumptions as made above, it is reasonable to seek a solution Mˆ of the inconsistent, contradictory (EQ 5-15) which minimizes the squared equation error. According to well-known results in the theory of linear equations [Todd J., 1977], such a solution Mˆ, which serves as an estimate for the real mean m ij ( c) M, can be calculated in the following manner: First introducing the abbreviations b' ( 1) n' ( 1) b' ( 2) n' ( 2) B =, N= (EQ 5-16) b' ( C) n' ( C) then a least square error solution to (EQ 5-15) is given by Mˆ = ( N'N) 1 N' B (EQ 5-17) This solution is regarded as an ordinary least squares (OLS) estimation method applied to (EQ 5-15). Now it is easy to show that the following holds: N'N C = n ( c) n' ( c) = C Φ nn c = 1 (EQ 5-18a) Φ nn N'B Φ nb C = n ( c) b' ( k) = C Φ nb c = 1 (EQ 5-18b) where and are the finite interval cross-correlation matrices correlating the sequences n ( c) with n ( c) and n ( c) with b ( c), respectively, over the 136

153 observation period c = 1, 2, C with this notation the equation (EQ 5-17) can be rewritten in the form Mˆ 1 = Φnn Φ nb (EQ 5-19) The equation can be interpreted loosely in the following way: an estimate for the m ij turning movement coefficient is computed by picking out that part of the leaving sequence b j ( c) which is correlated with the sequence n i ( c) of arrival counts at port i and relating it to the auto-correlation function of ( c). To analyse the quality of the estimated matrix Mˆ as calculated from (EQ 5-19), the same procedure can be applied for solving (EQ 5-15) for the real matrix of mean turning movements coefficients M : n i M 1 = Φnn 1 1 Φ nb + C ---Φ nn C c = 1 n ( c) ( n' + n' ( c) ) M ( c) (EQ 5-20) (the summation term within the random noise term in (EQ 5-14) vanishes when it is multiplied by n ( c) and summed up over the period of K intervals). Subtracting (EQ 5-19) gives the estimation error ( M Mˆ ) = 1 C Φ nn C c = 1 n ( c) ( n' + n' ( c) ) M ( c) (EQ 5-21) Taking into account that the sequences n ( c) and M ( c) are assumed to be uncorrelated, it can be shown from this equation by taking the expectation on both sides that the expectation of the estimation error becomes zero, i.e. (EQ 5-19) yields bias-free estimates. Additionally, it can be concluded from (EQ 5-21) that co-variances of the estimation error are declining as C increases. Thus better estimates can be expected for longer observation periods. However, when slow drifts of the mean split pattern M are to be expected too long an observation period will be detrimental again. It should be noted, that this procedure does not automatically satisfy conditions (EQ 5-3), (EQ 5-4) and (EQ 5-5) for the estimates. The static relation (EQ 5-13) may be included as an additional equation and then it is fulfilled only approximately. As far as the computational effort is concerned, the procedure requires inverting a matrix of size s s, where s is the number of entries of the facility. This task can be easily performed by a non-high performance computer. mˆ ij 137

154 Constrained optimization method. This approach involves using the conditions (EQ 5-3), (EQ 5-4) and (EQ 5-5) as additional specifications for the solution. The first step is to set up a deterministic model for the intersection in the form of equation (EQ 5-7), b' ˆ ( c) = n' ( c) Mˆ (EQ 5-22) where Mˆ is an estimate for the unknown mean turning movements coefficients matrix M. Using the samples of entering counts n ( c), the model generates estimates bˆ ( c) for the exit flow sequences on the basis of the estimated turning movements coefficients Mˆ. Taking this into consideration, the problem can be formulated as a constrained optimization problem [Cremer M., Keller H. 1987]: Given the sequences ( k) and b j ( k) of flow samples at the entries and exits of an intersection over a period of C sampling intervals, find a matrix Mˆ of estimates for the turning movements coefficients which minimizes the sum of the squared error between the exit flows of the model and the measured exit flows n i J = C C n ( c) nˆ ( c) c = 1 2 min Mˆ (EQ 5-23) where the estimates mˆ ij have to fulfil conditions (EQ 5-3), (EQ 5-4) and (EQ 5-5) and optionally the static balance equation (EQ 5-13). This formulation establishes a so called constrained ordinary least squares (COLS) estimation problem. A solution of this problem may be calculated using any well-known parameter optimization routine which is able to handle constraints in the form of linear equalities and inequalities Simple recursive estimation. It is a common feature of the two methods described before that they have to use data from a past observation interval of C sample periods where C should be over 7. Since each time interval contributes some partial information to the estimation process, one logical approach is to use the measurements of each sampling interval to improve the estimation in a step by step process. Such a single step procedure can be expected to be more flexible in tracking a changing O-D pattern since former measurements will have a fading influence on the actual estimates. 138

155 This method was developed and presented for the first time by [Cremer M., Keller H. 1981]. The formula considers the deviations b ( c) and n ( c) of counts with their mean values as obtained from an arbitrary interval. At the start of the estimation, the formula uses for the first step an estimate for the turning movements coefficients matrix Mˆ ( 0) which may be taken from preceding investigations or may even be selected arbitrarily. Then the general c th step is carried out as follows: Based on the estimation of the (c-1) th step the predicted exit flows deviations are computed from the measured entry flow deviations by a model similar to (EQ 5-22) (which is actually the deterministic part of (EQ 5-14)) b' ˆ ( c) = n' ( c) Mˆ ( c 1) (EQ 5-24) This prediction is then inserted into the following recursive correction formula: mˆ ij ( k) = mˆ ij ( c 1) + γ n i ( c) [ b j ( c) b' j ( c) ] (EQ 5-25) where γ is a gain factor which has to be chosen appropriately. It has to be pointed out that for the estimation of m ij ( c) entering flows n i ( c) of all entries have to be measured to compute the prediction bˆ j ( c) according to (EQ 5-24), yet only the exit flow b at the j th j ( c) exit has to be known. There are several main points which need mentioning in order that the way the estimation formula works may be explained. (a) mˆ ij ( c 1) = mˆ ij ( c) for i = 1,, r represents an equilibrium point since in this case the prediction error b j ( c) bˆ j ( c) is zero and mˆ ij remains unchanged. (b) If mˆ ij ( c 1) < m ij ( c), for a positive entry flow deviation n i ( c) > 0 the prediction for the deviation bˆ j ( c) may become too small bˆ j ( c) < b j ( c). The second term on the right side of equation (EQ 5-25) then will increase the new estimate mˆ ij ( c) accordingly. A similar argument holds if mˆ ij ( c 1) exceeds ( c) or if n i is negative. (In reality this reasoning is correct only mˆ ij in the statistical mean because of the superposition of the influences of all n i ( c).) This shows that correction is performed in the right direction. 139

156 (c) Applying the recursion formula to a sequence of C subsequent time intervals gives Here m is the j th j ( c) column of matrix M ( c) containing all turning movements coefficients, which are related to the j th exit flow. Now ( c) is defined to be the statemˆ ij ( C) = m ij ( O) + γ C C C n i ( c) ( n j ( c) bˆ j ( c) ) c = 1 (EQ 5-26) where the term within the brackets represents the cross-correlation function between the flow deviations n i ( c) at entry i and the prediction error of flows at exit j [(EQ 5-18a) and (EQ 5-18b)]. This means that in the temporal average only that part of the prediction error contributes to a correction of mˆ ij which is correlated with n i, i.e. which results from a difference between and the real mean value. Because the new estimate of the turning movement coefficient is computed by correcting the old value, (EQ 5-25) has the signal flow structure of a feedback loop. This gives rise to the question whether the formula is stable and the loop gain γ affects stability. The consideration of stability and convergence of the recursive estimation formula leads to the following assumptions: mˆ ij m ij (a) The expectation values of the fluctuations n i and are zero. (b) The deviations of different sampling intervals are statistically independent and mˆ ij m ij deviations of entry flows n i and of turning movements coefficients are statistically independent too. m ij Under these assumptions which may be considered to be fulfilled in most applications, it was shown that the recursive formula (EQ 5-25) gives bias-free estimates which converge to the real mean values of [Arnold L., 1972]. m ij Estimation by Kalman filtering (after [Cremer M., Keller H. 1987]). Another recursive estimation scheme can be designed using the technique of Kalman filtering. In order for this to be done a reformulation of the problem is needed. Let us consider a subsystem of all O-D flows adding up to the j th exit flow [see (EQ 5-1)] b j r ( c) = n i ( c) m ij ( c) = n' ( c) m j ( c) i = 1 which is nothing else but the j th row element of (EQ 5-7). (EQ 5-27) m j 140

157 vector of the j th subsystem. Dynamic transition of this state-vector may be described by the state equation m j ( c+ 1) = m j ( c) + w ( c) (EQ 5-28) where covariances w ( c) is an input vector of random noise terms with zero means and known E { w ( c) } = 0 (EQ 5-29) E { w ( c) w' () l } = W for c = l { 0 for c l (EQ 5-30) Information about the state variables is given by the measurements of the j th exit flows which are related to the m ij ( c) by the equation above, which may contain a random term Ψ ( c) accounting for measurement errors. The measurement output equation then is with b j ( c) = n' ( c) m j ( c) + Ψ( c) E { ψ ( c) } = 0 (EQ 5-31) (EQ 5-32) Subsequently, the estimation for the unknown turning movements coefficients is performed by the set of equations, which establishes the Kalman filter. The filter equations compute bias-free, minimum variance estimates, if the system is completely observable. In this case the full set of assumptions are not completely met since the constraints (EQ 5-3), (EQ 5-4) and (EQ 5-5) have been ignored. Therefore, it can be expected, that the estimates will be not necessarily optimal, but will have minimum variance. As in the other cases the constraints may be introduced by normalizing the results after each time interval thus improving the estimates Estimation of turning movements in PRODYN. PRODYN is a french real-time urban traffic control system developed by CERT and assessed on ZELT experimental field tests in Toulouse [Kessaci A., Farges J.L., Henry J.J., 1989]. It is based on Dynamic Programming sub-system optimization and on Decentralised Coordination. The real-time optimization is implemented on a rolling horizon and state variables like queues are estimated by Bayesian techniques. The algorithm, presented in this paragraph, estimates turning movements parameters using data from existing magnetic loop censors. The formulation of the problem follows the formulation presented by [Cremer M., Keller H. 1987]. 141

158 [Kessaci A., Farges J.L., Henry J.J., 1989] consider an intersection with r entries and s exits. The model introduces the following variables: n c i - volume which leaves link i during time interval ( c 1) T t < c T. for i = 1,, r. b c j - volume which leaves the intersection through exit j during time interval ( c 1) T + τ t< c T+ τ, where j = 1, 2 s. m c ij - the turning movement ratio of which leaves the intersection i through exit j during time ( c 1) T t < c T. These parameters satisfy the constraints presented as (EQ 5-3), (EQ 5-4) and (EQ 5-5) and reformulated as n c i ij 0 m c 1 for all i, j, c. (EQ 5-33) s ij m c i = 1 = 1 for all i, j, c. (EQ 5-34) Assuming further that no car leaves the intersection through the same port it has entered gives an additional condition m c ii = 0 for i = 1, 2 r. (EQ 5-35) These equations use c as a time index and T as a variable sampling time interval corresponding to the greens and intergreens periods for the stages of the intersection. The assumptions made in the model are (a) Each vehicle that has already entered into the junction during the period T will leave the junction during the same period, reflecting the requirement: r i n c i = 1 = s j b c j = 1 (i.e. the sum of all input flows is equal to the sum of all output flows). n c i (EQ 5-36) (b) All relevant data (input data flows and output flows ) are present in the system, measured by appropriate sensors. For each time period [ ( c 1)TcT, ] the following equation can be written: b c j b c j = r ij i m c nc i = 1 + δ c j (EQ 5-37) 142

159 where r is the number of entries for the intersection, and is a measurement noise which has zero mean and known covariance. In a matrix form the equations can be rewritten as: δ c j b c = M c n c + δ c Z EM c = 0 (EQ 5-38) (EQ 5-39) M c 0 (EQ 5-40) where b c is an ( s 1 ) vector of exit flows j b c, M c an ( s r ) matrix of turning movement ratios (excluding U-turns) ij m c, n c a ( r 1 ) vector of corresponding entrance link flows, Z an r 1 unity vector and E an ( r s) matrix with 0 and 1 elements. It is clear that (EQ 5-38) and (EQ 5-39) do not give enough relations to determine the m c ij parameters for a single sampling interval c, even if the noise is assumed to be null. In order to reach the solution [Kessaci A., Farges J.L., Henry J.J., 1989] minimise a quadratic criterion with respect to constant turning movements ratio of C sampling intervals: δ c j M C, over a period 1 min-- M 2 ( S c U c M c ) T 1 Λ c ( S c U c M c ) c Z EM c = 0 (EQ 5-41) (EQ 5-42) M c 0 (EQ 5-43) 1 where S c is an ( 1 C ) vector of b c, U c is an ( 1 C ) matrix of n c and Λ c an ( C C ) positive Σ 1 block diagonal matrix (the noise vectors are assumed to be not correlated). In order to derive a solution of the problem [Kessaci A., Farges J.L., Henry J.J., 1989] consider first the minimization problem with equality constraint (EQ 5-42) and (EQ 5-43) and subsequently apply the standard recursive least squares algorithm Choice of traffic turning movements coefficients estimation model. The constrained optimization procedure (the method for turning movements coefficients estimation used in PRODYN) has the advantage that all constraints and additional conditions may be included and, in that way, fulfilled by the procedure directly. In this way all available information is used. However, the application of parameter optimization methods leads, depending on the number of free parameters, to a considerable computational effort. While the estimation by the other methods takes a few seconds, the application of this method may require several minutes to get a solution for a medium size problem. Thus, the method seems to be better suited for off-line 143

160 applications in the design and analysis of traffic facilities rather than for on-line applications in the field. The computational requirements of the recursive formula method and the method using the Kalman filter are the lowest. This makes them suitable for on-line applications at the measurement site, using relatively inexpensive mid-range computers for the purpose. However, the quality of the estimates, especially in the case of real data, is slightly reduced [Cremer M., Keller H. 1987] in comparison with the other methods. Considering the above mentioned findings, it can be concluded that, although all methods give promising results, the only method, which is all-round suitable for the online turning movements estimation, is the least squares estimation using cross-correlation matrices (section ). Another important consideration, that has to be taken into account, is the fact that only this method is capable of producing results in an insufficient traffic counts information environment, while the rest require a full set of measured entry/ exit flows. Additionally, new independent equations, based on the stage information contained in the on-line information supplied by the real-time traffic control system can be easily added in the model, giving it increased robustness Turning Movements Estimation Models using insufficient traffic counts information: PADSIM estimation model Algorithm description. The algorithm, adopted in this research, estimates turning movements coefficients using the cross-correlation method described in paragraph The formulation of the problem follows the formulation presented by [Kessaci A., Farges J.L., Henry J.J., 1989] and considers an intersection with r entries and s exits. The notation in the model uses the following variables: n c i - volume, which enters entrance i during time interval ( c 1) T t < c T. for i = 1, 2, r. b c j - volume, which leaves the intersection through exit j during time interval ( c 1) T + τ t< c T+ τ, where j = 1, 2, s. m c ij n c i - the turning movement ratio of, which leaves the intersection through exit j during time ( c 1) T t < c T. 144

161 These parameters satisfy the constraints presented as (EQ 5-3), (EQ 5-4) and (EQ 5-5) and presented by [Kessaci A., Farges J.L., Henry J.J., 1989] as ij 0 m c 1 for all i, j, c. (EQ 5-44) s ij m c i = 1 for all i, j, c. (EQ 5-45) Assuming further that there are no U turns (i.e. no car leaves the intersection through its entry point) gives an additional condition m c ii = 1 = 0 for i = 1, 2, r. (EQ 5-46) In these equations c is used as a time index and T as a variable sampling time interval corresponding to the successive cycles in the work of the traffic control system. The model adopts the assumption, that Each vehicle, located in the intersection during the green light period, will leave the intersection at least during the intergreen period. Under this assumption, all vehicles into the junction during the period T leave the junction during the same period, reflecting the requirement that the flow entering the intersection is equal to the flow leaving the intersection. - [Kessaci A., Farges J.L., Henry J.J., 1989]. At the same time, the PADSIM estimation model recognises that the second assumption in the [Kessaci A., Farges J.L., Henry J.J., 1989] model - that all input flows b c j output flows are measured by appropriate sensors - does not hold. and all Although this second condition is presumed true in all of the presented models and approaches, in reality it is difficult to find a traffic network, controlled by a real-time control system, where all necessary data is available. In fact the first assumption does not depend on measurements and it can be safely adopted in the current PADSIM turning movements estimation model, but as far as the second assumption is concerned, there is only one out of ten intersections (these data are for the case of the Mansfield traffic network with SCOOT as a real-time traffic control system - a scheme presenting all inductive loop positions in the system is shown in Appendix A, Figure 1) with traffic counts (inductive loops) situated in appropriate positions and allowing fully measured input and output data as required by the model. The way out in this situation is to use cross-correlation matrices together with any additional information that can be obtained from the on-line data. Because the method considers the traffic network for C sampling intervals and the matrix solution is overdetermined, in effect the absence of some of the measurements will mean that some of the matrix rows will be missing. This will reduce the quality of the estimation, but the n k i 145

162 resulting system still will be overdetermined and the described methodology will allow mathematical solution of the reduced set of equations. Subsequently, the system of equations can be described in scalar form as: b j ( c) = n i ( c) m ij ( c) i Ω j for all measured i, j, c. (EQ 5-47) In a matrix form and for a number of sampling intervals C for one given cross-road, the original equations can be represented as: b c = n c M c (EQ 5-48) where: b c is a measurement row vector with dimensions 1 α, with α the number of the measured input/output traffic flows; n c is a measurement row vector with dimensions 1 α, with α equal to the number of the measured input/output traffic flows; M c is a matrix with dimensions α α, representing all turning movement coefficients, defined for the cross-road. Since the assumption is that all turning movement coefficients stay the same over the considered period of time, it can be written that therefore M 1 = M 2 = = M c (EQ 5-49) b c = n c M (EQ 5-50) The insufficiency of data (if the measurements are taken over one cycle only, see (EQ 5-8)) necessitates considering the equation (EQ 5-48) with measurements over several consecutive cycles C, which leads to the following equation B = NM (EQ 5-51) where: B is a measurement matrix with dimensions C α, with α the number of the measured input/output traffic flows; N is a measurement matrix with dimensions C α, with α equal to the number of the measured input/output traffic flows; M is a matrix with dimensions α α, representing all turning movement coefficients, defined for the cross-road. 146

163 The equation (EQ 5-51) can be further enhanced by using some additional information available from the real-time traffic control system flow counts. Some of the inductive loops, counting traffic flow, are situated in such positions, that they will count the output traffic flow in one direction only, i.e. giving direct estimates of the traffic flow splitting coefficients in specific directions according to the stage information inside the traffic control system cycle. However, these links can only be considered if the metering loops are positioned immediately after the intersection, so that the variation in the vehicle dynamics does not distort the measurements significantly. The equation that takes into account the stage flows [Peytchev E., Bargiela A., 1998]: b c Stage, can be written as follows j Ω j Stage n jc m ji Stage b ic Stage = for i Ω i (EQ 5-52) where Ω j Stage to flow during a given stage, and is a set of indices representing the links from which the traffic is allowed Ω i Stage is a set of indices representing the links into which the traffic can flow during a given stage. Comparing the expression in (EQ 5-52) with the expression of the equations (EQ 5-47), considered as basic in the model, it can be seen that they are identical in form, differing in value, since (EQ 5-52) correlates measurements taken for only part of the cycle c, while the original equations (EQ 5-47) have values accumulated over the whole cycle. As a consequence, the two sets of equations can be combined into one and the newly formed set can be expressed in matrix form as: where: B = NM (EQ 5-53) B is a measurement matrix with dimensions ( C + λ) α, with α the number of the measured input/output flows, λ is the number of additional stage-related equations and C is the number of cycles considered in the calculation; N is a measurement matrix with dimensions ( C + λ) α, with α equal to the number of the measured input flows, λ and C are as above; M is a matrix with dimensions α α, representing all turning movement coefficients, defined for the cross-road. This simple and neat form, however, does not take into account two additional characteristics of the process: (a) The sum of the coefficients for given section is 1 (EQ 5-45); 147

164 (b) It is possible that for some of the outgoing traffic flows there will be no measurement at all (no inductive loop to measure the outgoing traffic flow) which will lead to removing some of the information from (EQ 5-53); To reflect the above two requirements the equation (EQ 5-53) needs to be modified. All modifications will be demonstrated later using example data. The process starts with conversion of the matrix B into a vector b v with transformation defined as b v ( ( i 1) α+ j) = b( i, j) (EQ 5-54) for all i = 1 C + λ and all j = 1 α. (i.e. place one row the of original matrix after the other). The modification of the matrix N is more complicated. In order to the derive the same equations the transformation is defined as: n ( i, j) v = n( i, j ) n n 0 if if ( ( rem ( i, α) α) < j)& ( ( rem ( i, α) + 1) α j) (EQ 5-55) ( ( ( rem ( i, α) α) < j)& ( ( rem ( i, α) + 1) α j) ) and where i = 1 ( C + λ) α, j = 1 ( α α), i n = mod ( i, α) + 1 and j n = j ( rem( i, α) α). The final matrix N v is with dimensions ( C + λ) α and α α. The correspondence between a newly defined vector and the original matrix M is m v m( i, j) = m v ( i v ) (EQ 5-56) where i = rem( i v, α) + 1 and i = mod( i v, α) + 1 (EQ 5-57) The newly formed system is extended with α additional equations reflecting the conditions described as (EQ 5-17). The new elements in are described as b v () i = 1 for i = ( C + λ) α+ 1 C + λ α + α. At the same time the new rows in N v are described as n v ( i, j) = 1 for i = ( C+ λ) α+ 1 C + λ α + α and j = rem( i, α) + β α where β = 0 ( α 1). Finally in this representation, ρ rows in N v and b v, which describe equations with unmeasured outgoing traffic flow can be deleted. The outcome of the transformations can be expressed in the form: b v b v = N v m v the final dimensions of the matrices in (EQ 5-58) are as follows: (EQ 5-58) b v is a measurement vector with dimension ( C + λ) α+ α ρ ; 148

165 N v is a measurement matrix with dimensions ( C + λ) α+ α ρ and α α. m v is a vector with dimension α α, representing all turning movement coefficients, defined for the cross-road. The resulting system of equations (EQ 5-58) represents an overdetermined system of linear equations and it can be solved by using least square estimation to give a set of turning coefficients averaged over a period of C sampling intervals. The solution is given by (EQ 5-17) and it is m v = ( N v 'N v ) 1 N ' b v v (EQ 5-59) where N v ' is the transpose of N v if During the validation of the algorithm it has been found that it gives satisfactory results C 9. Subsequently in the current implementation of the PADSIM simulation model the moving horizon for turning movements estimation has been assigned to 9 cycles i.e. C = Algorithm illustration. Let us consider the picture in Figure 5-2. The intersection has three arms, therefore for the intersection drawn on the figure α = 3. Let us consider the calculation of the turning movement coefficients over 3 cycles (therefore C = 3) and let us assume the following measured values: Measured input vector in cycle 1: n 1 = [ 40, 25, 10] where 40 is the measured traffic flow input value into node 1, 25 is the input traffic flow into node 2 and 10 is the measured traffic flow incoming into node 3. Measured input vector in cycle 2: n 2 = [ 30, 25, 15] Measured input vector in cycle 3: n 3 = [ 40, 10, 20]. Alternatively let the measured output vector in cycle 1 be: b 1 = [ 23, 30, 22] where 23 is the measured traffic flow output value from node 1, 30 is the output traffic flow from node 2 and 22 is the measured traffic flow outgoing from node 3. In addition let us assume for the other two measured vectors the following values: b 2 = [ 27, 24, 19] 149

166 b 3 = [ 22, 32, 16] The resulting matrices will be: Furthermore, let us assume that in three consecutive cycles (therefore ) the stage measurements (that is outgoing from node 2 and 3 and incoming through node 1) are: n 1 13, = [ 4000,, ], n13, 2 = [ 3000,, ], n 13, 3 = [ 4000,, ] b 1 13, = [ 02714,, ], b13, 2 = [ 0206,, ], b13, 3 = [ 02812,, ] The resulting matrices are: N = , B = (EQ 5-60) λ = 3 N = , B = (EQ 5-61) applying the transformations described earlier it can be written b v = N v , (EQ 5-62) = 150

167 adding the conditions, described with (EQ 5-59), leads to the formulation of N v as b v and b v = N v, (EQ 5-63) Subsequently let us assume that for some reason there are no measurements of the outgoing traffic flow out of Node 1 (for example faulty detector or not detector at all). This is translated into rows 1, 4 and 7 being removed from both and. and the final matrix equation can be written in the form: = b v N v = m v (EQ 5-64) 151

168 and the solution according to (EQ 5-59) is m v = (EQ 5-65) and after conversion to M M = (EQ 5-66) for comparison the target values, that were used to calculate this artificial case were: M = (EQ 5-67) N60421A unmeasured 3 N60331H 2 N60421I N60421B Ahead Right N60421J N60421K N60431E Source: SCOOT region, Mansfield. N60421C 1 Figure 5-2. Model of the intersection N60421, for which the traffic turning movement coefficients model has been validated. 152

169 5.4. Validation of the PADSIM turning movement coefficients estimation model. In order to validate the model, measurement data has been collected for the SCOOT controlled traffic network in Mansfield, Nottinghamshire. The intersection for which the validation of the model has been performed is shown in Figure 5-2. It is a three-arm intersection with incoming flows measured by inductive loop numbers N60421A, N60421B, and N60421C, and outgoing traffic flows measured by inductive loop numbers N60431E, N60331H. At the same time there is additional turning movements information available. Inductive loop number N60421J measures the partial traffic flow outgoing from direction 1 and going into direction 3, inductive loop number N60421K measures the partial traffic flow outgoing from direction 1 and going into direction 2 and inductive loop number N60421I measures the partial traffic flow outgoing from direction 3 and going into direction 2. The outgoing traffic flow into direction 3 is unmeasured. Experiments have been performed to make a comparison between estimates for turning movement coefficients with the additional stage measurements taken into account and without. The results of the experiments with the additional stage information taken into account for 29 april 1997 are shown in Figure Figure 5-5: Legend: With stage data Without stage data m 1, Cycles m 1,3 Cycles It can be seen that the estimation of the coefficients using stage information is much smoother, which is in line with the assumption that the coefficients stay constant for a number of cycles. This is confirmed by the results of the least squares error calculation for the two cases. The least squares error for the case of estimation using stage information was 40835, while in the case of estimation without using stage information it was m Figure 5-3. i, j turning movement coefficients estimation. Comparison between estimation with and without stage information taken into account. 153

170 Legend: With stage data Without stage data 1 m 2, Cycles m 2,3 Cycles m Figure 5-4. i, j turning movement coefficients estimation. Comparison between estimation with and without stage information taken into account. Legend: With stage data Without stage data m 3,1 Cycles m 3,2 Cycles m Figure 5-5. i, j turning movement coefficients estimation. Comparison between estimation with and without stage information taken into account. 154

171 Legend: Real Data Simulated Data m 2,3 m 3,1 m 3,2 Cycles m Figure 5-6. i, j turning movements prediction. Prediction horizon - 4 cycles. Average deviation from real data - 29% Legend: Real Data Simulated Data m 1,2 m 1,3 m 2,1 Cycles m Figure 5-7. i, j turning movements prediction. Prediction horizon - 4 cycles. Average deviation from real data - 29% 155

172 The results presented in Figure 5-6 and Figure 5-7 show the coefficients estimated for the considered intersection as a result of prediction and estimation steps, i.e. not only do the inaccuracies of the turning movement coefficients model influence the results, but also the inaccuracies of the traffic queues and traffic densities prediction model. The used data are from 13 june Conclusions on turning movements estimation models. The estimation of dynamic origin-destination (O-D) matrices from traffic counts in a transportation network receives increasing attention. To extend the O-D estimation methods in a dynamic system environment, some researchers [Cremer M., Keller H. 1981], [Cremer M., Keller H. 1984], [Nihan N., Davis G., 1987] proposed the use of timeseries analysis of traffic counts data to formulate the relationships. [Nihan N., Davis G., 1987] and [Cremer M., Keller H. 1987] have, respectively, presented a family of O-D estimation models for intersections or small networks based on the prediction-error minimisation methods. A common feature of these models is that traffic flow through a traffic detector is considered to be a dynamic process in which O-D flows and exit flows are timedependent variables which depend on causal relationships of the time-variable patterns of entrance flows [Cremer M., Keller H. 1987]. The approach adopted in this research is capable of producing results for on-line turning movements coefficients estimation, based on a reduced set of data from the input/output traffic counts. The method, used in the estimation and prediction model, is the crosscorrelation matrices calculation method with equations using stage information added to the original set of equations describing the system. The comparison between the results obtained without using stage information and the results using stage information showed, that the second approach is advantageous. One interesting result is the accuracy of the estimation of the turning movement coefficients on predicted traffic queues and traffic densities, which stays below 30% for prediction up to 4 cycles ahead (6-8 minutes). The reason for the inaccuracy of the results is the fact that the calculation is based on prediction of the traffic volumes for up to 15 cycles ahead, which contains inherent inaccuracies. m i j, 156

173 Chapter 6 CONFIDENCE LIMIT ANALYSIS FOR THE TRAFFIC QUEUE AND TRAFFIC DENSITY PREDICTIONS 6.1. Introduction. Confidence limit analysis - the process of quantifying the effects of the uncertainty of the input data on the output results from state estimation and traffic flow prediction - has implications in many areas of traffic control systems and management. These fall into the following categories: real-time control, decision support, operational planning, telemetry system design and operator training. The relationship between the quality of measurement data and the quality of the prediction results is a function of several factors. Such factors include the type of the car detection device, location of the device, topology of the urban traffic network, even the quality of the very short term prediction model of the traffic control system which is used for supplying the data for simulation and prediction. In the context of traffic monitoring and control the accuracy of the prediction is of paramount importance. This is evident if the final result from the prediction process - estimation of the travel time alongside a given route - is considered. This is information given to the road users (or the system operator) to enable them in taking control decisions (either driving the car alongside a chosen route or implementing a given intervention). Subsequently the user of the information will be much more confident in his/her decisions if prediction comes with quantification of its uncertainty. For a traffic simulation and prediction module the main causes of uncertainty are: an inaccurate traffic simulation and prediction model, an inaccurate traffic flow turning movements estimation model, inaccurate prediction estimates of the traffic flows for the boundary links in the traffic network (for a definition of a boundary link see Chapter 4. ) and noise and systematic errors in measurement values [Bargiela A., 1985], [Bargiela A., Hainsworth G. D., B], [Walski T.M., 1983], [Walski T.M., 1984], [Walski T.M., 1985]. Less significant for the simulation uncertainty is the inaccuracy of the mathematical solution techniques and the precision limits of the computers used. The fact that all these factors are interrelated results in complex calculation of the confidence limits of the output results (predicted traffic flows). This is described below. A high level view of the confidence limits analysis process is given in Figure

174 The process described in Figure 6-1. is analogous to that presented by [Bargiela A., 1985], [Bargiela A., Hainsworth G. D., B], [Bargiela A., Hartley J. K., 1993], [Hartley J.K., 1996] in the context of water distribution systems monitoring and control. The first group of input parameters comprises the input values as they come from the measuring devices collecting input data and data estimates for some of the points in the network under consideration, which are needed for the state estimation process. The second group of parameters includes the accuracies for the measurements and estimated data. The confidence limit analysis process proceeds to produce estimates for the output results and quantifies their uncertainties. Subsequently, the results of the confidence limit analysis can be used in another process, specifically intended for the telemetry layout design, since the results will show the sensitivity of the system to various positions of the traffic flow detectors. The confidence limit analysis process will give also the sensitivity of the predicted data to the changes in the accuracies of the traffic flow devices, thus recommending the optimum value. Another important area, currently expecting an application of the confidence limit analysis, is the investigation of the social perception of the trade-off between the journey time and the uncertainty about this time. For example some people will prefer a mode of transport that is slower, but does not suffer significantly from random fluctuation in the traffic flows (e.g. a bus moving in a bus lane). - Telemetry Measurements. - Estimates. - accuracies of the measurements. - accuracies of the estimates. Interactive confidence limit analysis process Output Results. Confidence Limits of the Output Results. Figure 6-1. Confidence limits analysis process - domain independent view. This chapter describes the confidence limit analysis process for derivation of the error bounds on the estimation of the drivers turning movement coefficients. Subsequently, the method used in the process is applied for estimation of the error bounds of the predicted traffic queues and traffic densities. An overall view of the whole process of calculating the error bounds on all network predicted traffic flows and turning movements coefficients estimates is presented in Figure 6-2 and Figure 6-3. Since the calculation of turning movement coefficients is performed ahead in time and the results are supplied to the macrosimulation model for calculating queue lengths and 158

175 - Measurements of urban traffic flows. - Estimates of urban traffic flows. Accuracies: - accuracies of the measurements of urban traffic flows. - accuracies of the estimates of urban traffic flows. Interactive confidence limit analysis of the turning movements coefficients estimates Turning movements coefficients estimates Confidence limits of turning movements coefficients estimates Aiding telemetry layout design: - meter positions. - meter accuracies traffic densities (see Chapter 4. and Chapter 5. ), the calculation of the confidence limits for the traffic flow simulation results needs to start with confidence limit analysis for the turning movement coefficients. The high level view of the confidence limits calculation for the turning movement coefficients process is presented in Figure 6-2. The analysis requires two main groups of input parameters: measurements of the traffic flows delivered by the installed vehicle detectors for the case of calculating turning movements coefficients on the basis of measurements only and traffic flow estimates as calculated by the AR model implemented by the macrosimulation model for the case of calculating turning movements coefficients for prediction purposes. Figure 6-2. Confidence limit analysis process for turning movement coefficients estimates. estimation of the inaccuracies of the input data including: - inaccuracies of the data supplied by the real-time traffic control system. These are to be validated by collecting on-line data from the control system and comparing the values with the state of the system as seen by a human observer. 159

176 - inaccuracies for the predicted values for the boundary links in the model (provided by the AR model). These are to be estimated by comparing the results from the AR model with the data from the real-time control system. Subsequently the confidence limit analysis process is performed on the input data to produce three main groups of output results: turning movement coefficients estimates. confidence limits of turning movement coefficients estimates. These are used in the second stage of the analysis where the confidence limits for urban traffic flows and link traffic densities are calculated. estimates of the sensitivity of the solution to the changes in the number of meters in the system and of the sensitivity of the solution to the changes in a meter s measuring quality, which can be used for the design of the number of vehicle detectors needed for proper functionality of the system, for calculation of the detectors positions and detectors accuracy. The second stage of the uncertainty quantifying process is to proceed with calculation of the confidence limits for the predicted traffic flows and link densities in the model. This process is illustrated in Figure 6-3. The input parameters for the process include the input parameters required for the analysis described in Figure 6-2: measurements of the traffic flows delivered by the vehicle detectors and traffic flow estimates as calculated by the AR model implemented by the macrosimulation model. estimation of the inaccuracies of the input data including: - inaccuracies of the data supplied by the real-time traffic control system. - inaccuracies of the values (predicted by the AR model) for the boundary links (i.e. traffic inflow in the model). However, there are two additional parameters required for this stage: turning movement coefficients estimates. accuracy of the turning movement coefficients estimates. The first additional parameter, the turning movements estimates, is needed by the traffic model to produce the predicted traffic flows and link densities (see Chapter 4), since the turning movement coefficients estimation module is external to the model. The second additional parameter determines the inaccuracy of the turning movement coefficients estimates and it is needed by the confidence limit analysis process for estimation of the inaccuracies of the prediction. All information flows and their timing are illustrated in Figure

177 - Measurements of urban traffic flows. - Estimates of urban traffic flows. Accuracies: - accuracies of the measurements of urban traffic flows. - accuracies of the estimates of urban traffic flows. Interactive confidence limit analysis of the predicted urban traffic flows Urban traffic flows prediction Aiding telemetry layout design: - meter positions. - meter accuracies Turning movements coefficients estimates Confidence limits of urban traffic flow predictions Confidence limits of turning movement coefficients estimates Figure 6-3. Confidence limit analysis process for urban traffic flows and traffic densities prediction. The calculation of the confidence limits of the traffic flows and traffic densities for a short term prediction requires the simulation model to perform its prediction process a number of times (typically for 30 minutes prediction the simulation model performs 20 steps where the results of each step are fed into the model as measured values for the next step). Therefore, after having calculated the inaccuracy of the traffic flows and traffic densities after each step of the process, the results have to be fed back as: measured traffic flows values; estimated inaccuracies for both the turning movements estimation process and the traffic flows and traffic densities prediction process. 161

178 real measurements and accuracies of the real data information flow for step 1 Confidence Limit Analysis Process for turning movement coefficients and turning movement coefficients estimation. turning movement coefficients estimates and accuracies of the estimated data Traffic simulation model. Confidence Limit Analysis Process for queue lengths and traffic densities. information flow loop for steps 2 - N predicted data and accuracies of the predicted data Figure 6-4. Information flows in Confidence Limit Analysis Process for Traffic Simulation Systems domain Introducing turning movement coefficients estimation definitions for the case of the confident limit analysis process. This paragraph gives a brief explanation of the terminology for estimation of the traffic turning movements coefficients used throughout this chapter. For the purposes of the derivation of the error bounds of the drivers turning movement coefficients, the process of calculating the vector coefficients estimation process and the vector is called the turning movement is called the coefficients vector of the system. Furthermore, following the notation in the end of Chapter 5 and out of simplification considerations which do not reduce the generality of the research, the notation m will be used instead of m v, b instead of b v and N instead of N v.also for clarity reasons will be used to denote the ratio of traffic flow outgoing from m i, j m iv node i and entering node j instead of just function is defined with (EQ 5-56) and (EQ 5-57). where iv is just an index. The conversion Typically, an urban traffic network consists of nodes (cross-roads) and a number of links connecting them. It is assumed that for every such network the equations (EQ 5-1) to (EQ 5-7) are satisfied. m v m v 162

179 Since the turning movement coefficients for every cross-road in the urban traffic network are calculated separately from the other cross-roads in the network, the derivation of the error bounds of the drivers turning movement coefficients will be considered for one cross-road only. This is possible because the calculations are based on the measurement of the entry/exit flows only for a given cross-road, leaving the crosscorrelation of the traffic flows for adjacent cross-roads for the macrosimulation model (see Chapter 5). It is essential for the approach that the computation is done with the fixed measurement vectors N and b, which do not change throughout the computation. Such a way of calculating the state vector is called the deterministic way and the resulting solution is the deterministic solution. The confidence limit analysis approach operates on ranges of feasible values, attainable by the input measurements for the cross-road under consideration, given the possible variation in their accuracy. These results have dual application: They provide guidance on the required accuracy of measurements They enable the real-time identification of all operational states in which the deterministic state vector calculation occasionally produces misleading and strange results. The confidence limit analysis process requires evaluation of the error bounds for all inputs for the model parameters Assessment of the accuracies of the measurement data. A number of cities throughout Britain and many other countries have already installed operational traffic control systems and rely heavily on the traffic light controls generated by these systems. At the same time such a system is one of the basic building blocks of the Dynamic Model Traffic Control System described earlier (see Chapter 4) and the question about the accuracies of the data supplied by the system is of great importance because this is the basis on which all subsequent processing takes place. This research concentrates on considerations about the work and confidence limits of the results produced by the traffic control system (in the case of this research the traffic real-time control is performed by SCOOT) because it is by far the most common traffic control system implemented in Britain Measurement data - short description. There are two types of messages of interest to the traffic simulation models described earlier: 163

180 message containing a succession of 0 s and 1 s indicating the presence of a vehicle over the location of the vehicle detecting device ( 0 - no vehicle is present, 1 - there is a vehicle present) and it is delivered in the following form: Fr 11:12:13 M19 N60431H1 DETECTOR STATE cccc Here, in concise form, is coded the following information: day of the week, time of the day, message number, vehicle detector number and the detector state. This message is sent every second for every inductive loop in the system. message containing processed information from the previous type message and delivered in the form: Fr 11:12:13 M14 N60431H IVL<dd> OCC<dd> LQ<dd> BQ<dd> EB<d>LIT cccc This message contains in concise form the following information: day of the week, time of day, message number, detector number, successive number of the message in the current cycle, number of vehicles arriving at the stop line for the previous 4 seconds, length of the queue, position of the back of the queue, flag showing whether the exit from the link is blocked or not and the state of the traffic light in the direction of the detector for the previous 4 seconds Measurement data - choice of the message type for confidence limit analysis. The first type of message shows the exact time and the manner in which vehicles pass the position of the inductive loop, therefore it is of interest for the microsimulation model. The second type of message shows the growth of the queue length at the stop line and the state of the traffic lights and, therefore, is more appropriate to be taken into account as a basic message for the work of the macrosimulation model. A significant advantage of the second type, in comparison with the first type of messages, is the fact that its values are validated on the field by the civil engineers during the installation of the system and there is no need for validation of the macrosimulation model s parameters (since they can be retrieved from the validated information, contained in the message). For example, the discharge rate for the specific direction of the detector is validated and can be calculated from two consecutive M14 messages by finding the rate of queue reduction. The validated parameters, however, are only SCOOT system s approximations and future research may have to investigate the inaccuracies in validating those parameters. This thesis is limited to the estimating of the inaccuracies of the results of turning movement coefficient process and the results of the simulation process and considers the validated parameters free of inaccuracies. It should be recognised however, that such a choice of data source is essentially different from the choice of the raw data arriving from detectors installed in the streets 164

181 and every evaluation of the quality of the data inevitably leads to the evaluation of both the physical measurements and the queue building model implemented in the SCOOT traffic control system and does not lead to an assessment of the physical measurements only in the system. Nevertheless this choice is the better option because the SCOOT model has been developed over a number of years and more importantly the model is being validated on the field prior to any exploitation of the system and periodically when in exploitation Assessment of the accuracy of the messages used in the dynamic traffic model control system, described in Chapter 3. The research work aimed at assessing the quality of the input data is, in effect, a study of how good the queue building model of the SCOOT system is. The technique used for evaluation of the accuracy of the output data was simultaneous recording of video and SCOOT data. Subsequently the collected data was analysed for discrepancies. The examination of the results showed that within 30 minutes of observation time the length of the queue varied enough to cover all possible variants of queue formation (several times). On the basis of this result it has been decided that 3 hours of observation time is enough to form a representative data sample. At the same time the SCOOT model works best if the inductive loop is situated as far as possible upstream for a given section, therefore. This feature of the system makes it suitable for observation and data collection to be in the morning just after the rush hour because all variations of the queue formation and dissipation will be studied. In contrast an investigation of the rush hour queues showed the presence of one queue length - the maximum queue length from the traffic lights up to the inductive loop measuring the traffic flow - throughout the rush hour. The above considerations led to the decision to analyse the data for 3 hours in the morning after rush hour with observation on two consecutive days and subsequently validate them on two more days. This assessment, which takes into consideration observation data from the N13231T inductive loop situated in the Nottingham SCOOT region and is performed for a 4 day period between 29 July 1997 and 01 August 1997 over a 3-hour interval each day between 09h 30min. and 12h 30min., is regarded as a representative data sample. The row data are presented in tables Appendix B Table 1. to Appendix B Table 4. The data collection, therefore, consisted of two independent sets of data: numerical data collected by storing the M14 messages delivered by the SCOOT traffic control system into a file for the specified intervals. video data collected via closed circuit cameras and stored on a video tape. 165

182 Both types of data were collected with the kind collaboration of the Nottingham Control Centre staff Numerical data collection. Three SCOOT-controlled urban networks have been considered as candidates for the implementation of a real-time data collection application to be connected to SCOOT using the distributed memory environment DIME. These are Nottingham, Mansfield and Leicester. Based on the availability of the on-line SCOOT data it was decided that the Mansfield system offered the best environment for data collection and subsequent data verification. However, to ensure the generality of conclusions, off-line evaluations of the accuracy of various SCOOT measurements have also been performed for a number of locations in two different SCOOT regions in Nottingham. The following data have been collected: (a) network data for the Mansfield-south SCOOT region, bounded by the Nottingham Road (north of Forest Road intersection), Portland Street, St. Peter s Way and Bridge Street, have been compiled and digitized using a graphics based traffic map editor TEDI developed at the Universitat Politecnica de Barcelona. The data included road geometry, signal stage information and the positioning of inductive loops; (b) off-line M14 and M08 SCOOT messages were collected at the early stages of the project through the EPSRC Instrumented City facility. These data ware collected for several days for two SCOOT regions in Nottingham and as such it served as a reference set for the validation of conclusions reached through the analysis of the on-line Mansfield SCOOT data; (c) on-line M14 and M08 SCOOT messages were collected using the distributed shared memory environment DIME, initially on an as needed basis and subsequently, during the final 12 months of the project, on a continuous basis. An approximately 70Mb data file of a 1.0sec. resolution of data for a complete SCOOT region has been archived daily. A comprehensive data set of over 25000Mb is now available for detailed study and it could be made available to other researchers; (d) on-line M19 SCOOT messages providing information about vehicle signatures on individual inductive loops (0.25sec resolution) are being collected to support the research into the accuracy of traffic predictions using microsimulations which use real measurements for the generation of simulated vehicles. This is being accomplished by interfacing the HUTSIM microsimulator to SCOOT using DIME. The data flows and overall architecture of the system which allowed the numerical data collection is shown in Figure

183 The configuration used for data collection made use of the DIME environment described earlier and involved a number of applications running 24 hours a day. The first application (DIME client 1) was running continuously on a machine situated in the traffic control centre. It performed a connection to the real-time traffic control system (SCOOT) and wrote the data into the memory manager s buffers thus making all SCOOT data available for reading by other applications. The memory manager task was running 24 hours a day also and it was located on the same computer as the DIME client application. Client 1 (situated at the traffic control centre) DIME Messages DIME Memory Manager (situated at the site of the university) SCOOT Data DIME Messages SCOOT Computers Client 2 (situated at the site of the university) data file on disk Figure 6-5. Numerical data collection - data flows. The second application (DIME client 2) was running on a machine situated at the university site and runs only for the period of time arbitrated by the duration of the data collection. It made a connection to the memory manager application, read all necessary SCOOT messages and stored the data into a file. For the case of this study it ran 4 consecutive days for 3.5 hours. Its duration was predetermined by the considerations presented in paragraph The DIME client 1 application and the memory manager task have been running ever since thus providing, in any one moment of time, a suitable environment for other applications to make use of on-line SCOOT data Video data collection. The video data collection used the traffic control centre facilities and tuned one of the on-site cameras to look at one specific cross-road section. The output from the camera 167

184 was redirected to a video recorder and all information was recorded on a standard video tape for a duration of 3 hours. One restrictive condition, in this case, was the availability of the cameras to the conducted data collection, for the same cameras had to be used, in reality, for traffic control while the equipment was locked in one position for the case of data collection Results of the quantification of the uncertainties associated with SCOOT measurements. The assessment of the uncertainties, inherent for the on-line information messages supplied by SCOOT, was a prerequisite for the subsequent confidence limit analysis of the predictions of queues and traffic densities. The data collected through video-recording and subsequent counting of the cars on a video monitor and the data from the numerical collection are presented in Table 1 - Table 4 at the end of the thesis Relationship between the Link Profile Units (LPU) and the physical count of vehicles. 40 [LPUs] maximum average minimum [sample] Figure 6-6. SCOOT data: estimation of the ratio LPUs (y-axes) per car (for over 600 samples). The LPU data are taken from M14 SCOOT messages and the number of cars is as seen on video data. Inductive loop number - N13231T, Nottingham. Data collected for the period h. on 29, 30, 31 July and 01 August The traffic control system SCOOT represents the queue length information in its generated messages in LPUs (LPU stands for a link profile unit representing a normalised vehicle in the system). Therefore, the estimation of the ratio LPU/(car 168

185 count) is of great importance for the validation of the system, since all transformations between the real world data and the internal SCOOT system world data depend upon it. The correspondence between the Link Profile Units and the physical count of vehicles has been estimated by comparison between the numerical data collected on-line and the visual data recorded on a video-tape. The length of the queue at the stop line as seen on a TV monitor was recorded allowing the long vehicles (Buses and lorries) to be counted as 2 cars. It has been found that the ratio LPU/(car count) is typically 17.5LPU/veh. with a variation of +-5LPU/veh. for 90% of the analysed cases. This represents an accuracy of approximately 28% for the vehicles count using the SCOOT LPU readings. The raw data is visualised in Figure 6-6 with the maximum line, representing the ( ) LPU/veh boundary, the minimum line representing the (17.5-5) LPU/veh boundary and the middle line for the 17.5LPU/vehicle average value. Further calculations are based on the assumption that approximately 17.5 LPUs represent one vehicle in reality. [LPUs] [cars] Figure 6-7. SCOOT data: comparison between the length of the queue in the end of the red signal as estimated by SCOOT in LPUs and the data obtained from counting the number of the cars on a video-tape with reference to Figure 6-6. Inductive loop number - N13231T, Nottingham. Data collected for the period h. on 29, 30, 31 July and 01 August Based on this initial value, the length of the queue specified in the messages coming from the real-time traffic control system at each transition of the traffic lights from red to green (i.e. this is the maximum length of the queue for the specified cycle) has been calculated and recorded. Subsequently, the two different values (numerical data value and visual data value) were compared and the results showed that the accuracy of the 169

186 SCOOT message data in comparison to the real data is in the region of 15-25%. This is illustrated in Figure Most significant findings based on analysis of the numerical data. (a) The analysis of the length of the queues on stop lines at the end of the red signal, averaged over 1, 2, 3,..., 10 cycles, has shown that the averaged queue length is a poor predictor of the instantaneous values of the queues in a subsequent cycle. The best predictor was found to be a 5-cycle averaged queue (better than averaged over 10 cycles) but, even then, the error associated with instantaneous predictions was exceedingly large amounting to +-80% for 90% of predictions. Predicting the averaged queues as opposed to their instantaneous values is, as expected, reducing the prediction error. The error associated with 4-cycle averaged predictions using a 5-cycle averaged queue data was found to be typically +-30%. (Appendix C, Figure 1-4). (b) the analysis of the total vehicle count crossing the stop-line during a complete signalling cycle (traffic density calculated per cycle per link), averaged over 1, 2, 3,..., 10 cycles, has shown that there is a good correlation between the consecutive counts. The correlation is even better if a 5-cycle averaged count is taken as a basis. The prediction error of the instantaneous count in the subsequent cycle was found to be typically +-40% (compared with 80% for queues). This error is reduced to 25%, 15% and 10% for the predictions of the 2-, 3- and 4-cycle averaged counts respectively (See Appendix D, Figure 1-3). (c) the analysis of the total count of vehicles crossing two consecutive stop-lines has indicated a strong correlation of readings, particularly during the high traffic periods. For a representative pair of links N60431E and N60442A the discrepancies between the instantaneous readings in the two links were no more than +-20% between 7.00am and 8.00 pm. As expected, the correlation between the readings was much weaker during the night period where, due to an offset timing of traffic signals, a single passing vehicle may be counted in the wrong cycle thus giving rise to a large percentage error up to 100%. However, this is not seen as a significant problem because the supervisory control of traffic is not thought to be necessary during this period. The correlation of the 2-, 3-, 4- and 5-cycle averaged counts was consistently high and the respective predictions showed errors of 15%, 10%, 8% and 5%. This result underlies the validity of the macroscopic network modelling approach to cross-referencing the individual SCOOT readings (See Appendix E, Figure 1-3). (d) the analysis of the correlation between total counts of vehicles at the same time of the day on consecutive Mondays, Tuesdays etc. has indicated that a time series of measurements from previous weeks is a poor predictor of traffic for the current day. The 170

187 instantaneous predictions are typically +-50% in error for 90% of predictions and remain +-20% in error for the predictions of the total counts averaged over 5 cycles. This result has been verified for all the loops in the SCOOT region and it tends to reinforce our view that a purely historical trend analysis approach is not adequate for operational and supervisory control purposes (See Appendix F, Figure 1-6). These results will be used in the confidence limit analysis process for derivation of the drivers turning movement coefficients error bounds Derivation of the error bounds on the statistical characterisation of the drivers turning movement coefficients Introduction to confidence limits analysis approach. One of the most important steps in the prediction of the traffic flows and queue lengths in an urban traffic flow simulation and prediction model is the estimation of the traffic movement coefficients (see Chapter 4 and Chapter 5). Estimating the error bounds of these coefficients will ultimately lead to estimation of the accuracy of the prediction as a whole. This is especially true when turning movement coefficients are calculated over longer periods of time (e.g.over 9 cycles). The importance of consideration of confidence limit analysis has been recognised also in other application domains (e.g. water networks [Bargiela A., Hainsworth G. D., B], [Bargiela A., Hainsworth G. D., 1989] and [Hainsworth, G.D. 1988]) and this research extends their work to the traffic systems simulation and monitoring in general and to the turning movement coefficients in particular. The method chosen for representing the measurement uncertainty specifies upper and lower bounds for each measurement and for each estimated value. This uses the unknown-but-bounded concept for observation errors introduced by [Schweppe F.C., 1968]. If u 0 is the observed measurement vector, made up of the meter readings and the estimated pseudomeasurement values, then a lower limit u l and an upper limit u u can u l u u be specified. Generally, and are calculated by subtracting and adding the measurement error vector e u from and to u 0 which gives the equations and u l = u 0 e u (EQ 6-1) and e u u u = u 0 + e u (EQ 6-2) is a non negative, m-dimensional vector. This formulation of the uncertainty is derived from the recognition that the observed measurement vector is not necessarily the 171

188 true measurement vector (i.e. a vector with completely accurate measurements and estimated values), but the true vector is contained within a region bounded by the accuracy of the measurements and estimations which is specified by. The deterministic description of the turning movement coefficients calculation presented in Chapter 5 can be generalised to take into account the measurement uncertainty. In the deterministic situation, it is assumed that the true measurement vector u t can be approximated by u 0 (i.e. the observed measurement vector). In the nondeterministic (uncertain) model, all that is assumed is that the true measurement vector is contained in the region bounded by and. Defining the measurement set as a collection of all real measurements or pseudomeasurements (estimated measurements) the set of feasible measurement vectors can be expressed as U ( Ψ, u 0 ) u R s u l o = (, i u i u u i, i = 1,, s) (EQ 6-3) where s is the cardinality of the measurement set Ψ, u 0 is a measurement vector u l and u u are lower and upper bound on u 0. In this equation U ( Ψ, u 0 ) defines a region of in which the true measurement vector is contained. This region is the smallest that can be obtained within the limits of accuracy of the measurement set. Using this formalism the network equation can be written as a set inclusion in the following format: (EQ 6-4) where x is a state vector, g (). is the network function and the output from the network function (which is a measurement vector) belongs to U ( Ψ, u 0 ). This gives the set of feasible state vectors, X ( Ψ, u 0 ) for measurement set Ψ and measurement vector u 0 R s as u l Ψ (EQ 6-5) (EQ 6-4) will be referred to as the uncertain network equation and (EQ 6-5) as the state uncertainty set. For the uncertain system there is no unique operating state that can be calculated. All that can be defined is a set of possible operating states resulting from the set of possible measurement vectors. No preference is placed on any of these, all are assumed to be equally likely [Norton J.P., 1986]. This method does not make unrealistic assumptions about the probabilistic properties of the measurement data, their expected values or their probabilistic variation. The unknown-but-bounded treatment of measurement uncertainty leads to a simple and flexible presentation of state estimate uncertainty. Subsequently the feasible state estimates are specified by a defined set X ( Ψ, u 0 ). u u g ( x) U ( Ψ, u 0 ) X ( Ψ, u 0 ) = { X R s : g ( x) U ( Ψ, u 0 )} e u 172

189 To make the uncertainty in state estimates more quantifiable, uncertainty intervals or confidence limits, similar to those for measurement values, can be derived in the following way. Let us assume that x i l = min x i, i = 12 s,, x X( Ψ, u 0 ) (EQ 6-6) x l x u u l x i u = max x i, i = 12 s,, x X( Ψ, u 0 ) (EQ 6-7) the vectors and will provide lower and upper bounds on the state vector x in the same way that and did for the measurement vector. For each individual variable, the interval ( xl i, xu i ) is referred to as the uncertainty interval for the i th variable and xl i and xu i are referred to as its confidence limits. These uncertainty intervals or confidence limits are as tight as can be achieved from the measurement uncertainty. Calculating these bounds for turning movement coefficients is a process referred to as confidence limit analysis or uncertainty quantification. The confidence limit analysis process can be formulated as a series of mathematical optimisation problems. Taking into account (EQ 6-6) and (EQ 6-7) expressing the bounds for each of the independent state variables, the confidence limits for the derived state variables can be expressed by a similar set of equations: u u y i l = min y i (EQ 6-8) subject to y Y( Ψ, u 0 ) and y i u = max y i (EQ 6-9) subject to y Y( Ψ, u 0 ). The condition y Y( Ψ, u 0 ) is equivalent to the condition y = f ( x) for some x X( Ψ, u 0 ). Several optimisation techniques have been used to solve the optimisation problem [Hainsworth, G.D. 1988], [Bargiela A., Hainsworth G. D., 1989] Monte Carlo method. In normal use, deterministic state estimators produce one state estimate for one measurement vector, thus not reflecting the fuzzines of the input data. Alternatively, if a deterministic state estimator is used repeatedly for a whole range of measurement vectors, then some indication of state estimate variance is provided. 173

190 The uncertainty in the measurement data means that we can randomly choose from a range of input measurement vectors and on this basis calculate a range of feasible states. Naturally, not all of the calculated states will satisfy the constraints of the system and some of them will be rejected. If it satisfies all system constraints it is used to update the set of feasible state values for the system. At the start of the optimisation the state vector is zero. As soon as a feasible state estimate is found, it can be used to define the current maximum and minimum values for each state variable. Any new feasible state estimate found is compared against the maximum and minimum values and if any of these bounds are violated, new maxima can be defined. In this way the error bounds for the state variables can be gradually increased until, after many trials, their limits are asymptotically reached. This method is computationally intensive and therefore slow Uncertainty quantification method. This method requires expression of the uncertainty of the measurement data and the state variables. The accuracy of each variable or measurement value should be assessed independently, since a particular meter configuration means some of the parameters will have better accuracy than the others. The method used for defining the uncertainties for each measurement value is to describe the error bound and to calculate the corresponding error bound for each state variable. It has been shown that this approach provides a degree of flexibility while sufficiently defining the confidence limits required by the control applications [Sterling, M., Bargiela A., 1984 a]. Subsequently, the network equations are linearized and solved by using an implementation of a Simplex algorithm [Reid J.K., 1975] or by using the algorithm used by [Bargiela A., Hainsworth G. D., 1989] and proposed by [Roberts P.D., Ben-Israel A., 1970] Using the sensitivity matrix method. Let u represent the difference u g ( x t ). If x t represents the true state vector in the system (i.e. the measurement vector obtained without any error disturbances), u will then represent the difference between the measured vector and the true values of the measured variables. Because the true state of the system could not be known, the best estimate is obtained by assuming the measurement vector to be true and using the deterministic state estimator to produce the values for all state variables. J is a Jacobean matrix calculated from the state estimate, x represents the discrepancy between the calculated state vector and the true state of the system and u represents the discrepancy between the measurement vector and the true value of the measured variables: u = J x (EQ 6-10) 174

191 Since the measurement vector u is bounded by the measurement error vector u, the aim of the confidence limit analysis can be stated as finding a state error vector x which bounds x in the same way. Expressing x from (EQ 6-10) leads to x = ( J T J) 1 J T u (EQ 6-11) where J T is the transpose of J and ( J T J) 1 is the inverse of ( J T J)1. Provided that the system is observable, ( J T J) 1 exists and (EQ 6-11) is well defined. The matrix ( J T J) 1 J T can now be used as a sensitivity matrix, relating changes in the state vector to changes of the measurement vector. For one state variable ( x) i, calculating its error bound is just a matter of maximising u, where a i is the i th row of the sensitivity matrix ( J T J) 1 J T. For more detailed information see [Bargiela A., Hainsworth G. D., 1989]. a i Derivation of the error bounds on the statistical characterisation of the drivers turning movement coefficients. In contrast with the methods described above, in the confidence limit analysis process for turning movement coefficients described below, all matrices are measurement matrices, except for the turning movement coefficients vector m (because of the way m is calculated). Let us consider once again the solution (EQ 5-59) m = ( N T N) 1 N T b (EQ 6-12) where m is the state vector (i.e. the turning movement coefficients), N is a matrix of measurements of the incoming traffic flow into the intersection, N T is its transpose and b is a vector of measurements of the outgoing traffic flow from the intersection. Furthermore let us define l N as a matrix of measurements representing the lower bound of the measurements for the incoming traffic flow and as a matrix of measurements representing the upper bound of the measurements for the incoming traffic flows. In this case, by definition, the following inequalities are true u N 0 l n n ij u ij nij for all i and j (EQ 6-13) These values are positive due to the fact that they are measurements of real traffic flows and negative values for traffic flows have no meaning in the context of traffic simulation. Similar relations can be written for the outgoing traffic flows 0 l bi b u i bi for all i (EQ 6-14) 175

192 on the basis of the last two inequalities it is easy to see that where n 0 ij 0 l nij n ij n incoming traffic flow and l ij + n ij for all i and j (EQ 6-15) represents the error bound for this particular measurement of the n ij is the actual (real or estimated) measurement. Once again similar relations can be written for the outgoing traffic flows where b i 0 outgoing traffic flow and 0 l bi b i b l i b + for all i i (EQ 6-16) represents the error bound for this particular measurement of the b i is the actual (real or estimated) measurement. With reference to (EQ 6-12) the solution of the equation can be considered as the multiplication of the matrix ( N T N) 1 with the vector N T b. Let N T N = H and l T N l N = l H (EQ 6-17) l where the matrix N is defined as above and N is its transpose matrix. Similarly l T u T N u N = u H (EQ 6-18) u where the matrix N is defined as above and N is its transpose matrix. Consequently for each measurement matrix N, conforming to the (EQ 6-13), the following can be written u T s h ij = ( N T N) ij = n T ik n kj k = 1 for all i, j (EQ 6-19) since all n ij are non-negative, n T ik n kj = max when n ij = max = n and nt ij max u T = = n. In addition n ij T ik n kj = min when n ij = min = l nij and nt T ij = min = n. This is summarised in the expression l ij u ij 0 l h N ij ( T N) ij u hij (EQ 6-20) therefore the true measurement data matrix for this part of the (EQ 6-13) is bounded by the matrices l H and u H 176

193 The next step in the method is to find the bounding matrices after the inversion of H. Taking into account the formulation of an inverse matrix it can be written [Parsonson S.L., 1970]: ( adj H ) T = det H H 1 (EQ 6-21) or H det H H det H H n det H H 1 = H det H H det H H n2 det H (EQ 6-22) H n det H H n det H H nn det H where is the cofactor of. H ji The aim of this step is to find estimates for lower and upper bounds of. This is crucially dependent on the estimation of lower and upper bounds for det H. With regard to the expanded form of the determinant it is possible to obtain lower and upper bounds for det H. This is achieved by assuming that all positive members of the sum take part with their lowest values and all negative members of the sum take part with their highest values in the calculation of the lower bound for det H and, alternatively, for calculation of the upper bound all positive members of the sum take part with their highest values and all negative members of the sum take part with their lowest values. Similarly, lower and upper bounds for each of h ji case of calculating lower and upper bounds for det H. h ji can be calculated following the same assumptions as in the At this step there are three possibilities for the upper and lower bounds of det H : case 1: lower bound value negative and upper bound value negative. case 2: lower bound value negative and upper bound value positive. case 3: lower bound value positive and upper bound value positive. H 1 In the first case it is clear that the bounds for any element of the inverted matrix i h ij = H ji det H (EQ 6-23) can be calculated in the following way: 177

194 i h ij (a) to calculate upper bound of, if 0, substitute det H with its upper H ji H ji min bound and with its lower bound, if > 0, substitute det H with its lower H ji min bound and H ji with its lower bound. (b) to calculate lower bound for, select lower bound for det H and upper bound for if 0, and if 0, select upper bound for det H and upper H ji bound for. H ji H ji max In the third case the path is similar to the one described for the first case: i h ij H ji max i h ij (a) to calculate upper bound of, if 0, substitute det H with its upper H ji max bound and with its upper bound, if 0, substitute det H with its lower H ji H ji max bound and H ji with its upper bound. (b) to calculate lower bound for, select lower bound for det H and lower bound for,.if 0, and if 0, select upper bound for det H and H ji lower bound for. H ji min The consequences arising from the second case are very different. Since can be very close to zero or zero, the resulting inverse matrix can differ substantially and consequently the solution can vary in a wide region (infinity in the case of det H = 0 ) and therefore it is impossible to estimate bounds for the inverse matrix. After the inversion procedure it can be assumed that it is bounded by the inverted l i H ji matrices H and H. Following the same path for the second part of the multiplication on the right hand side of (EQ 6-13) and defining u l i N T b = l T N y l b it can be written that (EQ 6-24) where the matrix N is defined as above, N is its transpose matrix and b is the lower bound for the measurement vector of outgoing traffic flows. Similarly u u T N u b i h ij H ji min = = l y u y det H (EQ 6-25) where the matrix N is defined as above, N is its transpose matrix and b is the upper bound for the measurement vector of outgoing traffic flows. Consequently for each l u T T l l 178

195 measurement matrix of the incoming traffic flows N conforming to the (EQ 6-13) and for each measurement vector of outgoing traffic flows b conforming to the (EQ 6-14) the following can be written 0 l y N i ( T b) i u yi (EQ 6-26) Using the notation N T N = H and N T b = y, the equation (EQ 6-12) can be rewritten as l m l i H i + m = ( H + ) ( y + y) = = l il H y l l l H i y H i y + H i y + + (EQ 6-27) where the aim is to obtain estimates for lower and upper bounds for m as a function of all possible variations of H and y (all possible variation of H and y are l u l u defined by H, H, y and y ). Taking into account that the (EQ 6-27) becomes l m = l il H y (EQ 6-28) m = H il y + l H i y + H i y (EQ 6-29) defining m min = ( m min 1, m min 2,, mmin n ) the estimation of each mmin i in scalar form is defined as r mmin i = min hi ij y + min l hiji y j + min hi ij y j j = 1 l j r j = 1 j = 1 (EQ 6-30) since all y j and y j are non-negative (see (EQ 6-26)) and by definition h > h, ij therefore hi ij 0, the minimisation of the expression on the right side of (EQ 6-30) with regard to H and Y is trivial. For this purpose, it is enough for the first and the third member of the sum to be assumed r u iji l i hi ij = 0 (EQ 6-31) Similarly for the second member of the sum u ji l i yj l hiji < 0 y j = max ( y j ) = y if y j = 0 if h l iji 0 (EQ 6-32) The estimation of the upper bound for the vector variations of H and y follows the same path. m as a function of all possible 179

196 Let m max be defined as m max = ( m max 1, m max 2,, mmax n ) The estimation of each in scalar form is defined subsequently as m i max r mmax i = max hi ij y + max l hiji y j + max hi ij y j j = 1 l j r j = 1 r j = 1 (EQ 6-33) since all y j and y j are non-negative (see (EQ 6-26)) the maximisation of the expression on the right side of (EQ 6-30) with regard to H and y repeats the procedure described above. For the first and the third member of the sum the assumption is: hi ij = hi ij u iji = max ( hi ij ) = h l i hij if max hi 0 ij > 0 if max hi ij 0 (EQ 6-34) Similarly for the second member of the sum the assumption is: u ji l i yj y j = max ( y j ) = y if hi ij > 0 y j = 0 if h ij i 0 (EQ 6-35) Algorithm for derivation of the error bounds on the statistical characterisation of the drivers turning movements coefficients. (a) Obtain by subtracting the value of possible error resulting in overestimation of the measurement value for each particular measurement in the matrix of incoming flows measurements N. (b) Obtain by adding the value of possible error resulting in under-estimation of the measurement value for each particular measurement in the matrix of incoming flows measurements N. (c) Obtain by subtracting the value of possible error resulting in overestimation of the measurement value for each particular measurement in the matrix of incoming flows measurements b. (d) Obtain l N u N l b u b by adding the value of possible error resulting in under-estimation of the measurement value for each particular measurement in the matrix of outgoing flows measurements b. 180

197 (e) Calculate det H max (f) Calculate det H min (g) Calculate H ji min (h) Calculate H ji max (i) if det H max > 0 and det H min < 0 send message Impossible to calculate confidence limits - Matrix M close to singular. Stop. (j) if det H max > 0 and det H min > 0 if if if if H max ji 0 calculate H max ji < 0 calculate h H min ji 0 calculate i h max ij H min ji < 0 calculate h i max ij i h min ij i min ij = = = = H ji max det H min H ji max det H max H ji min det H max H ji min det H min (k) if det H max < 0 and det H min < 0 if if if if H min ji < 0 calculate h H min ji 0 calculate H max ji < 0 calculate h H max ji 0 calculate i max ij i h max ij i min ij i h min ij H ji min = det H max H ji min = det H min H ji max = det H min H ji max = det H max (l) Calculate H i = u H i l H i (m) Calculate l y = l T N l b (n) Calculate u y = u T N u b (o) Calculate y= u y l y 181

198 (p) Calculate l m = l H l y (q) For i = 1, 2,, n calculate where r mmin i = min hi ij y + min l hiji y j + min hi ij y j j = 1 l j r j = 1 r j = 1 (EQ 6-36) hi ij = 0 (EQ 6-37) and yi ij = yi ij u iji = max ( yi ij ) = y l i yij if l hiji < 0 0 if l hiji 0 (EQ 6-38) (r) For i = 1, 2,, n calculate mmax i = max hi ij y + max l hiji y j + max hi ij y j where r j = 1 l j r j = 1 r j = 1 (EQ 6-39) hi ij = hi ij u iji = max ( hi ij ) = h l i hij if max hi ij > 0 0 if max hi 0 ij (EQ 6-40) and yi ij = yi ij u iji = max ( yi ij ) = y l i yij if hi ij > 0 0 if hi ij 0 (EQ 6-41) (s) Calculate state vector which is in the middle of the error bounds interval as m = ( m max + m min ) (EQ 6-42) and m = 1 ± -- 2 ( m max m min ) (EQ 6-43) 182

199 6.5. Development of the state estimation algorithm. The simulation model as described in Chapter 4 has been formulated in a state-space with the state defined as a vector that has two state variables for each link i, the queue length at the red-to-green transition time instance c, denoted as traffic density during the traffic signals cycle, denoted as, and the average. The process of calculating the two state variables for all links is called the state estimation process for the urban traffic simulation model. On its first step the model works on the basis of all real data collected prior to the beginning of the simulation process. Usually this data set consists of all measurements collected for a number of consecutive cycles (the number of cycles depends on the model, for this macroscopic traffic simulation model the number of cycles is 15). The state estimation process begins with estimation of the drivers turning movement coefficients as explained in Chapter 5. and in the paragraph Derivation of the error bounds on the statistical characterisation of the drivers turning movement coefficients. of this chapter. The next stage in the state estimation for the traffic simulation model is to estimate and q ( t i i c ) k ( t i i c ) which is performed according to the equations described in Chapter 4..This action closes the first step of the simulation. The second step of the simulation process is to discard the oldest real measurement data and to complement the real data set with the simulated data for the urban traffic network, considering the predicted data as the newest data in the system. The data set is then passed to the Drivers Turning Movements Coefficients Estimation Module. The results from the module together with the combination of real and predicted data is passed to the Traffic Network State Estimation Module for calculation of the and ( ) state variables for all links in the network. q ( t i i c ) k ( t i i c ) q ( t i i c ) k t i i c Step 2 is repeated as many times as the traffic model and the depth of the prediction require. All these steps are formally expressed in the next paragraph State estimation algorithm. (a) Collect the real measurements data for C cycles. (b) repeat for all r crossroads in the traffic network (i.e. i = 1,... r): Store the incoming flows data in the data array NArr i [j,k]. Put the most recent data in NArr i [1,k], the oldest data in NArr i [N,k], where i = 1,... r. Put the outgoing traffic flows in the data array BArr i []. Put the most recent data in BArr i [1], the oldest data in BArr i [N], where i = 1,... r. (c) repeat for all M crossroads in the traffic network (i.e. i = 1,... r): 183

200 real measurements Drivers Turning Movement Coefficients State Estimation. information flow loop for steps 2 - N information flow for step 1 Urban Traffic Network State Estimation Module. Traffic simulation model. real data collected prior to the beginning of the simulation process and simulated data Figure 6-8. State Estimation Process for the macroscopic urban traffic flows simulation model. Calculate the drivers turning movements coefficients crossroad i on the basis of the data in NArr i [] and BArr i [] m i for the m i = ( N T i N i ) 1 N T i b i. (d) repeat for all r crossroads in the traffic network (i.e. i = 1,... r): Calculate the outgoing traffic flows for the crossroad i on the basis of the drivers turning movement coefficients using the data in NArr i []: m i for the crossroad i and b i = N i m i. (e) Perform a prediction for all streets i in the urban traffic network on the basis of data in NArr i [] and BArr i [] and calculate all state variables and ( ) (for a full explanation see Chapter 4): Queue Calculation - Case1: q ( t i i c ) k t i i c N = d Θ ic, + 1 i ic, + 1 q i i t i = q t + Q N c + 1 i c i, c + 1 ic, + 1 (EQ 6-44) (EQ 6-45) 184

201 Queue Calculation - Case2: N = d Θ ic, + 1 i ic, + 1 q i i t i = q t + Q N c + 1 i c i, c + 1 ic, + 1 (EQ 6-46) (EQ 6-47) Queue Calculation - Case3: i Θ N = q i, c + 1 i t + Q c i, c + 1 q i i t Ț Θ = Q c + 1 i c + 1 (EQ 6-48) (EQ 6-49) where is the queue length in the link i in the current cycle c ; q ( t i i c ) Q ic, + 1 c+1 ; N ic, + 1 Θ ic, + 1 d i is the number of cars joining the queue in link i during the cycle is the number of cars discharged from the queue during the green signal in the cycle c+1, and is the discharge rate for every specific direction and is determined by the traffic control system SCOOT. Traffic Density Calculation: k ( t i i c + 1) = k ( t i i c ) B N ic, + 1 i, c l i (EQ 6-50) is the traffic density in the link during the previous cycle c, is the length of the link i, + is the number of cars entering the link during the cycle c+1 (note that link expressed in cycles), is well approximated by where a is an integer representing the travel time along the is defined as above. (f) Shift the data in QArr i [] and YArr i [] in such a way that old QArr i [k]=new QArr i [k+1] and old YArr i [k]=new YArr i [k+1]. Store all new data in QArr i [1] and YArr i [1] and discard the data old QArr i [N] and old YArr i [N]. (g) If steps (c)-(f) are repeated less then N times go to step (c). (h) Stop. k ( t i i c ) l i B i, c 1 B ic, + 1 Q i, c+ 1 + a N i, c Confidence Limits of the predicted traffic flows. The process of estimation of the confidence limits of the state estimation vector (two vectors in the case of the PADSIM) follows an identical path to the one described earlier. 185

202 Starting with case 1 for queue length prediction it can be easily seen that any variation on the right hand side of the equation is linearly transformed to the left hand side of the equation: i q i t c + 1 q t i + i c + 1 = = i i q t + q t + Q + Q N N i c i c i, c + 1 i, c + 1 ic, + 1 ic, + 1 (EQ 6-51) which leads to the equation where prediction, direction and (EQ 6-52) is the uncertainty of the same state variable in the previous step of the is the uncertainty of the incoming traffic flow from this particular is the uncertainty of the traffic model of the real-time traffic control system implemented in the field (for the case of this research it is the SCOOT traffic control system). In the worst case the last member of the sum will have a negative value i.e. considering all members of the sum non-negative the expression becomes The uncertainty of the first member of the sum (EQ 6-53) can be assumed initially (i.e. only for step 1 of the estimation) to be equal to the uncertainty of the model of the realtime control system SCOOT. This is quantified in paragraph 6.3. The uncertainty of the third member of the sum is once again a direct consequence of the quality of the traffic model implemented in the real-time control system SCOOT and is quantified in paragraph 6.3. The uncertainty of the second member of the sum (i.e. the uncertainty of the incoming traffic flow for this particular link) is equal to the uncertainty of the outgoing traffic flow calculated for the cross-road immediately up-stream for the direction of this particular link. The quantification of the uncertainty of the outgoing traffic flows in each particular direction follows the ideas presented in paragraph The definition of outgoing traffic flow is i q t i c Q i, c + 1 N ic, + 1 i i q t i c + 1 = q t + Q N i c i, c + 1 ic, + 1 i i q t i c + 1 = q t + Q + N i c i, c + 1 ic, + 1 i q t i c b i = j Ω i n ij m ji (EQ 6-54) n ij where and Ω i m ji is the set of indexes of links adjacent to i. Taking into account that both are non-negative and following the quantification described in paragraph 186

203 6.4.2 for the lower and the upper bounds of the expression the (EQ 6-54) can be written as an inequality giving the maximum and the minimum values for b i l n l b i n j Ω i ij m ji j Ω i u u ij mji (EQ 6-55) and therefore the uncertainty b i is calculated as b i = j Ω i u n u ij m ji j Ω i l n l ij m ji (EQ 6-56) or in vector form u b i (EQ 6-57) where m and m i i are calculated on the basis of the uncertainty limits as quantified u in paragraphs and 6.4.3, while the quantification of N and l N i i depends on u which step is performed (here N and l N i i represent vectors, equal to the i th row of the u l N and N respectively). If performed on the first step, the uncertainty is equal to the uncertainty of the input data and if performed on one of the steps 2 to N, it is quantified recursively by using (EQ 6-52). u u N m i u l N i l i m i The same procedure has to be followed for the case 2 of the queue length calculation, simply because in the end it is the same expression as in case 1. = The procedure for calculation of the error bounds in the third case is even simpler. The resulting queue length, in this case, is part of the outgoing flow and therefore the uncertainty is calculated as a proportion of the uncertainty of b i q i i t q i c + 1 i t Ț Θ Ț Θ Ț Θ T Θ + Q Q Q Q = = c + 1 i c+ 1 i c + 1 ic+ 1 i, c + 1 T (EQ 6-58) therefore q i i t T Θ = Q c + 1 i, c+ 1 T (EQ 6-59) where Q ic, + 1 is calculated as above. As far as the uncertainty of the traffic flow density is concerned, the calculation follows the same path as in the calculation of the uncertainty of the queue length in case1: k ( t i i c + 1) = k ( t i i c ) B N ic, + 1 i, c l i (EQ 6-60) 187

204 where and is defined as above. The initial value k ( t i i 1) B Q ic, + 1 = N ic, + 1 i, c + 1 can be considered as k ( t i i c ) = Q i, c l i (EQ 6-61) since it reflects the initial value of the traffic flow density which is k ( t i i 1) B i1, = = l i Q i, l i (EQ 6-62) Confidence limits quantification algorithm. (a) Collect the real measurements data for C cycles and obtain the uncertainty of the data as described in paragraph 6.3. (b) Estimate Drivers Turning Movement Coefficients as described in Chapter 5. (c) Estimate Drivers Turning Movement Coefficients Confidence Limits on the basis of the confidence limits of the real measurement data and the confidence limits of the predicted data as described in paragraph 6.4 (d) Calculate l N l i m i by using the minimal estimates for the queue length measurements l Ni and for the Drivers Turning Movement Coefficients l mi (e) Calculate u N u m i i by using the maximal estimates for the queue length measurements u Ni and for the Drivers Turning Movement Coefficients (f) Estimate the uncertainty of the queue length prediction by calculating u mi i q t i c + 1 = i q t + Q + N i c i, c + 1 ic, + 1 (EQ 6-63) or where q i i t T Θ = Q c + 1 i, c+ 1 T (EQ 6-64) i q t i c = Q if considered for the first step of the prediction i, c i q t if considered for the steps 2 to N of the prediction i c q i, c + 1 = u N u m l N l i i i m i (EQ 6-65) (EQ 6-66) 188

205 and is as estimated in paragraph 6.3. N ic, + 1 (g) Estimate the uncertainty of the traffic flow density by calculating k ( t i i c + 1) = k ( t i i c ) B + N ic, + 1 ic, l i (EQ 6-67) where k ( t i i c ) = Q i, c if considered for the first step of the prediction l i k t i i c 1 if considered for the steps 2 to N of the prediction (EQ 6-68) Q i, c + 1 = u N u m l N i i l i m i (EQ 6-69) and is as estimated in paragraph 6.3. N ic, Algorithm for quantification of the maximum prediction horizon of the simulator for which the confidence limits on the state estimates remain acceptable. The functional description of the quantification of the maximum horizon for the prediction process is presented in Figure 6-9 and can be described as follows: (a) Collect all measurement data prior to the start of the prediction process. (b) Collect all confidence limits estimates for measurement data. (c) Calculate drivers turning movement coefficients. (d) Calculate confidence limits of the drivers turning movement coefficients. (e) Calculate all state variables of the traffic simulation model. (f) Estimate confidence limits for the state variables of the model. (g) Check if the confidence limits of the state variables remain acceptable. (h) if acceptable continue with (c) (i) if not acceptable stop the process and report the results. All confidence limits processes described above are coded in C programming language with dynamic connection to MATLAB software which facilitates all matrix calculations. 189

206 real measurements estimates of the uncertainties for the real measurements information flow for step 1 Drivers Turning Movement Coefficients State Estimation. Confidence Limits Estimation for the drivers turning movement coefficients Urban Traffic Network State Estimation Module. Traffic simulation model. information flow loop for steps 2 - N real data collected prior to the beginning of the simulation process and simulated data Stop the process and report the results. unacceptable confidence limits Confidence Limits Estimation for the simulation model state variables acceptable confidence limits Figure 6-9. The Confidence Limits Estimation Procedure - Information Flows Results. The algorithm for calculation of the confidence limits of the estimated turning movement coefficients was applied for a data set consisting of 20 consecutive days and the results included in the thesis are representative for the whole set. The inaccuracy of the input data for the confidence limit analysis was assumed to be between 1% and 10% and the bounds for the final solution have been calculated for different values within this interval (this is not a restriction of the method, since the inaccuracy of the input data can be defined by a matrix supplied by the user). The data used in the calculation are for the coefficients m 2,1 and m 2,3 according to the notation shown in Figure 5-2., cross-road number N The data represent the period from 0800h to 1200h on 06 may The confidence limits of the turning movements coefficients have been calculated for assumed inaccuracy of the input data of 1%, 3%, 5% and 7%. The results, produced by the proposed algorithm, are presented in Figure Figure

207 Legend: Estimated data Confidence limits of the estimated data Figure Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 1%. m 2,1 m 2,3 Cycle Number Legend: Estimated data Confidence limits of the estimated data Figure 6-11Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 3%. m 2,1 m 2,3 Cycle Number An illustration of the results of the prediction process with subsequent confidence limit analysis for benefit of the control room operator is shown in Appendix A, Figure Conclusions on confidence limit analysis for the traffic queue and traffic density predictions. A new algorithm for estimation of the bounds of the solution for the traffic movement coefficients has been presented. Subsequently, the area of application of the algorithm has been extended to the discrete systems domain and an algorithm for quantification of the error bounds of the predicted traffic flows and traffic densities has been designed and implemented. The confidence limit analysis process starts with estimation of the input data for the model. The input data for the model are supplied by the real-time operational traffic 191

208 Legend: Estimated data Confidence limits of the estimated data m 2,1 m 2,3 Cycle Number Figure 6-12Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 5%. Legend: Estimated data Confidence limits of the estimated data m 2,1 m 2,3 Cycle Number Figure 6-13Confidence Limits of turning movements coefficients. Assumed inaccuracy of the input data = 7%. control system, therefore the process starts with estimation of the quality of the SCOOT output data. Using recorded video data and alpha-numerical data collected within the DIME environment, this research showed that the inaccuracies of the SCOOT data vary in the range 15-25%. Another important result, that could be seen on the graphs above, is that the confidence limits set by the presented algorithm are very wide for input data errors to above 5%. This 192

209 is because the algorithm for derivation of these bounds takes into account the worst scenario for their calculation, while the average quality of the prediction of the traffic movement coefficients, as presented in the previous chapters, is in the region 15-25%. The conclusion from these facts is: although the input data are not very accurate, the errors seem to compensate one another, and the final result obtained by the estimation process on average is good, while the error bounds, as estimated by the presented algorithm, give a range of up to %, which does not carry any useful information. Another reason for the variation of the results is the fact that both matrices describing the solution are measurement matrices in contrast with the original approach for confidence limit analysis, where only the right hand side of the initial equation system is a measurement vector. Nevertheless, the implemented algorithm can be applied to any real world system which is described by an (over-determined) set of linear equations and the ideas presented in this research can be used in the discrete systems domain. 193

210 Chapter 7 CONCLUSIONS AND FURTHER RESEARCH 7.1. Concluding Remarks about the Project. The purpose of the project has been to design and develop an integrative framework for discrete systems and monitoring. The framework has been used for the implementation of advanced traffic/transportation telematics applications and it has been shown to be sufficiently flexible to provide the communication basis for distributed supervisory control/decision support applications in urban traffic networks. This research to date resulted in: Design and prototype implementation of a Distributed Dynamic Traffic Model System for advanced traffic management. The research into the traffic systems has led to further development of the distributed traffic systems, recognising the necessity of situating the computational power of the system on separate machines and connecting them in a network of distributed computers. This arrangement allows flexible allocation of multiple copies of the control software modules running concurrently in a distributed environment. Furthermore, a modular approach has been used in the design of the system. It recognizes the existing real-time control software as a separate module in the system, performing local traffic signal settings control. The design of the system identifies the global control strategy as being the responsibility of the supervisory layer of software comprising traffic network simulation, state estimation, origin-destination route optimization and control strategy generation modules. Such a layer ultimately will provide all necessary information for the in-car route guidance systems. In the case of a system capable of generating suggestions for improving the situation in the traffic network, the operator should be able to override any system s conclusions, therefore a sophisticated graphical interface for system-operator communication is envisaged in the system; Design and implementation of DIME: A DIstributed Memory Environment for monitoring and control of urban traffic, capable of providing an information interface for all software modules included in the distributed dynamic traffic model system and ensuring a fast and uniform access to the data circulating in the system. The Distributed Dynamic Traffic Model System has been built with DIME as a distributed computers communication harness. The experiments with DIME showed that it is capable of data distribution fast enough to allow proper 194

211 work of all modules of the distributed dynamic traffic model system even using a Wide Area Network (WAN); Design and implementation of PADSIM: A Predictive Macroscopic City Traffic Flows Simulation Model as a central software module of the distributed dynamic traffic management system. It has been formulated in a state-space with the state defined as a vector comprising two state variables: the length of the queue and the traffic density in a link specific instance of time. The originality lies in the choice of time instance for state calculation. The time instance is a variable for every individual link and depends on the red-to-green transition of the traffic lights for the link, thus implicitly taking into account all cycle and offset control variations of the signals. The model projects the envisaged movement of the traffic flow according to the turning movement coefficients estimation, provided by the turning movement coefficients estimation module. It provides predictive estimates for queue lengths and traffic flow densities and uses a graphical interface to represent the results in an easy to interpret way. The model has been calibrated by using telemetry data collected by an additional module connecting SCOOT to DIME. The evaluation of the model on the real traffic flows data confirmed that the state-space formulation, with link dependent discrete time, provides an adequate tool for the modelling of macroscopic traffic evolution. As a part of the investigation into the traffic modelling an implementation of the carfollowing traffic microsimulation model has been developed. It illustrates the possibility of inclusion of several copies of a given microsimulation model in the distributed dynamic model system and the subsequent information interface between macrosimulation and microsimulation models (any other microsimulation model can be included in the system using the flexibility provided by DIME). Design and implementation of an X11 graphical library for the implementation of user interfaces. Implementation of a cross-correlation matrices calculation method for dynamic drivers turning movement estimation using traffic flow detectors data, collected by the real-time control module of the distributed dynamic traffic model system (i.e. using SCOOT data collected through inclusion of the SCOOT in the DIME environment). Investigation of the applicability of the confidence limit analysis methods into the traffic control and monitoring domain. The most important developments in this area are: 195

212 - Design and implementation of an algorithm for deriving the error bounds on the statistical characterisation of the dynamic drivers turning movement coefficients. - Assessment of the accuracies of the real data supplied by the real-time traffic control system SCOOT for the purposes of the confidence limit analysis process. - Design and implementation of an algorithm for quantification of the maximum prediction horizon of the simulator for which the predicted traffic queues and traffic densities remain acceptable. Design and development of a software module for facilitating the interaction between the operator and control system as a part of the operators decision support The research has taken into account distinctive features of the SCOOT system such as queue formation and queue dissipation and content and frequency of its messages. (SCOOT is the real-time traffic operational control system implemented in more than 60 cities throughout the world). It is represented in the model as a real-time operational traffic control software subsystem of the distributed dynamic traffic model system Future Research. The presented research work pointed also to a number of directions for future research. (i) Investigation of the fundamental computing and communication problems that underlie the development of large scale (mobile) distributed telematics systems, such as the in-car traffic/travel information systems. (ii) Investigation of the impact of a supervisory layer of control on drivers behaviour. (iii) A description of Distributed Shared Memory Environment has been presented in Chapter 3 of this report. One distinctive feature of this environment is that it comprises embedded functions for fast data retrieval. The functionality of the system could be enhanced by embedding some of the Variable Data Transformations within the DIME itself. This would allow the user not only to define areas the program will use, but also to define the functions performed on the data even before its retrieval by the program (such as filtering). (iv) Investigation of the possibility of building a system with more than one Memory Manager running concurrently. (v) The PADSIM macroscopic simulation program presented in Chapter 4. can be enhanced in several ways: 196

213 (a) Taking into account diurnal fluctuations of the traffic flow; (b) allowing dynamic creation and deletion of links in the traffic network, thus allowing the operator to specify incidents or other events affecting the traffic flow; (c) designing and implementing an interface module for operator-simulation module interaction, allowing the operator to ask what-if type of questions; (vi) The research, presented in this thesis, introduces two layers of traffic control. The first layer - local control - is well known and there are a number of programs both offand on-line dealing with the subject. The second layer is just starting to develop with only a few hints at hand to point toward what the structure of the system might be and how it would control the dynamic traffic system. A central point in the development of the layer is the system s interventions problem, i.e. what elementary control actions and combinations of elementary control actions could be of use in a supervisory control environment. The experience so far in the development of the traffic control systems pointed to few interventions, which could be considered as supervisory, such as: giving weight in certain directions, opening lines in one and closing lines in another direction etc. The research refers to these control actions as operator interventions and they are needed on a traffic management layer rather than on a traffic lights control layer. Clearly further research in this direction is needed together with the development of the global control strategy generation module (as opposed to the local control module). (vii) Research into the design and implementation of a special specification language, which would allow the operator to specify the exact control strategy for evaluation and to implement the selected strategy on the field. (viii) The choice of optimal route is not restricted to the cars only. A traveller might decide to use alternative forms of transport within the urban area. Clearly the links between the control systems, managing the different types of transport has to communicate and exchange data on a supervisory layer of control and integration of the different systems is a big challenge. 197

214 Partial list of definitions: a, c, αβκ,, - coefficients in equations; y () t - measured value of traffic volume in link i at time interval t i ; P () t i - predicted traffic volume for link i at time interval t ; d () t i N () t i Θ i () t - discharge rate (number of cars leaving the queue per second), specific for every particular link i ; - number of cars leaving link i at time interval t ; - duration of the green signal in seconds for link i at time interval t ; q ( t i i c ) - queue length at the red-to-green transition time instance t i c for link i ; k ( t i i c ) - average traffic density during the traffic signals cycle c for link i ; Q ic, - number of cars joining the queue in link i during the cycle c ; QΘ ic, - number of cars joining the queue in link i during the green signal Θ i, c N ic, in the cycle c ; - number of cars discharged from the queue in link i during the green signal Θ i, c in the cycle c ; T c l i B i, c - duration of the cycle c ; - length of the link i ; - number of cars entering link i during the cycle c ; Ω i - set of indexes representing all upstream links adjacent to link i ; m ( c) j, i - turning movement coefficient determining what proportion of cars N j, c, exiting link j in cycle c, enters link i ; V ( t i i c ) V min V max k jam V n V n () t () t - average speed in the link i in cycle c. - minimum speed in the link i ; - free flow speed in the link i ; - jam density in the link i ; - the change of speed per second (acceleration) for a vehicle n in moment of time t ; - speed of the vehicle n in moment of time t ; 198

215 x n () t φ ( c) ij z() t r() t - position of the vehicle n in moment of time t ; - number of cars exiting link i and entering link j in cycle c ; - exponentially smoothed historical volume for the time interval t ; - exponentially smoothed difference between measured and historical volumes for the time interval t ; 199

216 References: [3COM Reference manual, 1990] 3COM TCP/IP with Demand Protocol, Architecture Programmer s Reference manual, Part No , December [Algers S., Bernauer E., Boero M., Breheret L., Taranto C.D., Dougherty M, Fox K., Gabard J.F. 1997] Algers S., Bernauer E., Boero M., Breheret L., Taranto C.D., Dougherty M, Fox K., Gabard J.F., Review of Micro-Simulation Models, SMARTEST report, [Archibald J., Baer J.L., 1986] Archibald J., Baer J.L., Cache Coherence protocols: Evaluation using a Multiprocessor Simulation Model, ACM Transactions on Computing Systems, Vol.4, No.4, November 1986, pp [Argile A.D.S., 1995] Argile A.D.S., Distributed Processing in Decision Support Systems, Ph.D.Thesis, Nottingham Trent University 1995, Nottingham, England. [Argile A., Peytchev E., Bargiela A., Kossonen I. 1996] Argile A., Peytchev E., Bargiela A., Kossonen I. Dime: A Shared Memory Environment For Distributed Simulation, Monitoring And Control Of Urban Traffic, 8th European Simulation Symposium, Genoa, Italy, ISBN , Vol.1, pp [Arnold L., 1972] Arnold L., Stochastische Differentialgleichungen, Oldenburg Verlag, Munchen, [Ashok K., Ben-Akiva M., 1993] Ashok K., Ben-Akiva M., Dynamic Trip Table Estimation for Real-Time Traffic Management Systems, Proceedings of the 12th International Symposium on Transportation and Traffic Theory, Berkeley, California, [Baras J.S., Levine W.S., Dorsey A.J., Lin T.L., 1979] Baras J.S., Levine W.S., Dorsey A.J., Lin T.L., Advanced Filtering and Prediction Software for Urban Traffic Control Systems, Transportation Studies Centre, University of Baltimore, MD,

217 [Barcelo J., 1988] Barcelo J., 1988, Artificial Intelligence and Simulation: Applications in Simulation of the Urban Traffic, Automatica e Instrumentacion 181, 1988, [Bargiela A., 1985] Bargiela A., An algorithm for observability determination in water system state estimation, IEE Proc., Part D, 132, pp , [Bargiela A., Hainsworth G. D., A] Bargiela A., Hainsworth G.D., Telemetry system design and on-line decision support with TCLAS software, presented at the international conference Computer applications for water supply and distribution, Leicester, September [Bargiela A., Hainsworth G. D., B] Bargiela A., Hainsworth G.D., Confidence Limit Analysis in water systems, presented at the international conference Computer applications for water supply and distribution, Leicester, September [Bargiela A., Hainsworth G. D., 1989] Bargiela A., Hainsworth G.D., Pressure and flow uncertainty in water systems, ASCE Journal of Water Resources, Planning and Management, Vol. 115, 2, March 1989, pp [Bargiela A., Hartley J. K., 1993] Bargiela A., Hartley J.K., An X11 Industry Standard Implementation of the Telemetry Confidence Limit Analysis, presented at the international conference Integrated computer applications in water supply, Leicester, September [Bell M.C., Bretherton R. D., 1988] Bell M.C., Bretherton R. D., Ageing of fixed time traffic signal plans, Proc. IEE, on Road Traffic Signalling, Institution of Electrical Engineers, London 1988, pp [Bell M.C., Gault H. E., 1982] Bell M.C., Gault H. E., An empirical study of plan change algorithms for area traffic control systems, Proc. IEE, 2nd International Conference on Road Traffic Control, Institution of Electrical Engineers, London 1982, pp [Bell M.G.H., 1984] Bell M.G.H., Variance and covariance for origin-destination flows when estimated by Log-linear models, Transportation Research, Vol. 18B, pp ,

218 [Bell M.G.H., 1984] Bell M.G.H., Log-linear models for the estimation of origin-destination matrices from traffic counts: an approximation, Proceedings of 9th International Symposium of Transportation and Traffic Theory, VNU, Delft, Netherlands, 1984, pp [Bell M.G.H., 1991a] Bell M.G.H., The estimation of origin-destination matrices by constrained generalized least squares, Transportation Research, Vol. 25B, pp , [Bell M.G.H., 1991b] Bell M.G.H., The real-time estimation of origin-destination flows in the presence of platoon dispersion, Transportation Research, Vol. 25B, pp , [Ben-Akiva M., Koutsopoulos H.N., Mukundan A., 1994] Moshe Ben-Akiva, Haris N. Koutsopoulos, Anil Mukundan, A Dynamic Traffic Model System For ATMS/ATIS Operations, IVHS Journal, 1994, Vol. 2(1), pp [Ben-Akiva M., Kaysi I., 1991] Ben-Akiva M., Kaysi I., Dynamic Driver Behaviour Modelling for Advanced Driver Information Systems, 6th International Conference on Driver Behaviour, Quebec City, Canada, [Benekohal R.F., Abu-Lebden G., 1994] Benekohal R.F., Abu-Lebden G., Variability Analysis of Traffic Simulation Outputs: Practical Approach for TRAF-NETSIM, Transportation Research Record, Vol. 1, part I 1457, 1994, pp [Bennett J., Carter J., Zwenepoel W., 1990] Bennett J., Carter J., Zwenepoel W., Munin: Distributed Shared Memory Based on Type-Specific Memory Coherence, Proceedings of 1990 Conference on Principles and Practice of Parallel Programming, ACM Press, New York, pp [Bielli M., Reverberi P., 1996] Bielli M., Reverberi P., New Operations Research and Artificial Intelligence approaches to traffic engineering problems, European Journal of Operational Research 92(1996), Elsevier, pp [Bisiani R., Forin A., 1988] Bisiani R., Forin A., Multilanguage Parallel Programming of Heterogeneous Machines, IEEE Trans. Computers, Vol.37, No8, Aug. 1988, pp

219 [Bisiani R., Ravishankar M., 1990] Bisiani R., Ravishankar M., Plus: A Distributed Shared-Memory System, Proceedings of 17th International Symposium Computer Architecture, IEEE CS Press, Los Alamitos, California, Order No.2047, 1990, pp [Blaukerborn R.C, May A.D., 1972] Blaukerborn R.C, May A.D., FREQZ: A revision of the FREQ freeway model, Special Report, Institute of Transportation and Traffic Engineering, University of California, Berkeley, CA, [Calvin, J. O., Chiang C. J., Van Hook D. J., 1995] Calvin, James O., Chiang C. J., Van Hook D. J., Data Subscription , Twelfth Workshop on Standards for the Interoperability of Distributed Simulations, March 13-17, [Calvin, J. O., Van Hook D. J., 1994] Calvin, J. O., Van Hook D. J., AGENTS: An Architectural Construct to Support Distributed Simulation, , Eleventh Workshop on Standards for the Interoperability of Distributed Simulations, September 26-30, [Calvin, J.O., Weatherly R., 1996] Calvin, James O., Richard Weatherly, An Introduction to the High Level Architecture (HLA) Run-Time Infrastructure (RTI), , Fourteenth Workshop on Standards for the Interoperability of Distributed Simulations, March 11-15, [Cantarela G.E. et al. 1993] Cantarela G.E., DiGangi M., Gunn H., Kroes E., Dynamic Traffic Assignment, Report on DYNA, DRIVE II project, [Cascetta E., 1984] Cascetta E., Estimation of Trip Matrices from Traffic Counts and Survey Data: A Generalised Least Squares Estimator, Transportation Research-B, Vol. 18B, No. 4/ 5, 1984, pp [Cascetta E., Nguyen S., 1988] Cascetta E., Nguyen S., A Unified Framework for Estimating or Updating Origin/ Destination Matrices from Traffic Counts, Transportation Research-B, Vol. 22B, No. 6, 1988, pp

220 [Chandler R.E., Herman R.C., Montroll E.W., 1958] Chandler R.E., Herman R.C., Montroll E.W., Traffic dynamics: Studies in carfollowing model, Operational Research 6, 1958, pp [Chang G., Wu J., 1994] Chang G., Wu J., Recursive Estimation of Time-Varying Origin-Destination Flows from Traffic Counts in Freeway Corridors, Transportation Research, 28B, No2, pp , [Chard B.M., Lines C.J., 1987] Chard B.M., Lines C.J., TRANSYT - the latest developments, Traffic Engineering and Control 28 (718), 1987 [Cheriton D.R., 1986] Cherion D.R., Problem-Oriented Shared Memory: A Decentralised Approach to Distributed System Design, Proceedings of Sixth International Conference on Distributed Computing Systems, May 1986, pp [Cremer M., 1983] Cremer M., Determining the Time-Dependent Trip Distribution in a Complex Intersection for Traffic Responsive Control, IFAC 4th International Conference on Control in Transportation Systems, Baden-Baden, Germany, 1983, pp [Cremer M., Keller H. 1981] Cremer M., Keller H., Dynamic identification of flows from traffic counts at complex intersections. Proceedings of 8th International Symposium of Transportation and Traffic Theory, University of Toronto Press, Toronto, 1981, pp [Cremer M., Keller H. 1984] Cremer M., Keller H., A systems dynamics approach to the estimation of entry and exit O-D flows. Proceedings of 9th International Symposium of Transportation and Traffic Theory, VNU, Delft, Netherlands, 1984, pp [Cremer M., Keller H. 1987] Cremer M., Keller H., A new class of dynamic methods for the identification of origin-destination flows, Transportation Research, 1987, B21, pp [Delp G., 1988] Delp G., The Architecture and Implementation of Memnet: A High-Speed Shared Memory Computer Communication Network, doctoral dissertation, University of Delaware, Newark, Del.,

221 [Dennis J.E. Jr., Schnabel R.B., 1983] Dennis J.E. Jr., Schnabel R.B., Numerical Methods for Unconstrained Optimization and Nonlinear Equations, Prentice-Hall, Englewood Cliffs, N.J., [Drouin M., Abou-Kandil H., Dib G., Bertrand P., 1983] Drouin M., Abou-Kandil H., Dib G., Bertrand P., A new approach for real-time control of urban traffic networks, IFAC 4th International Conference on Control in Transportation Systems, Baden-Baden, Germany, 1983, pp [Eldor M., 1977] Eldor M., Demand predictors for computerised freeway control system, Proceedings of the 7th International Symposium on Transportation and Traffic Theory, Institute of Systems Science Research, Kyoto, Japan. [Etches, A., Claramunt, C., Bargiela, A., Kosonen, I., 1999] Etches, A., Claramunt, C., Bargiela, A., Kosonen, I., An Inter-operable TGIS Model for Traffic Systems, In Innovations in GIS VI, Gittings, B. (ed.), Taylor & Francis, 1999 in press. [Euler G. 1988] Euler G Issues in real-time control of traffic, Workshop report. Management and Control of Urban Traffic Systems. US Engineering Foundation Press. New York. pp [Eykhoff P., 1974] Eykhoff P., System Identification, North-Holland, Amsterdam, [Fleish B., Popek G., 1989] Fleish B., Popek G., Mirage: A Coherent Distributed Shared Memory Design, Proc. 14th ACM Symposium on Operating Systems Principles, ACM, New York, 1989, pp [Fox K., 1999] Fox, K. Transferability of urban micro-simulation methods, Paper presented at the 31st Annual Conference of the Universities Transport Studies Group, held at the University of York, January (1999) [Fox K., Clark S. 1998] Fox K., Clark S. Evaluating the benefits of a responsive UTC system using microsimulation, Paper presented at the 30th Annual Conference of the Universities Transport Studies Group, held in Dublin, January (1998). 205

222 [Fox K., Clark S., Boddy R., Montgomery F.O., Bell M.C., 1998] Fox K., Clark S., Boddy R., Montgomery F.O., Bell, M.C., Some benefits of a SCOOT UTC System: An independent assessment by micro-simulation, Traffic Engineering and Control, 39(9), (1998). [Friesz T., Stough R. 1992] Friesz T., Stough R. On Predictive Models of Dynamic Urban and Regional Network Flows, paper presented at the North American Meetings of the Regional Science Association, Chicago, Illinois, [Gabard J.F., 1991] Gabard J.F., Car-Following Models, in: Papageorgiou M.(ed.), Concise Encyclopaedia Of Traffic & Transportation System Pergamon Press, Oxford, 1991, ISBN , pp [Gabrys B., Bargiela A., 1996] Gabrys B., Bargiela A., Integrated Neural Based System for State Estimation and Confidence Limit Analysis in Water Networks, Proceedings of European Simulation Symposium ESS 96, Genoa, October 1996, ISBN (Vol.2), pp [Ganslaw M.J., Schaake J.C., 1973] Ganslaw M.J., Schaake J.C., A volume and speed predictor for UTCS/BPS second generation software, Final report prepared for TRW systems, Houston, TX, [Gartner N., Gershwin S.B., Little J.D.C. 1980] Gartner N., Gershwin S.B., Little J.D.C., Pilot study of computer-based urban traffic management, Transportation Research B 14, 1980, pp [Gazis D.C., Herman R.C., Potts R.B., 1959] Gazis D.C., Herman R.C., Potts R.B., Car-following theory of steady-state flow, 1959, Operational Research 7, pp [Gershwin S.B., Little J.D.C., Gartner N. 1978] Gershwin S.B., Little J., Gartner N., Computer-assisted traffic engineering using assignment, optimal signal setting and modal split, US Department of Transportation, Report No. DOT-TSC-RSPA-78-10, [Gipps P.G., 1981] Gipps P.G., A behavioural car-following model for computer simulation, Transportation Research B15, 1981, pp

223 [Gipps P.G., 1986] Gipps P.G., A model for the structure of lane-changing decisions, Transportation Research B20, 1986, pp [Goodwin G.C., Payne R.L., 1977] Goodwin G.C., Payne R.L., Dynamic System Identification: Experiment design and Data Analysis, Academic Press, New York, [Grau, R.; Barcelo, J. 1992a] Grau, R.; Barcelo, J.; PACKSIM: an experience in using traffic simulation in a demand-responsive traffic control system, Departament d'estadistica i Investigacio Operativa, Seccio d'informatica, Universitat Politecnica de Catalunya, Research Report 92/05. [Grau, R.; Barcelo, J. 1992b] Grau, R.; Barcelo, J.; A review of objective functions in the CARS demandresponsive traffic control system, Departament d'estadistica i Investigacio Operativa, Seccio d'informatica, Universitat Politecnica de Catalunya, Research Report. [Grau, R.; Barcelo, J. 1993] Grau, R.; Barcelo, J.; The design of GETRAM: A Generic Environment for Traffic Analysis and Modelling, Departament d'estadistica i Investigacio Operativa, Seccio d'informatica, Universitat Politecnica de Catalunya, September 1993, Research Report. [Hainsworth, G.D. 1988] Hainsworth, G.D., Measurement Uncertainty in Water Distribution Telemetry Systems, Ph.D. Thesis, Nottingham Polytechnic, [Hartley J.K., 1996] Hartley J.K., Parallel Algorithms for fuzzy data processing with application to water systems, Ph.D. Thesis, The Nottingham University, [Hall M.D., Van Vliet D., Willumsen L.G. 1980] Hall M.D., Van Vliet D., Willumsen L.G., Saturn: A simulation assignment model for the evaluation of traffic management schemes, Traffic Engineering and Control, 21(4), 1980, pp [Herman R. et al. 1959] Herman R. et al. Traffic Dynamics: Analysis of stability in car following, Operational Research 31, 1959, pp

224 [Hill M. D., 1998] Hill M. D., Multiprocessors should support simple memory-consistency models, Computer August 1998, pp [Holtz A., Much C., Goblick T., Corbett E., Waxman A., Ashok K., Ben-Akiva M., Koutsopoulos H.N., 1992] Holtz A., Much C., Goblick T., Corbett E., Waxman A., Ashok K., Ben-Akiva M., Koutsopoulos H.N., A Distributed Hierarchical System Architecture for Advanced Traffic Management Systems and Advanced Traffic Information Systems, in Proceedings of the Second Annual Meeting of IVHS AMERICA, Newport Beach, CA, [Hunt P.B., Robertson D.I., Bretherton R.D., Winton R.I. 1981] Hunt P.B., Robertson D.I., Bretherton R.D., Winton R.I. SCOOT - A Traffic Responsive Method of Coordinating Signals, TRRL Laboratory Report 1014, [Improta G., Allsop R.E., Heydecker B.G., 1986] Improta G., Allsop R.E., Heydecker B.G., Network models fro traffic management, International Seminar on Management and Planning of Urban Transport Systems from Theory to Practice, Unversite de Montreal, Centre de Recherche sur les Transports, Montreal, Canada, [Kaltenbach M., 1984] Kaltenbach M., Network Flow Modelling for Traffic Control, Unversite de Montreal, Centre de Recherche sur les Transports, Montreal, Canada, Publication No.348, [Kaysi I., 1992] Kaysi I., Framework and models for the provision or real-time driver information, PhD thesis, Department of Civil Engineering, Massachusetts Institute of Technology, [Kaysi I., Ben-Akiva M., de Palma A. 1992] Kaysi I., Ben-Akiva M., de Palma A. Design Aspects of Advanced Driver Information Systems, Second International Seminar on Urban Traffic Networks, Capri, Italy, [Keller H., Ploss G., 1987] Keller H., Ploss G., Real-Time Identification of O-D flows from Counts for Urban Traffic Control, Proceedings of the 10th Conference on Transportation and Traffic Theory, Cambridge, Massachusetts, USA 1987, pp

225 [Kessaci A., Farges J.L., Henry J.J., 1989] Kessaci A., Farges J.L., Henry J.J., On-Line Estimation of Turning Movements and Saturation Flows in PRODYN, IFAC Proceedings of the 6th Symposium on Transportation, Paris, France, 1989, pp [Kessler R.E., Livny M., 1989] Kessler R.E., Livny M., An Analysis of Distributed Shared Memory Algorithms, Proc. 9th International Conference on Distributed Computing Systems, CS Press, Los Alamitos, California, Order No.1953, June 1989, pp [Kimber R.M., Daly P.N., 1986] Kimber R.M., Daly P.N., Time-dependent queuing at road junctions. Observation and prediction, Transportation Research B 20(3), 1986, pp [Kosonen, I., 1996] Kosonen I., HUTSIM - Simulation Tool for Traffic Signal Control Planning, report for Licenciate degree, Laboratory of Transportation Engineering, the Helsinki, University of Technology. [Kosonen, I., Bargiela, A., Claramunt, C., 1998] Kosonen, I., Bargiela, A., Claramunt, C., 1998, A Distributed Information System for Traffic Control. In Proceedings of the Xth European Symposium in Simulation Systems, Nottingham, A. Bargiela and E. Kerckhoffs (eds.), pp [Kosonen, I.; Pursula M., 1990] Kosonen, I., Pursula, M., A simulation tool for traffic signal control planning. Third International Conference on Road Traffic Control. IEE Conference Publication Number 320. London [Koutsopoulos H., 1992] Koutsopoulos H., Parallel Computing in Transportation Modelling, Second International Seminar on Urban Traffic Networks, Capri, Italy, [Koutsopoulos H., Xaiping Xu 1993] Koutsopoulos H., Xaiping Xu, An Information Discounting Routing Strategy for Advanced Traveller Information Systems (ATIS), Transportation Research C, Vol. 1C, No3, pp , [Lamport L., 1979] Lamport L., How to make a multiprocessor computer that correctly executes multiprocessor programs, IEEE Trans. Computers, Vol. C-28, No 9, Sept. 1979, pp

226 [Lenoski D. et al., 1990] Lenoski D. et al., The Directory-Based Cache Coherence Protocol for the DASH Multiprocessor, Proceedings of 17th International Symposium Computer Architecture, IEEE CS Press, Los Alamitos, California, Order No.2047, 1990, pp [Leonard D.R., Tough J.B., 1979] Leonard D.R., Tough J.B., Validation work on CONTRAM - A model for use in design of traffic management schemes, Planning and Transport Research and Computation Summer Annual Meeting, Transport and Road Research Laboratory, Crowthorne, UK, [Lesort J.B., Tardieu B., Lebacque P., 1982] Lesort J.B., Tardieu B., Lebacque P., Short-term traffic flow prediction in urban networks, Proceedings of International Conference on Road Traffic Signalling, IEE, Stevenage, UK, [Lesort J.B. 1991] Lesort J.B., Prediction of traffic flow, in: Papageorgiou M.(ed.), Concise Encyclopaedia Of Traffic & Transportation System Pergamon Press, Oxford, 1991, ISBN , pp [Li K., 1986] Li K., Shared Memory on Loosely Coupled Multiprocessors, PhD thesis, Department of Computer Science, Yale University, [Li K., Hudak P., 1989] Li K., Hudak P., Memory Coherence in Shared Virtual Memory Systems., ACM Trans. Computing Systems, Vol.7, No.4, Nov. 1989, pp [Ljung L., 1987] Ljung L., System Identification - Theory for the User, Prentice-Hall, Englewood Cliffs, N.J., [Lotan T., Koutsopoulos H., 1993] Lotan T., Koutsopoulos H., Approximate Reasoning Models for Route Choice Behaviour in the Presence of Information, Proceedings of the 12th International Symposium on Transportation and Traffic Theory, Berkeley, California,

227 [Lowrie P.R., 1982] Lowrie P.R., The Sydney Coordinated Adaptive Traffic System - Principles, Methodology, Algorithms, Proceedings of IEE International Conference on Road Traffic Signalling, 1982, pp [Lum M., Kinney L.L., Kumar K.S.P., 1983] Lum M., Kinney L.L., Kumar K.S.P., Feasibility of a Distributed Computer Traffic Control System, IFAC Control in Transportation Systems, Baden-Baden 1983, pp [Mahmassani H., Hu T., Jayacrishnan R., 1992] Mahmassani H., Hu T., Jayacrishnan R., Dynamic Traffic Assignment and Simulation for Advanced Network Informatics, Second International Seminar on Urban Traffic Networks, Capri, Italy, [Mahmassani H., Jayacrishnan R., 1991] Mahmassani H., Jayacrishnan R., System Performance and User Response Under Real-Time Information in a Congested Traffic Corridor, Transportation Research A, Vol. 25A, No5., pp , [The MathWorks, Inc., 1993] The MathWorks, Inc., System Identification Toolbox for Use with MATLAB, User s Guide, 24 Prime Park Way, Natick, Mass., , [May A., Keller H.E. 1967] May A., Keller H.E., Non-integer car-following models, Highway Research Board, (199):19-32, [McDonald M., Hounsell N.B., 1991] McDonald M., Hounsell N.B., Road Traffic Control: TRANSYT and SCOOT, in: Papageorgiou M.(ed.), Concise Encyclopaedia Of Traffic & Transportation System Pergamon Press, Oxford, ISBN , pp [McGarry, S. M., DiCaprio P. N., Weatherly R., Wilson A., 1996] McGarry, S. M., DiCaprio P. N., Weatherly R., Wilson A., Design Issues for the High Level Architecture (HLA) Run-Time Infrastructure (RTI) Prototype Version 0.2, , Fourteenth Workshop on Standards for the Interoperability of Distributed Simulations, March 11-15,

228 [McShane W.R., Lieberman E.B., Goldblatt R., 1976] McShane W.R., Lieberman E.B., Goldblatt R., Developing a predictor for highly responsive system-based traffic signal control, Transportation Research Rec., 596, [Messmer A., Papageorgiou M., 1990] Messmer A., Papageorgiou M., METANET: a macroscopic simulation program for motorway networks, Traffic Engineering + Control, September 1990, pp [Michalopoulos P.G., 1986] Michalopoulos P.G., Macroscopic Models of Traffic Flow for Simulation and Control, Proceedings of Symposium on Traffic Control Systems, Institut Catala per al Desenvolupament del Transport Generalitat de Catalunya, Barcelona, Spain, [Morin J.M., 1985] Morin J.M., SIMAUT: Un programme de simulation du traffic autoroutier, INRETS Report No.4, 1985, INRETS, Arcueil, France. [Nguyen S., 1984] Nguyen S., Estimating Origin-Destination Matrices from observed flows, In M. Florian (Ed.), Transportation Planning Methods, North Holland, Amsterdam, 1984, pp [Nguyen S., Morello E., Pallotino S., 1988] Nguyen S., Morello E., Pallotino S., Discrete Time Estimation Model for Passenger Origin/Destination Matrices on Transit Networks, Transportation Research-B, Vol. 22B, No. 4, 1988, pp [Nihan N., Davis G., 1987] Nihan N., Davis G., Recursive Estimation of Origin-Destination Matrices from Input-Output Counts, Transportation Research-B, Vol.21B, No. 2, 1987, pp [Nicholson H., Swann C.C. 1974] Nicholson H., Swann C.C. The prediction of traffic flow volumes based on spectral analysis, Transportation Research 8., 1974, pp [Nitzberg B., Lo V., 1991] Nitzberg B., Lo V., Distributed Shared Memory: A Survey of Issues and Algorithms, IEEE Computer, August 1991, pp

229 [Norton J.P., 1986] Norton J.P., An introduction to identification, Academic Press, [Papageorgiou M., Blosseville J.M., Hadj-Salem H. 1990] Papageorgiou M., Blosseville J.M., Hadj-Salem H., Macroscopic modelling of traffic flow on the Boulevard Peripherique in Paris, Transportation Research, B23, 1989, pp [Papageorgiou M. 1991] Papageorgiou M. Concise Encyclopaedia Of Traffic & Transportation System Pergamon Press, ISBN , 1991, pp [Parsonson S.L., 1970] Parsonson S.L., Pure Mathematics, Volume 1., Cambridge University Press, UK, [Payne H.J., 1971] Payne H.J., Models of freeway traffic and control, Simulation Council Proceedings, Vol , pp [Peytchev E., Bargiela A., 1998] Peytchev E., Bargiela A., Traffic Telematics Software Environment, 10th European Simulation Symposium, Nottingham, UK, October 26-28, 1998, pp [Peytchev E., Bargiela A., Gessing R. 1996] Peytchev E., Bargiela A., Gessing R. A Predictive Macroscopic City Traffic Flows Simulation Model, 8th European Simulation Symposium, Genoa, Italy, ISBN , Vol.2 pp [Peytchev E.T., Bargiela A., 1995] Peytchev E.T., Bargiela A., Parallel Simulation of City Traffic Flows using PADSIM (Probabilistic ADaptive SImulation Model), European Simulation Multiconference ESM'95, Prague, 1995, Eds. M. Snorek, M. Sujansky, A. Verbraeck, June 1995, ISBN , pp [Peytchev E.T., Bargiela A., 1994] E Peytchev, A Bargiela, Micro Simulation of City Traffic Flows in Support of Predictive Operational Control, 10th Int. Conference on Systems Engineering, ICSE'94, Coventry, Sept. 1994, ISBN , pp

230 [Pipes L.A., 1953] Pipes L.A., An operational analysis of traffic dynamics, application in Physics 24, 1953, pp [Rathi A.K., Santiago A.J., 1990] Rathi A.K., Santiago A.J., The new NETSIM simulation program, Traffic Engineering and Control, May 1990, pp [Reid J.K., 1975] Reid J.K., A sparsity-exploiting variant of the Bartel-Golub decomposition for linear programming bases, Report CSS 20, AERE Harwel, [Reushel R., 1950] Reushel R., Fahrzeugbewegungen in der Kolonne bei gleichformig beschleunigtem oder verzogertem, Leihtfahrzeug. Z. Osterr. Ing. Arch. Ver. 95, pp , 73-77, [Roberts P.D., Ben-Israel A., 1970] Roberts P.D., Ben-Israel A., A suboptimisation method for interval programming: A new method for linear programming, Linear Algebra and its applications, 3, pp , [Robertson D. I. 1969] Robertson D. I., TRANSYT Methods for area traffic control, Traffic Engineering and Control, October 1969, pp [Ross D.W. et al., 1977] Ross D.W., Humphrey T.L., Mahoney E.E., Sandys R.C., Williams G.L., Wohnoutka R., Wong P.J., Zeidler H.M., Improved control logic for use with computercontrolled traffic, Report NCHRP3 18(1), Stanford Research Institute, Menlo Park, CA. [Rowe E. 1988] Rowe E., The Los Angeles ATSAC system, Management and Control of Urban Traffic Systems, US Engineering Foundation Press, New York, pp [Satyanarayanan Mahadev 1990] Satyanarayanan Mahadev, Carnegie Melon University, Scalable, Secure, and Highly Available Distributed File Access, Computer May 1990 pp

231 [Schweppe F.C., 1968] Schweppe F.C., Recursive State estimation: Unknown but bounded errors and system inputs, IEEE transactions AC, Vol. AC-13, No. 1, Feb [Schwerdtfeger Th. 1984] Schwerdtfeger Th. DYNEMO: A model for the simulation of traffic flow in motorway networks, 9th International Symposium on Transportation and Traffic Theory, VNU, Utrecht, [Sims A. G. 1979] SIMS A. G The Sydney coordinated adaptive traffic system Research Directions in Computer Control of Urban Traffic Systems. American Society of Civil Engineering, New York pp [Sterling, M., Bargiela A., 1984 a] Sterling, M., Bargiela A., Minimum norm state estimation for computer control of water distribution systems, IEE Proc., 131(2), pp , [Sterling, M., Bargiela A., 1984 b] Sterling, M., Bargiela A., Leakage reduction by optimised control of valves in water networks, Trans. Inst. Meas. Control, 6, pp , [Sterling, M., Bargiela A., 1985] Sterling, M., Bargiela A., Adaptive Forecasting of Daily Water Demand, Comparative Models for Electrical Load Forecasting, pp , [Soderstrom T., Stoica P., 1989] Soderstrom T., Stoica P., System Identification, Prentice-Hall International, London, [Stumm M., Zhou S. 1990] Stumm M., Zhou S. Algorithms Implementing Distributed Shared Memory, Computer May 1990, pp [Taylor, N.B. 1990] Taylor, N.B. CONTRAM 5: An Enhanced Traffic Assignment Model, Transport and Road Research Laboratory, Department of Transport, UK, Research Report 249,

232 [Todd J., 1977] Todd J., Basic Numerical Mathematics 2: Numerical Algebra, Birkhauser-Verlag, Basel, [Van Hook D. J., Calvin J. O., Smith J. E., 1995] Van Hook D. J., Calvin J. O., Smith J. E., Data Consistency Mechanisms to Support Distributed Simulation, , Twelfth Workshop on Standards for the Interoperability of Distributed Simulations, March 13-17, [Van Hook, D. J., Brittain E. A., 1995] Van Hook, D. J., Brittain E. A., An Implementation of a Data Consistency Mechanism, , Thirteenth Workshop on Standards for the Interoperability of Distributed Simulations, September 18-22, [Vincent R.A., Mitchell A.I., Robertson D.I., 1980] Vincent R.A., Mitchell A.I., Robertson D.I., User guide to TRANSYT Version 8, Department of Transport, TRRL Report No. LR 888, Transport and Road Research Laboratory, Crowthorne, UK, [Vythoulkas P.C., 1993] Vythoulkas P.C., Alternative Approaches to Short-Term Traffic Forecasting for Use in Driver Information Systems, 12th International Symposium on Transportation and Traffic Theory Berkeley, California, USA July, 1993, pp [Walski T.M., 1983] Walski T.M., Technique for calibrating network models, Journal of Water Resources Planning and Management, ASCE, Vol.: 109, No. 4, Oct [Walski T.M., 1984] Walski T.M., Analysis of water distribution systems, VNR New York [Walski T.M., 1985] Walski T.M., Assuring accurate model calibration, Journal of AWWA, Vol. 77, No. 12, Dec [Warnstmis P., 1978] Warnstmis P., Simulation of traffic flows through interchange systems of arbitrary configuration, System Development Corporation, Contract No.FH , Federal Highway Administration, Washington DC,

233 [Wattleworth J.A., 1976] Wattleworth J.A., Traffic Flow Theory, In: Baerworld J.E., edition Transportation and Traffic Engineering Handbook, Prentice Hall, Englewood, NJ, [Whittaker J., 1993] Whittaker J., A State Space Prediction System for Interurban Traffic Networks: Specification and Some Results, working paper, Lancaster University, [Willumsen L.G., 1984] Willumsen L.G., Estimating Time-Dependent Trip Matrices from Traffic Counts, Proceedings of the 9th International Symposium on Transportation and Traffic Theory, Delft, The Netherlands, 1984, pp. [Winer B.J., Brown D.R., Michels K.M., 1991] Winer B.J., Brown D.R., Michels K.M., Statistical Principles in Experimental Design, University Press, USA, 1991, ISDN [Yang H., Sasaki T., Iida Y., 1992] Yang H., Sasaki T., Iida Y., Estimation of Origin-Destination Matrices from Link Traffic Counts on Congested Networks, Transportation Research-B, Vol. 26B, No.6, 1992, pp [Yang Q., 1997] Yang Q., A simulation laboratory for Evaluation of Dynamic Traffic Management Systems, Ph.D. thesis, Department of Civil and Environmental Engineering, Massachusetts Institute of Technology, USA, June [Zhou S., Stumm M., McInerney T., 1990] Zhou S., Stumm M., McInerney T., Extending Distributed Shared Memory to Heterogeneous Environments, Proceedings of 10th International Conference on Distributed Computing Systems, CS Press, Los Alamitos, California, Order No.2048, May-June

234 Appendix A. Example screens. Quaker Way St. Peters Way A617 Bridge Street Portland Str. Portland Str. St. Peters Way Nottingham Road Inductive loop numbers Inductive loops Nottingham Road - A60 Scale 1: 2 Appendix A, Figure 1: SCOOT controlled traffic network in Mansfield, Nottinghamshire. Inductive loop counts shown as cyan and purple areas. (Scale: 1 pixel corresponds to 2 meters) A-1

235 Communication Module - Live Data Connection to SCOOT Queue Lengths Scale 1: 0.5 Appendix A, Figure 2: On-line connection to SCOOT system for Mansfield area, Nottinghamshire. Lengths of the queues at 15h 35min 36sec shown as cyan rectangles. (Scale: 1 pixel corresponds to 0.5 meters) A-2

236 Appendix A, Figure 3: Distributed shared memory manager program - example screen. Display illustrating the work of a distributed shared memory manager program with one client named DSCOO connected to the system and one created area named M14. A-3

237 PREDICTED VALUES Prediction: Queue lengths with the confidents limits of the prediction On-Line Data Queue lengths Scale 1: 1 Appendix A, Figure 4: PADSIM macroscopic simulation model - queue prediction example screen. The on-line queue length data is shown in green colour superimposed on the traffic map and the predicted queue for four consecutive cycles is shown next to the link. The two black lines alongside the predicted queues show the calculated confidence limits of the prediction. (Scale: 1 pixel corresponds to 1 meter) A-4

238 Scale 1: 0.25 Appendix A, Figure 5:Microscopic traffic simulation model - example screen. (Scale: 1 pixel corresponds to 0.25 meters) A-5

239 Appendix A, Figure 6: Nottingham Traffic Control Centre - working with SCOOT traffic control system. A-6