PROJECT REPORT November 2005

Transcription

1 PROJECT REPORT November 2005 Portland State University Intelligent Transportation Systems Laboratory Prof. Robert L. Bertini Technische Universität München Chair of Traffic Engineering and Control Prof. Fritz Busch Imperial College London Centre for Transport Studies Prof. Michael G.H. Bell

2 1 Content 1 Content Introduction... 4 Empirical Comparison of German and U.S. Traffic Sensor Data And Impact On Driver Assistance Systems Portland State University PSU Outline Problem Statement Objectives of the Study Research Tasks PSU Current status Introduction Results Conclusions PSU Outlook PSU Collaboration PSU General Annotations by the Peers Technische Universität München: Traveltime Prediction TUM Outline Problem statement and objectives Organization of the Project TUM Current status Basics and Overall Approach Deriving Link Traveltimes: Traffic Model based Approach Data based Approach: Analysis and Preparation of relevant Data Sources TUM Outlook TUM Collaboration TUM General Annotations by the Peers Intelligent Adaptive Route Guidance Reliable Dynamic Route Guidance Imperial College London ICL Introduction ICL Reliable Dynamic Route Guidance ICL Outline ICL Current status ICL Outlook ICL Adaptive Multi-Criteria In-Vehicle Navigation ICL Outline ICL Current status ICL Outlook Offensive Project Summaries Page 2 of 108

3 5.3.4 ICL Collaboration ICL General Annotations by the Peers Conclusions Annex Detailed Reviews and Responses Peer Review Meeting November 24, PSU TUM Peer Review Meeting June 27, PSU TUM ICL Reliable Dynamic Route Guidance ICL Adaptive Multi-Criteria In-Vehicle Navigation Offensive Project Summaries Page 3 of 108

4 2 Introduction Klaus Bogenberger and Hartmut Keller Overall goals OFFENSIVE is a continuing research and development programme of the department of Traffic Technology (EW-1) within the BMW Group. The objective of this programme is to achieve research results in traffic technologies of the highest standards according to the BMW policy being leader in traffic telematics services. This is also reflected in contributions and publications in leading national and international journals and in the participation in international conferences and symposia. OFFENSIVE stands - within a comprehensive and integrated approach - for three lines of interdependent research: Theoretical work for the development of traffic oriented models based on mathematics or simulation. Empirical analyses of data generation and data fusion to be provided as input to traffic flow and impact modelling. Development of environments for the evaluation of traffic models and traffic control strategies based on the empirical data and theoretical work. Great importance is given to high quality presentations and within this context to the visualisation of the research results. BMW monitors the research activities via a continueing process of quality control by a peer review of the results achieved. This Project Report refers to the third generation of activities within OFFENSIVE. The first generation of research was dedicated to traffic flow simulation and the interaction between driver, vehicle, and traffic. The activities within the second generation were algorithms for automatic incident detection, modelling of accident occurrence and of the traffic impacts of driver assistance systems. Focus of this third generation of OFFENSIVE is research to support the development of vehicle based traffic information systems, in particular of dynamic routing within in-vehicle navigation systems. Three Subprojects of Dynamic Routing Within the project dynamic routing there are three subprojects and involved contractors: Dynamic Optimisation in networks introducing user preference of navigation systems and including traffic assignment strategies o Contractor: Imperial College London Travel time estimation and forecast across different network classes o Contractor: Munich University of Technology Analysis of Bottlenecks on high quality roads o Contractor: Portland State University. Offensive Project Summaries Page 4 of 108

5 Core of this approach is the development of control strategies for dynamic routing recommendations in road networks. In this context the complexity of user und system optimum is considered as well as the dynamics of traffic flows as a consequence of the acceptance of route recommendations, being individually or collectively initiated, by the divers and considering the fuzziness from low density traffic detections. The control strategies for the dynamic routeing are initiated event oriented. Therefore models are necessary which can detect these events. Automatic incident detection is therefore also here still important for network sections with low level sensing. Travel time estimations are therefore to be modelled considering these events either detected or modelled. This is also true for travel time forecasts with a time horizon of some two hours, if the variability of the effects of control measures and driver acceptance are respected. An essential part of this approach is a total quality management of the complete value chain, in particular by filtering emerging errors starting with data collection. Research Themes and Responsibilities The objective of research on dynamic routing within OFFENSIVE is to secure the high quality standards of vehicle based information systems. The focus here is to develop a gold standard for route recommendations, which can be a reference for the strategies of existing navigation systems. To be able to assess the quality of these different algorithms, empirical studies will carried out to be able to compare and evaluate their performance. Evaluation criteria are travel times, including the reliability of their forecasts, the quality of the routes selected assessed with respect to defined decision criteria such as traffic safety, tourist goals, trip length and availability in time. These problems are addressed on three levels of research, which are interrelated. BMW Group EW-1 is responsible for the project management. Dynamic Optimisation of Routeing in Road Networks The top level of dynamic routing is the development of optimal strategies for the dynamic route recommendations. The differences between user und system optimum are considered as well as the acceptance of the recommendations by the drivers. This includes research on the adaption to user preferences in navigation systems and developing methods for automated learning user preferences in parallel to the development of reliable dynamic route guidance. For the first analysis an urban network of Central London will be used, while the routing algorithms are being developed independent of local network topologies. It is expected that from the comparison between the gold standard to be developed for dynamic routing und the actually offered routing strategies in commercial systems in-depth knowledge can be identified for marketing these products. Responsibility: Imperial College London (Prof. M. Bell). Offensive Project Summaries Page 5 of 108

6 On-Line Forecasts of Travel Times The second level of research are travel time forecasts in networks. Travel time forecasts are determined on-line for midterm time horizons, that means for half an hour to one hour, depending on the size region and network extension considered. Factors influencing the travel times are the network topologies, urban streets and rural roads and freeways, weather, and road surface conditions as well as the driver and vehicle populations involved. The regional network of the City of Munich and the State of Bavaria are used as a reference, including urban arterials and motorways. Traffic data for the motorways are available from the BMW REFER project and for the urban network from projects such as MOBINET and INVENT. The quality of this data are to be improved according to the requirements of the routing algorithms considering in particular the procedures of automatic incident detection such as the BMW sponsored AZTEK algorithm. Responsibility: Munich University of Technology (Prof. F. Busch) Analytical Analysis of Bottlenecks and Traffic Congestion The identification of the traffic congestion and in particular of its spatial location is - depending on the type of sensing - still a problem and at the same time a very important information for any traffic control strategy. First traffic studies showed that the comparison of the time series and accumulation of traffic volumes and speeds at consecutive locations of measurement offers chances to identify congestion as well as its location within these sections. More research will be put into the promising analytical procedures to get more knowledge on traffic congestion generation and its dissemination. Time space diagrams will be used to visualise the propagation of speed contours and shock waves of congestion phenomena. Detailed traffic data are available for the motorway A9 North of Munich from previous BMW studies. Responsibility: Portland State University (Prof. R. Bertini) Structure of the Dynamic Routeing Project Report In this Project Report the first findings are documented of the research activities of the three research institutions. The table of contents of the report follows the structure of the levels of research activities described above. Each theme by contractor is reported by the following sections: outline, current status, outlook, collaborations and response to the peer reviews. Offensive Project Summaries Page 6 of 108

7 Empirical Comparison of German and U.S. Traffic Sensor Data And Impact On Driver Assistance Systems Executive Summary November 2005 Steven Boice and Prof. Robert L. Bertini Intelligent Transportation Systems Laboratory, Portland State University The objectives of this project are to conduct an empirical analysis of features of traffic dynamics and driver behavior on German and U.S. highways. The project has included the application of revolutionary analytical tools to empirical data archived in both Germany and the U.S. Through this analysis, an innovative comparison has been made between the behavior of German and U.S. drivers as they approach and pass through freeway bottlenecks. This has provided, for the first time, a direct comparative analysis of German and U.S. freeway data, and has contributed toward a greater understanding of differences in driver behavior in the two countries. In turn, this understanding will allow for improved travel time estimation and forecasting which will lead toward improved traffic management, traveler information and driver assistance systems. The project has focused on the identification and causation of several recurring bottlenecks on a section of Autobahn 9 (A9) between Munich and Nürnberg using archived inductive loop detector data. Bottlenecks have been identified, and their capacities and apparent causes have been measured. Two flows identified as the pre-queue and queue discharge flows have been found to vary by approximately 0-10 percent on freeways around the world based on previous research. Based on this analysis, an average flow drop of 8 percent upon bottleneck activation was measured which is consistent with other documented research. Shock speeds ranging from 6-20 km/hr were measured which is also consistent with previous research. Of relevance, these measurements can be used to measure the capacity of the freeway, predict queue propagation and recovery parameters and serve as significant inputs to traffic models as well as provide guidance to planners and designers. This freeway also segregates measured traffic parameters by vehicle type (auto and truck), allowing additional insights to be gleaned from the analysis that are not possible at other sites. In addition to traffic sensor data, this section of freeway is equipped with a variable speed limit system that adapts its speed based on traffic dynamics. The system utilizes dynamic message signs located overhead that present drivers with the regulatory speed and any warnings or prohibitions that may be active. Analysis targeted the relationship between the variable speed and measured changes in traffic flow states. Large fluctuations in traffic flow were found to trigger decreases in the variable speed limit and truck passing restrictions were found to be active prior and during bottleneck activation. Measurements concluded a high level of driver compliance and the effects the system had on the dampening of traffic congestion. Offensive Project Summaries Page 7 of 108

8 3 Portland State University 3.1 PSU Outline Problem Statement There is an increasing need to focus on improving the safety, efficiency and convenience of travel on the world s transport systems. Increasingly, the world s economy feels the impact of congestion, crashes and the value of time for people and goods. With this in mind, intelligent transport systems have been designed to save lives, time and money. From the infrastructure-based system perspective, government agencies have implemented numerous highway surveillance, operations and management systems. These systems all generate data that can be used for evaluating the systems themselves as well as for modeling the impacts of proposed changes to the system. Increasingly the data generated by these infrastructure-based systems can be used to unlock a greater understanding of the dynamics of traffic flow and driver behavior an outcome that has been desired for more than fifty years of traffic research. In turn, this greater understanding can be used to improve the ways in which traffic is modeled, travel time is predicted and control actions area applied. Further, private manufacturers have developed and implemented vehicle-based driver assistance and monitoring systems throughout the world. These systems generate floating car data and are sometimes linked with infrastructure based sensor data. There is a great potential for synergy by merging these two data sources and applying comprehensive analysis techniques in order to reveal new information concerning driver behavior and improve methodologies applied for measuring and predicting travel time on a real time basis. These results will contribute to an improved understanding of the differences between German and American driver behavior and will also improve traffic management and traveler information systems. Finally, it will also be possible to improve the accuracy and reliability of travel time prediction for in-vehicle driver information and navigation systems and improve driver assistance systems such as cruise control and lane change assistance systems Objectives of the Study The objectives of this project are to conduct an empirical analysis of features of traffic dynamics and driver behavior on German and U.S. highways. The project will include a thorough literature review of recent German and U.S. analyses of traffic dynamics as well as the application of revolutionary analytical tools to empirical data archived in both Germany and the U.S. Through this analysis, an innovative comparison will be made between the behavior of German and U.S. drivers as they approach and pass through freeway bottlenecks. This will provide, for the first time, a direct comparative analysis of German and U.S. freeway data, and will contribute toward a greater understanding of differences in driver behavior in the two countries. In turn, this understanding will allow for improved travel time estimation and forecasting which will lead toward improved traffic management, traveler information and driver assistance systems. The study outputs will include a technical report, a software package, and two technical journal/symposium publications. Due to the availability of archived freeway data from both Germany and the U.S., a reliable methodology for empirical freeway bottleneck analysis, it is anticipated that the study objectives can be achieved in a reasonable amount of time Research Tasks The following tasks will be completed: Offensive Project Summaries Page 8 of 108

9 Task 1: Literature Review The research team will review relevant, recent international scientific literature relating to empirical analysis of traffic dynamics. The principal investigator has co-authored several important scientific papers in recent years, and through previous research assignments is also familiar with other international research results in the area of traffic dynamics. In recent years, the Berkeley methodology has been applied to archived traffic data from North American sites, but has not yet been applied to German freeway locations. The literature review will include careful analysis of empirical analyses of German freeway data, and will include a summary table of results claimed by other authors using other methodologies. Deliverable: Literature summary and table of prior research results. Task 2: Site Selection and Reconnaissance During this task, German and U.S. freeway sites will be selected. It is likely that a section of the A9 Motorway in Germany and Interstate 5 in Oregon (U.S.) will be selected as the corridors of focus. Also during this task, all appropriate maps, aerial and ground level photographs, archived inductive loop detector data, probe vehicle data (including data from passenger cars in Germany and Oregon as well as incident response vehicles and buses in Oregon). In addition, variable message sign (VMS) display information will also be collected from both selected sites. Task 3. Data Preparation In this task, the research team will perform basic data organization, cleaning, and will prepare basic performance measures (flows, speeds, occupancies) for each detector location, including mainline lane-by-lane analysis and on-ramp and off-ramp analysis. Data from the sources described in Task 2 will be fused along spatial and temporal dimensions. Using a web-based interface, the research team will prepare a comprehensive archive database with links to the maps, detector locations, raw data and performance characteristics. Task 4: Preliminary Data Analysis In earlier studies, the principal investigator has examined traffic conditions upstream and downstream of freeway bottlenecks located near busy on-ramps and several reproducible features have been observed. For example, it was shown for the first time that bottlenecks could be identified definitively in the temporal and spatial dimensions. It was also possible to clearly identify periods during which the bottlenecks were active, ensuring that a queue was present upstream, and no queue spillover was impacting bottleneck flow downstream. This analysis made it possible to identify important traffic flow features that were previously in doubt. For example, very high bottleneck flows were measured for extended periods before queueing eventually occurred immediately upstream of the bottlenecks, giving rise to lower average discharge rates. In particular, periods of rather low discharge flow accompanied the onset of upstream queueing. While the bottlenecks were active, the average discharge flows were observed to be nearly constant and did not vary considerably from day to day. To promote the visual identification of time-dependent features of the traffic stream, these previous studies used transformed curves of cumulative vehicle count and curves of cumulative occupancy constructed from data measured at neighboring freeway loop detectors (referred to as the Berkeley method). These cumulative curves, displayed on a skewed axis provided the measurement resolution necessary to observe the transitions from freely-flowing to queued conditions and to identify a number of notable, time-dependent traffic features in and around the bottleneck. The Berkeley method will also be used in this study for the first time using German freeway data. Offensive Project Summaries Page 9 of 108

10 In this task, the Berkeley method will be applied to one typical day s German data set collected under Task 2. The researchers will develop a comprehensive description of the evolution of traffic flow during one day for each site, including identifying the locations and activation times of bottlenecks, measurement of their traffic flow characteristics, and preliminary identification of their reason(s) for formation. Graphical tools will be used to document and display these results, and preliminary software for analysis will be developed and tested in the research lab environment. Task 5: Preliminary Empirical Comparison The research team will qualitatively compare the preliminary results from the German freeway site to previous results from U.S. freeway sites. This will include contrasts and comparisons with other published results that have used German data but not the Berkeley method. These measurements will include travel time estimates, which can be used to improve in-vehicle navigation and driver assistance systems such as cruise control and lane change assistance systems. Also, estimates of net lane changing will be computed, which can help improve driver lane positioning systems. To the extent possible, at this stage, the impacts on traffic modeling and forecasting will be highlighted. The researchers will also attempt to highlight any evident differences in German and U.S. driver behavior. Task 6: Interim Report During this task the researchers will prepare an interim report documenting the results of Tasks 1-5. The format of the report will be agreed upon between the research team and the sponsor, with the intent that the report will serve as a basis for a scientific abstract/ article for submittal to a journal or symposium. Deliverable: A working paper will be prepared and the principal investigator will present interim results in Munich approximately at the project midpoint (the targeted timeframe would be Summer 2003 if the project begins in early 2003). Task 7: Final Data Analysis The researchers will continue the analysis begun in Task 4 above using data from other days on the same sites in order to confirm whether the preliminary findings are reproducible. The same analysis pattern will be followed, thus streamlining the activities under this task. The team will summarize the key traffic flow features that are found to be reproducible and will respond to comments and questions arising during Task 6. Also during this task, the research team will perform analyses of the U.S. freeway location as a continuation of the empirical comparisons begun in Task 5. The software tools will be finalized and tested for submittal to the sponsor. Task 8: Final Report During this task, the research team will incorporate sponsor comments from the Interim Report and will fully document the results of the entire project. The format of the report will be similar to that of the Interim Report and will be aimed at serving as one or more scientific articles for presentation at a symposium or publication in a journal. Deliverable: A final report will be prepared and the principal investigator (and possibly student research assistant) will present final results in Munich at the end of the project. The final report will also include a software package containing the analysis procedures and demonstrators. The project team will also prepare two scientific papers for submittal to transportation journals/symposia. Offensive Project Summaries Page 10 of 108

