DEVELOPMENT AND VALIDATION OF A FLEXIBLE, OPEN ARCHITECTURE, TRANSPORTATION SIMULATION

DEVELOPMENT AND VALIDATION OF A FLEXIBLE, OPEN

ARCHITECTURE, TRANSPORTATION SIMULATION

Michael Hunter Randy Machemehl

School of Civil and Environmental Engineering Center for Transportation Research

Georgia Institute of Technology 3208 Red River Atlanta, GA 30332, U.S.A. The University of Texas at Austin

Austin, TX 78705, U.S.A.

ters, etc.), and selection of a programming language. Such ABSTRACT

simulation development contains several significant disad-vantages, particularly extensive training requirements and Simulation has been utilized in the planning and develop-excessive development time and costs. To alleviate these ment of almost all sectors of the transportation field. The

disadvantages the practicing transportation community practicing transportation community primarily relies on

primarily relies on simulation packages. A few (of the simulation packages, as opposed to “ground up” simulation

many) examples of transportation simulation packages development. Unfortunately, the use of these simulation

available include CORSIM, WATSim, INTEGRATION, packages has several disadvantages, most notably the

VISSIM, and TEXAS. When a practitioner uses a simula-“black box” phenomenon and reduced modeling flexibility.

tion package, the simulation development effort has al-The simulation approach described in this paper lays the

ready been completed. With the inclusion of graphical foundation for a transportation simulation approach that

user interfaces, models are approaching “plug and play” minimizes the “black box” problem and increases model-capabilities, in which models may be quickly and eco-ing flexibility, while still providing an easy to use package

nomically constructed. in which highly capable models may be quickly and accu- While overcoming the advantages of simulation de-rately built. This simulation approach utilizes SIMAN and

velopment these packages have disadvantages, most nota-ARENA. This paper includes a brief discussion of the

bly the “black box” phenomenon and reduced modeling simulation approach, a comparison of the proposed simula-flexibility. An end user can enter data and receive results tion and CORSIM simulation results for an intersection

with little understanding of how the simulation operates and an arterial, and a comparison of the proposed simula-and limited knowledge of the inherent assumptions. Also, tion control delay to delays collected for a twelve intersec-a user is bound by the methods and assumptions of the tion grid north of downtown Chicago.

given simulation package. It is virtually impossible for an end user to conceptualize, design, and develop a simulation 1 INTRODUCTION

for a situation beyond the bounds set by the simulation package developer. Simulation is vital in the planning and development of al-most all transportation sectors. Isolated intersections, en-2 PROPOSED SIMULATION MODELING tire networks, airport landside and airside operations,

APPROACH OBJECTIVES freight movement, and passenger terminals: all of these

features of a transportation system may be analyzed

The model described in this paper lays the foundation for a through simulation. List and Troutbeck (1999) describe

transportation simulation approach that minimizes the four basic paradigms for simulation development: program

black box problem and increases modeling flexibility while code, flowcharts, pseudo code, and worksheets; although in

still providing an easy to use package in which highly ca-practice simulation development usually involves a combi-pable models may be quickly and accurately built. For this nation of two or more of these approaches. In these para-simulation modeling approach, SIMAN (Pedgen, Shannon, digms simulations are constructed from the ground up, ad-and Sadowski 1995), a general-purpose simulation lan-dressing issues such as event-based vs. time-based

