Regional Project Planning
As the Metropolitan Planning Organization (MPO), SCAG is responsible for preparing the Regional transportation Plan (RTP) that establishes the region’s long-range transportation goals, objectives and policies. Regional outcomes are achieved over a period of many years through a culmination of projects that build upon other individual ITS projects. The Southern California Regional ITS Architecture supports the RTP update process by documenting existing and planned ITS projects, including how ITS projects are sequenced.
Stakeholders that follow the Southern California Regional ITS Architecture ensure that their projects maintain consistency with the National ITS Architecture, which is a requirement for federally funded projects. Furthermore, in California, ITS projects that receive federal funding are required to follow the systems engineering planning process. Information and steps required in the systems engineering process are found or addressed throughout the Regional ITS Architecture.
For projects receiving Federal transportation funding from the Highway Trust Fund and Mass Transit Account, there are certain planning criteria that must be followed. Mass Transit Account funding applicants should review the procedures documented in National ITS Architecture Consistency Policy for Transit Projects, while other project funding applicants in California should take the procedures as outlined in or Chapter 13 of the Caltrans Local Assistance Program Guidelines (LAPG). These procedures are briefly explained for transit projects and non-transit projects in the following sections. ITS projects in California receiving federal funds have to ensure that systems engineering process is followed in addition to meeting the requirements related to the regional ITS architecture.
Non-Transit Projects
One requirement of the Local Assistance Program Guidelines (LAPG) is that the local agency must follow the process to determine the level of risk for the ITS project. There are three types of project risk (Exempt, Low-Risk and High Risk) which determine the process for project funding and development. Local agencies first submit a Field Review Form that includes the ITS Systems Engineering Review Form (SERF) to the Caltrans District Local Assistance Engineer (DLAE) as part of their E-76 Package. By answering the seven questions of the SERF, the local agency can determine if the ITS project is Low Risk (formerly “Minor”) or High Risk (formerly “Major”). The SERF is meant to be high-level project information and can be completed by public agency staff.
The list below shows where in this regional ITS architecture documentation information can be fund to assist in writing a SERF.
SERF REQUIREMENT | ITS ARCHITECTURE RESOURCE |
|---|---|
Identification of portions of regional architecture being implemented | ITS Inventory |
Requirements definition | Functional Requirements |
Analysis of alternative system configurations and technology options to meet requirements | Not Available in Regional ITS Architecture |
Procurement options | Not Available in Regional ITS Architecture |
Identification of applicable ITS standards and testing procedures | Standards |
Procedures and resources necessary for operations and management of the system | Not Available in Regional ITS Architecture |
Transit Projects
One requirement of the Local Assistance Program Guidelines (LAPG) is that the local agency must follow the process to determine the level of risk for the ITS project. There are three types of project risk (Exempt, Low-Risk and High Risk) which determine the process for project funding and development. Local agencies first submit a Field Review Form that includes the ITS Systems Engineering Review Form (SERF) to the Caltrans District Local Assistance Engineer (DLAE) as part of their E-76 Package. By answering the seven questions of the SERF, the local agency can determine if the ITS project is Low Risk (formerly “Minor”) or High Risk (formerly “Major”). The SERF is meant to be high-level project information and can be completed by public agency staff. The list below shows where in this regional ITS architecture documentation information can be fund to assist in writing a SERF
Applicants for Mass Transit Account funds need to provide the following information in the required FTA Transportation Electronic Award and Management (TEAM) system:
- The applicant needs to check the Self-Certification in the TEAM system, certifying compliance with the FTA National ITS Architecture Consistency Policy for Transit Projects.
- In the project description field, the applicant needs to make a statement that an applicable regional ITS architecture exists and that the ITS components in the project are part of the ITS architecture. The statement should also include that a Systems Engineering process was used to develop the ITS components of the project.
- The applicant should use the Non-Add Scope Codes in the project budget field to identify the ITS components of the project. Here are a few examples of the Non-Add Scope Codes for ITS component:
- 99300 – ITS Fleet Management
- 99400 – ITS Electronic Fare Management
- 99500 – ITS Traveler Information
Applicants can prepare itemized budgets with the ITS components separated out. Taking the three self-certification steps in TEAM is sufficient evidence of compliance with the FTA requirement at the time of grant award. FTA will use its oversight procedures to monitor compliance with the policy.
Though not required, FTA has a similar SERF form with the seven steps allowing grantees to document their use of a Systems Engineering process. Stakeholders can use information from the Regional ITS Architecture to fill out the FTA SERF form as described above for non-transit projects. The form will be made available on the FTA website at the time of grant award and prior to project triennial review. In most cases, the completed form would be requested during the triennial review; however, the FTA regional program manager can request earlier submission of the form. Applicants may use other means to document their use of the Systems Engineering process as long as it shows that the seven-step process has been followed.
Systems Engineering Process
The Systems Engineering process is a type of project planning process used for ITS projects. This process is required for major federally-funded ITS projects. The Systems Engineering Guidebook for ITS, co-sponsored by FHWA and Caltrans, is one resource for the Systems Engineering process. The following table outlines the basic System Engineering Process phases and how the Southern California Regional ITS Architecture can provide resources in each phase.
SYSTEMS ENGINEERING PHASE | ITS ARCHITECTURE RESOURCE |
|---|---|
Phase -1: Interfacing with Planning and the Regional Architecture | Regional Description, ITS Inventory |
Phase 0: Concept Exploration and Benefits Analysis | Regional Stakeholders, ITS Needs |
Phase 1: Project Planning and Concept of Operations Development (includes Systems Engineering Management Plan (SEMP)) | Regional Stakeholders, Operational Concepts |
Phase 2: System Definition and Design | Functional Requirements, Required Standards, Information Flows and Interface Requirements |
Phase 3: System Development and Implementation | Project Sequencing, Regional Stakeholders, Agency Agreements |
Phase 4: Validation, Operation & Maintenance, Changes & Upgrades | Regional Stakeholders, Agency Agreements, Architecture Maintenance |
Phase 5: System Retirement/Replacement | Not Available in Regional ITS Architecture |
Non-Transit Projects
One requirement of the Local Assistance Program Guidelines (LAPG) is that the local agency must follow the process to determine the level of risk for the ITS project. There are three types of project risk (Exempt, Low-Risk and High Risk) which determine the process for project funding and development. Local agencies first submit a Field Review Form that includes the ITS Systems Engineering Review Form (SERF) to the Caltrans District Local Assistance Engineer (DLAE) as part of their E-76 Package. By answering the seven questions of the SERF, the local agency can determine if the ITS project is Low Risk (formerly “Minor”) or High Risk (formerly “Major”). The SERF is meant to be high-level project information and can be completed by public agency staff.
The list below shows where in this regional ITS architecture documentation information can be fund to assist in writing a SERF.
SERF REQUIREMENT | ITS ARCHITECTURE RESOURCE |
|---|---|
Identification of portions of regional architecture being implemented | ITS Inventory |
Requirements definition | Functional Requirements |
Analysis of alternative system configurations and technology options to meet requirements | Not Available in Regional ITS Architecture |
Procurement options | Not Available in Regional ITS Architecture |
Identification of applicable ITS standards and testing procedures | Standards |
Procedures and resources necessary for operations and management of the system | Not Available in Regional ITS Architecture |
Transit Projects
One requirement of the Local Assistance Program Guidelines (LAPG) is that the local agency must follow the process to determine the level of risk for the ITS project. There are three types of project risk (Exempt, Low-Risk and High Risk) which determine the process for project funding and development. Local agencies first submit a Field Review Form that includes the ITS Systems Engineering Review Form (SERF) to the Caltrans District Local Assistance Engineer (DLAE) as part of their E-76 Package. By answering the seven questions of the SERF, the local agency can determine if the ITS project is Low Risk (formerly “Minor”) or High Risk (formerly “Major”). The SERF is meant to be high-level project information and can be completed by public agency staff. The list below shows where in this regional ITS architecture documentation information can be fund to assist in writing a SERF
Applicants for Mass Transit Account funds need to provide the following information in the required FTA Transportation Electronic Award and Management (TEAM) system:
- The applicant needs to check the Self-Certification in the TEAM system, certifying compliance with the FTA National ITS Architecture Consistency Policy for Transit Projects.
- In the project description field, the applicant needs to make a statement that an applicable regional ITS architecture exists and that the ITS components in the project are part of the ITS architecture. The statement should also include that a Systems Engineering process was used to develop the ITS components of the project.
- The applicant should use the Non-Add Scope Codes in the project budget field to identify the ITS components of the project. Here are a few examples of the Non-Add Scope Codes for ITS component:
- 99300 – ITS Fleet Management
- 99400 – ITS Electronic Fare Management
- 99500 – ITS Traveler Information
Applicants can prepare itemized budgets with the ITS components separated out. Taking the three self-certification steps in TEAM is sufficient evidence of compliance with the FTA requirement at the time of grant award. FTA will use its oversight procedures to monitor compliance with the policy.
Though not required, FTA has a similar SERF form with the seven steps allowing grantees to document their use of a Systems Engineering process. Stakeholders can use information from the Regional ITS Architecture to fill out the FTA SERF form as described above for non-transit projects. The form will be made available on the FTA website at the time of grant award and prior to project triennial review. In most cases, the completed form would be requested during the triennial review; however, the FTA regional program manager can request earlier submission of the form. Applicants may use other means to document their use of the Systems Engineering process as long as it shows that the seven-step process has been followed.
Systems Engineering Process
The Systems Engineering process is a type of project planning process used for ITS projects. This process is required for major federally-funded ITS projects. The Systems Engineering Guidebook for ITS, co-sponsored by FHWA and Caltrans, is one resource for the Systems Engineering process. The following table outlines the basic System Engineering Process phases and how the Southern California Regional ITS Architecture can provide resources in each phase.
SYSTEMS ENGINEERING PHASE | ITS ARCHITECTURE RESOURCE |
|---|---|
Phase -1: Interfacing with Planning and the Regional Architecture | Regional Description, ITS Inventory |
Phase 0: Concept Exploration and Benefits Analysis | Regional Stakeholders, ITS Needs |
Phase 1: Project Planning and Concept of Operations Development (includes Systems Engineering Management Plan (SEMP)) | Regional Stakeholders, Operational Concepts |
Phase 2: System Definition and Design | Functional Requirements, Required Standards, Information Flows and Interface Requirements |
Phase 3: System Development and Implementation | Project Sequencing, Regional Stakeholders, Agency Agreements |
Phase 4: Validation, Operation & Maintenance, Changes & Upgrades | Regional Stakeholders, Agency Agreements, Architecture Maintenance |
Phase 5: System Retirement/Replacement | Not Available in Regional ITS Architecture |