| Related: |  |
This section will consider how agencies
might implement the requirements of FHWA 23 CFR 940 and corresponding FTA
Policy as they relate to developing a regional ITS Architecture and the systems
engineering analysis for ITS projects. The section will first consider the
requirements of 23 CFR 940 and the FTA policy, and then will consider ways in
which agencies have implemented these requirements.
23 CFR 940 and the FTA Policy on ITS Architecture and Standards define a set of requirements for regions regarding regional ITS architecture, and a set of requirements for agencies to undertake good, documented engineering processes that help ensure that ITS projects attain the integration and operational objectives embodied in their regional ITS architectures. The requirements of the 23 CFR 940/ FTA/Policy are summarized below.
According to FHWA 23 CFR 940, a regional ITS architecture is a “regional framework for ensuring institutional agreement and technical integration for the implementation of ITS projects or groups of projects”. Developing a Regional ITS Architecture is a part of ITS Operations Planning (See Section 3.3.2). As specified in the FHWA 23 CFR 940.9 and corresponding FTA Policy Section V, the purpose of a Regional ITS Architecture is to guide the development of ITS projects and be consistent with ITS strategies and projects contained in applicable transportation plans.
Regional ITS Architecture are based on the National ITS Architecture, now called the Architecture Reference for Cooperative Intelligent Transportation (ARC-IT). ARC-IT provides a framework for planning, defining and integrating ITS in the United States. Some other countries have a similar framework for their ITS. Tailoring a Regional ITS Architecture from ARC-IT is best accomplished with the Regional Architecture Development for Intelligent Transportation (RAD-IT) software tool. The Regional ITS Architecture should be defined on a scale commensurate with the scope of the ITS investment in the region. The Regional ITS Architecture development should also include the participation of all the significant ITS stakeholders in the region. A Regional ITS Architecture is a regional plan showing both existing and planned systems and their interfaces for surface transportation system integration.
Refer to the Architecture Use section of the
ARC-IT website (https://www.arc-it.net) for more information on developing or
updating your Regional ITS Architecture.
The primary purpose of the Regional ITS Architecture is to develop a plan for how ITS projects are integrated together. ITS projects need to be understood and developed in the context of the region. The FHWA 23 CFR 940.11 (excerpted below in italics) and corresponding FTA Policy Section VI require the following for ITS Project Implementation:
One more important area to understand from the Regulation/Policy is the establishment of ITS project administration and oversight. The FHWA 23 CFR 940.13 and corresponding FTA Policy Section VII established project administration and oversight responsibilities to FHWA and FTA respectively. The Regulation/Policy reads as follows:
For reference, 23 CFR 940 defines “ITS” as:
Intelligent Transportation System (ITS) means electronics, communications, or information processing used singly or in combination to improve the efficiency or safety of a surface transportation system.
And 23 CFR 940 defines “ITS Project” as:
ITS project means any project that in whole or in part 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.[2]
Generally, state departments of transportation define projects that carry out an ITS user service (as embodied in the ARC-IT Service Packages) as those requiring integration, given that the purpose of the regional ITS architecture is to provide an integration plan for ITS within a region.
The FHWA Division and FTA Regional Offices determine how the systems engineering analysis requirements in the Regulation/Policy should be applied to ITS projects in each region and how compliance should be demonstrated by each project sponsor. Federal oversight is provided based on Stewardship and Oversight agreements that are defined with each state. Several states have established checklists that prompt project sponsors to consider the systems engineering analysis requirements as part of the project development process. Other states have developed template documents, or finished documents for common (and specific) project types (see discussion below). FHWA has also provided a range of Model Systems Engineering Documents that can be tailored to specific project needs by implementing agencies. These model documents cover traffic signal systems, dynamic message signs, CCTV systems, and (in progress at time of publication) traffic sensors. Each of these approaches is further discussed below. Contact the ITS specialist in your FHWA Division Office or FTA Regional Office for more information.
Agencies have applied a variety of approaches and tools to support the implementation of the SE process in order to address the requirements described above. These include use of a Systems Engineering Review Form (SERF), developing sample systems engineering documents for use in commonly deployed systems, and, at the federal level, use of Model Systems Engineering Documents. All three of these approaches are discussed below.
Some states have created a form that can serve as a checklist to address the SEA requirements of 23 CFR 940.11. Project sponsors fill out the form as a way to indicate their compliance with the requirements. The forms provide responses to the seven requirements for systems engineering analysis within 23 CFR 940.11. Some states (e.g. California and New Jersey) call this a SERF, other states (e.g. Arizona) call it a Systems Engineering Checklist. There is no specific format for these forms, with each state that has developed one creating something slightly different. Michigan DOT and Arizona DOT have created pdf forms that can be filled out. Caltrans and NJDOT have Word documents that can be filled out and submitted. Some states provide explanation for each question to clarify the information that should be collected. Since these are “checklists”, what is often requested are links to additional documentation (e.g. concept of operations or requirements documents) that have been created to support the project.
In addition to the seven requirements listed above, some states include sections that provide general descriptions of the project, or connections from the project to planning documents (such as a Metropolitan Transportation Plan). Some states tie the form/checklist to an assessment of risk (which was addressed in Section 4.2). The idea of tying the checklist to risk is to identify if the project falls into a category that is exempt from systems engineering analysis, is a low risk project that requires minimal analysis, or is a higher risk project requiring a more complete delineation of the systems engineering process.
In the absence of a state form to use, the following discussion provides the seven requirements along with some clarifying information on what to collect:
1. Identification of portions of the Regional ITS Architecture being implemented:
Contact your MPO or State DOT to get this information from your Regional ITS Architecture (“RA”). Review the portions of the RA that define the project. If your architecture has a defined project architecture for your project, then you can copy that. If not consider the following portions of the architecture as they relate to your project:
· Service Packages
· Elements
· Information flows
If there is no information in your RA, arrange with your MPO to provide them this information when your project is designed; they will use it in the next update of the RA.
2. Identification of participating agencies roles and responsibilities:
Can you identify all stakeholders that must participate in the implementation or operations phases of this project? What are their roles/responsibilities? Have they committed to the responsibilities? Some of this information might appear in your RA (e.g., “Operational Concepts” or other sections). If this will be defined in later phase of the project (e.g., Concept of Operations), the RA may be a good source to start definition.
3. Requirements definitions:
Are the system requirements (functional and performance) already well-defined in writing? If yes, indicate where they can be found (e.g., Standard or Specs). If they will be defined in later phase of the project, the applicable high-level functional requirements in the RA may be a good starting point for writing them. The focus is on “what” functions must be performed – not on “how” the technology will be used to perform them.
4. Analysis of alternative system configurations and technology options to meet requirements:
Have you considered alternative designs yet? This could include system configurations, different organizational roles; alternative hardware, software, or communications technology. Alternatives may be considered at several points in a project lifecycle. For large systems, concept exploration considers broad alternative concepts early as defined in Section 3.3.3. More detailed design/technology choices wait until High-Level design as described in Section 3.3.7.
5. Procurement options:
Have you considered different procurement options for each of the project phases (design, implementation, operation, and management)? These options could include: off-the-shelf vs. custom, lease vs buy, fixed-price vs. cost-reimbursable, purchase-of-services contract etc. Procurement options must consider the level of staff technical expertise, existing agency procurement practices, who will be the project manager, and what level of systems engineering expertise is needed for the project. A more detailed discussion of procurement options and considerations for support during development can be found in Section 4.4.
6. Identification of applicable ITS standards and testing procedures:
Do you know yet if any ITS Communications Standards are applicable to this project? If they are applicable, will you use them? If your RA identifies specific Information Flows, you can ask your MPO to produce a “Standards Report” for those Flows; it will identify ITS Standards to consider.
7. Procedures and resources necessary for operations and management of the system:
Can you identify all stakeholders that must participate in operations, management and maintenance of the system throughout its life cycle? What are the roles, responsibilities, and resources required from each stakeholder? Examples include: money, special equipment, staff time, O&M capabilities, special expertise, provision of data, and many more. You should consider hardware, software, and communications issues.
In general, these checklists are meant to be used for state DOT projects, but where Highway Trust Fund money is used for county or municipal ITS projects, Division offices may recommend use of the statewide forms (which have been coordinated with the Division Office) as the basis for addressing systems engineering.
[1] 940.9 is the 23 CFR 940 section defining Regional ITS Architecture requirements.
[2] Note the current version of ARC-IT does not define a set of “user services” but is defined around a set of Service Packages. So, consider the definition above to be equivalent to “provision of one or more ITS service packages as defined in the National ITS Architecture”.
| Related: | |
