Macro-level Traffic Simulation and Case Study Development for Ivhs System Architecture Evaluation

As a part of the ongoing IVHS Systems Architecture effort sponsored by FHWA, contractor teams are using traffic and communication simulations in an effort to quantify impacts of implementing their proposed architectures. One aspect of this modeling effort has been the application and modification of a macro-level traffic simulation, INTEGRATION, to capture the effects of proposed evaluatory designs based on the architectures. A set of case studies have also been developed on which the contractor teams may base their evaluatory designs. These case studies correspond to scenarios from urban, inter-urban, and rural areas. In this paper, the authors describe the approach taken in the modeling of architectural concepts within the INTEGRATION simulation. A description of the various vehicle types available in INTEGRATION is provided. These vehicle types are utilized within the study to represent the behavior of both guided and unguided vehicles, including the modeling of different levels of functionality in guided vehicles. In addition, specific model features which permit the consideration of vehicle probes as point sources of travel time information are described. The manner in which the presence and quality of alternative surveillance systems can be modeled is also discussed. Changeable message signs and beacons of various functionality levels are also modeled, as are high-occupancy vehicle facilities and restricted-acess links. Communication subsystem performance can also be reflected within the traffic simulation, including ATIS or ATMS updating intervals. In the second part of this paper, the development of suitable input parameters detailing the selected scenarios is presented. The data was developed to provide a uniform test-bed for the evaluation of architectural designs. Topics include the generation of network topologies, link and signalization characteristics, and the construction of dynamic travel demand patterns. An overview of the three scenarios are presented, with a more detailed examination of input generation for the Urbansville network, a macro-level case study based on a subset of the Detroit, Michigan roadway network. Topic keywords: System Architecture Evaluation, Traffic and Transportation Modeling, Benefits 1.0 INTRODUCTION One of the goals of the IVHS Systems Architecture research effort sponsored by the FHWA is the identification of a national architecture. The effort is comprised of two phases. Phase I (completed in January 1995) featured the evaluation of competing architectural approaches, while Phase II (beginning in 1995) features a consensus-building process to resolve incompatibilities among architectural approaches leading to the identification of a national standard. In either phase, the task of identifying and differentiating a promising IVHS architecture from alternative approaches necessitates the ability to quantitatively assess competing architectures over a range of issues. Proposed architectures are evaluated against a set of criteria designated by the FHWA (1). These criteria range from cost, functionality, performance, benefits and risks to qualitative issues such as inter-jurisdictional cooperation, market potential, and societal priorities. McGurrin (2) provides an overview of the IVHS architecture assessment methodology identified for the research effort. A subset of those criteria that are currently evaluated through modeling are detailed in Table 1. These criteria were selected for modeling because they were considered critical, sensitive to architectural approach, and because the state-of-the-art in modeling allowed for at least a first-cut quantitative approximation of these issues. The criteria evaluated through modeling in the architecture effort center on capturing nuances of two distinct aspects of the proposed architecture implementation. The first aspect can be described as the effect of architecture implementation on traffic conditions and network mobility. The second aspect is described as the ability of the architecture to support the communications load placed on the system. 1.1 Traffic and Communication Modeling Contractor teams selected by FHWA have developed candidate physical architectures. Since it is not possible to quantify the performance of a physical architecture, contractor teams also develop representative evaluatory system designs for a set of uniform scenarios, or case studies. Three scenarios have been developed for use in the architecture project, corresponding to representative urban, rural, and inter-urban geographic regions. Uniform scenario data, detailing scenario features such as roadway topology, travel demand patterns, demographic information, and terrain data, were developed and furnished as government-supplied baselines to all contractor teams. The government-supplied scenario data provides a common baseline for the evaluation of evaluatory designs. A common set of traffic models were identified (2) to insure comparability of modeling results. Traffic modeling and communication modeling are employed interactively by both the contractor teams and government evaluators for architecture evaluation. Traffic modeling provides a measure of the benefits accrued to the system because of the architecture’s implementation, both in terms of system and user travel time reduction. Communication modeling justifies that the communication system proposed for the architecture has enough capacity to handle expected demands. Traffic modeling and communication modeling must be considered as interdependent for architecture evaluation. For example, the traffic model will use an update period and missed message rate supported by analysis from the communications model. In turn, data from the traffic model on localized flow conditions will be used to determine the demand on the communications system. The overall traffic and communication modeling approach is illustrated in Figure 1. In the upper left of Figure 1 are government-defined data files describing a specific geographic region in terms of roadway networks, associated trip tables, and other data. Contractor team deliverables are indicated in the upper right of Figure 1. The contractor teams supply evaluatory design plans for each scenario. These plans describe the location and function of all system components. The contractor teams then alter input parameters to the traffic and communications models, selecting and justifying values which best represent their architectural approach. 1.2 Role of Macro-Level Traffic Modeling Traffic modeling within the architecture effort entails both macro-level and micro-level modeling. Macro-level traffic modeling for architecture evaluation focuses on what has been termed as strategic architectural modeling analysis. Strategic analysis focuses on a larger geographic area with less detail. Strategic analysis will also deal with relatively large numbers of vehicles (tens of thousands) in the system. Most traveling is done on highways and major arterials. A key analysis done at the strategic level is measuring the benefit of route guidance, coupled ATIS and ATMS strategies, and trip planning technology. In order to facilitate macro-level modeling within the architecture effort, two key tasks were undertaken. First, a suitable traffic simulation needed to be identified or developed. Second, a set of data for the simulation derived from the identified scenarios had to be generated. This paper presents the approach taken by the authors in these two areas. Section 2 of the paper describes model features and modifications employed in macrolevel modeling to reflect aspects of architectural design. Section 3 of the paper presents the development of the macro-level traffic modeling case study data for the enhanced traffic simulation program. A review of state-of-the-art traffic modeling capabilities (3), indicated that no single traffic simulation satisfied all the requirements for architectural evaluation. Desired modeling functionality included the ability to evaluate alternative route guidance strategies, model large-scale mixed freeway and arterial networks, and allow for the differentiation of communication system-specific architectural attributes such as point source versus broadcast-based approaches. Two traffic models were identified with enhancements for the architecture effort: INTEGRATION (4) for macro-level modeling and THOREAU (5) for micro-level modeling. The INTEGRATION simulation model required modification to meet the functionality required for architecture evaluation. In Section 2, these architecture-related enhancements are detailed. Suggestions for model enhancements came from several sources. Initial modifications to the model were implemented with respect to the requirements identified before the start of Phase I . Ongoing development during Phase I also included the suggestions for model features made by contractor teams. 2.0 MODEL DEVELOPMENT The INTEGRATION model is a microscopic network traffic simulation model that has been under continuous development since 1985. It has been applied by the model developers and others to a wide range of hypothetical and actual networks (6, 7). The model’s capabilities and structure make it well-suited for the evaluation of IVHS systems and control strategies. Since more general descriptions of the model appear elsewhere in the literature (8, 9), the model description provided in this paper is limited to the presentation of enhancements to five representative model capabilities that are particularly relevant for the evaluation of IVHS system architectures. First, a set of vehicle routing strategies supported by the model is presented. The modeling of surveillance systems and the flow of surveillance data from the field to the traffic management center (TMC) and from the TMC to the field are presented. The model’s ability to represent probe vehicles and the data that are available from these vehicles are described. Next, the changeable message sign (CMS) and ATIS beacon modeling capabilities of the INTEGRATION model are presented. Finally, some of the input parameters which may be varied in relation to communication subsystem capabilities are presented. 2.1 Driver Classes and ATIS Functionality Choices The different driver classes that can be modeled with INTEGRATION refer to the capability to represent different routing behavior or different access privileges to travel time information for each class of drivers. For each driver class, the user may specify the type, the quality, and the update frequency of any traffic information that is available to the driver, and how these data are used by the driver to choose their routes. For Phase 1 of the Architecture Study, only four driver/vehicle classes were modeled, each class with pre-defined routing capabilities. For Phase II, the INTEGRATION model has been generalized to permit the user to assign one or more routing characteristics from a comprehensive menu of choices to each one of seven driver classes. This flexibility not only provides the user with the ability to model a larger number of driver classes within a variety of architecture frameworks, but also provides a greater flexibility in terms of how these features can be combined. Up to seven driver or vehicle classes may be modeled and evaluated simultaneously. For example, high-occupancy vehicles (HOV), commuter, unfamiliar driver, commercial traffic, transit, and vehicles equipped with route guidance systems (RGS-capable) may be concurrently modeled and travel time performance compared. Table 1 provides a summary of the driver class routing options currently available within the INTEGRATION model. In addition, individual link access may be controlled by vehicle class. For example, HOVonly, transit-only or HAZMAT-restricted links might be designated in a network. Only vehicle classes with proper link access permissions will be allowed to traverse designated links during the simulation. 2.2 Surveillance Modeling Options The INTEGRATION model is capable of representing a range of architectures in terms of alternative data paths from the field to the TMC, and from the TMC to equipped vehicles in the field. Typically, there exist two general sources of traffic data field surveillance equipment, such as standard loop detectors, and vehicles equipped with the capability to directly transmit information to the TMC. These data sources provide traffic information, usually in the form of link travel times, to the TMC where the data are fused prior to the dissemination of these data from the TMC back to any equipped vehicles in the field. The INTEGRATION model permits the user to specify which links in the network are under surveillance, and as such are tracked in a dynamic database at the TMC. Currently, for such links, travel time information is compiled in the TMC as an exponentially smoothed average. Each time a vehicle traverses a link under surveillance, its travel time is incorporated into the moving average. The reliability, importance, or weighting, that is placed on the travel time estimate obtained from a vehicle of a particular class can be user specified. Thus, it is possible to reflect the relative reliability with which different travel time data can be obtained from different driver classes. For example, vehicles equipped with the capability of directly broadcasting their travel times to the TMC, can be modeled to provide more reliable travel time information than vehicles that do not have this capability. To provide greater flexibility in reflecting various architectures, individual links with the network may have vehicle specific weighting/reliability factors that are different from the network-wide default values. Thus, it is possible to reflect the situation in which travel time information cannot be obtained from RGS-equipped vehicles via radio broadcast due to, for example, the link being located in a canyon or otherwise being outside the direct radio broadcast region. These features permit the model to reflect the impact that communication equipment placement and coverage may have on the quality and quantity of travel time data available to the TMC. 2.3 Probe Vehicle Report Alternatives The INTEGRATION model also permits the user to designate a portion of the traffic generated at any origin as probe vehicles. These probe vehicles do not possess any behavioral differences from their non-probe vehicle counterparts, however, they are considered to be capable of transmitting unique information back to the TMC. Information can be transmitted to the TMC each time a probe vehicle initiates its trip, reaches its destination, or traverses a link. The information provided by these probe reports includes the vehicle’s origin and destination zone, trip or link travel time, distance traveled, driver type, total fuel consumed, and total emissions of nitrous oxide, hydrocarbon, and carbon monoxide. These data records are provided in a structured output file and can be post-processed for user specific comparisons and aggregation. 2.4 ATIS Point Sources: Changeable Message Signs and ATIS Beacons The INTEGRATION model incorporates the ability to model point sources of ATIS information, such as CMS and ATIS beacons, at network nodes. The designation of a node as an ATIS points source indicates that traffic data are provided to designated drivers when they pass by one of these locations. Currently, the point sources are modeled such that drivers who are traveling through a network will temporarily receive updated travel time information, which they can use immediately to re-route themselves. This travel time information is refreshed each time a driver passes through one of these designated nodes. The spatially and temporally constrained characteristics of a point source may be captured as the user may specify the amount of time after a driver has passed a source, that the driver will receive updated travel time information. These times are location specific, such that different point sources may provide information to drivers for different lengths of time. Furthermore, the user may also reflect compliance rates by specifying, for each point source, the proportion of the traffic stream that will utilize the information that is provided. The modeling of ATIS point sources is being made more flexible to provide for the representation of a greater range of architectures. The user will be able to define the characteristics of the source, in terms of the information being provided and/or received, the vehicle/driver classes that may communicate with the source, and the associated compliance rates. This feature also allows for the modeling of randomly-occurring "missed messages" or inadvertent driver routing error. 2.5 Interface with Communications Subsystem Modeling To aid in the design and evaluation of communication subsystems, INTEGRATION provides a number of important parameters which can be readily imported into a standard communications modeling tool. For example, the user may identify the interval at which ATIS updating takes place. 3.0 CASE STUDY DEVELOPMENT 3.