11 3.2 PSU Current status Introduction The objectives of this project are to conduct an empirical analysis of features of traffic dynamics and driver behavior on German and U.S. highways. This project attempts to analyze freeway traffic dynamics on an 18-kilometer section of Autobahn 9 (A9) between Munich and Nürnberg, Germany (see Figure 1). Analysis has focused on the identification and causation of several reoccurring bottlenecks throughout the corridor using archived inductive loop detector data for the days of June 24 July 8, 2002 and May 21, N Distances [meter]: Kilometer markers: Loop Detector Stations: AQ201 AQ202 AQ204 AQ206 AQ208 AQ210 AQ212 AQ213 AQ214 AQ215a Figure 1: Site Map Unique among empirical freeway analyses, the identification of a bottleneck within a particular freeway segment has been characterized as a location along the freeway that featured unqueued traffic downstream and queued traffic upstream. The construction of transformed cumulative vehicle count and time averaged speed for both autos and trucks aided with providing the resolution necessary to characterize traffic conditions over a freeway segment and to identify bottleneck activation locations and times. Evidence such as decreases in average flow accompanied by decreases in average speed has been used as an indicator of the transition from unqueued to queued traffic states. Upon identification of an active bottleneck, its effects can then be traced propagating upstream and downstream. Given the bottleneck s precise activation and deactivation times, its discharge flow (often referred to as ca- Offensive Project Summaries Page 11 of 108

12 pacity) can be measured. This propagation is referred to as the shock speed and was measured at each respective inductive loop detector station with its accuracy limited to the one-minute aggregation of the data. The capacity of the bottleneck was measured as the flow leaving the bottleneck and was measured by lane. These measurements were compared to other research that has been conducted on freeways in the United States, Canada, United Kingdom, and Germany. For isolated bottleneck activations (preceded by freely flowing traffic) this comparison was directed toward the measurement of flows prior and during bottleneck activation. For the non-isolated bottleneck activations, only the queue discharge flows are compared. The two flows identified as the pre-queue and queue discharge flows have been found to vary by approximately 0-10 percent on freeways around the world based on previous research. Based on this analysis, an average flow drop of 8 percent upon bottleneck activation was measured which is consistent with other documented research. Shock speeds ranging from 6-20 km/hr were measured which is also consistent with previous research. Of relevance, these measurements can be used to measure the capacity of the freeway, predict queue propagation and recovery parameters and serve as significant inputs to traffic models as well as provide guidance to planners and designers. This freeway also segregates measured traffic parameters by vehicle type (auto and truck), allowing additional insights to be gleaned from the analysis that are not possible at other sites. In addition to traffic sensor data, this section of freeway is equipped with a variable speed limit system that adapts its speed based on traffic dynamics. The system utilizes dynamic message signs located overhead that present drivers with the regulatory speed and any warnings or prohibitions that may be active. Analysis targeted the relationship between the variable speed and measured changes in traffic flow states. Large fluctuations in traffic flow were found to trigger decreases in the variable speed limit and truck passing restrictions were found to be active prior and during bottleneck activation. Measurements concluded a high level of driver compliance and the effects the system had on the dampening of traffic congestion Results Bottleneck Analysis In the portion of this study focusing on the diagnosis of freeway bottlenecks, analysis revealed that bottleneck activations occurred at predictable and recurring locations and were found to be isolated and non-isolated. Isolated bottleneck activations were consistently located near busy freeway on- and off-ramps and non-isolated bottlenecks were activated by the arrival of an upstream moving queue. Examples of bottleneck activations and deactivations, as well as the tracing of major disturbances are shown in Figure 2. Surges in demand on both the freeway ramps and the mainline have been identified as the primary contributing factors to bottleneck activations. As shown in Figure 3, observations of surges in trucks traveling in the median and center lanes prior to bottleneck activation have also been identified as contributing factors. An important note is that the regulatory speed for trucks is 80 km/hr at all times compared to 120 km/hr for autos, thus the movement of large, slower moving vehicles into a faster moving traffic stream may have significant impacts on the disruption of the mainline. The presence of trucks across all travel lanes may also have the effect of creating a wall of slower moving traffic, thus preventing vehicles wishing to travel faster from doing so. Offensive Project Summaries Page 12 of 108

13 Figure 2: Speed Contour Diagram Table 1 summarizes the measured bottleneck capacities for the A9. It also shows measured prequeue flows. Bottleneck capacity measurements were found to be consistent with those measured along freeways around the world. An average decrease in flow of 8 percent was observed between pre-queue and bottleneck discharge flows. Average shock speeds ranging from 6-20 km/hr were observed and some seen to travel a distance of 14 kilometers upstream. Narrow shocks such as those observed on the A9 have not been documented on North American freeways. The measurements are consistent with previous research and are hoped to contribute to the development of more accurate driver assistance systems. Figure 3: Truck Flow Trigger June 28, 2002 Offensive Project Summaries Page 13 of 108

14 Table 1: Summary of Bottleneck Features Pre-Queue Pre- Queue Discharge Discharge Shock Flow Duration Flow Flow Flow Flow Speed Day Date Isolated (vph) Duration (vph) Drop (km/h) Thu 6/28/02 Yes 0: : % /28/02 0: /28/02 0: /28/02 1: Wed 6/27/02 Yes 0: : % /27/02 0: Tue 6/26/02 Yes 0: : % Mon 7/2/02 Yes 0: : % Tue 7/3/02 Yes 0: : % /3/02 1: Wed 7/4/02 3: Thu 7/5/02 Yes 0: : % Mean: Standard Deviation: Handbuch für die Bemessung von Strassenverkehrsanlagen (HBS) 2001 Highway Capacity Manual (HCM) Bottleneck capacities were compared to those that would be expected from the U.S. Highway Capacity Manual (HCM) and the German Handbook for the Calculation of Traffic Systems (HBS). The comparison between the HCM and HBS is shown in Figure 4. One of the significant differences between the two manuals is the HCM s use of passenger car equivalents (pce). All trucks, buses, and recreational vehicles are converted to passenger cars to create uniformity since these types of vehicles possess different operating characteristics. The HBS methodology is based on percent heavy vehicles in the traffic stream. Capacity is defined as 1,800 vehicles per hour per lane (vphpl) for three lane Autobahns and 1,900 vphpl for two lane Autobahns with 10-percent heavy vehicles according to the HBS. The HCM identifies capacity as 2,286 vphpl which includes a proportion of 10-percent heavy vehicles and is equivalent to 2,400 passenger cars per hour per lane. The average pre-queue flow measurement for northbound A9 was 1,910 vphpl and 2,030 vphpl for southbound A9. Northbound A9 consists of three travel lanes and southbound 2 lanes where analyzed bottleneck activations occurred. The measured values are approximately 100 vphpl greater than would be expected respectively. These values are still however lower than would be expected based on the HCM. Driver behavior and the use of ramp metering in the U.S. may be a large contribution to the difference in estimated capacity. Offensive Project Summaries Page 14 of 108

15 Speed - Flow Relationship FFS = No limit; 120km/hr Level Terrain 0-20% Trucks 3 - lane facility Average Speed (km/hr) Flow (veh/hr) HBS q-v 0% HBS q-v 10% HBS q-v 20% HCM q-v 0% HCM q-v 10% HCM q-v 20% Figure 4: Speed Flow Relationship (HCM/HBS) Variable Speed Limit System The portion of the study that examined the impact of the variable speed limit system sought to determine the relationship between the variable speed limit system and actual traffic dynamics and determined that the changes in speed were adaptive to changes in traffic flow. Figure 5 shows a sample of the variable speed limit designations for one day. Fluctuations in traffic flow were identified that triggered the posted reduced speed limit. Figure 6 shows the difference between actual measured speed and the speed limit displayed on the VSL system. Measuring vehicle compliance revealed that the majority of drivers were in compliance with the speed indicated overhead, however truck speeds were km/hr above the regulatory 80 km/hr. Truck passing restrictions were consistently activated prior and during bottleneck activation. Analysis however revealed that truck movements were taking place prior to bottleneck activation when the restrictions were active. Movements occurred near busy freeway ramps which serve as indication that trucks are moving into the center and median lanes to travel around the entering and exiting freeway traffic Extended Floating Car Data A reference vehicle equipped (see Figure 7) with a global positioning device while traveling through the corridor has provided highly detailed data revealing the dynamics of the vehicle as it traveled through congested areas. This high resolution data has indicated precise beginning and ending times of congestion and has helped to estimate freeway travel times. Estimates of freeway travel times have been estimated using approximates based on inductive loop detector data and compared with those of the actual reference vehicle. Offensive Project Summaries Page 15 of 108

16 80 Bottleneck Active Between Legend Figure 5: May 21, 2003 Southbound Variable Speed Limit Bottleneck Active Between Sign AQ 215a = -1 km/hr Sign AQ 214 = -6 km/hr Figure 6: Speed Contour (Actual Speed VSL) Offensive Project Summaries Page 16 of 108

17 Figure 7: May 21, 2003 Southbound Floating Car Run 1 Figure 8: June 27, 2002 Northbound A9 Type 5 ASSIST Messages Offensive Project Summaries Page 17 of 108

18 BMW ASSIST Data Information pertaining to levels of congestion presented to drivers by an in vehicle navigation system were analyzed in concert with both the infrastructure-based sensor data and the variable speed limit system data to determine their accuracy as compared with measured traffic conditions. The system presented drivers the location and extent of estimated congestion in terms of kilometer to kilometer marker. Figure 8 shows an example. This analysis has revealed that the system presented a fairly accurate estimation of congestion parameters to the driver in advance of the anticipated congestion. The parameters were however found to be delayed which is likely due to processing time. This is illustrated in Figure 9 which shows the difference between the VSL speed designations and the AS- SIST messages. Figure 9: May 21, 2003 Southbound (VSL/ASSIST type 4) Conclusions This project has sought to conduct an empirical analysis of features of traffic dynamics and driver behavior on German and U.S. highways. The project has included a thorough literature review of recent German and U.S. analyses of traffic dynamics as well as the application of revolutionary analytical tools to empirical data archived in both Germany and the U.S. Through this analysis, using innovative methods, a comparison has been made between the behavior of German and U.S. drivers as they approach and pass through freeway bottlenecks. This has provided, for the first time, a direct comparative analysis of German and U.S. freeway data, and has contributed toward a greater understanding of differences in driver behavior in the two countries. In turn, this understanding will allow for improved travel time estimation and forecasting which will lead toward improved traffic management, Offensive Project Summaries Page 18 of 108

19 traveler information and driver assistance systems. The study outputs have included several publications, listed below. Bertini, R.L., Hansen, S. and Bogenberger, K. Empirical Analysis of Traffic Sensor Data Surrounding a Bottleneck on a German Autobahn. Transportation Research Record: Journal of the Transportation Research Board, Washington, D.C., (Paper In Press, also presented at 84th Annual Meeting in January 2005). Bertini, R.L., Boice, S. and Bogenberger, K. Using ITS Data Fusion to Examine Traffic Dynamics on a Freeway with Variable Speed Limits. Proceedings of the 8th International IEEE Conference on Intelligent Transportation Systems, Vienna, Austria, September 13-16, (Paper In Press and will be presented at ITSC in September 2005) Bertini, R.L., Bogenberger, K. and Boice, S. Impact of Variable Speed Limit and Driver Information System on Traffic Dynamics on a German Autobahn: Lessons for U.S. Applications. Proceedings of the 12th World Congress on Intelligent Transport Systems, San Francisco, November 5-10, 2005 (Paper Accepted and will be presented at ITS World Congress in November 2005) Bertini, R.L., Bogenberger, K. and Boice, S. Supporting In-Vehicle Navigation with Traffic Information Contrasting Europe With the U.S. Proceedings of the SAE World Congress, Detroit, Michigan, April 3-6, 2006 (Paper Accepted). Bogenberger, K., Bertini, R.L. and Boice, S. Empirisches Verfahren zur Analyse von Verkehrsdaten. Stra8enverkehrstechnik (to be submitted). Bertini, R.L., Boice, S. and Bogenberger, K. Dynamics of Variable Speed Limit System Surrounding a Bottleneck on a German Autobahn. Transportation Research Record: Journal of the Transportation Research Board, Washington, D.C., (Submitted). 3.3 PSU Outlook During the next year we intend to conduct an international analysis of congestion definitions. The objectives of this study are to conduct an analysis of the definitions of congestion from both the macroscopic and microscopic points of view toward the improvement of traffic information services. The analytical techniques will include a literature review, an anonymous internet-based survey among researchers and practitioners, a comparative analysis of traffic data performance characteristics, and a recommendation for definitions for different categories of traffic conditions. The research will be conducted relative to three regions: Germany, Great Britain and the United States. The following tasks will be completed: Task 1: Literature Review - Macroscopic The PSU research team will review relevant international literature in the public domain and will conduct an examination of different definitions of traffic congestion from a macroscopic perspective. This will include congestion measures that are measured at discrete points, over segments, facilities and corridors. The work of various researchers including Daganzo, Kerner, Keller, Kim, May and various standard references (e.g., the U.S. Highway Capacity Manual) will be included in the literature review. The possible traffic data sources will include loop detector speed/count/occupancy data, CCTV data, incident data reported by traffic management centers and law enforcement agencies, etc. Offensive Project Summaries Page 19 of 108

20 Task 2: Literature Review - Microscopic The PSU research team will review international literature in the public domain related to the measurement of congestion for a single vehicle. This will include probe vehicle based research and other measurement sources. Task 3. Preliminary Congestion Definition In this task the research team will develop and document suggested congestion definitions for a traffic information service, for both macroscopic (flow, average velocity, density, etc.) and microscopic situations (individual vehicles), over various spatial situations. This task will be completed based on the results of Tasks 1 and 2, and will be submitted to the research sponsor for review. Task 4. Survey In this task, the research team will use anonymous internet-based survey methods to ask focused questions of transportation/traffic researchers and practitioners in Germany, the United Kingdom and the United States. The survey will be designed to glean differences in perceptions and definitions for the three geographical regions. The results of the survey will be used to modify conclusions drawn from Tasks 1-3. Task 5: Data Analysis and Testing Based on the results of the above tasks, the PSU research team will conduct analytical tests of the potential congestion measures using field (freeway) data from the three geographical regions, and using probe vehicle data from the three regions. Ideally, the data sources will be from Munich, Portland and London with simultaneous field (sensor) and probe data over one corridor in each city. The data sets will be used to demonstrate the congestion definitions for each situation. Task 6: Final Report During this task, the research team will incorporate sponsor comments and will develop conclusions and recommendations regarding the recommended macroscopic and microscopic definitions of congestion. In addition, we intend to continue several lines of analysis from previous tasks: Task 7: A92 Before and After Analysis In this task we will examine the effects of the VSL system using data from both before and after its implementation. Task 8: Refinement of VSL Analysis Using a more definitive understanding of the A9 VSL algorithm we intend to continue our analysis of the causal relationship between traffic conditions and VSL displays and vice versa. Task 9: ASSIST Analysis We intend to continue examining the efficacy of the ASSIST system vis a vis the actual measured traffic conditions on the A9. Offensive Project Summaries Page 20 of 108

21 Task 10: Offensive Website Development We intend to continue developing and maintaining the Offensive website. 3.4 PSU Collaboration The PSU team has enjoyed a very positive collaboration with experts from BMW, the Technische Universität München (TUM) and Imperial College (IC). The work conducted by PSU has benefited from the reviews by our TUM and IC partners. We have visited both TUM and IC, and appreciated the opportunity to present a lecture at TUM for current traffic engineering students and external partners. In addition to a virtual team meeting in November 2004, the entire team gathered in London in June 2005, and representatives of PSU and IC met in Vienna in September 2005 at the IEEE ITSC. Further, the connections between the U.S., the U.K. and Germany have highlighted both differences and similarities in driving behavior and analytical techniques. We look forward to specific collaboration in several areas: Comparison and potential of applying IC routing algorithms using Portland testbed. Assessment of potential of utilizing TUM system for fusing data from multiple sources, including freeway sensors, buses and taxis. Development of data quality benchmarks that are applicable in Europe and the U.S. (TUM work). Development of microsimulation pre-processing tool using fixed sensor data and data filtering (oblique/cumulative) system. 3.5 PSU General Annotations by the Peers We received many valuable comments from our peers. It was suggested that we examine the impacts of weather in more detail, and we have recently begun to expand our analysis in that direction. The issue of benchmarking for data quality was also suggested and we are developing a means of using lessons learned from various data archiving systems to apply to this project. The addition of valuable German literature about lane control (LC) systems has contributed greatly to our understanding and analysis of driver compliance and the link between traffic theory and the speed and flow thresholds used in the LC system. Our peers also noted that techniques and findings thus far could be extended to incident detection and we are also looking at this issue. It was also pointed out that some of our findings could be tested in other European countries and we are interested in pursing this for other BMW markets. It was also recommended that we further explore the reasons for the differences between the HBS and the HCM, and we are currently working on this topic. Offensive Project Summaries Page 21 of 108

