Defining Design Space for Parameters of Traffic Signal Timing

85

Transportation Research Record: Journal of the Transportation Research Board, No. 2311, Transportation Research Board of the National Academies, Washington, D.C., 2012, pp. 85–98.DOI: 10.3141/2311-08

T. M. Brennan, Jr., School of Engineering, Purdue University, 205 Pawnee Drive, West Lafayette, IN 47906. B. D. Griggs, Econolite Control Products, Inc., Suite 100, 2950 Professional Place, Colorado Springs, CO 80904. G. M. Grimmer, A. M. Hainen, C. M. Day, and D. M. Bullock, School of Civil Engineering, Purdue University, 550 Stadium Mall Drive, West Lafayette, IN 47906. J. R. Sturdevant, Traffic Man-agement Center, Indiana Department of Transportation, 8620 East 21st Street, Indianapolis, IN 46219. Corresponding author: D. M. Bullock, [email protected].

now have nearly 74,000 configurable parameters. These parameters range from standard minimum and maximum times to detailed parameters necessary for configuring communication channels and input–output devices. Most agencies use only a subset of these parameters, but few if any agencies have a comprehensive check-list defining responsibility or design procedures for calculating and configuring these parameters. This lack of a comprehensive checklist—or a systematic definition of what needs to be configured for a traffic signal controller to operate properly—often leads to operational problems. All too often, minor parameter errors in the controller database, such as time-of-day schedules for coordinated operation, lead to substantial problems. Figure 1 shows a graphical record from before and after one of these errors was corrected in the time-of-day coordination plan (1). Figure 1a corresponds to a case in which adjacent intersections were running cycle lengths of 114 and 116 s from 15:00 to 19:00. These cycle lengths led to a shift in platoon arrival of 2 s every cycle (Figure 1a, Points i and ii). Subse-quently, both intersections were configured to operate with a 116-s cycle and functioned properly, with the platoon consistently arriv-ing in the green band, Figure 1b, Point iii (1). This example is just a representative type of configuration error that frequently occurs; literally thousands of opportunities exist to make similar mistakes or to forget to configure a parameter in any modern coordinated signal system.

Problem Statement

Because equipment varies and each agency has its own design phi-losophy, it is not feasible to define a one-size-fits-all checklist. As a result, configuration of a traffic signal controller is too often viewed as a task of printing the output from an optimization program and asking a technician to enter the data. On the surface, the number of inputs may appear to be minor. However, the traffic signal controller contains upwards of 74,000 design space parameters, which provide various locations where a misplaced number can cause unexpected operational results.

An agile, scalable approach is needed for agencies to define the design space for parameters of traffic signal controllers that must be configured to make a traffic signal operate. This design space can then serve as a checklist for staff or consultants to define expec-tations precisely when individuals develop new, or update existing, configurations for traffic signal controllers. This space can be aug-mented by referencing agency design policies, guidelines, and other references appropriate for defining the parameter configuration.

Defining Design Space for Parameters of Traffic Signal Timingempirical approach

Thomas M. Brennan, Jr., Brian D. Griggs, Gannon M. Grimmer, Alexander M. Hainen, Christopher M. Day, James R. Sturdevant, and Darcy M. Bullock

This paper proposes an agile, scalable approach for an agency to use for defining a design space for parameters of traffic signal controllers that reflect the agency’s procedures. This design space is more commonly known as a checklist of parameters that must be configured in a control-ler database. The procedure for establishing this design space used simple network-monitoring protocol messages from programmed traffic signal controllers to traverse the controller database tree systematically with the get-next command that was available on controllers that supported the National Transportation Communications for Intelligent Transportation System Protocol (NTCIP). In the case study, a corridor of 22 intersections (five isolated and 17 coordinated) was analyzed to establish the design space empirically. The controllers that were studied had approximately 74,000 configurable parameters, although many of these are seldom con-figured by most agencies. Longitudinally along a five-intersection corri-dor, approximately 430 parameters (0.6%) on isolated intersections were changed. Longitudinally along a 17-intersection coordinated system, approximately 1,700 parameters (2.2%) were changed. Approximately 93% of the parameters that were changed on the isolated intersections were defined by NTCIP 1202. Only 28% of the parameters that were changed on the coordinated intersections were defined by NTCIP 1202; the remaining 72% were vendor specific. The paper concludes with a series of tables that summarize the broad spectrum of parameters to be config-ured for a modern traffic signal controller to operate properly. Agencies can use these tables as a checklist for defining expectations precisely when individuals develop new traffic signal controller configurations or update existing ones. Similarly, consultants can use these tables and procedures to define a clear scope of work on signal-timing projects.

Forty years ago, agencies could develop one-page charts that defined all the parameters associated with a traffic controller. This compact design space made it quite easy to define procedures and responsi-bility for setting the timing for a traffic signal controller. However, as controller capabilities have matured, modern traffic controllers

FIGURE 1 Example of before-and-after cycle length mismatch on SR-37 in Noblesville, Indiana, displayed on Purdue Coordination Diagram: (a) cycle length mismatch during time-of-day (TOD) Plan 5, February 15, 2010, and (b) corrected cycle length during time-of-day Plan 5, February 22, 2010 (1)(EOG = end of green; BOG = beginning of green).

0

10

20

30

40

50

60

70

80

90

10 0

11 0

12 0

13 0

14 0

15 0

16 0

17 0

18 0

19 0

20 0

21 0

22 0

23 0

0: 00 3: 00 6: 00 9: 00 12 :0 0 15 :0 0 18 :0 0 21 :0 0 0: 00

FREE FREE COORDINATED

