CAD and AVL Services

The vendor required to provide computer-aided dispatch and automatic vehicle location (CAD and AVL) system is an inefficient and unsustainable platform that impedes authority ability to operate as a modern, data-driven transit agency.
- Core CAD and AVL functionality
1. Dispatching and service management
•    The dispatch software shall be fully web-based or a cloud native application, accessible via a standard web browser without requiring any remote desktop or virtualized client software. 
•    The interface shall be modern, intuitive, and stable, with no system freezes. 
•    Routine tasks, such as responding to an operator message or assigning a vehicle, shall require a minimal number of clicks.
•    The user interface shall be customizable, allowing dispatchers to resize, move, and save the layout of various windows (e.g., map, vehicle list, message queues) to suit their workflow. 
•    The map and vehicle list ("pool") views shall be independently resizable. 
•    The system shall display the real-time location of all active vehicles on a map with a data refresh rate of no more than five (5) seconds. 
•    The map display shall be highly configurable, allowing for multiple map layers (e.g., satellite, street), color-coded vehicle icons to represent status (e.g., early, late, off-route, emergency), and the ability to filter the display by route, division, or vehicle type. 
•    The system shall provide a "block map" or "route liner" display, showing the relative position of all buses along a specific route on a simplified line diagram, in addition to the standard geographic map view. 
•    The system shall support robust two-way text messaging between dispatchers and operators, including both canned and free-form messages. 
•    The interface shall clearly indicate when a message has been sent, delivered, and read by the operator. 
•    The system shall integrate a voice over IP (VOIP) or voice over LTE (volte) solution for voice communications, providing dispatchers with the ability to initiate private calls to a single operator, group calls to all operators on a route, and all-calls to the entire fleet directly from the dispatch console. 
•    The system shall include a graphical, map-based tool for creating and managing detours. dispatchers shall be able to draw a detour path on the map, select the affected stops, and activate the detour.
•    The system shall allow for the creation of both planned detours with pre-set start and end times and immediate, ad-hoc detours. 
•    The ability to set expiration dates on detours is required. 
•    The system shall provide a clear, high-priority visual and audible alert on all dispatch workstations when a covert alarm or panic button is activated. 
•    Activation of a covert alarm shall automatically enable a "listen-in" function, allowing dispatch to monitor the audio environment on the vehicle. 
•    The system shall create an automated incident log for all emergency events, time-stamping all actions taken by the dispatcher. 
•    The system shall provide a fully digital module for managing the daily extra board, eliminating the current paper-based process. 
•    The system shall track operator availability and suggest assignments for open runs based on union rules and hours of service. 
•    The system shall provide a clear and efficient workflow for logging and tracking all daily service exceptions, including operator call-offs, late pull-outs, vehicle swaps, and missed trips. 
•    The system shall be capable of automatically identifying and calculating lost service time.
2. Onboard system and operator interface (MDT and IVLU)
•    The system shall support an automated login method, such as an operator tapping a badge (NFC and RFID) on a reader integrated with the MDT. 
•    Manual entry of an id number shall be available as a backup. 
•    Upon successful sign-in, the system shall have the capability to send the operator their daily assignment details (e.g., vehicle number, block and run number, pull-out time) via a preconfigured mobile contact method, such as SMS text messages or a push notification. 
•    Upon a successful login, the system shall automatically identify the operator's scheduled block and run for the day, eliminating the need for manual selection for standard assignments. 
•    Turn-by-turn navigation is a mandatory, non-negotiable requirement. 
•    The MDT shall provide clear, voice-guided, and map-based turn-by-turn directions for all routes, including any real-time detours pushed from dispatch.
•    The operator interface shall be simple and intuitive, with a high-contrast display that is readable in all lighting conditions. 
•    The system shall lock out non-essential operator interactions while the vehicle is in motion. 
•    The MDT shall provide a clear, continuous display of the vehicle's schedule adherence status (e.g., "5 min late," "2 min early," "on time"). 
•    The system shall utilize advanced geofencing (e.g., polygons, route-based corridors) to trigger stop announcements and other location-based events, and shall not be limited to simple rectangular "trigger boxes." 
•    The system shall be able to correctly handle interlining at the transit center and other locations. it shall not prematurely end a trip or change the head sign before the vehicle has completed its service to the layover point. 
•    The system shall provide logic for defining "zero points" where the automated passenger counter (APC) data should be reset to zero (e.g., at the end of a route before a long layover), ensuring the accuracy of downstream ridership data.
- On-board system hardware and software
1. General onboard system requirements
•    Unified hardware platform: to resolve current challenges with hardware obsolescence, the contractor shall propose a single, current-generation hardware platform for the entire fleet. 
•    The use of multiple generations of core components is not acceptable.
•    Transit environment durability: all onboard hardware shall be designed and ruggedized for the public transit vehicle environment. 
•    It shall be rated to withstand constant shock, vibration, dust, humidity, and a wide range of operating temperatures. 
•    The system shall also be designed to operate reliably with the electrical power variations common in transit vehicles.
•    Modular and maintainable design: all major onboard components shall be of a modular design, allowing for rapid, in-field replacement by metro technicians. 
•    The replacement of any single core component shall take no more than fifteen (15) minutes for a trained technician.
•    Software and firmware updates: the system shall support remote, over-the-air (OTA) software and firmware updates managed from the central system. 
•    The update process shall be robust, with fail-safe mechanisms to prevent vehicle downtime in the event of an incomplete or failed update. 
•    Remote memory management: the system shall support remote upload, download, and clearing of system operational data by authorized users. 
•    Onboard system recovery: all core on-board equipment, including the integrated vehicle logic unit (IVLU) and mobile data terminals (MDT), shall include hardware and software functionality (e.g. a watchdog timer) to automatically reboot or restart in the event of a system freeze, application crash, or process failure. 
•    The system shall recover full functionality without requiring manual operator intervention.
•    Discrete event logging: the IVLU shall log all key operational events in its non-volatile memory, time-stamping each event with its corresponding GPS location. 
•    This shall include, but it not limited to:
o    Operator login and logout events.
o    Door open and close events for each door.
o    Wheelchair lift and ramp deployment and stow events.
o    Passenger stop requests.
o    Operator-initiated alarms or canned messages sent to dispatch.

- Contract Period/Term: 3 years
- Questions/Inquires Deadline: December 15, 2025