22 OFFENSIVE Traveltime Prediction Executive summary November 2005 Axel Leonhardt and Prof. Fritz Busch Lehrstuhl für Verkehrstechnik, Technische Universität München The expected traveltime and traveltime reliability are two of the most crucial factors that influence individual drivers' route choices and accordingly important input to many telematic applications, such as dynamic route guidance and traffic information systems. A model architecture for estimating and predicting traveltimes as well as quantifying uncertainties has been developed in this project. The model consists of three layers: A static layer, an off-line layer and an on-line layer. The model will be demonstrated on a part of the Munich road network. The static layer holds the static network information and base traveltimes that are calculated using static link and turning movement attributes based on a NavTeq digital map. The network attributes and the base traveltimes are used as fallback solution and as input for the offline and the on-line layer. The off-line layer holds a database of historical traveltimes and statistical measures that describe the variation of traveltimes on the static network over time. In addition, characteristic information is stored to categorize and classify traffic situations (calendar information, external information). The database is fed by multiple data sources. In the on-line layer, taveltimes and other traffic parameters are calculated. These traveltimes and other traffic parameters are used for traveltime predictions based on situation classification via pattern matching and for complementing the off-line layer. The main data sources are probe vehicle data from a local taxi company and the local bus authority. Stationary detector data is used to support situation classification. Buses send their positions every 20 seconds. Bus trip specific characteristics, such as deceleration, stopping and acceleration at bus stops are filtered out by recording typical stopping procedures in order to receive general link traveltimes. Taxis send their positions every one to two minutes. To utilize taxi positions one firstly has to match the taxi positions to the digital map, secondly to find the most probable route a taxi took and thirdly to distribute the calculated traveltime to the links the route consists of. The first and the second task have been solved interactively by matching the positions to a set of probable matched links and then calculating the most probable route between any combination of probable links by applying a link based weight update algorithm that incorporates turning movement delays and prohibitions. The most probable route and links are calculated respecting distances between taxi positions and links and the plausibility of the route. The third task is solved by distributing traveltimes with respect to road categories and turning movements.. Offensive Project Summaries Page 22 of 108

23 4 Technische Universität München: Traveltime Prediction 4.1 TUM Outline Problem statement and objectives Nowadays, there are many telematic applications running, aiming to assist drivers to plan and carry out their trips and to help traffic managers to make traffic more safe and efficient. Among the different parameters describing traffic states, traveltime (or the lost time) is the one that suits best in many situations: It is, contrary to macroscopic traffic parameters like flow or density, an entity that can be directly experienced by the travellers and essentially it influences the quality of travel experienced by the travellers. Assuming rational travellers (homo economicus), it can be stated, that traveltime is the essential parameter influencing individual route choices. So, the traveltime a traveller is likely to encounter on a trip certainly is a parameter of interest, showing the need for traveltime prediction. By definition, uncertainty cannot be excluded from predicted values. Uncertainty in traveltime prediction is caused by several reasons: missing data, varying data quality, assumptions that do not reflect a prevalent traffic situation. So predicted traveltime must not be seen as a crisp value, but as a value attached with reliability and/or uncertainty, expressed by degrees or functions describing a traveltime distribution (to be estimated). On the other hand, besides the expected traveltime, the uncertainty or reliability of the information is a very important attribute to the user (driver, traffic manager). This can be easily illustrated with the following example: Traveller A wants to visit friends. There is no fixed deadline when he needs to reach his destination, but he wants to get there as fast as possible. Among the different alternative routes, he would choose the one that minimizes the expected traveltime. Traveller B needs to get a plane at the airport outside the city. He is quite early, so that he can get to the airport in time using one of three possible routes, assuming no congestion. Traveller B would choose the most reliable route (not necessarily the one that minimizes the expected traveltime, but the one that gives a high probability to arrive at a certain time). So clearly, it makes sense to estimate uncertainty and to incorporate it into subsequent applications. There is different information and there are different assisting telematic applications in use and under development that incorporate uncertainty in order to better respond to the users need. Specifically, under the Offensive project, at the Imperial College London a reliable dynamic route guidance application is under development, incorporating link reliability (reflecting traveltime variations) into the calculation of the best route (which is basically most reliably fulfilling a traveltime constraint). The objectives of this research project are, to develop methods for predicting traveltimes in road networks and quantifying uncertainties of the predicted traveltimes. The methods will be prototypically implemented and demonstrated in a study area in Munich Organization of the Project In order to reach the project objectives, the following tasks are carried out. Offensive Project Summaries Page 23 of 108

24 Task 1 Dynamic traveltime prediction: Applications and Benefits In this workpackage, use-cases of Dynamic traveltime prediction (DTTP) will be analyzed and categorized with respect to the requirements for the DTTP methods. Focus will be given to the reliable dynamic routing applications, as it is the core of the Offensive overall project and links to Offensive partners from the Imperial College London. Results: Overview over use-cases and applications for dynamic traveltime prediction Requirements for dynamic traveltime prediction methods for dynamic routing applications (definition of model output) Task 2 State of the art, assessment and model selection Different approaches for traveltime derivation and prediction will be analyzed and presented. Based on an assessment with regard to the output requirements and the applicability of the methods, an overall model will be developed. The model strongly depends on the available data, and the focus in the data analysis strongly depends on the model chosen therefore, an interaction between Task 2 and 3 will be carried out iteratively. Results: State of the art and assessment of models for traveltime derivation and predictions Formulation of an overall approach to be realized Task 3 Analysis and preparation of relevant static and dynamic data for the Munich Road Network In WP3, the data available in the chosen study area will be analyzed with respect to temporal and spatial availability, data quality (usability), data format and organizational issues. In order to make the traffic data available for DTTP, modules will be developed and implemented that import and convert the data from its original format to the data structure used. To make sure that only valid data will be used, filter algorithms will be developed and applied. This workpackage is carried out in strict conjunction to Workpackage 2, as the method to be used strongly depends on the available data sources. Results: Detailed analysis of the data sources Importing, conversing and filtering methods to make the data available to the DTTP methods Concepts of the data use in the DTTP methods developed here Task 4 Traveltime estimation / calculation methods First of all, methods for estimating / calculating traveltimes will be developed and formulated for the different data sources selected in Task 4 for further use. Results: Formulation of Algorithms for deriving traveltimes from multiple data sources Implementation of the methods in Matlab Link / route traveltimes for the study periods (April 2005, October 2005 January 2006) Task 5 Statistical analysis and Prediction Methods Having derived link traveltimes from different data sources, a statistical analysis will be conducted to generate a basis of traveltimes for prediction based on historical information. Therefore, the various traveltimes calculated from the different sources have to be combined and aggregated and labelled Offensive Project Summaries Page 24 of 108

25 with uncertainty measures to get a consistent basis. Prediction methods using historical data will be formulated based on a classification scheme. In order to respond to abnormal situations and changes in traffic patterns, methods for incorporating (quasi) on-line information into the prediction will be developed. Results: Combination and Aggregation of taveltimes, Traveltime database for prediction purposes Prediction of traveltimes and associated uncertainties based on historical information using a classification method Incorporation of (quasi) on-line information to update traveltime and uncertainty predictions. Task 6 Request- and presentation-layer (GUI) The methods developed in Task 3 to 5 will be implemented in a tool to easily analyse and visualize traffic data and to carry out and present traveltime prediction requests. Results: GUI for importing, cleaning and visualizing traffic data Generation and updating of traveltime database Requesting and presenting traveltime predictions A final report will be produced at the end of the project. Workplan The project is running over three years. The tasks are principally organized as shown in Figure 1. Jun. 04 Sep. 04 Dez. 04 Mrz. 05 Jun. 05 Sep. 05 Dez. 05 Mrz. 06 Jun. 06 Sep. 06 Dez. 06 Mrz. 07 Jun. 07 AP1 AP2 AP3 AP4 AP5 AP6 Figure 1: Workplan Following the workplan, Tasks 1 to 3 are essentially finished and the core tasks (4 and 5) are under development. Note that the tasks strongly interact during the three years of the project. 4.2 TUM Current status This section is subdivided in three sections describing the current status of the research project Basics and Overall Approach Use Cases Generally, there is a strong dependency of the application where the model s output is used in, the available data sources and the overall model-approach. The application defines the models output whereas the available data sources specify the models input. The model developed here should be able to produce input for several applications. Relevant telematic applications aim to inform travelers and to influence their route choice behavior towards minimizing economic costs or maximizing individual profit. Some of them are listed in Table 1. Offensive Project Summaries Page 25 of 108

26 Dynamic navigation systems Dynamic navigation systems (DNS) are on-board systems that aim to inform the driver about the optimal way to a destination by acoustic and visual signals. DNS provide individualized output in the form of recommended routes. Here, DNS can benefit from the traveltime prediction methods here as reliability measures are provided and link interdependencies are investigated and formulated. Pre-Trip Routing Systems Pre-trip routing systems are systems that provide the driver with an optimal way to a chosen destination. No current positioning and re-routing is considered. Individualized traffic information systems Individualized traffic information systems Inform the driver about current traffic states, warn the driver (on trip) and give recommendations for alternative routes (on trip). The information is individualized, meaning that it is spatially and temporally scaled to the individual users' specifications. Dynamic information signs Dynamic information signs display current or future traffic states and warnings / information via text messages and / or visualizations (e.g. colored maps). The information is not individualized, meaning that the information provided does not necessarily cover an individual drivers' route or the time window he wants to make the trip in. Re-routing sings Re-routing signs at route decision points dynamically display recommendations on alternative routes to divert traffic flow from heavily loaded routes to alternative routes (e.g. the three leg freeway in Munich north consisting of A9, A92 and A99). Table 1: Potential applications for traveltime prediction There are also services that combine several functionalities. BMW ASSIST provides onboard applications like routing and traffic information, as well as an internet service including trip planning and pretrip traffic information. ASSIST is an individualized service. The applications require different spatial and temporal prediction horizons, outputs' accuracies and customized formulations of the predicted traveltimes' uncertainty. Although principally open, the model used here shall serve as a traveltime predictor and network reliability estimator for dynamic routing applications, so that the model requirements can be formulated as follows: Model Requirements Traveltimes need to be predicted in that way, that dynamic routing can be carried out. Traveltimes should be linked to and hence ideally directly modelled on a digital map that can be used for routing (directed graph with turning restrictions, geometric and design attributes). The prediction horizon has to cover a trip in time and space. The methods are to be demonstrated for a reasonable sized part of an urban agglomeration in the north of Munich (as described below). The maximum time horizon will be set to 90 minutes. Recurring traffic disturbances (e.g. peak hour traffic or congestion caused by regular events) should be modeled with high accuracy. Therefore, a statistical component is needed that analyzes traffic and traveltime patterns and their evolvement over time and space. A complex da- Offensive Project Summaries Page 26 of 108

27 tabase is needed, where traffic patterns / traveltimes are stored and can be accessed via calendar and additional information (e.g. inbound traveltime on the A9 on a typical Monday morning between and 09:00 09:30 a.m., or traveltime on the Middle Ring Road on a Saturday afternoon with the local football club having home game). Non-recurring traffic disturbances (e.g. congestion caused by incidents) should be detected and incorporated into the prediction. As prediction takes place in the real world, varying data availability and quality should be considered in the model. That means, the methods should be able to include as many data sources as possible and hence be able to produce high accuracy results. On the other hand, the model should predict traveltimes even if data availability and quality is low (less accurate or less reliable though). Therefore, there need to be back-up layers, providing traveltime information depending on data availability in different qualities. This means basically that there will always be a traveltime prediction available for the considered network. The quality of the prediction varies but by way of a quality measure this is recognized and can be incorporated into the methods. Predictions should be requested easily and results should be presented neatly Overall Approach The developed approach is illustrated in Figure 2. The different boxes and procedures in the diagram are labelled with letters (a) to (n) to be easier referred to later in the text. Network (a) Base Traveltimes (c) Attributes (b) Static Historical Database (e) Traveltime and Traffic State Estimation (f) Historical Traveltimes and Traffic States (g) Statistical Analysis (h) Historical Traveltimes + distributions (i) Traffic Data (d) (quasi) online Data (j) Traveltime and Traffic State Estimation (f) Actual Traveltimes and Traffic States (g) Pattern Matching (k) Situation (l) Off-line On-line Historical Information Actual Data Availability Situation Matching (m) Deliver Request GUI to request and present Predicted Traveltime + Reliability (n) Figure 2: Offensive Traveltime Prediction Concept Static Network: Digital Map The basic layer will be the traveltimes calculated from the link lengths and the associated link speed categories. The link speed categories correspond to the estimated free flow speeds. These traveltimes can be seen as the lower boundaries of the possible traveltimes (free flow traveltimes). The digital map was imported in VISUM and exported into a database, resulting in a table structure that is used throughout the different processing steps. Geo-coded information (e.g. GPS positions) can be matched to the map and then further processed. The map has to provide a high level of detail in order to be able to carry out map matching. Therefore, the links are stored as polylines, representing the true shape of the road network. Offensive Project Summaries Page 27 of 108

28 In order to relate the results to the digital map, the logical structure of the tables is expanded through additional attributes (traveltimes, reliabilities and variances for each source) and a time dimension later in the project. Figure 3: Screenshot of the visualization of the digital map using Matlab Study area The study will be carried out in a testbed in Munich North (in the following referred to as "study area"). The Area expands from the middle Ring Road in the south, to Munich Airport in the north. It contains major points of interest, such as the Airport, the New Munich Trade Fare Centre, the new Munich Football Stadium (Allianz Arena) and the BMW FIZ. Figure 4: Study area "Munich North" Offensive Project Summaries Page 28 of 108

29 The road network consists of an urban road network, freeways (A8, A9, A92, A94 and A99), and federal roads (B11, B13, B304, B388 and B471) Deriving Link Traveltimes: Traffic Model based Approach If talking of traveltime prediction models, one has to differentiate between models to derive traveltimes and models to predict traveltimes. To derive traveltimes, there needs to be a module that extracts link traveltimes from some sort of data. That may be measurements from local detector stations or other detection devices. Generally, link traveltimes may be measured directly, e.g. by floating cars or vehicle re-identification devices or they may be derived from traffic parameters like volume or speed via a traffic model. The first approach to be presented is a traffic model based approach (Figure 5): n typical Measurement Scenarios (time series) Statistical Analysis Plausibility- Checks Historical Data (2003) q Urban Freeway Federal (?) For each Measurement Scenario: 1. Accumulate measurements over day 2. Fit OD matrix to accumulated measurements (VISUM) 3. Dyn. Assignment of the fitted OD matrix Parameter: Profile for each OD pair Parameter optimization via external Module (COM Interface) Objective function: diff(visum link volume measured volume) Turning rates, quasi-dynamic (initially: 15 minutes intervals) VISSIM Simulation, applying the derived turning rates Sets of Travel Times on each Link for the examined Scenario Variation of demand / model parameters Travel Time variability Figure 5: Model based approach for the derivation of historic link travel times Traffic Model based approach: Step 1 Deriving typical traffic scenarios from the detector databases (for the freeways and the urban road network). On the urban roads, there are mainly aggregated link counts in different intervals (5 minutes, 15 minutes). On the freeway network, there are measurements that comply with TLS standard (1 minute intervals: q, v, two vehicle classes). The objective of the analysis is to find typical measurement patterns / scenarios. A measurement scenario consists of the 24 h measurement time series of a set of detectors. 24 h time series are chosen to account for the temporal interdependencies: As network performance is mainly dependent on the traffic load, it is necessary to know the load of the network at a given time and therefore the network load and the demand of the previous x intervals needs to be known. They in turn are dependent on the network load and the demand of the previous x intervals an so on. Likewise, there are spatial interdependencies so that a scenario should not be limited to one detector station but at least to a composition of detectors. So we state, that a scenario should not be limited to one measurement period (e.g. peak traffic flow) and / or one detector station. The objective is to find typical daily and network wide scenarios, e.g. typical Mondays, Saturday before Christmas, and so on. The scenarios found will be used to adjust a given 24 h OD matrix that is available for the test bed and was acquired in the year Traffic Model based approach: Step 2 It is assumed that the origins and destinations are still valid and that the number of trips for each OD pair can be adjusted by using real traffic counts of a given number of links in the network. The OD Matrix will be adjusted in a static manner towards the accumulated 24 h traffic counts of the chosen scenarios, thus getting OD matrices that should fit in sum to the respective scenarios. It would Offensive Project Summaries Page 29 of 108

