- What is Northern Virginia ITS Architecture?
- Who are the users of this architecture?
- How and when is the architecture being used?
- Does the architecture identify ITS Standards?
- Doesn't using architecture just add more work and more cost to the project?
- What are some of the benefits of using an ITS architecture?
Q: What is the Northern Virginia ITS Architecture?
A: The Northern Virginia ITS Architecture is the regional architecture for ITS deployments in the VDOT Northern Region Operations (NRO) that details the interconnection of Northern Virginia (NV) transportation facilities and stakeholders, and describes the flow of information between these agencies and their operations. Based on the definitions and structure of the National ITS architecture, the NV ITS Architecture guides transportation planning, project development and execution to achieve increased integration of transportation systems such as VDOT NRO's with other transportation systems. The architecture accomplishes this by clearly identifying and defining the existing and future ITS systems and their data exchanges.
The NV ITS Architecture is technology-independent. It is not a design document. It is not a project or institutional process. The architecture is simply a planning tool and facilitates project scope development that should include interface/integration with other systems.
Q: Who are the users of this architecture?
A: The primary users of the architecture are ITS project managers as they develop their ITS projects, including VDOT NRO project managers. Users also include project managers from the transportation, public safety-related agencies, and private transportation service providers in the region, who need to interact with VDOT and other stakeholders for their ITS projects.
Q: How and when is the regional architecture used?
A: The regional architecture can be used during three stages of a life cycle of the project:
- Stage 1 - Before Funding is Identified: To develop a high-level architecture overview of the systems and stakeholders that would participate in the project and to gain consensus. VDOT project managers may use the architecture to assist them with completing project proposals.
- Stage 2 - After Funding is Budgeted: As a step in the systems engineering process and in completing FHWA rule requirements. VDOT project managers may use the architecture to assist them in filling out the Checklist, demonstrating their projects follow the System Engineering process, comply with the architecture, and conform to federal Rule 940.
- Stage 3 - After Completion of the Project: To provide and update project information back to the Architecture Maintainer for the maintenance of the regional architecture.
One can use architecture to identify stakeholders/participants, define project boundaries, describe functions to be performed, and help develop the scope and cooperation.
Q: Does the architecture identify ITS Standards?
A: Yes and No. Yes. For each information exchange between systems in the NV ITS Architecture, the applicable ITS standards are identified. These standards often represent a superset of options rather than specific recommendations. With the different levels of maturity among the standards, the project manager still has to determine the specific applicability and availability of ITS standards for their projects. Standards identified in the architecture provide project managers with a starting point.
Q: Doesn't using architecture just add more work and more cost
to the project?
A: The goal of this effort is not to impose more work upon the VDOT NRO Staff managing the ITS project development, but to ensure that the projects are defined with integration in mind. Projects defined without considering integration opportunities are either more costly in the long run due to the cost of redesign in the future, or in extreme cases, not responsive to the region’s needs.
For example: A CCTV sharing project in Northern Virginia, was initially scoped for sharing only four (4) CCTVs in the Springfield Interchange area with Fairfax County Police and Virginia State Police. The scope was constantly expanded because more stakeholders wanted access to view these CCTV images. If the architecture was available and used at the beginning, the project manager could have quickly assessed the number of potential stakeholders that are interested in the CCTV images. This would have led to a different design for video-sharing with a much larger group of stakeholders while providing the ability and flexibility to add and accommodate future stakeholders. This project ended with a design that VDOT did not adopt and changed the business model by contracting with a private company to provide a video sharing clearinghouse.
Q: What are some of the benefits of using the architecture and
systems engineering for ITS?
A: The ITS Architecture enables more efficient intelligent transportation systems, deployed more quickly and effectively. Less money is wasted trying to retrofit incompatible systems.
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.
- What is (if any) this architecture's relationship with the Maryland statewide and Metropolitan Washington Regional architectures?
- Which architecture should I use for developing ITS projects in Northern Virginia?
- When do I use the Virginia Statewide ITS Architecture vs the Northern Virginia ITS Architecture?
Q: What is (if any) this architecture's relationship with the Maryland statewide and Metropolitan Washington Regional architectures?
A: The NV ITS Architecture identifies interfaces with the Maryland Statewide ITS Architecture and has reconciled any overlaps with the work being done to develop a regional ITS architecture for the Metropolitan Washington area. While developing the NV ITS Architecture version 1.0 in 2001 and updating the architecture version 2.0 in 2005, VDOT took the lead coordinating with both architecture project managers to ensure consistency. Beginning in 2006, a MWCOG architecture working group was established to hold frequent meetings with participation from VDOT, Maryland State Highway, WMATA, DCDOT, and MWCOG to coordinate the continuous architecture efforts and resolve nomenclature and approach issues and to ensure consistency among the architectures. It is our goal that all these agency architectures will be consistent with the Metropolitan Washington Regional architecture.
Q: Which architecture should I use for developing ITS projects
in Northern Virginia?
A: The answer depends on the scope of the project. If the project involves mainly VDOT NRO systems or interconnection with VDOT NRO systems, then the Northern Virginia ITS architecture should be used. If the project involves interconnections between non-VDOT systems, NV ITS Architecture should still be consulted but the MWCOG regional architecture should be also be referenced to make sure that all information is leveraged.
Q: When do I use the Virginia Statewide ITS Architecture vs the Northern Virginia ITS Architecture?
A: The Virginia Statewide ITS Architecture focuses primarily on statewide systems such as Virginia 511, VATraffic, Statewide Emergency Management coordination and operations, The Statewide ITS Architecture identifies interfaces between regional systems such as transportation operations centers and statewide systems such as VATraffic. It does not redefine the functionality of the regional systems but it does define the statewide systems functionality. On the other side, the Regional ITS Architectures identify the same interfaces but only define the regional system functionality. This division of functionality definition simplifies the architectures so they don't have to define everything. For project definition in Northern Virginia, the Northern Virginia ITS Architecture should be the primary resource used. If the project interfaces with a statewide system or a neighboring region's system, the Virginia Statewide ITS or the appropriate regional ITS architecture should be consulted for further details on the functionality of the interfacing system.
- What is the National ITS Architecture and where can I get more information?
- What is the FHWA Rule on ITS Architecture and Standards Conformity?
- Is the NV ITS Architecture consistent with the National ITS Architecture? If so, how?
- What is Turbo Architecture and where can I get it?
- How do I use Turbo Architecture?
A: The National ITS Architecture, developed by U.S DOT, provides a common
framework for planning, defining, and integrating intelligent transportation
systems. It is a mature product that reflects the contributions of a broad
cross-section of the ITS community (transportation practitioners, systems
engineers, system developers, technology specialists, consultants, etc.).
The architecture defines:
- The functions that are required for ITS
- The physical entities or subsystems where these functions reside
- The information flows and data flows that connect these functions and physical subsystems together into an integrated system
Version 6.1 of the National ITS Architecture is now available and can be accessed by clicking on http://www.iteris.com/itsarch/
Q: What is the FHWA Rule on ITS Architecture and Standards Conformity?
A: On January 8, 2001 the Final Rule on ITS Architecture and Standards Conformity and the Final Policy on Architecture and Standards Conformity were enacted by the FHWA and FTA respectively. The Final Rule/Final Policy ensures that Intelligent Transportation Systems (ITS) projects carried out using funds from the Highway Trust Fund including the Mass Transit Account conform to the National ITS Architecture and applicable ITS standards. This will be accomplished through the development of regional ITS architectures and using a systems engineering process for ITS project development.
Additional information on the Rule, Guidance and FAQ's is available through http://www.ops.fhwa.dot.gov/its_arch_imp/policy.htm
Q: Is the NV ITS Architecture consistent
with the National ITS Architecture and the FHWA Rule on ITS Architecture and
Standards Conformity? If so, how?
A: Yes. This architecture has been developed to be fully conformant with FHWA Rule 940 on ITS Architecture and Standards Conformity and is based on the latest National ITS Architecture - Version 6.1. It satisfies all the requirements of Rule 940.09 involving regional ITS Architecture development and it addresses how the architecture is applied in the systems engineering analysis required by Rule 940.11.
Q: What is Turbo Architecture and where can I get it?
A: Turbo Architecture is a software application that supports development of regional and project ITS architectures using the National ITS Architecture as a starting point. Turbo Architecture Version 4.1 fully supports Version 6.1 of the National ITS Architecture and includes many new features that improve support for the FHWA Rule 940 and FTA Policy for Regional ITS Architectures and Standards.
Turbo Architecture is a Windows Application that includes a quick start guide, a conversion guide, a user's manual, installation guide, and on-line help. The product is available for download free of charge (http://www.iteris.com/itsarch/html/turbo/turboform.htm) at the National ITS Architecture site.
Q. How do I use Turbo Architecture?
A: Turbo Architecture allows project managers to view and develop ITS project architectures using the NV ITS Architecture in an easy database format. The Turbo architecture version of the NV ITS Architecture can be downloaded from the NV ITS Architecture website. Project managers can develop specific project-related architectures using the NV ITS Architecture as a starting point. VDOT NRO has also offered training classes with hands-on Turbo Architecture exercises.
- What is an ITS project?
- To which federally funded projects does this Rule apply?
- What is required of all new ITS Projects?
- Does this Rule or the National ITS Architecture tell me which technology to buy?
- Do I have to replace all my existing equipment to conform with the National ITS Architecture?>
- How should agencies deal with work zones that use temporary ITS for traffic control on projects without ITS (i.e. pavement reconstruction)?
- Is any single traffic signal upgrade project an "ITS project"?
- Do I need to go through all the systems engineering steps for small replacement or maintenance ITS projects (like replacing cameras etc) or non-ITS projects with ITS elements?
- For ITS projects that don't use Highway Trust Funds, how should these be identified as opportunities for integration?
- How are earmarks treated under the Final Rule? Do earmark projects need to be in the regional ITS architecture? Do they need to follow a systems engineering process?
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.
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.
A: The rule states that - "Upon completion of the regional ITS architecture required in §§ 940.9(b) or 940.9(c), the final design of all ITS projects funded with highway trust funds shall accommodate the interface requirements and information exchanges as specified in the regional ITS architecture. If the final design of the ITS project is inconsistent with the regional ITS architecture, then the regional ITS architecture shall be updated as provided in the process defined in § 940.9(f) to reflect the changes.
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.
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.
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: Incorporating ITS elements into non-ITS construction projects 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 a region to have this "vision" and be able to identify these opportunities.
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.
A: 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.
A: The Rule/Policy does not require ITS projects that are not funded by the Highway Trust Fund to be compliant. However, in order for a regional ITS architecture to be most useful, it should contain all ITS activities and projects in the region. The stakeholders need to decide how the documentation that is developed as part of the regional ITS architecture should address projects that are funded outside of the Highway Trust Fund, and the appropriate level of detail to best identify the integration opportunities
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 be a reason to update the regional ITS architecture outside of the normal maintenance schedule.