To promote an understanding of how ITS infrastructure serves the activities agencies undertake to attain operational goals and objectives, and to promote the effectiveness of ITS projects in supporting those activities, Congress included Section 5206(e) in the Transportation Equity Act for the 21st Century. As a result of this section, in 2001 USDOT established in Title 23 of the Code of Federal Regulation a new Part 940 Intelligent Transportation System Architecture and Standards. This section identifies the National ITS Architecture, the requirement for regions to develop a regional ITS architecture, and the requirement 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. In addition to CFR 940, FTA has implemented a similar policy to address requirements on transit projects.
The CFR 940 requirements on ITS projects deployed by state, county, or municipal transportation agencies that utilize money from the Highway Trust Fund are managed by FHWA Division Offices. These requirements cover the two basic topics mentioned above: 1) the development of regional ITS architectures that can be used to plan the integration of ITS deployments within a region and 2) the documentation of systems engineering processes relating to ITS projects. Many of the Division Offices have defined procedures or processes that local agencies should follow to address the requirements. They may also develop forms, such as a Systems Engineering Review Form (SERF), to support the reporting of how ITS projects address the requirements. Appendix B provides a general set of approaches for agencies to address FHWA or FTA requirements.
As you will see in the following chapters, the systems engineering approach applied in the broader industry encompasses more than the requirements identified in the Regulation/Policy. A complete systems engineering process will meet or exceed the specific systems engineering analysis requirements identified in the Regulation/Policy. Recently the USDOT has put out a memorandum to clarify the use of systems engineering for ITS projects (Information Memo - Systems Engineering for ITS Projects (dot.gov). Relevant information from this memorandum is provided below.
Systems engineering provides a needs-focused, requirements-driven engineering process for ensuring that projects involving technologies used for intelligent transportation management meet the needs and the expectations of the agencies undertaking them. It is also used to demonstrate that projects are consistent with any applicable regional ITS architecture to ensure that they maintain interoperability in accordance with the stated needs and objectives of their stakeholder agencies.
Under 23 CFR 940.13, Division Offices (or States that have signed a Stewardship and Oversight Agreement) provide oversight of ITS projects. Oversight of ITS projects includes ensuring that compliance with the requirements in 23 CFR 940.11 is demonstrated. Projects that do not fund the acquisition of technologies that provide or contribute to the provision of ITS user services do not fall within the definition of an ITS project in 23 CFR 940.3 and, therefore, are not subject to these requirements. Examples of such projects include construction of traffic signals that are not expected to be part of a coordinated system of traffic signals, upgrades to existing signals, signal timing and other operational studies, operations and ITS feasibility and planning studies, and routine operations.
While systems engineering comprises a broad spectrum of proven engineering practices that take a variety of forms, 23 CFR 940.11 requires only the provision of a Systems Engineering Analysis that includes the seven attributes outlined in 23 CFR 940.11(c):
(1) Identification of portions of the regional ITS architecture being implemented (or if a regional ITS architecture does not exist, the applicable portions of the National ITS Architecture);
(2) Identification of participating agencies roles and responsibilities;
(3) Requirements definitions;
(4) Analysis of alternative system configurations and technology options to meet requirements;
(5) Procurement options;
(6) Identification of applicable ITS standards and testing procedures; and
(7) Procedures and resources necessary for operations and management of the system.
The analysis should be proportional to the scope and complexity of the project.
A regional ITS architecture, which is discussed in 23 CFR 940.9, can be described as a database of ITS technologies and systems, the interfaces and data that flow between them, the roles and responsibilities of their operating agencies, the requirements those systems will fulfill, and the goals and objectives that those systems help regional stakeholders to attain. Importantly, the regional ITS architecture is an outgrowth of an operations planning process, as identified in 23 CFR 940.9(a):
regional ITS architecture shall be developed to guide the development of ITS projects and programs and be consistent with ITS strategies and projects contained in applicable transportation plans.
The Systems Engineering Analysis, therefore, connects an implementation project to a program of operational improvements that deploy ITS over the horizon of applicable transportation plans. Systems engineering stands on a foundation of operations planning.
Most ITS projects that deploy conventional ITS technologies in support of existing operational activities pose lower risk than projects deploying innovative technologies in support of operational activities new to the agency undertaking them. A low-risk project has the following characteristics:
Experienced users who understand the application of the technology being implemented.
Clear and sufficiently detailed documentation of the agencys activities, needs, and requirements that are applicable to the proposed work.
No new agencies, jurisdictions, or modes that may require additional documentation of their activities and needs beyond what is already identified in existing documentation.
No new software being developed.
No new interfaces between systems not previously in use.
Use of technologies already shown to fulfill documented requirements.
Use of technology products that are not at the end of their service life such that their use would shorten the project lifecycle.
For low-risk projects, the required attributes of a Systems Engineering Analysis provided in 23 CFR 940.11 can be addressed using existing, reused, or pre-drafted documentation. For these low-risk projects, State and local transportation agencies have demonstrated several different approaches for conducting systems engineering at an appropriate level of detail to minimize risk without unnecessarily developing systems engineering products from scratch, and without the need to hire a systems engineering consultant. These approaches can include:
1) Categorical Systems Engineering. For example, Minnesota Department of Transportation (DOT) devised a risk-based approach that provides pre-drafted systems engineering documents for common lower-risk categories of projects. These pre-drafted documents can be used as supporting documentation that provides complete and correct descriptions of needs and requirements for the projects within the category. (See https://www.dot.state.mn.us/its/systemsengineering.html). Ohio DOT similarly identified specific types of projects that would be given defined systems engineering treatment. (See the Ohio DOT Traffic Engineering Manual, Part 13 Intelligent Transportation Systems (section 1300 (ITS), subsection 1301-3.2)): https://www.dot.state.oh.us/Divisions/Engineering/Roadway/DesignStandards/traffic/TEM/Documents/Part_13_Complete_011714Revision_011614_bookmarked.pdf).
2) Extensions of existing systems, for which systems engineering documents already exist. For example, California Department of Transportation (Caltrans) assesses risk for projects in this category based on the existence of the elements of a Systems Engineering Analysis already in place that can be used for the project in question. (See the Caltrans Local Assistance Program Guidelines, Chapter 13 Intelligent Transportation Systems (ITS) Program (pages 1 19): https://dot.ca.gov/-/media/dot-media/programs/local-assistance/documents/lapg/g13.pdf).
3) Extracting Systems Engineering Analysis elements from current and appropriately updated regional ITS architectures. A well-maintained regional ITS architecture developed in accordance with 23 CFR 940.9 includes roles, objectives, and requirements at the planning level. A project architecture includes these elements extracted from the regional architecture. These elements can be used to support a Systems Engineering Analysis.
4) The use of Model Systems Engineering Documents. A number of State and local agencies successfully employed the Model Systems Engineering Documents for Adaptive Control Signal Technologies developed by FHWA as part of Every Day Counts (Round 1). The success of these applications led to the expansion of the library of Model Systems Engineering Documents to include the following:
a) Traffic Signal Systems (incorporates and supersedes Adaptive Control Signal Technologies): https://ops.fhwa.dot.gov/publications/fhwahop19019/index.htm
b) Dynamic Message Signs: https://ops.fhwa.dot.gov/publications/fhwahop18080/index.htm
c) Closed-Circuit Television: https://ops.fhwa.dot.gov/publications/fhwahop18060/index.htm
d) Transportation Sensor and Detection Systems: (forthcoming)
Projects that use more than one of these technologies may combine the needs and requirements extracted from these model documents.
Some ITS projects, such as projects that lack a clear and documented understanding of the requirements they must fulfill, or the needs they must satisfy, demonstrate higher risk. In some cases, these projects may involve technologies approaching obsolescence or technologies not previously tested. In addition, projects that will develop new software or interfaces not previously in use pose greater risk. The degree of agency familiarity with a technology or operational activity also influences risk. For higher-risk projects, implementing agencies should consider the development of new systems engineering documentation as needed to provide the attributes required to support a Systems Engineering Analysis per 23 CFR 940.11.
Many States use a Systems Engineering Review Form (or similar document) to assess the risk of the project as the basis for identifying the systems engineering steps appropriate to mitigate those risks (for example, see the New Jersey DOT TSM Procedures Manual at page 12: https://www.state.nj.us/transportation/eng/elec/ITS/pdf/TSMProceduresManual.pdf).
If that review reveals gaps in the required systems engineering documentation, a plan for filling those gaps may be embodied in a Systems Engineering Management Plan (SEMP) or similar document (see Caltrans Local Assistance Program Guide at Chapter 13 page 2: https://dot.ca.gov/-/media/dot-media/programs/local-assistance/documents/lapg/g13.pdf).