i

TOD 1 TOD 2 TOD 3 TOD 4 TOD 5 TOD 6

CY

CL

E L

EN

GT

H (

s)

ii

EOG

BOG

0

10

20

30

40

50

60

70

80

90

10 0

11 0

12 0

13 0

14 0

15 0

16 0

17 0

18 0

19 0

20 0

21 0

22 0

23 0

0: 00 3: 00 6: 00 9: 00 12

(a)

(b) :0 0 1 5: 00 18 :0 0 2 1: 00 0: 00

FREE FREE COORDINATED

TOD 1 TOD 2 TOD 3 TOD 4 TOD 5 TOD 6

CY

CL

E L

EN

GT

H (

s)

EOG

BOG iii

Brennan, Griggs, Grimmer, Hainen, Day, Sturdevant, and Bullock 87

background

The controller design space is quite diverse and includes but is not limited to the traditional cycle, offset and split times, yellow-clearance time, red-clearance times, malfunction management unit configuration, detector mappings, flash configuration, recovery pre-emption, time-of-day plan, synchronous data link control parameters, phase maximum, and detector failure states. The methods used to calcu-late or define these parameters vary by agency, with no comprehensive manual or process to guide personnel on their selections. Furthermore, the person or group within or outside an organization responsible for configuring these parameters is often not clearly defined. Develop-ment of a comprehensive list of parameters and responsibilities would be an invaluable step in establishing vendor and contractor scopes of work when modern traffic signal systems are deployed.

Some efforts have been made to standardize the evaluation meth-ods for assessing signal configurations on the basis of traffic signal performance measurements for a coordinated system by using visu-alization techniques (1, 2), high-resolution traffic signal controller data (1, 3, 4–6), and a step-by-step analysis of the data input process (7). However, instead of waiting to observe the impact of configura-tion errors during field operations (Figure 1), a desirable alternative would be the development of quality assurance/quality control pro-cedures on a defined checklist before deployment to minimize the number of operational errors that require field adjustment. By pro-viding a means to evaluate controller settings before deployment, specific traffic controller values can be adjusted to meet agency stan-dards. Although there is no guarantee that these settings will provide the most optimal controller configuration, they do guarantee that the controller’s values are in accordance with the intended design.

Study Site

A study site was selected along US-30 in Merrillville, Indiana (Figure 2). The 7.0-mi corridor is composed of five isolated intersec-tions (1 to 5 in Figure 2) and 17 coordinated intersections (6 to 22)

and is bisected by Interstate 65. Each intersection had recently been updated with a new ASC/3 traffic signal controller and new com-munication infrastructure. Each of the 22 controller databases was collected May 11, 2011.

methodology

The data collection techniques to establish the design space used simple network-monitoring protocol (SNMP) messages from pro-grammed traffic signal controllers to traverse the controller database tree systematically through the get-next command available on con-trollers that support the National Transportation Communications for Intelligent Transportation System Protocol (NTCIP). An example of the get-next code used to obtain these data is as follows:

ConnectToController (controller IP address);GetNextRequest = 1.1;while (objectsRemain) { SNMPEncodeRequest(); SendToController(GetNextRequest); ReceiveResponse(); SNMPDecodeResponse(); SaveResponse(); CheckForEndOfObjects(); } CloseConnection();

Each controller’s distinct database tree is defined by NTCIP 1202 (8) or is a vendor-defined unique SNMP object identifier (OID). Each OID is a subset of the management information base (MIB), which groups OIDs into logical tables in accordance with NTCIP, and is unique within a controller. One can query the MIB (otherwise known as “walk the MIB tree”) through a network; doing so provides each OID and OID value in the controller database. In this study, an initial query of the MIB database returned approximately 135,000 parameters. Certain OIDs within a MIB can also have their values set through SNMP and are thus readable and writable (Table 1), while

US30

65

1

65

2 3

4 5

7

8

9

10

11 13

14

15 19

20

21

22

Map Area

Indianapolis, IN

6 12 18 16

17 4,000 FT 1,000 M

Isolated (Free) Operation

Coordinated Operation

FIGURE 2 Intersections 1 through 22 along US-30 in Merrillville, Indiana.

88 Transportation Research Record 2311

others cannot be altered and so are read-only. For the study corridor, OIDs whose value was read-only were removed from the potential design space; this deletion resulted in 74,762 configurable OIDs (Table 1). The resource requirements to implement the described methods are minimal and do not require any additional resources beyond those already required to manage a modern traffic signal con-troller. It is hoped that, in the long run, this technique will be applied to advanced traffic management systems to facilitate integration of multiple-vendor traffic signal controllers and other equipment.

A longitudinal comparison of the 22 intersections (Figure 3, hori-zontal comparison) as well as a comparison between a default database and the entire 22-intersection corridor were performed (Figure 3, verti-cal comparison). The middle and bottom sections of Table 1 show a summary of the counts of the observed differences for each of the hor-izontal and vertical queries, respectively. In this case, the longitudinal analysis indicates some inconsistency in relation to how the RedClear

time is configured for Phases 9 through 16. Because these phases are not used at any intersection along this corridor, this inconsistency did not create a problem. However, it illustrates the important point that corridors are frequently programmed by copying databases from other systems. In this case, it appears that the databases used to con-figure the isolated intersections had a different origin than the ones used as a starting point to configure the coordinated intersections.

deSign SPace

general description

As discussed earlier, approximately 74,000 parameters make up the configurable design space of a modern traffic signal controller (Table 1). The design space is further subdivided into about 13,000

TABLE 1 Analysis of Configured Parameters on US-30 in Merrillville, Indiana

