C250014_Exhibit_A_Scope_of_Work_Attachment_A.xlsx
XLSX spreadsheet 1 MB Posted
- Solicitation number
- 250014
- Issued by
- Orange County, California
About this file
This is a Scope of Work and requirements attachment (RFP 250014 Exhibit A) for the Orange County Transportation Authority (OCTA) Harbor Boulevard Transit Signal Priority (TSP) Deployment project. The OCTA seeks a cloud-based SaaS solution to implement transit signal priority operations across multiple jurisdictions including Fullerton, Anaheim, Garden Grove, Santa Ana, and Fountain Valley. The system must integrate with Swiftly transit data services and communicate with traffic signal controllers from manufacturers including Econolite, McCain, Trafficware, Q-Free, and Yunex. The solution shall support real-time bus location data processing, estimated time of arrival calculations, and NTCIP 1211-compliant priority request messaging. The project encompasses 52 signalized intersections along Harbor Boulevard, with implementation staged across the five participating cities. The vendor must deliver a fully functional system with comprehensive reporting capabilities, user role-based access controls, and multi-factor authentication security features. The contract term is five years beginning upon OCTA's acceptance of the project, with all-inclusive licensing, hosting, maintenance, and support included.
The system must achieve 99.9% uptime availability with service credits applied for degradation below this threshold, with recovery point objectives of 24 hours or less and recovery time objectives of 24 hours or less for disaster recovery. The vendor shall provide SOC 2 compliance certification, maintain Tier 2 or greater cloud infrastructure, and ensure all OCTA and city data is returned within 60 days of contract termination. Maintenance and support must include response times of two hours for Priority 1 critical issues, four hours for Priority 2 urgent issues, and 24 hours for Priority 3 routine requests. Security updates and patches must be applied within 30 days of release, with major software versions no more than two releases behind current versions. The vendor is responsible for all necessary hardware, software, and environmental infrastructure provisioning, including potential signal controller upgrades at specified intersections. Pricing shall be consolidated into a single licensing agreement with disclosure of enterprise licensing options and cost-effectiveness comparisons.
View the file
Other files
Show all 18
On GovTribe
Work with this file
- Download the original file
- Contacts named in this file
- Similar government files
- Ask GovTribe AI about this file
Text version
TOC
Table of Contents
| VENDOR TO COMPLETE | |
| A1. VENDOR RESPONSE INSTRUCTIONS | |
| A2. FUNTIONAL REQUIREMENTS LISTS | |
| A2. NON-FUNCTIONAL REQUIREMENTS LISTS | |
| A3. VENDOR QUESTIONAIRE |
| SYSTEM REFERENCE DOCUMENTS | |
| B1: REPORTS | |
| B2: INTERFACES AND DATA EXCHANGE | |
| B3: SYSTEM USERS | |
| B4: PROJECT STUDY AREA | |
| B5: LOCATION DEMOGRAPHICS | |
| B6: OCTA SYSTEM TOPOLOGY DIAGRAMS |
&"Arial,Bold"RFP 250014
EXHIBIT A
ATTACHMENT A
A1 Requirement Response Instructions *Note: Please use the following table to respond.
| Functional and Non-Functional Requirements List | |
| OCTA's Priority | Description |
| 1 - Required | Requirement is available in organizations current solution. |
| 2 - Preferred / Nice to Have | Requirement is not required but is preferred. |
| 3 - Out of Scope | Out of scope for this RFP. No response needed. |
| Responses for both Functional and Non-Functional Requirements | |
| Proposed Solution's Capability | Description |
| Yes | Software has the ability to meet the requirements functionality and is available in the current version of software. |
| Exception | Software has the ability to meet the requirement, explanation required. |
| Future Enhancement | Software feature is approved and the product roadmap and includes a timeframe. |
| Not Available | Software does not have the functionality and no plans for the function in product roadmap. |
| Method to Implement | Description |
| OOtB with configurations | The "Out-Of-the-Box" product has this capability using system configuration(s) . |
| Software Customization | Requirement can be met when software is customized. |
| Software Customization and 3rd Party Software | Both a product customization and 3rd party software would be required to meet this requirement. |
| 3rd Party Software | Other customers accomplish this requirement using 3rd party software. |
| Column Color Codes | |
| To be filled out by OCTA | |
| To be filled out by Vendor |
&G &"Arial,Bold"RFP 250014
EXHIBIT A
Printed on: &D at &T Page &P of &N &A
A2 Functional
| INFORMATION PROVIDED BY OCTA | TO BE UPDATED BY THE PROPOSER / VENDOR | ||||||
| ID | System Requirement | Category | Sub-category | Process | OCTA's Priority | Proposed Solution's Capability | |
| Tim Watson: Does the solution meet the requirement? | Method to Implement |
Tim Watson: How is the Requirement achieved?
Software Customization Cost Tim Watson: What is the cost to implement this software customization?
| If the proposed software customization will satisfy multiple requirements, then the cost by line item is not required. Instead, the Vendor shall reference the Customization in their requirements response and include the Customization's costs in the Price Summary Sheet. | 3rd Party Software Cost |
| Tim Watson: If a piece of 3rd Party software is software is proposed to satisfy multiple requirements, then the cost by line item is not required. Instead, the Vendor shall reference the 3rd Party Software in their requirements response and include the 3rd Party Software and interface development costs in the Price Summary Sheet. | Comments |
| Tim Watson: Proposer Comments may be added to the Vendor’s response for any requirement. If Customization or Partial Customization, then the Vendor should explain level of effort and risk. If Future Release, the Vendor should indicate target release number and date within project timeline. If 3rd Party software is proposed, the Vendor should indicate which software. | Assumptions |
Tim Watson: Identify and include any assumptions, as necessary.
| 1 | As a user, I will have the ability to log into the transit signal priority (TSP) system using secure, authenticated credentials issued by my city or authorized agency. | Functional | Security | Role Based Access Control | 1 - Required |
| 2 | As a user, I will have the ability to access the system only if my credentials are verified through multi-factor authentication (MFA) or equivalent secure login protocols. | Functional | Security | Role Based Access Control | 1 - Required |
| 3 | As a user, I will have the ability to access the TSP data, metrics, and configuration tools relevant to my city with read-only access to other locations (e.g., Garden Grove users will see Fullerton intersections but will not be able to modify). | Functional | Security | Role Based Access Control | 1 - Required |
| 4 | As a user, I will have the ability to be assigned a role (e.g., administrator, analyst, viewer), which determines the extent of my permissions (view-only vs. editable access). | Functional | Security | Role Based Access Control | 1 - Required |
| 5 | As a user, I will have the ability to request changes to user access levels and permissions through a centralized or city-level administrator. | Functional | Security | Role Based Access Control | 1 - Required |
| 6 | As a system administrator, I will have the ability to run reports that show which users are assigned to which security roles. | Functional | Security | Reporting/Analytics | 1 - Required |
| 7 | As a system administrator, I will have the ability to run reports that display the configuration of security roles, including permissions/functions granted. | Functional | Security | Reporting/Analytics | 1 - Required |
| 8 | As a user, I will have the ability to run reports on system parameter settings (e.g., thresholds, integration configurations, defaults). | Functional | Security | Reporting/Analytics | 1 - Required |
| 9 | As a system administrator, I will have the ability to run reports on workflow configurations, including steps, assigned roles, and approval paths. | Functional | Security | Reporting/Analytics | 1 - Required |
| 10 | As a user, I will have the ability to filter reports by user, role, department, parameter, or workflow type to find specific information quickly. | Functional | Security | Reporting/Analytics | 1 - Required |
| 11 | As a user, I will have the ability to export reports (e.g., PDF, Excel, CSV) for analysis, audit, and compliance purposes. | Functional | Security | Reporting/Analytics | 1 - Required |
| 12 | As a system administrator, I will have the ability to onboard new users, deactivate access, and assign roles as needed for city staff or third-party contractors. | Functional | Security | Security | 1 - Required |
| 13 | As a system administrator, I will have the ability to view an audit log of all user actions (e.g., changes to signal priority rules, manual overrides, dashboard access). | Functional | Security | Audit | 1 - Required |
| 14 | As a system administrator, I will have the ability to monitor login activity by city, user ID, and timestamp to detect unauthorized access attempts. | Functional | Security | Audit | 2 - Preferred / Nice to Have |
| 15 | As a user, I need access to workflows and configuration options relevant to my assigned role(s), ensuring secure and efficient access. | Functional | Security | Security | 1 - Required |
| 16 | As a system, I must authenticate and authorize users based on their assigned roles and permissions before granting access to workflows or configuration functions. | Functional | Security | Security | 1 - Required |
| 17 | As a system, I must enforce role-based access control (RBAC) to ensure users only see and perform tasks they are permitted to. | Functional | Security | Security | 1 - Required |
| 18 | As a system, I must provide a centralized role and function catalog where administrators can define, assign, or revoke user roles. | Functional | Security | Security | 1 - Required |
| 19 | As a system, I must support workflow visibility rules that ensure users only view workflows applicable to their role(s). | Functional | Security | Configuration | 1 - Required |
| 20 | As a system, I must maintain basic configuration settings (e.g., system parameters, integration points, notifications) with access restricted to authorized roles (e.g., system administrators). | Functional | Security | Configuration | 1 - Required |
| 21 | As a user, the system must provide audit logs and reports showing which users hold which roles and what functions they have access to. | Functional | Security | Audit | 1 - Required |
| 22 | As a user, the system must capture and display changes to user roles, including who made the change, what was changed, and when. | Functional | Security | Audit | 1 - Required |
| 23 | System must be able to generate workflow access reports, showing user participation, approvals, and workflow history by role. | Functional | Security | Reporting/Analytics | 1 - Required |
| 24 | System must provide a configuration change log that tracks updates to key system settings, accessible to auditors and compliance officers. | Functional | Security | Reporting/Analytics | 1 - Required |
| 25 | System must generate accurate and up-to-date reports on user role assignments. | Functional | Security | Reporting/Analytics | 1 - Required |
| 26 | System must generate reports showing role configurations and their associated permissions. | Functional | Security | Reporting/Analytics | 1 - Required |
| 27 | System must generate reports on system parameter settings. | Functional | Security | Reporting/Analytics | 1 - Required |
| 28 | System must generate reports on workflow configurations (steps, participants, routing rules). | Functional | Security | Reporting/Analytics | 1 - Required |
| 29 | System must provide filtering and search functions within reporting modules. | Functional | Security | Reporting/Analytics | 1 - Required |
| 30 | System must provide secure export functionality (PDF, Excel, CSV) restricted to authorized roles. | Functional | Security | Reporting/Analytics | 1 - Required |
| 31 | System will be capable to send real-time bus and signal data securely, using end-to-end encryption (e.g., TLS/SSL) to prevent interception or tampering. | Functional | Security | Data Transmission | 1 - Required |
| 32 | System will be capable to receive real-time bus and signal data securely, using end-to-end encryption (e.g., TLS/SSL) to prevent interception or tampering. | Functional | Security | Data Transmission | 1 - Required |
| 33 | System will be configurable to protect transmitted data where it matters such as; |
-Bus Onboard Systems (i.e., Automatic Vehicle Location AVL / CAD-AVL systems, Onboard communications modules cellular, DSRC, or 5G modems) -Traffic Signal Controllers (i.e., Local controllers at intersection) -Traffic Management Center (TMC) Systems (i.e., Cloud-hosted, on-prem systems that process requests, arbitrate priority, push signal timing adjustments.)
| -Transit Operations Center Systems ( i.e., scheduling systems, data warehouse AVL/TSP logs, API's if integrated with traffic signals) | Functional | Security | Data Transmission | 1 - Required | ||
| 34 | System will comply with industry standard cyber security framework (e.g. NIST 800-53, CJIS guidelines (if applicable), Local agency cybersecurity policies | Functional | Security | Compliance | 1 - Required | |
| 35 | Cloud Based System will have the ability to support TSP operations with ATC-compliant signal controllers, including those from major manufacturers (i.e., Econolite, McCain, Trafficware, Q-Free, and Yunex) | Functional | TSP Handling | Compliance | 1 - Required | |
| 36 | System will have the ability to manage signal priority operations for multiple bus routes spanning several city jurisdictions using cloud-based coordination. | Functional | Integration | Data Transmission | 1 - Required | |
| 37 | System shall be capable of receiving both static and real-time General Transit Feed Specification (GTFS) data from Swiftly at near real-time intervals. | Functional | Signal Request | Data Transmission | 1 - Required | |
| 38 | System will have the ability to interface with Swiftly data services to ingest near real-time bus location updates for use in transit signal priority (TSP) logic. | Functional | Integration | Data Transmission | 1 - Required | |
| 39 | System will have the ability to calculate Estimated Time of Arrival (ETA) updates as frequent as the data is received from Swiftly. | Functional | Signal Request | Reporting/Analytics | 1 - Required | |
| 40 | System will have the ability to associate each transit vehicle with a Swiftly “run” number and dynamically update route data in real time. | Functional | Signal Request | Reporting/Analytics | 1 - Required | |
| 41 | System will have the ability to generate NTCIP 1211 Priority Request messages when a bus approaches a signalized intersection under qualifying conditions. | Functional | Signal Request | Reporting/Analytics | 1 - Required | |
| 42 | System will have the ability to communicate with signal controllers using the NTCIP 1211 standard protocol. | Functional | TSP Handling | Compliance | 1 - Required | |
| 43 | System will have the ability to transmit priority requests to field signal controllers using standard traffic protocols (e.g., NTCIP 1211). | Functional | Signal Request | Data Transmission | 1 - Required | |
| 44 | System will have the ability to evaluate TSP conditions (e.g., lateness threshold, route eligibility, direction) before issuing a request. | Functional | Infrastructure | Data Management | 2 - Preferred / Nice to Have | |
| 45 | System shall support simultaneous priority requests for multiple buses operating on the same corridor for both directions as well as intersecting corridors. Conflicts for overlapping resolved based on configurable priority logic. | Functional | Signal Request | Data Transmission | 2 - Preferred / Nice to Have | |
| 46 | System will have the ability to host TSP logic, control rules, and data processing in a secure, cloud-based environment. | Functional | Infrastructure | Data Management | 1 - Required | |
| 47 | System will have the ability to ingest and integrate signal data and controller settings from multiple city central systems to the cloud. | Functional | Infrastructure | Data Management | 1 - Required | |
| 48 | System will have the ability to collect and store detailed logs of all TSP events, including timestamps, vehicle IDs, intersection IDs, and outcomes. | Functional | Performance Metrics | Reporting/Analytics | 1 - Required | |
| 49 | System will have the ability to report Key Performance Indicators (KPIs) such as, but not limited to the following: |
-ETA accuracy and variability -TSP request success rate -Average green delay/extension time -On-time performance improvement
| -Reduction in bus stop delay | Functional | Performance Metrics | Reporting/Analytics | 1 - Required |
| 50 | System will have the ability to report and visualize performance metrics that integrate bus and signal data for operational analysis, which may include but is not limited to the following: |
- Delay for main street and side street movements at signalized intersections
- Green time taken from each phase per signalized intersection
- TSP requests per approach per signalized intersection
- Reason for denial of TSP request
| - Travel time comparison (e.g., before/after, between vehicles and bus on the route, etc.) | Functional | Performance Metrics | Reporting/Analytics | 2 - Preferred / Nice to Have | ||
| 51 | System will have the ability to customize performance metric reports as define by OCTA. | Functional | Performance Metrics | Reporting/Analytics | 2 - Preferred / Nice to Have | |
| 52 | System will have the ability to log and process TSP data independently per city, ensuring local control of signal behavior. | Functional | System Configurability | Rules/Parameters | 1 - Required | |
| 53 | System will have the ability to apply TSP rules per city while still maintaining corridor-level logic for coordinated routing. | Functional | System Configurability | Rules/Parameters | 1 - Required | |
| 54 | System will have the ability to define and adjust activation parameters, such as: |
-Threshold (in seconds) to broadcast ETA and/or request priority by intersection -Minimum delay threshold (in seconds) -Time of day or day-of-week rules
| -Intersection-specific behavior | Functional | System Configurability | Rules/Parameters | 2 - Preferred / Nice to Have | ||
| 55 | System will have the ability to import or edit GTFS and route configuration files to align with transit operations. | Functional | System Configurability | Rules/Parameters | 2 - Preferred / Nice to Have | |
| 56 | System will have the ability to apply rule changes without interrupting ongoing operations, using a web-based admin console. | Functional | System Configurability | Rules/Parameters | 1 - Required | |
| 57 | System will have the ability to detect communication failures with controllers or vehicles and automatically revert to normal traffic signal operation. | Functional | Failover/Recovery | Data Management | 1 - Required | |
| 58 | System will have the ability to alert relevant city staff in case of hardware malfunction, data latency, or rule conflicts. | Functional | Failover/Recovery | Data Management | 1 - Required | |
| 59 | System will have the ability to generate real-time alerts in the event of equipment malfunctions or communication failures across any component of the TSP network. | Functional | Scalability | Monitoring | 1 - Required | |
| 60 | System will have the ability to retry failed priority requests within a defined retry window. | Functional | Failover/Recovery | Data Management | 2 - Preferred / Nice to Have | |
| 61 | System will have the ability to integrate with city-level systems such as Advanced Traffic Management Systems (ATMS), transit dispatch, or 3rd-party analytics platforms. | Functional | Integration | Data Management | 2 - Preferred / Nice to Have | |
| 62 | System will have the ability to expose Application Programming Interfaces (APIs) for integration with Traffic Management Centers (TMCs), Advanced Traffic Management Systems (ATMS), and internally or externally developed dashboards. | Functional | Integration | Data Management | 1 - Required | |
| 63 | System will have the ability to export data in standardized formats (CSV, JSON, API) for external reporting or research purposes. | Functional | Integration | Data Management | 1 - Required | |
| 64 | System will have the ability to update individual components (e.g., bus logic module, analytics engine) without affecting overall system uptime. | Functional | Scalability | Reporting/Analytics | 1 - Required | |
| 65 | System will have the ability to scale horizontally to support additional intersections or bus routes in future phases. | Functional | Scalability | Reporting/Analytics | 1 - Required | |
| 66 | System will have the ability to compute each bus’s ETA and transmit it to a minimum of the next three (3) upstream signalized intersections. | Functional | Signal Request | Reporting/Analytics | 1 - Required | |
| 67 | System will have the ability to calculate each bus’s Estimated Time of Departure (ETD) from stops and use this value to refine ETA predictions for upcoming intersections. | Functional | Signal Request | Reporting/Analytics | 2 - Preferred / Nice to Have | |
| 68 | System will have the ability to manage signal priority for both near-side and far-side bus stops, including the ability to cancel or restart TSP requests when the vehicle door opens at a near-side stop. | Functional | TSP Handling | Data Transmission | 2 - Preferred / Nice to Have | |
| 69 | System will have the ability to allow configurable thresholds for initiating priority requests, including parameters such as schedule adherence, passenger load, route identity, and traffic volume adjusted by time-of-day or corridor-specific conditions. | Functional | System Configurability | Data Management | 2 - Preferred / Nice to Have | |
| 70 | System will have the ability to allow authorized users to manually override or block TSP operations at specific intersections or across the entire corridor. | Functional | System Configurability | Rules/Parameters | 1 - Required | |
| 71 | System will have the ability to support at least five (5) levels of transit priority to differentiate between regular fixed-route buses, rapid services, and emergency or special vehicles. | Functional | Scalability | Reporting/Analytics | 2 - Preferred / Nice to Have | |
| 72 | System will have the ability to expand to support additional transit modes (e.g., streetcars, shuttles, demand-response vehicles) with configurable rules for each mobility type. | Functional | Scalability | Modularity | 2 - Preferred / Nice to Have |
&G &"Arial,Bold"RFP 250014
EXHIBIT A
Printed on: &D at &T Page &P of &N &A
A2 Non-Functional
| INFORMATION PROVIDED BY OCTA | TO BE UPDATED BY THE PROPOSER / VENDOR | |||||
| ID | System Requirement | Category | Sub-category | OCTA's Priority | Proposed Solution's Capability | |
| Tim Watson: Does the solution meet the requirement? | Method to Implement |
Tim Watson: How is the Requirement achieved?
Software Customization Cost Tim Watson: What is the cost to implement this software customization?
| If the proposed software customization will satisfy multiple requirements, then the cost by line item is not required. Instead, the Vendor shall reference the Customization in their requirements response and include the Customization's costs in the Price Summary Sheet. | 3rd Party Software Cost |
| Tim Watson: If a piece of 3rd Party software is software is proposed to satisfy multiple requirements, then the cost by line item is not required. Instead, the Vendor shall reference the 3rd Party Software in their requirements response and include the 3rd Party Software and interface development costs in the Price Summary Sheet. | Comments |
| Tim Watson: Proposer Comments may be added to the Vendor’s response for any requirement. If Customization or Partial Customization, then the Vendor should explain level of effort and risk. If Future Release, the Vendor should indicate target release number and date within project timeline. If 3rd Party software is proposed, the Vendor should indicate which software. | Assumptions |
Tim Watson: Identify and include any assumptions, as necessary.
| 1 | As a user, I need the ability to view my assigned user role(s) and their corresponding functions/permissions so that I understand what actions I can perform in the system. | Non-Functional / Technical | System Credits | 1 - Required |
| 2 | System shall support pre-configured, tested integration with Swiftly APIs or GTFS-RT feeds to ensure low-latency data processing. | Non-Functional / Technical | Scalability | 1 - Required |
| 3 | System shall be scalable to support additional bus routes and jurisdictions without requiring major architecture changes, provided central communication link is present. | Non-Functional / Technical | Scalability | 1 - Required |
| 4 | The system’s web-based dashboard shall meet OCTA’s non-functional standards by providing secure access, real-time data visibility, configurable controls, and status reporting with appropriate authentication, encryption, and performance guarantees. | Non-Functional / Technical | Scalability | 1 - Required |
| 5 | System shall have demonstrated operational deployment in a minimum of three (3) separate jurisdictions for a duration of at least one (1) year prior to deployment. | Non-Functional / Technical | Deployment | 1 - Required |
| 6 | It is required that the system is web based (SaaS). | Non-Functional / Technical | Administration Console | 1 - Required |
| 7 | Application must have a method for defining and managing User roles and access. | Non-Functional / Technical | Application Security | 1 - Required |
| 8 | Software and hardware shall be commercial-off-the-shelf (COTS) product(s) for TSP. | Non-Functional / Technical | Core Software | 1 - Required |
| 9 | Ability to audit data changes based on certain criteria. | Non-Functional / Technical | Database | 1 - Required |
| 10 | All data is property of OCTA and shall be returned to OCTA within sixty (60) calendar days of the end of the contract. | Non-Functional / Technical | Database | 1 - Required |
| 11 | An acceptable timeframe for the production environment to be down before activating the disaster recovery (DR) site is 12 hours. Beyond 12 hours activation of DR may be required by consultation with OCTA IT Staff. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 12 | At a minimum, the Recovery Point Objective (RPO) shall be 24 hours or less. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 13 | At a minimum, the Recovery Time Objective (RTO) shall be 24 hours or less. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 14 | Both parties shall mutually agree to activate the DR site. OCTA reserves the right to request the DR to be activated sooner or later than 12 hours based on the current situation. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 15 | Development and maintenance of a runbook detailing procedures and roles to initiate DR services. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 16 | Vendor shall provision the Data Center, hardware and software and will assist OCTA with any OCTA required hardware and software provisioning. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 17 | Vendor will annually test to review their internal procedures for activating the DR site and provide OCTA a report of the outcome. The report should include, but is not limited to, actual RPO/RTO times, issues and corrective action taken. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 18 | In the event of a disaster Vendor will provide access to the recovery center facility (setup within the United States) and provides cut-over services if required by OCTA Information systems operations. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 19 | No fee will be imposed when a disaster is called. | Non-Functional / Technical | Disaster Recovery | 1 - Required |
| 20 | A monthly report will be generated by the Support/Maintenance team, including but not limited to: details of logged Help Desk calls, availability of system, maintenance activities and tuning activities. | Non-Functional / Technical | Environment | 1 - Required |
| 21 | All changes to the infrastructure, hardware and software will be submitted to OCTA by a formal change request, and will be performed after OCTA provides acceptance. Vendor will work in alignment with OCTA to establish a change process. | Non-Functional / Technical | Environment | 1 - Required |
| 22 | All scheduled down-time will be done at the specific window(s) determined by consultation with OCTA. | Non-Functional / Technical | Environment | 1 - Required |
| 23 | Apply the latest upgrades, updates and patches within 30 days of release. Major operating systems and software applications must be no more the 2 releases off current version but security upgrades and patches must all be up to date within 30 days of release. | Non-Functional / Technical | Environment | 1 - Required |
| 24 | Vendor shall assist OCTA staff in the problem diagnostic process using vendor-provided tools, which may include front-end or back-end traces and other resources necessary for troubleshooting system issues. | Non-Functional / Technical | Environment | 1 - Required |
| 25 | At the software level, the system shall support administration of user accounts, including creation of new accounts, deletion of accounts, and password resets, with changes reflected in near real time. | Non-Functional / Technical | Environment | 1 - Required |
| 26 | Vendor SaaS/hosting facility will comply with applicable laws, rules and regulations regarding a safe work environment and fire protection measures and will maintain safety and security measures in accordance with level 3 or 4 data center standards. | Non-Functional / Technical | Environment | 1 - Required |
| 27 | If Vendor hosting facility shall operate and maintain the Environment, including the system hardware, system network and system operating software to level 3 or level 4 data center standards. | Non-Functional / Technical | Environment | 1 - Required |
| 28 | Vendor shall provision the necessary hardware, software and environment to allow OCTA to run the version of software initially licensed, and any future versions. | Non-Functional / Technical | Environment | 1 - Required |
| 29 | Vendor shall repair, upgrade or replace the environment components as necessary for the system to perform properly and be compatible with any future updates and version releases. | Non-Functional / Technical | Environment | 1 - Required |
| 30 | Vendor will immediately notify OCTA of a vendor or sub-contracted vendor security breach that impacts OCTA data and will provide regular status updates, at a minimum daily, until the breach is resolved. | Non-Functional / Technical | Environment | 1 - Required |
| 31 | Vendor will promptly notify OCTA of any compromise to the security of the hosting facility. | Non-Functional / Technical | Environment | 1 - Required |
| 32 | Vendor will use industry standard security measures, such as firewalls and standard encryption protocols, to protect OCTA data. | Non-Functional / Technical | Environment | 1 - Required |
| 33 | Hosting shall be provided in a Tier2 (or greater) cloud environment. | Non-Functional / Technical | Environment | 1 - Required |
| 34 | OCTA will only consider well-designed and previously implemented, proven software that is referenceable, has a demonstrated ease of use, asset management functionality consistent with Federal DOT guidelines for transit organizations, robust reporting capabilities, an advanced system integration architecture and superior product support. | Non-Functional / Technical | Environment | 1 - Required |
| 35 | Perform file restorations as required. | Non-Functional / Technical | Environment | 1 - Required |
| 36 | Repair all errors and faults which may include a reset or reboot of the server, restart of system services, installing patches by the operating system vendor. | Non-Functional / Technical | Environment | 1 - Required |
| 37 | The SaaS Environment will be available to OCTA 24 hours a day, seven days a week, 365 days a year (except for Scheduled Downtime events). | Non-Functional / Technical | Environment | 1 - Required |
| 38 | The system shall be accessible 24x7x365, with 99.9% up-time, i.e., annual down-time will not exceed 525.6 minutes per year. Penalties ramp up every 15 minutes if down-time exceeds maximum. Down-time allowance is reset annually on contract anniversary. | Non-Functional / Technical | Environment | 1 - Required |
| 39 | Vendor shall include in their Systems Integration narrative how their proposed SaaS-based software seamlessly integrates with OCTA’s existing on-premise production systems and databases. | Non-Functional / Technical | Environment | 1 - Required |
| 40 | Vendor shall list all required technical components (hardware, communications, environmental, infrastructure, etc.) with specifications and costs that enable the proposed Technical Solution to meet the performance, capacity and responsiveness of the system requirements. OCTA may discuss alternatives with the proposer to ensure that any hardware meets both the requirements of the proposer and conforms to OCTA’s technology infrastructure requirements and strategy. | Non-Functional / Technical | Environment | 1 - Required |
| 41 | At a minimum, OCTA expects a Service Organization Controls (SOC) 2 compliant environment. | Non-Functional / Technical | Environment Security | 1 - Required |
| 42 | If data is required from OCTA from a 3rd party network, it is preferred that the data be pushed from an OCTA system within OCTA’s DMZ via VPN tunnel | Non-Functional / Technical | Environment Security | 1 - Required |
| 43 | OCTA “IS Preferred Standards & Practices” should be addressed for non-OCTA managed environments when applicable. | Non-Functional / Technical | Environment Security | 1 - Required |
| 44 | Only privileged accounts may access and use tools with administrative capabilities, to conform to the concept of least privilege. | Non-Functional / Technical | Environment Security | 1 - Required |
| 45 | Physical destruction or degaussing of all media storage devices that retained Agency data will be done before releasing the media outside of the control of the Vendor; recording the date, time, method, and witness with a signed certificate of compliance. | Non-Functional / Technical | Environment Security | 1 - Required |
| 46 | Sensitive data will be protected, both in transit and while at rest. | Non-Functional / Technical | Environment Security | 1 - Required |
| 47 | System Security logs will be retained, and the Vendor shall be in compliance with all PII/PCI/HIPAA logging requirements (if applicable). | Non-Functional / Technical | Environment Security | 1 - Required |
| 48 | The Vendor shall immediately notify the Agencies Cyber Security team in the event (potential or real) of any incident/event resulting the loss (potential or real) of revenue, data, or security breach has occurred. | Non-Functional / Technical | Environment Security | 1 - Required |
| 49 | The Vendor shall maintain network security and confidentiality and provide the required software and monitoring tools to ensure network remains compliant with security standards, including: |
a. The appropriate administrative, technical, and physical safeguards designed to protect against Information Security Events. This should include regular security assessments; made available to OCTA as requested
b. Compliance, as required, to the requirements of applicable Data Protection Laws
c. Procedures for Change Management, patching, disaster recovery, and backups
| d. Provision of written information security policies for the Agency, as requested | Non-Functional / Technical | Environment Security | 1 - Required | ||
| 50 | The vendor’s technical staff will assist in evaluating OCTA’s architecture and configuration as related to security and access. | Non-Functional / Technical | Environment Security | 1 - Required | |
| 51 | The vendor’s technical staff will work with OCTA’s Security and project team to review security requirements in the new environment. | Non-Functional / Technical | Environment Security | 1 - Required | |
| 52 | Application Updates. Vendor shall periodically update the application to ensure compatibility and functionality. These updates may also contain application updates and fixes. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 53 | At project completion, all software use licenses and subscriptions shall be consolidated into a single licensing agreement to streamline renewals. The Vendor shall disclose whether an Enterprise Licensing option is available and specify the conditions under which it becomes more cost-effective than individual licenses or subscriptions. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 2 - Preferred / Nice to Have | |
| 54 | Software user licenses or cloud subscriptions shall be provisioned in alignment with the staged implementation rollout schedule. OCTA will procure licenses as required during the implementation project. Licenses for any third-party software included in the Vendor’s Technical Solution Design shall initially be provided through the Vendor, with subsequent renewals expected to be contracted directly between OCTA and the third-party provider. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 2 - Preferred / Nice to Have | |
| 55 | Firm shall provide all-inclusive license, hosting, maintenance, support, and other services for five (5) years, beginning with OCTA’s acceptance of the project. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 56 | The Vendor shall install all fixes provided in accordance with a process formally approved by OCTA | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 57 | Licenses: Vendor shall provide all licenses necessary for the successful development and use of this system. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 58 | Maintenance and Support: Vendor shall respond to all maintenance requests in a prompt and timely manner suitable for the Priority level defined below and at a maximum within twenty-four (24) hours for notification and action plan. Vendor shall provide OCTA with a point of contact (both email and phone number) to report issues. The Service Level Agreements (SLAs) are defined as follows: | ||||
| • | Priority 1: These are critical issues that impact usage of the system and for which there is no work-around. These need the fastest response and resolution. A response to OCTA shall occur within two (2) hours of the report and a plan to find and remedy the problem shall be put in place within one (1) business day. | ||||
| • | Priority 2: These are urgent issues for which there is a temporary work-around. A response to OCTA shall occur within four (4) hours of the report and a plan to find and remedy the problem shall be put in place within four (4) business days. | ||||
| • | Priority 3: This is the catch-all for all remaining issues or requests. A response to OCTA shall occur within twenty-four (24) hours of the report and a plan to find and remedy the problem should be put in place on an agreed-upon schedule. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 59 | Product release management services will occur throughout Project implementation timeline. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 60 | Software warranty and ongoing product support shall include security updates after the software is fully operational. | Non-Functional / Technical | License, Maintenance and Support, and Hosting | 1 - Required | |
| 61 | Reporting from the system databases shall complete in a time proportional to the number of records read but shall be on the order of tens of thousands of records per second. | Non-Functional / Technical | Performance | 1 - Required | |
| 62 | System maintenance activities (Backups, batch data transfers, etc.) shall complete within one to two hours each day, and shall not interrupt normal system functioning. | Non-Functional / Technical | Performance | 1 - Required | |
| 63 | The software should be capable of supporting a high volume of transactions, based on the expected usage by function across the locations identified in the B6 tab. Transactions must complete within a second and/or not more than the maximum performance metric, for the expected number of simultaneous users. The proposed software and hardware solution shall meet or exceed the performance expectations. | Non-Functional / Technical | Performance | 1 - Required | |
| 64 | Vendor shall include in their proposal their software SLA agreement reflecting the following performance criteria; any exceptions should be so noted and justified. See the SLA tab in this Excel file. | Non-Functional / Technical | Performance | 1 - Required | |
| 65 | The Vendor will perform all the efforts, actions and services as described in the Project Implementation Tasks documented within the scope of work (SOW). | Non-Functional / Technical | Project Implementation | 1 - Required | |
| 66 | The Vendor will produce all the Deliverables and documentation as described in the Project Implementation Tasks documented within the SOW. | Non-Functional / Technical | Project Implementation | 1 - Required | |
| 67 | In the event the licensed software falls below the 99.9% availability within a given month, service Credits will be applied to hosting fees. |
Greater than or equal to 97.0 and less than 99.9% is 10% of monthly Hosting Fees Greater than or equal to 96.5 and less than 97.0 is 20% of monthly Hosting Fees.
Greater than or equal to 96.0% and less than 96.5% is 40% of monthly Hosting Fees.
Greater than or equal to 95.0% and less than 96% is 50% of the monthly Hosting fees.
| For each .5% degradation after 95.0% of availability a 10% credit will be applied | Non-Functional / Technical | System Credits | 1 - Required | ||
| 68 | It is understood that Vendor will continue their best good faith effort to achieve the agreed upon service levels. | Non-Functional / Technical | System Credits | 1 - Required | |
| 69 | Note: OCTA is a 24 x 7 x 375 operation and we expect the system to be available 365 days a year, no holidays for bus operations, and should be taken into consideration when calculating up time. | Non-Functional / Technical | System Credits | 1 - Required |
&G &"Arial,Bold"RFP 250014
EXHIBIT A
Printed on: &D at &T Page &P of &N &A
A3
| Vendor Information |
| Vendor Name: |
| Contact Person: |
| Vendor's Security Contact (if different): |
| Date of Response: |
| Category | Questionnaire | Response |
| Data Protection | Where will OCTA (bus) and City (signal) data be stored? | |
| What encryption methods are employed for data transmission and storage? | ||
| Do you have backup recovery procedures in place? If Yes, describe. | ||
| Do you have disaster recovery procedures in place? If Yes, describe. | ||
| Do you have cybersecurity insurance? If Yes, describe coverage. | ||
| Does your cybersecurity insurance coverage include customers? If yes, describe. | ||
| Access Control | Describe your user authentication and authorization processes. | |
| How often are access controls reviewed? | ||
| How often are access controls updated? | ||
| How do you control access to our data? | ||
| Incident Response | Do you have a Cyber Incident Response Plan? | |
| Is your Cyber Incident Response Plan regularly tested? If Yes, describe. | ||
| What is the notification timeline to Client/Customers in the event of a data breach? | ||
| Compliance and Certification | Do you meet any major compliance standards (e.g., NTCIP, ISO 27001, SOC 2)? If yes, describe. | |
| How do you ensure compliance with relevant data protection laws and regulations? | ||
| Do you have an annual compliance report? If so, can you please provide it? | ||
| Infrastructure Security | Describe the security measures implemented in your physical and network infrastructure. | |
| Physical Security Measures: | ||
| Intrusion detection systems to detect unauthorized access | ||
| Regular maintenance and inspection of the infrastructure to identify and fix vulnerabilities | ||
| Network Security Measures: | ||
| Firewall systems to prevent unauthorized access to the network | ||
| Intrusion detection and prevention systems to detect and block malicious traffic | ||
| Encryption technologies to protect sensitive data | ||
| Regular software updates and patching to fix security vulnerabilities | ||
| Access control mechanisms such as passwords, multi-factor authentication, and role-based access control | ||
| Network segmentation to isolate sensitive data and limit the impact of security breaches | ||
| How do you protect against Distributed Denial of Service (DDoS) attacks and other network threats? | ||
| Employee Training | How do you educate/train your employees about cybersecurity awareness and best practices? | |
| Third-Party Security | Do you use third-party vendors? If yes, how do you ensure their security practices align with yours? | |
| Can you provide a list of third-party vendors involved in our services? | ||
| Do you contract with any offshore third-party vendors? | ||
| Software Development Security | What secure coding practices do you follow during software development? | |
| How do you address vulnerabilities and apply patches to your software? | ||
| Application Response | General Performance Assessment | |
| What are the key performance indicators (KPIs) for this application? | ||
| How does the system perform under normal operating conditions? | ||
| Are there any performance benchmarks for comparison? | ||
| System Resource Utilization | ||
| How much CPU, memory, and disk I/O does the application consume? | ||
| Are there any memory leaks or high CPU usage spikes? | ||
| Does the system utilize multiple cores efficiently? | ||
| Response Time & Latency | ||
| What is the average response time for critical operations? | ||
| Are there noticeable delays in specific processes? If yes, what processes and what is the delay (in seconds) for each impacted process? | ||
| How does the application handle real-time requests? | ||
| User interface to menu selections average response time? | ||
| Log in response average response time? | ||
| Log off average response time? | ||
| Record Save average response time? | ||
| Simple Report query report average response time? | ||
| Complex Report query report average response time? | ||
| Print request average response time? | ||
| Dashboard refresh average response times? | ||
| Batch Processing average response time? (if applicable) | ||
| Scalability & Load Handling | ||
| How does the system perform under peak load conditions? | ||
| What is the maximum number of concurrent users the system can support? | ||
| Does the system scale horizontally or vertically? | ||
| Network Performance | ||
| What is the average network latency for data transmission? | ||
| Are there any network bottlenecks affecting performance? | ||
| Is data compression used to optimize network usage? | ||
| Application Architecture | ||
| Is the software designed using microservices or a monolithic approach? | ||
| How is caching implemented to improve performance? | ||
| Are third-party integrations affecting system speed? | ||
| Error Handling & System Logs | ||
| Are there recurring errors or performance-related logs? | ||
| How are exceptions and failures handled in the system? | ||
| What monitoring tools are used to track errors and warnings? | ||
| Security & Performance Trade-offs | ||
| Are there security measures that impact performance (e.g., encryption, authentication)? | ||
| How does the system handle secure transactions without sacrificing speed? | ||
| Are there any performance concerns with Application Programming Interface (API) rate limiting? | ||
| Optimization & Future Improvements | ||
| Are there performance testing tools in place (e.g., JMeter, LoadRunner)? | ||
| How frequently is the application updated for performance enhancements? | ||
| Technical Assessment | Model (SaaS, Cloud, On-Premise) | |
| Which cloud provider (e.g., Azure, AWS, etc.) is being used for this solution? | ||
| Database and version required | ||
| What are the supported Browsers (Indicate which is the preferred browser when more than one browser is available)? | ||
| Are there specific desktop requirements (hardware, OS, and software) to connect to the cloud solution? | ||
| What are the mobility functions (is the application browser-based, or is application downloaded from App Store or Play Store onto the mobile device)? | ||
| What are the reporting functions (e.g. Business Objects, Jasper, Cognos, Proprietary)? | ||
| Service-Level Agreements (SLA’s) for P1 Issues (see SLA tab for definition) | ||
| SLA’s for P2 Issues (see SLA tab for definition) | ||
| SLA’s for P3 Issues (see SLA tab for definition) | ||
| SLA’s for P4 Issues (see SLA tab for definition) | ||
| Transit Signal Priority (TSP) Requests | ||
| What TSP messages are being sent to the traffic controllers (e.g. estimated arrival time (ETA), TSP request, etc.)? | ||
| How far in advance (in seconds) can the system generate a TSP message to the signal controllers? | ||
| What is the system's operational latency from data receipt to TSP request issuance? | ||
| What is the system's marging of error (e.g. ±5 seconds for 90% of predictions) in the TSP message? | ||
| What TSP responses (e.g. TSP enabled, green extend, green delay, etc.) are being captured from the traffic controllers that will be used for reporting and performance monitoring? | ||
| Software | ||
| Software Licenses (Perpetual or Annual Fees) | ||
| What is the “Uptime” percentage over a rolling 30-day window (based on cloud system operation and not on communication failures in the field)? | ||
| What is the optimum frequency of bus location update to the cloud solution? | ||
| What is the optimum frequency of traffic signal information update to the cloud solutions? | ||
| List of software systems (bus and traffic signals) that have successful interfaces with this solution | ||
| Upgrades | ||
| Frequency upgrades will be installed | ||
| Level of Effort (High, Medium, Low) | ||
| Customizations and/or Personalization of system’s screens/UI - does the solution retain all the customizations and/or personalizations when an upgrade is applied? Or, do the customizations / personalizations need to be manually re-applied or re-configured? | ||
| Are upgrades included, or is there additional cost for upgrades? | ||
| What will be required for future scability to support concurrent operations (e.g. 2000 signalized intersections on different signal controllers and 500 buses with conflicting TSP requests)? | ||
| Interfaces/Integration | ||
| Programming or tools used (Webservices, XML, groovy, java, etc.) | ||
| Is ongoing support available or are these items under a warranty? If under warranty what is the warranty period. | ||
| Team | Total Duration of Implementation – Start/End | |
| Headquarters location of Software Firm | ||
| Office location of Implementation Team | ||
| Office location of System's Maintenance and Support Team | ||
| Solution Costs | Year 1 Application Software/Licensing (support, maintenance, warranty) | |
| Year 2-5 Application Software/Licensing (support, maintenance, warranty) | ||
| Third Party Software (if applicable) | ||
| Traffic Signal Infrastructure Upgrades (see Signal Upgrades tab for details) | ||
| Signal Upgrades (see Signal Upgrades tab for details) |
&"Arial,Bold"RFP 250014
EXHIBIT A
Printed on: &D at &T Page &P of &N &A
B1
| B1. REPORTS | ||||
| Number | Name | File Type | Frequency | |
| New | Communication status: up-time for signals and status of buses, communication success | csv,xls,pdf | ||
| (exception: graphical would be pdf only but data would be csv, xls) | Weekly, 12-1 AM PST | |||
| New | Message Performace: Bus GPS location messages must be transmitted and received within 5 seconds or less to ensure real-time accuracy.The time of transaction (data handoff) across system integration points—between the bus AVL system, Swiftly, and traffic signal control—must occur within defined latency thresholds (≤ 5 seconds end-to-end). |
- Message Latency Definition: Average time from bus position capture to availability in traffic light control system.
- Transaction Success Rate Definition: % of transactions between integration points that are completed without delay or failure.
- End-to-End System Responsiveness Definition: Total time from bus location generation → integration point → traffic light response.
- Exception/Error Rate
| Definition: % of failed or delayed transactions beyond threshold. | csv,xls,pdf | Monthly, 12-1 AM PST |
| New | Key Performance Indicators: |
- ETA Accuracy and Variability Definition: Difference between predicted and actual bus arrival times at intersections or stops.
Purpose: Ensures reliable passenger information and supports accurate TSP activation.
- TSP Request Success Rate Definition: Percent of valid TSP (Transit Signal Priority) requests successfully received and processed by traffic signal controllers.
Purpose: Measures reliability of integration between bus systems and traffic signal systems.
- Average Green Delay/Extension Time Definition: Average number of seconds signals are held green or extended to accommodate buses.
Purpose: Ensures TSP effectiveness without excessive disruption to general traffic.
- On-Time Performance Improvement Definition: Percent improvement in bus on-time performance (scheduled vs. actual) after TSP implementation.
Purpose: Directly links TSP and synchronization to passenger service reliability.
- Reduction in Bus Stop Delay Definition: Reduction in dwell time at stops caused by traffic-related delays (not boarding/alighting).
| Purpose: Demonstrates passenger benefit and efficiency gains from reduced congestion delays. | csv,xls,pdf | Weekly, 12-1 AM PST |
| New | Trasit: Performance will be monitored using Swiftly data to measure schedule adherence, operational efficiency, on-time performance, dwell time, travel time, and traffic signal data to measure priority outcomes, TSP requests/success, arrivals on green at signalized intersections. |
- On-Time Performance Definition: % of buses arriving within the scheduled window (e.g., ≤1 minute early, ≤5 minutes late).
Purpose: Measures reliability of service and passenger experience.
- Dwell Time Definition: Average time spent at bus stops for boarding, alighting, and traffic-related hold.
Purpose: Identifies efficiency of boarding and impact of congestion/traffic signals.
- Travel Time Definition: Average time required to travel between defined…
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .