U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590

Skip to content
Facebook iconYouTube iconTwitter iconFlickr iconLinkedInInstagram

California Division

Home / About / Field Offices / California Division / Systems Engineering Guidebook for ITS

Home What's New Systems Engineering Guidebook Views Search Glossary Resources Feedback Site Map

4.5 Relationship to ITS Standards



This chapter identifies the relationship between this Guidebook and ITS standards. The focus of this chapter is on identifying key systems engineering process standards and other related ITS standards. This chapter will briefly discuss evolving ITS protocol and equipment standards.

Why Use ITS Standards?

Don't reinvent the wheel: Use of equipment standards [Dynamic Message Sign, for instance] mean that requirements will not need to be developed from scratch. However, be aware that equipment standards may not keep up with advances in technology.

Avoid early obsolescence: By gradually migrating field devices to ITS standards compliant devices the system will be moving in the direction the industry is going.

Obtain a choice of vendor: Products conforming to an ITS standard can be inter-changeable with products from other vendors. However, inter-changeability is hindered by vendor specific features that go beyond the standard, or by partial implementation of a standard.

Multi-point control of devices are going in the direction of IP-based networks. Not only will this put all devices on a single network; any center on the network can access and control any device. This allows the centers to back up each other in case of failure or operational downtime.

Potential Benefits of Standards to Systems Engineering Processes

If a system is being developed that has components covered by mature ITS standards and the existing ITS standard supports your operational concept; then, the use of ITS standards can be of considerable benefit to many [if not most] of the systems engineering processes described in this Guidebook. Obvious examples include:

  • High Level Design and Component Level Detailed Design: If an ITS standard [example: a Dynamic Message Sign] can support your requirements, then use of such a standard eases the design tasks and allows the use of predefined proven components
  • Hardware/Software Development: Use of ITS standard components such as the use of any off-the-shelf product, will reduce the design effort
  • Integration and Verification: If the chosen ITS standards are mature, then both integration and verification efforts will be easier. On the other hand, if the ITS standard is not mature, or has not been used before, the effort to prove the product matches the standard can be difficult
  • Risk Management: Use of a proven product built to a mature ITS standard will reduce development risk in a project
  • Procurement Options: Use of ITS standards will make it easier to specify the product needed for the project and allow multiple vendors to compete to provide the same standard product
  • Standards are widespread in the transportation industry and are generally developed for one of two reasons: to improve interoperability or to stimulate competition. For ITS, a primary emphasis of the standards being developed is on the interoperability of systems and the interchangeability of sub-systems and components. This leads to easier system integration and smoother coordination among systems

What does FHWA Final Rule [23 CFR 940.11] say about the use of ITS Standards?

FHWA Final Rule [23 CFR 940.11] requires that "All ITS projects funded with highway trust funds shall use applicable ITS standards and interoperability tests that have been officially adopted through rulemaking by the DOT." As of the date of this writing, while the DOT recommends judicious use of the available standards, none of them have been officially adopted through rulemaking. The FHWA Final Rule also expects the regional ITS architecture to identify ITS standards supporting regional and national interoperability. The Final Rule expects consistency between the regional ITS architecture and any related projects.

NTCIP Standards Development

One ITS standards effort is being conducted by the National Transportation Communication for ITS Protocol, or NTCIP. These standards identify protocols and message sets to be used Center to Center, Center to Roadside, and Vehicle to Roadside. It is a joint standardization project of the American Association of State Highway and Transportation Officials [AASHTO], the Institute of Transportation Engineers [ITE], and the National Electrical Manufacturers Association [NEMA], with funding from the U.S. Department of Transportation [USDOT].

[See NTCIP 9001 National Transportation Communications for ITS Protocol – NTCIP Guide Version 3 at Website http://www.ntcip.org ]

Other ITS Standards Activity

Standards development organizations at the national level that are working on ITS standards also include:

American National Standards Institute [ANSI], http://www.ansi.org [general communications]

American Society for Testing & Materials [ASTM], http://www.astm.org [Vehicle to Roadside]

Institute of Electrical and Electronics Engineers [IEEE], http://www.standards.ieee.org [Center to Center transit and incident management]

Society of Automotive Engineers [SAE], http://www.sae.org/topics/itsinits.cfm [Center to Center and Vehicle to Roadside]

Documentation and Process Standards Activity

Another area of standard development that is of use to the systems engineer involves documentation standards and systems engineering process standards. Systems engineering document and process standards offer the systems engineer good advice in the following areas:

Systems Engineering Process

Institute of Electrical and Electronics Engineers, IEEE Std. 1220-1998 IEEE Standard for Application and Management of the Systems Engineering Process

Electronics Industries Alliance, EIA 632 Standard Processes for Engineering a System

Concept of Operations Document [see Chapter 3.4.3]

IEEE 1362 IEEE Guide for Information Technology – System Definition – Concept of Operations Document

Concept of Operations Document [see Chapter 3.4.3]

American National Standards Institute / American Institute of Aeronautics and Astronautics, ANSI / AIAA G-043-1992 Guide for the Preparation of Operational Concepts Documents

Requirements Specifications [see Ch. 3.5.1]

IEEE STD 1233 IEEE Guide for Developing System Requirements Specifications

Configuration Management [see Ch. 3.9.6]

EIA 649 National Consensus Standard for Configuration Management

Technical Reviews and Audits [see Ch. 3.9.10]

IEEE 1028-1988 Standard for Software Reviews and Audits

Software Architecture Design [see Ch. 3.5.2 and 3.5.3]

IEEE 1471-2000 Recommended Practice for Architectural Description of Software-Intensive Systems

Independent Verification and Validation [see Ch. 3.6.3 and 3.7.1]

IEEE 1012-1998 Standard for Software Verification and Validation

System Modeling Standards Activity

Over the years there have been many attempts to develop modeling approaches to help with system and software design, including:

  • Unified Modeling Language [UML] – This is a language for specifying, visualizing, constructing, and documenting the design of software. The standard for UML is maintained by the Object Management Group. Information on UML is available at their web site, http://www.omg.org.

§  Integrated Method for Information Modeling [IDEF] – Another method for modeling processes is called IDEF. This technique is used in the Guidebook to model the processes described in Part 4. Information on IDEF can be found at http://www.idef.com.


Return to top
Page last modified on September 20, 2016
Federal Highway Administration | 1200 New Jersey Avenue, SE | Washington, DC 20590 | 202-366-4000