Appendix_A_Lextran_CADAVL_Final_Requirements_Updated.xlsx
XLSX spreadsheet 56 KB Posted
- Solicitation number
- 2023-06
- Issued by
- Essex County, Kentucky
About this file
This file is a technical specification appendix for a comprehensive Computer-Aided Dispatch/Automatic Vehicle Location (CAD/AVL) and Enterprise Resource Planning (ERP) system Request for Proposals (RFP) issued by Lextran, the Transit Authority of Lexington-Fayette Urban County Government in Kentucky. The RFP seeks a competitive contract for an integrated technology solution covering IT infrastructure, voice and data communication, onboard systems, central systems, maintenance and finance management, garage management, and project implementation. Proposals are due by 5:00 pm Eastern time on September 29, 2023, with all questions and clarification requests due by August 17, 2023. The contract will include initial implementation and a potential four-year warranty period, with options to extend support for up to six additional years in two-year increments.
The technical specifications detail extensive requirements for a comprehensive transit technology ecosystem, including advanced features such as automated passenger counting, vehicle health monitoring, automated vehicle announcements, garage management, and robust financial management modules. The system must integrate with existing Lextran infrastructure, support multiple vehicle types, provide real-time data tracking, enable comprehensive reporting capabilities, and meet various industry standards including National Transit Database (NTD) reporting requirements. Key components include GPS tracking, wireless communication, mobile data terminals, digital signage integration, and interfaces with existing systems like radios, fareboxes, and video surveillance. The RFP emphasizes flexibility, modularity, data ownership, security compliance, and the ability to support future technological expansions and integrations.
View the file
Other files
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
Technical Specifications
| Appendix A: Technical Specifications |
| Each tab on this worksheet contain the technical specifications for this project. Proposers are required to respond to each item on each tab. Proposals with missing, incompleted, or ambiguous responses can be deemed non-responsive. Proposers may not edit any technical specification. |
| Response Code | Definition |
| F | Fully Compliant – Proposer fully complies with requirement. Responses that are qualified by exceptions or limitations, etc. in the Compliance Matrix shall be considered the equivalent of “N” (does not comply). |
| CM | Complies with Modified Requirement – Proposer shall provide modified requirement language to which they commit to comply, without requiring development. The “CM” will be equivalent to a response of “F” if WC opts to change the requirement as proposed, or to a response of “N” if WC opts to not change the requirement. |
| If complete alternate requirement wording is not proposed in conjunction with a “CM” response, the response will be considered equivalent to a response of “F” to the requirement as stated in the RFP until complete alternate requirement wording is agreed. WC alone shall be the judge of the completeness and appropriateness of alternate requirement language. | |
| D/I | Development Required / Integration or Interface Development – Proposer intends to comply with this requirement, but needs to further develop their solution (not including configuration changes) to provide this functionality, or will be required to develop an integration or interface with a third-party software to enable this functionality. |
| N | Does Not Comply – Proposer does not comply with the requirement. Accompanying comments are discouraged. |
1.0 IT Infrastructure
| Req # | Function | Requirements | Proposer Response | Proposer Notes |
| 1.01 | 1.0 IT Infrastructure | The hosted system should be based on an open architecture model supporting: |
- development of new ideas and future interfaces
- Hardware (and software) inventory database
- Utilization of latest versions of common, industry standard OS platform and software
- Flexibility and modularity for future expansion and upgrades to newer devices and hardware
| 1.02 | 1.0 IT Infrastructure | The hosted system shall provide Lextran with data ownership rights and unrestricted access to data, databases (including scripts and schema, entity relationship diagrams, data dictionary, etc.) and allowed number of product licenses. Additional provisions to integrate database with other applications shall also me made in the future if desired by Lextran. |
| 1.03 | 1.0 IT Infrastructure | Lextran shall approve Contractor's proposed security settings and policies for all systems hosted by Lextran. All software security shall be provided in accordance with best practices identified in International Organization for Standardization and the International Electrotechnical Commission (ISO/IEC) 27002 or an alternative published standard from a recognized security-standards body. |
| 1.04 | 1.0 IT Infrastructure | The contractor shall provide Lextran with specifications for all provided hardware and necessary data documentation typical to transit agency operations. |
| 1.05 | 1.0 IT Infrastructure | The system shall include tools necessary to track and report on the industry-standard metrics. |
| 1.06 | 1.0 IT Infrastructure | The Contractor shall propose and supply a data archiving and archive retrieval solution in addition to identifying an incremental or other timeframe-based data backup procedure that might integrate with Lextran's existing backup process. Data storage space needs shall consider sufficient storage for a minimum of ten (10) years. |
| 1.07 | 1.0 IT Infrastructure | The Contractor shall set-up the central system in redundant configuration by default and clearly describe their approach for enabling the redundant server. |
2.0 Voice & Data Comm.
| Req # | Function | Requirements | Proposer Response | Proposer Notes |
| 2.01 | 2.1 General Requirements | The Contractor shall describe the approach to integrating with existing Lextran data communication infrastructure and providing supporting communications infrastructure and applications required to satisfy the following communication needs for this project, in conformity to the requirements outlined in the following sections: |
• Duplex (two-way) wireless data communication between the Lextran central system and revenue or non-revenue vehicles, while located in Lextran yards; and
• Duplex wireless data communication between the Lextran central system and revenue or non-revenue vehicles while en-route within Lextran's coverage area.
| 2.02 | 2.2 On-Board Equipment | The Contractor shall use a multi-band antenna to limit the number of antenna hardware to be installed on each vehicle. An antenna which can support a combination of global positioning system (GPS) connection, cellular network connection and wireless fidelity (Wi-Fi) connection using a single unit shall be used. |
| 2.03 | 2.2 On-Board Equipment | The Contractor shall detail an integration plan with Lextran's existing Cradlepoint Ibr900 mobile gateway routers (MGR). The Contractor shall suggest their preferred cellular provider and MGR for consideration. |
| 2.04 | 2.2 On-Board Equipment | The Contractor shall integrate the MGR to the on-board components provided by the Contractor for the new CAD/AVL system, such that the MGR is the primary communication pathway for wireless transmission of operational data between the fixed route vehicles and the central system. |
| 2.05 | 2.2 On-Board Equipment | Where private Lextran wireless local area network (WLAN) access is available (e.g. at yards), all data exchanged between the vehicle and central system shall be completed over WLAN connection, in order to minimize metered data charges. Contractor shall utilize the MGR's Institute of Electrical and Electronics Engineers (IEEE) 802.11x Wi-Fi connection for this purpose provided by access points in the yard. |
| 2.06 | 2.2 On-Board Equipment | Each MGR deployed in Lextran’s fleet shall support routing of traffic to/from a specific bus, and to/from a specific IP-addressable device on that bus. It should be also capable of: |
i. Communication monitoring
ii. Reporting
iii. Statistics
iv. Management of cellular service for each vehicle by Lextran
v. Integration with CAD/AVL(system and onboard components)
vi. Integration and design for each vehicle type
| 2.07 | 2.2 On-Board Equipment | The Contractor shall use Lextran’s Dynamic Multipoint VPN (DMVPN) that connects the MGR to Lextran’s central system, rather than the public Internet. | |
| 2.08 | 2.3 Commercial Carrier Data Integration | The Contractor shall be responsible for the following: | |
| • | Designing the integration between the MGR and CAD/AVL on-board components for the purpose of data exchange; | ||
| • | Performing the installation of any necessary integration components; | ||
| • | Integrating the MGRs with the CAD/AVL components (e.g. vehicle logic unit (VLU)), as required; and | ||
| • | Interfacing the commercial cellular providers Private Network VPN in the back office components (e.g. CAD/AVL virtualized servers, CAD/AVL OCC/customer service/administrative workstations). | ||
| 2.09 | 2.4 Mobile Voice Communications (P25 Voice System) | Lextran and/or the vehicle OEM will provide and install P25 Phase 2 Trunked mobile radios that are compatible with the Lextran system independently on Lextran's fixed route transit vehicles. Radio Communication shall include the following features: |
i. Use of existing radio communication (fixed and portable units)
ii. Controlled electronically by the CAD/AVL VLU, via the mobile radio's auxiliary connector
iii. CAD/AVL application with Push-to-Talk (PTT) and full-duplex functionality.
iv. Voice calls – one-way, two-way, selected vehicle(s) and monitoring of call activities
v. Ability to locate and update vehicle information when incoming call is accepted by the controller.
| 2.10 | 2.5 Yard and Transit Center Communication | The CAD/AVL System shall upload/download all of the required bulk data from/to Lextran vehicles once they enter into the Wi-Fi coverage area, including: | |
| • | Fixed-route schedule data to vehicles | ||
| • | Configurations, firmware upgrades, and patches to vehicles | ||
| • | AVA annunciation files to vehicles | ||
| • | APC data download from vehicles | ||
| • | Video clips from the Digital Video Recorder (DVR) | ||
| • | VHM data from revenue vehicles | ||
| • | Pre- and post-trip inspection reports | ||
| • | Other needed data, such as driver/employee info |
3.0 Onboard Systems
| Req # | Function | Requirements | Proposer Response | Proposer Notes |
| 3.01 | 3.1 General | All onboard equipment shall be designed for use in a highly operational transit environment, with specific attention to ergonomics, reliability, efficiency, safety, and security of all system users. | ||
| 3.02 | 3.1 General | Failure of a single component must not cause a ripple effect in disabling another vehicle part, such as engine and electrical components. Contractor shall detail how the system identifies, reports, and alerts component failure. | ||
| 3.03 | 3.1 General | All equipment shall be compliant with applicable sections of the 47 Code of Federal Regulations (CFR) Part 15 of Federal Communications Commission (FCC) rules and regulations regarding radio frequency devices and shall be designed to operate in a transit environment. | ||
| 3.04 | 3.1 General | All onboard devices shall be designed for a minimum ten (10) years of useable life. The Contractor shall guarantee a minimum ten (10) years of availability of devices for replacement or fleet expansion. Newer versions of devices may be supplied, provided that they are backwards compatible with existing devices and systems. | ||
| 3.05 | 3.2 Environment | Onboard equipment, inside or outside, shall be capable of operating under typical transit operating environment in the Lextran service area during all seasons over the year. Where equipment does not comply with environmental conditions, equipment shall be protected with environmentally-protected enclosures or cabinets. | ||
| 3.06 | 3.3 Electrical | Onboarding wiring and cabling shall meet standards of an operational transit environment. The Contractor shall be responsible for the provision of all wiring, cabling, connectors, and terminations. If the Contractor deems any existing wiring and cabling sufficient to be reused then the Contractor shall provide documentation and warranty for each instance. | ||
| 3.07 | 3.3 Electrical | All in-vehicle equipment shall incorporate power conditioners/filters, be protected against absorption of "routine" electrostatic charges, over-voltages, and reverse polarity conditions, and shall not freeze up if power is applied in incorrect order | ||
| 3.08 | 3.3 Electrical | The Contractor shall identify the power requirements including start-up and operation for all equipment to be installed on vehicles. | ||
| 3.09 | 3.4 Vehicle Area Network (VAN) and Vehicle Local Area Network (LAN) | The Contractor shall install communications cabling and connections at par with standard transit operational requirements. | ||
| 3.1 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The Contractor shall provide a Vehicle Logic Unit and Mobile Data Terminal that act as the central processor, data storage, and device manager for all onboard devices and integrate with other onboard hardware to enable onboard processing and other functionality. The system shall contain hardware, software, and specifications that meet the standards of an operational transit environment. | ||
| 3.11 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall have the ability to automatically reset, reboot or refresh in case of component failure. | ||
| 3.12 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall support wireless and ethernet connectivity and allow remote access to control most onboard functions | ||
| 3.13 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall include interface and communication ports, onboard solid-state storage devices, and removable memory cards with sufficient storage space to house all data for several operational days until it’s been uploaded and before being overwritten. | ||
| 3.14 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall ensure that real time data captured is safe from being lost in case of failure. The VLU shall check for and download bulk data files when entering Lextran's maintenance facility. The VLU shall also be able to download data over cellular when manually prompted to do so. | ||
| 3.15 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall allow Lextran staff to manually access and download stored data during a communications or other hardware failure as a redundant back-up option. This may be accomplished using a service laptop connected to a USB port or through the use of removable media. If removable media is used, the VLU operating system must not reside on the same removable media as other data. | ||
| 3.16 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall be ADA compliant and be configurable with touch screen, push buttons, and/or voice commands | ||
| 3.17 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall need passwords for logging on which can be operated remotely and changed when needed via configuration download | ||
| 3.18 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall allow audio alters, announcements, and specific automated alters to dispatch and offer messaging capabilities from/to dispatch including: |
i. Predefined and configurable canned messages sent with a single command
ii. Voice control only when vehicle is in safe-driving mode
iii. Trigger headway maintenance issues
iv. Trigger notification of any malfunctioning component
v. Audio and visual indicators
| 3.19 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The safe driving mode shall allow Lextran management to determine the criteria that will prevent vehicle operators from interacting with MDTs when driving. Criteria will include when the vehicle is moving above a configurable speed limit (e.g., 5 miles/hour). | |
| 3.2 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | Upon successful logon, the MDT shall display a configurable pre-trip inspection screen that shall be filled in by the vehicle operator after conducting their pre-trip inspection of the vehicle. Activation of this feature shall be a configurable parameter that Lextran can choose to use. | |
| 3.21 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The inspection data shall be uploaded automatically to the central system in real-time; specifically Covert Alarm and Wheel Chair Inspection Reports, and shall be available to the authorized staff to review as needed. Lextran will decide at the time of design review on what other inspection items shall be displayed on the CAD screen or should be available for offline reporting. | |
| 3.22 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall include transit industry standard GPS connectivity providing high level of accuracy and connectivity to GPS satellites. | |
| 3.23 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The GPS Receiver shall report real time data (such as vehicle location, traffic conditions, ETA to next bus stop, etc.) | |
| 3.24 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall allow automated transmission of specific real time data (such as destination and next bus stop/location) to onboard electronic signs | |
| 3.25 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall provide position reports to the central system as follows: | |
| • | Routine position reports shall be provided every 5 seconds while the vehicle is in operation, regardless of whether it is logged-on or not; | ||
| • | Event-based position reports shall be provided every time the vehicle passes a stop or time-point, regardless of whether the vehicle stops or not; and | ||
| • | At transit centers, position reports shall be provided when the vehicle enters the transit center, when it arrives at the designated bay, when it departs the bay, and when it leaves the transit center. | ||
| 3.26 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The Contractor shall interface with the existing voice radios to provide closed-mic communication between vehicle operators and dispatchers and have features typical to standard transit operations. | |
| 3.27 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall allow the vehicle operator to select a set of pre-defined messages to send a canned data message to the central system. All canned messages to dispatch shall include the date, time, location (latitude and longitude) vehicle ID and vehicle operator ID. | |
| 3.28 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The VLU shall use wireless data communications thru the MGR to send and receive messages with the central software at any time. The transmission and storage data protocol shall be standard for typical transit operations | |
| 3.29 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall be equipped with a covert microphone having adjustable orientation and sensitivity and capable of providing functions typical to transit operations | |
| 3.3 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The covert alarm switch shall be mounted at a location that can be easily pressed by the operator in a discreet manner but unlikely to be accidently activated. Once the switch is pressed it will also activate the event flag on the digital video recorder (DVR) of the on-board surveillance system for automated recording per configurations within the DVR. | |
| 3.31 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall allow Audio and visual notifications on configurable discrepancies: |
i. Scheduling
ii. Timings
iii. Vehicle off-route (and then when reverting to on-route)
| 3.32 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The MDT shall be equipped with a navigation assistance module to provide visual and audible turn-by-turn instruction for operators of fixed-route vehicles. This navigation assistance will also be provided for detours. Whether or not this feature is enabled shall be configurable by Lextran. | |
| 3.33 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The Contractor shall provide interfaces and all necessary interface control documents (ICDs) to existing onboard systems provided including but not limited to: | |
| • | Odometer | ||
| • | Headsign; | ||
| • | Dynamic Message Signs (DMSs); | ||
| • | Public Speakers; | ||
| • | Farebox and Fare Collection Systems; | ||
| • | DVR | ||
| • | APC | ||
| • | AVA | ||
| 3.34 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The onboard system shall allow operator or Controller override of destination sign code, and log such overrides. | |
| 3.35 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The system shall have to ability to integrate with Lextran's onboard fare payment systems; including any standalone farebox systems and shall provide standard functions typical to transit operations | |
| 3.36 | 3.5 Vehicle Logic Unit and Mobile Data Terminal | The system shall have the ability to integrate with the existing security equipment (cameras, DVRs) provided by TSI and shall provide standard functions typical to transit operations | |
| 3.37 | 3.6 Automatic Passenger Counter (APC) System | The Contractor shall provide an end to end Automatic Passenger Counter system hardware solution where existing hardware cannot be used. | |
| 3.38 | 3.6 Automatic Passenger Counter (APC) System | The APC system shall be able to integrate with the existing APC hardware provided by Infodev. | |
| 3.39 | 3.6 Automatic Passenger Counter (APC) System | The system shall provide functionality to confirm that the APC is operational as part of the vehicle pre-trip inspection process, | |
| 3.4 | 3.6 Automatic Passenger Counter (APC) System | The system shall alert the operator and dispatch if the APC is disabled or malfunctioning. The system shall log any faults as part of maintenance reporting. | |
| 3.41 | 3.6 Automatic Passenger Counter (APC) System | The system's integration with the APC shall support reporting of passenger loads in real-time to the dispatch central system: | |
| • | Specific trips or blocks; | ||
| • | Exceeding a defined load threshold related to vehicle type; and | ||
| • | On-demand data request | ||
| 3.42 | 3.6 Automatic Passenger Counter (APC) System | The Contractors shall describe their experience in helping other agencies with the Federal Transit Administration (FTA) certification process for using APC data for National Transit Database (NTD) reporting. | |
| 3.43 | 3.6 Automatic Passenger Counter (APC) System | The APC system shall detect and track door openings correlating to actual transit stops. It shall be possible to account for siting of temporary stops, or temporary bus stop closures and re-routes. Actual transit stops may include flag stops on detours or other non-permanent locations. If the vehicle goes off-route, the system shall continue to log the longitude and latitude of all locations where the doors open/close. | |
| 3.44 | 3.6 Automatic Passenger Counter (APC) System | The doorway sensors shall be able to count and differentiate between boarding and alighting passengers. | |
| 3.45 | 3.6 Automatic Passenger Counter (APC) System | The system shall consist of Individual APC units centrally controlled by main APC controller and shall have the ability to manually collaborate sensors and review download/stored data | |
| 3.46 | 3.6 Automatic Passenger Counter (APC) System | APCs as installed in each combination of vehicle door location and vehicle model shall have a precision of plus or minus five (5) percent or less at the 95% level of confidence for both boardings and alightings, as established from observed versus APC-measured counts for door open-close cycles with non-zero passenger activity. | |
| 3.47 | 3.6 Automatic Passenger Counter (APC) System | The Proposer shall provide information on the maintenance required for the proposed APC solution (e.g., recalibration of sensors) to maintain the required 95% APC accuracy. | |
| 3.48 | 3.6 Automatic Passenger Counter (APC) System | The APC controller shall be interfaced with a wheelchair lift sensor and record the number of wheelchair lift operational cycles at each stop. | |
| 3.49 | 3.6 Automatic Passenger Counter (APC) System | For each stop, the APC controller shall create a data record to store the number of boarding and alighting passengers for each doorway, the number of wheelchair lift activations, and the number of errors. | |
| 3.5 | 3.6 Automatic Passenger Counter (APC) System | Each data record shall also include the current GPS location’s latitude and longitude, as well as the current date/time, vehicle number, vehicle operator ID, run number, route number, and trip number. | |
| 3.51 | 3.7 Automated Vehicle Announcements (AVA) System | The system shall have the ability for the solution to integrate with the existing PA system to provide: | |
| • | Audio announcements over an internal speaker system to inform on-board passengers; | ||
| • | Audio announcements over an external speaker to inform intending passengers; and | ||
| • | Visual announcements on Lextran's existing interior passenger information displays that provide a text version of on-board audio announcements. | ||
| 3.52 | 3.7 Automated Vehicle Announcements (AVA) System | The AVA system shall include the ability to broadcast simultaneous audio and visual announcements utilizing recorded and text-to-speech audio transmitted from dispatch. | |
| 3.53 | 3.7 Automated Vehicle Announcements (AVA) System | The AVA shall be integrated with the system for automated, configurable, live notifications of upcoming stops, intersections, landmarks and accommodate defining trigger zones | |
| 3.54 | 3.7 Automated Vehicle Announcements (AVA) System | As each fixed-route vehicle approaches a stop or other designated location, a digitally-recorded announcement shall be made automatically in English and Spanish languages over the existing on-board public address (PA) system speakers and displayed on DMS inside the vehicle to inform passengers about upcoming stops, major intersections, and landmarks. | |
| 3.55 | 3.7 Automated Vehicle Announcements (AVA) System | Lextran shall be able to configure the announcements so they are made in either English or in Spanish or both languages. | |
| 3.56 | 3.7 Automated Vehicle Announcements (AVA) System | The location information announced/displayed shall provide the stop name and transfer opportunities. | |
| 3.57 | 3.7 Automated Vehicle Announcements (AVA) System | As part of the pre-trip inspection, functionality shall be provided to test the AVA system by playing an audio and visual test message. The system shall alert the operator and dispatch of any fatal error condition that occurs during pre-trip tests. | |
| 3.58 | 3.7 Automated Vehicle Announcements (AVA) System | The vehicle operator shall have the ability to trigger the activation of any pre-recorded announcements manually. | |
| 3.59 | 3.7 Automated Vehicle Announcements (AVA) System | The system shall include functionality to display a “stop requested” message on the DMS and make an audible "stop requested" announcement when a customer activates a stop request or wheelchair area stop request. | |
| 3.6 | 3.8 Vehicle Health Monitoring (VHM) | Contractor shall provide a full-featured Vehicle Health Monitoring system solution for onboard diagnostics management that shall interface with existing multiplex and powertrain systems and be integrated with the VLU to obtain system date/time and current vehicle latitude/longitude information and with fleet to collect codes from engine, transmission and breaking system modules | |
| 3.61 | 3.8 Vehicle Health Monitoring (VHM) | The VHM shall monitor vehicle controls – including fluid levels, temperature, voltage, oil pressure, etc. | |
| 3.62 | 3.8 Vehicle Health Monitoring (VHM) | The VHM shall prompt reporting to central controller of any alarms resulting from malfunctioning components | |
| 3.63 | 3.8 Vehicle Health Monitoring (VHM) | The MDT shall provide access to maintenance diagnostic and troubleshooting information screen to appropriately authorized users. | |
| 3.64 | 3.10 Supervisor/Support Vehicles Equipment | The Contractor shall equip supervisor vehicles with typical operations equipment to provide remote dispatching capabilities. Supervisor vehicles shall be equipped with built-in GPS receivers to enable vehicle location tracking. Lextran shall have the ability to track all supervisor and maintenance/service vehicles using the CAD/AVL software. | |
| 3.65 | 3.11 On-board Video Surveillance System | The Contractor shall integrate with existing cameras or provide their own cameras to provide a full-featured Onboard Camera system solution for onboard video data capture and monitoring using up to 16 cameras (front/rear ends and sides) |
4.0 Central Systems
| Req # | Function | Requirements | Proposer Response | Proposer Notes | |
| 4.01 | 4.1 General | All central systems equipment shall provide features standard to a highly consumption and operational transit environment, and be designed for use with a specific attention to ergonomics, reliability, efficiency, safety, and security of all system users. The contractor shall leverage the existing infrastructure and equipment wherever possible and be fully responsible for implementing these interfaces. | |||
| 4.02 | 4.1 General | Any patches, updates, and version upgrades by hardware or software Contractors, (including operating systems), shall not void CAD/AVL Contractor warranty. | |||
| 4.03 | 4.1 General | The system shall be designed for continuous operation without the need to manually “reboot” computers or devices. Necessary scheduled reboots will not impact day-to-day operations. | |||
| 4.04 | 4.1 General | The central system and all CAD/AVL subsystems shall automatically recognize any stoppage, failure, failover, or lock-up of a system process and automatically log the problem, attempt a restart if appropriate, and notify appropriate staff. | |||
| 4.05 | 4.1 General | The system shall include user/role based security for software and applicant access and shall provide a single-point interface for the management of user accounts, groups, and associated privileges. | |||
| 4.06 | 4.1 General | The system shall not place limitations (through licensing or otherwise) on the number of concurrent workstations sessions running on virtual or physical workstations. | |||
| 4.07 | 4.2 Built-in Maps | The Contractor shall provide high-quality and regularly updated mapping data for all map-based software with the ability to use them consistently for various systems and modes (scheduling, paratransit and fixed route) | |||
| 4.08 | 4.2 Built-in Maps | The system shall include mechanisms to allow for frequent updates to built-in maps in the central and on-board systems at par with standard transit industry practices. | |||
| 4.09 | 4.2 Built-in Maps | Lextran shall be able to edit and update map layers used in vendor provided GIS modules. | |||
| 4.10 | 4.3 Data Import and Integration Interfaces | The CAD/AVL system shall have the ability to independently import scheduling data from the new scheduling system as part of an automated procedure with the central system checking for files or views in a predetermined directory, or database table, or as a real-time service (service oriented architecture). | |||
| 4.11 | 4.3 Data Import and Integration Interfaces | The imported data will include stops, timepoints, combined stop/timepoints, routes, route traces, route variants, patterns, blocks, trips, timetables, service calendars, day types, service types, exceptions, and other relevant schedule data for purposes of supporting CAD/AVL and functions. | |||
| 4.12 | 4.3 Data Import and Integration Interfaces | The CAD/AVL system shall be interfaced with the workforce management system to provide the following functions: | |||
| • | Real-time updates on operator schedule | ||||
| • | Real-time updates on vehicle assignments | ||||
| • | Real-time updates on work performed by operators as recorded by the CAD system to generate exceptions in the workforce management system for reporting on payroll hours | ||||
| 4.13 | 4.3 Data Import and Integration Interfaces | Data exchange between the CAD/AVL and workforce management systems shall be automated and does not require any manual intervention from Lextran staff. | |||
| 4.14 | 4.4 CAD/AVL System | The system shall use typical MS Windows-style graphical user interface (GUI) conventions with features standard for use in typical transit environemnts | |||
| 4.15 | 4.4 CAD/AVL System | The Contractor shall provide remote access to the CAD/AVL system to customer service, maintenance, supervisors for off-site dispatching, staff at transit centers, and other authorized Lextran staff and describe their approach for remote connectivity | |||
| 4.16 | 4.4 CAD/AVL System | The Contractor shall provide technical requirements for ruggedized laptops or equivalent mobile hardware such as tablet along with required software licenses to allow remote mobile access for supervisor vehicles to the central fixed-route CAD/AVL system over a cellular data connection. | |||
| 4.17 | 4.4 CAD/AVL System | The dispatch shall be able to view the location of supervisor vehicles equipped with mobile laptops on CAD/AVL map views; in addition to fixed-route vehicle locations. | |||
| 4.18 | 4.4 CAD/AVL System | The system shall be able to process and provide real-time location and mapping of revenue and non-revenue vehicles (e.g. supervisor vehicles). It shall provide access to all vehicle location tracking and other functions standard to typical transit operations through the map-based and schematic interface. | |||
| 4.19 | 4.4 CAD/AVL System | The system shall receive and store information related to event types and event data with event-triggered automatic location reports. Event types that trigger location reports shall include: | |||
| • | Location and schedule/route adherence reports; | ||||
| • | Text and pre-defined messaging; | ||||
| • | Data upload and download; | ||||
| • | Software updates; | ||||
| • | Device parameter changes; | ||||
| • | Onboard device status, changes, and error reports; | ||||
| • | System ignition/shutdown; | ||||
| • | Operator log-on/off/over; | ||||
| • | Arrival/departure at stop and time-point; | ||||
| • | Start and stop motion; | ||||
| • | Door open and close; | ||||
| • | Destination sign changes; and | ||||
| • | Onboard logs and alerts from the MDT. | ||||
| 4.20 | 4.4 CAD/AVL System | The system shall allow all Vehicle Data Replay functions standard to typical transit operations | |||
| 4.21 | 4.4 CAD/AVL System | The system shall allow Voice Call Management and Data Messaging features typical to standard transit operations | |||
| 4.22 | 4.4 CAD/AVL System | The system shall provide Central Covert Alarm Handling funcitons typical to standard transit operations | |||
| 4.23 | 4.4 CAD/AVL System | The Contractor shall provide information on how the system can create and track incidents. | |||
| 4.24 | 4.4 CAD/AVL System | The system shall have the capability to receive, store, and display vehicle location data received from multiple external systems (e.g., ridehail services). | |||
| 4.25 | 4.4 CAD/AVL System | The Contractor shall provide detail on how the CAD/AVL system could integrate with the City's traffic control system software to enable a Center-to-Center TSP implementation through the provision of TSP AVL data using industry standard data communication formats and inlcuding data feeds typical to standard transit operations. | |||
| 4.26 | 4.4 CAD/AVL System | The system shall provide access to all route and schedule adherence tracking functions and comprise of real-time headway and detour management capabilities through the GUI. | |||
| 4.27 | 4.5 AVA Software | The Contractor shall provide a full-featured automatic vehicle announcement (AVA) software that enables remote configuration of announcement and visual data. The AVA shall include generation of canned voice and message announcements, voice and message dissemination features, and other components standard to typical transit operations. |
4.28 4.6 Automated Passenger Counters (APCs) The Contractor shall provide an end to end Automatic Passenger Counter system solution that enables the following:
i. Management of APC System equipment in the fleet including Firwire, and Vehicle-specific configuration ii Post-processing for APC data including storage, management, and processing of APC/AVL data, and
iii. Archiving and retreival of the data in raw or report form.
4.29 4.7 Vehicle Health Monitoring Software The Contractor shall provide an end to end Vehicle Health Monitoring Software solution that enables-
i. Vehicle Health Monitoring of components/J1939 including capability to configure and apply different methods to monitor components,
ii. VHM data transmission and display through CAD/AVL system in real time with real-time data filtering in display feature, and
iii. Generation of VHM alerts and reports with Ability to configure sending of specific alerts or reports to staff
| 4.30 | 4.8 Data Feeds and Application Programming Interfaces | Contractor shall provide various data feeds and real-time APIs including Schedule data feeds in GTFS format, Real Time Passenger Information (RTPI) in GTFS-realtime format consisting of industry standard measures like Trip updates, service alers, vehicle positions, etc., as well as the tools to manage access to the APIs including key-based access amangement, diagnositics to monitor and manage developer use of API, and compaints and feedback management through online portal or general wesbite/module |
| 4.31 | 4.9 Business Intelligence, Reporting, and Dashboards | Contractor shall provide business intelligence, reporting, and dashboarding tools. |
| 4.32 | 4.9 Business Intelligence, Reporting, and Dashboards | The Business Intelligence (BI) tool and dashboard should have the ability to extract raw data in common formats including .csv, .xls etc. to be added to BI reporting and databases should support commonly used inquiry tools (ex. SQL) for data retrieval |
| 4.33 | 4.9 Business Intelligence, Reporting, and Dashboards | The BI tool shall provide Trip planning and scheduling feature. Forecasting (based on historical data, demand, weather conditions) |
| 4.34 | 4.9 Business Intelligence, Reporting, and Dashboards | The tool should include Incident reporting, monitoring and control with emailing capabilities along with Statistical reporting features including standard transmit management queries and those required by the National Transit Database (NTD) program |
| 4.35 | 4.9 Business Intelligence, Reporting, and Dashboards | The tool should provide standard Revenue measures – media sales, fares. Ridership shall include report on ridership data by fare category, shall also include daily/monthly report with detail for each boarding to include route # at boarding, pass type used and time. System shall be able to identify this information based on location coordinates not relying on driver input for route changes. |
| 4.36 | 4.9 Business Intelligence, Reporting, and Dashboards | The tool should include standard Maintenance measures including Real-time vehicle availability, maintenance work summary, and repeat failures summary. |
| 4.37 | 4.9 Business Intelligence, Reporting, and Dashboards | The tool should include standard Dispatch reports including Response Time, Detour Management, Incidenet Management, Dispatch Work, and Session Time |
| 4.38 | 4.10 Fixed-Route Scheduling Software | The Contractor shall provide a full-featured fixed route schedule software, that generates high-quality fixed route schedule data and integrates with other downstream systems (CAD/AVL system, workforce management system, etc) to communicate this data for subsequent use. The software should support both manual and automatically configured route and stop definition. |
| 4.39 | 4.10 Fixed-Route Scheduling Software | The software should enable trip building features standard for typical transit operations including creation of schedules and timetables (manually and automated), and ability to import data in different formats such as csv, xls, etc |
| 4.40 | 4.10 Fixed-Route Scheduling Software | The software should provide vehicle assignment (using blocks) features standard for typical transit operations |
| 4.41 | 4.10 Fixed-Route Scheduling Software | The software should have the ability to perform Runcutting operations based on labor contract rules and management/scheudling objectives |
| 4.42 | 4.10 Fixed-Route Scheduling Software | The software should enable autoamted and manual created of rosters that can be configured by the following types- |
i. Based on cost effectiveness, type, availability, work schedules and workload
ii. HR Information
iii. Flexible in labor contract rules for bids and picks
iv. Allow for flexilibity over time to enhance rules
4.43 4.10 Fixed-Route Scheduling Software The system shall integrate with the CAD/AVL Software for the purposes of exporting the following data:
· Stop information
· Route trace information, if available
· Vehicle schedule information
· Driver schedule information
| 4.44 | 4.10 Fixed-Route Scheduling Software | The system shall have the ability to export all data from the scheduling software, including payroll information by pay code, into an Excel file by pay code. |
| 4.45 | 4.10 Fixed-Route Scheduling Software | The system shall have the ability to export a detailed weekly time summary that includes all employess from the payroll system to an Excel file. |
| 4.46 | 4.10 Fixed-Route Scheduling Software | The system shall have the ability to export detailed and summary reports for each pay element and premium in the labor agreement to an Excel file. The data output shall be able to be generated by employee and period for each element and premium. All payroll detail needed for compliance with (NTD) National Transit Database, State of Kentucky, Agency audit, Federal and adherence to labor agreement reporting is required. |
| 4.47 | 4.10 Fixed-Route Scheduling Software | The system shall allow users to manage Daily Dispatching activities typical to standard transit operations, including an Extra Board, Supplemental Board, Volunteer Board, and so forth |
| 4.48 | 4.11 Public Facing Communications | The system shall include a mobile smartphone application that provides real-time arrival and departure information, trip planning, and other information typical to public transportation. The mobile smartphone application shall be customizable to include Lextran's branding. |
| 4.49 | 4.11 Public Facing Communications | The system shall be able to produce customer-facing real-time information at the Transit Center and potentially at key bus stops in Lexington. |
5.0 Maintenance & Finance MGMT
| Req # | Function | Description | Requirements |
| 5.01 | 5.0 Maintenance & Finance Management | 5.1 General | The Contractor shall implement a full-featured maintenance management software (MMS) that provide standard functionality typical to transit operations. |
| 5.02 | 5.0 Maintenance & Finance Management | 5.2 Data Conversion | The Contractor shall determine the necessary data required to make the system operational, identify what data will be available from current systems, and what data may have to be developed. the Contractor shall be responsible for cleaning and importing existing data into the new MMS. |
| 5.03 | 5.0 Maintenance & Finance Management | 5.3 Asset Inventory | The software should incorporate Management of fleet inventory and associated data, including but not limited to: |
i. Vehicle purchase and status history
ii. Prior maintenance issues and repair history
iii. Associated work orders and inventory usage
iv. Current vehicle status
5.04 5.0 Maintenance & Finance Management 5.3 Asset Inventory The software should incorporate facility and fixed asset (fixed equipment, ITS and networking equipment) inventory data, including:
i. Asset purchase and status history
ii. Prior maintenance issues and repair history
iii. Associated diagnostics and configuration changes (applicable for ITS and networking equipment)
iv. Current or last known status/equipment health
v. Depreciation calculations
5.05 5.0 Maintenance & Finance Management 5.4 Vendor Information Management The system shall provide the ability to manage vendor contact information including
i. Vendor information such as contact details, types of inventory/assets sold, etc,
ii. Purchase and pricing history, and
iii. Delivery and shipping information
5.06 5.0 Maintenance & Finance Management 5.5 Driver Reporting The system shall provide the ability for drivers to record issues for vehicle components defined in the system. At a minimum, the following information shall be provided:
· Vehicle number (selected from a predefined list);
· Driver ID (selected from a predefined list);
· Vehicle component (selected from a predefined list);
· Issue (selected from a predefined list);
· Description;
· Time of observation;
· Location of observation; and
· Vehicle operational status.
5.07 5.0 Maintenance & Finance Management 5.6 Work Orders The system shall support Creation, modification, supervision, finalization, and other ongoing management of work orders and associated data, including:
i. Type of work order and other status information
ii. Fleet involvement
iii. Staff involvement and time
iv. Associated purchase orders and pricing
v. Associated inventory usage
5.08 5.0 Maintenance & Finance Management 5.7 Maintenance Scheduling The MMS shall support scheduling and management of preventative and ad-hoc maintenance scheduling activities and data for fleet vehicles and associated inventory including:
i. Manual or automatic creation of PM or ad-hoc work orders,
ii. History of maintenance activities,
iii. Generation of predictive maintenance suggestions.
5.09 5.0 Maintenance & Finance Management 5.8 Parts Inventory Tracking The MMS shall have the ability to manage and track parts inventory data, including:
i. Parts stock management and updates
ii. Parts location
iii. Parts history, including supersessions (full history for each part attached to the current part, including all previous #'s/labels, dates, orders, etc.)
iv. Automatic and manual ordering based on pre-defined values
v. Generation of purchase orders for inventory replenishment.
5.1 5.0 Maintenance & Finance Management 5.9 Document Management The system shall allow management of documents associated with assets and inventory, including:
i. Purchase related documents,
ii. User manuals and design documents, Iii. Warranty and licensing documents.
5.11 5.0 Maintenance & Finance Management 5.10 Paperless Shop The system shall provide the ability to electronically record all maintenance-related activities in real-time to minimize or eliminate the use of paper. These activities include the following:
· Electronic reporting of vehicle defects and other maintenance issues with Lextran assets
· Work assignment to maintenance staff
· Tracking of labor hours by assigned task
· Work order management
· Electronic parts inventory management using barcode reader
· Electronic equipment check-in/check-out
5.12 5.0 Maintenance & Finance Management 5.11 Interfaces The system shall have an User-friendly interface providing:
i. Dashboard with pending, new, overdue status concerns (work orders, inventory, etc.)
ii. User notifications via email
iii. Management level dashboard
5.13 5.0 Maintenance & Finance Management 5.11 Interfaces The system shall provide different interfaces like-
i. Fuel Management System – Integration with fuel management system for fueling history and mileage data.
ii. Integration with the ERP System for purchase order/invoicing data sharing.
iii. Other integration/data exports – Export of other data, including payroll data.
5.14 5.0 Maintenance & Finance Management 5.12 Data Management and Reporting The MMS shall provide Data Management and Reporting functions including:
i. Transit Asset Management Reporting – Reporting of NTD required reports, including TAM reports,
ii. Needs to include support for Annual & Tri-annual audits
| 5.15 | 5.0 Maintenance & Finance Management | 5.13 General Finance | The financial system is a key piece of the overall solution. The financial system shall enable Lextran staff to perform typical transit finance related aspects, including General Ledger management, accounts payable, accounts receivable, and purchasing functions. |
| 5.16 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to create vendor profiles and assign various relevant attributes (e.g. vendor service type, location, address, payment type, vendor identification number etc.) in a streamlined process. |
| 5.17 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to search for, track and report vendor profile and associated activities by all stored attributes. |
| 5.18 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall provide for a permission-based user authorization access that limits access to different types of data and functionality by user type. |
| 5.19 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to attach documents and communications to the vendor record. |
| 5.2 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to verify TIN (Tax ID Number) to IRS database. |
| 5.21 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall support a streamlined process for invoice entry and a range of functionality options for the user’s convenience (e.g., batch entry, unlimited invoice line items, templates for recurring use etc.) Contractor shall work with Lextran to determine specifics. |
| 5.22 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to prevent common entry errors such as inactive or incorrect charge codes, duplicate invoices etc. |
| 5.23 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to flag missing or incorrect entries such as outstanding Purchase Orders and erroneous transactions when processing. |
| 5.24 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to make corrections/ modifications and edits to vendor payments, unposted invoice transactions, invoice records etc. |
| 5.25 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to electronically receive and process invoices from vendors. |
| 5.26 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to scan, attach and store vendor invoices related to a specific transaction. |
| 5.27 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall provide notifications for significant updates such as when a PO invoice is reversed, not approved or rejected. |
| 5.28 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to distribute invoice payments (by item or total) into multiple General ledger accounts and make partial payments (i.e., progress payments) on Purchase Orders. |
| 5.29 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to pay employee expenses (both travel and non-travel), issue expense advances and reconcile expenses for reporting. |
| 5.3 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to apply credit memo to PO and clear credit/ debit memo without processing payment. |
| 5.31 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to pay via ACH (multiple times a day), wire and check and p-card. |
| 5.32 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall generate a permanent file for export after bank reconciliation and prevent the altering of payment information after payment has been secured. |
| 5.33 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to process check runs at any time and allow withholding or deleting of selected items from payment for a particular check run. |
| 5.34 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to consolidate or separate checks issued to the same vendor in a check run. |
| 5.35 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to restrict the printing of negative and zero amount checks. |
| 5.36 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to issue checks or EFT payments from various back accounts. |
| 5.37 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to notify the user and restrict payments for manual checks greater than a user-defined maximum threshold. |
| 5.38 | 5.0 Maintenance & Finance Management | 5.14 Accounts Payable | The system shall have the ability to restrict the reuse of a check number. |
This is the start of the file's text. The full file is on GovTribe.
File details come from the government source that posted it. Updated .