Parameter Type (OID)Distinct Parameter [no. (%)]

Parameter (MIB) Group

NTCIP 1202 or Vendor Specific

Read–write controller parameters (design space) Readable–writable parameters 13,215 (17.7) 203 NTCIP 1202 Readable–writable parameters 61,547 (82.3) 543 Vendor Readable–writable parameters 74,762 (100.0) 746 Total

Longitudinal analysis of parameters changed Typical Indiana DOT altered parameters (22 intersections) 844 (1.1) 41 NTCIP 1202 Typical Indiana DOT altered parameters (22 intersections) 2,090 (2.8) 111 Vendor Typical Indiana DOT altered parameters (22 intersections) 2,934 (3.9) 152 Total

Indiana DOT parameters (Isolated Intersections 1–5) 402 (0.5) 3 NTCIP 1202 Indiana DOT parameters (Isolated Intersections 1–5) 29 (0.0) 6 Vendor Indiana DOT parameters (Isolated Intersections 1–5) 431 (0.6) 9 Total Indiana DOT parameters (Coordinated Intersections 6–22) 462 (0.6) 25 NTCIP 1202 Indiana DOT parameters (Coordinated Intersections 6–22) 1,191 (1.6) 63 Vendor Indiana DOT parameters (Coordinated Intersections 6–22) 1,653 (2.2) 88 Total

Summary of parameters changed in comparison with a typical coordinated system database Typical Indiana DOT altered parameters (Isolated Intersection 1) 990 (1.3) 45 NTCIP 1202 Typical Indiana DOT altered parameters (Isolated Intersection 1) 1,716 (2.3) 144 Vendor Typical Indiana DOT altered parameters (Isolated Intersection 1) 2,706 (3.6) 159 Total Typical Indiana DOT altered parameters (Coordinated Intersection 6) 597 (0.8) 36 NTCIP 1202 Typical Indiana DOT altered parameters (Coordinated Intersection 6) 1,289 (1.7) 79 Vendor Typical Indiana DOT altered parameters (Coordinated Intersection 6) 1,886 (2.5) 115 Total

Note: Data analysis performed on May 11, 2011; no. = number; DOT = department of transportation.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Default Database Queryof Each Intersection

Longitudinal Query of IntersectionController Databases

DefaultDatabase

FIGURE 3 Default database query and longitudinal query of intersection controller databases.


parameters defined in NTCIP 1202 (Table 1) and 61,000 parameters that are vender specific (Table 1).

In comparison with the agency’s default coordinated-system database, on average, the isolated intersections required approxi-mately 2,700 parameters (3.6%) to be changed from the default database (Table 1). In contrast, the coordinated controllers required approximately 1,800 parameters (2.5%) to be changed from the default database (Table 1). In both cases, approximately one-third of the parameters changed are defined in the NTCIP 1202 standard, and the remaining two-thirds of configured parameters reside in the vendors private MIB. Among all these parameters, only a small por-tion of the design space (e.g., cycle, offset, and split) can be calcu-lated by using software programs like Synchro and TRANSYT for coordinated intersections.

In summary, Table 1 is a list of the total number of NTCIP 1202 standard and vendor-specific parameters that can be configured in a controller. Table 1 shows the number of parameters that change longitudinally along

• A 22-intersection corridor,• A five-intersection isolated (uncoordinated) subsection, and• A 17-intersection coordinated subsystem.

Table 1 shows an empirical characterization of the design space for both free and coordinated operation relative to a default agency database for a coordinated system. In this case, because the reference default database was for a controller in a coordinated system, the num-ber of parameters in the design space for isolated operations was larger than the number of parameters in the design space for coordinated operations. Perhaps, longer term, it will be important for agencies to develop different default databases for each of these types of opera-tions. Figure 4a is graphical illustration of the number of parameters in the design space; they are categorized as either NTCIP 1202 or vendor-specific parameters. Figure 4b is a slightly different view of the same data, but instead of showing total parameters, it shows a count of parameter groups in the design space. For example, Table 2 shows that 16 RedClear parameters were changed and would be taken into account at 16 parameters in Figure 4a. However, Figure 4b would count these RedClear changes as one group.

example application of longitudinal analysis to identify database inconsistencies

In Figure 5, the 25 NTCIP standard parameters in the design space are shown on the vertical axis for the coordinated intersections in Table 1. The horizontal axis shows the number of parameter values that were altered for this coordinated system (462 total). In Table 3, a select number of altered parameter groups is shown with respect to Callouts a through g in Figure 5, along with the number of parameters affected within each group. The following discussion provides a summary of each of these callouts and their values (found in Table 3); each group designation corresponds to its callout in Figure 5:

• Callout a. The value for CoordForceMode (coordinated force-off mode) varies between 2 and 3. This value is set at the discretion of the programmer and is dependent on local traffic conditions at each intersection.• Callout b. The values for PhaseMaximum1 (Phases 1 through 8)

have a considerable amount of variation between intersections. Not surprisingly, Figure 5 shows that all eight of these phases have had some changes. The 50-s Phase 1 maximum time at Intersection 17 at

first appears to be a possible outlier. Further inspection reveals that the intersection is a major access point to a mall, and at 20:00 on Saturdays, when the mall is closing, the controller is set to go into free operation to clear the mall parking lot when the mainline traffic volumes along the corridor are low.• Callout c. The values for PhaseMaximum2 (Phases 1 through 8)

have substantially less variation than PhaseMaximum1. Intersec-tions 11 and 17 are major ones (17 is the mall entrance) requiring different time-of-day maximum times during free operation.• Callout d. The values for the PhaseMinGreen (Phases 1 through 8)

