Local Evaluation Report for ATLAS-ITS Phase II: Integration of Real-Time Traffic Information for Adaptive Signal Control, Traveler Information and Management of Transit and Emergency Services
Pitu B. Mirchandani and David E. Lucas The University of Arizona Department of Systems & Industrial Engineering Tucson, AZ 85721-0020
December 2005
ATLAS-ITS Phase II: Integration of Real-Time Traffic Information for Adaptive Signal Control, Traveler Information and Management of Transit and Emergency Services
Executive Summary Major roads and arterials in the City of Tucson and Pima County are already significantly detectorized with inductive loop detectors and, at places, with video-based detectors. These detectors are used for semi-actuated signal control and for limited traveler information. In addition, many intersections have systems that allow signal preemption by emergency services such as fire and ambulance. ATLAS II projects integrate real-time data from available detectors for (a) traffic adaptive signal control, (b) providing real-time traffic predictions to traveler information systems, (c) for adaptive signal priority for transit vehicles, and (d) for proactive coordination of signal phasing to provide preemptive pathways for emergency vehicles. The overall program consisted of six projects led by the University of Arizona, in cooperation with several public and private sector partners and/or collaborators. The goals and objectives of the ATLAS II program included: Assist in the development of an ITS Strategic Plan and Architecture that allows for the integration of real-time transportation information for planning purposes; Deploy and integrate a real-time traffic prediction method to provide data for an advanced traveler information system; Deploy and integrate a real-time traffic adaptive signal system for a grid of intersections to improve traffic flow; Deploy and integrate a transit signal priority system for arterial roadways for improved transit performance; Deploy and integrate a link travel time estimation system for arterial roadways to provide real-time data for use in traffic adaptive signal control; and Deploy a combined travel forecasting model, which is an alternative approach capable of evaluating future transportation and urban development plans while overcoming limitations inherent in existing approaches for large zone systems and networks.
2
In t ro d u c t i o n
The Systems and Industrial Engineering Department at The University of Arizona has been involved with several ITS projects, including operational testing of traffic adaptive signal control and research/development of innovative approaches to real-time prediction of traffic conditions and transit priority. The ATLAS II program integrates many of the results and expertise developed as part of these earlier projects. In particular, The University of Arizona and its partners/collaborators integrated available real-time traffic information from loop detectors and other sources for real-time traffic-adaptive signal control, for providing real-time traffic prediction for traveler information, for adaptive signal priority for transit vehicles, and for arterial link travel time estimation for improving real-time traffic-adaptive signal control system performance. In addition, a new approach to travel forecasting, which overcomes limitations inherent to existing methods, and an ITS strategic deployment plan for the local region were developed. Fortunately, major roads and arterials in the City of Tucson and Pima County are already significantly detectorized with inductive loop detectors and, at places, with video-based detectors. These detectors are used for semi-actuated signal control and for limited traveler information. Also, because of the field operational tests of RHODES (a real-time trafficadaptive signal control system developed at The University of Arizona), a set of intersections is connected via a dedicated fiberoptic communication system. Many intersections also include systems that allow signal preemption by emergency services such as fire and ambulance. Finally, the City and its public transit agency, Sun Tran, have also installed a transit management system that includes instrumentation of all fleet vehicles, providing near-real-time location data for use in traveler information and transit signal priority. A major goal of the ATLAS II program was to integrate these ITS elements into a system whereby data can be utilized to its fullest extent in order to provide maximum benefit to both system operators and users. The overall ATLAS II program consisted of six (sub-)projects, including the development of an integrated architecture conforming to the National ITS Architecture. These subprojects are: Development of an ITS strategic deployment plan and an architecture that allows for the integration of the required real-time information (effort led by the Pima Association of Governments (PAG); Deployment and integration of a real-time traffic prediction method for traveler information systems (in cooperation with the City of Tucson); Deployment and integration of a real-time traffic adaptive signal system for a grid of intersections (in cooperation with the City of Tucson and Gardner Transportation Systems (which later became part of Siemens ITS); Deployment and integration of transit signal priority for an arterial (in cooperation with the City of Tucson, Sun Tran and Gardner Transportation Systems); Deployment and integration of real-time arterial link travel time estimates (in cooperation with the City of Tucson); and Deployment of a `combined' travel forecasting model capable of working with large zone systems and networks (in cooperation with the Pima Association of Governments).
-
-3
The following chapters of this report will describe each of these six sub-projects in detail, report the results of each research effort, provide some insight into the technical and institutional issues that were encountered and explain how these were handled. While the final form of the ATLAS II program included the six projects described, the original program proposal covered five projects, one of which is not listed. This project involved the deployment and integration of route advisory and limited traffic signal coordination/preemption for emergency vehicles for the City of Tucson Fire Department. Due to a lack of necessary infrastructure discovered later, this capability was not realizable and thus the effort was directed toward two new subprojects which fit within the program goals which could be deployed. It is these types of realizations and adjustments, which will be described in detail in later sections, that provide the greatest barrier to deployment and integration of intelligent transportation systems and it is hoped that the knowledge and experience gained during the ATLAS II program will be of benefit to future ITS researchers as they work to overcome similar obstacles in their w4 ATLAS 2A Development of a 21st Century ITS Strategic Deployment Plan and an Architecture for Integrating Real-Time ITS ServicesProject Description This deployment plan seeks to infuse ITS data into the traditional transportation planning databases, mainstream ITS project development processes into those of transportation planning, and incorporate ITS in projects designed to increase capacity to the maximum extent possible. Pima Association of Governments (PAG) led and coordinated this effort; the University of Arizona participated in the development of this plan. Research Results An ITS Working Group, consisting of representatives from various PAG constituencies, as well from the University of Arizona, was organized. Monthly meetings continue today, with at least one ATLAS member regularly attending. PAG completed an inventory of all ITS elements in the Tucson metropolitan area and, using the latest ITS Architecture mapping software, has worked with ATLAS to develop an ITS Architecture for the Tucson metropolitan area. The PAG ITS Strategic Deployment Plan for the 21st Century is available from PAG. It continues to be revised as new ITS projects are defined and deployed.
5ATLAS 2B Development and Integration of a Real-Time Traffic Prediction Method for Traveler Information Systems
Project Description The objective of this project is to gather data and provide real-time predictions of traffic conditions to motorists � using developed algorithms and software for predicting traffic conditions including traffic volumes, turning ratios and other traffic parameters. Partners on this project included the City of Tucson and Siemens Gardner Transportation Systems. Research Results Various methods of gathering and displaying travel time data were reviewed by the project team and included discussions with methods currently available, for example, the method developed by Dr. John Leonard, of Georgia Tech. However, all of these required that frequent detector information be available at a central traffic operations center. Since this type of data was currently only available along a single corridor, as described below, that site was used to provide the initial data set. A system for gathering this data and presenting it in a usable form was developed by the research team and provided a source of arterial data that has since been made available to other researchers. Using this data, an algorithm to predict arterial travel times, using real-time signal status and detector data, was developed, resulting in a prototype traveler information system covering the project area. A paper detailing the algorithms and research results has been published: W. H. Lin, A. Kulkarni, P. Mirchandani (2004) "Short-term Arterial Travel Time Prediction for Advanced Traveler Information Systems", Journal of Intelligent Transportation Systems, 8(3), pp. 143-154. Technical/Institutional Issues When this project was first proposed, it was understood that the City of Tucson's detection system was fully operational and capable of providing the type of data required to support this project. Unfortunately, this proved not to be the case and this lack of data was a major obstacle to the progress of this project. Infrastructure limitations constrained the data collection area to a section of Speedway Blvd just north of the University of Arizona campus. Part of the Living Lab for Transportation Technologies, a stretch of this major arterial is configured with sufficient detectors and communications to support the algorithms developed as part of this research effort.
6
ATLAS 2C � Deployment and Integration of a Real-Time Traffic Adaptive Signal System for a Grid of Intersections
Project Description The RHODES Real-Time Traffic Adaptive Signal Control System has been shown to be an effective control strategy when deployed on arterial networks. The purpose of this project was to deploy RHODES on a grid network to determine if it would be effective with this network topology as well. The existing RHODES installation in Tucson consisted of seven intersections on Speedway Blvd, between Euclid Avenue and Country Club Road. The proposed project called for extending this system southward, along both Euclid Avenue and Campbell Avenue, then along Sixth Street as well, completely encircling the University of Arizona campus within a grid of RHODES-controlled intersections (see Figure 1). The Research Team was tasked with designing a communication system to incorporate these new intersections into the existing system, while integrating with the existing traffic control hardware to provide adaptive signal control. The final task was to evaluate the system to determine its effectiveness.
Park Ave Cherry Ave Country Club Rd Campbell Ave Euclid/1st Ave Mountain Ave Tucson Blvd Actual Expansion
N
Grant Road
Pima/Elm
University Medical Center
Speedway Blvd
Second Street
Third/University
University of Arizona
Sixth Street
Existing RHODES Signals
Proposed Expansion
Figure 1 � Site Map
7
Technical Issues Unfortunately, the scope and timeline of this project changed dramatically over time as various impediments came to light, and continue to do so. The first challenge was to decide on a new test site when it became apparent that the intersections along the proposed expansion could not support RHODES, as was originally believed. When the project began, an inventory of available conduit, power sources, cabinets, detectors and other infrastructure was made to determine if any deficiencies existed. Through this process, the team discovered that none of the intersections along the proposed expansion route could support the demands of this project without a major redesign, estimated to cost in excess of $100,000 each. This was due in large part to the age of the intersections, leading to a lack of sufficient conduit space, detector infrastructure and other requirements. In addition, the University had already planned a large amount of construction work along the proposed expansion route, leading to concerns about construction delays and other impacts. At this point, other possible sites along the existing RHODES system were examined in detail, with the project team deciding that the site directly north of the University was the best option among those available. This site (see Figure 1) extends the existing RHODES network north along both Euclid/First Avenue and Campbell Avenue, then along Grant Road, adding five intersections to the existing network, similar to the initial proposed site. Part of the decision-making process when selecting the new expansion site was the consideration of how it would be incorporated into the existing communications network to provide the peerto-peer communications needed by RHODES. While the existing RHODES network consisted of fiber optic links, the high cost of installing additional fiber precluded this as an available option along the expansion route. Alternative technologies, such as the use of CDPD modems and spread-spectrum radio equipment, to provide the needed connectivity were explored, but each had specific deficiencies that made it inappropriate for the current project. About this time, the City of Tucson began planning a pilot project to evaluate the ability of using high-speed wireless networking to provide real-time communications between a hospital emergency room and paramedics in the field. Learning of this effort, the Research Team designed a wireless communications system that satisfies the communications needs of the current RHODES project, as well as the "ER-Link" pilot project. Using off-the-shelf hardware from Cisco Systems, an 802.11b point-to-point wireless network was constructed to provide interconnects between the five expansion intersections and the existing fiber optic network, as well as a mobile router to be used for the ER-Link pilot project. Figure 2 shows the four pointto-point wireless links that were created, using five wireless bridges, providing the desired connectivity between neighboring intersections. Other remaining tasks involved the integration of RHODES with the traffic control hardware and the installation of additional detection. These tasks were delayed significantly due to a major redesign of two of the project intersections (Grant/Campbell and Grant/Elm). In the process of this redesign, the existing traffic cabinets were replaced with ones incompatible with the NextPhase 2070 controller software and system loops were removed as part of the roadway construction. This necessitated a hardware modification by City of Tucson personnel to alter the cabinets to work with the existing controller hardware and software as well as the installation of new system loops along Campbell.
8
Park Ave
Euclid/1st Ave
Campbell Ave
Mountain Ave
Tucson Blvd
Cherry Ave
N
Grant Road
Pima/Elm
University Medical Center
Speedway Blvd
Fiber Optic Network
Wireless Network
Figure 2 � Communications Network Once all of these hardware/infrastructure issues were resolved, the actual work of installing and configuring RHODES on these five additional intersections began taking place. The Research Team completed this work in September 2004 and began monitoring the expanded network through a new field-to-central monitoring capability that had been added to the RHODES system as part of this project. This provided the ability to passively monitor the status of each intersection in real-time to confirm that the communications system was functioning at an acceptable level, while providing a stream of information that could be stored for other purposes, such as integration with the City of Tucson's Traffic Management System. Unfortunately, further hardware issues arose, as intersections began going into "flash" condition (where are approaches are given a flashing red indication) at various times due to problems with the 2070 controllers and the NextPhase software which caused the 2070 to restart. The Project Team and its partners were unable to resolve the cause of these problems, so the decision was made to replace the 2070 controllers with the Econolite ASC/2S controllers previously used by the City of Tucson at these locations. This option became available as a result of parallel efforts of the Project Team to enable RHODES to be used with an off-the-shelf ASC/2S controller, in conjunction with a separate RHODES project. For this project, the system was only partially deployed. Components of the planned system were tested, but the RHODES control of the complete grid network did not take place. As of the writing of this report, 6 intersections are currently using the Econolite ASC/2S controllers, with the remaining 6 2070 controllers scheduled for replacement in the near future, once the necessary hardware is obtained. At all twelve intersections, RHODES is operating in Standby, or "passive", mode, collecting information about detector and signal status, as well as peer data from neighboring intersections. However, signal control information is not being returned to the controller, which continues to operate using the regular time-of-day coordination patterns.
Country Club Rd
9
With a complex system such as this, there are multiple failure points, as all components are interdependent and must be operational for the system to work properly. Several times, the research team replaced the final piece of non-working equipment, only to have another piece fail just a day or so later. In addition to the project delays this caused, there were repair costs as well as personnel costs to handle these events. The project team would recommend that future projects incorporate a budget item to cover such `incidental' or maintenance costs to ensure that they can be handled within the project budget. It is hoped that, barring any additional hardware issues, that the Project Team will be able to have the system operate in Online mode sometime in the future, i.e., with RHODES actively controlling the intersections. This will be at no cost to ATLAS Phase 2 budget (since the project is already completed) but as a contribution provided by the ATLAS Center and the University of Arizona. The ATLAS Center and the City of Tucson have signed a Memorandum of Agreement to make this happen. After the system completes its initial run successfully, the Project Team will make any necessary changes to the system's operation, at which point it will be monitored and evaluated by team personnel. It is expected that the system will be left in operational mode following the completion of this evaluation period during select times to be decided upon by project participants. This will provide for a set of continuous technical feedback based on the system's performance while also providing a live data set for evaluating future system upgrades. Some Project Products The project resulted in several `products' that can be used by project participants and others in related areas. First is the use of off-the-shelf 802.11b Wi-Fi networks in modern transportation systems. While a few other uses of this technology for this purpose have been reported, the number of installations has been small as the transportation community gathers information about the ability of this technology to satisfy their needs. The results of this project show that this type of network is a viable alternative for providing communications in transportation networks and should be considered when deciding on communications upgrades of network expansion. Results thus far show that while intersections on the fiber portion of the RHODES system have almost no packet loss, those on the wireless segments show a loss rate of, on average, 1%-3%. Based on the experience of the Research Team, the amount of data loss over a wireless network, as well as the time required for configuration and maintenance, is greater than for other `land-line' solutions and should be considered as part of the decision-making process. Another expected product is the demonstration that RHODES can provide effective signal control in a grid network topology, as well as in arterial applications. As each RHODES intersection communicates with its peer or neighboring intersections, data about changes in vehicular demand are transmitted along the network, regardless of the underlying topology, effectively providing a measure of "implicit" coordination. While not providing explicit progression bands on a regular cycle, we believe that this type of control will be appropriate in many instances, especially in light of the benefits that adaptive control provides over traditional coordinated control.
10
Institutional Issues As with any large project involving several agencies, issues arose that had to be resolved in order for the project to move forward. Some of these were technical, related to either hardware and/or software, while others were what could be referred to as `institutional' issues. For example, one of the technical issues involved configuration and installation of the wireless networking equipment, which required significant time by the Research Team to overcome in order to produce a working system. In this project, the tasks were very interdependent and a lack of progress on one would severely hamper progress on another. This was evident almost from the beginning when it became apparent that the proposed project site was no longer a feasible option. A large amount of time was lost reviewing alternative sites, conducting field inventories, etc. in order to even begin work on the project tasks, including the communications system design and other integration work. Other projects have shown the importance of having a "champion" within each participating agency or organization to provide leadership and direction to ensure that progress is being made towards the project goals. As an example, plans for upgrading two of the project's intersections were already underway when it was discovered that the new traffic cabinets would be incompatible with other project components, such as the traffic controller software and that some required detection equipment was scheduled for removal. More oversight into aspects of the project would have identified this as a potential problem, allowing it to be addressed during the design phase, rather than forcing the design team to re-design part of the integration work to overcome it. Over the course of the project, each participant was required to balance its commitments to the project with all of its other responsibilities and duties, sometimes resulting in temporary halts in progress as effort was directed elsewhere. This was a problem throughout the course of this project as budgets limited the availability of key personnel, affecting the ability of the Research Team to complete various tasks. For future projects, we would recommend that each participant ensure they are fully aware of the commitment being made by becoming part of the research team and confirm that sufficient resources are available to accomplish the project goals, as proposed. This is perhaps the most important factor affecting the success of any project and will have the biggest impact upon the research team's ability to complete the project tasks in time and within budget. There is now a "Memorandum of Understanding" between the City and the ATLAS Center to work together to implement new transportation technologies, especially those that deal with adaptive traffic signal systems. Still, even with this MOU, the City moves very slowly in meeting its commitments.
11
ATLAS 2D � Deployment and Integration of Transit Signal Priority for an Arterial
Project Description The primary motivation for this project was to extend earlier research into integrating Transit Signal Priority (TSP) within the RHODES architecture and to compare this system with alternative methods of providing TSP. The Research Team was first tasked with integrating realtime bus location information from SunTran's TransitMaster 2001TM system with the existing network. This information would then be used as input to algorithms developed by the team to estimate bus arrival times at intersections along the RHODES Speedway Corridor. A simulation analysis of these algorithms and the RHODES TSP system would then be evaluated via simulation, with the most promising of the TSP approaches implemented and evaluated. Technical Issues In other recent research projects, the Research Team had successfully integrated RHODES into various communications networks and hardware platforms. Thus, given the Team's knowledge of hardware interfaces and communication networks, it was envisioned that the application of TSP within the Tucson RHODES system would be straightforward. However, the research team faced many obstacles on the path to implementation, almost from the start. The first task was to gather real-time bus location data and make it available to the Research Team. Unfortunately, as personnel from City of Tucson's several departments were involved in simply provisioning a network connection between the University and SunTran servers, this task alone took an exceedingly long time to accomplish. Even after initial connections were functioning, several network interruptions took place during the latter stages of the project as changes were made to the City's network settings, such as configuring a firewall to disallow access between the networks. Since these interruptions were not communicated to the Research Team directly, the project was further delayed. Notwithstanding the networking issues, other issues arose surrounding the TransitMaster database, from its format and underlying structure to ways of accessing it, delaying the team's ability to evaluate the type and quality of data available. Information about the contents of the data was provided in written documentation that was found to be out of date and which had almost no support available from either the supplier or the system operators. Thus, obtaining the desired information from the system turned into a trial-and-error process, increasing the time required to continue on to the next step of actually using the data. The TransitMaster database resides at SunTran and is connected to the City of Tucson's communications network over the I-Net, a SONET network connecting various city departments and educational facilities, such as schools and libraries. As the University of Arizona was also connected to the I-Net, the Research Team decided that the best option for connecting to the TransitMaster database would be through this network. Bringing together personnel from the University of Arizona's Center for Computing and Information Technology (CCIT) and the City of Tucson's Information Technology (IT) departments, the Project Team developed a plan that
12
would connect the UA Living Lab to the I-Net, through a link available at CCIT, which would then provide access to the TransitMaster database at SunTran. This required the installation of SONET hardware in the Living Lab, as well as the installation of additional fiber optics between the Living Lab and CCIT, and required a significant amount of time to complete. Additional complications included providing access to UA facilities for City of Tucson IT personnel for maintenance and support to ensure the security and integrity of the I-Net while satisfying the concerns of departments from both the University of Arizona and City of Tucson. Note that all of this work was simply to get a connection established between the two networks. No data, as of yet, was actually being transferred. With a network connection now in place, the research team met with SunTran personnel to gain access to the TransitMaster database and begin evaluating the data that was available. It was learned that the information needed for this project was not available in a single location, but was spread across several different tables within the database, some of which could not be made available directly. The decision was made to create a new database, housed in the UA Living Lab, containing only that data needed by the project team, which would be populated in real-time from the TransmitMaster database. This would minimize concerns about placing a large load upon the database server while giving the project team unrestricted access to the data once it had been copied over into the local database. Within this framework, SunTran provided access to the TransitMaster database in order to monitor the system and update the local database as new records were added. Evaluation of the available data then began in earnest, with the software needed to maintain an up-to-date database of location data developed by the project team over a period of several months. Unfortunately, a lack of direct support by the TransitMaster system developers, in this case Siemens ILG, led to a lot of wasted effort, as the team grappled with understanding how the data was acquired and stored, and the format in which it was finally made available. ATLAS Research Team's understanding of database and format resulted only after several failed attempts; this understanding that could have been gained through a simple support call. Attempts to request support from the system developer were unsuccessful, given their understandable reluctance to support the development of a potentially competitive product (Siemens ILG also provides Transit Signal Priority software). As a result, the software development effort needed to provide the Research Team with an accurate stream of data mirroring that available within the TransitMaster system required several months to complete. Once this effort was complete, The ATLAS team began the development of algorithms to estimate arrival times of transit vehicles at various points in the network. The efforts focused on estimating arrival times to the intersections of Speedway/Park and Speedway/Mountain, two of the intersections on the RHODES Corridor. These intersections were already connected to the Living Lab network and would provide a suitable test site for evaluation of the system when completed. It was decided to focus only on the westbound approaches to these intersections. The Research Team developed methods for estimating arrival times using the available information, which consisted of periodic (approximately every 40 seconds) location updates via GPS reporting of the vehicles' longitude and latitude. Examining the available data in detail, it was discovered that some of the information needed, namely the direction in which the bus was
13
traveling, as well as the route to which it was assigned, was not available using the existing software developed by the Research Team. After several discussions with personnel from SunTran and research by the team, the location of the needed data was identified and the software was then updated to include the transfer of this data to provide a complete set. The estimated time of arrival (ETA) is based upon projecting the vehicle's current location based upon previous reports. Unfortunately, updates are only provided every 40 seconds or so, meaning that the error in the estimates can be quite large as several factors can confound the estimate, including traffic flow interruptions, number of passengers entering/exiting the transit vehicle, whether any handicapped riders are present and whether the bus is on schedule or not. The implemented ETA algorithm is a two-stage process. First, using a time point far upstream of the intended destination, the vehicle's crossing time is compared with the published schedule to determine if the vehicle is on time. Any deviation is then taken into account when the initial ETA is computed, using the remaining distance to the destination. As the vehicle approaches the destination, additional location updates are provided and used to update the ETA. Once the vehicle has passed the destination, the actual time required to travel from the upstream time point location, as well as the default travel time from the published schedule, is used to calculate a "weighted average value" to adjust future estimates accordingly. Note that this method works well if there are no significant delays along the bus route. However, during rush hour and other congested periods, the assumptions of this method limit its ability to provide accurate ETAs. If a large deviation between the latest ETA and the average is found, the algorithm relies upon a second method to estimate the travel time by dividing the bus route into multiple zones. Using historical data, average travel times for each zone can be estimated as new location updates are received, with the travel times summed up to estimate the ETA at the destination. Experimental results indicate that during periods of congestion, e.g., from 4-6pm, this modification improves the accuracy of the arrival time estimates over the original approach. With an accurate ETA available, all that is left is to communicate this information to RHODES so that this information can be incorporated into its decision-making. This is currently handled by transferring a small data file to RHODES each time updated ETAs are calculated. This file contains the route number, ETA in seconds and whether the bus is late or not. Using this information, RHODES updates the ETA of any vehicles it previously received information on and then decides if priority should be given to an arriving vehicle. Currently, priority may be given unconditionally, i.e., always, or only when a vehicle is late, with separate parameters for each route. For example, if a specific route is an express, then you may wish to always give it priority, while a standard route would receive priority only when it is running behind schedule. When the ETA indicates the vehicle is sufficiently close, RHODES will issue a constraint on its phase sequence to ensure that the vehicle needing priority receives a green indication when it arrives. As there is some error inherent in the estimated arrival times, this phase constraint is currently applied for +/- 5 seconds of the given ETA. This is to improve the likelihood that priority will be given when the vehicle actually arrives, while also ensuring that incorrect arrival times do not adversely impact the operation of the intersection. Evaluation of this system using real data from the Living Lab indicate that it works reasonably well under normal operating conditions and is a feasible method of providing transit signal priority.
14
There are several improvements that can be made to improve the system further. Increasing the frequency of the AVL updates to 15-20 seconds would improve the accuracy of the ETAs greatly by improving the ability to track vehicles more closely. Another improvement could be gained by incorporating information about the use of wheelchair lifts and bike racks, as well as the number of passengers boarding/disembarking to better estimate the time spent at each bus stop. Typically, as the congestion on the road increases, the number of transit riders also increases during this time, so better and more accurate information is critical to such a system operating well during these busy times. We should note that occasional anomalies in the SunTran data were observed, where, for example, the database would indicate the imminent arrival of a vehicle that was not really there. Also, during congested periods, such as 4pm-6pm, the system appeared to become less stable, with less frequent updates than normal and incorrect data being reported. For these and other reasons, the performance of the system is far from perfect, yet it is sufficient to demonstrate the practical application of our approach. The system implemented here is a proof-of-concept study which shows that the incorporation of available AVL data into the RHODES adaptive control system is a viable approach to provide transit signal priority. In addition, the system provides ETAs that can be used to monitor the performance of the system and which could also be used to provide information to waiting passengers through an expansion of the existing system to include signage at nearby bus stops, through either wired or wireless connections or by updating an online route map with ETAs. The coarseness of the data currently available from the SunTran system may preclude its use under daily operating conditions, but in other areas with more frequent location updates and additional passenger information, this system provides an effective method of transit signal priority in conjunction with adaptive traffic control. The software used to transfer data between the TransitMaster and Living Lab databases can be adapted for other uses and is currently also being used to support other University of Arizona research by providing data for use in trip planning to investigate the reliability of making transfers and improving the rider's experience. In addition, the modifications made to the RHODES software provide additional features not previously available, which increases interest in the system while demonstrating the power this type of architecture provides. Institutional Issues By far, the largest impediments in this project were institutional ones, where the exchange of information created formidable barriers to progress that could often only be overcome by brute force methods. Future projects of this nature require increased support by all project participants to ensure that information and data being offered as available is actually in a usable form and that every effort has been made to overcome any issues that could arise regarding the use of proprietary data or software. In addition, project participants must be committed to helping to resolve any issues that arise within their own organizations that may become serious impediments. This was most apparent when the Research Team was attempting to create a connection between the networks of the University of Arizona and the City of Tucson. Each IT department was focused on the effects of such access on its own network and the team, as a whole, was unprepared, and at times, unable, to resolve these issues when they arose. By
15
helping to address these types of issues before the initiation of the project, and by acting on behalf of the entire network team, others in the organization may be able to improve the way in which some of these goals could be achieved. This includes the addition of representatives from such groups into the project team so that the team includes those responsible for making commitments and decisions in regard to resources under their control. Such an arrangement would have helped greatly to ensure better communication with other team members when decisions were made to change how access to the City of Tucson network was made, for example. Rather than responding to a network outage and trying to resolve it after the fact, such issues could be addressed and communicated beforehand, eliminating such problems before they begin.
16
ATLAS 4C(a) � Real-Time Estimation of Arterial Travel Times
Project Description Travel time estimation for freeways using loop detector data is well developed. In general, these results are based on a simple stochastic model for freeway travel, in which vehicles that arrive at an upstream detector during a given time interval have a common probability distribution of travel time to a downstream detector. This model assumes (1) there are no vehicles entering or exiting the roadway between detectors, and (2) the probability distribution of travel time is invariant within a given time or distance. However, for urban arterials, traffic flow is significantly affected by vehicles entering and exiting the roadway. Furthermore, for real-time applications, higher resolution data are required, with a time interval of a few seconds. Although it is feasible to obtain loop detector data every second, there is a lack of an accurate traffic model that can fully use these data for arterial travel time estimation. The Research Team has postulated two different models for estimating link travel times. In one approach, a set of detectors is used to identify platoons of vehicles. Downstream of this is another set that identifies platoons. Using a maximum likelihood matching approach, the upstream set is matched with the downstream set. Once the matching is performed, it is straightforward to estimate prevailing travel times for each of the platoons. This approach offers several advantages over existing methods and provides good travel time estimates for arterial networks. The second approach assumes that there is an entering stream U1 at one of n given locations d1i (i=1, ..., n); and an exiting stream U2 at one of the m given locations d2i, (i=1, ..., m). The magnitude of each stream and the position of the entry and exit points are random variables. The impact of the disturbance streams on arterial flow is considered using different probability distribution functions fk (k=1, 2, 3), corresponding to: (k=1) no vehicle access, (k=2) vehicle entering and (k=3) vehicle exiting. These two approaches will then be evaluated for deployment purposes, in terms of accuracy and computational times. Research Results The first method proposed was implemented and evaluated using data and simulation models available from the Living Laboratory for Transportation Technologies, and was shown to provide good results for various arterial segments using real-time detector data. This method is currently being incorporated within the RHODES traffic-adaptive control software to provide improved performance and added functionality. The second method had undergone some initial implementation and testing, but was fully implemented not for evaluation. A paper describing the first method was presented at the 2004 Annual Meeting of the Transportation Research Board and the results are available in the following publication: D.E. Lucas, P.B. Mirchandani and N. Verma, "Online Travel Time Estimation Without Vehicle Identification", Transportation Research Record: Journal of the Transportation Research Board, No. 1867, pp. 193-201, Washington, D.C., 2004.
17
ATLAS 4D � Implementation of a Combined Travel Forecasting Model for the Tucson Region
Project Description Travel forecasts by class of traveler (or trip purpose) and modes are needed to evaluate future transportation and urban development plans. Traditionally, such forecasts have been prepared using the sequential, or four-step, procedure, a time-consuming and awkward approach with inherent limitations for the comparison of alternative plans. This project will deploy the Combined Model � an alternative approach that combines trip distribution, mode choice and assignment steps, which is practical for large zone systems and networks. Research Results Professors Hillel Bar-Gera and David Boyce (the developers of the Combined Model) visited the ATLAS Center in July 2002 and March/April 2003, respectively, to work with Professor Mark Hickman and other ATLAS personnel on this project. During the project's initial stages, standard traffic assignment models were tested, using data provided by the Pima Association of Governments, which was based on over 600 zones. A new model developed by Bar-Gera and Boyce (Origin-Based Model) was also tested, which proved to be much faster and accurate in convergence. It is planned that the Origin-Based Model will be used as a nested subroutine in future development of the Combined Model. PAG provided most of the data for the Combined Model and the model was fine tuned with that data. The Combined Model considers four modes (auto, transit, walk and bike) and uses the algorithm based on Frank-Wolfe Decomposition to solve for both the origin-destination flows and for the network assignment. A large number of summary measures of automobile and transit travel have been replicated. Unfortunately, in 2004, the PAG transportation planning group decided to change is network description to an 859-zone model, requiring that the Combined Model be recalibrated for that number of zones. These include new calibration data from PAG, through the 2000 household survey and volume counts on many of the major arterials in Tucson. Changes in data, and data format, resulted in additional analysis of model outputs, which still is currently underway. A draft final report on the project is available.
18
