7-RFP2009 - Part G - Attachment I - System Requirements Matrix - Final (Updated).pdf

City of Alexandria Request For Proposals (RFP)

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement RFP No.: 2009

Attachment I

System Requirements Matrix

INSTRUCTIONS

The following System Requirements Matrix defines the functional, technical, and operational capabilities sought for this procurement.

Each requirement is categorized as “Required”, “Preferred”, or “Optional”. “Required” indicates a mandatory capability that must be met in the proposed solution. “Preferred” indicates a capability that is desirable but not mandatory. “Optional” indicates a capability that is not required but may be included at the Offeror’s discretion. In some instances, a “Note to Offeror” designation may be used to provide additional clarification or context regarding the Customer’s intent or operational needs. The Offeror will not need to provide a “yes” or “no” response; however, the “Comments” section is available if the Offeror wants to provide a comment on the “Note to Offeror” narrative.

Offerors are expected to respond to each requirement in the matrix and indicate whether the requirement can be met. If a requirement cannot currently be met, this does not automatically disqualify a proposal; however, Offerors should clearly indicate the limitation and provide supporting information on how the requirement could be addressed through alternative functionality, configuration, or future roadmap development.

Where narratives are bolded within a “Requirement” box, Offerors are expected to provide a substantive explanation of how the requirement will be satisfied. These expanded responses should not be included within the requirements matrix comments field;

instead, they should be addressed within the Technical Proposal under the relevant section, in order to ensure consistent evaluation and maintain the integrity of structured requirement responses.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

Item/Section

Required, Preferred, Optional, or Note to

Offeror

Requirement Yes/No Comments

General

1.1 – General Required The Solution is able to work with both timetable-based and frequency-based service types with headway management functionality.

1.2 – General Required

The Solution’s data and service management tools can support the use of DASH-assigned user roles and passwords with full capability to add, delete, or modify users, groups, or roles in any systems and will have full administrative rights to do so. The Solution includes a logon, logoff feature that is password protected and will allow a user to logon to a specific user access level.

1.3 - General Preferred The Offeror can provide an unlimited number of licenses/users to the platform/CAD software.

1.4 – General Required

The Solution is cloud-based platform/database in accordance with City’s Department of Information Technology Services (ITS) requirements, provided as separate attachments.

1.5 – General Preferred The Solution is browser-based and can be accessed and used entirely through a web browser.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

System Architecture 2.1a – Project

Management Plan and Project Schedule

Required

The Offeror can provide details of the management structure of the project, organization chart, and key personnel and their responsibilities and relationships.

2.1b – Project Management Plan and Project Schedule

Required

The Offeror can provide details of the Project Schedule in order to monitor the project progress (The project schedule should include time frames for the preparation and DASH’s approval of all deliverables and documentation.)

2.1c – Project and Project Schedule

Required

The Offeror can provide a detailed description of management controls on progress, performance, schedules, and costs relative to the project schedule and subsequent operations.

2.1d – Project and Project Schedule

Required The Offeror can provide activity reports to incorporate the project schedule against actual completion of activities.

2.2 – Quality Control Required

The Offeror can provide details of the quality processes employed to ensure the quality of the Solution (including work, equipment, hardware, software, materials, function, operation) delivered is of a level that meets design goals, performance and reliability requirements.

2.3 – Contingency Required The Offeror can provide details of action plans should any of the major deliverables not be delivered as originally scheduled.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

2.4 – Specifications Required

The Offeror can provide details of the specifications, functionalities, and interfaces of the entire Solution to include, sub-systems, applications, components, etc.

2.5 – Training Required

The Offeror can provide details on the basic principles that will apply to the development and delivery of training program. The plan should include but not be limited to the following:

• Outline of training course to be covered by

Solution users;

• Number of classes by user type (i.e.

Operations, Administration, Dispatch, etc.);

• Contingence of refresher training, if needed;

• Schedule of when training will be provided;

and

• Number of training hours to be provided on an upfront and annual basis to be administered, as needed, per DASH’s discretion.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

2.6 – Implementation Required

The Offeror can provide details on the activities required of the Offeror, DASH, and other involved parties during the implementation period. The implementation plan will include but not be limited to the following:

• Mini fleet Pilot Test on ten (10) vehicles for fourteen (14) days;

• Details of what activities are required from

DASH;

• Detail cutover activities; and

• Go-live readiness activities.

2.7 – Network/Data

Communication Required

The Offeror can provide the details of any data communications, whether wired or non-wired (wireless), between all Solution and equipment.

The plan should include but not be limited to the following:

• Data communication / polling between equipment and back-office;

• Data communication between DASH and hosted site; and

• Data communication between Solution and integrated on-board systems.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

2.8 – System Hardware Access

Security Required

The Offeror can provide details of any design specifications of Solution devices / components / hardware to deter the effects of vandalism and theft, prevent unauthorized access to the interior of the equipment, and prevent unauthorized removal of the equipment from its installed vehicle and location.

2.9 – System Equipment

Specifications and Functionality

Required

The Offeror can provide details of any design specifications and functionality of any equipment supplied (i.e., MDT, APC, IVU, etc.) Useful Life Certifications of all equipment.

2.10 – System Equipment Installation

Required

The Offeror can provide details of site preparation and installation design, including any necessary civil, electrical and mechanical drawings and construction packages. Complete description of installation plan to include but not be limited to the following:

• Vehicle equipment installation by each classification of vehicle; and

• Schematic drawings, power feeds, data feeds, etc.

2.11 – Application program interface

Information Required

The Offeror can provide the details of any interfaces/integrations with external systems and onboard systems.

2.12 – Disaster Recovery Required

The Offeror can provide a detailed description of the continuity of the critical business functions and core processes that are required to ensure the ongoing operations when normal operations are interrupted or degraded by adverse events.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

2.13 – System Equipment Safety

Plan Required

The Offeror can provide the details of any safety measures and precautions that need to be taken, while in use or during maintenance activities.

2.14 – Full System Installation Testing Required

The Offeror can describe in depth the installation testing approach. In addition, provide details of all the test plans including the procedures, testing inputs required from DASH, specific tests to be executed, and the chronological order of their execution.

2.15 – Acceptance Testing Required

For any deficiencies, defects, or issues identified during acceptance testing, the Contractor shall correct at no additional cost to DASH and resolve to DASH’s satisfaction prior to final system acceptance.

2.16 – Succession Plan Required

The Offeror can provide details on how the Offeror's operations would continue under DASH’s control once acceptance testing has been completed.

Computer Aided Dispatch (CAD)

3.1 - CAD Required

The Solution can provide a comprehensive set of Computer Aided Dispatch features that will allow for effective and efficient monitoring and control of fixed-route vehicles. Explain the types of CAD functions provided by the proposed solution for fixed route vehicle usage.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

3.2 - CAD Optional

DASH currently uses the Optibus daily operations module to track operator availability and assignments.

The Offeror may provide, if desired, its own module or functionality to perform operations management.

The Solution should assist operations team administer, manage, and ensure that each block and run are accounted in a day-to-day sequence.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

3.3 - CAD Required

The Solution can accurately monitor the route and schedule adherence of all fixed route revenue vehicles that are operating on defined schedules. The Solution must, at a minimum, calculate on-time performance based on departure times. Ideally, the Solution will handle both arrival and departure times in calculating on-time performance. Explain how the solution will address the monitoring of route and schedule adherence for fixed route vehicles. Describe how the proposed solution handles interlined blocks.

Detail the methodology of schedule adherence or projected bus arrival information. This should include considerations such as operations standard operating procedure (SOP), time points, interlining, disruptions, real-time traffic data, past route performance data, etc.

Detail the management capabilities of service disruptions, such as incidents, accidents, detours, and live block modifications. This should include the system’s capability to extend disruption related updates to the end users.

Detail the platform’s ability to handle dropback operations, mid-route reliefs, and other operational practices where operator assignments might continue across multiple blocks in a given day.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

3.4 - CAD Required

The Solution can provide an interactive map interface allowing current and historical vehicle position histories to be displayed.

Detail the functional ability of the solution’s historic map functions. This should include filter settings by date/time window(s)s, vehicles, routes, operators, ridership, and past service performance parameters.

3.5 - CAD Required

The Solution can supply the public with real-time bus location information, schedule information, service alerts, and links to other service information. These features will be accessible to the public through a desktop- and mobile-friendly website and varied applications. The Solution shall provide an API or data output for the DASH communications team to incorporate service disruptions, delays, and missed or partial missed trips on webpage and/or other platforms.

Please detail what data can be provided for these purposes.

Offerors will describe how the maps and overlays will be created, refined, and updated, maintained as well as identify who will be responsible for such tasks.

DASH will provide the Offeror with transit data in GTFS format. If needed, Offeror shall provide map updates annually for the contract period at no additional cost as part of the software maintenance agreement.

3.6 - CAD Required Maps and overlays will be accurate and easy for DASH Staff to use and interpret.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

3.7 - CAD Required

The map will support a variety of attributes including all roads, fixed routes, transit centers/hubs, time points, and bus stops within the DASH service area. Map should also be filterable by vehicle status as well (late, early, off-route, idle, etc.)

3.8- CAD Required

The interactive map will have the ability to pan and zoom in and out, and restrict the display to show specific vehicle(s), route(s), area, etc. The Offeror should provide examples of CAD map displays.

3.9 - CAD Required

A status screen should display all active vehicles with:

• Operator;

• On Time Performance;

• Headway Adherence;

• Trip;

• Run;

• Route; and

• Detour Status.

The status screen should have the ability to filter and display buses and/or runs based on:

• ANY combination of filter parameters above;

and

• Within each filter parameter, an unlimited number of selections based on available fields must be available.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