reflect a considerable amount of variation across the corridor. Portions of this corridor have video detection, and it is agency policy to have a minimum recall set for any phase with video detec-tion. Typically, movements with video detection are configured with small minimum values to ensure that the phase is serviced each time but rely on the video detection system to extend the phase.• Callout e. The values for the PhaseRedClear (Phases 1 through 8)

have a considerable amount of variation in value settings that are dependent on intersection width and design speed. The total num-ber of changed OID value parameters for PhaseRedClear is 8 of a possible 16. The 0 values within Group e correspond to phases that have been omitted and are consistent with the 0 values in Group d.• Callout f. The values for the PhaseRedRevert (Phases 1 and 5) are

changed only at Intersection 18. Although this value has little impact on controller operation, it demonstrates how a single value change across the corridor can be identified for checking of consistency and further inspection.• Callout g. The TimebaseAscPattern (time base pattern) changes

were found to have two numbers, 0 and 254. Although these both trigger free operation for the test controller’s specific configurations, this inconsistency is not desirable for long-term training and main-tenance because it creates opportunities for personnel working with the system to select an incorrect pattern accidently as the system matures and as new patterns might be added in future years. On the basis of MIB analysis, these numbers were adjusted by the agency in the deployed controllers to reflect the intended design value of 254.

Table 3, in addition to the descriptions above, is useful for summa-rizing the range of parameters configured longitudinally along a cor-ridor and for identifying substantial variations that warrant further scrutiny. In Group d, the PhaseMinGreen.2 and PhaseMinGreen.6 for Intersections 18 and 19 show relatively high minimum-green values (25 s). These values are indicative of high volumes being served at these intersections, with the tendency to queue over the advance detectors and cause a gap-out at the intersection. Although other alternative controller configurations, like the volume–density function, can resolve this gap-out issue, the high minimum green was one way the field technicians could address a gap-out trouble call at Intersections 18 and 19.

In Group g, although on this corridor both 0 and 254 can place the controller in free operation for TimebasePattern.99 (Table 3), an agency convention for free operation on these controller databases, a 0 value could be misinterpreted by operators and lead them to believe that the controller is operating erratically under certain con-figurations. The 0 value requires that the coordinated operation and free operation be called from the time base pattern, while a value of 254 places the controller in free operation without coordination from any source, as shown in NTCIP Section 2.5.1 (8). This type of difference in values reflects a potential operational problem that can be avoided by setting the 0 values to 254. These different val-ues reflect the agency’s transition into new NTCIP standards. Previ-ously, the National Electrical Manufacturers Association standard

0

200

400

600

800

1000

1200

1400

1600

1800

2000

2200

2400

2600

2800

3000

3200

1 2 65 94 83 7

2 65 94 83 7

10 11 12 13 14 15 16 17 18 19 20 21 22

CO

UN

T O

F A

LT

ER

ED

PA

RA

ME

TE

RS

INTERSECTION ID

Vendor Specific

NTCIP 1202

Isolated(Free) Operation

CoordinatedOperation

0

20

40

60

80

100

120

140

160

180

1 10 11 12 13 14 15 16 17 18 19 20 21 22

CO

UN

T O

F A

LT

ER

ED

PA

RA

ME

TE

R G

RO

UP

S

INTERSECTION ID

(a)

(b)

Vendor Specific

NTCIP 1202

Isolated(Free) Operation

CoordinatedOperation

FIGURE 4 Analysis of controller database parameters for 22 intersections: (a) count of parameter changes from typical coordinated agency controller database and (b) count of parameter groups changed from typical coordinated agency controller database.

TABLE 2 Example of Longitudinal Comparison

Parameter Values by Intersection for Phase Red Clearance Time (s)

Parameter Namea

Isolated Intersections Coordinated Intersections

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

RedClear.1 1.0 1.0 1.0 1.0 1.0 1.8 1.0 3.1 2.0 2.0 1.5 2.0 1.5 2.0 0.0 0.0 1.5 1.5 1.5 1.5 1.0 1.5

RedClear.2 1.6 1.6 1.6 1.6 1.6 1.5 1.5 1.4 1.5 1.8 2.0 1.8 2.0 2.0 3.0 2.5 2.0 2.0 2.0 2.0 1.5 1.8

RedClear.3 2.1 2.1 2.1 2.1 2.1 0.0 1.0 0.0 0.0 0.0 1.0 0.0 1.5 1.5 0.0 0.0 2.0 1.5 1.5 0.0 1.0 1.0

RedClear.4 2.1 2.1 2.1 2.1 2.1 1.5 1.5 3.4 2.0 2.0 2.0 2.0 2.0 2.0 2.0 0.0 2.0 2.0 1.8 1.5 1.5 1.5

RedClear.5 1.0 1.0 1.0 1.0 1.0 1.8 1.0 3.1 2.0 2.0 1.5 2.0 1.5 2.0 0.0 0.0 1.5 1.5 1.5 1.5 1.0 1.5

RedClear.6 1.0 1.0 1.0 1.0 1.0 1.5 1.5 1.4 1.5 1.8 2.0 1.8 2.0 2.0 3.0 2.5 2.0 2.0 2.0 2.0 1.5 1.8

RedClear.7 1.0 1.0 1.0 1.0 1.0 0.0 1.0 0.0 0.0 0.0 1.0 0.0 1.5 1.5 0.0 0.0 2.0 1.5 1.5 0.0 1.0 1.0