30 of course be desirable to dynamically estimate OD matrices, accounting for the time varying demand patterns. Nevertheless a static approach is chosen at first because there is a software package ready available that is able to adjust an OD matrix with respect to real measurements. Using that package, the travel time basis can be generated faster than implementing a method for dynamic OD matrix estimation. The adjustment of the OD matrix is carried out by VStromFuzzy, an entropy maximization method implemented in VISUM. Basically, VStromFuzzy is a method for updating an existing travel demand matrix by using current count data taking into account fuzzy values based on traffic flow bundles across network elements. That means the most probable OD matrix is calculated optimizing an objective function consisting of the system entropy and the difference between the estimated link counts and the real link counts. Using suitable shaped and parameterized membership functions (accounting for the variability of demand and the plausibility of detector data, possibly estimated by plausibility checks), a maximum accepted difference between estimated and real traffic counts can be defined while favoring estimated values near real traffic counts. Furthermore, through weights it can be adjusted if more reliance is given to the old OD matrix or the actual traffic counts. The drawback of the method is, as mentioned above, that it can only adjust the matrix in a whole and not the respective OD trip profiles. To account for the dynamics in the system, the OD matrices found for each scenario will be dynamicised in the next step. Traffic Model based approach: Step 3 Flow profiles (percentage of daily demand for each time slice) for each OD pair will be generated in an optimization process. An external module will optimize dynamic traffic assignment of the fitted OD pair and will iteratively solve the objective function: Min (VISUM link volume measured volume). The resulting dynamic traffic assignment will provide turning rates / path choice information. Traffic Model based approach: Step 4 Having generated scenario dependent quasi-dynamic turning rates / path choice information, they will be used as input to a microsimulation to generate quasi-dynamic link travel times for each scenario. Microscopic simulation is a very useful off-line tool, as it generates measured travel times and implicitly considers incidents and the resulting network impacts. Because the off-line application is not timecritical, the main drawbacks (extensive calibration effort and (compared to macroscopic models) the lacking computational efficiency) can be acquiesced. Traffic Model based approach: Step 5 Sets of travel times will be generated for each scenario through the variation of demand and / or turning rates / model parameters. It is expected that the sets of travel times will form a certain distribution, centered around a mean value. In the course of the project, a preliminary simulation study has been carried out using the microscopic simulation model VISSIM based on real traffic data on a stretch of the A94 freeway in the east of Munich (south east border of the study area). The stretch is of particular interest, as it serves as major corridor for commuters from east of Munich and as there is a trade fare center located near exit Munich Riem (Figure 6). Offensive Project Summaries Page 30 of 108

31 Munich Steinhausen Munich Trade Fair Munich East Figure 6: Stretch of the A94 Freeway to be used for generating traveltimes using microscopic simulation (VISSIM) So recurring congestion (caused by commuters), as well as non-recurring congestion (caused by Trade Fare visitors) can be observed. The objectives of the study were: To investigate, if the VISSIM approach principally works for freeways To generate traveltime look-up tables for typical scenarios (averaging) and associated statistical measures (x % percentiles) To generate look up tables for real days (Monday with / without Trade Fare). Therefore, for a period of four months (January April 2004), typical scenarios were generated. Basically, a differentiation between Monday-Thursday, Friday, Saturday & Sunday / Holyday, each with and without trade fare has been made. Average demands, as well as average demands plus one standard deviation were calculated for each scenario and fed into the simulation model. Not surprisingly, one could observe that traffic volume varies over day of week and time of day, as well as between days with and without trade Fare. Feeding the respective traffic volumes in a carefully calibrated VISSIM model, traveltimes for different scenarios were generated. Results indicate that inbound as well as outbound traveltime is substantially higher for typical trade fare scenarios (330 vs. 900 sec. during morning / evening peak, 330 vs. 950 sec. during evening peak). Furthermore, results indicate that outbound traffic (if there is no trade fare) is not dependent on normal fluctuations (expressed by standard deviation), as opposed to inbound traveltimes that show a substantial growth (330 vs sec. during morning peak) under "high" traffic demand compared to normal traffic demand. For any scenario investigated, a time varying traveltime table was generated that can be used as a look up table. Figure 7 shows an example of the inbound traveltime between the Munich East interchange and Munich Steinhausen for a typical Monday (the typical scenario was generated by feeding average Monday traffic volumes to VISSIM) and for a Mondays with high traffic demand (feeding the average plus one standard deviation for Monday traffic volumes to VISSIM). As can be seen, while traveltime is around 380 seconds over the whole day for the typical scenario, significant rise takes place in the morning peak (around 07:00 a.m.) for the high demand scenario. These findings show how the method can be used for applications: If someone has an appointment, then calculating with the high value is appropriate, but generally 380 seconds are the expected trip time. Offensive Project Summaries Page 31 of 108

32 Traveltime on the A94 Freeway on a "typical Monday" and a "Monday with high Traffic Demand" Inbound, Munich East - Munich Steinhausen 1200 Typical Monday 1000 Monday w ith high Demand 800 Traveltime [sec] :00 6:00 8:00 10:00 12:00 14:00 16:00 18:00 20:00 22:00 Time [hh:mm] Figure 7: Traveltimes generated using VISSIM on the A94 Freeway, using typical Monday and Monday with high Traffic demand (95 % percentile) traffic volumes As the outputs' quality of Traffic model based approach presented in heavily relies on the availability and quality of input data (link traffic volumes), stationary detector in the study area have been analysed at first in order to decide if it is worthwhile to carry on with this approach. The analysis shows that the freeway network in the study area is well equipped with stationary detectors, making the application of traffic models a promising approach. The stations are spaced approximately 2 km from each other with most entrance and exit ramps equipped with detectors. A sufficient number of detectors delivers plausible data. Although promising, the presented approach has been dropped because of low data availability and quality in the urban network (see for details). A data based approach, deriving traveltimes directly has been chosen instead Data based Approach: Analysis and Preparation of relevant Data Sources In order to determine the final model architecture, a detailed analysis of the available data sources was conducted, resulting in the choice of which and how data is to be used for traveltime prediction Available Data: Overview Bedsides the NavTeq digital map described in , for the area studied in this project, the following potentially useful data sources are available (in varying spatio-temporal availability): Taxi positions from the IsarFunk taxi Fleet (taxi probes) Positions from the Buses of the local Transport Authority MVG (bus probes) FCD from other sources (BMW, TUM, possibly ddg) Vehicle Re-identification data from license plate recognition systems Measurements from the urban local detector network (different systems, mainly flow) Measurements from the freeway detector network (flow and speed) Additionally, data from the weather radar may be used as additional information. Offensive Project Summaries Page 32 of 108

33 Due to administrative, organizational and technical difficulties, the gathering of the data is a complex process. For evaluations, there are two periods from which the different data sources are available: 1st Period April 2005 (studies on availability and feasibility, development of pre-processing and processing methods) 2nd Period October 2005 January 2006 (application and refinement of methods, generation of time varying traveltime maps) The first step of the study is to analyze the different data characteristics, their respective spatial and temporal availability and the expected quality of the inherent information. In the second step, for each of the data sources, methods for data pre-processing (conversion, formatting and filtering) and processing (generation and structured storing of traveltimes) are developed. ptv Navteq map VISUM ACCESS DB ACCESS DB Taxi positions *.log Files (1 per day) Import ACCESS DB PT Data *.csv Files (1 per day) Import ACCESS DB Freeway detector data *.csv Files (1 per day) Convert *.csv Files Urban det. data *.dmp Files (1 per month) Import ORACLE DB Export Convert *.csv Files FCD xfcd *.log File (1 per trip) *.log Files FCD Vehicle Re-identification *.log File (1 per trip) *.csv Files (1 per day) *.log Files *.csv Files Weather (Radar) *.gif File (96 per day) *.gif Files Figure 8: Overview of available data Taxi Probes Taxis from the IsarFunk (local taxi operator) taxi fleet send their positions with timestamps approximately every on to three minutes. Taxis can be in different states, describing their current actions, like "occupied with passenger" or "occupied with destination". Overall, there are three out of 11 states that can be used for traveltime estimation. After filtering (depending on position and status), there were approximately usable Taxi positions in April In Figure 9, an example is given for deriving link and route traveltime using a taxi probe. The trip has been extracted from a log file provided by IsarFunk imported and visualized on the NavTeq digital map using Matlab (lower right of Figure 9) Offensive Project Summaries Page 33 of 108

34 Figure 9: Example for deriving link and route traveltimes using taxi probes on April 13th 2005 from the Middle Ring Road to Munich Airport As can be seen, Link traveltimes can be extracted, classified and stored in the Traveltime Database as follows: Link Date Day of Week Timeintervall Traveltime [s] Source I 2005/04/13 Wed 16:30-16: Taxi I /04/13 Wed 16:30-16: Taxi.. Table 2: Example for Link traveltimes stored in the traveltime database Also the route traveltime from Freeway entrance A9 Middle Ring to the Airport can be calculated (25 min and 53 seconds) and stored in a separate database. However promising and meaningful the data, there are some challenges associated with the automatic derivation of link traveltimes from taxi probes: Vehicle positions are recorded only every one to three minutes, so that there is no map matching support as the successive GPS positions do not form the shape of the route used by the taxi. If the taxi positions are matched correctly, the (most probable) path between the two positions needs to be found. Generally, the more acceptable alternative paths (having similar costs) are available, the harder it gets to find the correct path. The task gets especially difficult in an urban environment, where many alternative paths are available, since taxi drivers are "experts" and quite often use alternatives to the main roads. Offensive Project Summaries Page 34 of 108

