The New York City, NY, USA, Traffic Signal System - A Standards-Based Approach

HISTORY

The City of New York, NY, USA, has approximately 11,000 signalized intersections. Most of these intersections use single dial, electromechanical controllers, in which a simple timing dial controlled by a synchronous motor advances a load switching camshaft that provides one circuit for each signal and/or pedestrian display for each phase. The contacts ride on "cams" that are broken off to enable the power to the signal display.

The camshaft is ratcheted, or advanced, based on the position of "keys" located around the dial to provide the interval timing. The dial typically makes one revolution per cycle (gears select the cycle length). Interlocks ensure that the dial and cam remain in sync. A single offset key is used to set the relationship between intersections.

New York City's central vehicle traffic control system (VTCS) replaces the dialgenerated pulses with computer-generated advance signals that are connected to the controller's camshaft through a modification kit using leased telephone circuits. The installation of the central system began in the late 1960s. It has been expanded and upgraded over the years.

The system currently controls almost 6,500 intersections in New York and uses two different types of communications: a DC interconnect system for the outer boroughs (Brooklyn, Queens, Staten Island and The Bronx), which uses 100volt DC pulses to advance the camshafts; and a high-speed coaxial cable network for Manhattan, which uses a communications adapter with built-in time-based coordination, detector processing and monitoring circuits (see Figure 1).

New York City is expanding its system with approximately 2,200 additional intersections. After considerable negotiations with the telecommunications service provider, the City of New York decided to undertake a program to use wireless technology for the expansion.

Eventually, all existing hard-wired interconnect will be replaced with wireless technology. The wireless network is part of a combined effort between emergency services and the City's Department of Information Technology and Telecommunications to provide a wide range of wireless services, including traffic control, video, emergency call boxes, automatic vehicle location and other mobile data services. The wireless infrastructure will provide a high-speed wireless Ethernet from the traffic management center to the traffic controllers.

The final aspect of the upgrade program is the field traffic controllers themselves. The City had wanted to replace the aging electromechanical controllers for many years. In the late 1990s, the New York City Department of Transportation advertised for the purchase of 1,000 controllers with a specification based on the emerging Advanced Transportation Controller (ATC) Type 2070 and the New York State 170/330 Cabinet. The bids were more than twice the available budget and, subsequently, the procurement was abandoned.

A STANDARDS-BASED APPROACH

Although the earlier attempt to purchase solid-state traffic controllers saw prices that were too high, the lessons learned from that procurement were used to develop the new specifications. The goals remained the same, but emerging intelligent transportation systems (ITS) standards played a different role.

The first step in developing the procurement following the system engineering process was to examine actual user needs and requirements for the traffic controllers. Several workshops were held with maintenance and operations personnel to identify and document the minimum and maximum features and/or functions required for the new traffic controllers.

It is important to understand that all signal system maintenance is performed by electricians under maintenance contracts to several electrical contractors. Due to the size of the system, ease of maintenance and installation were major drivers in the development of the specifications. After meetings with city engineers and maintenance personnel and an analysis of field operations, a high-level draft specification was developed.

Because cost was a major issue, the draft specification requirements were distributed to manufacturers for their review and comments. A series of private meetings was arranged with these vendors to obtain candid feedback on the requirements and some of the design aspects of the specification. This was an important part of the development process. Establishing requirements without tempering them for cost effectiveness and costs/benefits can be dangerous, as evidenced by the earlier failed procurement.

This time, each vendor was asked to indicate ways to reduce costs and to provide some estimates as to the relative cost of certain options. Feedback from these vendors was used to finalize the specification.

It is important to note that "cherry picking" the best features and construction techniques from each manufacturer was avoided. The specification tried to work from common elements to minimize custom development and keep costs down. The City wanted to ensure that it would be a highly competitive procurement and did not want a repeat of earlier issues.

Some of the major findings for highlevel requirements included the following:

* The size of the cabinet had to remain small-about the same size as the existing cabinets due to the limited sidewalk space. Construction techniques/materials had to match existing City cabinet specifications.

* Field maintenance had to be reasonably fool-proof; maintenance had to be virtually plug-and-play for all field replaceable items. Field maintenance personnel should not be able to alter the timing or operational parameters. Diagnostic troubleshooting aids were an essential part of the field maintenance support.

* Six load switches would handle 97 percent of the existing intersections. Where six were inadequate, 12 load switches would meet the need. However, there was a desire to provide a means of expanding the local controller in the future for more inputs and load switches. All load switches should be the same type.