RedClear.8 2.1 2.1 2.1 2.1 2.1 1.5 1.5 3.4 2.0 2.0 2.0 2.0 2.0 2.0 0.0 3.0 2.0 2.0 1.8 1.5 1.5 1.5

RedClear.9 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.10 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.11 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.12 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.13 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.14 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.15 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

RedClear.16 1.0 1.0 1.0 1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0 0.0

aFinal digit represents phase number.


0 20 40 60

VehicleDetectorOptions

VehicleDetectorFailTime

VehicleDetectorExtend

VehicleDetectorDelay

VehicleDetectorCallPhase

TimeBaseScheduleDay

TimebaseAscPattern

SplitTime

Port1DevicePresent

PhaseYellowChange

PhaseRedRevert

PhaseRedClear

PhaseMinimumGreen

PhasePassage

PhaseOptions

PhaseMaximumInitial

PhaseMaximum2

PhaseMaximum1

PhaseAddedInitial

PatternSequenceNumber

PatternOffsetTime

DayPlanHour

CoordForceMode

ChannelControlType

ChannelControlSource

Number of Changed OID Values

64

199

a: 1

b: 8

c: 8

d: 8

e: 8

f: 2

g: 1

FIGURE 5 Longitudinal comparison of NTCIP 1202 database elements that vary between Intersections 6 through 22 (25 groups, 462 objects).

TABLE 3 Longitudinal Comparison of Select NTCIP 1202 Database Elements That Vary Between Coordinated Intersections 6 Through 22

Parameter Value by Coordinated Intersection Count of Unique ValuesGroup Parameter Name (OID) 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

a CoordForceMode.0 3 3 3 3 3 2 3 3 2 3 2 3 3 2 3 2 2 2

ba PhaseMaximum1.1 20 25 20 25 20 14 20 30 25 0 0 50 20 10 20 20 35 8PhaseMaximum1.2 45 60 60 50 55 45 55 55 60 50 45 65 60 60 60 40 55 6PhaseMaximum1.3 0 35 0 0 0 14 0 25 20 0 0 30 20 12 0 15 20 8PhaseMaximum1.4 30 40 30 30 30 18 30 40 35 30 0 20 25 20 30 25 30 7PhaseMaximum1.5 20 35 25 25 20 14 20 30 25 0 0 25 15 10 20 20 20 8PhaseMaximum1.6 45 60 60 50 55 45 55 55 60 50 45 55 60 60 60 40 55 5PhaseMaximum1.7 0 25 0 0 0 14 0 25 20 0 0 14 20 12 0 20 20 5PhaseMaximum1.8 30 40 30 30 30 18 30 40 35 0 35 20 25 20 30 25 30 7

ca PhaseMaximum2.1 0 0 0 0 0 25 0 0 0 0 0 25 0 0 0 0 0 2PhaseMaximum2.2 0 0 0 0 0 50 0 0 0 0 0 65 0 0 0 0 0 3PhaseMaximum2.3 0 0 0 0 0 15 0 0 0 0 0 30 0 0 0 0 0 3PhaseMaximum2.4 0 0 0 0 0 30 0 0 0 0 0 20 0 0 0 0 0 3PhaseMaximum2.5 0 0 0 0 0 25 0 0 0 0 0 25 0 0 0 0 0 2PhaseMaximum2.6 0 0 0 0 0 50 0 0 0 0 0 65 0 0 0 0 0 3PhaseMaximum2.7 0 0 0 0 0 15 0 0 0 0 0 30 0 0 0 0 0 3PhaseMaximum2.8 0 0 0 0 0 30 0 0 0 0 0 20 0 0 0 0 0 3

da PhaseMinGreen.1 7 7 5 8 7 3 7 7 7 0 0 8 3 3 3 5 6 6PhaseMinGreen.2 15 15 20 15 15 15 15 15 15 15 15 20 25 25 15 20 15 3PhaseMinGreen.3 0 7 0 0 0 3 0 7 7 0 0 8 3 3 0 5 6 6PhaseMinGreen.4 1.5 10 8 8 7 4 7 8 8 8 0 8 4 4 8 5 8 6PhaseMinGreen.5 7 7 5 8 7 3 7 7 7 0 0 8 3 3 3 5 6 6PhaseMinGreen.6 15 15 20 15 15 15 15 15 15 15 15 20 25 25 15 20 15 3PhaseMinGreen.7 0 7 0 0 0 3 0 7 7 0 0 8 3 3 0 5 6 6PhaseMinGreen.8 8 10 8 8 7 4 7 8 8 0 8 8 4 4 4 5 8 6

ea PhaseRedClear.1 1.8 1 3.1 2 2 1.5 2 1.5 2 0 0 1.5 1.5 1.5 1.5 1 1.5 6PhaseRedClear.2 1.5 1.5 1.4 1.5 1.8 2 1.8 2 2 3 2.5 2 2 2 2 1.5 1.8 6PhaseRedClear.3 0 1 0 0 0 1 0 1.5 1.5 0 0 2 1.5 1.5 0 1 1 4PhaseRedClear.4 1.5 1.5 3.4 2 2 2 2 2 2 2 0 2 2 1.8 1.5 1.5 1.5 5PhaseRedClear.5 1.8 1 3.1 2 2 1.5 2 1.5 2 0 0 1.5 1.5 1.5 1.5 1 1.5 6PhaseRedClear.6 1.5 1.5 1.4 1.5 1.8 2 1.8 2 2 3 2.5 2 2 2 2 1.5 1.8 6PhaseRedClear.7 0 1 0 0 0 1 0 1.5 1.5 0 0 2 1.5 1.5 0 1 1 4PhaseRedClear.8 1.5 1.5 3.4 2 2 2 2 2 2 0 3 2 2 1.8 1.5 1.5 1.5 6

