U.S. Department of Transportation
Federal Highway Administration
1200 New Jersey Avenue, SE
Washington, DC 20590
202-366-4000
California Division
OBJECTIVE: 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:
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:
§ 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.