guage, and ARENA (Kelton, Sadowski, and Sadowski simulation, distribution selection and implementation, un-1998), a hierarchical simulation-modeling tool that auto-derlying vehicle movement (i.e. car-following equations,

mates the creation of SIMAN, were used. With SIMAN Newtonian mechanics, acceleration / deceleration parame-

12Hunter and Machemehl

and ARENA as the foundation, the development of a flexi-ble, open, efficient approach to transportation simulation with the following properties is undertaken: hierarchical, event-based, object-oriented, and stochastic. 2.1 Hierarchical

This simulation approach consists of three tiers of blocks (objects). The tier 1 blocks are most functionally robust and may be readily combined to create an intersection, ar-terial, or network simulation model. Each of these tier 1 blocks is constructed from hierarchy tier 2 and tier 3 blocks. Tier 3 blocks (the lowest tier) are the basic SIMAN building blocks. Tier 2 blocks are intermediary blocks, constructed from tier 3 blocks with the intent of simplifying the construction and complexity of tier 1 blocks. For example, the APPROACH block is a tier 2 block that models the vehicle queue and stop bar departure on a single lane approach. The tier 1 PRETIMED block ties together APPROACH blocks with a pre-timed signal logic, capturing the operation of a pre-timed intersection in a single tier 1 block.

Utilizing tier 1 blocks greatly reduces the complexity of model construction. For example, the single intersection model in the validation discussion was constructed using twenty-one tier one blocks. If this same model was con-structed directly from tier 3 blocks (i.e. constructed with only SIMAN basic building blocks) nearly 900 blocks would be required. By utilizing the hierarchical object-oriented approach the task is greatly streamlined, allowing for efficient model development. 2.2 Event-Based

Currently the proposed simulation is event-based. Once all actions have been completed at a simulation time the simu-lation clock is advanced to the next scheduled event, re-gardless of the amount of time between events. 2.3 Object-Oriented

Roughly stated, object-oriented programming is a program-ming approach where one first considers the software in terms of objects and how those objects interact with each other. By utilizing a simulation approach where the trans-portation system is seen as a collection of interacting ob-jects, creation of an open simulation architecture becomes a simpler and more straightforward task. This approach en-ables contributions by a wide array of developers and users. 2.4 Stochastic

In current tier 1 blocks, a user may introduce randomness. Aspects that may include randomness include the creation (i.e. vehicle enter) interval, aggressiveness factor (which

affects speeds, headways, and intersection start-up lost times), and turning movements. The stochasticity of the creation interval and aggressiveness factor may be set to follow many different distributions. 2.5 Summary

Currently the proposed simulation only models vehicle traffic on signalized networks. This is accomplished through 10 tier 1 blocks: ENTER, EXIT, QUEUE-CHANGE, TURNBAY, LANEADD, LANEDROP, PRE-TIMED, PRETIMED8P, ACTUATED8P, and SIGNAL. Through these blocks, vehicles enter and exit the network, change queues and select turn movements, lanes are added and dropped in the network, pre-timed, actuated and adap-tive signal control is modeled, vehicles travel along links, and both vehicle and network statistics are collected. 3 MODEL VALIDATION

Validation of a simulation can be a difficult process, difficult even to precisely define. In a general sense the goal of vali-dation is to gain confidence in the ability of the model to reasonably reflect real world conditions. Validation includes testing for reasonableness, adequacy of the model structure, and model behavior against the referent system (Pedgen, Shannon, and Sadowski 1995). The focus of this discussion is on the comparison of proposed model behavior to that of several transportation networks. For additional information on the model reasonableness and structure the reader is re-ferred to Hunter (2003). It must be noted that neither this discussion nor the referenced document should be consid-ered the final statement on the validity of the proposed simu-lation approach. Validation is a continual process, only over time and through use may wide-ranging confidence be gained. The intent of this study is to provide initial confi-dence in the simulation approach.

Ideally, a transportation simulation validation study includes comparisons of simulated results against real world data. Unfortunately, an acute problem in transporta-tion is the lack of sufficient data sets to vigorously validate a simulation. To overcome the limited data available a combination approach to validation was undertaken, com-paring the developed simulation against CORSIM, a highly regarded transportation simulation package, and against a real-world data set.

This approach has several notable drawbacks. Firstly, CORSIM errors are introduced into the validation process. In a comparison to CORSIM it is only possible to state how well the proposed model reflects the performance of CORSIM, not the real world. Secondly, the determination of the quality of the proposed simulation results is subjec-tive. The following discussions rely on engineering judg-ment to gauge the quality of the proposed simulation ver-sus CORSIM and the real world data. Future research will

13Hunter and Machemehl

delve into developing formal methods by which transporta-tion simulation results may be gauged. 3.1 CORSIM Validation Scenarios Two different geometric scenarios were studied for initial model validation: an isolated intersection and a three inter-section arterial. These scenarios were chosen as they cap-ture the fundamental aspects of most traffic networks: op-erations at an intersection and the interaction between intersections. Characteristics similar to intersections in both validation scenarios include three phase signal timing (leading East-West lefts), protected only left turns, no right turns on red, 2.4 second start-up lost time, 2.0 second de-parture headways, and turn movements from turn bays only (i.e. no shared lanes). In the isolated intersection sce-narios the East-West approaches include three through lanes while in the arterial scenarios there are two through lanes. The distance between arterial intersections (from stop bar to stop bar) is set at 1320 ft with a 30 mph average free flow speed. In all scenarios the North-South ap-proaches are comprised of a single right turn bay and a single through lane. Also, vehicle queue changing prob-abilities in the simulation were set to achieve a similar queue changing frequency of that observed in CORSIM. Due to space constraints, only a synopsis of the validation study against CORSIM is presented. For a complete dis-cussion the reader is encouraged to refer to Hunter (2003). 3.1.1 Validation – Isolated Intersection For the isolated intersection, comparisons were made under low to over-saturated traffic conditions through fifteen dif-ferent volume / cycle length scenarios. Five replicate runs were performed for each scenario, for a total of 75 runs of each simulation model. Figure 1 shows the average east-bound through volumes, delays, speeds and queues deter-mined in both models. Similar results were developed for the westbound, northbound, and southbound approaches. Overall CORSIM and the proposed simulation were found to exhibit similar values and trends for several measures of effectiveness (volumes processed, average ve-hicle delay, average queues, and average speed) in non-congested situations. In over-congested situations both models identified intersection performance problems al-though absolute differences between the measures of effec-tiveness values produced by the two models could be sig-nificant. The proposed simulation approach typically had greater delays, most likely resulting from the vertical queu-ing model. A vertical queue fails to limit the queue length by the approach link length, inflating the link delays. In a network the upstream intersection delay would also be ef-fectively lowed, since vehicles would be allowed to enter a downstream link even when the downstream queue length exceeds the link length. Also, upstream crossing move-ments would not be blocked by spillback. Speed (mph)Volume (vph)3,0002,5002,0001,500EB Thru Volume Processed1,000500-515103015452060COR Cycle 60COR Cycle 90COR Cycle 120TB Cycle 60TB Cycle 90TB Cycle 1202575Demand Volume Scenario (vph)18016014012010080604020-EB Thru DelayCOR Cycle 60COR Cycle 90COR Cycle 120TB Cycle 60TB Cycle 90TB Cycle 120Delay (sec/veh)5151030154520602575Demand Volume Scenario (vph)25201510COR Cycle 60COR Cycle 90COR Cycle 120TB Cycle 60TB Cycle 90TB Cycle 120EB Thru Speed5-5151030154520602575 Figure 1: Eastbound Thru Delay, Volume, and Speeds for CORSIM (COR) and the Proposed Simulation (TB) Under Different Isolated Intersection Demand Volume / Cycle Length Scenarios Another area of disagreement is left turn movements, particularly when demand approaches or exceeds capacity. CORSIM consistently processes more vehicles and has a lower delay than the proposed simulation. The CORSIM congested left turn behavior is the more aggressive, allow-ing for a higher capacity. Left turn behavior is an area in which additional study is required. Demand Volume Scenario (vph)14Hunter and Machemehl

3.1.2 Validation – Arterial 70Delay (sec/veh)EB Thru DelaysTB EB1 ThruCOR EB1 ThruThe arterial validation study is primarily concerned with the operation of intersection approaches where there is a modeled upstream intersection, as other approaches will operate in a manner similar to that of the isolated intersec-tion. Thus results discussed are for the eastbound and westbound directions. Northbound and southbound opera-tions behave as seen in the isolated intersection discussion. Based on the isolated intersection comparisons a sin-gle cycle length and volume demand scenario was selected for the arterial study. A thru volume demand of approxi-mately 85% of capacity (85% green time utilization) was selected and a common cycle of 90 seconds was chosen. The effect of the offset is the variable of most interest in the arterial study. Thus six different offset scenarios were modeled. Listed as (Intersection 1, Intersection 2, Intersec-tion 3) offsets in seconds, these six cases are (0,0,0), (0,15,30), (0,30,60), (0,45,0), (0,60,30), and (0,75,60). Figure 2 presents the proposed simulation and CORSIM average delays, queues, and speeds for the east-bound and westbound approaches of the test arterial. For the un-congested volume scenario tested the proposed simulation and CORSIM demonstrate excellent agreement in the captured absolute MOE values and trends, as signal offsets changed. In both the eastbound and westbound di-rections both simulations process similar through, left, and right turn volumes. The approach delays vary according to the offset scenarios with both simulation models exhibiting similar trends in delays over the offset scenarios. The cal-culated delays from both models were found to be similar, typically within five or fewer seconds. Also, for the given offset scenarios there are no significant differences between queues modeled by the two simulations. The queue differences are always within two vehicles and typically within one vehicle or less. In addi-tion, both absolute speeds and speed trends simulated by both models are similar. 3.2 Comparison to Chicago Data The utilized data set was part of a RT-TRACS (Real-Time Traffic Adaptive Control System) field test. This test was a field evaluation of RTACL (Real-Time Adaptive Control Logic) on a twelve-intersection network just north of downtown Chicago. The adaptive control field test in-volved numerous participants: FHWA, Chicago Depart-ment of Transportation, Chicago Bureau of Electricity, PB Farrradyne, and ITT Systems (ITT 2001). ITT Systems, who was responsible for performing the field evaluations, was the primary contact for obtaining the field data utilized in this validation effort. As part of the RTACL evaluation, before and after conditions were measured in the field. The before condi-tion field measurements provided the data required for a 605040302010-0,0,0TB EB2 ThruCOR EB2 ThruTB EB3 ThruCOR EB3 Thru0,15,300,30,600,45,00,60,300,75,60Offset Scenario (Int 1 sec, Int 2 sec, Int 3 sec)1210Queue (veh)EB Average Thru QueuesTB EB1 ThruCOR EB1 ThruTB EB2 ThruCOR EB2 ThruTB EB3 ThruCOR EB3 Thru82-0,0,00,15,300,30,600,45,00,60,300,75,60Offset Scenario (Int 1 sec, Int 2 sec, Int 3 sec)30Speed (mph)EB Average Thru Speed252015105-0,0,0TB EB1 ThruCOR EB1 Thru0,15,300,30,60TB EB2 ThruCOR EB2 Thru0,45,0TB EB3 ThruCOR EB3 Thru0,60,300,75,60 Figure 2: Eastbound Thru Delay, Queues, and Speeds for CORSIM (COR) and the Proposed Simulation (TB) Under Different Offset Scenarios Offset Scenario (Int 1 sec, Int 2 sec, Int 3 sec)comparison to the simulation. The performance measure util-ized for comparison in this simulation study is control delay. 3.2.1 Site Description and Data Collection Figure 3 provides an overview of the twelve intersections (numbered 1 through 12) for which data was collected. This twelve-intersection grid is bounded by West Ontario on the North, West Grand on the South, North LaSalle on the East, and North Orleans on the West. Signal control data were also known for the neighboring intersections on 15Hunter and Machemehl

Systems as part of the RT-TRACS field evaluation with the published results being utilized for this validation ef-fort. For raw data and summarized results the reader is re-ferred to the RT-TRACS field study report (ITT 2001). 3.2.2 Comparison of Simulated and

Measured Control Delays

A simulation model was constructed for the twenty-three in-tersection network for which data were collected. Figures 4 and 5 contain the simulated and field measured control delays for the AM and PM peak periods, respectively. As all probe vehicle routes are straight through the network the probe ve-hicle delays are for the through movements only. Thus, for a consistent comparison the simulated delays are also for through movements only. Also, in this presentation, evalua-tion of agreement between model and probe vehicle data is that of practical rather than statistical difference, based on traffic engineering expertise and judgment. Hunter (2003) further explores the use of statistical significance in the evaluation of the proposed simulation model. 3.2.2.1 AM Peak Period Control Delay

Overall, the AM peak period simulated versus probe vehi-cle control delays demonstrate reasonable agreement. For example, the critical I-90 access route, West Ohio East-bound, the simulated versus probe vehicle control delays are (all in sec/veh) 7.1 vs 3.2, 11.9 vs 13.0, and 16.0 vs 10.7 for the intersections with North Franklin, North Wells, and North LaSalle, respectively. Both the probe vehicle and simulated delays indicate similar traffic condi-tions. A review of Figure 4 leads to the same conclusion of similar probe vehicle and simulated traffic conditions for West Ontario westbound, North LaSalle northbound and southbound, and North Wells southbound. Further review of Figure 4 does however show that not all probe vehicle and simulated control delays indicate similar operating conditions. A prime example of dis-agreement is the northbound approach at the North Orleans and West Ontario intersection. The probe vehicle delay is 1.2 sec/veh while the simulated delay is 21.9 sec/veh. A 1.2 sec/veh control delay (probe vehicle measured delay) implies that nearly all of the probe vehicles passed through the intersection unimpeded by the traffic signal. The 21.9 sec/veh control delay (simulated delay) implies that at least a fraction of the vehicles are hindered by the signal control. The probe vehicle and simulation would seem to indicate different operating conditions.

A review of the data collection methodology reveals how the simulation and probe vehicles may be reflecting different aspects of the real-world operation. From Figure 3 it is seen that the probe vehicle route that includes this approach from which the control delay is measured begins south of West Hubbard on North Orleans, traveling northbound on North Orleans thru West Hubbard, West

Figure 3: North – South Probe Vehicle Route

West Erie (North), West Illinois (South), and North Clark (East). These intersections were included in the simulation model (for a total of 23 simulated intersections), allowing for nearly all approaches on the twelve primary intersec-tions to have simulated arrival patterns more consistent with those found in the field. Only the eastbound intersec-tion approach arrivals on North Orleans do not account for the impact of upstream intersections. The network consists of both one-way and two-way streets, with average block length of 300’ to 400’ and speed limits of 30 to 35 mph. Detailed descriptions of the network geometry may be found in the ITT report (2001).

A drawback to this data set is limited traffic volume data. Volumes are based on 15-minute counts performed at each intersection during 1999 and 2000. The signal tim-ings are all pre-timed with a 75 second background cycle. Timing plans were two or three phase. As part of the adap-tive control evaluation, the intersection offsets for the be-fore conditions were optimized (ITT 2001).

Travel time runs utilizing probe vehicles instrumented with Starlink GPS antennas and receivers were utilized to gather performance measures. Five probe vehicles were utilized during the peak hours over a three-day period in late October 2000. The probe vehicles followed specific routes. Figure 3 shows the north-south routes, similar east-west routes through the network were also included in the probe vehicle runs. Routes involving I-90 access were de-termined to be critical and were therefore assigned two probe vehicles, all other routes were assigned a single probe vehicle (ITT 2001). Over the peak periods, the probe vehicles were able to obtain 10 to 95 observations for each route, with most approaches receiving 30 to 60 observations. From this data, travel time and control delay information was determined for most of the twelve inter-sections. All reduction of raw data was performed by ITT

16Hunter and Machemehl

3.2.2.2 PM Peak Period Control Delay

The PM peak period simulated versus probe vehicle control delays may be found in Figure 5. These delays do not dem-onstrate the same level of agreement as the AM peak period. While there are still examples of agreement, such as the West Ohio westbound traffic flow there are significant areas of disagreement. Areas of particular concern are the West Ontario and West Grand eastbound and the intersections of West Ontario and West Grand with North LaSalle.

Significant upstream turning movements do not readily explain these control delay differences; two possible expla-nations follow. The first is the possibility of inaccurate vol-ume and signal timing data. The volumes were collected up to a year prior to the conducting of the probe vehicle runs. Also, during the probe vehicle study a bridge providing ac-cess out of downtown Chicago was closed, leading to a sig-nificant increase in the northbound traffic on LaSalle during the PM peak (ITT 2001). This detour is not reflected in the volume counts. The possibility exists that the data given for the before conditions does not match the field conditions during the probe vehicle measurements. A second possibility is that the simulation has accurate initial data and does not adequately reflect real-world op-eration. It is possible to gain some additional insight into this possibility. As part of the adaptive control study ITT Systems developed CORSIM models of the before condi-tions. The CORSIM results have a closer correlation to the proposed simulation results than the probe vehicle meas-urements. While both the proposed simulation and CORSIM may be incorrect it appears reasonable that the discrepancies result from inaccurate input data. At this time the PM comparison must be considered inconclusive in gauging the validity of the proposed solution.

Figure 4: Chicago Simulation and Probe Vehicle Control Delay (sec/veh) - AM Peak (not-to-scale)

Grand, West Ohio, and finally West Ontario. Platoons of vehicles travel along this route, falling within a green band, are not hindered by an intersection’s signal control. The majority of probe vehicles will fall within these platoons, incurring little delay, as measured in the field.

In contrast the simulated control delay is not calcu-lated from a sampling of probe vehicles but from all vehi-cles that travel northbound through the intersection of North Orleans and West Ontario. In this instance, this is a significantly different vehicle population than that captured by the probe vehicles. The intersection of North Orleans and West Ohio provides access to the network from I-90. The North Orleans and West Ohio intersection west ap-proach’s left turn movement (i.e traffic from I-90 turning northbound onto North Orleans) is significant, at approxi-mately 950 veh/hr, nearly double the northbound traffic from the south approach. These vehicles are not within a green band and are hindered by the North Orleans and West Ontario signal control.

Thus, the simulation is capturing a major movement (from I-90 to northbound on North Orleans) not reflected in the probe vehicle measurements. The probe vehicle measurements dramatically fail to capture the overall per-formance of the approach, underestimating the through movement control delay. Wherever an upstream turning movement feeds a substantial portion of an approach’s through movement, a system of probe vehicle routes such as those utilized is likely to fail to accurately reflect the approach’s operation. The intersection of North Wells and West Grand southbound approach is another example of this effect. The right turn movement onto North Wells from West Ohio is a significant movement that is not cap-tured by the probe vehicles. Again this leads to a signifi-cant skewing of the probe vehicle control delay.

Figure 5: Chicago Simulation and Probe Vehicle Control Delay (sec/veh) - PM Peak (not-to-scale)

17Hunter and Machemehl

4 CONCLUSION

This approach to simulation has potential advantages over current widely utilized transportation simulation packages. While currently limited to intersection/arterial/network traf-fic analysis it is readily expandable to other aspects of the transportation system. Much of this expansion potential is a result of the hierarchical, object-oriented structure. When a user wishes to model a transportation system feature other than those directly accounted for, such as a toll plaza, such development may be done in-house or by third-party devel-opers. All other current blocks may be used with the new toll plaza block(s). This “open architecture” approach frees a user from a dependence on the original developers.

The hierarchical nature of the model also allows for a minimal learning curve to initial model construction. One may quickly become efficient with tier 1 blocks, learning as little or as much as desired about the underlying logic, and still be able to construct realistic, highly capable mod-els. As users desire to expand beyond the default tier 1 blocks they can learn and experiment with tier 2 and 3 blocks, performing more unique analyses.

Finally, the object-oriented approach to modeling represents a more “common sense” approach to simulation. From an individual’s earliest experiences one typically views the world in terms of objects and how they interact with each other; from a toaster’s interaction with bread, to a key’s interaction with a lock, to a car’s interaction with a traffic signal. Utilizing existing human mechanisms for viewing surroundings increases the likelihood of creating a more intuitive, understandable, efficient, and accurate simulation software package (Brown 1997).

Importantly, initial confidence may be placed in this simulation approach. The Chicago AM measured per-formance matches well with those simulated while the PM results are inconclusive. Combined with the CORSIM comparison results, a reasonable level of confidence in this modeling approach is warranted. 4.1 Limitations

While these initial efforts into this open architecture, object oriented approach to simulation are promising, there are limitations. These may be categorized into real-world traf-fic operations not captured and general limitations to the simulation approach. Traffic operations not yet captured include permissive phasing, vehicle lane changing to over-take slower vehicles, horizontal queuing, and freeway simulation. Many of these limitations may be overcome through the continued development of simulation objects, although some will be difficult to capture due to the more general limitations.

Possibly the most daunting general limitation is the underlying event-based nature of this approach. While event-based simulation is well suited to modeling signal

control it is not nearly as apt at capturing some of the inter-action of traffic flow. This weakness will become particu-larly constraining when attempting to model freeways. The event-based nature is the underlying reason for the current use of vertical queuing rather than horizontal queu-ing. Future effort on this simulation approach will include the incorporation of time-based simulation. Initial efforts will center on incorporating time-based modeling into the current ARENA platform although if this is not possible it will be necessary to move the hierarchical, object-oriented constructs to a alternative platform, if the simulation ap-proach is to be further advanced.

Also, while this approach attempts to open the “black box” by allowing the user to add to and alter the underly-ing objects, it must not be assumed that this will be a sim-ple task. To fully understand the model constructs, the user will have to devote time and effort into gaining an un-derstanding of general simulation development and the un-derlying SIMAN language. Without this effort a user may still construct complex models using the tier 1 blocks, but the model will be no less a “black box” than the other available simulation packages.

As a last point this validation effort also highlighted the lack of availability of quality, real world data. There is a clear need for field studies with the express goal of de-veloping data collection guidelines and obtaining data sets for the validation of transportation analytical and simula-tion models. This would not only be useful for validation of the proposed simulation model but also would provide a means for direct validation of the many other simulations that are used in practice today. ACKNOWLEDGMENTS

The authors are grateful for the funding provided through the Southwest Region University Transportation Center in support of this work. Also, for the data and assistance pro-vided by ITT industries, particularly Charlie Stallard. REFERENCES

Brown, D. 1997. An Introduction to Object-Oriented

Analysis, Objects in Plain English. Northern Alberta Institute of Technology, John Wiley and Sons, Inc. Kelton, W. D., R.P. Sadowski,, D. A. Sadowski. 1998.

Simulation With ARENA, McGraw-Hill.

Hunter, M. P. 2003. Development and Validation of a

Flexible, Open Architecture, Transportation Simula-tion with and Adaptive Control Implementation. Doc-toral dissertation, Department of Civil Engineering, The University of Texas at Austin, Austin, Texas.

ITT Industries Inc, 2001. Evaluation of the Near North

Chicago RT-TRACS Field Test. ITT Industries Inc., Systems Division, Colorado Springs. Prepared for USDOT FHWA Travel Management R&D.

18Hunter and Machemehl

List, G. and R. Troutbeck. 1999. Advancing the Frontier of

Simulation as a Capacity and Quality of Service Tool, Department of Civil and Environmental Engineering, Rensselaer Polytechnic Institute, Troy, N.Y. Unpub-lished Report.

Pegden, C. D, E. R. Shannon, R. P. Sadowski. 1995. Intro-duction to Simulation using SIMAN, Second Edition. McGraw-Hill. AUTHOR BIOGRAPHIES

MICHAEL HUNTER is an Assistant Professor in Civil and Environmental Engineering at the Georgia Institute of Technology. His research interests include object-oriented modeling, transportation simulation, real-time traffic signal control, and traffic operations. He has a B.S. degree in Civil Engineering from Rensselaer Polytechnic Institute and M.S. and Ph.D. degrees in Civil Engineering from The University of Texas at Austin. He may be contacted at .

RANDY MACHEMEHL is a Professor at The University of Texas at Austin, is the Director for the Center for Trans-portation Research, and is Associate Director of The Uni-versity of Texas Research Component of the Southwest University Transportation Center Program. He is a regis-tered professional engineer and has had an active research career, having been principal or co-principal investigator on more than 100 research studies for the U. S. Department of Transportation, Federal Highway Administration, Urban Mass Transportation Administration, The Texas Depart-ment of Transportation, and The Texas Governor's Office. Results of Dr. Machemehl's research have been reported in over 150 journals and technical publications. He may be contacted by e-mail at .

19