35 triplength, taxi traveltime Matching-Network x 10 6 Routing-Network Matching Box Pos 3 01:46:25 Pos 2 01:44: ? Pos 1 01:42: x 10 6 Figure 10: Illustration of taxi probe Figure 11: Illustration of the route choice problem In order to find the correct positions and the correct paths between them, the following steps are carried out: 1. Matching the positions to all links that are in a certain radius, depending on digital map and GPS accuracy. Exemplary investigation indicates 20 meters to be a reasonable radius. In most cases there are at least two possible matches (each direction is coded as an individual link), near intersections there may be more. 2. Based on the distances to the possible matched links and the trip direction, choose the most probable matches and insert new nodes into the graph (see Fehler! Verweisquelle konnte nicht gefunden werden.) 3. Calculate shortest path between the two matches (here, any shortest path algorithm can be used (computational efficiency is not the issue for an offline application), at the moment Dijkstra's algorithm is used).path finding could be further refined by calculating a set of possible paths and applying additional criteria (e.g. expert knowledge of taxi drivers, making a path that is used more frequently by taxi drivers more likely to be correct path) in order to find the most probable. The result is a path taveltime between the two nodes. That needs to be distributed to the links the path consists of in a sensible manner. Therefore, the following routine is proposed: 1. Calculate free flow Traveltime for all links and link sections the path consists of based on static attributes 2. Subtract the free flow traveltime from the traveltime measured by the probe, deriving a delay 3. If delay is negative: Use free flow traveltime for further processing 4. If the delay is positive: Put the delay to the intersections as that are the most likely places a delay occurs. If there is more than one intersection, delay is spread with respect to the turning movement. If there is no intersection (typical on freeways), delay is automatically add to the link traveltime. Taxi probes form one part of the backbone of the proposed model. 01:36:27 01: Public Transit Public Transit vehicles send their positions as distance from the last stop approximately every 20 seconds. The operating frequency for most of the lines is 1 per 10 minutes between 5:00 AM and 24:00 AM, sometimes being reduced off-peak. Offensive Project Summaries Page 35 of 108

36 Figure 12: Time over space Diagram from buses (Line 140), leaving Frankfurter Ring at Ingolstädter Straße to Paracelsusstraße on April 25th 2005 As the Information is provided regularly and on pre planned routes, bus probes can be planned with in time and space. Basically, the most important links and routes in the urban part of the study area are covered. Map matching is trivial, as routes are known for each bus line. Drawbacks are that bus traveltimes do not equal passenger car taveltimes, due to stopping for boarding and deboarding passengers ( operational cycle ). So observed bus traveltimes provide an upper limit for the link traveltimes (if not calibrated). This has to be taken into account, e.g. by subtracting a factor (may be estimated by using average values or empirically investigated). The data are generally of high quality meaning that most of the trips seam to be plausible. Through appropriate pre-processing / filters, invalid data has to be filtered out. Typical sources for invalid data are buses not resetting at the stops or buses stopping with no obvious reason. Unfortunately, protocols containing information about operational incidents or delay causes is not available (highly sensitive data). While traveltimes can be easily calculated from timestamps and referred to certain stretches on a link or route, these stretches do normally not fall together with the links that form the network for individual transport. Where a pair of positions stretches over two links, the traveltime is added to the upstream link, as it ends with an intersection. If it stretches over more then two links, the traveltime is split up equally between all but the last link Conventional FCD FCD are collected more or less occasionally by BMW and TUM using GPS receivers and software. Compared to Taxi positions, FCD positions come highly frequent (one position per second), making route findings between two positions unnecessary and providing map matching support as the successive GPS positions form the shape of the route used by the probe. Besides the reliable map matching and link traveltime derivation, the frequent positions allow a detailed trip reconstruction, such as delays can be localized highly accurate in time space. Offensive Project Summaries Page 36 of 108

37 However, a traveltime prediction model is not to be based on FCD, as the latter is only available on a non-regular basis. Hence, throughout the project, FCD will be used mainly for validating the link traveltimes calculated by using other data sources and analyzing delays Vehicle Re-identification A direct way to measure traveltimes from stationary detectors is vehicle re-identification. One of the most promising technologies is number plate recognition. By adding time stamps to the number plate information, travel times can be calculated by matching the number plate codes. Depending on the distance between the detectors and the local characteristics of the network, the generated traveltimes can be connected with routes. Figure 13: Positions of vehicle re-identification cameras As some of the re-identified vehicles may use alternative routes or stop between the detectors (e.g. to go shopping), the data series have to be filtered for each possible route. If the filtering is done properly, the generated travel time information is very accurate and allows for statistical analysis due to a high number of samples. The characteristic distribution of the traveltime over time of day of a route can usually be identified using only a few days of data. Mobile detection devices can be used to record travel times on any route. While vehicle reidentification can only generate travel times between to fixed sections, floating car data can be used to identify local bottlenecks in between those profiles. If available online, data from vehicle reidentification may also be used for detecting incidents, especially when flow information from inductive loop detectors is being fused with traveltime information. Donnerstag, Zeitdifferenz Kam 1-Kam2 [hh:mm:ss] Reisezeit [m in] 0:20:00 0:18:00 0:16:00 0:14:00 0:12:00 0:10:00 0:08:00 0:06:00 0:04:00 0:02:00 0:00:00 0:00 1:00 2:00 3:00 4:00 5:00 6:00 7:00 8:00 9:00 10:00 11:00 Uhrzeit [hh:mm] 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 0:00 Figure 14: individual vehicles' traveltimes (blue points) and average traveltime based on historical data basis (orange line ) Offensive Project Summaries Page 37 of 108

38 TUM positioned two re-identification cameras on behalf of BMW EW-3 in the north of Munich (Sudetendeutsche Straße and Ingolstädter Straße, Figure 13) to monitor the traveltimes along this route and hence the delays drivers leaving BMW to the north will encounter over the day. Figure 14 shows the traveltime (y-axis, traveltime in minutes) on a Thursday over the day. Additionally, two mobile cameras are in use at TUM to measure traveltimes on important routes. But like FCD, re-identification cameras are not widely in use yet, so that the output will be used for testing and validation purposes Stationary Detector Data Extensive data surveys including qualitative detector data analysis showed that a lot of stationary detectors do not provide a sufficient level of quality. The analysis shows that the freeway network in the study area is well equipped with stationary detectors, making the application of traffic models a promising approach. The stations are situated approximately 2 km away from each other with most entrance and exit ramps equipped with detectors. A sufficient number of detectors delivers plausible data. However promising the data availability is for the freeway network, that does not apply for the urban road network. Figure 16 shows positions of detectors in the urban road network in the northern part of the study area. Detector data from January to August 2004 have been analyzed in order to assess the usability of an OD Matrix estimation based approach. Colors are indicating the quality or plausibility of the respective detector measurements (traffic volume). Green indicates plausible data for the whole cross section, providing link volumes that could be fed into an OD matrix estimator. Orange indicates partly plausible data (e.g. only one of two lanes), that may allow to reconstruct traffic flows by making certain assumptions (and consequently adding uncertainty to model input). Red indicates totally implausible or missing data. LageMessquerschnitt Position of detector Detektionsrichtung Direction of detected traffic flow GuteQualität Plausible Data (for all lanes) Mittlere Mixed Qualität Quality (z.b.: (e.g. not all lanes detected) SchlechteQualtiät Poor Quality (keine (no data, oder unplausible data) Keine No data available Figure 15: Detector positions and data quality (indicated qualitatively by color) for the Munich urban road network Offensive Project Summaries Page 38 of 108

39 As can be seen in Figure 15, the Middle Ring road and the Frankfurter Ring road are pretty well equipped with (apparently) functioning detectors, whereas the remaining urban road network is not. Figure 16 shows some typical detector mal-functions that could be observed in the analysis. It can be stated that the existing data quality and quantity of stationary detectors is not sufficient for advanced applications Like DTTP. To derive networkwide taveltimes based on stationary traffic data, one would need to make many model-assumptions (it would be "overmodelled"). Therefore, an overall traffic model based approach spanning the freeways, the rural (where no detectors are placed) and the urban roads is not feasible given the current detector equipment. However, stationary detectors are used in the course of the project to describe traffic scenarios (traffic patterns). 500 Det Tag 1 Datatype 1 70 Det Tag 1 Datatype q [Kfz/5min] q [Kfz/5min] :00 4:00 8:00 12:00 16:00 20:00 0:00 7:12 8:24 9:36 10:48 12:00 13:12 14:24 Zeit Time q [Kfz/5min] Det Tag 1 Datatype 1 Figure 16 a-c: Typical detector malfunctions, far to high values for traffic volume (upper left), scattering (upper right), implausible constant traffic volumes over long periods (lower left) :00 4:00 8:00 12:00 16:00 20:00 0:00 Zeit Spatial and temporal coverage Figure 17 gives a rough indication about the overall data availability. As can be seen, in the urban part there is a nearly full coverage with bus- and taxi-probes (yellow shaded areas), whereas on the rural roads taxi probes are available. on the freeways, there are taxi-probes as well as stationary detector data available. Offensive Project Summaries Page 39 of 108

40 Figure 17: Spatial availability of data for the study area Due to their heterogeneous nature, the different data sources do not initially provide a traveltime for each link in every time step. As a matter of fact, each data source will result in a spatially and temporally holey layer, where traveltimes are referenced to different spatial levels (links / routes). Therefore, on the next level, a strategy layer will be established that intelligently combines the information of the different layers. Traveltimes will be stored in a traveltime database where they may be requested by subsequent modules. Offensive Project Summaries Page 40 of 108

41 Data based Approach: Overall Concept and Modules Derivation of Taxi Traveltimes Method as described in Derivation of Bus Traveltimes Method to be defined Derivation of XY Traveltimes Method Classification (Day of Week, Time of Day, Holidays, Events) Integration of traveltimes Filling gaps: spatio-temporal Interpolation Fusion: weighted average Traveltimes (Links und Routes) Local Prediction Maximum Likelihood Local Prediction k-nn Analyse räumlich-zeitlicher Abhängigkeiten ( Link-Interdependenzen ) Correlation analysis Local Prediction Maximum Likelihood + k-nn Networkwide Prediction k-nn Figure 18: Data based approach Concept and methods chosen for further investigation 4.3 TUM Outlook Conduct 2 nd measurement period: Data will be collected for at least four months (October 2005 to January 2006). The following data will be collected: Taxi positions Bus positions Stationary detector data from the freeway and the urban road network Vehicle re-identification data on exemplary routes FCD on exemplary routes Data cleaning: Refinement and implementation of data pre-processing methods (until December 2005). The objective is carry out the complete processing chain data file import to Matlab clean the data export the cleaned data automatically in Matlab routines. Derivation of link traveltimes: Development and testing of methods to automatically calculate traveltimes (until February 2006). Integration / fusion of the taveltimes So far, the individual data sources deliver traveltime information that does not cover the whole network in time and space. For that, a strategy layer needs to be established that generates the most likely traveltime for each link for a given timeintervall (e.g. traveltime on link no. 10 on Tuesday, June 28th 2005 at 09:00 AM). Statistical Analysis of traveltimes Having derived link traveltimes, these need to be statistically analyzed. First of all, the traveltimes need to categorized: Each day (24 h) will be classified hierarchically with respect to events, bank holi- Offensive Project Summaries Page 41 of 108

42 days, days before bank holidays and day of week. So it is firstly checked if there is a major event, than if there is a bank holiday and so on. Having done that, for each class and time interval, the average traveltime will be computed and the distribution of the traveltimes will be estimated. It is assumed that a normal distribution will not fit, however it will be checked if t can be applied for simplicity. The result is a tuple [Expected Traveltime; Variance] for each class for each time interval for each link. Derivation of reliability measures As stated before, traveltime will not only be calculated but also be labelled with reliability measures. The first will be based on the variance of the historical traveltimes in the respective class based on the statistical analysis conducted. The second will indicate if on-line data was incorporated into the prediction. The following may be considered for estimating the reliability of a predicted traveltime: Similarity of the recognized pattern, determined by calculating differences between the real scenario and the most similar scenario in the travel time database Typicality of the scenario, determined by calculating distance metrics between the real scenario and the k nearest scenarios in the travel time database Discrepancy of the results of the different travel time prediction methods used (it is planned: to apply two prediction methods). It is assumed that the probability of a link travel time being true is correlated to the difference of the outcomes of the different methods. Estimated quality of the available data It is important to notice, that there will be two measures of uncertainty regarding traveltimes: The reliability of the traveltime information, which is based on data availability and quality, and the variance of the historical traveltimes. Link interdependency analysis: After having derived link traveltimes, a correlation analysis will be conducted in order discover spatiotemporal dependencies between link states (congested / free) and link state increments (Shift from congested to free and vice versa). Correlation is analyzed for different time slices in order to allow link states to travel through the network. Links to be correlated will be pre selected (adjacent links) so that pseudo correlation can be minimized. Statistical analysis and prediction methods: To actually predict traveltimes, two transparent methods will be applied. The first is the Maximum-Likelihood approach formulated by Lin et Al. for predicting macroscopic traffic parameters such as volume and speed. The approach basically uses the historical distributions 1 of an entity (here: traveltime) and its increment for the horizon (x) to be predicted. The data are preclassified (distributions for typical Mondays and so on). Given an actual traveltime at instant t, the most likely traveltime at instant t + x can be calculated as follows: TT i, t+ x σ = 2 TT, i, t+ x ( µ + TT ) i, TT, t+ x 2 σ TT, i, t+ x i, t+ x + χ σ χ σ 2 TT, i, t+ x 2 TT, i, t+ x µ TT, i, t+ x 1 normal is assumed, distribution described by mean and standard deviation. Normal assumption needs to be tested and possibly replaced Offensive Project Summaries Page 42 of 108

43 The expected traveltime at instant t + x is the average of the actual traveltime plus the historical increment weighted by the standard deviation of the historical traveltime at instant t + x and historical traveltime at instant t + x weighted by the standard deviation of the historical increment. Additionally, the constant χ can be adapted to control the influence of the past. This local prediction method is based on the assumption that characteristics are repetitive and can be described by time series. The second approach to be used for prediction is a k-nearest Neighbour (k-nn) approach. k-nn have been used for traveltime prediction (e.g. Robinson et Al.) and proven to work quite well. It is planned to expand the approach with a spatial dimension, considering not only measurements on one link but also the development on links elsewhere in the network. The challenge will be to select a proper distance metric based on which similarity is calculated. Both methods can also be used if there is no actual data available: It then simply results in the historical taveltime for the instant t + x for the respective class (based on known information like day of week etc.). Visualization: The following steps are carried out to enhance visual representation and to ease data interpretation through visualization: Visual improvement of the network presentation (displaying the map as a real road network considering road categories instead of just drawing lines). Possibly displaying an aerial image as background image. Dynamic visualization of vehicle positions (taxis, buses and floating car). Dynamic visualization of traffic quality through colour coding in order to rapidly identify critical situations. 4.4 TUM Collaboration Due to the project focuses, an interaction between ICL and TUM is strongly desirable. As ICL's ICNavS uses link traveltimes and estimated link reliabilities as an input and TUM's methods are predicting traveltimes and associated uncertainty measures, coordination is needed in order to use synergies. In particular, the following actions need to be harmonized: Data format, static: ICL and TUM are both using NavTeq digital maps. Data format, traveltimes and reliability: TUM received an example data file, explaining the data format used so far. By now, ICNavS uses a single values for the link traveltimes and the associated reliabilities. In the course of the project, it may be defined how time varying information may be incorporated in the system (definition of an interface between TUM methods and ICNavS). Link interdependencies: ICNavS incorporates link interdependencies into the calculation of the shortest paths in order to account for positive (congestions on link A deterioration of traffic quality on link B) or negative (congestions on link A improvement of traffic quality on link B) relations between link performance (and hence reliability). The traveltime database produced by TUM provides a basis for investigating these interdependencies. TUM will therefore carry out a correlation analysis of link performances for a small region in the study area. In a first step, only two states of link performance will be defined: free and congested. Potentially correlated links will be pre selected to exclude pseudo correlations (outlook). Possibility of a real world test (outlook) Offensive Project Summaries Page 43 of 108

44 4.5 TUM General Annotations by the Peers We received many valuable comments from our peers. They pointed out that the data based approach integrating various sources is a promising approach, but there might be a risk to tailoring it to work in Munich and it may be hard to apply the method in other cities. TUM replies that the overall model would work in other environments as well and the actual traveltime estimation methods can be adjusted or extended for other cities. It also was commented that different data sources may result in differing link traveltimes for the same instant. TUM replies that this is incorporated in the statistical analysis. The question was raised how traveltime reliability is defined and calculated. TUM replies that it is calculated based on taveltime variations and data availability. It was agreed by all parties that TUM and ICL should coordinate their activities in order to make TUM's traveltime predictions usable for ICL's route guidance applications. Regarding taxi data it was suggested that the route derivation procedure for taxi data using shortest path algorithms could be enhanced by expert knowledge (e.g. the preference of a main road to a minor road or statements of taxi drivers). TUM replies that this is taken into account be calculating link weights. Regarding bus data it was stated that it would be useful to get hold of information on potential incidents on the line, in order to justify abnormally high traveltimes. TUM replies that there is no way to get this information from the local authority. With regard to the use of the bus data, it was noted that careful attention should be directed towards the filtering of excessive dwell times (stop time). TUM replies that this will be done. The question was raised if pseudo trajectories or trajectories for buses excluding the deceleration, stop, and acceleration time be constructed to serve for travel time estimation. TUM replies that pseudo trajectories will be constructed by recording highly detailed GPS positions (1 position per second) and subtracting "typical" deceleration, stop, and acceleration times. Offensive Project Summaries Page 44 of 108

45 Intelligent Adaptive Route Guidance Executive summary November 2005 Kyounga Park and Prof. Michael G.H. Bell Centre of Transport Studies, Imperial College London Previous studies on in-vehicle navigation usage, route choice criteria, learning algorithms and adaptive route guidance have been reviewed. Many studies on route choice criteria focus on the relative importance of attributes affecting route choice and show that the dependence of driver preferences on situations (e.g. travel distance, trip purpose, etc) leads to conditional interactions between attributes. In order to devise an algorithm for learning user preferences, the advantages and disadvantages of machine learning methods have been compared. The review shows that decision tree learning outperforms other methods. Route strategies adopted in related works on adaptive route guidance are divided into two groups: link-based strategies and route-based strategies. Link-based approaches focus on inferring and updating weights for link attributes, while in the route-based approach, routes are scored. The routing strategy of this study mimics driver route choice rules, which consist of a two-stage process: choice set generation followed by route selection. The process of route generation involves computing weighted link costs and finding plausible candidate routes by the A* algorithm. The process of route selection is carried out by scoring candidate routes. Highest priority is assigned to the route with the highest score and other routes are recommended as alternatives. Attributes are identified according to several considerations: data availability, relative importance, and attribute nature. Attributes are divided into three classes: primary, secondary and other. Provisionally, 15 attributes are classified as primary. Some attributes are directly observable, whereas others require assumptions or data mining. To design learning algorithms, a performance measure and training experience are defined. Based on the literature review on learning algorithms and route choice criteria, the decision tree learning algorithm is considered the most suitable method taking into account human readability and the ability to represent conditional relevance between attributes. The decision tree learning algorithm used most widely is ID3, which utilises a statistical test to determine attributes that best split examples. This test is repeated with other attributes, until the tree perfectly classifies the training examples or until all attributes are tested. The navigation schemes of the parallel study, namely autonomous navigation and supported navigation, are extended to give adaptive autonomous navigation and adaptive supported navigation by including the user preference learning function. Using an agent-based approach, the system architecture consists of four agents in route guidance (i.e. the user interface agent, the route selection agent, the route generation agent and the user model agent), a traffic information DB, and a transport networks DB. Interactions between each agent and each DB server in the new navigation schemes will be formulated. Offensive Project Summaries Page 45 of 108

46 Reliable Dynamic Route Guidance Executive summary November 2005 Ioannis Kaparias and Prof. Michael G.H. Bell Centre of Transport Studies, Imperial College London Efficient and robust route guidance algorithms have been devised to provide the driver of an equipped vehicle with a reliable route to his/her chosen destination. Two system architectures have been considered, namely the Autonomous Route Guidance scheme (ARG) and the Supported Route Guidance scheme (SRG). ARG includes a reliable route computation, taking place in the vehicle itself, based on historical link travel time data enhanced by broadcast information on road closures, traffic incidents etc., outputting a single reliable (risk-averse) route to the destination prior to the start of the trip. SRG on the other hand includes a route computation, taking place at a Traffic Information Centre, which takes into account current travel time data and outputs a set of partially disjoint reliable routes to the destination. This provides more advanced information to the driver prior to the start of his/her trip. A service offered to the driver in both schemes during the trip is the re-routing function, altering the driver s route in case an incident occurs on the planned route or if the driver diverts from it. Both ARG and SRG are based on the concept of link travel time reliability, defined as the probability of a link to be congested. The path computation is carried out by a modified version of the A* algorithm, avoiding unreliable links (i.e. links with a high probability of being congested) by applying link penalties to them. The resulting path in the ARG scheme must satisfy a number of constraints to be acceptable, such as maximum path duration and minimum total path reliability; if these are not met, the link penalties are reduced and a new path is computed. This methodology is not exact, as the resulting path may not be the optimal one and a better path may exist; however, it is an acceptable path to the driver. For the SRG scheme, some additional constraints are introduced, such as a maximum number of paths, as well as a maximum path overlapping ratio, to ensure that the paths computed are partially disjoint. For the re-routing function however, only a total path duration constraint is imposed. In order to run some initial simulations on a real road network and in the absence of real data, link travel time data, based on the speed limit of each link, link reliability data and junction delay data are created. Also, to account for the characteristics of real road networks, road types are defined and the network structure is altered to consider turn restrictions. Additionally, the structure of the algorithm is altered (link-based from node-based) so as to contain the positioning and direction of the vehicle. Finally, link failure dependence relationships are assumed, in order to take into account the effect of a link failure on neighbouring links. To run the initial simulations, a software tool called ICNavS is developed. This offers the ability to create a road network by drawing on top of a map or to load a previously created network. Then, as soon as the network is loaded, the route guidance algorithm developed (including ARG, SRG and rerouting) can be executed, yielding reliable routes between selected origin-destination pairs. Offensive Project Summaries Page 46 of 108

47 5 Imperial College London 5.1 ICL Introduction The ICL team has been working on two projects, reliable dynamic route guidance (covered in Section 5.2) and adaptive multi-criteria route guidance (covered in Section 5.3). In both cases, there is a review stage followed by an algorithm formulation stage culminating in field trials. Regarding the first project, a substantial review performed by Professor Yanyan Chen (see the OF- FENSIVE website) led to the formulation of a family of algorithms based on the common principle of reducing link penalties. These algorithms have been implemented in ICNavS (Imperial College Navigation Software), a software tool developed specifically for this purpose, and initial off-line tests have been run. These will be followed by further tests leading into field trials starting next year. Regarding the second project, there has been a review of literature on machine learning and related topics leading to the proposal to use decision tree learning as a basis for discerning driver preferences. The next stage involves off-line tests with data to be generated by ICNavS leading also to field trials next year. Offensive Project Summaries Page 47 of 108

48 5.2 ICL Reliable Dynamic Route Guidance ICL Outline Problem Statement and Objectives As the usefulness of in-vehicle information systems is appreciated, more drivers install them in their vehicles. Having started off with luxury makes and models, they are gradually spreading through the entire vehicle fleet, proving that their future is very promising. An important feature, offered by more sophisticated systems, is route guidance. The objective of route guidance is to provide participating drivers a fast route to their chosen destination. When the route computation is based on current traffic conditions, it is called dynamic route guidance. In accordance with that, reliable dynamic route guidance is the feature, whose objective it is to provide participating drivers a reliable (risk-averse) route to their destination. It should be noted, that risk in this context is defined as the probability of encountering congestion and does not refer to road safety. Consequently, a reliable (risk-averse) route is one which, under travel time uncertainty conditions (usually the rule in real road networks), minimises the probability of experiencing delays, by avoiding potential sources of delay. These are for example right turns in the UK (left turns in Continental Europe and in the US), where the turning vehicle usually has to cross one or more opposing streams, resulting in increased waiting times at junctions. The research work presented here is carried out as part of the OFFENSIVE project and involves providing reliable dynamic route guidance to the driver in two forms, namely Autonomous Route Guidance (ARG) and Supported Route Guidance (SRG), each requiring the corresponding system architecture. More specifically, ARG includes a best-route computation based on static (historic) link travel time profiles, complemented by information on traffic incidents broadcast to the vehicle using the Traffic Message Channel (TMC), which is part of the Radio Data System (RDS). Network data is provided in the form of a CD and the route computation takes place in the vehicle itself. As opposed to that, SRG involves continuous communication with a Traffic Information Centre (TIC). The route computation takes place in the TIC taking current network conditions into account. The information transmitted to the vehicle can consist of a set of alternative routes, allowing multi-routeing between given origins and destinations. As a complement to both the ARG and the SRG schemes, the re-routing function is also considered. This is activated every time the driver diverts from the selected route or when an incident causing delays is reported on the selected route. Its outcome is a modified reliable route from the specified current position of the vehicle (given by the GPS) to the selected destination. The computation of the modified route takes place in the vehicle for the ARG scheme and in the TIC for the SRG scheme. The approach adopted closely follows the Link Reliability approach, described by Chen et al (2005). After introducing the concept of reliability, the Link Reliability approach uses a modified version of the A* algorithm to search for the best path to the destination. The modifications applied include the application of link penalties in order to avoid unreliable links, the application of a number of constraints which the resulting route should satisfy and the adaptation of the A* algorithm itself, in order to satisfy the efficiency requirement, which in the case of an in-vehicle navigation system is very demanding Organisation of the Project Tasks The project presented in the previous section includes the following tasks: Task 1: Establishing background: This stage involves the familiarisation of the project participant with principles of Artificial Intelligence and Operations Research. Furthermore, it includes the development of programming skills, in order to carry out the rest of the project. More specifically, the project partici- Offensive Project Summaries Page 48 of 108

49 pant develops skills in the C++ and the Visual C#.NET programming languages during this stage of the project. Task 2: Literature review: This stage of the project involves a review of the existing literature on route guidance algorithms. Areas of interest include path finding, congestion risk modelling (travel time uncertainty) and dynamic route guidance. Task 3: Development of route guidance algorithms: Route guidance algorithms are developed and are constantly improved, according to the observations made. Algorithms for both the ARG and the SRG schemes are developed, as well as for the re-routing scheme. Task 4: Development of software: Software is developed in order to run the route guidance algorithms. The resulting program enables the user to input a destination and to obtain a good route or a set of good routes to that destination. Task 5: Derivation of the missing data: The missing data includes link travel time profiles, link failure interdependences and junction delay values. As an initial step, sensible values are assumed, until real values are obtained and processed. Possible sources of data include floating car data. Task 6: Field trials: This stage consists of the familiarisation stage, during which the project participants are getting acquainted with the test vehicle, and of the actual conduct of the field trials on part of London s road network. Task 7: Write-up and completion of final report: A final report (PhD thesis) is to be produced at the end of the project. The current status of the project finds task 1 to be 100% complete and tasks 2, 3, 4 and 5 to be under way. As an indication, task 2 is around 60% complete, task 3 is around 70% complete, task 4 is around 80% complete (basic version of software is up and running) and task 5, which is at a very initial stage (only assumptions have been made), is about 10% complete. A more detailed account of the current status of the project is given in the next section ICL Current status This section presents the current status of the research described. A short description of the A* algorithm and the Link Reliability approach is given, followed by an account of the achievements made during the last project period. These include the creation of a procedure for modelling real road networks and the development of software enabling the user to execute the route guidance algorithms on real road networks The Link Reliability Approach Chen et al (2005) introduce the concept of reliability, in order to model the risk of encountering congestion. The reliability of a link is simply derived from the distribution of travel time throughout the day. Namely, the variable of reliability takes values from 0 to 1, with 0 making the link unusable and 1 meaning that the travel time on that link is constant throughout the day. For example, if link i has a reliability value of r i, then it means that there is a probability of r i that link i will be uncongested. Having defined reliability, the method to be followed in order to obtain a reliable path (or a number of paths) is based on the A* shortest path algorithm, as described by Hart et al (1968). The advantage of A* compared with other shortest path algorithms, such as Dijkstra s algorithm (1959), is that the A* is much more efficient, due to its ability to convert an uninformed search into an informed search. The A* algorithm uses a heuristic function to estimate the cost (travel time) from any point to the destination node of the network; this is usually the airline distance to the destination. The fastest path is eventually found, under the condition that the heuristic does not overestimate the actual distance to the destination. Nevertheless, the number of nodes expanded is much smaller than it is for other algorithms, making A* more efficient. Offensive Project Summaries Page 49 of 108

50 The concept of A* is summarized as follows; the algorithm holds two lists, the open list and the closed list. The closed list contains all the nodes of the network that have been expanded, whereas the open list contains all the nodes that may be expanded at the next step. At each step, one node is expanded and moved from the open list to the closed list, while its successors are placed into the open list. For every node n: f(n) = g(n) + h(n), where g(n) is the travel time from the origin to node n and h(n) is the estimate of the travel time from node n to the destination. The node to be expanded at each step is the node with the lowest f(n) value, among the nodes in the open list. Chen et al present algorithms for both the ARG and the SRG schemes. Modifications to the conventional A* algorithm are made. The most important modification to the A* algorithm is the application of constraints. Constraints are imposed to the resulting route in order to make it acceptable to the driver. The constraints applied are the following: Maximum path duration Minimum path reliability Maximum number of paths (in the SRG scheme, where a number of reliable paths are computed) Maximum path overlap ratio (in the SRG scheme) Every time a path is computed, it is checked against these constraints. If it satisfies them, it is kept, otherwise it is eliminated and a new path is computed. The application of link weight (travel time) penalties enforces the above constraints. The main idea lies in performing an initial search, finding the quickest path without considering reliability, penalising unreliable links by applying travel time penalties and running subsequent searches, each time reducing the penalties, until the computed path satisfies the constraints imposed. For the SRG scheme, where more paths are computed, link penalties are also applied to already used links; this guarantees that the paths will share as few links as possible (will be partially disjoint), in order to reduce the probability of joint path failure caused by the failure of a single link. The idea of link penalties was initially introduced by Pu et al (2001) as an attempt to develop a method for finding alternate paths in a network. Chen et al use the following travel time penalty for links having a reliability value lower than a preset threshold, and in the case of the SRG scheme, also for links that are already in one of the computed paths: t i = α m (1 r i ) q W 0, with 0 < α < 1, m = number of iterations, q = 0 if m = 0 otherwise q = 1 and W 0 = a large value. Figure 1: The Link Reliability approach Offensive Project Summaries Page 50 of 108

51 Another modification of the A* algorithm in both the autonomous and the supported route guidance schemes is that the algorithm runs backwards, that is from the destination to the origin. The advantage of running the A* from the destination to the origin is that after the first run, the computed cost from the destination to every visited node can be used as an estimate for subsequent forward A* runs. The number of nodes visited is thus significantly reduced and consequently the computation time is also significantly reduced. An outline of the Link Reliability approach is shown in Figure 1. In the next sub-section, the methodology developed in order to model real road networks is described Modelling Real Networks So far, the Link Reliability approach has only been used on artificial grid networks. These are very convenient to carry out initial tests, however they are too idealised and cannot be used to model real road networks. In order to run simulations on real networks, a software tool (ICNavS) is developed and used. This will be described in detail later in this report. In this section, some properties of real networks are presented and their modelling approach is explained. The features that distinguish a real road network from an artificial grid network are the following: a. Network hierarchy b. One-way roads and dead-ends c. Turn restrictions d. Junction delays e. Positioning of the vehicle f. Link failure dependence relationships These are described in the following subsections. a. Network Hierarchy A road network is usually hierarchical. This means that there are different types of roads, each one of them having different properties, such as traffic flow speeds and number of lanes. Generally, all roads can be placed in one of the following five categories: 1. Motorway (Freeway in the US) 2. Major A-road 3. A-road 4. B-road 5. Minor road For longer distances, drivers prefer higher ranked roads, as they enable travelling at higher speeds. This is why motorways and major A-roads are usually preferable for interurban trips. However, each driver s origin and destination are usually only accessible by roads of lower category. In order to deal with the hierarchy of road networks, an approach based on the speed limits of each road type is adopted. Namely, it is assumed that vehicles travel at a constant speed, whose value is close to the speed limit. This is called the design speed. Speed limits are variable for different types of road and it is also very common that roads of the same category have different speed limits. Table 1 shows the speed limit on each road type, as well as the design speed value that is used. Having determined the design speed for each road type, an estimate of the link travel time, based on the road type, can be derived next. Using the simple principle that time is given by the ratio of space over speed, a link travel time can be calculated by dividing link length by its design speed. This is the design travel time, referred to simply as travel time in the rest of this report. Offensive Project Summaries Page 51 of 108

52 b. One-Ways and Dead-Ends Table 1: Speed limits for each road type and speed values used Artificial grid networks are usually undirected graphs, meaning that all links can be traversed at any direction. However, this is not the case for real road networks, where due to the presence of one-way streets, all links have to be directed. Additionally, it is very common that a two-way road has different travel times in opposing directions. Therefore, separate links are introduced for every possible connection from one node to another; two-way roads are represented by two opposing links. Dead-ends are another feature of real road networks which does not exist in grid networks. Taking into account the fact that dead-ends are always two-way roads, as otherwise one would not be able to drive in and then out, it has to be ensured that they are represented by two links of opposite directions. c. Turn Restrictions and Intersection Representation The main feature, which differentiates real road networks from artificial grid networks, is the existence of turn restrictions. Right turns in the UK (left turns in Continental Europe and in the US) are very often banned, due to the fact that there is not adequate space to accommodate the formation of the resulting queue of turning vehicles. Several attempts to model turn prohibitions have been made in the past. The first method was proposed by Wattleworth and Shuldiner (1963). The approach adopted was to substitute every junction by a smaller sub-network of dummy nodes and links. Despite the fact that this approach alters the network structure and reduces efficiency, it is the most widely used method in transportation applications. An important contribution to the field was made by Kirby and Potts (1969), where a review of existing techniques was carried out and a new method was proposed, according to which penalties are applied to turning movements. For prohibited turns, the corresponding penalty value is set to infinity. Easa (1985) further developed this approach. Ziliaskopoulos and Mahmassani (1996) introduced the Extended Forward Star Structure. According to this, there is a list with all allowed movements in the network and every node holds as many labels as links emanating from it. Shortest path algorithms can then be executed on this modified network structure, while all labels are updated gradually. Multiple labels are also needed for the Kirby and Potts method, as the cost to a node can be different, according to which node is chosen next. The weak point of applying label correcting algorithms, such as the A*, using either the Kirby and Potts method or the Extended Forward Star Structure is that a node cannot be considered to be expanded and consequently added to the closed list, unless all of its labels have been explored and updated. The result is a large number of nodes in the open list and a very small number of nodes in the closed list; consequently, the algorithm either yields a sub-optimal path or enters an infinite loop. Treating each label separately would be a solution to the problem; nevertheless, any advantage in memory would be lost in that case, as this would be equivalent to representing each node as a set of dummy nodes and dummy links. Offensive Project Summaries Page 52 of 108

53 The approach adopted for the present report is a modified version of the Wattleworth and Shuldiner approach and of the Extended Forward Star Structure. Namely, each node holds information on all the allowed movements going through it. Movements are expressed similarly to the Extended Forward Star Structure, where a movement is represented by three nodes: start node - middle node end node. Every time the network is stored, a lower layer dummy network is created, similar to the subnetwork in the Wattleworth and Shuldiner approach. For every entry and exit of each node a dummy node is created and for every movement, a dummy link is created. The travel time of the dummy link is the delay of the corresponding movement. The algorithm is run on this dummy network and the resulting path is carried onto the higher level. Applying the approach just described, it can be observed that the most computationally demanding process is the creation of the dummy elements. However, this process only needs to take place when the network topology is altered. Considering the application of the end product, which is a navigation system used by a driver, it can be realised that such a situation does not arise, as the driver is not able to perform any changes to the network topology. Consequently, the approach only poses a memory overhead to the developer and is therefore acceptable, as it makes practically no difference for the user. d. Junction Delays The delays experienced at junctions are, together with the delays encountered on links, the main sources of loss of travel time along a route. A good route should therefore ensure that they are minimal. Junction delays are strongly dependent on the type of movement that takes place. Right turns (assuming left-hand drive) usually cause higher delays than straight-on movements and left movements. Chen et al (2005) assume a delay value of 0 for left turns. On the other hand, the delay of a straighton movement or right turn is a randomly generated value between 0 and 2 minutes, with right turns having generally higher delay values than straight-on movements. In the present report, more specific values are given, bearing in mind that these values have to be relatively lower for a road network, in order to be realistic. The estimated values assigned to junction delays in this report also depend on the types of roads meeting at the junction. Left turns are still assumed to have a delay of 0, as a left turning movement Table 2: Right turn movement delay values in seconds does not usually come into conflict with other traffic streams. The estimated junction delay for a right turn movement depends on the road type of the link from which the movement starts and on the road type of the link to which the movement is directed. The delay values for right turns for all possible combinations of road types are shown in Table 2. It should be noted, that no right turns are possible onto or Table 3: Straight-on movement delay values in seconds from motorways; therefore, any right turn movement delays involving motorways Offensive Project Summaries Page 53 of 108

54 are neglected as not applicable. The estimated junction delay for a straight-on movement depends on the road types of the links that are being crossed by the movement, and more specifically, on the road type of the link with the highest road type crossing the movement in question. The delay values for straight-on movements are shown in Table 3. Again, motorways are not included, as the only possible movements onto and from motorways are merges from on-ramps and exits onto off-ramps, whose delays are practically negligible. e. Positioning of the vehicle In artificial grid networks, the origin and destination of a route, as well as the position of the vehicle, are identified as nodes. To be exact, any journey always starts from an origin node and ends on a destination node. However, in real road networks, where the nodes correspond to junctions, this approach has a serious drawback, and that is the fact that not only the position of the vehicle is required, but also its direction. It is possible, that a vehicle is located on a road between two junctions, facing towards one of them and not being able to make a U-turn. However, if the position of the vehicle is expressed as a node, it is very likely that two alternative routes would guide the vehicle to make illegal or impossible movements. Figure 2 clarifies the problem described in the previous paragraph. As can be seen, starting from the origin node, two routes are computed to the destination (dotted line and continuous line). However, the two routes depart in opposing directions from the origin node, assuming that the vehicle is located exactly on that junction and that the driver is able to drive in any direction. However, this is very unlikely to occur in real life. A solution to the problem presented here is to slightly modify the network structure and make it link-based rather than node-based. Namely, when specifying the origin and destination, an origin-link and a destination-link are specified, considering that the origin or the destination respectively are located somewhere on this link. The route guidance algorithms however are still node-based, in fact dummy-node-based. Therefore, when specifying an origin link or a current position link (for re-routing), its end dummy node is specified as the origin of the search; for the specification of the destination link, the destination dummy node is specified as the start dummy node of the link. Using this technique, the setting of the origin link or the current position link immediately limits the next allowed movements. Similarly, the setting of the destination link results in the direction of approach of the destination being fixed, which is very important in some cases. In any case, when the user is prompted to enter the destination of his/her trip, it is most likely that this will be a street name, therefore only referring to a link. f. Link failure dependence relationships Figure 2: Problems of using nodes as origin, destination and vehicle position Chen et al (2005) introduce the idea of link failure dependence, where failure is defined as the congested state of a link. Failure dependence relationships between links express how congestion on one link affects other links. Considering links i and j, there are three possible types of failure dependence between them. Namely, if the performance of link i deteriorates, then link j is positively failure dependent on i if its performance also deteriorates. Alternatively, j is negatively failure dependent on i, if a deterioration of the performance of i results an improvement of the performance of link j. Finally, if a deterioration of the performance of i leaves the performance of j unaffected, then i and j are failure independent. Offensive Project Summaries Page 54 of 108

55 Chen et al (2005) also define a failure dependence coefficient µ ij, where -1 < µ ij < 1. More specifically, if link j is positively failure dependent on link i, then µ ij > 0, and the greater the dependence the larger the value of µ ij. If on the other hand j is negatively failure dependent on i, then µ ij < 0, and the greater the dependence the smaller the value of µ ij. Finally, if i and j are failure independent, then µ ij = 0. The approach adopted in this report involves so-called geometrical failure dependence. This includes the assumption that links are failure dependent because of their location, and more specifically, the set of links which are positively failure dependent on some link i are primarily the links upstream of link i, and secondarily the links upstream of them. In other words, a link is positively failure dependent on link i, if i can be reached from this link using a maximum of three links (a maximum dependence degree 3). Depending on the location of the positively failure dependent link, the failure dependence coefficient varies accordingly. For failure dependent links of degree 1 (i can be reached using only one link), a value of µ = 1 is used (absolute failure dependence). For links of dependence degree 2 (i can be reached using two links), µ = 0.75 and for links of dependence degree 3, µ = 0.5. An example of the failure dependence relationships is given in Figure 3, where the incident link (link connecting nodes 53 and 109) is shown and the failure dependence coefficients for the positively failure dependent links are given. Figure 3: Example of failure dependence Having modelled real road networks and having made assumptions for all the missing data, the report continues with the description of the route guidance algorithms and the software Reliable Dynamic Route Guidance Algorithms Three functions of the route guidance algorithm can be identified, according to which route guidance scheme is used. Namely, the Reliable Routing function (RR), the Partially Disjoint Paths function (PDP) and the Re-routing function (Re-R), corresponding to the ARG scheme, the SRG scheme and the Re-routing scheme respectively, are developed. The outcome of the RR function of the algorithm is a reliable path, satisfying all the imposed constraints, from the chosen origin to the chosen destination. In case no such path is found, no reliable Offensive Project Summaries Page 55 of 108

56 path is suggested, but the fastest path, calculated without considering reliability, is given as a result. This also happens for the PDP function, whose normal outcome is a set of routes from the chosen origin to the chosen destination. The Re-R function is somewhat different, as it does not compute a route from the origin to the destination, but from the current position of the vehicle to the destination. The Re-R function is enabled, only if a route, among the suggested routes resulting from the RR or the PDP functions, has been chosen. However, enabling the Re-R does not mean that it will be executed, regardless of whether there is a need for it or not. The Re-R function can only be executed, if an incident is reported somewhere downstream of the current position of the vehicle, or if the vehicle has diverted from the selected route. After running the Re-R function of the algorithm, the resulting part-route (from the current position to the destination) needs to be checked against the imposed constraints. In re-routing, drivers are generally more interested in finding a correct alternative route to their destination, without paying so much attention to whether this route is reliable. Therefore, the only constraint that needs to be satisfied for the re-routing path is the duration constraint. In order to check this, the total duration of the modified route (from the origin to the current position and from the current position to the destination) is calculated. If the constraint is satisfied, the newly computed part-route from the current position to the destination substitutes the existing part-route of the selected route. If the constraint is not satisfied, then the computed part route is ignored and a new part route is calculated. The route guidance algorithm, including all three functions is presented next. At first, some definitions are listed, before the actual algorithm is presented. Function: The function of the algorithm (RR or PDP) OP d : Open list of dummy nodes CL d : Closed list of dummy nodes o: The origin link d: The destination link c: The current position link od: The dummy node corresponding to the origin link (end dummy node of the origin link) dd: The dummy node corresponding to the destination link (start dummy node of the destination link) cd: The dummy node corresponding to the current position link (end dummy node of the current position link) n d : A dummy node corresponding to node n s(n d ): A successor dummy node of n d p(n d ): A predecessor dummy node of n d Γ(n d ): The set of successor dummy nodes of n d Γ -1 (n d ): The set of predecessor dummy nodes of n d t(a,b): The travel time of the link from dummy node a to dummy node b r(a,b): The reliability of the link from dummy node a to dummy node b SP d : A list containing connected dummy nodes P p (L p,t p,r p ): Path p, containing the links in list L p and having a total travel time T p and a total reliability R p m: Iterations counter p: Paths counter PathSet: List of p computed paths T max : Path duration threshold (T max = βt 0 ) r min : Link reliability threshold R min : Path reliability threshold ε max : N max : Maximum path overlapping ratio threshold Maximum number of paths Offensive Project Summaries Page 56 of 108

57 µ (a,b)(c,d) : Failure dependence coefficient of link (c,d) to link (a,b). Π, Π oc, Π cd : Selected path, part of the selected path from the origin to the current position, part of the selected path from the current position to the destination Step 1: Backward A* search 1a: Set p = 0. OP d contains only d d. CL d is empty. g(n d ) = infinity for all n d, g(d d ) = 0 Find h(n d ) for all n d 1b: n d * = Argmin nd in OPd f(n d ), f(n d ) = g(n d ) + h(n d ) Add n d * to CL d and remove it from OP d. 1c: If n d * = o d, go to Step 1d. Else, for each i in Γ -1 (n d *): Add i to OP d if not already there and not in CL d If g(i) > g(n d *) + t(i, n d *), then g(i) = g(n d *) + t(i, n d *), n d * = s(i) and add i to OP d if it is in CL d. Go to Step 1b. 1d: Set n d = o d, add n d to SP d, set T 0 = 0 and R 0 = 0 1e: Set n d = s(n d ). Add n d to SP d. Calculate T 0 = T 0 + t(n d,n d ), R 0 = R 0 x r(n d,n d ). Add (n d,n d ) to L 0. Set n d = n d, T 0 = t 0, R 0 = R 0. 1f: If n d is not equal to d d, Go to Step 1e. Else Output path P 0 (L 0,T 0,R 0 ). Set p = p + 1 and p = p. Step 2: Replace the h estimates with known g values For each dummy node n dcl in CL d, set h(n dcl ) = g(n dcl ) Set W 0 = γt 0, where 1.5 < γ < 3 Set m = 0 Step 3: Link travel time increment If Function = RR For each link (a,b) with r(a,b) < r min t (a,b) = t(a,b) + α m [1-r(a,b)] q W 0, 0 < α < 1, q = 0 for m = 0, q = 1 otherwise. For every other link t (a,b) = t(a,b) Set m = m + 1 and m = m. Else if Function = PDP If p = 1 For each link (a,b) with r(a,b) < r min t (a,b) = t(a,b) + α m [1-r(a,b)] q W 0, 0 < α < 1, q = 0 for m = 0, q = 1 otherwise. For every other link Offensive Project Summaries Page 57 of 108

58 t (a,b) = t(a,b) Set m = m + 1 and m = m. Else For each link (a,b) with r(a,b) < r min, for each link in PathSet and for each link (x,y) with µ (a.b)(x,y) > 0 t (a,b) = t(a,b) + α m [1-r(a,b)] q W 0, 0 < α < 1, q = 0 for m = 0, q = 1 otherwise. For every other link t (a,b) = t(a,b) Set m = m + 1 and m = m. Else if Function = Re-R For each incident link (x,y) Set r(x,y) = 0. For each link (a,b) Set r(a,b) = 1 µ (x,y)(a,b). For each link (a,b) with r(a,b) < r min t (a,b) = t(a,b) + α m [1-r(a,b)] q W 0, 0 < α < 1, q = 0 for m = 0, q = 1 otherwise. For every other link t (a,b) = t(a,b) Set m = m + 1 and m = m. Step 4: Forward A* search using t (a,b) 4a: If Function = RR or Function = PDP OP d contains o d. CL d is empty. g(n d ) = infinity for all n d, g(o d ) = 0. Else if Function = Re-R OP d contains c d. CL d is empty. g(n d ) = infinity for all n d, g(c d ) = 0. 4b: n d * = Argmin nd in OPd f(n d ), f(n d ) = g(n d ) + h(n d ) Add n d * to CL d and remove it from OP d. 4c: If n d * = d d, go to Step 4d. Else, for each i in Γ(n d *): Add i to OP d if not already there and not in CL d If g(i) > g(n d *) + t (i, n d *), then g(i) = g(n d *) + t (i, n d *), n d * = p(i) and add i to OP d if it is in CL d. Go to Step 4b. 4d: Set n d = d d, add n d to SP d, set T p = 0 and R p = 0 4e: Set n d = s(n d ). Add n d to SP d. Calculate T p = T p + t(n d,n d ), R p = R p x r(n d,n d ). Add (n d,n d ) to L p. Set n d = n d, T p = T p, R p = R p. 4f: If n d is not equal to o d, go to Step 4e. Else Output path P p (L p,t p,r p ). Offensive Project Summaries Page 58 of 108

59 Step 5: Check constraints If Function = RR If T p < T max and R p > R min, then add path P p to PathSet. This is an acceptable, more reliable path than the fastest path. Go to Step 6. Else, go back to Step 3. Else if Function = PDP Set maxε = 0. For each path P i in PathSet Set ε 1 = 0, ε 2 = 0, ε 12 = 0. For each link (a,b) in L i and for each link (a,b) in L p If (a,b) belongs to both L i and L p, then ε 12 = ε 12 + t(a,b) and ε 12 = ε 12. Else if (a,b) only belongs to L i, then ε 1 = ε 1 + t(a,b) and ε 1 = ε 1. Else if (a,b) only belongs to L p, then ε 2 = ε 2 + t(a,b) and ε 2 = ε 2. Set ε = ε12 ε1 ε. 2 If ε > maxε, maxε = ε. Set ε = maxε. If T p < T max, R p > R min and ε < ε max, then add path P p to PathSet. Set p = p + 1 and p = p. If p < N max, go back to Step 3. Otherwise go to Step 6. Else, go back to Step 3. Else if Function = Re-R Step 6: Termination T Π = 0, R Π = 1. For each link (a,b) in Π oc, T Πoc = T Πoc + t(a,b), R Πoc = R Πoc x r(a,b) and T Πoc = T Πoc, R Πoc = R Πoc. If T Πoc + T p < T max, then Π = Π oc + P, and thus T Π = T Πoc + T p and R Π = R Πoc x R p. Go to step 6. Else, go back to Step 3. An interesting point to mention is that in Step 3 for the PDP function, when the first alternative path is computed, the link penalties are only applied on unreliable links, whereas when computing the next alternative paths, also used links are penalised. The reason for not penalising used links in the first alternative path computation is that the path set only contains the fastest path at that point, which was computed without any consideration of reliability. Consequently, penalising its member links could result in avoiding reliable links. It should be noted here that the fastest path is not a part of the candidate path set (it is not added to it in Step 1) and does not come into consideration when checking the path overlapping constraint in Step Description of the Developed Software ICNavS (Imperial College Navigation Software) is a software tool enabling the execution of route guidance algorithms on real road networks. It is written in Visual C#.NET object-oriented programming language. In the next paragraphs, a description of the structure and the user interface of ICNavS is presented. Structure There are two classes, one for nodes (called Nodes ) and one for links (called Links ), each one of them holding a set of properties. Additionally, there is a class for movements (called Movements ) and a class for paths (called Paths ) likewise holding a number of properties. Offensive Project Summaries Page 59 of 108

60 Properties can be categorised into static and runtime. Static properties are the properties of a network element, which are not modified during the execution of a route guidance algorithm. Such are, for example, properties relating to network topology and geometry, such as location. As opposed to that, properties that are altered during the execution of a route guidance algorithm are called runtime properties. A good example of these is the node label. Every object of class Nodes (i.e. every node in the network) holds the following static properties: location (X and Y co-ordinates with respect to a given origin), name, ID number and allowed movements through the node (a list of object of class Movements ). Additionally, it holds a runtime property indicating, in case the node has been explored, the node where the search came from (pointer). Besides these properties, every Nodes object is associated with a circle image, representing the node in the visual interface of the software. All the nodes of the network are stored in a list and are recalled when needed using their ID number. Similarly to the Nodes objects, every object of class Links (i.e. every link in the network) holds the following static properties: name, ID number, start node, end node, link road type, link speed, link travel time and link reliability. Additionally, it holds two runtime properties, namely: a property indicating whether there is a traffic incident on the link and another property holding the updated value of the travel time, following the travel time penalty application. Every Links object is also associated with the image of a line, representing the link in the visual interface of the software. All the links of the network are stored in a list and are recalled when needed using their ID number. To keep track of the allowed movements in the network, the Movements class is created. Each Movements object holds the following static properties: start node, middle node, end node, type (right, left or straight-on), delay and reliability. Movements objects do not possess any runtime properties and are stored in lists on each Nodes object. In order to store the computed paths, a class called Paths is formed. A Paths object only holds the following properties: ID number, list of member links, total travel time and total reliability. These are all runtime properties, as they can only be modified by the route guidance algorithm. According to the turn restriction representation method, described in Section 3, additional classes to represent dummy elements are needed. A class called Dummy Nodes is created to represent all dummy nodes; its static properties are ID number and mother node (the node of the upper level, to which the dummy node is a sub-node ), whereas most of their properties are runtime. Namely, these are: parent dummy node (in case the dummy node has been explored, this points to the dummy node where the search came from), heuristic estimate of the distance to the destination (h as defined in Section 2), actual distance from the origin (g as defined in Section 2) and label (f = h + g). Dummy nodes are not associated with an image for efficiency reasons. Instead of adding an additional class for dummy links, the existing Links class is modified to account for dummy links. Therefore, two new static properties are added to the class: start dummy node and end dummy node. A link is characterised as dummy, if its link road type property is set to 0. Similarly to the dummy nodes, no image is associated with dummy links. User interface Describing the user interface of ICNavS, it consists of a main window with a canvas, where the network is inserted, buttons for each application, a box showing the properties of the selected item, a list box displaying the set of the computed paths and another box, displaying the properties of the selected path in the list box. By selecting the appropriate mode using the buttons, the user can draw a network on the canvas by adding nodes and links, edit their properties, edit the allowed movements, remove elements and zoom in and out to obtain the desirable view of the network. The user can additionally place a road map as a background and draw the network on top of it, so that the created network matches the real network. For memory requirement minimisation purposes, the Offensive Project Summaries Page 60 of 108

61 background can be enabled and disabled at any time. The background can also be scaled in order to obtain the right distances. The created network can be saved to a file, through which it can be loaded at any time. When a calculation has taken place, the computed paths are shown in the list box and are displayed on the canvas by different colours and patterns. The selected path from the list box is shown more opaque than the other paths and its properties are displayed in the box below the list box. The user must then choose one of the computed paths to reach the specified destination. Once a path is chosen, all the other paths disappear from the canvas, while the list box is disabled. However, the paths are not deleted from the memory and can always be recalled if there is a need for them. An outline of the user interface of ICNavS is shown in Figure 4. Figure 4: User interface of ICNavS Experiments and results This section describes the experiments carried out and the results obtained from the application of the described algorithm on a real road network, using ICNavS. The network chosen is a part of the West London area of Kensington, containing 384 nodes and 956 links and spreading over a length of approximately 2.5 km and a width of 1.5 km. It is modelled according to the methods described in Section and then imported into ICNavS, where it obtains the structure described in Section The test network as it is output in ICNavS is shown in Figure 5, where the nodes and links can be distinguished on the map. The parameters of the simulations are given next. Parameter α, which is used in the travel time penalty application is set to 0.7. Equivalently, parameter γ, used in the calculation of the W 0 value for travel time penalties (W 0 = γt 0 ), is set to 1.9. Offensive Project Summaries Page 61 of 108

62 Figure 5: The Kensington test network The duration permission parameter β, defining the maximum path duration constraint (T max = βt 0 ), strongly depends on the network size. As this is a relatively small network and travel times do generally not exceed 7 minutes, a value of β = 2 is applied. This means that a route can be twice as long as the fastest route to be considered to be acceptable. Of course, in a larger network where travel times usually exceed 30 minutes, a parameter of β = 2 would result in routes of duration of 1 hour to be acceptable, which is clearly not realistic. A value of 1.1 or 1.2 would be assigned to β in that case. The link reliability threshold, defining the reliable or unreliable state of a link is set to 0.9. Any link having reliability lower than this value is considered to be unreliable and has its weight modified by the application of travel time penalties. In the PDP function, a minimum path reliability constraint (R min ), a maximum number of paths constraint (N max ) and a maximum path overlapping ratio constraint (ε max ) are applied. The thresholds defining the acceptability of a path are 0.35, 5 and 2 respectively. This means that any path computed has to have a total reliability of at least 0.35, while at most 5 paths besides the fastest path may be calculated. Furthermore, a maximum overlapping ratio of 2 means that the total length of overlapping between two paths can be at most twice as long as the total non-overlapping length between these two paths. Finally, a number of selected links and right turns are set to be unreliable (their reliability value is lower than 0.9). Three simulations are run, one for each different function of the algorithm. However, for comparison purposes, the same origin-destination pair is used. The results obtained are presented next. Figure 6: The calculation of the fastest path for both the RR and the PDP functions Figures 6 and 7 show the outcome of the RR function of the algorithm, applied on the test network. As can be seen, the algorithm prefers roads of Offensive Project Summaries Page 62 of 108

63 Figure 7: The calculation of the reliable route for the RR function and the first alternative route for the PDP function Figure 8: The calculation of the second alternative route for the PDP function Figure 9: The calculation of the third alternative route for the PDP function higher categories, as this reduces travel time. This is why a significant part of the route includes a Major A- road (Cromwell Road). The computed route has a total travel time of T 0 = 5.47 minutes and a reliability value of R 0 = 0.1. However, when reliability is considered, Cromwell Road is avoided, as it has sections with reliability values lower than the reliability threshold. Consequently, an A-road is chosen instead (Brompton Road). This results in the total travel time value to rise to T 1 = 6.87 minutes and the reliability value to improve to R 1 = 0.38, thus satisfying the imposed constraints. The outcome of the PDP function of the algorithm, applied on the test network is presented next. The calculation of the fastest route and the first alternative route is identical to the RR function, as for the former reliability is not considered and for the latter only unreliable links are penalised. Nevertheless, the next steps of the procedure differ, as not only unreliable links, but also positively failure dependent links to them, as well as used links are penalised. The resulting path set, consisting of five partially disjoint routes excluding the fastest route, is the following: Route 0: T 0 = 5.47 min, R 0 = 0.1 (Fastest route Fig. 6). Route 1: T 1 = 6.87 min, R 1 = 0.38 (First alternative route Fig. 7). Route 2: T 2 = 7.98 min, R 2 = 0.44 (Second alternative route Fig. 8). Route 3: T 3 = 7.51 min, R 3 = 0.4 (Third alternative route Fig. 9). Route 4: T 4 = 7.58 min, R 4 = 0.44 (Fourth alternative route Fig. 10). Route 5: T 5 = 7.17 min, R 5 = 0.41 (Fifth alternative route Fig. 11). Figure 10: The calculation of the fourth alternative route for the PDP function Offensive Project Summaries Page 63 of 108

64 Figure 11: The calculation of the fifth alternative route for the PDP function Figure 12: The calculation of the re-route path from route 3, following an incident report downstream of the current position of the vehicle In order to carry out the third simulation using the Re-R function, a route among the calculated candidate set needs to be chosen by the driver. As an example, route 3 is chosen here. Additionally, it is assumed that an incident occurs on a link on the selected route, so that it has to be avoided, in order to prevent delays from being experienced by the driver. The current position of the vehicle is set upstream of the incident link. Thus, all the conditions required for the Re-R function to be enabled and activated are met. The outcome of the Re-R function being executed on the test network and more specifically on route 3 is shown in Figure 12. The incident link (not on the route any more) and the current position link are shown, while the modified route is drawn. A comparison of Figures 9 and 12 clarifies this issue. The new total travel time of the modified route 3 is 8.09 min, satisfying the duration constraint, while the new reliability value of the route is ICL Outlook The priority step for the next project period is to complete tasks 2, 3 and 4, described in the Outline section of this report. More specifically, a thorough review of existing literature needs to be concluded, a few further developments need to be done on ICNavS and the formulation of the route guidance algorithm needs to be finalised. Following these tasks, work on task 5, involving the derivation of the missing data, is to be put under way, aiming to be concluded by the end of the next project period. Meanwhile, task 6 needs to be put under way, with the prospective of starting the actual field trials by the end of the next project period. A more detailed outlook on the upcoming tasks of the project is given next. Task 2: Finishing task 2 is the top priority task to be carried out in the next project period. A review of existing literature on route guidance algorithms needs to be concluded and a report needs to be produced. The resulting literature review, along with the present report will form the final internal report for the transfer examination, from MPhil to PhD. Task 3: The further development of the algorithm is one of the next tasks to be undertaken. Applying the developed algorithm to a larger network would yield interesting results and necessary modifications to the present version of it. For example, the efficiency of the algorithm could be improved by revising the heuristic estimate for the A* algorithm. Also, a possible interaction with the so-called Robust Shortest Path problem approach could be looked into. Task 4: The further development of ICNavS is also one of the priority tasks for the next project period. Namely, the program needs to become able to read from a NAVTEQ digital map and picture it, so that Offensive Project Summaries Page 64 of 108

65 the developed algorithm can run on it. Also, the program needs to obtain a function, which will enable it to load networks under the right-hand drive rule. Thus, it will be possible to load networks from other countries, such as Germany and the US. Task 5: The derivation of the missing data stage is to be carried out later in the next project period. With initial estimates for travel times, reliability values and junction delays, initial simulations have been executed. However, it is essential that simulations are run using real data. A larger test network is to be selected, possibly of the size of a London borough, i.e. large enough to offer several route choices. A possible source of data is floating car data, provided by a company called ITIS. The aim is to complete this task by the end of the next project period. Task 6: Field trials are scheduled to start at the beginning of the third project period (third year of the project). However, as a familiarisation and a setup period of the test vehicle are required prior to the conduction of the actual field trials, it is aimed that the setup period is completed by the end of the next project period, concurrently with task 5. Offensive Project Summaries Page 65 of 108

66 5.3 ICL Adaptive Multi-Criteria In-Vehicle Navigation ICL Outline Background In most luxurious cars, navigation systems are installed as an option and many manufacturers aim to provide them as a mid-price option in the future (Svahn, 2004). Navigation systems combined with PDAs and mobile phones are now widely available. The navigation systems market is projected to grow to 5.4 billion USD by 2010, which represents a 66% growth over today s market, estimated at 3.2 billion USD (CSM Worldwide, 2005). As the use of navigation systems becomes more and more frequent, the demand for development of more useful systems increases. In fact, existing navigation systems help drivers to manipulate cars and hence improve safety. However, navigation systems could be even more useful. Research on the usage of navigation systems shows that approximately 65% of users are satisfied with route guidance and consider suggested routes reasonable (Svahn, 2004). Nonetheless, earlier research on driver compliance by Bonsall (1992) shows that travellers are less likely to comply with route guidance in familiar areas, which means the usefulness of a navigation system depends on the level of network familiarity. In the meantime, the focus group study with familiar drivers by Schofer et al. (1997) shows that even dynamic route guidance with real-time traffic information is unlikely to satisfy drivers, who have a good knowledge of the transport network. The participants to this study emphasised, that it was necessary to consider individual desires for more control over route planning and suggested that this could be done by making more intelligent systems that can learn driver preferences on routes. Among the advanced navigation systems available in the current market, some provide the function of planning user-specific routes, as well as considering real-time traffic information on major corridors. Drivers can select an option by which a preferred route can be chosen. However, this function does not cover the all user preferences on route choice. Moreover, this requires the driver to select a certain option whenever he/she uses the system. In fact, the simplest method to acquire knowledge of user preferences is for the user to input them directly. However, since user preferences vary and often spread over a wide range of attributes, the process of gaining enough knowledge on user preferences can be very time-consuming. Moreover, there may be latent preferences that drivers do not notice. Consequently, it is necessary to come up with methods of capturing user preferences, whilst minimising the required effort from the user s part. This has led to the emergence of a research field known as user modelling, which is defined as the process of acquiring knowledge about a user, in order to provide services or information adapted to their specific requirements (Torres, 2000). Initially, user modelling has been applied on education software development, for students who have different learning abilities. Information overload on the Internet has further emphasised the importance of user modelling, for adaptive information services to the different needs of individuals. User modelling is a useful approach to capture user preferences without any information being directly input by the user; instead, the information is retrieved while the user makes use of the route guidance system. This research addresses the problems of incorporating user modelling methods into route guidance for more user-friendly and more intelligent navigation systems Research approach The overall objective of this research is to enhance the efficiency of navigation systems from the user s perspective and to increase user satisfaction by adding a learning capability to their structure. The primary goal is a prototype of an adaptive route guidance system in relation to conventional guidance systems. This objective can be divided into the following sub-objectives: Offensive Project Summaries Page 66 of 108

67 To develop models, which are able to represent user preferences covering a range of diversity according to factors such as person, environment, route etc. and to learn through automated processes To specify relationships between the functions of route guidance systems, such as data flows within the systems, connections between different functions, and so on. It is necessary to take into account the system architecture of the autonomous navigation and the supported navigation schemes. To develop a hybrid route strategy that combines the route planning algorithm (modified A* algorithm) and the learning algorithm To integrate dynamic route guidance from the system s perspective and adaptive route guidance from the user s perspective. The parallel and proceeding research, Reliable Dynamic Route Guidance, aims to improve navigation systems in terms of network reliability. The two route guidance systems (reliable and adaptive) should be integrated to devise an advanced navigation system. The main aim of this research is to develop user models and routing models. The construction of user models entails identifying attributes affecting route choice decision and developing the process of learning user preferences. An adaptive multi-criteria routing model is being developed by incorporating user models into routing models, which will be built by a hybrid routing algorithm and a multi-criteria routing algorithm. A hierarchical system architecture should be considered in the routing models. The adaptive multi-criteria routing model is integrated with the reliable route guidance system before field tests are carried out. The above described research plan, consisting of seven research steps is visualised in Figure 1. Brief explanations of each step are presented as follows. 1. Identifying attributes 2. Learning user preferences Dynamic route Guidance User model System architecture 3. Hierarchical system architecture Route guidance 4. Hybrid route guidance Adaptive multi-criteria routing model 5. Multi-criteria routing 6. Integrating route guidance systems 7. Field test Figure 1: Research steps Step 1: Identifying attributes related to route choice: In order to capture user preferences on route choice, it is necessary to specify factors, which are relatively important and observable. Identification of attributes affecting route choice behaviour will start from all attributes which are dealt with in related research, considering data availability in network DB systems. Regarding travel cost among the attrib- Offensive Project Summaries Page 67 of 108

68 utes, there will be a focus on monetary costs. In fact, the introduction of traffic management measures such as congestion or parking charges has increased the monetary cost of car travel. In the meantime, there is a need to consider the fact that some attributes are link-specific whereas others are area-specific. For example, congestion or parking charges vary by area, whereas scenery and environmental quality is typically area-specific. Accordingly, the way to include these attributes in a model should be proposed. Step 2: Learning user preferences: Automatic recognition of user preferences by learning algorithms will be proposed. Attributes identified in Step 1 will be applied as variables. This feature aims to catch user preferences without asking the user to input these, but some attributes may be input by users directly before or during the trip via the navigation system. After discussing the requirements of user modelling and the most appropriate methods, user models will be incorporated in the routing algorithm. Step 3: Hierarchical system architecture: System architecture for adaptive route guidance may have a hierarchical structure, related to routing strategies. In the supported route guidance system architecture, sets of candidate routes are produced from the communication between the TIC and the invehicle system. Accordingly, a distributed system architecture where the routing strategy is divided into two phases, route generation in the TIC and route selection in the in-vehicle system would be suitable. Step 4: Hybrid route guidance: Routing algorithms will be formulated combining the current strategy, which is responsive to dynamic network traffic conditions, with adaptive route guidance, which is responsive to user preferences. A basic strategy will be to include automatically weighted attributes in the modified A* algorithm. Step 5: Multi-criteria routing: The influence of qualitative attributes on route guidance should be considered. Drivers, for instance, may not like driving in an area where the rate of traffic accidents is high. Driver behaviour research shows that past experience plays an important role in route choice. Familiarity is another qualitative factor. Methods to address qualitative attributes, such as fuzzy rules, can be applied. Generally speaking, these approaches are likely to take more time to find an optimal solution than single-objective approaches. Since route guidance requires the provision of real- time information, computation limits should be taken into consideration. Step 6: Integrating route guidance systems: In this step, the integration of dynamic route guidance and adaptive route guidance in one system will be investigated. An agent-based approach, where each agent is given a specific function in the navigation system, will enable the integration of two different systems. While carrying out this research, collaboration with the research on reliable route guidance will be continued. Step 7: Field tests: The final step is to test the functionality of a prototype of the integrated navigation system. The prototype will be tested in a real situation with real transport networks and traffic conditions. In order to analyse the level of efficiency and usefulness of adaptive route guidance, experimental methods and evaluation methods will be formulated Relationship with the parallel research project Because of the needs to collaborate with the parallel research, this research should start from understanding what is considered in conjunction. First, the key part of the shortest path finding algorithm applied in the proceeding research (Chen et al. 2005) will be the same. The previous research focuses on modifying the A* algorithm to increase computing efficiency and to consider dynamic route guidance in terms of network reliability. In this context, link cost function of the A* algorithm combines link reliability and link length as follows. t ij = t ij + = t ij + tij n q α ( 1 r ij ) W0, 0 < 1 < α q=0 when n =0, q=1 when n>=1 Offensive Project Summaries Page 68 of 108

69 where, t ij : mean normal travel time of link (i,j) t ij : incremented weight of link (i,j) r ij : reliability of link (i,j) W0 : penalty for unreliability α : discount factor included to ensure a feasible route n : iteration number in search for the risk averse route. The basic form of the link cost function will not be changed, but extending the function with other attributes related to route choice (e.g. no. of turns, length by road type, safety, or familiarity) is required. Travel time and link reliability along with other attributes will be weighted according to user preferences. Another important factor is the system architecture, which comprises two types of navigation; autonomous navigation and supported navigation. In the autonomous navigation scheme, routes are based on default estimates of link travel times and network data in form of an on-board CD-ROM, enhanced by broadcast dynamic traffic information about incidents. On the other hand, supported navigation exploits two-way data exchange between the guided vehicle and a Traffic Information Centre (TIC), where an optimal route is computed based on real-time traffic conditions, increasing the range and accuracy of information. The framework of the system architecture will be continued in this research ICL Current status Literature review In-vehicle navigation usage By investigating the usage and functionality of current in-vehicle navigation systems, factual considerations concerning the development of advanced navigation systems can be obtained. Svahn (2004) surveyed the usage of navigation systems for 84 current users. According to the survey results, navigation systems are most frequently used in foreign environments, whilst hardly ever used in wellknown environments; the usage of navigation is higher for longer trips. An interesting discovery is the fact that users with higher computer skills tend to use the systems more often, make use of most of its functions and do not worry about safety problems. Another market survey by J.D Power and Associates (2003) shows that 22% of the users make use of their navigation system every day, 33% make use of it once or twice a week and the level of usage is higher in the younger generation. According to these results, navigation systems do not seem to be used often for daily trips in familiar areas. In fact, the usage of navigation systems tends to increase in unfamiliar areas. It appears that those who travel to unfamiliar areas more often than others are more frequent users of navigation systems (J.D Power and Associates, 2004). Figure 2 shows that the frequency of frequent user s trips to unfamiliar areas is almost double than that of total users. never 1-2 times 1.1% per year 11.1% Almost every day 2.7% 1-2 timew per w eek 18.3% 1-2 times per year 1-2 times 4.3% per quarter 13.5% never 0.3% Almost every day 5.0% 1-2 timew per w eek 33.7% 1-2 times per quarter 24.7% 1-2 times per month 42.1% 1-2 times per month 43.2% a) total participants b) frequent users Figure 2: The frequency of the usage of navigation systems in unfamiliar areas (calculated from J.D Power and Associates, 2004) Offensive Project Summaries Page 69 of 108

70 Regarding the purpose of using navigation systems, it appears that about one of three users and two of three frequent users make use of their navigation system to arrive to unfamiliar locations, while they also need to use in familiar areas for the specific purposes such as finding the exact locations of addresses, alternative routes because of traffic congestion, or estimating travel time (Figure 3). Locating restaurants finding local retail stores finding alternative routes due to construction/traffic estimating time of arrival to destinations finding routes to unfamiliar locations finding residential/business address 0.0% 10.0% 20.0% 30.0% 40.0% 50.0% 60.0% 70.0% total users frequent users Figure 3: The purpose of using navigation systems (calculated from J.D Power and Associates, 2004) Even though this result reveals that users benefit from navigation systems regardless of their familiarity with the area, the efficiency of route guidance drops in familiar areas, where drivers often repeat the same trips. This leads to a decrease in compliance by the drivers in familiar areas (Bonsall, 1992). Dynamic route guidance systems (DRGS), along with real-time traffic information are expected to increase the efficiency of navigation systems, especially in familiar areas. However, field trials of the socalled ADVANCE navigation system showed that the familiar drivers were unsatisfied with the offered routes because they believed that they had a better knowledge of the network than the system, even though the routes were planned considering the current traffic situation (Schofer et al.,1997). Researchers reached the conclusion that this occurs due to three factors, namely: 1) coding errors and procedures to contain local network details, 2) routing biases of route selection criteria between public and individuals, and 3) limits in the quality of travel time data base. The additional function of selecting route choice options in advanced navigation systems can be considered as one way to reduce routing biases. The majority of the navigation systems currently available on the market, offers the option to exclude undesirable route segments such as motorways and toll ways. However, the techniques of this function may not yet be advanced enough, so as to drastically improve the efficiency of navigation systems. Route choice attributes for car drivers Attributes included in current navigation systems and research on route guidance are not diverse enough to address route choice behaviour. In fact, travel time and network reliability are the only attributes considered in previous research. In order to comprehensively consider user preferences, the idea is to consider first all possible attributes affecting route choice. According to Bovy and Stern (1991), route choice attributes fall into four categories; route, traveller, trip and other circumstances such as weather or time of day. The most important attribute would be the route characteristics, which can be divided into three sub-categories; road (e.g. travel time, distance), traffic (e.g. congestion, no. of turns) and environment (e.g. security, land-use). In total, 64 attributes are comprised in these categories. Since it is too many to utilise at the same time, it is necessary to sort more significant ones from the entire list. Offensive Project Summaries Page 70 of 108

