Reso 1997-136 to 140 - Laserfiche WebLink

Home

Mr. Steve Fitzsimons Page 3 November 5, 1996 Signal systems generate a continuous stream of data including detector data, signal timing data (actual splits, etc.), and data regarding "events" or faults in the system. In most systems these data are generated continuously, stored for a short time (a few hours to a few days), and then discarded or written over by new data. The Generation 1.5 software (called "Traffic Information System" or TIS in this memo) extracts this raw data from signal detectors and controllers either in total or at various times defined in a sampling plan and converts it to input data understood by standard signal timing optimization software programs such as TRANSYT 7F and PASSER 2. It is this software, TIS, that TJKM proposes to develop for the East 14th Street/Mission Boulevard TSM project. There are two main groups of programs in TIS: 1) data acquisition and compiling, and 2) modelling and timing plan generation. Following is a generalized discussion for each group of programs in TIS. 1. Data Acquisition and Compiling Module: Data from detectors (stopline, advance and system) is stored in the controller for varying amounts of time. These data include volume, speed and occupancy. Of interest is the volume and occupancy data. In addition, there are other data generated at the intersection level such as actual splits and offsets (ie., whether the synch phase received an early green, etc.), and "events" or failures in specific system components. In interpreting the data prior to input to traffic signal timing optimization models, it is appropriate to ensure that the data are complete and accurate. Failed detectors, stuck ped push buttons, and communications failures between field masters and controllers, for example, all have a direct effect on the operation of the system and their effect should be known for specific times and days in order to properly interpret the data during the analysis of signals timing. In addition, controllers and field masters also store signal settings data such as signal phase timing, coordination plans, etc. To the extent that these data have a direct counterpart in signal timing optimization models, they must be able to be collected with the data acquisition module. Some controllers and some centralized signal system software, however, do not access nor store all of the needed data. During detailed design of the data acquisition and compiling module, these details will become known. Once the data are extracted from the signal system, they need to be compiled into a more recognizable format For example, individual loop data may be interesting some of the time (for example, when the engineer wishes to determine the distribution of approach traffic by lane rather than phase or movement), so the data are compiled into phases or movements such that data from three or four detectors might all be summed into a volume representing, say southbound East 14th Street at Davis, etc. The signal settings data are similar between systems, but the specific reporting output varies with the system. Such data also need to be compiled into a standardized report, so that regardless of system, the engineer can look for "Phase 2 minimum green" in the same place every time. For failures in the system, there needs to be a common format report flagging the time and duration of a failure such as a stuck detector or push button, or a signal going into flash, etc. regardless of the system. Such information cautions the engineer that the data for that specific time period is suspect or incorrect and shouldn't be used for standard analysis. This module provides functions for automated access to central signal monitors or field masters for updating a permanent traffic database, and it also provides a function for a common formatting of data common to all systems and analysis software (volumes by movement and by time period, signal timing in effect - both planned and actual for movement and time period, and system hardware failures for