Telecommunications infrastructure is important in enabling Intelligent Transportation Systems (ITS) to function, as it ties together and moves data between the major elements of an ITS, including roadside equipment, vehicles, the vehicle operator and central operations facilities (such as transportation management centers). Through integrating the individual elements of an ITS, telecommunications provides a critical technical function to the system, and can act as a mechanism for enhancing overall transportation efficiency. Telecommunications also comprises a significant share of the cost of an ITS, both in terms of implementation and operations and maintenance.
Arriving at the telecommunications solution that best suits agencies' needs is a high priority, but it can be a challenge. This is largely due to the rapid pace of change in telecommunications and the skills required to understand and assess different telecommunications alternatives. This report is designed to provide assistance on what processes work best and what factors should be considered when making telecommunications decisions. A number of the best techniques for exploring telecommunications alternatives are presented to help agencies determine the optimal alternative in support of their ITS program.
For this study, the telecommunications experiences of state Departments of Transportation (DOTs) and agencies from across the country were examined. In particular, examples of successful practices in ITS telecommunications were drawn from California, Georgia, Maryland, Michigan, Minnesota, Missouri, New York, Texas, Virginia, and Wisconsin.
Many factors must be considered in deciding upon the right telecommunications solution for an ITS Program, and a requirements analysis is an effective tool for outlining these factors. A requirements analysis is a hierarchical, iterative process for deriving and describing the full set of needs to be satisfied by a product, system or service provider. The selection of the most appropriate telecommunications solution depends on the identification of the full set of requirements.
In conducting a rigorous requirements definition process for the Chesapeake Highway Advisories Routing Traffic (CHART) program, the Maryland State Highway Administration reasoned that it could not develop an efficient network for CHART without knowledge of why it was needed, who would be served, and how it would be used. This information enabled Maryland SHA to identify the appropriate technical characteristics of the telecommunications system, including data, video, and voice traffic.
By describing five key steps for performing a requirements analysis, there are lessons for anyone looking to begin the process of selecting their system:
- Identify ITS Program Goals, Objectives, and Requirements. Since the telecommunication is intended to support an ITS, the first step in developing the requirements is the formulation of ITS goals and objectives by the ITS stakeholders. In many cases these have been previously defined in earlier project documents. These goals and objectives serve as the bases for the derivation of high-level or generalized requirements, which can then be decomposed further into lower-level technical requirements.
- Derive Technical Requirements. The requirements analysis should include the following three types of technical requirements: functional, operational and performance.
- Functional requirements identify what is to be done. For example, a functional requirement is that the network must carry incident information from the traffic management system to the traveler information system.
- Operational requirements identify who or what performs the function, where the function is performed, how many perform the function and when it is performed.
- Performance requirements quantify performance measures such as how much, how often or how fast.
The requirements must be written in terms that telecommunications engineers can use to derive technical architectures, including components such as video, data, voice, local area network (LAN), reliability, maintainability and availability (RAM), and security. Examples of detailed requirements are device message sizes and formats, frequency of transmission, polling interval for low speed devices, image and motion quality, transmission delay, number of simultaneously viewable images, and camera selection and control constraints for CCTV.
- Document Requirements. Each program-level and derived telecommunication requirement should be assigned to the appropriate requirement type and each should be assigned a unique identifier. Each requirement statement should be as concise as possible, and can be subdivided into two or more clearly identified parts.
- Validate Requirements. Upon identifying the set of requirements, it is necessary to review the complete list for inconsistencies, conflicts, and gaps and to check that each of the requirements is measurable. The requirements are then presented to the stakeholders (initially in writing and then in a group working session). It is important for someone at each stakeholder organization to indicate approval and to "take ownership" of the requirements. Reaching consensus on the requirements, both within and across stakeholder groups is likely to require multiple meetings. Reaching consensus will be facilitated if each stakeholder organization gives an individual the authority to speak for, and act on behalf of, the organization.
- Manage Requirements. The requirements analysis is a "living" document and should be carefully managed. Any changes to the document must be logged and described, and can only be made after formal review and approval by a configuration control board representing the interests of the stakeholder groups.
The requirements analysis provides the technical basis for identifying the appropriate telecommunications solution for an ITS project. In defining technical requirements, Maryland SHA was able to minimize two key risks: 1) that the agency would build a network that would not meet its needs, and 2) that the agency would build a network that would be costly to change or redesign in order to take advantage of technology improvements. By understanding and documenting its requirements, particularly by identifying who needed access to the information and how much bandwidth was required to provide acceptable access, Maryland SHA could build a network that adequately addressed its needs.
(Our website has many links to other organizations. While we offer these electronic linkages for your convenience in accessing transportation-related information, please be aware that when you exit our website, the privacy and accessibility policies stated on our website may not be the same as that on other websites.)