Making Sense of Its Standards

Over the course of his traffic engineering career, Ken Vaughn, president of Trevilon Corp., Oak Hill, Va., has drawn on his ITS experiences which range from coordinating traffic signals to being involved with ITS protocol efforts, each of which he addressed the same goal-improving transportation operations.

Currently, Vaughn is involved in one of the more complex issues facing the ITS industry today-standardization.

In this installment of Industry Interview, Transportation Management + Engineering asks Vaughn to help explain the complexities associated with and to help make sense of the ITS standardization plight faced by North American transportation engineers.

For those TM+E readers who may not be familiar with you, what is your background in intelligent transportation systems?

I've been fortunate enough to have the opportunity to work on a variety of ITS projects with many of the industry's leading experts.

My interest started with a fortunate combination of experiences during my time at Tulane University. Our traffic engineering course was taught by the traffic engineer for Jefferson Parish, Doug Robert. His course provided a practical, real-world view to traffic engineering while the general course load at Tulane included a solid grounding in computer technologies that exceeded most other schools at the time.

After graduation, I went to work for Los Angeles County where I gained public-sector experience and worked on a project to coordinate 800 traffic signals across the county. The project introduced me to a wide variety of real-world technical, legal, political, and financial issues that face jurisdictions. 

I followed this valuable field experience with more formal education at Texas A&M. This provided me with the resources to further research signal timing under the guidance of Carroll Messer and Edmond Chang, air quality impacts of ITS under the mentoring of Ed Rowe, and traffic flow theory under the sponsorship of Tom Urbanik.

After I received my Master's Degree, I was fortunate enough to obtain a position with PB Farradyne and work directly with Phil Tarnoff and Roy Sumner on several state-of-the-art deployments, including the Atlanta ATMS project and the TravelAid weather warning system for Washington State DOT. Towards the end of my stay at Farradyne, I became involved with the National Transportation Communications for ITS Protocol (NTCIP) effort. While this effort was solely focused on signal controllers at the time, I worked with the FHWA and the I-95 Corridor Coalition to quickly begin extending the standard to cover other ITS devices, such as message signs and road/weather stations.

My involvement with the NTCIP expanded as I moved to Iteris, Inc. where I managed the development of the NTCIP Exerciser and worked with the Virginia DOT in their efforts to procure and test message signs and weather stations. The output of the Virginia DOT work fed into our work with ENTERPRISE (www.enterprise.prog.org) to develop a procurement guide for NTCIP equipment as well as NTCIP test procedures that could be used on any project. I later worked with Rick Denney to refine the procurement guide into a software tool, known as the SpecWizard, which has recently become one of the cornerstones of the FHWA outreach efforts in assisting agencies to develop NTCIP procurement specifications.

In 2000, I started my own firm with the goal of advancing the ITS Standards efforts through consulting services and tool development. As a result of our efforts, Trevilon has developed testing software for ITS Standards called Ntester, which is available for free at (www.trevilon.com). We also developed a complimentary product, FTS for NTCIP, which captures data being sent over a communications circuit and decodes it according to the NTCIP or other major protocols.

It's evident that everyone who is involved in ITS defines this segment of the transportation industry differently. How do you define ITS?

My background as a traffic engineer makes me favor a broad definition of ITS. I view ITS as any set of tools involving electronic systems designed to automate data collection, data analysis, device control, or information sharing in order to improve transportation operations. As a traffic engineer, that is all I really care about-improving transportation operations.

Using this definition, an actuated traffic signal would be considered ITS because it uses remote sensors to detect vehicles and then modifies timing parameters in order to improve transportation operations. The fact that the technology predates the "ITS" industry by better than 50 years does not negate the fact that it still meets the basic definition of what an ITS system is.

However, my view is also supported by my on-the-job training as a systems engineer. From this perspective, I believe it is important to recognize any transportation project that involves electronic systems as an ITS project. This is because the project necessarily involves a variety of technologies in which many transportation engineers have not had any training and in order to ensure a successful project, a systems engineering process should be followed. The failure of many signal system projects can be directly attributed to the lack of any systems engineering process guiding the development/deployment efforts.

What are ITS standards and how do they work?

"ITS Standards" usually means those standards that have been or are being developed as a part of the US DOT's ITS Standards Program in order to standardize the communication interfaces of the National ITS Architecture. In some contexts it can also refer to any standard used by an ITS deployment, for example, the Internet Protocol, or hardware standards related to ITS, such as the advanced traffic controller.

There are several 100+ page guide documents that attempt to provide a basic explanation of how they work (e.g., the NTCIP Guide available from www.ntcip.org).