* Four input slots were considered adequate for the six-load switch controller. This could handle up to eight detector channels or six channels and the DC communications adapter. For the larger cabinet, 10 input slots were considered adequate. There needed to be a means of extending the number of detectors supported for special locations (as yet undefined).

* The controller had to support a wide range of communications capabilities, including the existing DC interconnect, the Manhattan cable interconnect, Ethernet and, possibly, other modems for digital or analog communications infrastructure.

* The controllers should support basic National Electrical Manufacturers Association (NEMA) TS2 functionality, but also needed support for pre-timed operation until the National Transportation Communications for ITS Protocol data communications infrastructure was in place (see Figure 2).

Some of the other compromises and/or requirements adopted by the City included the following:

* The conflict monitor used by the New York State 330 Cabinet was considered acceptable; however, the normal voltage operation thresholds had to be wider (95 volts AC) and it had to support the NEMA start-up timing.

* The load switches had to match the New York state ratings due to the mixture of incandescent and lightemitting diode (LED) signal heads in use.

* All input cards had to match the New York state requirements, except that a manual switch was required for each channel to allow maintenance personnel to quickly force the detector to present a constant call.

* The New York state interface assembly was considered acceptable, was relatively inexpensive and was easily replaceable.

* The DataKey used for the 2070 controller was considered unacceptable; it was sole source and expensive, required special programming devices and was easily lost.

* Due to size, 19-inch rack mounting was not considered a requirement. In other words, small cabinet size was considered more important than rack mount standardization.

* The use of a bus interface unit (BIU) and backplane wiring was considered acceptable as long as there was no way that field short circuits could damage traces to the backplane wiring.

After meetings with vendors and a review of New York state specifications, it appeared that the NEMA TS2 Type-1 Cabinet would present the most compact, cost-effective approach. However, it also was noted that most of the New York State 170/330 Cabinet subassemblies and plug-in devices were less expensive than their NEMA counterparts. In discussions with the various manufacturers, it became clear that "repackaging" due to the mechanical constraints of the small cabinet was not a large cost item.

Therefore, the cabinet requirements were developed to use the standard plugin devices (for example, input cards, load switches, BIU and flashers) but required customization of the major assemblies (for example, input files and output files).

It also was determined that with an order of 1,000 controllers, the project was large enough that the packaging and custom software development costs would not drive up the unit price more than approximately $500 per cabinet (based on estimates from interviewed vendors).

It was decided that the 2070 construct (with all internally interchangeable modules) was too expensive for the relatively simple intersections within the City. Therefore, a more functional approach was taken. The form, fit and function of the controller were mandated, but the internal construction, including the processor and memory, was left to the vendor.

With this approach, it was felt that the vendor could easily use or repackage its standard hardware to meet the needs of the installation. This approach closely matched the ATC standards development program at the time.

To protect the interests of the City over the long term, the vendor was required to provide the source code and a full development system, to allow the City or subsequent third parties to make modifications to the software and deploy that software throughout the City. Although the ownership of the software was left to the vendor, license rights allowed the City to deploy the software or derivative products at all intersections within the City.

COMMUNICATIONS

At the time of the bid letting, the communication infrastructure had been designed based on a multi-drop, 9,600 bits per second digital service (DDS-II). However, the City had just started negotiations on a possible wireless solution. Therefore, the controller specifications were written so that the controller would be required to support a variety of communications options. This included support for the existing DC interconnect, the Manhattan coaxial cable interconnect, 10BaseT Ethernet and TIA-232 serial.

To accommodate other options, the specifications required that the vendor include provisions for a standard 2070 communications card that could support a variety of digital and analog communications technologies. This approach matched the ATC standard and allowed the City to leverage its future communications purchases from the broader traffic controller market.

The final issue was the adoption of the NTCIP standards for actuated signal control (1201-Global Objects and 1202-Actuated Signal Control). Although the industry has been plagued with "custom" (or semi-custom) implementations of NTCIP, proprietary management information bases and proprietary objects (including block objects), it was decided that the New York signal system would disallow the use of any custom or proprietary objects except for features specific to the New York project.

Furthermore, such features were to be well documented, such that future procurements could specify these objects easily, including formats and functionality and their interaction or relationship to the standard objects.

The NTCIP standard (1202) provides all of the objects for managing the operation of a standard NEMA traffic controller as defined in the TS2 specification. It was determined that this standard would be used and the optional objects and value ranges would be identified to ensure future compatibility. Taking this approach and ensuring that the management information base used will be in the public domain was the first step.