71 A considerable number of studies have attempted to derive the relative importance of route selection criteria. The first study on route selection criteria dates back to the 1960s (Bovy and Stern, 1991). A factor analysis with 21 attributes related to route choice was carried out by Wachs (1967). The result of the analysis showed that travellers consider access controlled routes as the most important criterion, which includes the number of lanes, full-stop signs and traffic signals, width of lanes, pedestrian crossings, and smoothness of the pavement. These are followed by congestion, safety, travel distance, commercial development, scenery and absence of commercial development. While accessibility is most important in Wachs s study, Benshoof s study conducted in 1970 (Bovy and Stern, 1991) indicates that travellers are affected most by travel time. Traffic volume, travel distance, number of stops, driving comfort, safety, travel time reliability and habitual route are ranked next. A potential reason for the difference in the results from the two studies can be found in another study by Huchingson et al. (1977). This study points out that driver preferences are situation-dependent, that is, the relative importance differs according to the situation. For example, drivers characteristics (e.g. commuters in CBD or random drivers on motorways) and destinations (e.g. trips to work or trips to home) can be identified as situations. Stern and Leiser s study in 1988 (Bovy and Sterns, 1991) reveals that, the driver s competence, as well as the travel length in terms of both time and distance, also have an influence on the priorities of route selection criteria. The method of survey is another factor justifying the difference in the results. Consequently, an attempt to identify priorities of route choice attributes from the literature does not seem to be appropriate. Instead of ranking the attributes, Pang et al. (1995) sort the primary attributes used in the dynamic route guidance system. Travel distance, travel time, congestion, toll, degree of difficulty and scenery of a route are sorted as the primary attributes and all other factors as the secondary ones, which are not used in the system. On the other hand, the finding that travel distance and travel time affect the priorities of attributes has a significant meaning with respect to the relationship between attributes. Stern and Leiser (Boby et al. 1991) have found that perceived travel time is most important for short (< 3 km) trips, while the number of turns is the most important factor for medium (3 9 km) distance trips. Regarding travel time, perceived travel time is also most important for short trips (< 9 min), while it disappears from the top four attributes for longer trips (0 28 min). This indicates that travel time and distance have impacts on certain attributes and vice versa, or in other words, relationships between attributes can be described by a hierarchy, where the upper levels are considered as conditions. This implies that a method, which would be able to deal with these conditional interactions, would be most suitable for representing route choice behaviour. Methods for learning user preferences By learning user preferences, it is possible to provide services or information specific to user requirements (Torres, 2000). This can be achieved by personalising the functionality of the systems. In Artificial Intelligence (AI), many researchers have sought ways to learn about user preferences; these attempts have created an independent research area, that is, user modelling. A user model is considered to be a consequential outcome of user modelling. Figure 4 describes user modelling and a user model in adaptive systems. Figure 4. The structure of adaptive systems (Bruisillovsky, 2002) Offensive Project Summaries Page 71 of 108