3.10 - CAD Required

The Solution can contain user configurable error flagging for the following:

• Off Route Vehicles;

• Vehicles in exceed of certain number of minutes off schedule adherence;

• Runs that are not assigned and checked in within run’s scheduled report time;

• Blocks that are not assigned vehicles and has exited garage by scheduled pull out time;

• Blocks/Trips that are within a user configurable headway deviation (indicate if bunching is present);

• Unassigned Trip;

• Incorrectly Assigned Trip; and

• Operator Not Logged In.

3.11 - CAD Required

The Solution can support two (2)-way text messaging with Bus Operator with canned messages for Operator response and free text for Dispatch. Messaging should support communication to individual buses, groups of buses, and the entire fleet.

3.12 - CAD Required

Ability to assign/correct Bus Assignments remotely from Dispatch and be able to integrate with other software (such as Swiftly, Optibus, Fleetio, etc.)

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

3.13 - CAD Preferred

Ideally, vehicle positions will be updated every zero (0) to five (5) seconds. Specify the intervals in which vehicle positions on this display are automatically updated.

3.14 – CAD Required The Solution can support multiple users without creating data conflicts with or overriding actions by other users.

3.15 – CAD Required

The Solution can show vehicles moving on a route map while showing routes, bus stop schedules, and other amenities available for customers to view in real time.

3.16 – CAD Required

The Solution can provide customer alert and announcement options for:

• Texting/e-mail;

• Social media; and

• customer platform website.

Automatic Vehicle Location (AVL)

4.1 - AVL Preferred The Offeror’s Solution can integrate with existing GPS antennas on buses.

4.2 - AVL Required The Offeror can provide Automatic Vehicle Location on all customer vehicles.

4.3 - AVL Required The AVL will operate without interaction/input from the vehicle operator.

4.4 - AVL Required

The AVL will report accurate bus locations of all buses within and outside of the DASH fixed-route network.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

On Vehicle Systems (OVS)

5.1 - OVS Required

The Offeror shall identify hardware to serve as the central processor, data storage, and device manager for all onboard devices. This can be via proprietary device, cloud, router, etc.

5.2 - OVS Required

The Solution can integrate and control all in-vehicle ITS functions and hardware, including the GPS receiver, APCs, AVAS, Destination Signs, Infotainment, LED interior signs, etc.

5.3 - OVS Required The Solution can compute the vehicle position, speed, and direction based on multiple positioning systems and inputs including the GPS receiver.

5.4 - OVS Preferred The Solution can include secondary position system consisting of an odometer interface or other dead-reckoning device.

5.5 - OVS Required

The Solution can compute and update onboard vehicle position information every five (5) seconds or less and will provide that position information to other onboard devices as needed. Specify the intervals in which vehicle positions on this display are automatically updated.

5.6 - OVS Required

