Frequently Asked Questions
General Questions
FTA
ITS Projects
Regional Architecture Development
Standards
Systems Engineering
Training and Technical Assistance
General Questions
Q: Why did the USDOT issue this Rule?
A: This Rule specifies how to implement language in the Transportation Equity Act for the 21 st Century (TEA-21), requiring that ITS projects conform to the National ITS Architecture and Standards. This Rule establishes a process for implementing the legislation through the existing planning and project development processes. The Final Rule requirements can be found in 23 CFR 940.
Go to top of the page.
Q: Does this Rule introduce new or unproven concepts?
A: Many locations have been developing system architectures to guide the implementation of ITS in their areas because of the effective transportation planning benefits the development process provides. These early examples were instrumental in developing this Rule by providing proven approaches and validating the proposed concepts. So while for particular locations these concepts may be new, they are based upon successful, proven approaches.
Go to top of the page.
Q: Who at the USDOT has the role/responsibilities of making the conformity determination?
A: The FHWA Division or FTA Regional office has the primary role in determining whether a project complies (or where there is limited direct oversight, whether a recipient of Highway Trust Fund monies has established procedures to ensure compliance) with the requirements of the ITS Architecture and Standards Rule/Policy. The FHWA Resource Centers and FHWA/FTA Headquarters are available to the Division and Regional offices for technical assistance in reviewing procedures or materials for compliance.
Go to top of the page.
Q: When do I have to comply with this Rule?
A: The project development requirements take effect April 8, 2001 . Regions that have deployed ITS have until April 8, 2005 to develop and document their Regional ITS architecture. Regions that have not yet deployed ITS will have four years from the date their first ITS project advances to final design. It is recommended that State and local agencies work with their FHWA and FTA field offices to determine the best schedule for implementation.
Go to top of the page.
Q: What will be the consequence of non-conformity with the Final Rule (23 CFR 940)?
A: Federal funds from the Highway Trust Fund, including the Mass Transit Account, will be withheld for ITS projects.
Go to top of the page.
Q: How can I find out more about the ITS Architecture and Standards Final Rule?
A: All information as it becomes available will be posted on the FHWA Office of Operations website at https://ops.fhwa.dot.gov/its_arch_imp/index.htm.
Go to top of the page.
Q: How can I find out more about the National ITS Architecture?
A: Check out the architecture web site at http://www.iteris.com/itsarch/. The USDOT also provides training classes on use of the National
ITS Architecture. Training is available through your FHWA
Division Office or FTA
Regional Office.
Go to top of the page.
FTA
Q: Why are there an FHWA Rule and an FTA Policy and how are they different?
A: The FTA and FHWA have different processes and procedures for project development. Therefore, the FHWA has issued a Regulation, and FTA has issued a Policy. The policy language in each document is consistent and will be carried out in a coordinated fashion, as applicable under FTA and FHWA project management and oversight procedures.
Go to top of the page.
ITS Projects
Q: What is an ITS project?
A: An ITS project, as spelled out in the Final Rule, is any project in whole or in part that funds the acquisition of technologies or systems of technologies, that provide or significantly contribute to the provision of one or more ITS user services as defined in the National ITS Architecture. In other words, an ITS project is any project that may provide an opportunity for integration at any point during its life.
Go to top of the page.
Q: To which federally funded projects does this Rule apply?
A: This Rule applies to any ITS project receiving funding in whole or in part from the Highway Trust Fund, including the Mass Transit Account.
Go to top of the page.
Q: Does this Rule or the National ITS Architecture tell me which technology to buy?
A: No. Using the National ITS Architecture helps define requirements for what the technology should do to ensure information exchange and interface compatibility. Use of specific technology is not required.
Go to top of the page.
Q: Do I have to replace all my existing equipment to conform with the National ITS Architecture?
A: No. The proposed Rule does not require replacement of existing systems or equipment. Applicable ITS standards would be used as new features and system upgrades are planned with the use of the National ITS Architecture.
Go to top of the page.
Q: Is the USDOT mandating a particular system design?
A: No. The USDOT is mandating that states and regions follow a process of systems engineering, use USDOT adopted standards, and work with all relevant stakeholders in their area. The outcome of the process is a regional ITS architecture, which guides system design. The National ITS Architecture supports a variety of system designs and is flexible enough to support both distributed and centralized systems.
Go to top of the page.
Q: How should agencies deal with work zones that use temporary ITS for traffic control on projects without ITS (i.e. pavement reconstruction)? Will project architectures be needed for these types of projects?
A: Project level ITS architectures are only required for major ITS projects until a regional ITS architecture is developed. If the ITS project being implemented as part of a construction effort meets the requirements for regional integration or major regional initiative, then it will need a project level ITS architecture. From a practical point of view, ITS activities related to construction projects may become permanent installations, and as such, should be examined for fitting into the larger regional ITS perspective. If a regional ITS architecture exists, incorporating ITS elements into a construction project may be a method of implementing elements identified in the regional ITS architecture in a more efficient manner than using separate ITS projects after the construction activities. A regional ITS architecture would allow an area to have this "vision" and be able to identify these opportunities.
Go to top of the page.
Q: Do small urban area systems owned by local agencies need to conform to the Final Rule?
A: Yes, if the region had ITS deployed on April 2001, or if a region wants to spend Federal funds on ITS projects. Generally, for small areas, if it has a computerized signal system, or AVL or DMSs, then they have ITS and must have a regional ITS architecture by April 8, 2005 . If a region does NOT currently have any ITS, it will need to create a regional ITS architecture when it advances it's first ITS project for Federal funding.
Go to top of the page.
Q: What is a major ITS project?
A: Any ITS Project that affects regional integration of ITS systems. This terminology is relevant only for projects advancing to final design during the development of the Regional ITS Architecture.
Go to top of the page.
Q: What are some examples of major ITS projects?
A: Some examples include various transportation operations centers such as a traffic management center or transit management center; a major new integrated traffic signal system; an automatic vehicle location system for a large transit fleet; a traveler information service; or a freeway surveillance and control system.
Go to top of the page.
Q: Is any single traffic signal upgrade project an "ITS project"?
A: FHWA anticipates this will probably be the most difficult judgment regarding ITS projects that will have to be made. There are so many variations on how and when traffic signals were installed, that the answer may be yes or no. This decision must be made at the FHWA Division office level with considerable input from the affected State and local agencies. As a Rule of thumb, consider the following:
If the project entails upgrading a majority of the signals in a system or in a geographic area, then yes, it's an ITS Project. For instance, upgrading the hardware of 200 of 250 intersections would probably count as an ITS project. But so would upgrading 1 of 3 intersections, if that is all you have in your town. Consider asking yourself, "what is the percentage of the total intersections being upgraded?" If the answer is a high percentage, then it probably is an ITS project.
It should be noted that the systems engineering (SE) process must be applied to all ITS projects or projects with ITS elements. However, as each of the steps in the SE process is applied, it is likely that only a few details will need to be addressed on most projects and quite often, standards will probably be the only step considered in detail. The real test is experience. Consider the scope of the project and use good judgment as to whether it should be considered an ITS project or not.
Go to top of the page.
Q: How will agencies address projects already in the "pipeline?"
A: The Rule/Policy does not apply to projects that reached final design by April 8, 2001 . For other ITS projects, activities related to the Rule/Policy will likely depend upon what stage of development the projects have reached. During the regional ITS architecture development, major ITS projects will have to satisfy the requirements for a project level ITS architecture which will require examining them for integration opportunities per the National ITS Architecture. Other ITS projects should be reviewed to see if there may be some additional opportunities for linking with other regional efforts or engaging other stakeholder groups. It may be unpractical to alter a project's design because of the maturity of the design or other factors. However, opening the project up for reexamination may reveal ways for improving a project's implementation with additional resources or broader acceptance by stakeholders.
Go to top of the page.
Q: I'm just planning one ITS project for my region. Do I have to develop a regional ITS architecture? If so, when?
A: As stated in section 940.9(c) of the FHWA Rule and section V(c) of the FTA Policy, once an area advances its first ITS project to final design it must develop a regional ITS architecture within four years of that date. If there truly are no other ITS projects planned for addressing the transportation needs in a region, then practically speaking, whatever project level architecture is developed for that lone ITS project is the region's ITS architecture. It should be recognized and documented as such so that, if at some time in the future, the region does consider further ITS deployment, the regional ITS architecture will be updated reflect the new ITS projects. This can be accomplished by updating of the regional ITS architecture as provided in section 940.11(d) of the Rule or section VI(d) of the FTA Policy.
Go to top of the page.
Q: For ITS projects that don't use Highway Trust Funds, how should these be identified as opportunities for integration?
A: The Rule/Policy does not apply to ITS projects that are not funded by the Highway Trust Fund. However, in order for a regional ITS architecture to be the most useful, it should contain all ITS activities and projects in a region. The stakeholders need to decide how the documentation that is developed as part of the regional ITS architecture should indicate projects that are funded outside of the Highway Trust Fund, and to what level of detail may be appropriate so that the integration opportunities can best be identified.
Go to top of the page.
Q: How are earmarks treated under the Final Rule? Does the regional ITS architecture need to be updated for earmark projects (ITS integration projects)? Do earmark projects need to be in the regional ITS architecture? Do they need to follow a systems engineering process?
A: By definition, earmark projects are integration projects, so they must meet the requirements of the Final Rule, i.e. must follow a systems engineering process and be reflected in a regional ITS architecture. Per the earmark guidance package, earmark funds can be used to develop a regional ITS architecture if there isn't one in the region already. Whether or not a regional ITS architecture is updated because of an earmark project, is up to the region. In other words, just because there is an earmark doesn't mean a region MUST update their regional ITS architecture at that time. However, if an earmark project will have a significant impact on the ITS systems in a region, or involves a large number of stakeholders, then that may a reason to update the regional ITS architecture.
Go to top of the page.
Q: What is the relationship of projects with Homeland Security funding to the regional ITS architecture?
A: The Final Rule applies to ITS projects that are funded in part or in whole with the Highway Trust Fund, including the Mass Transit Account. Therefore, ITS projects that are funded with Homeland Security funding, or any other Federal funds, don't need to be part of the regional ITS architecture. However, much like ITS projects that are fully funded with State and local money, if they are part of the transportation system and will have an impact on the region, it is strongly encouraged to include them all in the regional ITS architecture.
Go to top of the page.
Q: What is a project level architecture? How and when is it developed in the planning process?
A: Until a region has a regional ITS architecture in place, any major ITS projects that are advanced in that region require the development of a project level architecture. This project level architecture focuses on the possible information exchanges between the ITS system(s) being planned as part of the project with other known existing or planned systems in the region.
Go to top of the page.
Regional Architecture Development
Q: What is a regional ITS architecture?
A: A regional ITS architecture is a tailored version of the National ITS Architecture, including only the subsystems and functions that are planned for implementation in the local area or state.
Go to top of the page.
Q: What is a region? How are the boundaries determined? Is there a minimum size?
A: The defining parameter in determining what constitutes a region is the availability of integration opportunities for existing or planned ITS systems amongst and between stakeholders. Sometimes this might constitute a governmental boundary (i.e. a county or state), an agency boundary (i.e. an MPO region), or a service boundary (i.e. a transit service area). The Final Rule states that, in metropolitan areas, the metropolitan planning area be considered (but not required) as a minimum size for a region. The ultimate decision must be made by the participating agencies and stakeholders, but should be based on the desired integration of ITS systems in those jurisdictions.
Go to top of the page.
Q: Who is responsible for developing regional ITS architectures?
A: The proposed Rule provides flexibility to local areas in determining what agencies or organizations develop the regional ITS architecture. However, because of the linkages to existing planning processes, the states and metropolitan planning organizations are ultimately responsible for ensuring that the proposed Rule's conditions are met for using federal funds.
Go to top of the page.
Q: How much does developing a regional ITS architecture cost?
A: The benefits of reduced retrofit and upgrade expenses should outweigh the costs of doing a regional ITS architecture. Before this Rule was issued, many local areas were already developing regional ITS architectures because of the benefits to effective transportation planning and project development. As a rough estimate, it would probably cost about $300,000-$500,000 to develop a regional ITS architecture and strategic deployment plan for a large metropolitan area. For a small urban area, a regional ITS architecture and strategic deployment plan can be roughly estimated at $100,000 to $200,000.
Go to top of the page.
Q: What do the taxpayers get for spending money on a regional ITS architecture?
A: More efficient intelligent transportation systems, deployed more quickly and effectively. Less money wasted trying to retrofit incompatible systems.
Go to top of the page.
Q: Who should be involved in the development of a regional architecture? Is a regional architecture in non-conformance if key stakeholders are not present? How should States get non-traditional players who are deploying ITS technologies involved?
A: The development of a regional architecture is a collaborative process. To make it work, the participation of key stakeholders is critical. However, it may be impossible at times to fully engage certain stakeholders, either traditional (e.g., local transit property) or non- traditional (e.g., public safety). There is no "conformance test" of regional architectures called for in the Rule/Policy, so a lack of participation of certain stakeholders would not affect that. Nevertheless, it is important to make every effort to engage all stakeholders. The USDOT understands agencies cannot be forced to participate. Having said that, if the champion cannot get their participation at stakeholder meetings, it may be necessary to go to these agencies to determine their needs, their existing and planned ITS systems and their interest in integrating with other regional systems. It may be possible to work through and intermediary who represents the interests of a group of stakeholders. An example may be a state transit authority representing local transit authorities in the development of a statewide architecture.
Go to top of the page.
Q: While a formal "agreement" between stakeholders is desirable, when is it actually required?
A: The regional ITS architecture called for in this Rule/Policy must include, among other things, "an operational concept that identifies the roles and responsibilities of the participating agencies...," and, "any agreements (existing or new) required for operations..." For practical purposes, a list of the required agreements needed to implement the operational concept will meet the requirements of the Final Rule. However, once the agreements are developed, the stakeholders should consider including them in the regional ITS architecture documentation for reference purposes. To ease future maintenance issues, the agreements can be included as an appendix. There is no discussion within the Final Rule/Policy of the necessary formality of those agreements but it is expected that those agreements would be documented in writing somehow as part of the regional ITS Architecture. This could be with something as simple as letter between affected agencies. Where there is an implied sharing of staff or budgets or a transfer of authority, those affected jurisdictions will likely require more formal documentation than is required by the Rule/Policy before proceeding with actual project implementation.
Go to top of the page.
Q: Do I have to have a completed regional ITS architecture before I can develop any new ITS projects?
A: No, you can advance ITS projects in your region while you develop your regional ITS architecture. However, major ITS projects that advance during this period require a project level ITS architecture.
Go to top of the page.
Q: How does the regional ITS architecture relate to the transportation planning process?
A: The development of the regional ITS architecture
is not meant to compete with the formal transportation planning process.
They must work together to provide the best "plan" for the
region. Key ITS projects and initiatives are targeted early in the planning
process in order to facilitate more effective integration with other
projects in the region. For instance, the architecture can support and
help define the goals and objectives of a Long Range Transportation
Plan since it provides a vision of ITS in the future as seen by the
stakeholders. Operational concepts, market packages, and agency/subsystem
interfaces can all provide more clarity to the Long Range Transportation
Plan components for better scoping and allocating costs. In the case
of the Transportation Improvement Program (TIP), the application of
regional architecture products can generate more accurate cost estimates
for projects in the TIP, a better understanding of the agencies involved
in each project, and synergies among projects that might be taken advantage
of to better plan and sequence projects. For information on ITS and
the planning process, please refer to the Planning for Transportation
System Management and Operations website (http://plan4operations.dot.gov)
maintained by the Office of Planning. Also the electronic document library
(EDL) on the ITS webpage (www.its.dot.gov)
contains references on ITS and planning.
Go to top of the page.
Q: The National ITS Architecture contains subsystems my region is not planning to deploy. Do I have to have a plan for all these subsystems and interfaces?
A: No. The regional ITS architecture should be tailored to local needs and problems, as it should be a natural extension of the existing transportation planning process.
Go to top of the page.
Q: What types of funds are being used by States when developing architecture documents? What are the funding eligibility criteria for the development of the architecture documents?
A: There are many sources of funding that can be used to develop regional ITS architectures. Project funding from the NHS, STP, and CMAQ programs may all be used to craft regional ITS architectures, based upon the federal-aid eligibility provided by TEA-21 of ITS and operations and management expenditures. Planning funds may also be used, but like the constraints of the other federal-aid programs, all eligibility criteria for the selected funding source must be met.
Go to top of the page.
Q: Should consultants be hired to aid in the development of the regional ITS architectures and be employed to provide maintenance to the document upon completion?
A: Whether or not stakeholders should use consultants in developing and maintaining a regional ITS architecture depends on a number of factors. These factors include the knowledge, skill, and availability of stakeholder agencies' staffs related to regional ITS architecture development, and the complexity of the transportation system of a region. A number of larger regions employed consultant help in developing their regional ITS architectures and have retained those consultants' services in maintaining and updating the regional ITS architecture. Even if an area chooses to use consultants to develop and maintain a regional ITS architecture, the stakeholders' staffs should be aware of and knowledgeable about the processes used by the consultant so that they can be assured of compliance with the provisions of the Rule/Policy.
Go to top of the page.
Q: How should States engage the private sector in the development of the regional architecture?
A: In many areas around the country, activities by private sector firms play a significant role in the implementation of ITS across a region. This is especially true in traveler information services. How States and other regional stakeholders interact with these private ventures will depend upon current and emerging business arrangements of the public agencies and the private firms. For example, many public agencies provide data or video information to private firms that may re-sell or re-convey the information to the general pubic or to specialized travelers. These sharing arrangements provide an excellent opportunity to engage the private firms in developing a regional ITS architecture. If there are no arrangements currently in place, the developers of a regional ITS architecture may wish to craft an initial version of their architecture that can be used to begin discussion with private sector firms. These discussions should include exploring ways that the private sector firms can enhance the regional ITS architecture or provide services indicated in the regional ITS architecture.
Go to top of the page.
Q: What is a "complete" architecture?
A:A regional ITS architecture is never really complete. By definition it is a "living document" that must be revisited and revised as the requirements of the region change. In fact, the Rule has a requirement that a process be put in place for maintaining and updating the regional ITS architecture as necessary. For the purposes of using the regional ITS architecture to influence project design, once the stakeholders have developed an initial architecture, and all the key stakeholders have reached consensus, then they can say "it's complete for now." When something major changes in the region, or when the scheduled review time occurs, the stakeholders will need to maintain and update the regional architecture. So at any given time beyond this initial "completion date", the region should have a "complete" regional architecture, with the understanding it might change tomorrow.
Go to top of the page.
Q: What do you mean by a sequence of projects required for implementation?
A: The "sequence of projects" noted in section 940.9(d)(8) of the Federal Highway Administration's Final Rule on Intelligent Transportation System (ITS) Architecture and Standards refers to the scheduling of projects necessary to implement the regional ITS architecture. The intent is to recognize that in order to initiate some projects, other projects may have to be completed. An example in building a house would be that the electrical wiring and the plumbing needs to be completed before the interior walls can be finished. This identification of the projects' sequencing helps the stakeholders visualize how a region's ITS projects will "fit together" over time and their interdependencies.
Go to top of the page.
Q: What if the regional ITS architecture development steps and intent have been undertaken earlier but simply not called regional ITS architecture?
A: The Final Rule doesn't dictate form. The different parts of the regional ITS architecture may exist in different forms in different places or documents. As long as all parts of the Final Rule requirements can be demonstrated, conformity has been met. However, if the requirements of the Final Rule are scattered throughout several documents or locations, then maintenance will certainly become an issue.
Go to top of the page.
Q: For any given region within a State, will an existing statewide ITS architecture also satisfy the regional ITS architecture requirement of the Final Rule?
A: Just because a region (city, county, etc) is located within a State, that doesn't mean the regional ITS architecture requirements for that region are automatically met within the statewide ITS architecture. If the stakeholders within that region participated in the development of the statewide ITS architecture, and their specific systems and related interfaces in the region are part of it, then the Final Rule requirements for that region have been met. These stakeholders must also be part of the statewide ITS architecture maintenance process to ensure accurate reflection of their regional systems. If at some point, the stakeholders choose to have their own regional ITS architecture, their elements can be "pulled out" of the statewide ITS architecture and put in their own documentation. However, there must be consistency between both the statewide and any regional ITS architectures.
Go to top of the page.
Q: What if the statewide ITS architecture is at odds or conflicts with the regional ITS architecture, e.g. project prioritization is not the same?
A: Project prioritization is a local/regional decision. The regional and/or statewide ITS architecture should only consider sequencing of projects, not their priority for deployment. Statewide and regional ITS architectures should be consistent with each other. In fact, any regional ITS architectures that overlap should be consistent with each other. As a suggestion, the operational concepts, functional requirements, interconnects, information flows, project sequencing, agency agreements and ITS standards sections should be compared for compatibility. If there is a gap or an unnecessary overlap, the stakeholders can agree to change one or both architectures as needed. The changes can occur then or at the next maintenance cycle, as appropriate.
To address the issues of prioritization in a regional vs. statewide ITS architecture, perhaps an implementation plan that all stakeholders can agree upon would be useful. If however, a "shared" deployment, such as a fiber optic backbone, is a priority for the statewide ITS architecture stakeholders, and passes through a region for which the backbone is NOT a priority, then maybe the statewide stakeholders can agree to pay the full amount of deployment. In this case, since the region stakeholders don't have to provide funding, then they can agree to the deployment now vs. later and adjust their regional ITS architecture accordingly. In fact, the deployment of the fiber optic backbone may change the sequencing of the region's projects and change the region's project prioritization.
Go to top of the page.
Q: Will a regional ITS architecture and systems engineering analysis be required when "off-the-shelf projects" come up for funding?
A: Yes, these projects must be included in the regional ITS architecture, and will need to follow a systems engineering analysis if to be funded with Federal funds. This is also a good idea because of the current state and progress of technology. However, the local/regional people and others involved should be informed as early as possible before planning to fund shelved projects.
Go to top of the page.
Q: How often should the regional ITS architecture be updated?
A: A regional ITS architecture can be updated two ways, on a predetermined time cycle, or on an as needed basis. For the predetermined time cycle, we recommend using the TIP or STIP timeframe. For the as needed update, it can be triggered by a major change or addition the architecture, or after several smaller changes have been collected. Either strategy has impacts on cost and resources. For an extensive discussion of what should be considered in updating a regional ITS architecture, please refer to the "Regional ITS Architecture Maintenance White Paper" found on the Architecture implementation webpage and on the EDL as document #13957. It should also be noted that while a regional ITS architecture is technology independent, updates may be driven by improvements or developments in technology, especially in telecommunications.
Go to top of the page.
Q: How will the maintenance of the regional ITS architecture be funded?
A: Regional ITS architecture maintenance can be funded with Federal, State or local funds. All Federal funds are eligible, but perhaps SPR or PL funds would be most applicable. Some regions may choose to do their regional ITS architecture maintenance in-house using stakeholder staff.
Go to top of the page.
Q: Are there security implications of posting the regional ITS architecture on the Internet?
A: Many regions have put their regional ITS architecture on the Internet as an effective stakeholder outreach and data gathering tool. A few in the public safety and homeland security community have expressed a concern that posting the regional ITS architecture on the Internet poses a security issue. While there is still discussion about this, and it's not clear what will happen with this issue, there are a few thoughts that can be shared. While a regional ITS architecture does show the information flows between systems, and sometimes the method of the exchange (i.e. fiber, cellular, microwave, etc), the specific locations of the equipment is usually not specified. In a large metropolitan area, the specific locations of every detector, camera, DMS, etc would be onerous to show. However, for a regional ITS architecture that covers a smaller geographic area, showing the locations of specific equipment may be more possible, and could be an issue for the homeland security and public safety community. Another perspective is that many maps and other sources show the locations of critical infrastructure (i.e. bridges, power stations, hospitals, etc), so the regional ITS architecture doesn't provide any more information than can be garnered from other sources. However, the stakeholders will ultimately make the decision on what, if anything will be displayed on the Internet.
Go to top of the page.
Standards
Q: Elaborate on Section 940.9(d)(7) - Identification of ITS Standards supporting regional and national interoperability.
A: A key component of a regional ITS architecture is the determination of interface requirements and information exchanges with planned and existing systems and sub-systems. It is this part of the architecture development process that focuses on integration opportunities among the various existing and planned ITS systems in a region. There are over 115 ITS standards either developed or under development that are intended to facilitate these information exchanges. Once interfaces and information exchanges are agreed upon in the region, the ITS standards must be reviewed to see which will fulfill the regional requirements. The standards identified as absolutely necessary for the region, will be the ones that define regional interoperability.
Interoperability is the ability of systems to: (1) provide services; (2) accept services from other systems; and (3) use the services exchanged to operate effectively together. Interoperability is important because it simplifies developing ITS systems and procedures and allows ITS tasks to be performed consistently. Examples of interoperability are being able to use the same toll tag on multiple toll roads, being able to use one computer system to operate different variable message signs, and being able to send information and data from one traffic management center to another without multiple translation tables.
ITS standards bring about interoperability by specifying consistency and compatibility of the interconnects and interfaces, both hardware and software, between ITS systems and components. The stakeholders in a region must decide which ITS standards will achieve regional interoperability based on the ITS systems and components being deployed in the region and the ITS standards available. The use of standards is a first step toward achieving interoperability, although full interoperability will likely require agreements among the different agencies and organizations that provide the systems and the information to be shared. The level of formality of the agreements will be the stakeholders' choice.
Go to top of the page.
Q: Is the use of any standard mandated by this proposed Rule?
A: No, not at this time. Standards and interoperability tests are mandated only when they become officially adopted by the USDOT; at this point the USDOT has not adopted any ITS standards. The USDOT encourages the use of applicable ITS standards prior to their official adoption, however, as appropriate.
Go to top of the page.
Q: What does it take to have a standard adopted by the USDOT?
A: Currently there are no ITS Standards that have been adopted by the USDOT. However t here are several standards that have been developed via industry consensus and are approved for use by the standards development organizations (SDOs). FHWA and FTA encourage the appropriate use of these standards.
A formal Rulemaking process will precede any USDOT ITS standard adoption. Formal adoption will take some time after approval of the standard by an SDO. The USDOT has developed a set of criteria to determine when a standard could be considered for formal adoption. These criteria include, at a minimum, the following elements:
- A Standard Development Organization (SDO) has approved the standard.
- The standard has been successfully tested in real world applications as appropriate.
- The standard has received some degree of acceptance by the community served by the standard.
- Products exist to implement the standard.
- There is adequate documentation to support the use of the standard.
- There is training available in the use of the standard where applicable.
Go to top of the page.
Q: Does conformity with the National ITS Architecture ensure interoperability?
A: No. That's why there is the additional requirement for standards and interoperability tests, after they have been adopted by the USDOT. Even with the use of standards and interoperability tests, interoperability with other regions can only be ensured through detailed inter-jurisdictional discussions and agreements. The National ITS Architecture does provide a framework for determining the requirements for interoperability.
Go to top of the page.
Q: Does interoperability testing apply to all ITS projects?
A: The only interoperability tests that are currently contemplated by the USDOT are those associated with the Commercial Vehicle Operations (CVO) program. These tests are currently being used by States deploying CVO systems and will follow a similar set of criteria for adoption as those defined for standards. Again, as with standards, should the USDOT consider the adoption of these or any other interoperability tests, a formal Rulemaking process would be required.
Go to top of the page.
Q: On what projects should I use ITS standards?
A: ITS standards should be used on all transportation projects that involve ITS technologies. The Regional Architecture Development for Intelligent Transportation (RAD-IT) tool, an interactive software program developed to assist in regional ITS architecture and project architecture development, can be used to determine which standards are appropriate for an ITS project. One feature of RAD-IT is the identification of information flows that can be selected for the regional ITS architecture based upon the functions and services selected by the stakeholders. Each of the information flows has the appropriate ITS standards identified, so the stakeholders can select which ITS standards should be pursued as individual projects are developed. More information on the RAD-IT tool can be found on the Architecture Implementation website.
Go to top of the page.
Q: Where can I get more information on ITS standards?
A: The USDOT ITS Standards website at www.standards.its.dot.gov/standards.htm has the latest information on ITS standards development, use, testing, training and technical assistance.
Go to top of the page.
Systems Engineering
Q: How does following a systems engineering process help me?
A: As an inter-disciplinary approach to procurement and implementation, systems engineering (SE) enables you to identify and document all of the project requirements, to effectively manage the technical complexity of the resulting developments, and to verify that the requirements are thoroughly and correctly implemented. The use of an SE methodology assures that all phases of a system's lifecycle are addressed, from conception thru design, installation and testing, and operations and maintenance. With early identification and control over your requirements, considerable costs - in an order of magnitude - can be avoided compared to otherwise unmanaged changes during the design and implementation phases of the project. SE gives you the toolset AND drives the mind set for achieving successful operations at reduced cost.
As an SE methodology is followed, the seven minimum criteria mentioned in 940.11(c) will be addressed. The degree to which they are addressed will be commensurate with the project scope and its complexity.
Go to top of the page.
Q: Define "system functional requirements".
A: The system functional requirements noted in Section 940.9(d)(5) of the FHWA Final Rule on ITS refers to a reasonably complete description of the high-level tasks, actions or activities that must be performed by the ITS components to address the needs or problems of the region. The level of detail is up to the stakeholders, but some of the market packages and equipment packages of the ITS National Architecture could be used as a resource.
Go to top of the page.
Q: What is the cost of conducting a systems engineering analysis as described in the Final Rule?
A: Based on an analysis of large software projects, a rule of thumb is that 15% of the project cost should be used for a full systems engineering analysis. While this may seem a lot, the cost of not following a systems engineering process is an increased chance of cost and schedule overruns, and possibly project failure. It's very important to note that the systems engineering analysis needs to be commensurate with the scope of the ITS project. As transportation projects of all sizes gather information on using a systems engineering process, this rule of thumb will become more accurate.
Go to top of the page.
Q: What is the difference between an Operational Concept and a Concept of Operations?
A: Within the context of regional ITS architectures and systems engineering analyses, the difference between an operational concept and a concept of operations is one of scope and level of detail. Whereas an operational concept is region-wide, and part of the regional ITS architecture, a concept of operations is project-specific, and part of a systems engineering analysis.
An operational concept describes the roles and responsibilities of the stakeholders as they relate to systems and transportation operations within a region. It's intended to be a high-level document, because the number and complexity of systems, and stakeholders' roles and responsibilities in a region may be large. In fact, the depth of information of an operational concept will be decided upon by the stakeholders, and will likely rely very heavily on the quantity and variety of systems in a region. To that end, many regional ITS architectures use "high-level operational scenarios" to engage stakeholders and better describe their roles and responsibilities within the region. For instance, these scenarios might describe what happens during a large weather incident, hazardous material spill, or long-term construction project. As stakeholders walk through these scenarios, and document their operational concept, the significance of understanding roles and responsibilities is quickly highlighted and gaps or challenges in regional operations can be identified and addressed. The resulting documentation can be a series of statements that are binding (shall), simply stated facts (will), or establish a goal or direction (should).
A concept of operations, also referred to as a "conops," describes more detailed operational characteristics of a particular system or project, and provides a common understanding of the system's goals and expectations for project stakeholders to track as the system is implemented or enhanced. It also defines the roles and responsibilities of the stakeholders specifically impacted by the project or system. The concept of operations provides overall operational issues from which design and implementation criteria will be taken. It is not a detailed design document, but an overview of how the system or project shall operate and the interactions among the stakeholders. These are binding user requirements within the SE process and will be documented as predominantly mandatory (shall) statements. Identification of these project requirements may also help determine the most effective procurement methods early in the project development.
Go to top of the page.
Training and Technical Assistance
Q: Will there be any formal training and technical assistance offered in developing, using and maintaining regional ITS architectures?
A: USDOT has developed the Regional ITS Architecture Guidance document that outlines a process for the development of a regional ITS architecture. The document can be found on the FHWA Office of Operations Publications website.
Also available is the Regional ITS Architecture. The training and workshops bring together the key players from a region to provide "training" on the process of developing a regional ITS Architecture so they can lead their region's efforts, or acquire the services of and monitor a contractor to carry out that development. Additional information on training and workshops are found on the National ITS Architecture website
Once a regional ITS architecture is developed, there are several resources available to assist in the use and maintenance of the architecture. Also available is a white paper entitled "Regional ITS Architecture Maintenance" (FHWA Office of Operations website) that expands upon the Architecture Guidance Documents and provides a more detailed guide for the development of an architecture maintenance plan and the activities involved in maintaining an architecture.
If interested in any of the training or technical assistance presented
here on any and all aspects of the regional ITS architecture process,
please contact your local FHWA
Division Office or FTA
Regional Office. FTA is also developing a number of workshops and
seminars targeted to its personnel and to its customers related to ITS
architecture consistency.
Go to top of the page.
Q: What are the best online resources for the Field staff to go to for regional ITS architecture and Final Rule information?
A: The Architecture Implementation website through the FHWA Office of Operations contains the most comprehensive information on the Final Rule and architecture conformity. Information can also be accessed through the ITS JPO website.
Go to top of the page.
