Getting the Green Light
Delcan's Traffic Control System Stops Drivers from Seeing Red

Richard Chylinski, Delcan Corporation

These days you hear a lot about intelligent cars. But what about intelligent roads...or intersections, or traffic lights? The next time the traffic jam you anticipate on your way to work never happens, you may, in fact, have an intelligent traffic system to thank.

Delcan Corporation, a Toronto-based engineering, planning, and project management firm, designs and implements intelligent transportation systems like the one just described. Our version, UTCS (Urban Traffic Control System), is a PC-based traffic control system that provides centralized road and intersection monitoring and traffic flow optimization in several major cities.

A typical UTCS in a large metropolitan area ties thousands of traffic signals together. Centralized control immediately alerts traffic engineers to any signal failure. The system's sophisticated reporting and analysis capabilities help engineers generate timing plans to optimize traffic flow according to the day of the week and the time of day, and to download these timing plans instantly to every intersection. The system even adjusts itself to traffic patterns in real time, gauging the flow of vehicles at various points and adjusting the length of red and green lights within the traffic grid. The net effect? Drivers benefit from fewer traffic jams, shorter waits at intersections, and a lowered probability of signal downtime.

We have now developed a traffic control system that dwarfs previous deployments. In Vancouver, British Columbia, we've implemented a QNX-based application that will eventually combine some 1200 traffic signal controllers - the hardware that coordinates traffic lights, "walk/don't walk" signals, and so on - into a centralized server. To manage the much larger load - and to accommodate even larger installations in the future - we've developed improved architecture and components for UTCS that will allow it to scale up to handle the largest metropolitan traffic systems.

Improved architecture
Communications servers

To enhance performance and maximize configuration and expansion options, the UTCS system can be distributed on several tiers or hardware layers. The tier closest to "street level" consists of communications servers that connect via dedicated lines with the 1200 traffic signal controllers throughout the city. Running on QNX, the communications servers manage and log massive amounts of I/O and messaging traffic, including all signaling activity at every intersection. The Vancouver implementation uses just three communications servers, but the system is designed to accommodate up to 50.

At regular intervals, the communications servers send activity-logging information to update the QNX-based central server, which is the realtime data repository and control center of the system. Alarms and other critical notifications are also relayed as needed. The central server contains application logic relating to alarm and event management, as well as the traffic response control algorithms that allow the system to adjust itself to new traffic conditions. The central server is also the repository from which operators can extract information relating to system events and traffic patterns.

QNX is our choice for system components that require fault-tolerant realtime performance, such as the central server and communications servers. However, it made sense for the operator workstation application to run on our clients" standard desktop platform, alongside the operators" standard PC office applications. For that reason, operator workstations run on Windows NT. From these PCs, operators can access the central server to generate reports and control all functions of the UTCS. We designed the system to initially accommodate 10 operator workstations, but the actual number is limitless.

Enter Velocis DBMS

In earlier versions, we used an ISAM database. However, Velocis, with its client/server architecture and support for the Open Database Connectivity (ODBC) standard, better matched the multi-tier design of the new system. Velocis resides on the central server and is accessed from both the communications server (to write information to the database) and the operator work- stations. Velocis was also a good match for the QNX operating system because features of the DBMS enable it to keep up with the application"s heavy messaging traffic. Specifically, Velocis supports two APIs: industry-standard SQL and a proprietary C function library, which manipulates records at a lower (and faster) level than the high-level SQL. Using SQL, we reduced development time - an important achievement given our tight schedule.

The C function library is a tool we're keeping in reserve for future enhancements to the system. Depending on future performance demands, it would make sense to use the lower-level interface to handle realtime tasks such as logging the constant stream of information into the database, and SQL for less performance- intensive tasks such as database reporting. Velocis is unique among client/server database management systems in that it supports the use of both interfaces to access a single database. Velocis" cross-platform and multi-protocol support were also critical in system design (see below).

Cross-platform communication
In implementing UTCS, we were faced with the question of how to support communications between the quite different QNX and Windows NT platforms. Fortunately, the unique communications capabilities of both Velocis and QNX solved this problem.

First, Velocis supports the ODBC standard, which defines an interface for an application running on Windows to communicate with any data source possessing an ODBC driver (in this case, the Velocis database running on QNX).

Second, both Velocis and QNX support multiple communications protocols, which enabled us to harness TCP/IP to communicate between the QNX central server and the operator workstations while simultaneously using the QNX FLEET transport for realtime messaging between the communications servers and the central server. (For the other critical messaging component, between the traffic signal controllers and the communications servers, we use an internally developed, ultra-lightweight protocol called TRAP, or Traffic Application Protocol).

Distributed data management objects
Our engineers created a reusable object for caching and distributing realtime information at different nodes in the system. The object's interprocess communication is based on System V message queues, using QNX's message passing, and is used as a memory management facility. On the NT-based operator workstations, we replaced QNX message passing with Win 32 named pipes. A typical deployment is on the communications server where certain data must be stored temporarily until it is flushed to the Velocis database on the central server. This mechanism resembles a kind of database, but the key difference is that while Velocis manages persistent information, the data in the distributed objects is never stored to disk.

The key benefit of this component is its transparency to system developers. It hid3es the geographical distribution of system components so that for programmers, all processes are represented as if they"re running on the same PC.

Tight schedule

We began development on the UTCS system in early 1999, and deployment took place in the fall. We were confident we could make this tight deadline, though, because we"ve used QNX to implement communications structures before. As we progress, we are even more impressed by the QNX operating system"s support for realtime, asynchronous control. Asynchronous control is critical in an application such as this, where there are many small programs running concurrently and telling different drivers what to do. Realtime performance is important because the application must be able to manage a large number of communications channels - some 70 in all - each handling about 30 intersections.

QNX's and Velocis' efficient use of computing resources, along with the UTCS system's distributed nature, allow our clients to save money on hardware. For instance, the central server, communications servers, and operator workstations all run on Pentium PCs. Since communications processing is spread between three servers, the minimum horsepower required for each is a modest 32M of RAM with a 500M hard drive. The central server requires a Pentium with at least 128M of RAM and a 6G hard drive.

Lighting the way
The new system is light years away from Vancouver's old traffic control system, which ran on a Perkin-Elmer mini that had reached its expansion limits. The new application will make it possible for planners to automate and streamline many management functions. For example, with the old system, traffic engineers had to download new timing plans individually to each traffic signal controller. With the new system, the entire download can be accomplished with one batch. In addition, the system moves away from the second-by-second control mode in which the signal controllers relied on continuous interaction with the central computer. With improvements in technology, more processing capacity is available at the intersection. The result is that controllers can operate independently, and with complete functionality, even if disconnected for a time from the central server.

The new system's links to office applications will allow reports to be generated on short notice, which in turn will enable politicians, planners, and other end-users of system data to respond more quickly to public concerns.

While modern traffic control systems can't make up for older streets and highways that are inadequate for current traffic flow, they can maximize the efficiency of existing infrastructure. Systems like UTCS can make an important difference in improving a region"s traffic situation - less stop and go, and more convenient, efficient, and safe driving for all.