The second step was to clearly identify the special features and the data objects for those features. This was left to the vendor, which also was required to obtain object IDs for the custom objects and ensure that the management information base can be used by the City for all future procurements. These objects included items such as dynamic configuration of inputs and outputs, support for trap detectors for Manhattan and IP-addressing values.

RESULTS

The project was bid in fall 2000 and was awarded to the low bidder in spring 2001. Due to constraints on the general procurement of equipment, the bid was a typical low-bid materials procurement with no incremental payments for anything other than delivered product.

However, the procurement did recognize the developmental nature of the project and established a schedule and submittal program requiring a specification walk-through at the kick-off; a design walk-through as the vendor completed its designs; complete design submittals; prototype testing and review; and design approval testing on a sample of the first production units.

This testing program was rigorous, requiring the successful testing of five units (simultaneously) over environmental limits such as temperature, humidity, voltage, transients, vibration and shock per NEMA standards, augmented with some of the more stringent 170/2070 test requirements.

The low bid was substantially lower than the previous bid per controller, including cabinet, software, plug-ins, testing and delivery to the City. However, the controller itself is significantly more powerful than a 2070 (or ATC) and is equipped with more memory and a more robust operating system.

Over the past six months, the City has installed almost 600 controllers and continues to expand. As can be expected, the transition to solid-state controllers from the older electromechanical controllers has had its share of problems. Where electromechanical contacts are forgiving of issues such as bad wiring, poor splices, or bad grounding, solidstate controllers, with their conflict monitors and LED signal heads, can be problematic when faced with these conditions (see Figure 3).

The City has had to upgrade wiring and add dummy loads where temporary repairs are necessary. The field maintenance personnel now must carry laptop computers and have been trained in both corrective and preventive maintenance for devices such as conflict monitors and controllers.

LESSONS LEARNED

Testing the operational software has been time-consuming and tedious. The nature of the system interactions between VTCS and the traffic controllers is complex and the vendor has had to develop the operational software that manages to maintain safe operation with all of the safety checks in the field and remain online with VTCS.

During the initial design phases, the vendor proposed providing USB ports to facilitate the loading of operational parameters and software (both operating system and application software).

The City accepted this change such that the maintenance (and installation) contractors no longer need a laptop computer. Rather, they can use a commonly available USB memory device to load all software and parameters in a matter of a few seconds. This greatly simplifies the installation and maintenance processes. This proved to be so successful that the ATC standard added a USB port to the original design.

To meet the "nearly fool-proof" requirement, the vendor chose to mount a cabinet address card (also used for the IP address of the controller) into the cabinet. This 16-bit cabinet address is read by the controller at start-up and, if the database does not match, it continues in flashing operation until a database can be loaded. If a USB or laptop computer is available, it searches for the file on that device that matches the cabinet address and downloads the configuration and operational parameters before starting three-color operation.

When a system communications port is available, it uses the cabinet address to request a download of these parameters (with a technician present) and then releases the signal to three-color operation. The front panel has been augmented to show the cabinet location (street/cross street) loaded in the database, which serves as a further check that the right database has been loaded.

NEXT STEPS

New York City is moving forward on two fronts for the next phases of its upgrade program. The first is the procurement of a large-scale wireless network for communications to controllers. This will be a redundant, mesh type network using the intersections as repeaters and routers with a limited number of wireless access points to connect to the central system over the City's existing fiber backbone.

To meet the needs of a wireless communications medium, the City is working with NTCIP standards committees and the traffic controller vendor to develop an exception-based reporting system based on the NTCIP 1103 standard and simple network management protocol traps. This approach allows the real-time reporting of state changes without the need for polling, reducing communications traffic by approximately 90 percent while allowing support for real-time intersection displays and monitoring. This technology currently is being tested and should be ready for operation with test deployments of the wireless technology by early summer 2005.

The second aspect of the expansion program is the ongoing procurement of new controllers. The City is preparing a procurement bid that will expand the number of solid-state traffic controllers to approximately half the total number of intersections over the next two to three years, depending on budget.

This procurement document mandates backward compatibility with the existing cabinets but allows the biddet to provide equipment meeting the now adopted ATC standards for cabinet devices. The standard does not mandate the use of the ATC engine board, although it is likely that most bidders will adopt this approach.

Testing of the controller firmware has been a significant effort and is ongoing. Although the original procurement was structured to require only repacking of a vendor's standard product and some custom software to manage the special functionality of VTCS, the low bidder used this project to re-engineer its product from the ground up. This meant a new hardware design for the controller and all new software-starting with NTCIP as its basis of operation. As a result, the project has suffered significant delays due to the complexity of the applications and the hardware designs. It is anticipated that future procurements will remain closer to the procurement schedule.