BBB_OBVSS_System_Requirements_Matrix.xlsx
XLSX spreadsheet 32 KB Posted
- Solicitation number
- 485
- Issued by
- Los Angeles County, San Francisco City, California
About this file
This is a Functional Requirements Matrix for the City of Santa Monica Department of Transportation (SMDOT) Onboard Bus Video Surveillance System (OBVSS) procurement. The document establishes 94 mandatory and optional technical requirements that vendors must address in their proposals. The OBVSS encompasses onboard recording and storage components, including network video recorders (NVRs) capable of supporting up to 32 IP cameras with resolutions ranging from 1920x1080 pixels (Full HD) to 3840x2160 pixels (4K); video management system (VMS) software for cloud or on-premises deployment; interior and exterior camera systems with integrated infrared and microphone capabilities; audio recording functionality; wireless and cellular communications infrastructure; integration with existing multiplex control systems and passenger-facing displays; and cybersecurity measures compliant with CJIS standards and U.S. data residency requirements. The project includes fleet-wide installation across SMDOT's fixed-route bus fleet, with pilot installations required on at least one standard 40-foot bus and one 60-foot articulated bus prior to full deployment. Vendors must provide detailed installation schedules, functional verification testing, a 30-day operational acceptance period, comprehensive training, and complete as-built documentation.
The requirements matrix mandates a minimum one-year warranty on all hardware and software with the option for extended coverage up to six years at the City's discretion. System support during the warranty period includes technical support, software patches, firmware updates, and security updates at no additional cost. Vendors are responsible for removal of existing OBVSS equipment, installation labor, and restoration of all vehicle components to original condition. The matrix requires vendors to provide separate pricing for camera deployment alternatives, including full replacement and a hybrid option utilizing existing compatible cameras supplemented with new 360 or fisheye interior cameras. Optional pricing is requested for advanced analytics capabilities such as automated passenger counting, operator distraction detection, and passenger fall event detection, as well as for optional video recording solutions for approximately 15 non-revenue support vehicles. All training must be conducted in-person at SMDOT's maintenance facility and include both operational and maintenance personnel, with comprehensive documentation provided in digital format.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Request_for_Proposals_for_Onboard_Bus_Video_Surveillance_System.pdf | ||
| Architecture_Questionnaire.pdf | ||
| OBVSS_Cost_Proposal_Schedule.xlsx | XLSX spreadsheet | |
| Enterprise_Core_Technologies.pdf | ||
| VISA_Questionnaire.pdf | ||
| Software_Maintenance_Agreement_Template.docx | DOCX document | |
| Software_as_a_Service_Template_(11-25).docx | DOCX document | |
| A-Proposer_Checklist.pdf | ||
| D-Software_Maintenance_Agreement_Template.docx | DOCX document | |
| City_of_Santa_Monica_VISA_Questionnaire.pdf | ||
| Proposer_Checklist.pdf |
Show all 11
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
Functional Requirements Matrix
| Big Blue Bus — OBVSS System Requirements Matrix | |||||||
| Vendor Instructions: Select a response for each requirement. Describe all exceptions, dependencies, substitutions, or proposed alternatives and cite the applicable proposal section. | |||||||
| Requirement ID | Source Clause | Category | Requirement | Requirement Type | Vendor Response | Comments/Exceptions | Proposal Reference |
| OBVSS-001 | 3.3.1.1 | Onboard Recording & Storage | Each vehicle shall be equipped with a high-definition network video recorder (NVR) or similar product (analog devices not accepted). | Mandatory | |||
| OBVSS-002 | 3.3.1.2 | Onboard Recording & Storage | The NVR shall be capable of withstanding vibration consistent with public transit, temperature ranging from -10 degrees F to 120 degrees F, and humidity ranging from 5% - 95% non-condensing. | Mandatory | |||
| OBVSS-003 | 3.3.1.3 | Onboard Recording & Storage | The NVR shall support a minimum of eight (8) cameras with the ability to expand up to 32 IP cameras as needed. | Mandatory | |||
| OBVSS-004 | 3.3.1.4 | Onboard Recording & Storage | The NVR shall support all of the following types of cameras: |
• IP Cameras including 360° and/or Fisheye IP Cameras using TCP/IP connectivity.
• Cameras with a minimum resolution of 1920x1080 pixels (Full HD or FHD) – up to 32.
| • Cameras with a resolution of 3840x2160 pixels (4K/Ultra HD/UHD) – up to 8. | Mandatory | ||||
| OBVSS-005 | 3.3.1.5 | Onboard Recording & Storage | The NVR shall support a minimum of six (6) discrete inputs. A discrete input is defined as an input that can receive a voltage signal to denote an action (brake, left turn signal, right turn signal, hazard lights, kneel, wheelchair ramp deployments, etc.) that happens onboard the vehicle. | Mandatory | |
| OBVSS-006 | 3.3.1.6 | Onboard Recording & Storage | The NVR shall be able to support both battery and ignition power configurations. | Mandatory | |
| OBVSS-007 | 3.3.1.7 | Onboard Recording & Storage | The NVR shall capture GPS data, speed, and other telemetry. | Mandatory | |
| OBVSS-008 | 3.3.1.8 | Onboard Recording & Storage | The NVR shall have an integrated G-Force sensor to tag video based on G-force based events. | Mandatory | |
| OBVSS-009 | 3.3.1.9 | Onboard Recording & Storage | The NVR shall support a user configurable automatic shutdown timer. | Mandatory | |
| OBVSS-010 | 3.3.1.10 | Onboard Recording & Storage | The NVR shall operate on 9-32 VDC. | Mandatory | |
| OBVSS-011 | 3.3.1.11 | Onboard Recording & Storage | The NVR shall include an integrated 3-axis accelerometer. | Mandatory | |
| OBVSS-012 | 3.3.1.12 | Onboard Recording & Storage | The NVR shall have an integrated clock that is powered by a separate battery integrated to the NVR. | Mandatory | |
| OBVSS-013 | 3.3.1.13 | Onboard Recording & Storage | The NVR shall have a fully integrated J1939 interface incorporated into the NVR. | Mandatory | |
| OBVSS-014 | 3.3.1.14 | Onboard Recording & Storage | The NVR shall have the ability to output video signal to a monitor via either HDMI (Digital output or BCN (analog output). | Mandatory | |
| OBVSS-015 | 3.3.1.15 | Onboard Recording & Storage | The NVR shall store and manage video data from interior and exterior cameras within the vehicle. | Mandatory | |
| OBVSS-016 | 3.3.1.16–3.3.1.17 | Onboard Recording & Storage | The NVR shall have a removable / hot-swappable hard drive and review station for manual video retrieval. The removable drive caddy shall have enough capacity to store at least 600 hours per month, per bus, of continuous retention at required camera resolutions and frame rates. | Mandatory | |
| OBVSS-017 | 3.3.1.18 | Onboard Recording & Storage | Retention calculations shall be based on minimum recording assumptions of: |
• 4K roadway camera at 15 fps
• Interior and exterior 1080p cameras at 15 fps minimum
• H.265 or equivalent compression
| • Continuous recording mode unless event-based recording is proposed as an approved alternate | Mandatory | ||||
| OBVSS-018 | 3.3.1.21 | Onboard Recording & Storage | The onboard storage solution shall support redundant mirrored storage or equivalent fault-tolerant architecture. | Mandatory | |
| OBVSS-019 | 3.3.1.22 | Onboard Recording & Storage | Each PoE ethernet port integrated into the NVR shall support 802.3af; each port supporting a full 15.4W. | Mandatory | |
| OBVSS-020 | 3.3.1.23 | Onboard Recording & Storage | The NVR shall provide sufficient aggregate PoE power to support all required onboard cameras, including 4K, 360°, and IR-enabled cameras, operating simultaneously at full load (minimum 120w aggregate PoE budget). | Mandatory | |
| OBVSS-021 | 3.3.1.24 | Onboard Recording & Storage | The NVR shall not require cameras with certain power requirements to be connected to specific PoE ports. All PoE ports shall provide similar connectivity. | Mandatory | |
| OBVSS-022 | 3.3.1.25 | Onboard Recording & Storage | The OBVSS shall provide on board communication capability to enable wireless data download and remote configuration of on-board camera system via router devices and Wi-Fi when the vehicle is in the yard. | Mandatory | |
| OBVSS-023 | 3.3.1.26 | Onboard Recording & Storage | The OBVSS shall be configurable so that the NVR can continue downloading video footage over Wi-Fi using onboard routers (either existing or installed by proposer) even after the vehicle’s ignition is turned off, drawing on battery power for a pre-determined amount of time or until the download is completed, whichever amount of time is lesser. | Mandatory | |
| OBVSS-024 | 3.3.1.27 | Onboard Recording & Storage | The system shall be able to support live video streaming and requested video download with end-to-end latency not to exceed 500 milliseconds under normal operating conditions and shall maintain packet loss below 1% while operating over yard Wi-Fi and cellular connectivity. | Mandatory | |
| OBVSS-025 | 3.3.2.2 | Video Management & Evidence | The VMS shall not require a specialized PC or other PC equipment to view, download, or access recorded content beyond a hard drive dock. | Mandatory | |
| OBVSS-026 | 3.3.2.3 | Video Management & Evidence | Licensing shall support all required SMDOT operational, maintenance, supervisory and administrative users without additional per-user charges during the warranty/support term. | Mandatory | |
| OBVSS-027 | 3.3.2.4 | Video Management & Evidence | The VMS shall be a client/server software solution. | Mandatory | |
| OBVSS-028 | 3.3.2.5 | Video Management & Evidence | The VMS shall support integration with the City’s identity management environment, including Entra ID (Azure Active Directory) to authenticate all users using industry-standard protocols such as SAML 2.0, OAuth 2.0, or OpenID Connect/ and role-based access controls. | Mandatory | |
| OBVSS-029 | 3.3.2.6 | Video Management & Evidence | The VMS shall have the ability to process user scheduled video/data offload requests. | Mandatory | |
| OBVSS-030 | 3.3.2.7 | Video Management & Evidence | The VMS shall allow for the video to be: |
• Exported to common, widely compatible formats like MP4, AVI or MOV.
• Downloaded and distributed to use without additional software being required.
| • Provide options for downloading video at different quality/resolutions as needed. | Mandatory | ||||
| OBVSS-031 | 3.3.2.8 | Video Management & Evidence | The VMS shall have the ability to provide automated email alerts for system health status. | Mandatory | |
| OBVSS-032 | 3.3.2.9 | Video Management & Evidence | The VMS shall utilize database(s) for storage/retrieval of audio / video data. | Mandatory | |
| OBVSS-033 | 3.3.2.11 | Video Management & Evidence | The VMS shall provide system-wide health status as well as detailed NVR logs for issue diagnosis. | Mandatory | |
| OBVSS-034 | 3.3.2.12 | Video Management & Evidence | Requested video files shall be provided as a single file. Segmented video, or “blocks” are not acceptable. | Mandatory | |
| OBVSS-035 | 3.3.2.14 | Video Management & Evidence | The user shall have the ability to review partially downloaded video in the event that the entire video segment has not completed downloading. | Mandatory | |
| OBVSS-036 | 3.3.2.15 | Video Management & Evidence | The system shall be capable of real-time video monitoring to enable users to view video from the on-board system in real-time over cellular or Wi-Fi data including live look-in capabilities. | Mandatory | |
| OBVSS-037 | 3.3.2.16–3.3.2.20 | Video Management & Evidence | The VMS shall provide comprehensive video search and review capabilities, including search by date/time and vehicle location, map-based vehicle location display, metadata display during video review, and the ability to blur or redact identifying features during video retrieval or post-download. | Mandatory | |
| OBVSS-038 | 3.3.2.21 | Video Management & Evidence | The VMS shall have the ability to perform ridership validation. At a minimum, it shall have a system whereby the VMS will download a single video file which only shows video from a specific route during passenger boarding times (door-open to door-close). | Mandatory | |
| OBVSS-039 | 3.3.2.22 | Video Management & Evidence | The VMS shall have the ability to operate on an on-prem server or as a cloud hosted solution based on SMDOT desired configuration. | Mandatory | |
| OBVSS-040 | 3.3.3.1 | Camera System | All cameras shall be IP cameras powered via PoE. | Mandatory | |
| OBVSS-041 | 3.3.3.2 | Camera System | All cameras shall support a minimum resolution of 1920 x 1080 pixels (Full HD or FHD). | Mandatory | |
| OBVSS-042 | 3.3.3.3 | Camera System | All cameras (both interior & exterior) shall have integrated IR’s for capturing video in low light conditions. | Mandatory | |
| OBVSS-043 | 3.3.3.4 | Camera System | All interior cameras shall have an integrated microphone within the camera housing. | Mandatory | |
| OBVSS-044 | 3.3.3.5 | Camera System | All exterior cameras shall have an environmental rating of IP67 or greater. | Mandatory | |
| OBVSS-045 | 3.3.3.6 | Camera System | When required for onboard monitoring, proposer shall provide low-latency video output solution in order to minimize latency on monitors. | Mandatory | |
| OBVSS-046 | 3.3.3.7 | Camera System | All cameras shall provide an image that is stable and free from vibration. | Mandatory | |
| OBVSS-047 | 3.3.4.2 | Camera System | The Proposer shall ensure that the proposed camera layout provide continuous evidentiary coverage of all passenger boarding, alighting, operator interaction, ADA securement, articulation, stairwell, and exterior hazard zones. Blinds spots shall be minimized through the use of additional fixed, 360°, or fisheye cameras where necessary. | Mandatory | |
| OBVSS-048 | 3.3.4.7 | Camera System | Proposers shall provide separate pricing for the following camera deployment alternatives: |
• Full Camera Replacement: Complete replacement of all onboard cameras with proposer-provided equipment.
| • Hybrid Camera Reuse Option: Utilization of existing serviceable IP cameras currently installed on vehicles where compatible the proposed OBVSS, combined with installation of at least one (1) 360° or fisheye interior camera per vehicle and replacement of any incompatible or failed cameras. | Mandatory | ||||
| OBVSS-049 | 3.3.5.1 | Audio Recording | The system shall have the ability to record independent audio on each internal camera. | Mandatory | |
| OBVSS-050 | 3.3.5.2 | Audio Recording | The system shall have the ability to independently playback each channel of audio without the corresponding video channel being shown. | Mandatory | |
| OBVSS-051 | 3.3.5.3 | Audio Recording | The OBVSS shall capture dialogue and sounds inside the vehicle. The functionality shall be designed to provide acceptable audio recording functionality given background noise under prevailing operating conditions. Audio shall record synchronously with video feeds from selected cameras onboard the vehicle so that the audio recording is associated with each camera image when downloaded and viewed. | Mandatory | |
| OBVSS-052 | 3.3.6.2 | Wireless and Cellular Communications | Proposers shall provide and recommend their own dedicated onboard router, modem, gateway, or equivalent communications solution required to support the proposed OBVSS, including live view, wireless offload, remote configuration, and health monitoring functions, and the costs associated with the solution. | Mandatory | |
| OBVSS-053 | 3.3.6.5 | Wireless and Cellular Communications | The system shall have the ability to download requested data via both 802.11 wireless and cellular networks. | Mandatory | |
| OBVSS-054 | 3.3.6.6 | Wireless and Cellular Communications | The proposer’s OBVSS shall include onboard communications with the following specifications: |
• Cellular 4G/5G functionality
• 802.11n/ac/ax
| • Dual-band 2.4 GHz / 5 GHz with preference for 5 GHz yard offload. | Mandatory | ||||
| OBVSS-055 | 3.3.7.1 | Multiplex and MFD Integration | The proposed OBVSS shall be fully compatible with the existing multiplex control system currently installed on the SMDOT fleet, including the Dinex / I/O Controls multiplex architecture and associated display logic used to activate rear-view camera displays and driver Multi-Function Displays (MFDs). | Mandatory | |
| OBVSS-056 | 3.3.7.3 | Multiplex and MFD Integration | The OBVSS shall be capable of automatically routing the designated rear-facing camera feed to the existing MFD or rear-view monitor with minimal latency and without degradation of image quality. | Mandatory | |
| OBVSS-057 | 3.3.7.4 | Multiplex and MFD Integration | The Proposer shall be responsible for identifying all interface requirements, signal conversion devices, software configuration, multiplex programming coordination, and integration modules necessary to ensure compatibility with the existing multiplex environment. | Mandatory | |
| OBVSS-058 | 3.3.7.6 | Multiplex and MFD Integration | The proposer shall provide a written description and schematic of how the proposed system will integrate with the existing multiplex and Dinex control logic. | Mandatory | |
| OBVSS-059 | 3.3.8.1–3.3.8.2 | Passenger Entry Monitor Integration | The proposed OBVSS shall integrate with existing passenger-facing monitors above the operator compartment. On vehicles equipped with compatible 10-inch HDMI touchscreen displays, the proposer shall utilize the existing displays to continue providing a live entrance-door camera feed unless replacement is necessary for compatibility or performance reasons. | Mandatory | |
| OBVSS-060 | 3.3.8.3, 3.3.8.6 | Passenger Entry Monitor Integration | Where existing passenger-facing monitors are incompatible with the proposed OBVSS, the proposer shall provide and install replacement monitors, identify all affected vehicles in the implementation plan, and include all replacement hardware and installation costs in the base proposal. | Mandatory | |
| OBVSS-061 | 3.3.8.4 | Passenger Entry Monitor Integration | The Proposer shall identify all required hardware, cabling, signal converters, mounting brackets, and software configuration necessary to maintain compatibility with the existing touchscreen display devices. | Mandatory | |
| OBVSS-062 | 3.3.8.5 | Passenger Entry Monitor Integration | Replacement monitors shall, at a minimum: |
• Be a minimum of 10 inches diagonal display size
• Support HDMI digital video input
• Provide continuous live display of the entrance-door camera feed
• Be industrial / transit-grade and designed for vibration, temperature, and transit vehicle environments
• Be securely mounted in a vandal-resistant enclosure
| • Provide brightness and contrast sufficient for daylight passenger visibility | Mandatory | ||||
| OBVSS-063 | 3.3.9.1 | Hosting, Cybersecurity & Data | If the proposed VMS is cloud-hosted, the Proposer shall provide a secure commercial cloud hosting solution, which may include Microsoft Azure, Azure Government, or an equivalent commercially available cloud platform that meets City cybersecurity and data protection requirements. | Mandatory | |
| OBVSS-064 | 3.3.9.2 | Hosting, Cybersecurity & Data | The Proposer shall clearly identify the proposed hosting environment, including cloud provider, hosting region(s), data residency, and system architecture. | Mandatory | |
| OBVSS-065 | 3.3.9.3 | Hosting, Cybersecurity & Data | The System shall support the latest stable versions of major web browsers, including Chrome, Edge, Safari, and Firefox, and be fully usable on both desktop and mobile devices without requiring a native app. | Mandatory | |
| OBVSS-066 | 3.3.9.4 | Hosting, Cybersecurity & Data | Where installation of system software is required on City computers, the software shall be compatible with Windows 11 and all future Microsoft Windows operating system releases. | Mandatory | |
| OBVSS-067 | 3.3.9.5 | Hosting, Cybersecurity & Data | The System shall be hosted in a cloud environment with data residency in the continental United States and compliance with applicable federal, state, and municipal data handling regulations. | Mandatory | |
| OBVSS-068 | 3.3.9.6 | Hosting, Cybersecurity & Data | The Proposer shall provide a detailed description of the cloud hosting architecture, including at a minimum: |
• Primary hosting region and backup / failover region
• System redundancy and high-availability design
• Automated data backup and disaster recovery procedures
• Recovery time objective (RTO) and recovery point objective (RPO)
• Data encryption in transit and at rest
• Role-based access controls and multi-factor authentication
• Audit logs for user access, exports, deletions, and system changes
• Cybersecurity monitoring, intrusion detection, and vulnerability management
• Patch management and update deployment process
| • Compliance with applicable CJIS, public records, and City IT security requirements | Mandatory | ||||
| OBVSS-069 | 3.3.9.8 | Hosting, Cybersecurity & Data | Where the system may be used for law enforcement coordination, evidentiary retention, or investigative purposes, the Proposer shall identify how the solution supports CJIS-aligned security controls, including access logging, encryption, and U.S.-based data residency where applicable. | Mandatory | |
| OBVSS-070 | 3.4.1 | Additional Components | The OBVSS shall include a remote LED status display which shows the health status of the system and is easily viewable by the driver without opening the equipment cabinet. | Mandatory | |
| OBVSS-071 | 3.4.2 | Additional Components | The OBVSS shall include a driver-accessible event marker button or equivalent operator-initiated trigger that allows the operator to manually flag and preserve video associated with an incident or noteworthy event. | Mandatory | |
| OBVSS-072 | 3.5.3 | Installation and Acceptance | Installer will be responsible for removing existing OBVSS. | Mandatory | |
| OBVSS-073 | 3.5.4 | Installation and Acceptance | Installation will be handled by the vendor or the vendor’s selected sub-contractor. | Mandatory | |
| OBVSS-074 | 3.5.5.1 | Installation and Acceptance | Prior to fleet-wide installation, the Proposer shall complete pilot installations on at least one (1) standard 40-foot bus and one (1) 60-foot articulated bus, if applicable. | Mandatory | |
| OBVSS-075 | 3.5.5.2 | Installation and Acceptance | Pilots shall be reviewed and approved by SMDOT prior to the commencement of full fleet deployment. | Mandatory | |
| OBVSS-076 | 3.5.6.1 | Installation and Acceptance | The Proposer shall provide a detailed fleet installation schedule, including projected daily/weekly vehicle quantities, installation sequence, milestone dates, and estimated total project duration. | Mandatory | |
| OBVSS-077 | 3.5.8.1 | Installation and Acceptance | Following installation on each vehicle, the Proposer shall perform functional verification testing including, at a minimum: |
• All camera views
• Audio recording
• Live view functionality
• Wireless offload
• Rear-view monitor / MFD integration
• Reverse trigger activation
• Passenger entry monitor display
| • GPS and metadata capture | Mandatory | ||||
| OBVSS-078 | 3.5.9.1 | Installation and Acceptance | Following completion of fleet installation, the system shall undergo a thirty (30) day operational acceptance test period during which system functionality, wireless downloads, live viewing, storage, and alerting functions shall be verified prior to final project sign-off. | Mandatory | |
| OBVSS-079 | 3.5.10.1 | Installation and Acceptance | The Proposer shall restore all vehicle panels, equipment compartments, wireways, mounting surfaces, and interior finishes to original condition following installation activities. | Mandatory | |
| OBVSS-080 | 3.5.11.1 | Installation and Acceptance | The Proposer shall provide as-built documentation for each vehicle type, including wiring diagrams, camera locations, monitor connections, NVR locations, and multiplex integration points. | Mandatory | |
| OBVSS-081 | 3.6.1 | Warranty & Lifecycle Support | The Proposer’s solution shall provide the City with a warranty for the system for a minimum of one (1) year warranty on all provided hardware and maintenance support. | Mandatory | |
| OBVSS-082 | 3.6.2 | Warranty & Lifecycle Support | The one (1) year warranty period shall begin at completion and sign off of the project. | Mandatory | |
| OBVSS-083 | 3.6.3 | Warranty & Lifecycle Support | The Contractor shall provide the City the option of purchasing extended warranties for the system for an additional five (5) years [ie. Years 2-6], exercised at the City’s sole discretion. | Mandatory | |
| OBVSS-084 | 3.6.4 | Warranty & Lifecycle Support | System support during the warranty period shall include technical support for all hardware and software, as well as providing, licensing, installing and integrating all released software patches and upgrades for the system. All software updates, security patches, firmware updates, bug fixes, and technical support for the VMS, mobile applications, onboard NVR firmware, and associated system components shall be included at no additional cost during the base warranty and maintenance support term. | Mandatory | |
| OBVSS-085 | 3.7.1–3.7.2 | Training & Documentation | Initial training to be conducted in person at BBB's Maintenance Facility. Vendors shall provide a detailed training plan including topics to be covered, and quantity of training hours, for maintenance and operational users. | Mandatory | |
| OBVSS-086 | 3.7.3 | Training & Documentation | Technical training for maintenance shall include, at a minimum: |
• All aspects of maintaining the OBVSS include but are not limited to repair, replacement, installation, troubleshooting, diagnostics, and preventative maintenance activities of all OBVSS components.
| • Alls aspects of using the VMS system, include, but are not limited to, video retrieval, reporting, alert management, troubleshooting, and advanced user regarding configuration of the system, user access, and assets. | Mandatory | |||
| OBVSS-087 | 3.7.4 | Training & Documentation | User guides, troubleshooting manuals, preventative maintenance instructions, equipment material lists, wiring diagrams, or other documented materials for the use and maintenance of system and associated hardware are required. | |
| • These materials should be provided in digital form. | Mandatory | |||
| OBVSS-088 | 3.8.1 | Maintenance & Customer Support | Vendor to provide a thorough explanation of the RMA process including but not limited to: |
• Steps required to initiate RMA
• Method of submitting an RMA request
• Average turnaround time for repair, replacement or refund
• Whether expedited RMA processing is available for critical failures
• Communication channels for tracking updates on RMAs
| • Any costs to the customer related to the RMA process (e.g. shipping) | Mandatory | ||||
| OBVSS-089 | 3.8.2.1 | Maintenance & Customer Support | Vendor shall provide documented instructions for recommended preventative maintenance (PM) activities, including recommended PM frequency, and PM inspection checklist of onboard equipment, including NVR units, cameras, power supplies, and connectivity modules. | Mandatory | |
| OBVSS-090 | 3.9.4 | Optional Technology | Proposers currently developing, piloting, testing, or commercially offering such capabilities may provide a separate narrative description of: |
• Current maturity level
• Existing deployments
• Active pilot programs
• Known limitations
• Required hardware or cloud dependencies
| • Expected implementation timeline | Optional | |||
| OBVSS-091 | 3.9.3, 3.9.5 | Optional Technology | Any optional AI or advanced analytics capability shall be submitted as a separately priced optional alternate, clearly segregated from the base proposal cost. |
Examples of such capabilities may include, but are not limited to:
• Automated passenger counting and occupancy analytics
• Operator distraction or inattentive driving detection
• Passenger fall event detection
• Door-area incident analytics
• Mobility device / wheelchair securement monitoring concepts
• Passenger behavior analytics related to boarding and alighting
| • Hazard-zone awareness and passenger movement analytics | Optional | |||
| OBVSS-092 | 3.10.1 | Optional System for Non-Revenue Support Vehicles | In addition to the fixed-route fleet, the City operates approximately fifteen (15) non-revenue support vehicles. As an optional alternate, the Proposer may provide forward-facing or other recommended vehicle camera recording solutions for these vehicles. |
If proposing this option, the Proposer shall describe:
• The recommended camera hardware and recording platform.
• Whether the solution integrates with the proposed OBVSS Video Management System.
• Storage methodology (onboard, cloud, or hybrid).
• Video retrieval process.
• GPS, date/time, and event metadata capabilities.
• Cellular connectivity requirements, if applicable.
| • Warranty and support provisions. | Optional | ||||
| OBVSS-093 | 3.10.4 | Optional System for Non-Revenue Support Vehicles | The Proposer shall identify any differences between the proposed vehicle solution and the transit bus OBVSS, including any limitations related to integration, software functionality, or video management. | Optional | |
| OBVSS-094 | 3.10.5 | Optional System for Non-Revenue Support Vehicles | Pricing for this optional alternate shall be provided separately in the Cost Proposal Schedule and shall include, at a minimum: |
• Camera hardware
• Recording device (if required)
• Installation
• Mounting hardware
• Software licensing
• Cellular equipment and service (if applicable)
• Warranty
• Any recurring subscription or cloud-hosting fees Optional
File details come from the government source that posted it. Updated .