All of the "ITS Standards" use a concept of a modular communications stack. In other words, rather than defining how each piece of transportation information is encoded into a data packet represented by a series of one's and zero's, there are a series of standards, each responsible for defining one aspect of how to exchange information. Within the NTCIP effort, this is broken into four distinct levels. At the lowest level (NTCIP 2100 series standards), we define how a message is sent across a given communications link while preventing bit-errors. At the next level (NTCIP 2200 series) we define how the message can then be routed through a series of intermediate devices. The third level (NTCIP 2300 series) defines how the message is structured such that one application can talk to the corresponding application in the other machine. The final level (NTCIP 1200 series) is the definition of the transportation information of interest. Most of the other (non-NTCIP) ITS standards are at this highest level and define transportation-specific information for center-to-center communications and would use the remainder of the NTCIP stack for exchanging the data. However, some efforts have had to define their own stacks in order to meet their unique needs (e.g., dedicated short range communications).

How did you become involved in working with ITS standards?

By 1994 I had considerable experience in working with a variety of traffic signal control algorithms as well as designing protocols for the in-vehicle units used in TravelAid. This made me a natural selection to monitor the National Electrical Manufacturers Association's (NEMA's) NTCIP development efforts to ensure that its design would be flexible enough to support future signal control algorithms, such as those being included in the RT-TRACS program.

Once I began monitoring the efforts, a few of us realized that the NTCIP could be applied to devices well beyond signal controllers. After working with the FHWA and various industry leaders, we established a Steering Group and I was tasked with the effort to extend the NTCIP to message signs. By 1996, the ITS Standards Program was in full swing and the Steering Group had transformed into the Joint Committee. As the very first standards were reaching completion, I was tasked with extending the effort to Road/Weather Information Systems as well as developing the NTCIP Exerciser.

As the standards efforts progressed, I was asked to coordinate various efforts, including center-to-center communications, Traffic Management Data Dictionary, Incident Management, Transit Communications Interface Profiles, etc.  Likewise, as the standards began to be finalized, I was called upon to assist in training efforts and deployment support.

Currently, what areas of ITS tend to be most in need of standards implementation?

While personal opinions vary greatly among engineers, I believe that the areas of most need are the interfaces between the center subsystems of the National ITS Architecture.

In order to realize the full potential of ITS, we must be able to share communications between different organizations in real-time; however, this effort is hindered by the complex nature of the data.  The information that we exchange often deals with very abstract concepts such as congestion, accidents, and locations. The way in which these concepts are represented in existing systems is widely varied due to the distinct ways in which the information is used. In order to develop robust standards, we must be able to harmonize all of these different views and develop a single way to present the information. This is a much more challenging task then developing a standard interface for a field device where the functionality of the device is well understood. This is why such a huge need has developed for center-to-center standards without being previously solved.

Where does the U.S. stand in regards to ITS standards deployment?

The US is well underway in the deployment of several standards, most notably those for message signs and weather stations. However, we still have a long way to go. While we are extending standards to many new devices and interfaces, we are also monitoring the deployments of existing standards and determining how we can solve the problems that have been identified in order to make the standards even more robust. As a result, in the next year, the industry will begin to see the second generation of standards become available.

What role do you play in defining ITS standards?

I am one of the many technical experts in the industry that are assisting in the development of the ITS Standards. Specifically, I bring the perspective of a traffic engineer, through my formal training and early experience, a systems integrator, through my involvement in various integration projects, and a liaison among many of the various efforts. In several cases, I have also acted as the chair of a working group and/or the primary editor of a standard. However, there are many other valuable views brought to the table by other participants. These include the public sector members who are able to clearly indicate what today's real-world needs are, the systems integrators who are able to identify the technical challenges in interoperating with multiple manufacturers and/or devices, and device manufacturers who are able to bring unparalleled expertise regarding the practical implementation issues involved in such deployments. It is precisely this combination of views that make ITS Standards robust.

Are you involved in the Standards Development Organizations, if so, what do these Organizations do for ITS standards?

The standards development organizations provide the legal and administrative structure necessary to develop and maintain an industry standard. From a legal perspective, these organizations must ensure that the committee structure remains open, balanced and representative of the various stakeholders such that all are able to voice their concerns.

The Standards Development Organizations are also responsible for the administrative aspects of guiding the standards through the process. This entails sending the draft standards out to User Comment at specific stages of the process, logging all comments received, recording ballots at various stages of the process, resolving any negative ballots, and then maintaining the standards, typically on a five-year cycle. And of course, there are version control issues and the paperwork required with documenting the process followed.

While I am not directly involved in the Standards Development Organizations as a staff member, when I act as chair, I inherit some of these responsibilities and coordinate closely with the staff of the organizations.

In regards to ITS standards, what are some of the problems being addressed?

The initial version of any standard is likely to have some rough spots around the edges. The extent to which these exist varies by standard and is generally related to how complex the standard is and how well the functionality of the interface is known. Thus, the center-to-center standards tend to have more problems than the center-to-field standards. However, these are largely technical issues that can and will be solved with time. From a practical perspective, several standards, e.g., message signs and weather stations, are already demonstrating the benefits offered through standardization, but even here there is room for improvement such as adding new features.

However, perhaps the biggest challenge facing the ITS Standards community is in providing the necessary outreach, knowledge transfer, and technical assistance to the agencies that are procuring systems. Many of these agencies have little experience in dealing with Information Technology projects and have difficulty in procuring and managing such projects.

In order to address this issue, the FHWA is undertaking extensive efforts to provide training and procurement workshops (www.its-standards.net/train.htm), and technical assistance (www.its-standards.net/Deploy.htm).

Another challenge that the industry is facing is the establishment of well recognized processes for validating and verifying (e.g., testing) their ITS components for conformance to the standards. Many agencies have ignored testing to date due to the complexities involved in the process; however, in order to minimize problems in the future, it is critical to properly test the devices as they are deployed so that any areas of non-compliance can be corrected while the vendor is still under contract. One of my reasons for starting up Trevilon was to improve the availability of services in the area.

What type of impact may these problems have on the National ITS Architecture?

For the most part, the standards are consistent with the National ITS Architecture, but they are at a much finer grain of detail. As a result some of the details regarding how the various subsystems link together have been refined by the standards process and the National ITS Architecture is being periodically updated to reflect this as-built design. But from the big picture view, these are relatively minor issues and their impact on real-world deployments will be minor or nil.

Why should a transportation engineer incorporate ITS standards into their infrastructure?

I think at this point most agencies have realized the benefits that ITS offers, be it coordinated signals or something more advanced. In our cities, congestion is likely to worsen in the future and ITS has demonstrated that it can assist in the managing the challenges that accompany such congestion with relatively low costs. In order for the agencies to take advantage of the benefits that ITS offers, the various ITS components must be interoperable and maintainable.  Thus, assuming an agency wishes to use ITS, they are faced with the issue of whether to use customized solutions or industry standards. 

Industry standards provide many benefits over customized solutions, including:

(1) The ability to share communications infrastructure among different types of devices when the various devices use the same lower layer standards; this is critical when you consider that the cost of the communications infrastructure is frequently well over 50% of the cost of an ITS project;

(2) Decreased long-term software costs due to vendors using the same software version for all clients rather than having to develop customized solutions for specific clients;

(3) Better software reliability due to the fact that each vendor would have only one version and thereby any bugs in the software will be discovered and solved more quickly;

(4) Less risk for the agency due to the fact that most deployments will be deployments of previously proven software; and

(5) Better long-term migration plans to incorporate new features, solve problems, or switch vendors because the entire industry will be faced with the same conversion process.

As a result, there will likely be off-the-shelf upgrade solutions to assist users to migrate from one version of the standard to the next; but if an agency used a customized solution, they will be burdened with the entire cost to develop a new customized solution (or the cost to then migrate to the standard).

Thus, in my mind it is not so much a question of whether the industry will migrate to standards, but when will the industry migrate?

The answer to this question has to be provided by the public agencies themselves because in reality there are costs related with migrating to standards-and the ultimate source of all funds in the industry is the public sector. The costs include:

(1) Design - i.e., development of the standards;

(2) Documentation - i.e., providing sufficient materials to explain the standard to others including issues such as how to write procurement specifications;

(3) Development - i.e., the manufacturers and system integrators implementing the standard;

(4) Testing - i.e., some defined process to ensure that the delivered components work according to the design; and

(5) Some performance degradation - i.e., a standard meeting everyone's requirements will never be as efficient as a customized solution that meets only one user's requirements.

This degradation could be in the form of higher bandwidth requirements, higher processing requirements, or even the loss of some set of features. For example, a particular version of a standard may not support a feature due to simple omission or because there was insufficient demand within the industry to add it.

It is this last item that really ends up driving the decision. The first four points should be performed for a customized solution, and if they are not performed, future integration projects will have significantly higher costs. Thus, the first four items represent costs that must be incurred anyway over time; using a standard may result in realizing a higher percentage of these costs in the near-term but a lower life-cycle cost.

The fifth issue is more significant and poses the real question to the industry: Do the life-cycle benefits of the currently proposed standards outweigh the costs related to performance degradation? I think the early deployments have indicated that they certainly do (or shortly will) for many devices including message signs and weather stations. For other devices, such as signal controllers, I think the answer currently varies based on the specific needs of a given agency. However, I think the momentum is already on the side of the standards effort; and as the standards community is better able to gauge the real-world needs of the users, we will be able to enhance the standards to address these needs.