fa PhaseRedRevert.1 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 2PhaseRedRevert.5 0 0 0 0 0 0 0 0 0 0 0 0 2 0 0 0 0 2

g TimebasePattern.99 2 2 2 2 2 2 2 2 2 2 2 2 0 2 0 0 2 25 5 5 5 5 5 5 5 5 5 5 5 5 54 4 4 4 4 4 4 4 4 4 4 4 4 4

aFinal digit in name represents phase number. Values are in seconds.


required a 0 value to place the controller in free operation, but this has been changed to 254 (8).

deSign SPace checkliSt

Table 1 defines the potential controller design space in terms that only a few agencies would consider. The table defines a potential controller design space on the basis of an empirical comparison of what parameters changed longitudinally along subsections and the entire 22-intersection corridor. It also defines a potential controller design space on the basis of an empirical comparison between sub-sections of a 22-intersection corridor and a default agency database. Figure 4, a and b, is a graphic reminder that this design space may vary slightly from intersection to intersection.

This section of the paper presents tables enumerating the NTCIP and vendor-specific object groups that correspond to the 25 NTCIP and 63 vendor-specific groups tabulated in Table 1. The checklist for the 25 NTCIP objects appears in Table 4. The checklist for the 63 vendor-specific objects is enumerated in Tables 5, 6, and 7, and graphically illustrated in Figure 6. Descriptions of these tables and of the column attributes follow.

In Table 4, the 25 MIB groups previously identified in Figure 5 rep-resent the NTCIP general design space. Each MIB group is aligned with five potential checklist categories that are used to define the ori-gin of the MIB group values. These checklist category assignments were developed on the basis of Indiana Department of Transporta-tion standard practices. However, these tables could easily be adapted to any agency’s requirements by changing which box is shaded or even adding or deleting category columns (perhaps for a signal tech-nician). The majority of these MIB values are defined by agency protocol or programmer knowledge. Two of these checklist items, PhaseRedClear and YellowChange, are defined by ITE standards. The PatternOffsetTime, PatternSequence number (for lead and lag variations), PhaseMinimumGreen, and SplitTime can be derived from Synchro output. Of the 25 represented MIB groups, only two were unclear as to the origin of the responsibility or the require-ments for their values. However, the Unclear column in Table 4 is important because of the likelihood that, once any agency performs this task of enumerating the design space, it will encounter similar unclear objects that require further internal dialogue to define.

Table 5 shows the general vendor-specific parameter design space for 43 MIB groups that account for 719 parameter changes. The major-ity of the parameter selections in Table 5 are to be defined by agency

TABLE 4 Typical NTCIP 1202 Selection Guidance for General Parameters

Parameter Selection Guidance

MIB Group Table Structure Altered OIDsAgency Guidelines ITE Synchro

Programmer Judgment Unclear

ChannelControlSource 16 Tbl(s) of 1 4

ChannelControlType 16 Tbl(s) of 1 4

CoordForceMode Bin/Txt/Value 1

DayPlanHour 16 Tbl(s) of 50 5

PatternOffsetTime 120 Tbl(s) of 1 4

PatternSequenceNumber 120 Tbl(s) of 1 5

PhaseAddedInitial 16 Tbl(s) of 1 4

PhaseMaximum1 16 Tbl(s) of 1 8

PhaseMaximum2 16 Tbl(s) of 1 8

PhaseMaximumInitial 16 Tbl(s) of 1 4

PhaseMinimumGreen 16 Tbl(s) of 1 8

PhaseOptions 16 Tbl(s) of 1 6

PhasePassage 16 Tbl(s) of 1 8

PhaseRedClear 16 Tbl(s) of 1 8

PhaseRedRevert 16 Tbl(s) of 1 2

PhaseYellowChange 16 Tbl(s) of 1 8

Port1DevicePresent 1 Tbl(s) of 19 2

SplitTime 119 Tbl(s) of 16 32

TimebaseAscPattern 100 Tbl(s) of 1 1

TimeBaseScheduleDay 200 Tbl(s) of 1 199

VehicleDetectorCallPhase 64 Tbl(s) of 1 34

VehicleDetectorDelay 64 Tbl(s) of 1 16

VehicleDetectorExtend 64 Tbl(s) of 1 11

VehicleDetectorFailTime 64 Tbl(s) of 1 64

VehicleDetectorOptions 64 Tbl(s) of 1 16

Total 462

Note: Tbl(s) = table(s); txt = text.


TABLE 5 Typical Vendor-Specific Selection Guidance for General Parameters


MIB Group Table StructureAltered OIDs

Agency Guidelines ITE Synchro


Asc3AddedInitialOption 4 Tbl(s) of 64 17

Asc3CNA2Phases Bin/Txt/Value 1

Asc3crdForceOffAddInitial Bin/Txt/Value 1

Asc3crdInterconnectSource Bin/Txt/Value 1

Asc3crdUsePedTime Bin/Txt/Value 1

Asc3DayPlanActionNumber 16 Tbl(s) of 50 9

Asc3FlashExitOverlapDelay Bin/Txt/Value 1

Asc3MMUColorChkDisableGrn 16 Tbl(s) of 1 6

Asc3MMUColorChkDisableRed 16 Tbl(s) of 1 2

Asc3MMUColorChkDisableYel 16 Tbl(s) of 1 6

Asc3MMUCompatibilityMode Bin/Txt/Value 1

Asc3MMUCompatibilityState 160 Tbl(s) of 1 21

