Attachment C – Specification Requirements Checklist.docx
DOCX document 59 KB Posted
- Attached to
- City of Wausau CAD/AVL Hardware, Software and Professional Services Wausau Transit System.
- Solicitation number
- 25-1019
- Issued by
- Marquette County, Wisconsin
About this file
Specification Requirements Checklist Summary
This is a specification requirements checklist for the City of Wausau Area Transit System's comprehensive CAD/AVL (Computer-Aided Dispatch/Automatic Vehicle Location) procurement. The checklist details functional and performance requirements across nine major system components: Service Design Software, System Supervisory Software, Automatic Passenger Counters (APC), On-Board Annunciator System, Driver Scheduling Software, CCTV Security System, On-Board Driver User Interface, Vehicle Location System, and Communication System, plus Data Management and Operations/Maintenance Requirements. The Service Design Software must support minimum fifty routes, 150 stops per route, and 100 vehicles with capabilities for route creation, performance analysis, and GTFS format schedule exports. System Supervisory Software requires real-time vehicle positioning with map displays updating every five seconds, historical playback functionality, and support for 100 vehicles and 100 drivers. The APC system must count passenger boardings and alightings at front and rear doors with data storage for minimum seven years (with granular location data retained for one year) and must meet Federal Transit Administration accuracy requirements of less than two percent missed counts. The On-Board Driver User Interface requires a minimum 11-inch touchscreen display with multitouch capability, login authentication through Windows Azure, fare type selection with minimum ten fare types, and transfer management functions. Proposals are due January 15, 2026, at 4:00 PM, with the deadline for submitting questions set for December 15, 2025 (not 2026 as stated in the opportunity summary).
The checklist establishes performance specifications across all components including environmental operating parameters (temperatures from -20 to +60 degrees Celsius and up to 95 percent non-condensing relative humidity), warranty requirements of minimum three years with optional two-year extensions, and comprehensive support services available 24/7/365 with one-hour response times for technical support and three-hour resolution times for service-disrupting issues. The communication system must provide Wi-Fi connectivity supporting 802.11ac and WPA3 standards with minimum 500 Mbit/second data rates and cellular connectivity with 5G/4G fallback providing coverage at minimum 1 Mbit/second over 98 percent of existing routes. Data management requires central SQL Server database storage with backup and recovery processes, query and export capabilities by date, time, vehicle ID, driver ID, route, and location, and export formats including CSV and Microsoft Excel. All system operational data must remain accessible to agency staff in exportable formats throughout the contract term. Training requirements include written materials provided one week before installation, online training materials for all user groups, and minimum two primary plus one make-up training session for each functional group including customer service, supervisors, drivers, vehicle maintenance staff, system administrators, and accounting personnel.
View the file
Other files
| File | Type | Posted |
|---|---|---|
| Attachment B - Bidders List.docx | DOCX document | |
| RFP_Final_20251201.docx | DOCX document | |
| Attachment F – Affidavit of Non-Collusion.docx | DOCX document | |
| Attachment A - Bidder Required Form.doc | DOC document | |
| Attachment E - Federal Clauses Non-Vehicles.pdf | ||
| Attachment H - Baseline Conditions Report.docx | DOCX document | |
| Attachment D - Pricing Proposal.docx | DOCX document | |
| Wausau CAD-AVL RFP Questions and Responses.pdf | ||
| Attachment G - Bidder Response Checklist.docx | DOCX document | |
| Detailed CAD AVL Customer Price Form.xlsx | XLSX spreadsheet |
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
ATTACHMENT C – SPECIFICATION REQUIREMENTS CHECKLIST
| Provided |
| Not Provided |
1. Service Design Software
| 1.1. Functional Requirements |
| ☐ |
| ☐ |
| 1.1.1. The service design software shall facilitate route creation and design, including: |
| ☐ |
| ☐ |
| 1.1.1.1. Turn by turn route shapes. |
| ☐ |
| ☐ |
| 1.1.1.2. Stop locations. |
| ☐ |
| ☐ |
| 1.1.1.3. Travel times between stops. |
| ☐ |
| ☐ |
| 1.1.1.4. Identification of route timepoints. |
| ☐ |
| ☐ |
| 1.1.1.5. The ability to create multiple patterns per route, where patterns may include regularly scheduled alternate schedules or route shapes. |
| ☐ |
| ☐ |
| 1.1.1.6. The importing of census data layers and work with street geometry including non-navigable roads and road capacity. |
| ☐ |
| ☐ |
| 1.1.1.7. Scheduled transfers between routes at locations beyond the downtown transfer center. |
| ☐ |
| ☐ |
| 1.1.1.8. Assigned schedules by days of the week. |
| ☐ |
| ☐ |
| 1.1.1.9. Calculation of milage and hours by type (revenue, dead head, etc.) of designed routes for reporting requirements. |
| ☐ |
| ☐ |
| 1.1.1.10. Transfer timing optimization. |
| ☐ |
| ☐ |
| 1.1.2. The software shall include route performance analysis features of existing, operating routes, including: |
| ☐ |
| ☐ |
| 1.1.2.1. Data Import from Supervisory Software (see Section 2.x) of historic travel times of vehicles. |
| ☐ |
| ☐ |
| 1.1.2.2. Data Import from Automatic Passenger Counters (see Section 3.x) by location and time. |
| ☐ |
| ☐ |
| 1.1.2.3. Route performance by time and geography. |
| ☐ |
| ☐ |
| 1.1.2.3.1. Performance metrics shall include ridership, operator hours, and mileage data. |
| ☐ |
| ☐ |
| 1.1.2.4. In service and out of service time. |
| ☐ |
| ☐ |
| 1.2. Performance Requirements |
| ☐ |
| ☐ |
| 1.2.1. The service design software shall support a minimum of fifty (50) routes. |
| ☐ |
| ☐ |
| 1.2.2. The service design software shall support a minimum of one hundred and fifty (150) stops per Route |
| ☐ |
| ☐ |
| 1.2.3. The service design software shall support a minimum of one hundred (100) vehicles |
| ☐ |
| ☐ |
| 1.2.4. Service design software shall have the ability to export schedules: |
| ☐ |
| ☐ |
| 1.2.4.1. To System Supervisory Software |
| ☐ |
| ☐ |
| 1.2.4.2. In static GTFS format compatible with Google’s requirements |
| ☐ |
| ☐ |
| 1.2.4.3. On a daily basis |
| ☐ |
| ☐ |
| 1.2.4.4. As needed with an on-demand export function. |
| ☐ |
| ☐ |
2. System Supervisory Software
| 2.1. Functional Requirements |
| ☐ |
| ☐ |
| 2.1.1. GTFS Real Time Output shall conform to industry standards (Google’s Live Transit Updates) including: |
| ☐ |
| ☐ |
| 2.1.1.1. Data elements |
| ☐ |
| ☐ |
| 2.1.1.2. Update Rate |
| ☐ |
| ☐ |
| 2.1.1.3. Publication |
| ☐ |
| ☐ |
| 2.1.2. Real-Time Vehicle Status |
| ☐ |
| ☐ |
| 2.1.2.1. Vehicle Positioning for real-time vehicle status shall meet requirements per Section 8. |
| ☐ |
| ☐ |
| 2.1.2.2. The Supervisory Software shall include a User Display |
| ☐ |
| ☐ |
| 2.1.2.2.1. The user display shall be accessible from all agency workstations. |
| ☐ |
| ☐ |
| 2.1.2.2.2. The user display shall display alert or error conditions if communication is lost (displayed with an icon color scheme) with a vehicle that has been logged in without a corresponding log out. |
| ☐ |
| ☐ |
| 2.1.2.2.2.1. Authentication LDAP |
| ☐ |
| ☐ |
| 2.1.2.2.3. The User Display shall include a Map including: |
| ☐ |
| ☐ |
| 2.1.2.2.3.1. The most current received vehicle positions. |
| ☐ |
| ☐ |
| 2.1.2.2.3.2. Updated vehicle locations at a rate of at least every five (5) seconds. |
| ☐ |
| ☐ |
| 2.1.2.2.3.3. User controls including but not limited to panning and zooming of the map display. |
| ☐ |
| ☐ |
| 2.1.2.2.3.4. Togglable layers of map content for visibility including: |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.1. Routes |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.2. Selectable map background including an option for a transportation base map and satellite image. |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.3. User definable landmarks (point data) |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.4. Vehicle Icons shall have selectable display features including: |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.4.1. Vehicle ID |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.4.2. Service Status |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.4.3. Driver ID |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.4.4. Compliance with route schedule and path |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5. An historical playback function that shall include: |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.1. An historical date selector |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.2. An historical time selector |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.3. A vehicle ID selector |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.4. A driver ID selector |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.5. A route selector |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.6. The ability to allow to show vehicle position at the selected time and date. |
| ☐ |
| ☐ |
| 2.1.2.2.3.4.5.7. The ability to allow for playback speed of up to a minimum of 10x real time. |
| ☐ |
| ☐ |
| 2.2. Performance Requirements |
| ☐ |
| ☐ |
| 2.2.1. The system supervisory software shall include the ability to report data on a minimum of 100 vehicles. |
| ☐ |
| ☐ |
| 2.2.2. The system supervisory software shall include the ability to report data on a minimum of 100 drivers. |
| ☐ |
| ☐ |
| 2.2.3. The system supervisory software shall meet storage requirements in Section 10. |
| ☐ |
| ☐ |
3. Automatic Passenger Counters (APC)
| 3.1. Functional Requirements |
| ☐ |
| ☐ |
| 3.1.1. The APC shall: |
| ☐ |
| ☐ |
| 3.1.1.1. Count individual passenger boardings. |
| ☐ |
| ☐ |
| 3.1.1.2. Count individual passenger alightings. |
| ☐ |
| ☐ |
| 3.1.1.3. Count all passenger movements at the front vehicle door. |
| ☐ |
| ☐ |
| 3.1.1.4. Count all passenger movements at the rear vehicle door. |
| ☐ |
| ☐ |
| 3.1.1.5. Not interfere with passenger movements through vehicle doors. |
| ☐ |
| ☐ |
| 3.1.2. The APC hardware shall use 12 VDC power, if powered from the vehicle. |
| ☐ |
| ☐ |
| 3.1.3. The APC shall acquire current vehicle position from the Vehicle Location System as described in Section 8. |
| ☐ |
| ☐ |
| 3.1.4. Data Management and Administration |
| ☐ |
| ☐ |
| 3.1.4.1. The APC system shall store the following attributes for each detected passenger movement: |
| ☐ |
| ☐ |
| 3.1.4.1.1. Movement type (board or alight). |
| ☐ |
| ☐ |
| 3.1.4.1.2. Boarding/alighting date and time. |
| ☐ |
| ☐ |
| 3.1.4.1.3. Boarding alighting location (as latitude/longitude). |
| ☐ |
| ☐ |
| 3.1.4.1.4. Vehicle ID and route #. |
| ☐ |
| ☐ |
| 3.1.4.2. The APC system shall store transaction attributes in a central database not located on the vehicle. |
| ☐ |
| ☐ |
| 3.1.4.3. The APC shall compute current passenger load after each bus stop event (door open/close cycle). |
| ☐ |
| ☐ |
| 3.1.4.4. The APC database shall store boarding alighting location (as numerical bus stop ID). |
| ☐ |
| ☐ |
| 3.1.4.5. The APC system shall update the central database at maximum of five (5) minute intervals. |
| ☐ |
| ☐ |
| 3.1.4.6. The central database shall store all boarding/alighting attributes for a minimum of seven (7) years. |
| ☐ |
| ☐ |
| 3.1.4.7. The central database shall store granular real-time location data for a minimum of one (1) year |
| ☐ |
| ☐ |
| 3.1.4.8. The central database shall be accessible from agency workstations. |
| ☐ |
| ☐ |
| 3.1.4.9. The APC data shall be available through the Service Design Software. |
| ☐ |
| ☐ |
| 3.1.4.10. The APC data shall be available through the System Supervisory Software. |
| ☐ |
| ☐ |
| 3.1.5. The APC system shall provide data query and extraction tools to allow agency staff to access and export data. |
| ☐ |
| ☐ |
| 3.1.5.1. The database shall allow data to be queried by date. |
| ☐ |
| ☐ |
| 3.1.5.2. The database shall allow data to be queried by time. |
| ☐ |
| ☐ |
| 3.1.5.3. The database shall allow data to be queried by vehicle ID. |
| ☐ |
| ☐ |
| 3.1.5.4. The database shall allow data to be queried by route ID. |
| ☐ |
| ☐ |
| 3.1.5.5. The database shall allow data to be queried by trip ID. |
| ☐ |
| ☐ |
| 3.1.5.6. The database shall allow data to be queried by location (through a lookup between latitude/longitude and named locations, such as bus stops). |
| ☐ |
| ☐ |
| 3.1.5.7. The database shall export data as a comma separated value text file. |
| ☐ |
| ☐ |
| 3.1.5.8. The database shall export data as a Microsoft Excel-compatible spreadsheet file. |
| ☐ |
| ☐ |
| 3.1.5.9. Data access and export may be provided by Service Design Software or System Supervisory Software in lieu of dedicate tools for requirements. |
| ☐ |
| ☐ |
| 3.1.5.10. The PC system may include a mapping display (dedicated not part of the Service Design Software or System Supervisory Software) for visualizing and analyzing data. |
| ☐ |
| ☐ |
| 3.2. Performance Requirements |
| ☐ |
| ☐ |
| 3.2.1. Environmental |
| ☐ |
| ☐ |
| 3.2.1.1. The APC shall function as defined in the manufacturer's specifications between the temperatures of -20 to +60 C. |
| ☐ |
| ☐ |
| 3.2.1.2. The APC shall function as defined in the manufacturer's specifications up to a non-condensing relative humidity level of 95 percent. |
| ☐ |
| ☐ |
| 3.2.2. Accuracy |
| ☐ |
| ☐ |
| 3.2.2.1. The APC shall adhere to the Federal Transit Administration’s (FTA) requirements for one hundred (100) percent counts as required for NTD Reporting. |
| ☐ |
| ☐ |
| 3.2.2.1.1. Less than two (2) percent of passenger counts shall be missed. |
| ☐ |
| ☐ |
| 3.2.2.1.2. The APC shall report scheduled trips with no counts. |
| ☐ |
| ☐ |
| 3.2.2.2. Upon installation the APC shall be validated per FTA guidelines in coordination with the FTA Validation Analyst representing Wausau Metro Ride. |
| ☐ |
| ☐ |
4. On-Board Annunciator System
| 4.1. Functional Requirements |
| ☐ |
| ☐ |
| 4.1.1. Announcement Triggers |
| ☐ |
| ☐ |
| 4.1.1.1. The Annunciator shall automatically play a message naming the upcoming stop name. |
| ☐ |
| ☐ |
| 4.1.1.2. The Annunciator shall select a message based on vehicle direction of travel and next stop on the current route or landmark. |
| ☐ |
| ☐ |
| 4.1.1.3. The Annunciator shall acquire position data from the vehicle location system as described in Section 8. |
| ☐ |
| ☐ |
| 4.1.1.4. The Annunciator shall play the message as the vehicle is leaving the previous stop. |
| ☐ |
| ☐ |
| 4.1.1.5. The Annunciator shall not announce a stop prior to passing the preceding stop. |
| ☐ |
| ☐ |
| 4.1.1.6. The pre-determined distances from the approaching stop used to trigger message playback may be configurable on a per-stop basis by agency personnel. |
| ☐ |
| ☐ |
| 4.1.1.7. The annunciator may play a message to announce end of line. |
| ☐ |
| ☐ |
| 4.2. Performance Requirements |
| ☐ |
| ☐ |
| 4.2.1. Environmental |
| ☐ |
| ☐ |
| 4.2.1.1. The system shall function as defined in the manufacturer's specifications between the temperatures of -20 to +60 C. |
| ☐ |
| ☐ |
| 4.2.1.2. The system shall function as defined in the manufacturer's specifications up to a non-condensing relative humidity level of 95 percent. |
| ☐ |
| ☐ |
| 4.2.1.3. Announcements shall be clearly audible above the background noise of vehicle operation and passenger conversation. |
| ☐ |
| ☐ |
| 4.2.1.3.1. The Annunciator system shall include multiple speakers if needed to ensure clarity for all seating positions on the vehicle. |
| ☐ |
| ☐ |
| 4.2.1.3.2. Annunciator system shall include automatic sound level adjustment based on vehicle load and time of day. |
| ☐ |
| ☐ |
| 4.2.1.3.3. The Annunciator system shall have the ability to include optional announcements such as detours and service changes. |
| ☐ |
| ☐ |
5. Driver Scheduling Software
| 5.1. Functional Requirements |
| ☐ |
| ☐ |
| 5.1.1. The system shall include the following functions: |
| ☐ |
| ☐ |
| 5.1.1.1. Importing service definition from Service Design Software. |
| ☐ |
| ☐ |
| 5.1.1.2. Generating driver work pieces consisting of: |
| ☐ |
| ☐ |
| 5.1.1.2.1. Date |
| ☐ |
| ☐ |
| 5.1.1.2.2. Route(s) |
| ☐ |
| ☐ |
| 5.1.1.2.3. Service start and end times from service schedules |
| ☐ |
| ☐ |
| 5.1.1.3. Automatically assigning vehicles to driver work pieces based on availability. |
| ☐ |
| ☐ |
| 5.1.1.4. Allowing manual adjustments to vehicle assignments. |
| ☐ |
| ☐ |
| 5.1.1.5. Allowing manual adjustments to driver assignments. |
| ☐ |
| ☐ |
| 5.1.2. System shall store driver information details including: |
| ☐ |
| ☐ |
| 5.1.2.1. Driver ID |
| ☐ |
| ☐ |
| 5.1.2.2. Driver name |
| ☐ |
| ☐ |
| 5.1.2.3. Driver phone number (for text message distribution) |
| ☐ |
| ☐ |
| 5.1.2.4. Driver seniority |
| ☐ |
| ☐ |
| 5.1.2.5. Driver medical exam expiration date |
| ☐ |
| ☐ |
| 5.1.2.6. Driver License expiration date |
| ☐ |
| ☐ |
| 5.1.2.7. Driver Commercial Driver’s License (CDL) status |
| ☐ |
| ☐ |
| 5.1.2.8. Driver Contact preference (mobile phone text or email) |
| ☐ |
| ☐ |
| 5.1.2.9. Driver Email |
| ☐ |
| ☐ |
| 5.1.3. Scheduling Parameters shall include: |
| ☐ |
| ☐ |
| 5.1.3.1. Per route vehicle restrictions |
| ☐ |
| ☐ |
| 5.1.3.2. Per driver route restrictions/preferences |
| ☐ |
| ☐ |
| 5.1.3.3. Driver CDL Status |
| ☐ |
| ☐ |
| 5.1.3.4. Driver availability restrictions per route |
| ☐ |
| ☐ |
| 5.1.3.5. Driver seniority preferences |
| ☐ |
| ☐ |
| 5.1.3.6. Scheduled time off |
| ☐ |
| ☐ |
| 5.1.3.7. Sick/unavailable real-time rescheduling |
| ☐ |
| ☐ |
| 5.1.4. Schedule Publication |
| ☐ |
| ☐ |
| 5.1.4.1. Driver schedules shall be available: |
| ☐ |
| ☐ |
| 5.1.4.1.1. In a printable format (such as pdf). |
| ☐ |
| ☐ |
| 5.1.4.1.2. As individual documents for each driver. |
| ☐ |
| ☐ |
| 5.1.4.1.3. On a daily basis. |
| ☐ |
| ☐ |
| 5.1.4.1.4. On a weekly basis. |
| ☐ |
| ☐ |
| 5.1.4.2. Driver schedules shall be distributed via preferred contact method. |
| ☐ |
| ☐ |
| 5.1.4.2.1. Message Content shall include driver report time and routes assigned. |
| ☐ |
| ☐ |
| 5.1.4.2.2. Messages shall be distributed by 2 PM the day before and assignment. |
| ☐ |
| ☐ |
| 5.1.4.2.3. Message distribution list shall be taken from driver information details. |
| ☐ |
| ☐ |
| 5.2. Performance Requirements |
| ☐ |
| ☐ |
| 5.2.1. The driver scheduling software shall report number of drivers. |
| ☐ |
| ☐ |
| 5.2.2. The driver scheduling software shall report number of routes. |
| ☐ |
| ☐ |
| 5.2.3. The driver scheduling software shall report number of vehicles. |
| ☐ |
| ☐ |
| 5.2.4. Schedule Update interval shall occur daily upon and manual edit/connection. |
| ☐ |
| ☐ |
| 5.2.4.1. The system shall only send updates to relevant individuals. |
| ☐ |
| ☐ |
6. CCTV Security System
| 6.1. Functional Requirements |
| ☐ |
| ☐ |
| 6.1.1. Communications Interface |
| ☐ |
| ☐ |
| 6.1.1.1. The communications system shall provide a Wi-Fi Connection to retrieve data from the existing AngelTrax digital video recorder (DVR) on each equipped vehicle. |
| ☐ |
| ☐ |
| 6.1.1.2. The communications interface shall not require modifications to the existing DVR. |
| ☐ |
| ☐ |
| 6.1.1.3. The communications interface shall not require modifications to the AngelTrax viewing software. |
| ☐ |
| ☐ |
| 6.1.1.4. Cellular Connection |
| ☐ |
| ☐ |
| 6.1.1.4.1. A connection to the AngelTrax DVR and the Metro Ride office network may use a cellular connection. |
| ☐ |
| ☐ |
| 6.1.1.4.2. If provided, the cellular connection shall use a cellular router common with other vehicle systems. |
| ☐ |
| ☐ |
| 6.1.1.4.3. If provided, the cellular router may support bandwidth limiting features to restrict the connection speed to the AngelTrax DVR. |
| ☐ |
| ☐ |
| 6.1.1.5. External Wi-Fi Access Points |
| ☐ |
| ☐ |
| 6.1.1.5.1. Performance Requirements |
| ☐ |
| ☐ |
| 6.1.1.5.1.1. Data Transfer rates between the AngelTrax DVR unit and a Wi-Fi access point shall be as defined in Section 9. |
| ☐ |
| ☐ |
| 6.1.1.5.1.2. Data Transfer rates between the AngelTrax DVR unit and the Metro Ride office network access point(s) when transferring date over cellular connections shall be as defined in Section 9. |
| ☐ |
| ☐ |
7. On-Board Driver User Interface (UI)
| 7.1. Functional Requirements |
| ☐ |
| ☐ |
| 7.1.1. Physical |
| ☐ |
| ☐ |
| 7.1.1.1. The display of the on-board UI shall meet the following requirements and features: |
| ☐ |
| ☐ |
| 7.1.1.1.1. A minimum of 11 inches, measured diagonally |
| ☐ |
| ☐ |
| 7.1.1.1.2. A minimum of 16 bit color resolution |
| ☐ |
| ☐ |
| 7.1.1.1.3. Sufficient brightness to be readable in daylight conditions on board the vehicle. |
| ☐ |
| ☐ |
| 7.1.1.1.4. User adjustable and auto adjustable brightness (night and day modes) with a minimum of ten (10) brightness levels |
| ☐ |
| ☐ |
| 7.1.1.1.5. No reflection off vehicle windows such that it interferes with the driver’s view of the exterior of the vehicle. |
| ☐ |
| ☐ |
| 7.1.1.1.6. Touch sensitive display supporting three (3) point multitouch at a minimum. |
| ☐ |
| ☐ |
| 7.1.1.1.7. Mounted UI to the vehicle that shall meet the following requirements: |
| ☐ |
| ☐ |
| 7.1.1.1.7.1. UI mount ensures vibration transmitted to the unit does not exceed manufacturer's specifications. |
| ☐ |
| ☐ |
| 7.1.1.1.7.2. The UI display visible to the driver without any portion of the screen obstructed. |
| ☐ |
| ☐ |
| 7.1.1.1.7.3. The UI display’s farthest touch sensitive portion no greater than 21 inches from center of the driver’s seat. |
| ☐ |
| ☐ |
| 7.1.1.1.7.4. The UI mounting does not block or otherwise interfere with any other vehicle controls or displays. |
| ☐ |
| ☐ |
| 7.1.1.1.7.5. The UI mount provide mechanisms for power and data connections that include a retention mechanism that prevents unintentional disconnection. |
| ☐ |
| ☐ |
| 7.1.1.1.8. The driver UI shall be powered from the vehicle’s 12 VDC power supply. |
| ☐ |
| ☐ |
| 7.1.2. Login and Authentication |
| ☐ |
| ☐ |
| 7.1.2.1. The user interface shall present prompts for driver input during authentication. |
| ☐ |
| ☐ |
| 7.1.2.2. The user interface shall prompt the driver to input: |
| ☐ |
| ☐ |
| 7.1.2.2.1. Driver ID (as alphanumeric user ID). |
| ☐ |
| ☐ |
| 7.1.2.2.2. Driver Password (as alphanumeric password). |
| ☐ |
| ☐ |
| 7.1.2.2.3. Vehicle ID (selected from list). |
| ☐ |
| ☐ |
| 7.1.2.2.4. Route ID (selected from list). |
| ☐ |
| ☐ |
| 7.1.2.3. The authentication function shall communicate in real time to authentication authority (Windows Azure services). |
| ☐ |
| ☐ |
| 7.1.2.4. The authentication function shall provide a confirmation to the driver that authentication has been accepted or rejected by the authentication authority. |
| ☐ |
| ☐ |
| 7.1.2.5. The authentication function shall validate Vehicle ID to prevent acceptance of invalid values. |
| ☐ |
| ☐ |
| 7.1.2.6. The user interface shall provide a mechanism for drivers to log out of the system. |
| ☐ |
| ☐ |
| 7.1.3. Fare Type Input |
| ☐ |
| ☐ |
| 7.1.3.1. The user interface shall provide a fare type selection screen with distinct on-screen buttons and labels indicating corresponding fare types. |
| ☐ |
| ☐ |
| 7.1.3.2. Once active, the fare type selection screen shall remain visible until another function is selected by the driver. |
| ☐ |
| ☐ |
| 7.1.3.3. Passenger fare type shall be entered with a single button press on the user interface. |
| ☐ |
| ☐ |
| 7.1.3.4. A minimum of ten (10) rider fare types shall be supported with the ability to update fare types administratively. |
| ☐ |
| ☐ |
| 7.1.3.5. The user interface shall have a mechanism to “undo” the last entered passenger fare class and enter a new one. |
| ☐ |
| ☐ |
| 7.1.4. Transfer Management |
| ☐ |
| ☐ |
| 7.1.4.1. The Fare Type Input screen shall include buttons to record transfer activity. |
| ☐ |
| ☐ |
| 7.1.4.1.1. The UI shall have a mechanism to record issuance of a paper transfer. |
| ☐ |
| ☐ |
| 7.1.4.1.2. The UI shall have a mechanism to record receipt of a paper transfer. |
| ☐ |
| ☐ |
| 7.1.5. Checklists |
| ☐ |
| ☐ |
| 7.1.5.1. The UI shall include mileage on and off and the means to report out. |
| ☐ |
| ☐ |
| 7.1.6. Communication with transit control center |
| ☐ |
| ☐ |
| 7.1.6.1. The UI shall allow supervisors to send custom messages out to vehicles. |
| ☐ |
| ☐ |
| 7.1.6.2. Messages from the transit control center |
| ☐ |
| ☐ |
| 7.1.6.2.1. The UI shall allow driver access to “inboxes” that receive notifications specific to the driver and route as well as system-wide notifications. |
| ☐ |
| ☐ |
| 7.1.6.2.2. Drivers shall be able to mark inbox messages as “read” to confirm receipt. |
| ☐ |
| ☐ |
| 7.1.7. Future use cases |
| ☐ |
| ☐ |
| 7.1.7.1. The UI shall allow for future expansion to paratransit operations. |
| ☐ |
| ☐ |
| 7.2. Performance Requirements |
| ☐ |
| ☐ |
| 7.2.1. 7.2.1. Hardware warranty shall be provided as defined in section 11. |
| ☐ |
| ☐ |
| 7.2.2. Environmental requirements |
| ☐ |
| ☐ |
| 7.2.2.1. The UI shall function as defined in the manufacturer's specifications between the temperatures of -20 to +60 C. |
| ☐ |
| ☐ |
| 7.2.2.2. The UI shall function as defined in the manufacturer's specifications up to a non-condensing relative humidity level of 95 percent. |
| ☐ |
| ☐ |
| 7.2.3. The UI shall prompt the driver for login credentials no later than 15 seconds from a cold start (engine off) of the vehicle |
| ☐ |
| ☐ |
8. Vehicle Location System (VLS)
| 8.1. Functional Requirements |
| ☐ |
| ☐ |
| 8.1.1. General |
| ☐ |
| ☐ |
| 8.1.1.1. The VLS shall integrate with the other tools described in Sections 2, 3, 4, 7, and 10. |
| ☐ |
| ☐ |
| 8.1.1.2. The VLS shall determine vehicle position. |
| ☐ |
| ☐ |
| 8.1.1.3. The VLS shall have an external antenna for the GPS/GNSS receiver. |
| ☐ |
| ☐ |
| 8.1.1.4. The VLS shall transmit location data via a cellular data connection on the vehicle. |
| ☐ |
| ☐ |
| 8.1.1.5. The VLS shall use 12 VDC power supplied by the vehicle electrical system. |
| ☐ |
| ☐ |
| 8.1.2. Data |
| ☐ |
| ☐ |
| 8.1.2.1. The VLS shall store information consistent with requirements listed in section 10. |
| ☐ |
| ☐ |
| 8.1.2.2. The VLS shall store information in a central database not located on the vehicle. |
| ☐ |
| ☐ |
| 8.1.2.2.1. The VLS shall store (or shall combine with Driver User Interface Data): |
| ☐ |
| ☐ |
| 8.1.2.2.1.1. Date, time, and driver ID for driver log in. |
| ☐ |
| ☐ |
| 8.1.2.2.1.2. Date, time, and driver ID for driver log out. |
| ☐ |
| ☐ |
| 8.1.2.2.1.3. Date, time, and driver ID for in-service checklist completion. |
| ☐ |
| ☐ |
| 8.1.2.2.1.4. Latitude and Longitude for each position update transmitted from the vehicle. |
| ☐ |
| ☐ |
| 8.1.2.3. The VLS shall make vehicle location information accessible from agency workstations (see section 2). |
| ☐ |
| ☐ |
| 8.1.3. The VLS shall provide on-time performance reports with the following: |
| ☐ |
| ☐ |
| 8.1.3.1.1. Ability to define an “on time” window (positive or negative time offset from scheduled time of arrival at a stop). |
| ☐ |
| ☐ |
| 8.1.3.1.2. Ability to query number of late, on-time, and missed timepoint occurrences by route, date, trip, stop, driver ID, and vehicle ID. |
| ☐ |
| ☐ |
| 8.1.4. The VLS shall communicate to remote systems using the communications system described in Section 9. |
| ☐ |
| ☐ |
| 8.2. Performance Requirements |
| ☐ |
| ☐ |
| 8.2.1. The VLS shall be capable of providing position updates a minimum of once every ten (10) seconds. |
| ☐ |
| ☐ |
| 8.2.2. The VLS shall acquire sufficient satellite signals to provide a vehicle position accurate to within 10 meters within four minutes of a cold start. |
| ☐ |
| ☐ |
| 8.2.3. The VLS shall provide vehicle position accurate to within 10 meters within one minute of a warm start. |
| ☐ |
| ☐ |
9. Communication System
| 9.1. Functional Requirements |
| ☐ |
| ☐ |
| 9.1.1. The communications system shall include a Wi-Fi interface for connections to Metro Ride or other City of Wausau access points. |
| ☐ |
| ☐ |
| 9.1.1.1.1. The Wi-Fi connection shall support 802.11ac as a minimum connection standard. |
| ☐ |
| ☐ |
| 9.1.1.1.2. The Wi-Fi connection shall support WPA3. |
| ☐ |
| ☐ |
| 9.1.1.1.3. The Wi-Fi connection shall support centrally managed authentication for connections to access points |
| ☐ |
| ☐ |
| 9.1.1.1.4. The Wi-Fi connection shall support data connections to: |
| ☐ |
| ☐ |
| 9.1.1.1.4.1. The driver user interface (UI). |
| ☐ |
| ☐ |
| 9.1.1.1.4.2. The Automatic Passenger Counter system. |
| ☐ |
| ☐ |
| 9.1.1.1.4.3. The on-board digital video recorder. |
| ☐ |
| ☐ |
| 9.1.1.1.4.4. The annunciator system. |
| ☐ |
| ☐ |
| 9.1.1.1.4.5. Connections to other systems may be through a central on-board unit or directly to individual system controllers. |
| ☐ |
| ☐ |
| 9.1.2. The communication system shall include a cellular connection. |
| ☐ |
| ☐ |
| 9.1.2.1. The cellular connection shall support 5G (NR) connections. |
| ☐ |
| ☐ |
| 9.1.2.2. The cellular connection shall support fall back to 4G connections. |
| ☐ |
| ☐ |
| 9.1.2.3. The Wi-Fi connection shall support data connections to: |
| ☐ |
| ☐ |
| 9.1.2.3.1. The driver user interface (UI). |
| ☐ |
| ☐ |
| 9.1.2.3.2. The Automatic Passenger Counter system. |
| ☐ |
| ☐ |
| 9.1.2.4. The cellular connection may support connections to |
| ☐ |
| ☐ |
| 9.1.2.4.1. The on-board digital video recorder. |
| ☐ |
| ☐ |
| 9.1.2.4.2. The annunciator system. |
| ☐ |
| ☐ |
| 9.1.2.5. Connections to other systems may be through a central on-board unit or directly to individual system controllers. |
| ☐ |
| ☐ |
| 9.2. Performance Requirements |
| ☐ |
| ☐ |
| 9.2.1. Wi-Fi Connection |
| ☐ |
| ☐ |
| 9.2.1.1. The Wi-Fi connection shall support minimum data rate of 500 Mbit/second. |
| ☐ |
| ☐ |
| 9.2.1.2. The Wi-Fi connection shall demonstrate data throughput of a minimum of 100 Mbit/second between a vehicle and access point at any location inside the Metro Ride garage. |
| ☐ |
| ☐ |
| 9.2.2. Cellular Connection |
| ☐ |
| ☐ |
| 9.2.2.1. The cellular connection shall provide coverage with at least 1 Mbit/Second over 98 percent of the existing Metro Ride routes. |
| ☐ |
| ☐ |
10. Data Management
| 10.1. Data Storage |
| ☐ |
| ☐ |
| 10.1.1. Data shall be stored in a central database accessible from agency workstations SQL server. |
| ☐ |
| ☐ |
| 10.1.2. Backup and recovery |
| ☐ |
| ☐ |
| 10.1.2.1. Vendor shall supply a data backup and recovery process description to the City |
| ☐ |
| ☐ |
| 10.1.2.1.1. Backup and recovery processes shall be implemented such that there is no data loss in the event of storage malfunctions, failure, or malicious action. |
| ☐ |
| ☐ |
| 10.2. Data Retention |
| ☐ |
| ☐ |
| 10.2.1. All data collected shall be stored for a minimum of seven years with the exception of granular real-time location data which shall be stored for a minimum of one (1) year |
| ☐ |
| ☐ |
| 10.3. The database shall provide data query and extraction tools to allow agency staff to access and export data: |
| ☐ |
| ☐ |
| 10.3.1.1. The database shall allow data to be queried by date. |
| ☐ |
| ☐ |
| 10.3.1.2. The database shall allow data to be queried by time. |
| ☐ |
| ☐ |
| 10.3.1.3. The database shall allow data to be queried by vehicle ID. |
| ☐ |
| ☐ |
| 10.3.1.4. The database shall allow data to be queried by driver ID. |
| ☐ |
| ☐ |
| 10.3.1.5. The database shall allow data to be queried by route. |
| ☐ |
| ☐ |
| 10.3.1.6. The database shall allow data to be queried by location. |
| ☐ |
| ☐ |
| 10.3.1.7. The database shall allow data to be exported as a comma separated value text file. |
| ☐ |
| ☐ |
| 10.3.1.8. The VLS database shall export data as a Microsoft Excel-compatible spreadsheet file. |
| ☐ |
| ☐ |
| 10.3.1.9. The database shall allow for the creation and export of custom operations reports by agency staff. |
| ☐ |
| ☐ |
| 10.4. Data Access Control |
| ☐ |
| ☐ |
| 10.4.1. Data access shall be controlled via City of Wausau’s existing Windows Azure services. |
| ☐ |
| ☐ |
| 10.4.2. Authentication |
| ☐ |
| ☐ |
| 10.5. Data Security and Access Protection |
| ☐ |
| ☐ |
| 10.5.1. Data and access shall be restricted to authenticated users. |
| ☐ |
| ☐ |
11. Operations and Maintenance Requirements
| 11.1. Warranty Period |
| ☐ |
| ☐ |
| 11.1.1. All system components shall be warranted for a period of a minimum of three (3) years. |
| ☐ |
| ☐ |
| 11.1.2. The warranty shall cover all failures due to any defects in materials or workmanship of devices, software, and services. |
| ☐ |
| ☐ |
| 11.1.3. The Contractor shall be responsible for any failures due to installation techniques or materials. |
| ☐ |
| ☐ |
| 11.1.4. Warranty period shall commence upon acceptance. |
| ☐ |
| ☐ |
| 11.1.5. Updates to system software shall be included as a service during the warranty period. |
| ☐ |
| ☐ |
| 11.1.6. A minimum of an additional two (2) years shall be available for purchase as part of the initial contracting process. |
| ☐ |
| ☐ |
| 11.1.7. If the Contractor intends to terminate support services during the warranty period, a transition plan shall be supplied that ensures continuity of service for all participating agencies. |
| ☐ |
| ☐ |
| 11.2. Operational Services |
| ☐ |
| ☐ |
| 11.2.1. Any system services (hosting, cloud storage, etc.) shall be included in the system cost for a period of three (3) years. |
| ☐ |
| ☐ |
| 11.2.2. A minimum of an additional two (2) years shall be available for purchase as part of the initial contracting process. |
| ☐ |
| ☐ |
| 11.2.3. If the Contractor intends to terminate operational services during the contract period, a transition plan shall be supplied that ensures continuity of service for all participating agencies. |
| ☐ |
| ☐ |
| 11.3. Data Access |
| ☐ |
| ☐ |
| 11.3.1. All system operational data shall be: |
| ☐ |
| ☐ |
| 11.3.1.1. Accessible by agency staff. |
| ☐ |
| ☐ |
| 11.3.1.2. Exportable in a comma or tab separated text format such as CSV or TSV. |
| ☐ |
| ☐ |
| 11.3.1.3. Available for the duration of the contract. |
| ☐ |
| ☐ |
| 11.3.1.4. Accessible from the respective offices of participating agencies. |
| ☐ |
| ☐ |
| 11.4. Required Support Services |
| ☐ |
| ☐ |
| 11.4.1. The Contractor shall be the contact for technical support. |
| ☐ |
| ☐ |
| 11.4.2. The Contractor shall provide a single point of contact for all support requests. |
| ☐ |
| ☐ |
| 11.4.3. Support contact shall be available via telephone. |
| ☐ |
| ☐ |
| 11.4.4. Support contact shall be available via e-mail. |
| ☐ |
| ☐ |
| 11.4.5. Support contact shall be available via an on-line, web-based issue reporting (ticketing) system. |
| ☐ |
| ☐ |
| 11.4.6. The Contractor shall provide a minimum stock of spare components equal to ten (10) percent of the project total or one additional unit of each component, whichever is greater. |
| ☐ |
| ☐ |
| 11.4.7. The Contractor shall provide on-site device service or replacement during the warranty period. |
| ☐ |
| ☐ |
| 11.5. Support Response Periods |
| ☐ |
| ☐ |
| 11.5.1. Technical support shall be available on a 7-day per week, 24 hour-per day basis. |
| ☐ |
| ☐ |
| 11.5.2. Support shall be available 365 days per year, except leap years, when 366 days will be available. |
| ☐ |
| ☐ |
| 11.5.3. All technical support requests shall be responded to within one (1) business hour. |
| ☐ |
| ☐ |
| 11.5.4. Any issues that result in delay or suspension of service shall be resolved within three (3) hours. |
| ☐ |
| ☐ |
| 11.5.5. Any issues that result in the inability to process payments shall be resolved within eight (8) hours. |
| ☐ |
| ☐ |
| 11.6. Training Requirements |
| ☐ |
| ☐ |
| 11.6.1. Training Materials |
| ☐ |
| ☐ |
| 11.6.1.1. Written training materials shall be provided a minimum of 1 week in advance of system installation. |
| ☐ |
| ☐ |
| 11.6.1.2. Contractor shall provide training syllabi for each user group prior to scheduling training sessions. |
| ☐ |
| ☐ |
| 11.6.1.3. Contractor shall provide online training materials for all user groups for use at any point during the support period. |
| ☐ |
| ☐ |
| 11.6.1.4. Contractor may provide written materials to supplement Wausau Metro Ride’s Operator’s Manual. |
| ☐ |
| ☐ |
| 11.6.2. Training Sessions |
| ☐ |
| ☐ |
| 11.6.2.1. In-person training shall be specific to the parts of the system each user group will interact with. |
| ☐ |
| ☐ |
| 11.6.2.2. Contractor shall provide: |
| ☐ |
| ☐ |
| 11.6.2.2.1. Training for customer support (call taking and dispatching staff) |
| ☐ |
| ☐ |
| 11.6.2.2.2. Training for supervisor staff |
| ☐ |
| ☐ |
| 11.6.2.2.3. Training for drivers |
| ☐ |
| ☐ |
| 11.6.2.2.4. Training for vehicle maintenance staff |
| ☐ |
| ☐ |
| 11.6.2.2.5. Training syllabi for each user group prior to scheduling training sessions |
| ☐ |
| ☐ |
| 11.6.2.3. A minimum of one primary and one make-up training session shall be scheduled for each user group over a period of not less than two days. |
| ☐ |
| ☐ |
| 11.6.3. Training Content |
| ☐ |
| ☐ |
| 11.6.3.1. Instructions for hardware installation shall be included |
| ☐ |
| ☐ |
| 11.6.3.2. All functional aspects of the system shall be described in training materials. |
| ☐ |
| ☐ |
| 11.6.3.3. Training materials shall be supplied as both physical and electronic versions. |
| ☐ |
| ☐ |
| 11.6.3.4. Training materials shall be organized for each functional group: |
| ☐ |
| ☐ |
| 11.6.3.4.1. Customer service agents |
| ☐ |
| ☐ |
| 11.6.3.4.2. Vehicle drivers |
| ☐ |
| ☐ |
| 11.6.3.4.3. System administrators |
| ☐ |
| ☐ |
| 11.6.3.4.4. Accounting and financial staff |
| ☐ |
| ☐ |
| 11.6.3.4.5. Maintenance staff |
| ☐ |
| ☐ |
| 11.6.3.5. A minimum of two live training session shall be conducted for each of the functional groups. |
| ☐ |
| ☐ |
| 11.6.3.6. Training shall include training for software functions. |
| ☐ |
| ☐ |
| 11.6.3.7. Training shall include demonstrations for specific work tasks. |
| ☐ |
| ☐ |
File details come from the government source that posted it. Updated .