Location data will be sufficiently precise to accurately and reliably identify the location of each vehicle on the street network. At a minimum, ninety-five percent (95%) of the time, vehicle location will be accurate to within ten feet (10')., RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

5.7 - OVS Required

The Solution can provide location reports to the system as follows:

• Routine location reports will be provided on a regular basis regardless of whether it is logged on or not. The Offeror will include GPS update frequency; and

• Position reports will be provided when the vehicle enters and departs its Terminal and Connection Points.

5.8 - OVS Required The Solution can indicate any vehicle that is not reporting its status and location within a configurable time period.

5.9 - OVS Required

The Solution can connect with available onboard circuits and record date, time, and location when the onboard circuit events occur, such as, but not limited to:

• Front Door Open;

• Rear Door Open;

• Lift/Ramp Deployment (preferred);

• Stop Requested; and

• Bike Rack Occupancy Detection (preferred).

5.10 - OVS Required

The Solution can check daily for and download bulk data files containing service, operator assignment, and other information from the central computer system. The capacity will be provided to allow for storage of at least two (2) full bus service schedule changes of data. The system will also allow for a data push for same day changes.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

5.11 - OVS Required

If internet connectivity is lost, all data will be stored on the vehicle until connectivity is reestablished.

After the connection is established, all data should be pushed to the server. The server will post-process the data. This requirement is to guarantee delivery and ensure no data is lost.

5.12 - OVS Required If internet connectivity is lost, the system will function as normal until connectivity is reestablished.

5.13 - OVS Required

The OVS will have sufficient non-volatile memory capacity to store at least thirty (30) days of operational and APC data, assuming up to ten

(10) revenue hours per day.

5.14 - OVS Preferred

In the event the vehicle needs to offload data when the vehicle has completed service for the day, the OVS will have a DASH configurable parameter of zero (0) to thirty (30) minutes that controls the power down of the OVS and MDT after the vehicle master ignition switch is turned “off.”

5.15 - OVS Preferred

The OVS will inform all managed devices to initiate a graceful power-down of itself and the MDT at a DASH configurable time zero (0) to thirty (30) minutes before power-down is activated.

5.16 - OVS Preferred Upon reaching the power-down threshold, the OVS will completely remove power from all connected devices and itself.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

5.17 - OVS Preferred If the vehicle operator has not logged off, the system will automatically log off, prior to power down activation.

5.18 – OVS

Integration with Sierra Wireless

Note to Offeror

All DASH Fixed Route vehicles are currently equipped with a Sierra Wireless oMG2000, Airlink Mg90, or Airlink Xr90 routers.

5.18a – OVS Integration with Sierra Wireless

Preferred

The Offeror should include the option to upgrade on-board routers to a newer model, such as a Sierra Wireless Airlink Xr90 or later 5G enabled device. This option can be exercised at any point in the life of the contract.

Mobile Data Terminal (MDT) Display

6.1 - MDT Display Note to Offeror

The MDT should be an industry-proven, open-architecture technology that is easy to replace when damaged and made to withstand the rigors of fixed-route service vehicles including, but not limited to cutaways, trolleys, and heavy-duty buses (including electric buses). All upgrades to technology, both hardware and software, should be part of the per-bus contract price to avoid unforeseen costs in the future.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

6.2 - MDT Display Required

The MDT will be equipped with a touchscreen display that meets the following requirements:

• Ability to be used by Operators wearing gloves;

• Readable by Operators wearing polarized lenses;

• Sufficient brightness to be readable in direct sunlight;

• Dimmed or night mode operation that will automatically reset for daytime operation;

• A minimum size of seven (7) inches as measured diagonally;

• A minimum resolution of 640x480 pixels.

Contain a speaker to be used to provide audio alerts;

• The MDT display will include functionality, configured by DASH, to display different font, size, icons, buttons, colors, styles on the screen; and

• Text based interface with clearly labeled operator controls.

6.3 - MDT Display Required The MDT will allow an Operator to set MDT brightness and volume settings within pre-defined limits.

6.4 - MDT Display Required All settings will return to their default values that DASH has set when a new logon occurs.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

6.5 - MDT Display Required

The MDT will display the current block, run, route, trip, next three (3) bus stops, text messages, detour information, and data communications system status.

6.6 – MDT Display Required

The MDT will receive messages from the CAD system, alerting the Operator with an audible and visual signal when a new message has been received.

6.7 - MDT Display Preferred The MDT will allow operator to send a yes/no response and acknowledgement to “response required” messages received from the system.

6.8 - MDT Display Required The MDT will show the bus moving on a map with route overlay and provide turn-by-turn directions in both audio and visual format.

6.9 - MDT Display Required

The MDT will store pre-defined messages that may be sent by the Operator to the CAD system.

All pre-defined messages sent to dispatch will include the date, time, and vehicle ID. The pre-defined messages will be configurable by the system administrator from the system.

6.10 - MDT

Display Required

A detour should also be displayed in real-time, including the capability of showing last minute detours such as for a collision or emergency road repair.

6.11 - MDT

Display Required The MDT will provide turn-by-turn directions when a real-time detour is activated.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

6.12 - MDT

The MDT will display on-time performance (early, on-time, late). Ideally, an audible tone would plan when a bus is running ahead of schedule/early.

6.13 - MDT

After the initial login by the Operator, the MDT will automatically switch between trips/routes, based on the programmed schedule without requiring Operators to change trips/routes, while accounting for layovers, and interlining routes and service types.

6.14 - MDT

When necessary, the MDT will allow the Operator to manually select which route, run, and/or block they are not scheduled to operate.

6.15 - MDT

Display Required Based on the schedule, the MDT will automatically know when the vehicle is deadheading.

6.16 - MDT

Display Preferred

The MDT will allow for a customizable counter for bicycles, mobility devices, or other event types, that is configurable by DASH.

6.17 - MDT

The MDT will power up automatically when the vehicle ignition is turned on and will power down a programmable time after the vehicle ignition is turned off.

6.18 - MDT

Display Preferred

Driver input functions (such as trip switching and counter inputs, except panic button functions) should be disabled while the vehicle is in motion.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

6.19 - MDT

The MDT will display a Maintenance Screen that monitors all connections to the server and all connected equipment. For example, the screen will indicate if data is being uploaded and downloaded, if the APCs/AVAS is working, connectivity to Infotainment, GPS reception, destination sign status, fare box connection status (if option selected), etc.

6.20 - MDT

The Solution can allow for remote access to the MDT allowing dispatch/management to see what the driver is seeing, adjust settings, or restart the device remotely.

6.21 - MDT

MDT should provide access to a Training mode where the operator can see schedule feedback, sign controls, and other functions, but the bus will not be reported for real-time purposes. Training status should be indicated to dispatchers in CAD.

Destination Sign Integration

7.1 - Destination Sign Integration Required

All fixed-route DASH buses are equipped with either a Twin Vision or Hanover Destination Sign. The Solution can integrate with the Destination Signs to allow a single point of sign on through the operator control unit that automatically updates the Destination Sign.

7.2 - Destination Sign Integration Required The MDT can allow for manual control of the

Destination Sign using the Destination Sign OCU.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

7.3 - Destination Sign Integration Preferred

The OVS can allow the Operator (using the MDT) or dispatcher (using remote access) to manually override, individually or systemwide, active destination sign and PR sign readings.

7.4 - Destination Sign Integration Preferred

If possible, DASH prefers that Destination Sign message lists can be updated remotely and pushed to vehicles.

Automated Voice Annunciation System (AVAS)

8.1 - AVAS Required

DASH uses Hanover as the on-board infotainment display provider. DASH requires Offeror to integrate with the Hanover product and utilize it as the interior display for AVA functions.

8.2 - AVAS Required AVAS will make internal and external audio announcements with automated pre-set messages at designated, geofenced locations.

8.3 - AVAS Required

The AVAS will have the ability to announce major advertised stops, stops serviced by multiple routes, key transfer points and public service announcements.

8.4 - AVAS Required

If a vehicle is operating off route, the internal automated announcements/displays will not be made. Once the regular route is reacquired, the System will automatically determine and announce the next valid bus stop or other designated location. The response of the AVAS to off-route and on-road detection will be automatic and not require Operator intervention or action.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

8.5a - AVAS Required

The AVAS announcements will be able to be programmed remotely and pushed to vehicles over a cellular connection. DASH will determine the announcement list and author the wording of announcements.

The Offeror should describe how the announcements will be produced and programmed, including whether pre-programmed audio will be recorded or use text-to-speech.

8.5b - AVAS Required

DASH Operations and Planning and Technology staff shall be able to deploy ad hoc text-to-speech announcements on a one (1)-time or recurring basis to inform customers on board of detours or service changes.

8.6 - AVAS Required

The AVAS will:

• perform audio announcements over an internal and external speaker system;

• can play both human-recorded and text-to-speech audio files;

• if the Offeror’s system supports text-to-speech, include text-to-speech software/licensing; and

• Allow DASH to customize and edit audio trigger locations via stop-specific geofencing or other options.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

8.7 - AVAS Required

The MDT will include functionality to generate the following messages and provide DASH with the ability to prioritize the type of AVAS messages being announced at any given time:

• Internal audible announcements (next stop, customer service, transfers, etc.);

• Internal time-based (e.g., reoccurring scheduled message at a time interval);

• Audible customer service announcements;

• Internal Operator initiated audible customer service announcements;

• Location-based customer service announcements; and

• External audible bus arrival announcements.

8.8 - AVAS Preferred

Operators can perform a functionality test of the AVAS by activating a self-test mode which should play an audio test message inside and outside the bus, flash any passenger displays as well as MDT audio. The OVS will record all AVAS faults and errors and display fatal error conditions during pre-check tests on the MDT.

8.9 - AVAS Preferred The AVAS will play audio messages within one (1) second of being triggered.

8.10 - AVAS Preferred The AVAS will contain sufficient memory to store both current and future announcement data for every DASH bus stop.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

8.11 - AVAS Preferred The AVAS will upload AVAS log files to the system as part of the normal data upload and download process.

8.12 - AVAS Preferred

The AVAS will include an Automatic Gain Control (AGC) circuit to automatically and independently adjust internal volume levels depending on vehicle speed or ambient noise level. Each audio announcement played using AGC will be played at a consistent volume determined by sampling the AGC immediately prior to playing the announcement.

8.13 - AVAS Preferred

The AVAS will allow minimum and maximum volumes for internal announcements to be configurable by DASH. The vehicle operator will not be able to manually adjust the volume below or above these levels.

8.14 - AVAS Required

The AVAS will allow the Operator to make manual announcements over the internal and external public address (PA) system. Manual announcements will override the AVAS until the manual announcement is complete.

8.15 - AVAS Required

The AVAS will meet the requirements of ADA to automatically announce recorded information about each stop, major intersection, key locations, transfer opportunities, and route destination in each fixed-route vehicle prior to arriving at that location. The Solution can use a sequential list with individually customizable location trigger points to announce stops.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

8.16 - AVAS Required

The AVAS will support both English and Spanish language messages. Further, the system will be able to support up to three additional languages in the future.

8.17 - AVAS Required

The AVAS will not require a vehicle operator to configure the AVAS or initialize it for it to operate, nor will the AVA system require any operator input to make any automated announcement.

The block that the vehicle is logged into will dictate the automated announcements, and the position of the bus will initiate location-based announcements. The system will only announce stops based on the current route, pattern, and direction.

8.18 - AVAS Preferred

Integrate with the Hanover Smart TFT Infotainment (Preferred) or Interior LED display (Optional) that are onboard select buses.

For buses not currently equipped with Infotainment displays, Offerors will provide:

• Two (2) 29” Hanover TFT for GILLIG, New Flyer 40’ Electric, and Proterra buses; and

• One (1) 21” and One (1) 29” Hanover Smart TFT for New Flyer Diesel and 60’ Electric buses

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

8.19 - AVAS Required

When the vehicle is approaching a stop, the on-board sign should announce the name of the stop.

Trigger proximity parameters should be user configurable. The name of the stop should remain constantly visible (no issues with alternating between the time or stop request) until the bus departs the stop.

8.20 - AVAS Required

When the vehicle is located at a timepoint, the on-board sign should indicate the time remaining before departure. Under configurable conditions while vehicle is located at a timepoint, the Solution should be able to automatically play a specific public relations (PR) audio message.

Infotainment

9.1 - Infotainment Note to Offeror

DASH has selected the Hanover infotainment platform to replace Sunrise LED displays going forward. Sixteen (16) DASH fixed route vehicles are already using the new Hanover platform.

9.2 - Infotainment Preferred

Offerors should provide infotainment screens for use on buses with currently no infotainment. There will be two (2) anti-glare, full-color, LCD screen with rugged enclosures and integrated media player appropriately sized for viewing displayed content at all seated positions within the bus.

• One (1) 29” screen for 35’ buses; and

• Two (2) screens composed of one (1) 21” and one (1) 29” Hanover Smart TFT for 40’ and 60’ buses.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

9.3 - Infotainment Preferred All hardware will be rugged, tamper-proof, and suitable for the transit environment in terms of shock and vibration.

9.4 - Infotainment Preferred

Screens will have full HD resolution with the capability to auto-dim based on time-of-day viewing. Screen placements will be in locations approved by DASH.

9.5 - Infotainment Preferred

The Solution can provide information on current route status, including anticipated stop arrival times. The infotainment system will have the capability to provide advertisements, news, weather, real time information, and other content within a fully customized playlist administered by

DASH.

9.6 - Infotainment Preferred

The Solution can be able to accept a wide array of media content file extensions including but not limited to: .MP3, .MP4, .WAV, .JPEG, .JPG, .GIF, .PNG, .WMV, .MPEG, and .SWF.

9.7 - Infotainment Preferred

The content playlist will be fully customizable including order, frequency, timing (peak/off-peak), location specific, sizing and design (screen configuration).

9.8 - Infotainment Preferred

The Solution can provide options to schedule content based on real-time, based on run-time, or based on geofencing. The Offeror shall describe how the schedule can be customized.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

9.9 - Infotainment Preferred

All media content played will be logged to the Intelligent Transit System and provide usable and configurable reporting to DASH including content:

time, location, duration, number of passengers present, and frequency.

9.10 - Infotainment Preferred Media content creation and management software will be made available to DASH, with a minimum five (5) user licenses.

Automatic Passenger Counters (APC)

10.1a - APC Preferred

All DASH fixed route buses are equipped with HELLA APC-R or HELLA APS-R units. The Offeror will be able to reuse DASH’s current passenger counters units on board and connect to the Vehicle Locator Unit, but may propose a vendor-sourced optical solution, if desired.

10.2 - APC Required The APCs will accurately count passengers as they board and alight, recording the data as a function of individual stops, routes, and runs.

10.3 - APC Required

Overall APC performance will enable the exact determination of alighting and boarding passengers at each stop with an accuracy greater than ninety-five percent (95%). Alternatively, this percentage can change to that approved in the APC NTD Certification Process.

10.4 - APC Required

The APCs will be designed and tested to produce highly accurate raw data, to demonstrate an ability to discriminate valid passengers from non-passenger objects, and to detect double-backs and re-crossings.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

10.5 - APC Required The APC system will automatically count passengers at each transit stop and in-service stops made at non-transit stops.

10.6 - APC Required The APC system will allow functionality testing, as part of the pre-trip, to confirm that the APC system is operational.

10.7 - APC Required

The APC system will properly allocate boardings and alightings between different routes and route directions at terminals. This will account for interlined trips.

10.8 - APC Required

The APC system will only count boarding and alighting when the doorway is open, to avoid any counting of passengers moving in the vicinity of the doorway passages between stops.

10.9 - APC Required The Solution can be configured to count a passenger when a door is “opening” or “closing” to ensure all passengers are counted.

10.10 - APC Required The APC will count successive passengers that are walking as close together as is practical, either one behind the other or side by side.

10.11 - APC Required The APC will count moving passengers with speed between 0.1 and 3 meters per second.

10.12 - APC Required The APC will count passengers with heights between one (1) meter and the maximum height of the doorway.

10.13 - APC Required The APC will detect the direction of motion for boarding and alighting passengers, regardless of door height or crowds.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

10.14 - APC Required The APC will not separately count objects carried by passengers, such as shopping bags or umbrellas.

10.15 - APC Required The APC system will detect and track door openings correlating to actual transit stops.

10.16 - APC Preferred

The APC will account for temporary stops, temporary bus stop closures, and re-routes. If the vehicle goes off route, the Solution can continue to log the longitude and latitude of all locations where the doors open/close.

10.17 - APC Required The APC will create a data record for each stop and to store the number of boarding passengers.

10.18 - APC Required

Each data record will also include the current GPS location latitude and longitude, current date/time, vehicle number, vehicle operator ID number, route number, trip number, and direction of travel.

10.19 - APC Preferred APC data will be pushed to the GTFS-RT feed so that the public can see the capacity of DASH buses.

10.20 - APC Preferred

Upgrade all current Hella APC-R equipped buses to the latest available optical passenger counting solution that is compatible with existing Hella/Xovis APS-R hardware.

Transit Signal Prioritization (TSP)

11.1 - TSP Required

The Offeror should detail any experience and/or options on offer with Transit Signal Prioritization

(TSP).

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

Yard Management

12.1 – Yard Management Preferred

The Yard Management System will maintain a yard plan showing the current vehicle locations, IDs, availability status, and assignments by operator and run or block; and provide for vehicle status updates by the Maintenance Department.

System will have user configurable logic which will dictate status and needs of vehicle. i.e.: vehicles returning from service should automatically be configured to be “needs to be serviced”. Once processed through a service station, the status can automatically be changed to “ready for service”, etc.

12.2 – Yard Management Preferred

The yard plan and vehicle status will be available to the Dispatch Center console and to selected pre-existing Maintenance Department workstations.

12.3 – Yard Management Preferred Display yard plan in graphical format matching the actual layout of the yard.

12.4 – Yard Management Preferred Automatically record movements of a vehicle in, out of, and within the yard.

12.5 – Yard Management Preferred

Provide vehicle status such as holding vehicles for maintenance and vehicle being cleaned and disinfected.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

12.6 – Yard

Provide integration via API from 3rd party charge management system on status, occupation, State of Charge (SOC), and rate of charge of all electric bus chargers. These data points must be made available on the yard management interface of the CAD/AVL system.

12.7 – Yard

Provide integration via API to 3rd party electric vehicle dispatch planning aid software, such as WideSense. Data points to be shared should include but is not limited to electric bus position, SOC, active/inactive charging status, estimated time to availability, and availability to dispatch based on physical location.

Automatic Vehicle Monitoring (AVM)

13.1 – AVM Preferred

DASH staff will have the ability to manage all fleet vehicles in real-time with built-in features, to maintain on-time performance and make informed rerouting decisions.

13.2 – AVM Preferred The Solution can include health reporting on the state of system, each bus, and all connected devices.

13.3 – AVM Preferred

Seamless integration with Fleetio software.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

Inspection Software

14.1 - Inspection Software Preferred

The Offeror will provide an option for pre/post trip vehicle inspection software. Drivers should be able to perform pre/post trip vehicle inspections via the MDT. Once the pre/post trip is completed, the inspection should automatically be sent to maintenance for dispatching to the responsible departments for pending repairs.

14.2 - Inspection Software Preferred

Mutually exclusive of an in-suite solution, the Solution has the capability to integrate with 3rd party pre-trip inspection systems, such as Fleetio or Zonar, via defined interfaces. For example, a functionality would be if a bus fails a safety critical inspection during a street relief, that should flag back to dispatcher in CAD indicating “bus on block 2201 failed inspection, needs to be replaced ASAP”.

Please describe the capability of the integration.

Service Data Management

15.1 – Service Data Management Required

The Solution can be capable of defining stops as:

• Time Points;

• Stop Points; and

• Terminals.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

15.2 – Service Data Management Required

The Solution can be capable of quick changes to a route, including corrections to driver/operator errors. For example: Quickly adding a stop back to a route that was removed by accident. Changes to assignments should not require a restart of the tablet, or a logout and login to receive changes.

The system will automatically update and refresh for both Dispatch and Operators.

15.3 – Service

There will be a simple, user-friendly system that allows for verification of passenger counts, number of trips, vehicle mileage, revenue service hours, and allows for corrections. Ideally, this system will highlight data or issue a warning when data is outside of normal parameters.

15.4 – Service

Management and development of service schedules, including the ability to build and modify from a database of route patterns, stops, and timetables.

15.5 – Service

Create new routes and modify existing route paths, bus stop locations, time points, trips, and relief points.

15.6 – Service

The Solution can allow DASH to edit to route lines, stop locations, vehicle announcements, end of line points, and other standard functions of a transit system.

15.7 – Service

The Solution can provide visual mapping interface where users can define and view routes, stops, relief points, break points, and garage locations.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

15.8 – Service

The Solution has the ability to assign garage, service IDs, and certain vehicle types to specific routes.

15.9 – Service

The Solution has the ability to allow multiple patterns and run times for routes based on time of day, day of the week, and season (including route deviations).

15.10 – Service

The Solution has the ability to make network changes in planning and immediately understand scheduling implications due to large and small changes including but not limited to, network changes, vehicle type changes, route changes, stop changes, etc.

15.11 – Service

The Solution has the ability to assign headsign codes to route patterns for further integration into

CAD/AVL.

15.12 – Service Data Management Required The Solution has the ability to alert the user when a route is unassigned or is missing a running time.

15.13 – Service Data Management Required

The Solution has the ability to import actual runtimes from the solution and compare to scheduled times to determine areas of consistent late/early activity and to highlight recommended adjustments to improve on-time performance.

15.14 – Service

The Solution has the ability to holistically analyze network service to improve on-time performance by assisting the planner to determine if edits need to be made on a trip-by-trip level.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

15.15 – Service

The Solution can have the ability to import a database of stops from spreadsheets (CSV, Excel, etc.), including multiple characteristics such as:

• Location;

• Amenities at stop (shelters, benches, bike racks, trash cans, etc.);

• Locations (latitudes and longitudes); and

• ADA accessibility.

15.16 – Service

DASH staff will have the ability to create geofences for:

• Bus Stops;

• Facilities (example: bus garage); and

• Transit Center.

15.17 – Service Data Management Required DASH Staff will have the ability to create geo-fences for announcements.

15.18 – Service Data Management Required

The Solution can be programmable with blocking from the runcut so buses will move between routes without requiring DASH operations staff to adjust which buses are assigned to a given route, while accounting for layovers and interlining routes and service types.

15.19 – Service

The Solution can allow DASH Staff to have the ability to include ad-hoc vehicle blocks to the CAD system when extra bus service is provided or to combine routes when there is a driver shortage.

This option will allow same day changes.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

General Transit Feed Specification (GTFS)

16.1 - GTFS Required The Offeror shall provide free use API endpoints.

16.2 - GTFS Required

The Offeror shall provide free use of GTFS-RT feeds that are synced with a static GTFS feed source designated by DASH Staff. The Solution can be the official GTFS of the agency and used for all information.

16.3 - GTFS Required

API endpoints will be open for free use by any developer, providing the following data at minimum:

• GTFS-Realtime Trip Updates;

• GTFS-Realtime Vehicle Positions;

• GTFS-Realtime Service Alerts; and

• Web-accessible location for GTFS static feed located at a stable URL that can be accessed by data ingesters.

Agency-defined attributes like trip and stop numbers should be preserved in the GTFS dataset.

16.4 - GTFS Preferred The GTFS-RT feed will include real-time capacity information from the APCs.

16.5 - GTFS Required The GTFS will be the complete file for public consumption.

16.6 - GTFS Preferred The Solution can include all provisions necessary to update and publish all GTFS data related to bus fares.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

16.7 - GTFS Required

The Solution can have the capability to publish real-time changes to routes or schedules without the need for pre-scheduling (i.e. making changes twenty-four (24) hours in advance).

16.8 - GTFS Required

Alerts published to GTFS feeds will include the alert title, date(s) affected, cause of issue, impact on service, and option for a photo, and an option to publish a translated alert.

16.9 - GTFS Required

All GTFS feeds will be of proven quality to allow for integration into Google Maps.

(Please note that all static GTFS datasets must pass Feed Validator requirements as defined by the General Transit Feed Specification steering organization.)

16.10 - GTFS Required

The Offeror can supply all services (i.e. cloud hosting, support, server expenses, etc.)

necessary for the continued operation of these items with ninety-nine percent (99%) or greater uptime per month for the duration of the contract period.

16.11 - GTFS Required

All data in any format retrieved from these endpoints and interfaces must be fully owned by the DASH or licensed in such a way that the DASH has free, unrestricted, transferrable, and irrevocable rights to store and use said data, including its combination with other data sets.

16.12 - GTFS Required The Solution can provide both GTFS static and GTFS Real-time feed.

RFP: Computer-Aided Dispatch / Automatic Vehicle Location (CAD/AVL)

System Replacement

16.13 - GTFS Required The Solution can generate robust GTFS for both downstream integration and to provide to third-party rider information systems.

Operations and Payroll

17.1 – Operations and Payroll Optional

The Offeror will provide a Daily Dispatch, Time and Attendance module that records all transit operator attendance and assigns paid hours based on the Collective Bargaining Agreement rules. The Solution can include the following listed in the subsections below:

17.1a – Operations and

Payroll Optional

a) time management, including overtime payment management in accordance with the agency’s Collective Bargaining Agreement with union employees. Keeping track of the work done by drivers as well as calculating payroll must be included.

17.1b –

Payroll Optional

b) attendance management (track driver clock-in and clock-out and provide visibility into who is working each day).

17.1c –

Payroll Optional c) provide real-time alerts to notify users of critical issues such as driver no-shows or late shift starts.

17.1d – Operations and

Payroll Optional d) The system must be able to add and track absences for every driver.

17.1e – Operations and

Payroll Optional

e) ability to…