Asc3NtcipRing1Phase 15 of 16, 1 of 15 2

Asc3NtcipRing2Phase 15 of 16, 1 of 15 8

Asc3PassageOption 4 Tbl(s) of 64 70

Asc3PhaseAddedInitial 4 Tbl(s) of 16 10

Asc3PhaseMaximum1 4 Tbl(s) of 16 56



Asc3PhaseMaximumInitial 4 Tbl(s) of 16 10

Asc3PhaseMinimumGreen 4 Tbl(s) of 16 50

Asc3PhaseOptions 4 Tbl(s) of 16 8

Asc3PhasePassage 4 Tbl(s) of 16 56

Asc3PhasePedestrianClear 4 Tbl(s) of 16 24

Asc3PhaseRedClear 4 Tbl(s) of 16 56

Asc3PhaseRedRevert 4 Tbl(s) of 16 50

Asc3PhaseSimultaneousGapPhases 16 Tbl(s) of 1 2

Asc3PhaseWalk 4 Tbl(s) of 16 24

Asc3PhaseYellowChange 4 Tbl(s) of 16 56

Asc3ptnActionPlan 120 Tbl(s) of 1 1

Asc3ptnPhaseSplit 120 Tbl(s) of 16 32

Aasc3ptnSequenceSelect 120 Tbl(s) of 1 5

Asc3seqBarrierTypeSel 16 Tbl(s) of 1 5

Asc3seqPhaseConcurrency 16 Tbl(s) of 1 16

Asc3tbCtlSequence 36 Tbl(s) of 1 5

Asc3tbExceptDayPlan 36 Tbl(s) of 1 3

Asc3tbExceptDOMOrDOW 36 Tbl(s) of 1 3

Asc3tbExceptFormat 36 Tbl(s) of 1 1

Asc3tbExceptMonth 36 Tbl(s) of 1 3

Asc3tbExceptWOMOrYear 36 Tbl(s) of 1 2

Asc3tbLPStatementSel 100 Tbls of 200 16

Asc3tbResetTimeHour Bin/Txt/Value 1

Asc3tbResetTimeMin Bin/Txt/Value 1

Total 719


or programmer judgment. However, three variables, Asc3PhaseMini-mumGreen, Asc3ptnPhaseSplit, and Asc3ptnSequenceSelect, can be derived from Synchro output. In Table 6, the vendor-specific design space of the detection parameter is defined by 10 MIB groups, which account for 394 parameter changes. In Table 6, the majority of the MIB value origins are based on programmer judgment. This is an expected outcome when the number of site-specific attributes that need to be taken into account for these types of data input is con-sidered. The one MIB group that is determined by agency policy in Table 6 is VehDetFailTime because values vary on the basis of agency detector hardware, tolerances, and usage type. Finally, in Table 7, the design space for vendor-specific communication and data storage infrastructure is defined by 10 MIB groups, which account for 78 parameter changes. The communication infrastructure, like detection parameters, is relatively site specific with seven of the MIB groups being defined by programmer judgment.

Tables 4 through 7 were empirically developed from Indiana Department of Transportation practice but represent a reasonable facsimile of an agency design space. Obviously, some agencies

will have more objects in this list and others fewer. Furthermore, agencies may have different perspectives on the categorization of each of these objects. However, the procedure for obtaining this list is easily reproduced by any agency using NTCIP controllers and can be readily adapted to their local practice with minimal effort.

concluSionS and Future aPPlicationS

This paper proposed using standard NTCIP get-next objects as a sys-tematic empirical method of defining the design space for a modern traffic controller. Of the approximately 74,000 configurable param-eters in a controller, a typical coordinated system requires about 2.2% (1,653) of those parameters changed per intersection. Approx-imately 28% of those parameters were NTCIP 1202 parameters and 72% were vendor specific.

Application of the NTCIP get-next systematic database querying was used to illustrate how longitudinal comparisons could be per-formed between intersections to identify consistency problems and

TABLE 7 Typical Vendor-Specific Selection Guide for Communication and Data Storage Infrastructure Parameters





Asc3AutoBackupToDatakey Bin/Txt/Value 1

Asc3EcpipAddress Bin/Txt/Value 1

Asc3Portduplex 1Tbl(s) of 5 1

Asc3PortModemControl 1Tbl(s) of 5 1

Asc3PortrespDelay 1Tbl(s) of 5 1

Asc3PortsingleFlag 1Tbl(s) of 5 1

Asc3PorttelemAddr 1Tbl(s) of 5 2

Asc3LocalDetectorLogging 4 Tbl(s) of 64 64

Asc3tbDetLog 36 Tbl(s) of 1 5

Asc3unitWarningGrpDisableMap Bin/Txt/Value 1

Total 78

TABLE 6 Typical Vendor-Specific Selection Guidance for Detection Parameters





Asc3ByDetType 64 Tbl(s) of 1 36

Asc3CallOption 4 Tbl(s) of 64 75

Asc3DetExtensionOption 4 Tbl(s) of 64 70

Asc3DetPhaseLockDet 4 Tbl(s) of 1 1

Asc3DetPhaseMaxRecall 4 Tbl(s) of 1 1

Asc3VehDetCallPhase 4 Tbl(s) of 64 34

Asc3VehDetDelay 4 Tbl(s) of 64 16

Asc3VehDetExtend 4 Tbl(s) of 64 11

Asc3VehDetFailTime 4 Tbl(s) of 64 64

Asc3VehDetOptions 4 Tbl(s) of 64 86

Total 394


0 20 40 60

Asc3unitWarningGrpDisableMap Asc3tbDetLog

Asc3PorttelemAddr Asc3PortsingleFlag Asc3PortrespDelay

Asc3PortModemControl Asc3Portduplex

Asc3LocalDetectorLogging Asc3EcpipAddress

Asc3AutoBackupToDatakey Asc3VehDetOptions

Asc3VehDetFailTime Asc3VehDetExtend

Asc3VehDetDelay Asc3VehDetCallPhase

Asc3DetPhaseMaxRecall Asc3DetPhaseLockDet

Asc3DetExtensionOption Asc3CallOption

Asc3ByDetType Asc3tbResetTimeMin

Asc3tbResetTimeHour Asc3tbLPStatementSel

Asc3tbExceptWOMOrYear Asc3tbExceptMonth

Asc3tbExceptFormat Asc3tbExceptDOMOrDOW

Asc3tbExceptDayPlan Asc3tbCtlSequence

Asc3seqPhaseConcurrency Asc3seqBarrierTypeSel

Asc3ptnSequenceSelect Asc3ptnPhaseSplit Asc3ptnActionPlan

Asc3PhaseYellowChange Asc3PhaseWalk

Asc3PhaseSimultaneousGapPhases Asc3PhaseRedRevert Asc3PhaseRedClear

Asc3PhasePedestrianClear Asc3PhasePassage Asc3PhaseOptions

Asc3PhaseMinimumGreen Asc3PhaseMaximumInitial

Asc3PhaseMaximum3 Asc3PhaseMaximum2 Asc3PhaseMaximum1

Asc3PhaseAddedInitial Asc3PassageOption

Asc3NtcipRing2Phase Asc3NtcipRing1Phase

Asc3MMUCompatibilityState Asc3MMUCompatibilityMode

Asc3MMUColorChkDisableYel Asc3MMUColorChkDisableRed Asc3MMUColorChkDisableGrn

Asc3FlashExitOverlapDelay Asc3DayPlanActionNumber

Asc3crdUsePedTime Asc3crdInterconnectSource

Asc3crdForceOffAddInitial Asc3CNA2Phases

Asc3AddedInitialOption

Number of Changed OID Values

75

70

70

64

86

64 Table 6

Table 7

Table 5

FIGURE 6 Longitudinal comparison of vendor-specific database elements that vary between coordinated Intersections 6 through 22 (63 groups, 1,191 objects).


outliers (Table 3). The paper concluded by enumerating the NTCIP and vendor-specific parameters summarized in Table 1 as a design checklist in Tables 4, 5, 6, and 7. These tables summarize the broad spectrum of parameters that must be configured to make a modern traffic signal controller operate properly. An agency can use these tables as a checklist with which staff or consultants can define expec-tations precisely when traffic signal controller configurations are developed or updated. These tables provide a framework for devel-oping quality assurance/quality control checklist procedures that the authors believe will significantly reduce the number of operational errors requiring field adjustment. Although some agencies will have more objects in these tables and others fewer, the procedure for obtaining this list can be easily reproduced by any agency that uses NTCIP controllers and can be readily adapted to local practice with minimal effort.

acknowledgmentS

This work was supported by the Joint Transportation Research Pro-gram administered by the Indiana Department of Transportation and Purdue University.

reFerenceS

1. Brennan, T. M., Jr., C. M. Day, J. R. Sturdevant, and D. M. Bullock. Visual Education Tools to Illustrate Coordinated System Operation. In Transpor-tation Research Record: Journal of the Transportation Research Board,

No. 2259, Transportation Research Board of the National Academies, Washington, D.C., 2011, pp. 59–72.

2. Head, L., D. Gettman, D. M. Bullock, and T. Urbanik II. Modeling Traffic Signal Operations with Precedence Graphs. In Transportation Research Record: Journal of the Transportation Research Board, No. 2035, Trans-portation Research Board of the National Academies, Washington, D.C., 2007, pp. 10–18.

3. Day, C. M., and D. M. Bullock. Arterial Performance Measures, Vol-ume 1: Performance-Based Management of Arterial Traffic Signal Sys-tems. NCHRP 3-79A. Transportation Research Board of the National Academies, Washington, D.C., 2010.

4. Day, C. M. Performance-Based Management of Arterial Traffic Signal Systems. PhD dissertation. Purdue University, West Lafayette, Ind., 2010.

5. Day, C. M., and D. M. Bullock. Application of High Resolution Traf-fic Signal Controller Data for Platoon Visualization and Optimization of Signal Offsets. Presented at Mobil.TUM 2009, International Scientific Conference on Mobility and Transport, Munich, Germany, May 2009.

6. Brennan, T. M., Jr., C. M. Day, D. M. Bullock, and J. R. Sturdevant. Performance Measures for Railroad-Preempted Intersections. In Transpor-tation Research Record: Journal of the Transportation Research Board, No. 2128, Transportation Research Board of the National Academies, Washington, D.C., 2009, pp. 20–34.

7. Wiesenfeld, M. T. Analysis of Design and Implementation Standards for Coordinated Traffic Signal Systems. Master’s thesis. Purdue University, West Lafayette, Ind., 2008.

8. National Transportation Communications for ITS Protocol: Object Defi-nitions for Actuated Traffic Signal Controllers, vers. 01.07. FHWA, U.S. Department of Transportation, 2005.

The contents of this paper reflect the views of the authors, who are responsible for the facts and the accuracy of the data, and do not necessarily reflect the official views or policies of the sponsoring organizations. The contents do not constitute a standard, specification, or regulation.

The Traffic Signal Systems Committee peer-reviewed this paper.

Documents

Defining Design Space for Parameters of Traffic Signal Timing